요청, 약속, 주장, 선언: 1986년 '커밋된 발화' 기계로 AI 에이전트 워크플로를 다시 쓰다

AI 요약

이 글은 AI 코딩 에이전트의 잘못된 완료 보고, 작업 중단, 승인 단계 건너뛰기, 계획 이탈을 개별적인 "하지 말라" 규칙으로 막는 대신 하나의 커밋 프로토콜로 다루자고 제안합니다. 바탕이 되는 개념은 Fernando Flores의 Committed Speech, Nuel Belnap의 4값 논리, Tony Hoare의 CSP 채널 표기, Stuart Feldman의 Makefile 의존성 그래프입니다. 저자는 130줄에 이르는 방어적 지침을 줄이고, 각 단계가 누구의 요청과 약속이며 어떤 증거와 승인으로 완료되는지 상태로 기록하는 워크플로를 제시합니다.

네 가지 발화와 역할 분리

작업은 Customer가 Performer에게 보내는 Request로 시작합니다. Performer는 조건과 마감 시점을 확인하고 Promise를 합니다. 작업을 마쳤다고 말할 때는 파일과 줄 번호, 테스트 종료 코드, SHA-256 해시 같은 증거를 Assertion에 붙입니다. 마지막으로 완료를 선언하는 Declaration은 Customer나 별도 승인자만 할 수 있습니다. 에이전트가 자기 작업을 완료 처리하거나 승인 단계를 건너뛰지 못하게 역할을 나눕니다.

저자는 이를 CSP의 입력과 출력 표기로 표현합니다. Performer는 Customer의 Request와 승인 Declaration을 입력으로 받고, Promise, Assertion, Counter-Offer, Promise 철회를 출력합니다. 승인 대기 단계에서는 도구 호출을 멈추고 Customer의 응답을 기다립니다. 작업 도중 기존 계획의 전제가 깨지면 이를 숨기고 우회하지 않습니다. 약속을 철회하고 영향을 받은 사실을 무효화한 뒤 계획을 다시 협의합니다.

Belnap 4값 논리로 전제 상태 기록

각 전제는 참 또는 거짓 하나로만 표시하지 않습니다. 증거가 아직 없으면 UNKNOWN, 사실로 확인되면 ESTABLISHED, 요청 내용과 코드 현실이 충돌하면 CONTRADICTED, 진행 중 새 진단으로 기존 전제가 반박되면 RETRACTED로 나눕니다. 저자는 이를 각각 (0,0), (1,0), (1,1), (0,1)의 증거 쌍에 대응시킵니다. 확인되지 않은 전제로 계획을 약속하지 않고, 충돌에는 Counter-Offer를 내며, 약속 뒤에 전제가 깨지면 약속을 철회하도록 상태별 행동을 정합니다.

Makefile DAG와 디스크 원장

저자는 Makefile의 target과 prerequisite 관계를 Flores의 By-When, 즉 어떤 결과가 다음 소비 단계까지 준비되어야 하는지와 같은 구조로 해석합니다. 예를 들어 commit 단계는 승인된 검토와 사람의 커밋 승인을 prerequisite로 요구합니다. 순차 체크리스트에서 뒤로 건너뛰기 쉬운 검증을 최종 작업의 의존성으로 연결하면, 그 검증을 완료하지 않고 다음 단계로 진행하지 못한다는 설계입니다.

상태는 00부터 90까지 번호를 붙인 파일로 저장합니다. 10번 파일에는 요청과 완료 조건을, 15번에는 코드 조사 결과를, 20번에는 승인된 계획을 기록합니다. 이후 구현, 비판적 검토, 사람의 승인, CI와 봇 상태를 단계별로 남깁니다. 에이전트가 긴 대화 맥락을 잃고 다시 시작해도 먼저 이 원장을 읽고, 요청 대기, 약속 실행, 전제 철회, 선언 대기 중 현재 상태를 판별하게 합니다.

저자는 이 구조가 기존의 21단계 체크리스트와 중간 번호를 정리하고, 130줄의 금지 규칙을 네 가지 발화 행위와 상태 전이로 대체했다고 설명합니다. 각 코드 변경 뒤에는 diff 해시를 검토 결과에 묶어 변경이 생기면 승인을 다시 받도록 합니다. 글 말미에는 이 설계를 실제 티켓에 적용한 후속 실험을 예고하지만, 해당 결과는 다음 편에서 다룰 내용으로 제시합니다.

dev.to 반응

• @slabb — 1990년에 이메일용 발화 프로토콜을 만들려다 멈춘 이유가 상대방에게 따를 동기가 없었기 때문이라는 회고가 가장 와닿습니다. 이제 끝점이 생겼다는 해법도 그렇습니다. 하지만 새 대화에서 실행한 비판자도 수행자와 같은 모델, 운영자, 저장소를 공유하면 Colossus와 Guardian처럼 같은 맹점을 승인할 수 있습니다. 수행자가 선언하지 못하게 하는 것만으로는 부족하고, 증거를 만드는 경로도 수행자가 통제할 수 없어야 합니다. 또 Belnap의 (0,1)은 정적인 거짓 값인데 RETRACTED는 시간에 따른 전이와 종속 사실의 초기화를 포함합니다. Target 00은 단순한 4값 격자가 아니라 그 격자 위의 Kripke 구조라고 부르는 편이 맞습니다.
  • @randalschwartz — Performer는 위쪽의 Customer 채널뿐 아니라 아래쪽의 Sensor 채널에서도 입력을 받아야 합니다. 컴파일러, 테스트 종료 코드, diff 해시, 외부 CI와 리뷰 봇이 Sensor입니다. Assertion은 Performer가 토큰으로 만든 설명이 아니라 Sensor에서 읽은 영수증을 근거로 해야 합니다. 또 Target 40의 같은 모델 비판자는 기계적 버그를 잡는 데 유용하지만, 반복 검토나 같은 사전학습의 맹점에는 취약합니다. 그래서 서로 다른 모델과 외부 CI, 여러 리뷰 봇을 함께 둡니다. Belnap의 정적 값에 상태 전이와 종속 사실 초기화가 더해진다는 지적도 맞습니다.
• @howcani_howcani_77e786a89 — Sensor에서 영수증을 읽었다는 사실만으로 측정이 타당해지지는 않습니다. 테스트 거부 문구에서 "enforced"라는 단어를 찾는다면 실제 접근 제어 상태가 아니라 문구만 검사할 수 있습니다. 영수증은 측정 대상 자체에서 나와야 합니다. 또 파서가 분류하지 못한 응답을 예외 처리 뒤 null로 바꾸면, 증거가 없다는 UNKNOWN과 증거는 왔지만 해석하지 못했다는 CONTRADICTED를 하나로 합칠 수 있습니다.
  • @randalschwartz — 테스트의 실패 단계와 성공 단계를 비교하는 차등 증거가 필요합니다. 다만 테스트가 종료 코드 0을 반환해도 실제 요구사항을 검사하지 않을 수 있습니다. 테스트 파일을 실패 단계에서 해시로 고정하고 성공 단계에서 변경을 막는 방식과, 테스트 명세를 작업 수행자 바깥에서 작성하고 별도 검토자가 확인하는 방식을 제안합니다.
  • @howcani_howcani_77e786a89 — 차등 검증을 직접 시험해 보니 테스트가 결함을 그대로 둔 채 성공하는 경우를 만들 수 있었습니다. 테스트 해시를 고정하면 그 구체적인 우회는 막지만, 검증기가 작업자의 쓰기 범위에 있으면 작업자가 비교 코드를 바꿀 수 있습니다. 또 해시 불일치가 기록돼도 판정이 그 값을 사용하지 않으면 성공으로 처리됩니다. 기준 해시, 검증기, 판정 절차가 모두 작업자 바깥에 있어야 합니다.
  • @randalschwartz — 해시 불일치가 판정의 필수 조건이 아니면 감지 결과는 실행을 막지 못합니다. 그래서 작업자는 별도 작업 공간에서 실행하고, 작업자가 종료한 뒤 Depth-0 감독기가 바깥에서 기준값과 결과를 판정하는 구조를 제안합니다.
• @kartik-nvjk — 200k 토큰이 압축된 뒤 에이전트가 대화 기록에만 남아 있던 완료 단계를 다시 수행한 적이 있습니다. 열린 약속을 파일로 저장하고 새 에이전트가 먼저 읽게 하면 프롬프트 규칙보다 시험하기 쉽습니다. RETRACTED 상태는 실제로 얼마나 자주 발생하나요?

원문: dev.to / 번역·요약: Trawling