AI 시대의 의사결정은 「상태 전이」로 강해진다. Worldline State Machine 실전 가이드

TL;DR

솔직히 AI를 사용할수록 선택지는 늘어납니다. 하지만 선택지가 늘어났다고 해서 의사결정이 가벼워지는 것은 아닙니다. 오히려 AI가 매번 그럴싸한 안을 10개씩 내놓기 때문에, 마지막에 인간이 "그래서, 뭘 고를 건데?"라며 멈춰버리기 쉽습니다.

이 기사에서는 그 망설임을 Worldline State Machine으로 다루는 방법을 작성합니다. 의사결정을 「정답 찾기」가 아니라, 현재 위치·후보 세계선·전이 조건·금지 조건·관측 지표·다음 액션을 가진 상태 전이 (State Transition)로서 설계하는 사고방식입니다.

AI에게 상담해도 망설임이 사라지지 않는 이유

AI에게 "어느 것을 우선해야 합니까?"라고 물으면, 대개 그럴싸한 대답이 돌아옵니다. "긴급도와 중요도로 정리합시다", "단기 임팩트와 장기 가치로 비교합시다", "리스크와 리턴을 봅시다". 물론 맞습니다.

하지만 말이죠, 옳은 말을 들어도 움직일 수 없을 때가 있지 않나요? 왜 그렇다고 생각하시나요? 저는 그 원인의 상당히 큰 부분이 현재 위치의 정의 부족에 있다고 생각합니다.

개발에서도 마찬가지입니다. Issue의 상태가 모호한 채로 "다음에 무엇을 구현할까요?"라고 물어도 대답은 흔들립니다. 요구사항 정의 중인지, 설계 리뷰 대기 중인지, 구현 중인지, 테스트 실패 대응 중인지, 릴리스 판단 대기 중인지. 이 상태가 모호하면 AI가 아무리 우수해도 망설입니다. 인간도 망설입니다.

상태 전이 (State Transition)란, 간단히 말해 어느 상태에서 다른 상태로 이동하는 규칙입니다. 신호등이라면 빨강→초록→노랑→빨강. GitHub Issue라면 Open→In Progress→Review→Done. 게임이라면 마을→필드→보스전→클리어.

의사결정도 이것으로 볼 수 있습니다. "망설이는 자신"을 탓하는 것이 아니라, 지금의 상태명은 무엇인지, 다음에 진행할 수 있는 상태는 무엇인지, 나아가기 위한 조건은 무엇인지, 나아가서는 안 되는 조건은 무엇인지, 나아간 후에 무엇을 관측할지를 봅니다. 이렇게 하면 AI에 대한 상담이 단번에 구체적이 됩니다.

Worldline State Machine이란 무엇인가

Worldline State Machine은 미래를 하나의 정답 루트로 보지 않기 위한 프레임워크입니다. AI 시대에는 선택지를 만드는 비용이 엄청나게 낮아졌습니다. 기획안도, 구현안도, 학습 계획도, 영업 문구도, AI가 순식간에 여러 개를 내놓습니다.

그렇기에 인간 측에 필요한 것은 「선택지를 늘리는 힘」뿐만 아니라, 어느 세계선으로 전이할지를 결정하는 설계력인 것입니다.

Worldline State Machine에서는 의사결정을 다음 6가지 부품으로 다룹니다.

부품	의미	예시
currentState	현재 위치	idea_collecting
...	...	...

예를 들어 개인 개발이라면, currentState는 "아이디어는 있지만 검증 전", worldline A는 "주말에 MVP를 만든다", worldline B는 "먼저 글로 수요를 측정한다", worldline C는 "일단 보류하고 기존 프로덕트 개선으로 돌아간다". 이렇게 하면 "MVP를 만들어야 할까?"라는 거대한 질문이 "지금의 상태에서 MVP 검증 상태로 전이해도 되는가?"라는 리뷰 가능한 질문이 됩니다.

Obsidian에 두는 Markdown 템플릿

처음부터 복잡한 도구는 필요 없습니다. Obsidian에서도 VS Code에서도 좋으니, 우선 한 장의 Markdown으로 만듭니다.

mkdir -p decisions
cat > decisions/worldline-sample.md <<'EOF'
# Worldline State Machine
...

이 템플릿의 좋은 점은 AI에게 그대로 전달할 수 있다는 것입니다. "이 메모를 읽고, 전이해도 될지 리뷰해줘"라고 말할 수 있습니다. "부족한 관측 지표를 보완해줘"라고 말할 수 있습니다. "TypeScript의 가드 함수 (Guard Function)로 변환해줘"라고 말할 수 있습니다.

TypeScript로 전이 가드(Transition Guard) 작성하기

Markdown으로 사고방식이 굳어졌다면, 다음은 TypeScript로 가드를 작성합니다. 가드란 "이 상태에서 다음으로 넘어가도 되는가"를 판정하는 함수입니다.

type StateId = "idea_collecting" | "validation_ready" | "mvp_building" | "paused";
type WorldlineId = "build_mvp" | "write_validation_article" | "pause";
type Constraint = {
...

다음은, 전이 가드입니다.

const transitionMap: Record<WorldlineId, StateId> = {
build_mvp: "mvp_building",
write_validation_article: "validation_ready",
...

사용할 때는 다음과 같습니다.

const result = evaluateWorldline({
currentState: "idea_collecting",
candidate: "write_validation_article",
...

인생이나 업무의 판단을 전부 코드로 결정할 필요는 없습니다. 하지만 코드로 구현할 수 있을 정도로 판단 재료를 분해하면, 모호한 망설임이 줄어듭니다.

GitHub Actions로 판단 방치를 탐지하기

의사결정에서 가장 아까운 것은 결정한 사항을 잊어버리는 것입니다. 그래서 Markdown에 reviewDate를 작성하고, GitHub Actions로 방치된 상태를 탐지합니다.

---
title: Worldline State Machine Sample
state: validation_ready
...

기한 만료를 탐지하는 Node.js 스크립트는 다음과 같습니다.

import fs from "node:fs";
import path from "node:path";
function parseFrontmatter(text: string): Record<string, string> {
...

name: decision-review-gate
on:
schedule:
...

코드에는 테스트가 있습니다. PR(Pull Request)에는 리뷰가 있습니다. 하지만 인생이나 프로덕트의 판단에는 리뷰 날짜가 없는 경우가 많습니다. 그래서 판단이 "말만 하고 끝나는" 상황이 됩니다. Worldline State Machine에서 판단은 상태 전이 (State Transition)입니다. 상태가 전이되었다면 관측합니다. 관측했다면 다음 상태로 진행할지, 되돌릴지, 보류할지를 결정합니다. 이 루프를 만들면 AI를 상당히 사용하기 쉬워집니다.

AI에게 맡기는 3가지 프롬프트 (Prompt)

1. 설계용 프롬프트

당신은 의사결정 설계 리뷰 담당자입니다.
다음 Worldline State Machine 메모를 읽고, 현재 위치·후보 세계선·전이 조건·전이 금지 조건·관측 지표·다음 액션으로 분해해 주세요.
제약 사항:
...

2. 리뷰용 프롬프트

당신은 엄격한 테크 리드 (Tech Lead) 겸 프로덕트 매니저 (Product Manager)입니다.
다음 DecisionContext를 리뷰하고, 이 상태 전이를 허용해도 될지 판정해 주세요.
관점:
...

3. 회고용 프롬프트

당신은 의사결정 로그 회고 담당자입니다.
다음 Worldline State Machine의 실행 결과를 읽고, 전이가 성공적이었는지, 되돌려야 하는지, 다음 상태로 진행해야 하는지를 판단해 주세요.
규칙:
...

디버깅용 프롬프트

다음 Worldline State Machine이 제대로 작동하지 않습니다.
원인을 「상태 정의」 「전이 조건」 「관측 지표」 「제약 사항」 「다음 액션」의 5가지 관점에서 진단해 주세요.
개선안은 Markdown 템플릿과 TypeScript 가드 (Guard) 양쪽 모두에서 제시해 주세요.

주의할 점 (Pitfalls)

먼저, 상태를 너무 많이 늘리지 않는 것입니다. 처음부터 상태를 20개 만들면 파탄 납니다. 처음에는 idea_collecting, validation_ready, building, reviewing, paused, done 정도로 충분합니다.

다음으로, 관측 지표를 너무 거창하게 만들지 않는 것입니다. "인생 만족도 향상" 같은 지표는 중요하지만, 처음에는 측정하기 어렵습니다. 30분 동안 작업했는가, 메모를 한 장 썼는가, 한 명에게 보여주었는가, 저장 수가 3건인가, CI가 통과했는가. 이 정도면 충분합니다.

마지막으로, AI에게 결정권을 너무 많이 넘기지 않는 것입니다. AI는 후보 정리, 누락 확인, 코드화에는 능숙합니다. 하지만 무엇을 소중히 여길지에 대한 최종 결정은 인간 측에 남겨두어야 합니다.

내일부터 시작하는 방법

추천하는 것은, 내일 이것 하나만 하는 것입니다.

• Obsidian 또는 VS Code에서
  decisions/오늘날짜.md를 생성하기

• 작성하기 - Current State(현재 상태)를 한 줄로 쓰기

• Candidate Worldlines(후보 세계선)를 딱 3개만 쓰기

• Transition Guard(전이 가드)를 3개 쓰기

• Anti Guard(안티 가드)를 3개 쓰기

• AI에게 리뷰용 프롬프트 던지기

• 첫 30분간의 액션을 딱 1개만 결정하기

이것으로 충분합니다. 상태 전이(State Transition)의 좋은 점은 실패하더라도 로그가 남는다는 것입니다. "그때 왜 진행했는가", "무엇을 보고 판단했는가", "어떤 제약 조건을 경시했는가", "다음에는 어떤 가드를 강화해야 하는가". 이것이 남으면 실패는 자산이 됩니다.

AI 시대에는 실패하지 않는 사람이 강하다기보다, 실패를 구조화하여 다음 판단으로 변환할 수 있는 사람이 강해지는 느낌이 듭니다.

요약

AI 시대의 의사결정에서 중요한 것은 AI에게 정답을 묻는 것이 아니라고 생각합니다. 중요한 것은 AI가 리뷰할 수 있는 형태까지 자신의 현재 위치와 후보 세계선을 구조화하는 것입니다.

Worldline State Machine은 그것을 위한 작은 프레임워크입니다. 현재 위치를 적는다. 후보 세계선을 적는다. 전이 조건을 적는다. 진행하지 못하는 조건을 적는다. 관측 지표를 적는다. 다음 액션을 적는다. AI에게 리뷰를 시킨다. 실행 후에 상태를 업데이트한다.

이를 반복하면 의사결정이 '기합'이나 '센스'에만 의존하기 어려워집니다. 물론 모든 것을 기계적으로 결정할 필요는 없습니다. 인간의 직관도, 감정도 중요합니다.

하지만 말이죠, 직관을 지키기 위해서라도 구조가 필요합니다. 구조가 있기 때문에 AI에 휘둘리지 않을 수 있습니다. 구조가 있기 때문에 나중에 되돌아볼 수 있습니다. 구조가 있기 때문에 다음의 내가 더 강해질 수 있습니다.

우선은 마크다운(Markdown) 파일 한 장부터 시작해도 괜찮습니다. 오늘의 고민에 상태 이름을 붙이고, 3가지 세계선을 써보는 것. 거기서부터 시작해 봅시다.