AI 코딩 에이전트로 몇 시간짜리 장기 작업을 맡겨본 사람이라면 익숙한 실망이 있다. 한 시간 정도는 놀랍도록 잘 굴러가다가, 그 뒤로는 서서히 무너진다. 흔한 진단은 "모델이 아직 부족하다"거나 "컨텍스트 창이 좁다"는 것이지만, asyncdot.com에 소개된 'Chief of Staff(참모장) 패턴'은 다른 곳을 가리킨다. 문제의 본질은 에이전트가 코드를 못 짜는 데 있지 않다. 에이전트의 컨텍스트가 휘발성이고, 자기 작업에 대한 보고가 믿을 수 없다는 데 있다.
여기서 핵심 통찰은 해법이 기술적이기보다 조직적이라는 점이다. 에이전트를 더 많이 붙인다고 해결되지 않는다. 오히려 신뢰할 수 없는 보고자만 여럿으로 늘어나고, 그들의 말을 대조해 무엇이 진짜인지 판정하는 존재는 여전히 없다. 인간 조직이 오래전에 배운 분업, 즉 '일을 하는 사람'과 '무엇이 사실인지 아는 사람'을 나누는 규율을 에이전트 세션에 그대로 옮기자는 것이 이 패턴의 골자다.
코디네이터와 실행자, 그리고 외부의 보드
구조 자체는 새롭지 않다. 오케스트레이터-워커, 혹은 코디네이터-임플리멘터-베리파이어라는 이름으로 이미 알려져 있고, 저자도 'Chief of Staff'는 자신들이 붙인 은유일 뿐 공인된 용어가 아니라고 못 박는다. Git의 인티그레이션 매니저 워크플로를 떠올리면 쉽다. 기여자들은 각자의 저장소에서 작업하고, 한 명의 관리자가 각 변경을 로컬에서 직접 테스트한 뒤 무엇을 본 저장소에 반영할지 결정한다. 여기서 관리자의 역할을 사람 대신 에이전트 세션에 대해 수행하는 것이 코디네이터다.
필요한 것은 세 가지다. 첫째, 각자 독립된 컨텍스트 창을 가진 세션들. 한 세션의 혼란이 다른 세션을 오염시키지 않는다는 점에서 격리는 결함이 아니라 기능이다. 둘째, 이 세션들을 명령줄에서 스크립트로 띄우고 조율하는 도구. 셋째, 가장 자주 생략되지만 생략하는 순간 밤을 넘기지 못하게 만드는 요소인 '지속적인 외부 보드'다. 프로젝트·목표·의존성이 연결된 태스크·설계 문서를 담고, 코디네이터와 모든 실행 세션이 함께 읽고 쓴다. 세션은 소모품이고, 보드가 곧 기억이다. 결정적으로 코디네이터는 직접 코드를 짜지 않는다. 코디네이터가 구현을 시작하는 순간 검증을 멈추게 되고, 패턴은 과부하 걸린 단일 세션으로 붕괴한다.
계측기가 거짓말을 하는 방식
이 방법론을 단순히 '에이전트 여러 개 동시 실행'과 구분 짓는 지점은 검증 규율이다. 규칙은 단순하다. 한 번에 하나의 작업 항목, 하나의 디스패치, 하나의 커밋. 그리고 검증 게이트는 작업을 시작하기 '전에' 먼저 돌려본다. 시작하기도 전에 초록불이라면 그 작업은 아무것도 증명하지 못한다. 올바른 구현과, 애초에 아무것도 실행하지 않은 검사, 아무것도 걸리지 않는 필터, 이미 참인 것을 단언하는 테스트를 구분할 수 없기 때문이다. 실제로 대기 중인 태스크의 상당수가 다른 카드에서 이미 처리됐거나 이후 변경으로 무의미해진 것으로 드러난다.
저자가 든 사례가 이 위험을 압축한다. 어떤 세션이 로그 파일에 커밋 해시를 손으로 적어 넣고, git으로 검증했는데 자신이 파일에 쓴 문자열이 아니라 셸에 떠 있던 단축 해시를 대상으로 확인했다. 두 검사 모두 통과했지만, 파일에는 아무것도 가리키지 않는 해시가 남았다. 검사 대상과 기록 대상이 서로 다른 객체였고 그중 하나만 테스트된 것이다. 여기서 나오는 원칙이 '아티팩트는 자기가 썼다고 믿는 변수가 아니라 아티팩트에서 값을 다시 읽어 검증하라'다. 마찬가지로 '없음'을 단언하려면 같은 실행 안에 양성 대조군을 둬야 한다. 아무것도 실행되지 않았다면 "나쁜 일이 없었다"는 검사도 통과하기 때문이다. 부재를 결론짓기 전에, 대상이 있을 때 계측기가 그것을 실제로 찾아내는지부터 확인해야 한다.
메시지는 넛지, 파일은 계약
세션끼리 직접 메시지를 주고받는 채널은 유용하지만 의존해서는 안 된다. 메시지는 바쁜 세션 뒤에 밀리거나, 수신 세션의 권한 모드에 따라 승인 대기에 걸리거나, 전달되지 못한 채 만료될 수 있다. 침묵은 동의가 아니다. 그래서 반드시 도착해야 하는 것은 지속적인 채널, 즉 보드나 파일에 남긴다. 저자의 표현대로 메시지는 슬쩍 미는 신호이고 파일은 계약이다. 나아가 루프·라우팅 규칙·기준처럼 매 주기를 지배하는 지속적 정책은 리뷰된 정책 디렉터리에 두고, 일회성 브리핑이나 세션별 지시는 보드나 스크래치 디렉터리에 둔다. 둘을 섞으면 반년 뒤 어떤 파일이 여전히 규범인지 아무도 분간하지 못한다.
장시간 자율 실행에는 타임박스도 필요하다. 다만 간격은 '얼마나 자주 상황을 드러낼지'를 정할 뿐 '어디서 작업을 멈출지'를 정하지 않는다. 타이머가 항목 중간에 만료되면 그 항목을 끝내고, 검증하고, 커밋한 뒤 보고한다. 작업 도중에 끊으면 절반만 적용되고 검증되지 않아 정직하게 설명조차 어려운, 가장 복구하기 힘든 상태로 남는다. 체크포인트는 허가를 구하는 순간이 아니라 상황을 드러내는 순간이다. "계속할까요?"라고 쓰고 있는 자신을 발견하면 지워야 한다. 지켜보는 사람은 필요하면 알아서 끼어들고, 지켜보지 않는 사람에게는 그 질문이 실행을 죽이는 셈이다.
한국 실무자를 위한 현실적 함의
세부 함정들도 곱씹을 만하다. 런처가 워크스페이스를 만들었다고 보고하는 것과 에이전트가 실제로 돌고 있는 것은 다르다. 프로세스와 작업 디렉터리를 확인해야 하며, 실행 직전에 기준 타임스탬프를 잡아둬야 그 사이 끼어든 무관한 세션을 잘못 인정하지 않는다. 세션 이름은 추측 가능한 주소가 아니라서 주소로 삼기 전에 살아 있는 세션을 다시 나열해야 하고, 보드가 보여주는 잘린 짧은 ID를 임의로 늘려 완전한 식별자를 만들면 형식만 멀쩡하고 존재하지 않는 값이 된다. 공유 작업 트리에서는 맨 커밋 대신 경로를 지정한 커밋을 써서 동시 실행 세션이 스테이징한 것까지 딸려 들어가지 않게 막는다.
이 모든 규율의 대가로 얻는 것은 속도가 아니라 신뢰다. 이 패턴이 작동하는지의 척도는 코드가 얼마나 많이 쏟아졌는가가 아니라, 어느 순간에든 "지금 이 작업의 상태가 어떻습니까?"라고 물었을 때 참인 답을 받을 수 있는가다. 에이전트가 장기 작업에서 부진할 때 더 좋은 모델이나 더 큰 컨텍스트로 손이 가는 것은 자연스럽지만, 둘 다 도움은 되어도 진짜 제약을 건드리지 못한다. 진짜 제약은 아무도 확인하지 않는다는 것이다. 코드를 한 줄도 쓰지 않지만 무엇이 사실인지 아는 조율 세션이, 또 하나의 실행자보다 값지다는 결론은 결국 인간 조직의 오래된 교훈이 에이전트 세계로 옮겨온 것이다.