서론

AI 에이전트에게 작업 지시서를 쓰게 하고, 다른 AI 에이전트에게 실행하게 하는 운용을 하고 있는 분들에게.

내 손안의 어떤 지시서가 "미수정 위반 사항 17건을 시정하라"고 명령하고 있었다——착수 전에 재측정했더니, 전제 조건은 모두 해소된 상태였다.
지시서의 근거가 된 실측은 4일 전의 것이었으며, 그 4일 동안 선행 PR(Pull Request) 그룹이 모든 것을 머지(merge) 완료한 상태였다.

이 기사에서는 멀티 세션 AI 운용에서 "지시하는 쪽의 지시가 낡았다"는 사고가 어떻게 발생하는지, 그리고 **받는 쪽이 착수 전에 재측정하는 문화(발사 전 실측)**가 이를 어떻게 흡수했는지 실례를 통해 기술한다.

이 기사에서 알 수 있는 것:

• 작업 지시서의 전제가 며칠 만에 부패하는 실례 2가지 (전제의 전멸·감사 어휘의 진부화)
• 왜 AI 협업에서는 문서가 인간 팀보다 더 빠르게 부패하는가
• 대책으로서의 "발사 전 실측"——지시서 측에 재측정을 심어두는 유형과, 부패한 지시를 재해석하는 방법

전제: 복수 세션 운용과 작업 지시서

나는 복수 리포지토리(repository)의 업무 도구군을, 리포지토리마다 별도의 세션으로 AI 에이전트를 세워 병행 개발하고 있다. 횡단적인 계획을 세우는 조정역 세션이 Markdown 형식의 작업 지시서를 쓰고, 각 리포지토리 담당 세션이 이를 받아 구현하는 분업 방식이다.

이 구조에서는 지시서, 계획표, 감사 보고서와 같은 문서가 세션 간의 유일한 인터페이스가 된다. 그리고 문서는 작성하는 순간의 실측 스냅샷이며, 리포지토리는 작성 후에도 계속 움직인다.

실례 1: 지시서의 전제가 4일 만에 전멸해 있었다

어떤 이행 계획표에 대상 리포지토리의 현황으로서 다음과 같이 적혀 있었다 (실측일 기재·commit SHA 고정).

• 미사용 CSS 클래스 (silent no-op) 17건 잔존
• 검출용 lint 미배선
• 규약으로 금지된 디렉토리 세그먼트 (hooks/) 잔존

이 행을 전제로 일괄 변환 도구의 발사와 시정 PR을 지시하는 지시서가 구성되었다. 그런데 담당 세션이 착수 전에 origin/main을 fetch 하여 재측정하자, 3가지 전제는 모두 해소된 상태였다. 계획표의 실측부터 지시서 발사까지의 4일 동안, 어휘 변환 적용·lint 배선·17건의 시정·디렉토리 이설의 선행 PR 그룹이 전부 머지되어 있었던 것이다.

담당 세션은 지시대로 기계를 쏘지 않고(쏘면 헛발질이거나 최악의 경우 이중 적용), 계획표의 해당 행에 "실측 갱신——이후 main에서 해소됨"이라는 주석을 다시 작성했다. 몇 번의 커맨드로 끝나는 재측정 비용으로, 중복 작업인 PR 몇 개 분량을 없앤 계산이 된다.

실례 2: 감사가 규약보다 오래된 언어로 측정하고 있었다

더 큰 규모의 사례도 겪었다. 이행 계획 전체가 사전 감사 보고서를 바탕으로 구성되어 있었다. 그런데 나중에 검증해 보니, 그 감사는 규약이 정한 lint 규칙 이름으로 단 하나도 측정하지 않았다——감사 보고서를 규약의 전체 13개 규칙 이름으로 grep 하여 검색 결과 0건. 감사가 측정하고 있었던 것은 규약이 생기기 전의 어휘(hex 직접 작성·생(raw) fetch·inline style...)였다.

감사 → 규약 → 이행 계획 순으로 만들어졌고, 계획의 할당이 감사에 의존하고 있었기에 "규약의 축으로 아무도 측정하지 않은 채 이행 계획이 세워졌다"는 결과가 되었다. 실질적인 피해도 구체적이었다. 감사에서 "깨끗하다"고 평가되어 가볍게 취급되었던 리포지토리가, 규약의 규칙으로 재측정하자 셀렉터 346개 중 48개(14%)가 위반 사항이었다. 13개 규칙 × 14개 리포지토리로 다시 측정하자 위반 건수는 총 13,021건에 달했고, 이행 계획은 처음부터 다시 짜야 했다.

지시가 부패하는 단위는 "수치"뿐만이 아니다. 측정의 어휘 그 자체가 부패한다.

원인: 구현 속도가 문서의 신선도를 앞지른다

인간 팀에서도 지시는 부패하지만, 통상적으로는 구현보다 지시가 더 빠르다. AI 협업에서는 이것이 역전된다. 병행하는 세션이 하루에 수 개의 PR을 머지하므로, "4일 전의 실측"은 인간 팀의 감각으로는 "수 스프린트 전의 실측"에 해당한다.

그리고 AI 수신자는 기본적으로 문서를 의심하지 않는다. 적혀 있는 숫자를 그대로 전제로 삼아 성실하게 헛발질을 한다. 지시서의 권위와 실태의 신선도가 괴리된다는 점을 운용의 전제로 두어야 한다.

대책: 발사 전 실측을 지시서 측에 심어두기

대책은 수신자의 선의에 맡기지 않는 것이다. 나의 운용에서는 지시서 포맷 자체에 첫 번째 단계로서 다음과 같이 적는다.

Step0: origin/main을 fetch 하여 재측정·SHA 고정 (stale 금지)

즉, "이 지시서의 숫자를 믿지 마라. 착수 전에 HEAD에서 다시 측정하고, 측정한 SHA를 기록한 뒤에 실행하라"를 지시서 스스로가 명령하는 것이다. 실례 1의 헛발질(空撃ち) 회피는 이 Step0가 기능한 결과이다. 지시서에는 "17건이 지금도 17건인지, 이후의 변동을 실측하라"는 형태로, 전제의 실효 가능성까지 명기하게 되었다.

작성자 측의 대책(숫자에 반드시 실측일과 SHA를 첨부함)과 수신자 측의 대책(착수 전 재실측을 절차화함)이라는 양륜(両輪)을 통해, 문서는 '권위'에서 '검증 가능한 주장'으로 격하된다. 나는 이 격하야말로 건전함의 본체라고 생각한다.

이미 적용되었다면 무엇을 실행할 것인가: 멱등성(Idempotency) 증명으로의 재해석

전제가 사라진 지시는 버리는 것만이 정답은 아니다. 재해석될 수 있는 경우가 있다.

또 다른 실례로, 과거의 일괄 변환 PR이 "버전 관리되는 변환 도구의 정식 출시" 이전에 수중에 있던 잠정 드라이버로 실행되었다는 사실이 밝혀진 적이 있다. 다시 실행해야 할까? 재실측 결과, 정식 출시 버전의 도구가 해당 PR의 결과를 byte 일치로 재현할 수 있음(228/228)이 확인되었다. 여기서 지시의 목적은 "변환을 적용한다"에서 "동일한 변환을 재실행해도 동일한 결과가 된다(차분 제로)는 것을 기록한다"로 재해석된다. 이미 적용된 대상에 기계를 다시 실행하는 의미는, 차분이 아니라 멱등성(Idempotency)의 증명에만 있기 때문이다.

"지시대로 실행한다"와 "지시를 반려한다"라는 이지선다가 아니라, 지시의 의도를 유지한 채 검증 태스크로 축퇴(Reduction)시킨다라는 제3의 선택지를 발사 전 실측의 부산물로서 얻을 수 있다.

배움

• 문서는 세션 간의 유일한 인터페이스이지만, 작성된 순간의 스냅샷일 뿐이다. AI 협업에서는 구현 속도가 문서의 신선도를 앞지르기 때문에, 4일 전의 숫자는 이미 신용할 수 없다.
• 대책은 수신자의 선의에 맡기지 말고 절차로 만든다. "착수 전 HEAD에서 재측정·SHA 고정"을 지시서 스스로가 적게 한다. 숫자에는 실측일과 SHA를 첨부한다.
• 부패하는 것은 수치뿐만 아니라 측정의 어휘(Vocabulary)다. 규약(Convention)을 만들었다면, 규약의 어휘로 다시 측정하기 전까지 과거의 감사는 무효로 취급한다.
• 전제가 사라진 지시는 헛발질이나 반려가 아니라 "멱등성(Idempotency)의 증명"으로 재해석될 수 있다.

1차 자료

본 기사의 실례는 나의 운용 기록(비공개 지시서·이행 계획표·실측 로그)에 기반한다. 고유한 숫자(17건·4일·13,021건·228/228 등)는 모두 당시의 기록에서 가져온 것이며, 기억에 의존해 작성한 것은 없다.

공개 리포지토리에서의 실행 실례: nene-field PR #102 — 버전이 포함된 변환 도구의 출력물로만 구성된 move-only PR. 발사 전 실측을 거친 후의 "실행해도 좋은 상태"의 전형으로서.

관련 기사

• 방치된 숫자는 과소 표시로 기울어진다 — 문서 내 숫자가 부패하는 문제의 단일 리포지토리 버전
• curl 전록(All Green)·브라우저 6개 기능 정지 — "검증했다"의 범위가 실태와 어긋나는 이야기. 측정 어휘의 진부화와 동일한 유형
• tsc --noEmit이 아무것도 검사하지 않고 있었다 — 초록색으로 보이는 검사를 의심하고 재측정하는 이야기

본 기사의 실례는 해당 십수 개의 리포지토리를 별도 세션의 AI 에이전트로 병행 개발하는 운용 기록에서 도출되었다.

── 모리 히데유키 (Ayane International) 🔗 ayane.co.jp

Discussion