🤖
1681 in / 1590 out / 3271 total tokens
AI 코딩 봇의 작업 흐름을 게임 FSM처럼 정의했다. 상태 전이표, 분기, 루프 카운터, 교착 해제까지 전부 명시한 workflow.md를 새로 만들었다.
기존엔 harness.md에 파이프라인 개념만 있고, 실제로 어떤 조건에서 어디로 분기하는지, 몇 번 루프를 돌 수 있는지가 애매했다. Claude가 알아서 판단하겠지라고 넘겼는데, 막상 돌려보니 REVIEW에서 CODE 사이를 무한히 왕복하더라. UE5에서 Behavior Tree에 max loop count 안 걸면 NPC가 제자리에서 평생 뛰는 거랑 같은 문제다.
그래서 명시적으로 묶었다. TRIAGE에서 SIMPLE/STANDARD/COMPLEX 세 갈래로 분기하고, STANDARD는 REVIEW 루프 최대 3회, COMPLEX는 REVIEW 3회 + QA 3회로 제한했다. 2회 연속 교착 상태가 되면 내가 개입하도록 설계했다. 게임 서버에서 데드락 감지해서 GM에게 알림 보내는 로직과 동일한 사고방식이다.
계획 파이프라인도 따로 정의했다. CONTEXT → DRAFT → DEBATE_LOOP → SYNTHESIS 흐름인데, DEBATE_LOOP가 핵심이다. 에이전트 간 토론을 반복하면서 계획을 다듬는 구조다. 이 결과물이 impl 문서 형태로 나오면, 그게 계획 파이프라인에서 개발 파이프라인으로 넘어가는 인터페이스가 된다.
재트리아지 전이도 넣었다. SCOUT 단계에서 조사하다가 영향 범위가 예상보다 크면 다시 TRIAGE로 돌려보내서 COMPLEX로 재분류한다. 게임 개발할 때 프로토타입하다가 "이거 규모가 장난 아니네" 싶으면 제작 파이프라인을 엔진 팀으로 넘기는 것과 같다.
TRIAGE → SIMPLE → IMPLEMENT → DONE → STANDARD → SCOUT → SPEC → CODE ←→ REVIEW (max 3) → DONE → COMPLEX → SCOUT → SPEC → CODE ←→ REVIEW (max 3) → QA ←→ CODE (max 3) → DONE
핵심은 루프 카운터와 교착 임계값이다. AI 에이전트는 "조금만 더 수정하면 될 것 같아"라며 무한히 자가 수정을 반복하는 경향이 있다. 유한 상태 머신의 fundamental 원칙, 즉 모든 상태는 반드시 종료 조건을 가져야 한다는 걸 그대로 적용한 것이다.
harness.md에는 workflow.md 참조 링크 한 줄만 추가했다. 기존 구조를 건드리지 않고 새 규칙을 끼워 넣는 방식.
다음 할 일: 각 상태 전이에서 실제로 어떤 에이전트가 어떤 도구를 호출하는지 agent-mapping과 연동하는 부분 검증.
상태머신의 종료 조건을 명시하지 않으면, AI는 영원히 "거의 다 됐어"를 반복한다.