병렬 AI 에이전트는 검토할 때가 되면 환상이 깨진다

제 에이전트한테 물어봤더니 이런 답을 주더군요 🤔 병렬 에이전트를 운영하는 사람들이 효과를 본 몇 가지 접근법입니다: 에이전트가 단순히 diff만 내놓는 게 아니라 검토 가능한 아티팩트를 생성하게 하세요. 각 에이전트가 무엇을 하려 했는지, 무엇을 변경했는지, 무엇을 테스트했는지, 의도적으로 무엇을 건드리지 않았는지에 대한 짧고 구조화된 요약을 출력하도록 강제하세요. '5개 파일이면 되는데 20개를 건드리는' 문제는 보통 검토 전까지는 보이지 않는 스코프 드리프트(scope drift) 때문입니다. 만약 에이전트가 처음에 스코프를 선언하고 나중에 검토 시 대조해야 한다면...

SaaS 코드베이스에서 50개 미만의 활성 저장소를 다룰 때, 세 번째 병렬 에이전트를 도입하고 나서 정확히 이 난장판을 겪었습니다. 에이전트들은 빨랐지만, 작업 의도와 결과물인 diff 사이의 맥락을 계속 놓치게 되면서 검토 시간이 2배 정도 늘어났습니다. 특히 하나의 작업이 15개 이상의 파일로 퍼져나갈 때 더 심했죠. 결국 소유자, 의존성, 체크 항목, 짧은 근거가 포함된 간단한 작업 카드를 추가했더니 혼란이 많이 줄었습니다. 하지만 '완료'라는 상태가 무엇을 의미하는지 명확하게 정의하는 깔끔한 방법은 아직 찾지 못했네요.

"오늘날 너의 검증 단계는 어떤 모습인가"라는 질문에 대해 — 나한테 결국 효과가 있었던 건 "완료"의 의미를 "에이전트가 완료라고 말했다"가 아니라 "위조할 수 없는 증거를 생성했다"로 바꾸는 거였음. AI_Conductor가 말한 소스에서의 증거에 덧붙이자면, 문제는 에이전트가 스스로 증거를 생성하게 하면 결국 자기 보고를 믿는 꼴이 된다는 거임. 그래서 도움이 된 두 가지 추가 사항이 있음: 경계 검사는 작업 실행 시점에 수행되는데, 에이전트가 말로 빠져나갈 수 없는 게이트 역할을 함 — scope creep이 발생한 diff나 충족되지 않은 수락 조건 같은 거 말이지.

이게 제가 이 시스템을 만든 정확한 이유입니다. 기술적으로는 멀티 에이전트 컨텍스트와 메모리 관리를 위한 프로토콜이죠. 본질적으로는 에이전트 군단 전체를 위한 하나의 공유 두뇌입니다. 모든 상호작용을 기록하고 에이전트가 하는 모든 일을 한곳에서 추적하는 세 가지 핵심 요소가 담긴 간단한 쓰기 백(write back) 시스템일 뿐입니다.

저는 각 에이전트가 작업을 마칠 때마다 생성해야 하는 디브리핑 스킬을 가지고 있습니다. 기본적으로 에이전트가 화이트보드 앞에 나와서 무엇을, 어떻게, 왜 했는지 설명하는 식이죠. 질문도 할 수 있고요. 매우 시각적이고 플로우차트와 포스트잇이 있는 캔버스를 사용하는데, 코드가 어디로 향하고 있는지 제대로 이해하는 데 정말 큰 도움이 됩니다.