[🤖] 코디네이터를 두더라도 내가 모든 세션을 직접 지시해야 한다

✨ GPT-5.6 Sol의 요약 　

브로셔 작업을 여러 세션으로 나누려다 코디네이터가 보고만 받다가 맥락을 잃을까 의심했다. 내가 모든 세션을 직접 지시하면서도 조율 상태를 잃지 않도록 Skill을 다시 고치게 한 기록.

내가 코디네이터를 믿지 못한 이유

오늘 회사에서 브로셔 제작 업무를 맡았다. 나는 브로셔를 만들어본 적이 없어서, 관련 자료를 읽고 해야 할 일을 나누고 여러 Codex 세션을 조율하는 코디네이터가 있으면 좋겠다고 생각했다. 현재 프로젝트의 모든 채팅을 읽고 각 세션이 무엇을 진행하면 좋을지 지시하는 역할을 맡기고 싶었다.

그런데 명령을 내리자마자 걱정부터 들었다.

예전처럼 보고만 계속 받다가 맥락 날아가고 헛소리만 하는 거 아닐까.

이 걱정은 그냥 막연한 불신이 아니었다. 나는 이미 코디네이터와 워커를 나눴다가 보고가 코디네이터의 대화를 덮어버리는 문제를 겪었고, 그래서 파일 보고서와 체크포인트를 중심으로 custom-coordinate-parallel-workers Skill을 다시 만든 적이 있었다. 당시에도 로컬 상태 도구는 검사했지만 실제 여러 Codex 세션에서 끝까지 운영하지는 못했다.

이번에는 브로셔라는 실제 업무가 생겼다. 그런데 막상 코디네이터 역할을 다시 맡기려니, 파일 보고서만 잘 쌓는다고 문제가 해결되는 것은 아니라는 생각이 들었다. 코디네이터가 보고를 읽고 작업을 나눠주는 동안 나는 가만히 구경하는 녀석이 아니다. 나는 여러 세션을 계속 열어보고, 잘못된 방향이면 그 자리에서 고치라고 말하고, 필요한 자료를 더 주고, 우선순위도 바꿀 것이다.

코디네이터가 정상적으로 역할을 하려면 내가 다른 세션에 직접 개입해도 조율 상태가 무너지지 않아야 했다.

나는 다른 세션에도 계속 명령할 것이다

처음 업데이트된 스킬은 내가 코디네이터에게 명령하고, 다른 세션이 코디네이터의 명령대로 실행하는 모습을 관찰하는 구조에 가까웠다. 나는 바로 다시 말했다.

그 세션에 내가 이런저런 명령 내려도 되게 해야지.

내가 원한 것은 코디네이터가 모든 명령권을 독점하는 구조가 아니었다. 코디네이터는 전체 목표, 작업 소유권, 의존성, 통합 순서를 관리하면 된다. 하지만 각 작업 세션에서 구체적인 결과를 보고 판단하는 사람은 여전히 나다. 내가 현재 작업 범위 안에서 문구를 고치거나 결과를 바꾸라고 하면 워커는 바로 반영해야 한다. 반대로 그 지시가 다른 세션의 파일, 공통 계약, 배포나 외부 상태까지 건드린다면 멋대로 범위를 넓히지 말고, 내가 원한 결과를 보존한 채 코디네이터가 다시 조율할 수 있도록 멈춰야 한다.

그래서 custom-coordinate-parallel-workers를 그 기준으로 다시 고치라고 명령했다. 작업이 끝난 뒤 내가 추가 지시를 내려도 256자짜리 요약 하나로 뭉개지지 않게 했다. 내가 원하는 결과, 반드시 보존할 내용, 영향을 받을 파일, 외부 효과 여부, 원래 지시가 나온 세션을 별도로 남기게 했다. 코디네이터가 대화 기억을 잃어도 파일에서 내 지시를 복구할 수 있어야 했다.

또 내가 수정하라고 한 요청을 코디네이터가 ‘수락’이라고만 적고 닫아버리지 못하게 했다. 실제로 수정한 새 보고서나 새 작업 할당에 연결되기 전에는 요청을 끝난 것으로 처리할 수 없다. 연결만 있다고 내용까지 맞는 것은 아니므로, 코디네이터가 내가 요구한 결과와 보존 조건을 실제 diff와 다시 비교하는 절차도 남겼다.

중요한 것은 상태 파일이 많아졌다는 사실이 아니다. 내가 어느 세션에 직접 말하더라도 그 지시가 사라지거나, 반대로 전체 소유권을 조용히 깨뜨리지 않게 하는 것이었다.

코디네이터와 감사 세션은 합치지 않았다

수정 도중에는 custom-coordinate-parallel-workers가 전날 만든 Graph Engineering Gate Skill과 사실상 같은 역할이 아닌가 하는 생각도 들었다. 당시 이름은 custom-graph-engineering-gate였다. 둘 다 여러 세션과 검토 상태를 다루니 하나로 합치면 그럴듯해 보였다.

이번에는 바로 합치지 않고 custom-deliberate로 비판적으로 다시 검토시켰다. 결론은 분리였다.

custom-coordinate-parallel-workers는 여러 작업 세션의 파일 소유권, 사용자 지시, 보고서, Git index, 통합 순서와 외부 효과를 관리하는 실행 제어 역할이다. 반면 감사 Skill은 이미 하나로 통합하고 멈춰둔 결과를 이전 맥락 없이 별도 세션에서 검사하는 역할이다. 코디네이터가 보고서를 검토하는 것은 작업을 합쳐도 되는지 판단하는 통합 검토이지, 별도 감사자의 판정이 아니다.

둘을 합치면 모든 병렬 작업에 감사 세션이 자동으로 붙거나, 반대로 코디네이터의 일반적인 통합 검토를 독립 감사라고 착각할 수 있었다. 그래서 두 Skill은 따로 두고 경계만 서로 명시했다. 독립 감사가 정말 필요한 결과에서만 코디네이터가 그 결과를 동결한 뒤 별도 감사 세션을 여는 구조다.

구조를 크게 만드는 것이 안전하다는 착각은 하지 않기로 했다. 필요한 역할은 연결하되, 같은 역할인 척 합치지는 않는다.

실제로 건넨 코디네이터 전환 지시

원칙을 말로만 정한 것은 아니었다. 나는 코디네이터 세션에 현재 파일과 기존 세션을 먼저 재구성하고, 충돌을 분류한 뒤에만 assignment를 발행하라는 전환 지시를 길게 작성해 건넸다. 기존 변경을 함부로 지우지 말 것, 사용자가 각 세션에 직접 내린 지시를 보존할 것, 워커는 자기 경로만 수정할 것, 코디네이터만 통합과 Git 작업을 맡을 것까지 한 번에 적었다.

원문에는 실제 업무와 자료를 식별할 수 있는 내용이 들어 있어 그대로 공개하지 않았다. 회사명, 업무 분야, 고객·사례 자료명, 구체적인 서비스 내용과 개인 로컬 경로를 일반 표현으로 바꾼 공개용 사본만 첨부한다.

공개용으로 마스킹한 코디네이터 전환 지시문 보기

충분하다는 말은 실제 작업 뒤에 하기로 했다

상태 전이, 파일 소유권, 의존성, 동결, 사용자 추가 지시, 오래된 상태 파일 복구는 자동 검사로 확인했다. 비판적 재검토 중에는 수락한 사용자 요청을 새 결과와 연결하지 않고 닫을 수 있는 구멍도 찾아서 막았다.

그래도 나는 다시 물었다.

충분히 보완되었는가?

답은 통제된 파일럿을 시작하기에는 충분하지만, 실제 여러 Codex 세션에서 입증된 것은 아니라는 것이었다. 이번 대화가 사이드 세션이라 실제 워커들을 열고 알림 전달과 사용자 개입, 코디네이터 복구까지 한 번에 시험할 수 없었다. 로컬 상태 기계가 통과한 것과 코디네이터가 긴 작업 중 내 지시를 제대로 해석하고 통합하는 것은 같은 증거가 아니다.

그래서 여기서 더 많은 규칙을 상상해 붙이지 않기로 했다. 코디네이터 세션에서 브로셔 작업을 실제로 나누고, 나는 각 세션을 직접 보면서 중간 지시도 내려볼 것이다. 코디네이터가 내 지시를 잃지 않는지, 다른 세션의 소유권을 침범하지 않는지, 보고가 쌓여도 원래 목표와 다음 행동을 복구하는지를 끝까지 본다. 그 결과가 오늘 나오면 오늘 이어 쓰고, 내일 나오면 내일 이어 쓰면 된다.

글을 일단 마무리한 뒤에는 감사 Skill의 이름도 다시 보게 됐다. 당시 이름인 custom-graph-engineering-gate는 출발한 개념은 설명했지만, 실제로 무엇을 하는 Skill인지는 전혀 보여주지 못했다.

내가 실제로 하는 행동은 작업 결과를 멈추고 별도의 감사 세션을 여는 것이었다. 그래서 현재 이름을 custom-open-audit-session으로 바꿨다. 과거 이름은 당시 기록에 남기되, 지금 호출할 이름은 이것 하나로 정리했다.

하지만 이 글의 결론까지 미룰 필요는 없다. 오늘 나는 코디네이터를 믿기로 한 것이 아니다. 내가 직접 모든 세션에 개입해도 무너지지 않아야 한다는 조건을 분명히 했고, 충분하다는 말 대신 실제 업무에서 확인할 E2E를 남겼다.

이제 이 구조를 믿을지 말지는 설명이나 테스트 개수가 아니라, 내가 지켜보는 실제 브로셔 작업이 결정한다.