🤖
1681 in / 1672 out / 3353 total tokens
하네스 파이프라인의 실행 흐름을 상태 머신으로 명시적으로 정의했다. 이제 각 에이전트가 어디서 와서 어디로 가는지, 몇 번 루프를 돌 수 있는지, 막히면 누가 개입하는지가 전부 문서화됐다.
가장 핵심은 개발 파이프라인의 TRIAGE 분기다. 요청이 들어오면 TRIAGE에서 복잡도를 판정해서 SIMPLE/STANDARD/COMPLEX 세 갈래로 나뉜다. SIMPLE은 그냥 바로 구현. STANDARD는 SCOUT→SPEC→CODE→REVIEW. COMPLEX는 여기에 QA 루프까지 붙는다. 게임 개발에서 보스 패턴 짤 때 상태 머신 그리는 거랑 같은 원리인데, 결국 "현재 상태 + 조건 = 다음 상태"를 명시하지 않으면 에이전트가 길을 잃는다.
루프 카운터를 제한한 게 중요한 결정이다. REVIEW와 QA 각각 최대 3회. 그리고 2회 연속 같은 결과가 반복되면 교착 상태로 판정해서 '이더 개입'으로 빠진다. 이건 게임에서 무한 루프 방지하는 타임아웃 로직이랑 동일한 사고방식이다. AI 에이전트끼리 리뷰어는 "이거 수정해"라고 하고 코드는 "수정했는데 같은 문제야"라고 무한 반복하는 걸 방지해야 했다.
계획 파이프라인(CONTEXT→DRAFT→DEBATE_LOOP→SYNTHESIS)도 추가했다. 개발 파이프라인과 트랙 간 연결점은 impl 문서다. 계획 파이프라인에서 합의된 impl 문서가 개발 파이프라인의 입력이 된다. 이걸 명시해두지 않으면 계획과 실행 사이의 인터페이스가 모호해진다.
재트리아지 전이도 넣었다. 조사 단계에서 수정이 필요해지거나, 영향 범위가 당초 예상보다 커서 복잡도가 상향되면 다시 TRIAGE로 돌아간다. 게임 개발에서 프로토타입 해보니 스코프가 너무 커져서 기획 단계로 돌려보내는 상황이랑 같다.
workflow.md 파일 하나에 상태 전이표 101줄을 때려 넣었다. 앞으로 에이전트들이 이 그래프를 읽고 자기 위치를 파악하면 된다.
text TRIAGE ├─ SIMPLE → IMPLEMENT → DONE ├─ STANDARD → SCOUT → SPEC → CODE ←→ REVIEW (max 3) → DONE └─ COMPLEX → SCOUT → SPEC → CODE ←→ REVIEW (max 3) → QA ←→ CODE (max 3) → DONE
다음 할 일은 이 상태 그래프를 실제로 실행하는 런타임 로직이다. 문서로만 정의해둔 상태고, 에이전트들이 이걸 따르도록 강제하는 메커니즘이 아직 없다.
상태 머신은 문서가 아니라 런타임이어야 한다. 지금은 설계도 단계.