서론

AI 에이전트와의 「하나의 긴 채팅」이 컨텍스트 과부하와 세션 단절로 인해 점점 돌아가지 않게 된 분들에게.

AI 코딩 에이전트를 일상적으로 사용하다 보면, 조만간 「하나의 긴 채팅」의 한계에 부딪히게 된다. 컨텍스트는 넘쳐나고, 세션을 넘어가면 문맥이 사라지며, 여러 리포지토리(Repository)를 동시에 다루면 이야기가 뒤섞인다. 담당을 전환하는 순간 「방금 전까지의 흐름」이 상실되어, 다시 처음부터 설명해야 하는 상황이 발생한다.

이 글은 그 문제에 대해 내가 정착한 협업의 「형태(型)」를 소개한다. 요점은 단 세 가지다.

AI를 지휘자(conductor)와 담당자(executor)로 나눈다 - 양자 사이를
지시서(work order)와 보고서(handoff)라는 문서로 전달한다 - 위임에는 반드시
**stop-gate(멈춤 조건)**를 먼저 기입한다

그리고 마지막에 결정적인 역할을 하는 것이, 채팅 이력이 아니라 파일화된 기록을 「정본(正本)」으로 삼는다는 점이다. 이것이 가능해지면 세션이 끊겨도, 담당 에이전트가 교체되어도 작업이 멈추지 않고 돌아가기 시작한다.

나는 1인 + 다수의 AI 세션으로 OSS 프로덕트군(NeNe 시리즈)을 개발하고 있으며, 아래 내용은 그 실운용에서 추출한 형태이다. 구체적인 사업 내용이나 프로덕트 고유의 이야기가 아니라, 협업의 구조 그 자체가 주인공이다.

이 글에서 알 수 있는 것:

• AI를 지휘자와 담당자로 나누고, 지시서와 보고서만으로 전달하는 협업 구조
• 위임 시 「멈춤 조건(stop-gate)」을 먼저 기입하여 에이전트의 폭주를 방지하는 방법
• 정본을 채팅 외부(파일)에 두고, 세션을 일회용으로 사용할 수 있는 상태를 만드는 방법

왜 「하나의 긴 채팅」으로는 돌아가지 않는가

먼저, 단순하게 「1개 세션에서 전부 하기」가 스케일링되지 않는 이유를 언어화해 두겠다.

• 컨텍스트 윈도우(Context Window)는 유한하다. 장시간의 작업 로그는 반드시 넘치게 되며, 넘치는 순간 전제 조건이 누락된다.
• 세션의 경계에서 문맥이 사라진다. 윈도우를 닫거나, 다른 머신에서 재개하거나, 다음 날 이어서 하는 경우 모두 「방금 전의 대화」를 가져올 수 없다.
• 멀티 리포지토리(Multi-repository)라면 이야기가 섞인다. 프로덕트 A의 사정과 프로덕트 B의 사정이 동일한 스크롤백(Scrollback)에 공존하면, 에이전트는 아무렇지 않게 혼동한다.
• 담당을 교체하고 싶을 때가 있다. 어떤 태스크를 다른 세션(혹은 다른 도구의 에이전트)에 넘기고 싶을 때, 채팅 이력은 이전할 수 없다.

이것들은 모두 「상태가 채팅 안에 갇혀 있다」는 점에서 기인한다. 그렇다면 상태를 채팅 외부——파일——로 내보내면 된다는 것이 이 형태의 출발점이다.

지휘자와 담당자를 나누기

첫 번째 분할은 AI 세션의 역할을 2개 층으로 나누는 것이다.

• 지휘자(conductor): 횡단적인 관점을 가진 세션. 할 일을 분해하고, 지시서를 작성하며, 돌아온 보고서를 리뷰하고, 횡단 TODO 보드를 업데이트한다. 개별 코드는 기본적으로 직접 쓰지 않으며, 「무엇을・어떤 순서로・어디서 멈출 것인가」를 설계하는 것이 업무다.
• 담당자(executor): 1개 리포지토리 / 1개 태스크에 집중하는 세션. 지시서를 받아 해당 리포지토리의 규약에 따라 구현·테스트·리뷰까지 수행하고, 결과를 보고서에 써서 돌려준다.

그리고 인간(프로젝트 오너)은 지휘자가 올리는 판단 포인트(Decision Point)만을 판결한다. 모든 것에 손을 대는 것이 아니라, 「결정해야 할 것」에 인간의 시간을 집중시킨다.

포인트는 지휘자와 담당자가 같은 채팅에 있지 않다는 것이다. 별개의 세션으로 실행하며, 양자는 문서로만 주고받는다. 이렇게 하면 담당자의 컨텍스트는 「하나의 업무」로 압축되어 클린하게 유지되며, 지휘자는 횡단적인 상황을 조망하는 데 전념할 수 있다.

지시서(work order)의 형태

지시서는 지휘자가 담당자에게 전달하는 「발주서」다. 내가 실제로 사용하고 있는 포맷은 대략 다음과 같은 요소로 구성되어 있다.

• 수신처와 제목: 누구로부터 누구에게, 어떤 태스크인가 (지휘 → ○○ 담당

）。

• 배경 / 오너 결정 (Owner Decision): 왜 지금 이것을 하는가. 인간이 내린 결정을 1~2줄로 명기한다.
• 할 일 (우선순위): 번호가 매겨진 작업 목록. 우선순위와 순서를 지휘자가 미리 정해둔다.
• 1차 자료: 판단의 근거가 되는 자료로의 링크. "사실 관계는 여기서 확인하라"를 명시한다.
• stop-gate (중단 조건): 이는 나중에 절을 나누어 자세히 설명한다.
• 주의 사항 (하지 말아야 할 것): 금지 사항. "운영 환경(Production) 배포는 하지 않는다", "이 범위는 건드리지 않는다" 등.
• 보고처: 어느 파일에 보고서를 작성할 것인가.

무해한 가공의 태스크로 예를 들면 다음과 같다 (실물이 아니라 형식을 보여주기 위한 더미 데이터).

# 지시서 2026-01-15 — sample-app: 청구서 PDF 출력 구현 (지휘 → sample-app 담당)
오너 결정: 명세 화면에서 청구서를 PDF로 저장할 수 있도록 한다.
기존의 양식 템플릿 메커니즘 위에 얹는다. main 동기화부터 시작.
...

지시서가 "발주서"로서 기능하기 위한 조건은, 담당자가 지휘자에게 되묻지 않고도 착수할 수 있어야 한다는 것이다. 배경, 순서, 근거, 금지 사항, 중단 조건이 모두 적혀 있다면 담당자는 망설임 없이 달려 나갈 수 있다.

보고서 (handoff)의 형식

보고서는 담당자가 작업 결과를 지휘자에게 전달하는 문서다. 지시서와 쌍을 이루며 다음과 같은 구조를 가진다.

• 어떤 지시서에 대한 보고인가 (링크를 연결).
• 구현 단위별 결과: 무엇을 변경했는가 / 어떻게 검수했는가 (테스트·CI의 Green 상태) / 머지(Merge) 상태.
• stop-gate에 걸렸을 때의 경과: 중단된 이유와, 대신 남긴 설계 메모.
• 총괄 테이블: 각 항목의 Issue / PR / 상태를 일람화.
• 준수 사항 확인: "운영 환경 배포는 하지 않았다" 등, 지시서의 금지 사항을 준수했다는 내용.

가공의 태스크 보고서는 다음과 같다.

# 보고서 — sample-app: 청구서 PDF 출력 (2026-01-15)
지시서: (해당하는 지시서로의 링크)
## PDF 렌더러 추가 (✅ merged)
...

보고서의 장점은 지휘자가 이것을 읽는 것만으로 상황을 재구성할 수 있다는 점이다. 담당자의 채팅 내역을 거슬러 올라갈 필요가 없다. 결과와 검수의 증적이 파일에 남아 있기 때문에, 리뷰도, 다음 지시도, 이 한 장에서 시작할 수 있다.

stop-gate가 포함된 위임 — "중단 조건"을 먼저 작성하기

이 형식에서 가장 효과적인 것이 바로 stop-gate다. 이름 그대로 "위임의 중단 조건"으로, 지시서를 작성하는 시점에 "여기에 해당하면 구현하지 말고 멈춰라"라고 선언해 두는 메커니즘이다.

AI 에이전트는 내버려 두면 "부탁받은 일을 끝까지 완수하려고" 한다. 그 자체는 미덕이지만, 다음과 같은 상황에서는 완수해 버리면 곤란하다.

• 언뜻 작은 수정인 줄 알았으나, 기존 설계와 맞지 않아 대규모 개편(Refactoring)이 되어버릴 때.
• 보안 설계(인증·인가 모델)를 조용히 바꿔버리게 될 때.
• 영향 범위가 사전 예상보다 넓게 퍼졌을 때.

이런 케이스에서 기세에 눌려 그대로 달리게 두면, 리뷰하기 힘든 거대한 차분(Diff)이나 설계 사상을 역전시키는 변경 사항이 올라온다. stop-gate는 **"Phase 0에서 먼저 실제 코드를 확인하고, 선언된 모순이 발견되면 구현하지 말고 설계 메모를 남긴 채 정지하여 판단을 지휘자에게 돌려준다"**라는 절차를 미리 심어둠으로써 이를 방지한다.

실제 운용에서는 바로 이 stop-gate가 발동한 사례가 있다 (내용은 일반화하여 기술한다). 어떤 감사 소견의 시정 사항 중에 "다른 프로덕트에서 채택한 방식을 이곳에도 도입한다"라는 항목이 있었다. 지시서에는 "기존 인가 모델과 모순되거나 대규모 개편이 필요하다면, 구현하지 말고 설계 소견을 Issue에 작성하고 멈춰라"라는 stop-gate를 달아 두었다.

담당자는 지시대로 우선 기존 미들웨어 구성과 인가(Authorization) 실제 코드를 Phase 0에서 확인했다. 그 결과:

• 제안된 방식은 인증 처리 순서를 전제로 하고 있었으나, 이 구성에서는 순서를 바꾸면 인가 게이트를 그냥 통과해 버리는 우회(Bypass)가 발생한다.
• 이쪽은 "URL을 정답으로 보고 대조하여, 불일치 시 fail-close로 차단한다"라는 신뢰 모델이지만, 제안된 방식은 반대로 "클라이언트의 신고를 정답으로 간주한다"—— 즉, 신뢰의 방향이 역전된다.
• 도입을 위해서는 기존의 데모 메커니즘까지 포함한 대규모 개편이 필요하며, 현행 방식은 가동 중이고 긴급성이 없다.

——라는 3가지 모순을 확인하고, 담당역은 코드 한 줄도 바꾸지 않고 정지했다. 대신 왜 정지했는지와 향후 설계 방침을 Issue에 남겨두고, 계속 진행할지 여부에 대한 판단을 지휘역에게 되돌려주었다.

만약 stop-gate가 없었다면, 에이전트(Agent)는 "부탁받았으니까"라며 인가 모델(Authorization model)을 새로 써버렸을지도 모른다. "멈추는 조건을 미리 언어화해 두는 것"만으로도, 위임의 안전성은 크게 달라진다. 이는 인간 사이의 위임에서도 마찬가지지만, 지시에 충실하게 움직이는 AI가 상대라면 그 효과가 더욱 두드러진다.

기록을 정본으로 삼는다 (채팅 이력을 정본으로 삼지 않는다)

지금까지의 형식을 관통하는 사상은 **"정본(source of truth)을 채팅 외부에 두는 것"**이다.

지시서도 보고서도, 공유 작업 디렉토리에 둔 단순한 파일이다. 이에 더해, 여러 리포지토리(Repository)에 걸친 "지금 해야 할 일"은 인간과 AI가 공유하는 한 장의 TODO 보드(Plain text)로 관리한다. 상태는 모두 파일로 내려가 있으며, 채팅의 스크롤백(Scrollback)에 의존하지 않는다. 이것이 가져다주는 효용은 매우 크다.

세션이 끊겨도 재개할 수 있다. 새로운 세션은 보드와 직전의 지시서·보고서를 읽는 것만으로 상황을 복구할 수 있다. "아까 했던 이야기"를 기억할 필요가 없다. -
담당을 교체할 수 있다. 어떤 태스크를 다른 세션이나 다른 도구의 에이전트에게 넘기는 것이, 파일을 가리키는 것만으로 끝난다. -
인간이 비동기적으로 리뷰할 수 있다. 대화에 매달려 있지 않아도, 나중에 보고서를 읽으면 판단할 수 있다. -
감사 가능하다. 누가 무엇을 지시했고, 무엇을 했으며, 어디서 멈췄는지가 날짜가 포함된 문서로서 남는다.

규모감을 하나 예로 들어보겠다. 실제 운용 중인 바쁜 하루를 계산해 보니, 횡단적인 지휘 세션이 내보낸 문서가 10건(지시서와 인간에게 보내는 에스컬레이션), 돌아온 보고서가 11건, 합쳐서 20건 이상의 문서가 공유 작업 디렉토리를 통해 돌고 있었다.

이 정도의 분량이 하루 만에 돌아가도 혼란스럽지 않은 이유는, 한 건 한 건이 파일로서 독립되어 있고 상태가 채팅에 갇혀 있지 않기 때문이다. 어느 한 세션의 컨텍스트(Context)가 넘치더라도, 기록만 남아 있다면 다른 세션이 그 뒤를 이어서 처리할 수 있다.

바꿔 말하면——채팅 이력을 정본으로 삼으면, 그 이력을 가지고 있는 세션이 죽는 순간 작업도 죽는다. 기록을 정본으로 삼으면 세션은 일회용 실행기가 되며, 얼마든지 다시 세울 수 있다.

배움

마지막으로, 형식으로서 가져갈 수 있는 포인트를 정리한다.

AI를 "지휘"와 "담당"으로 나눈다. 한 세션에 모든 것을 시키지 않는다. 지휘역은 설계와 조망을, 담당역은 한 태스크에 집중한다. -
전달은 문서로 한다. 지시서(발주서)와 보고서(납품서)를 한 쌍으로 만든다. 담당역이 되묻지 않고 착수할 수 있고, 지휘역이 보고서만으로 상황을 재구성할 수 있는 상태를 목표로 한다. -
위임에는 반드시 stop-gate를 붙인다. "여기에 해당하면 구현하지 말고 멈춰서 설계 메모를 남겨라"를 사전에 작성한다. 충실하게 움직이는 AI일수록 멈추는 조건의 명시가 효과적이다. -
정본은 채팅 외부에 둔다. 파일화된 지시서·보고서·공유 TODO 보드를 source of truth로 삼는다. 세션과 담당은 일회용으로 만들 수 있으며, 기록이 남아 있는 한 작업은 멈추지 않는다. -
인간의 시간은 "판단"에 집중한다. 손을 직접 움직이는 것이 아니라, 지휘역이 올리는 GO/NO-GO 판단에 집중한다.

이 형식은 특별한 도구를 요구하지 않는다. 필요한 것은 "문서의 포맷을 정하는 것"과 "정본을 파일에 두기로 결심하는 것"뿐이다. AI 에이전트를 하나의 장난감으로서가 아니라, 교체 가능한 실행기 무리로 다루기 시작하면 협업의 풍경은 바뀐다.

1차 자료 (Sanitize)

본 기사는 필자의 워크스페이스에서 실제 운용 중인 지시서 / 보고서 문서군과 워크스페이스 운영 규약 문서에서 형식(구조)만을 추출하여 작성했다. 지시서·보고서의 실제 사례, 제품 고유의 내용, 고객·영업·사업과 관련된 정보는 본문에 일절 포함하지 않았으며, 예시는 모두 무해한 가공의 태스크("청구서 PDF 출력 구현" 등)로 대체했다. 건수(어느 하루의 지시서 10건 / 보고서 11건)는 실제 파일 수를 센 것이다.

시리즈 / 관련 (미공개)

동일한 "기록 주도 AI 협업" 테마의 자매 주제로서, 기록으로부터 상태를 복구하는 이야기, AI가 지시 자체를 실사하여 정정해 오는 이야기, 인간과 AI가 한 장의 TODO 보드를 공유하는 운용 이야기를 별도 기사로 준비 중이다.

── 저자는 셀프 호스팅(Self-hosting) 기반의 업무 도구군을 실제로 운용 중이다.

이러한 종류의 레거시 쇄신(Legacy Refactoring) / 공유 서버 제약에 관한 조사를 업무로 수행하고 있다.

연락처: github.com/hideyukiMORI

Discussion