[🛠] AI Orchestration #5: 포기했던 코디네이터·워커 분리를 다시 설계했다

✨ GPT-5.6 Sol의 요약 　

전달문 때문에 코디네이터가 맥락을 잃자 분업 자체를 포기했지만, 단일 세션의 병목을 겪고 나서 파일 보고서와 코디네이터 단독 commit 구조로 다시 설계한 기록.

코디네이터와 워커를 나누는 일을 한 번 포기했다

지난달에는 코디네이터와 워커를 실제로 연결해봤다. 하나의 목표를 여러 작업으로 나누고, 워커가 구현한 결과를 코디네이터가 검토해서 합치는 흐름이었다.

분업 자체는 빨랐다. 서로 겹치지 않는 기능을 동시에 구현하고, 코디네이터는 전체 제품의 방향과 통합만 맡을 수 있었다. 문제는 워커가 결과를 전달하는 방식이었다.

워커들은 작업을 마치거나 막힐 때마다 코디네이터 세션에 전달문을 보냈다. 처음에는 자연스러운 방식이라고 생각했다. 하지만 워커 수가 늘자 코디네이터 대화에는 보고가 계속 쌓였고, 메시지가 들어올 때마다 하던 일을 멈추고 다른 작업으로 넘어갔다.

한 워커의 테스트 결과를 읽다가 다른 워커의 Git index 충돌을 확인하고, 다시 원래 구현으로 돌아오려는 순간 또 다른 완료 보고가 도착했다. 대화는 빠르게 길어졌고, 압축이 반복될수록 목표와 배포 금지 조건, 현재 stage 상태를 다시 복원하는 시간이 늘어났다. 어느 순간에는 코디네이터가 통합자보다 워커 전달문을 처리하는 창구에 가까워졌다.

결국 나는 코디네이터와 워커 세션을 나누는 방식 자체를 포기했다. 만들어뒀던 coordination Skill도 충동적으로 삭제했다. 여러 세션을 관리하지 않고 하나의 메인 세션에서 전부 처리하면 적어도 맥락이 여기저기 끌려다니지는 않을 거라고 생각했다.

단일 세션으로 돌아가니 분업이 왜 필요했는지 보였다

그런데 하나의 세션에서 큰 제품 작업을 계속하자 반대쪽 병목이 바로 드러났다.

구현, 테스트, 문서 정합화, 실기기 확인, Runtime 준비를 모두 한 세션이 순서대로 처리해야 했다. 중간에 우선순위 질문이나 다른 세션의 인계가 들어오면 진행 중인 작업의 상태부터 다시 확인해야 했다. 하나를 확실히 끝내려다 보니 전체 진행은 길어졌고, 급한 일을 먼저 보려 하면 기존 작업을 어디까지 마무리해야 하는지부터 다시 판단해야 했다.

문제는 분업이 아니었다. 오히려 서로 독립적인 작업까지 한 세션이 붙들고 있는 쪽이 비효율적이었다. 코디네이터와 워커를 나누는 것이 여전히 가장 효율적이었다. 다만 워커가 코디네이터의 현재 대화에 직접 들어오는 구조를 그대로 되살리면 같은 실패를 반복할 뿐이었다.

그래서 이번에는 분업을 포기하는 대신, 코디네이터의 맥락을 끊는 전달 경로를 없애기로 했다.

한 줄 알림도 결국 같은 문을 열었다

먼저 워커가 긴 전달문 대신 이런 메시지만 보내면 되지 않을까 생각했다.

READY task-042: 보고서 경로

하지만 다시 생각해보니 길이가 문제가 아니었다. 메시지가 코디네이터 대화에 들어오는 순간, Codex는 그것을 현재 작업보다 새롭게 들어온 맥락으로 받아들이기 쉬웠다. 한 줄이어도 작업을 바꾸는 입구는 그대로였다.

그래서 워커가 코디네이터에게 메시지를 보내지 않게 하기로 했다. 완료, 차단, 실패 상태는 모두 보고서 파일로만 남긴다. 코디네이터는 자기 작업을 안전한 checkpoint나 commit까지 끝낸 뒤에만 inbox를 확인한다.

보고서가 도착했다는 사실은 현재 작업을 끊을 사건이 아니다. 다음 검토 대기열에 파일 하나가 추가됐을 뿐이다.

Worktree는 깨끗했지만 최신 상태에서 멀어졌다

그다음에는 워커마다 Worktree와 Branch를 따로 주는 방법을 검토했다. Git index와 미커밋 변경이 서로 섞이지 않으니 겉으로는 가장 깨끗했다.

그런데 실제 프로젝트에서는 다른 문제가 컸다. 여러 기능이 같은 API, schema, 화면을 계속 건드렸다. 먼저 끝난 세션의 개선이 다른 Worktree에는 바로 보이지 않았다. 각자 깔끔하게 작업했는데 막상 합치려고 보니 오래된 구조를 기준으로 만든 수정이 쌓여 있었다. 그때부터 수정할 요소만 더럽게 많아졌다.

그래서 이번에는 반대로 정했다.

하나의 main Working Tree
├─ 여러 워커가 최신 변경을 함께 봄
├─ 워커는 배정된 파일과 hunk만 수정
├─ 워커는 stage와 commit을 하지 않음
└─ 코디네이터만 검토·stage·commit

물론 공유 Working Tree도 아무 제한 없이 쓰면 바로 엉킨다. 그래서 한 파일에는 기본적으로 한 명의 writer만 두고, 같은 파일을 병렬로 만질 때는 hunk가 확실히 떨어진 경우만 허용한다. 공통 schema, import 정리, formatter처럼 주변까지 움직이는 작업은 직렬화한다.

워커가 실행한 테스트도 그대로 최종 증거로 믿지 않는다. 그 테스트는 다른 워커의 미커밋 변경이 함께 있는 상태에서 돌았을 수 있다. 워커는 자기 범위의 검사를 하고, 전체 회귀와 build는 코디네이터가 변경 집합을 얼린 뒤 한 번 수행한다.

보고서는 대화를 대신하는 검토 계약이 됐다

삭제했던 coordination Skill도 이 원칙으로 다시 만들었다. 새 custom-coordinate-parallel-workers Skill에는 이 흐름을 넣었다.

코디네이터가 task id, 사용자 결과, 쓰기 가능한 경로를 배정한다. 워커는 구현과 범위 검증, 임시 프로세스 정리까지 마친 뒤 보고서를 원자적으로 생성하고 멈춘다. 보고서에는 실제 변경 파일, 검사 결과, 다른 작업과의 겹침, 미완료 범위와 제안 commit을 적는다.

코디네이터는 전체 대화를 다시 읽지 않는다. inbox에서 task id, 상태, 제목, 검사 요약만 먼저 보고 다음에 합칠 작업 하나를 고른다. 그 보고서와 실제 diff가 맞는지 확인한 뒤 정확한 hunk만 stage하고 commit한다.

전체 배포 후보가 정해지면 워커 mutation을 막는 freeze도 둔다. 변경이 계속 들어오는 동안 전체 테스트를 반복하지 않고, release에 들어갈 작업이 멈춘 뒤 current-state 문서, 전체 회귀, build, 배포 검증을 이어간다.

보고서가 단순한 작업 일지가 아니라, 코디네이터가 그 변경을 믿고 다음 상태로 넘길 수 있는 검토 계약이 된 셈이다.

이제 실제 작업에서 굴려봐야 한다

Skill의 상태 관리 도구는 격리된 임시 환경에서 돌려봤다. 정상 완료뿐 아니라 쓰기 경로 충돌, 변경 요청 뒤 재작업, 실행 중 freeze 거부, 다음 배치로 보류하는 흐름까지는 통과했다.

하지만 아직 실제 여러 Codex session을 이 방식으로 운영한 것은 아니다. 파일로만 보고하게 했을 때 정말 코디네이터의 컨텍스트가 덜 흔들리는지, 공유 Working Tree의 경로 소유권이 생각만큼 잘 지켜지는지는 다음 병렬 작업에서 직접 봐야 한다.

이번에 되돌아온 결론은 처음과 비슷하지만 이유는 더 분명해졌다. 코디네이터와 워커의 분리는 필요하다. 실패했던 것은 분업이 아니라, 모든 워커 보고를 코디네이터의 현재 대화에 실시간으로 밀어 넣은 방식이었다.

지금 기대하는 변화는 워커를 더 많이 띄우는 것이 아니다. 코디네이터가 자기 일을 끝낼 때까지 자기 맥락을 지키는 것이다. 병렬 작업의 속도는 워커 수보다, 그 결과를 합치는 사람이 얼마나 덜 끌려다니느냐에 달려 있었다.