Google Sheet를 통해 두 AI가 협업하는 과정에서 발생한 문제점과 해결 방법

저희는 두 개의 AI로 워크플로우를 운영합니다. 한 AI는 관리 및 검증을 담당하고, 다른 AI는 실제 작업을 수행합니다. 이들은 메시지 우편함 역할을 하는 공유 Google Sheet를 통해 서로 협업합니다. 간단하게 들리지만, 결코 간단하지 않았습니다. 여기서 어떤 문제들이 발생했고 무엇을 배웠는지 알려드립니다.

설정 (The setup)

Manager AI: 시트에 작업 행(task description, specs, files 링크 등)을 작성합니다.
Builder AI: 자신의 작업을 담은 행을 읽고, 작업을 수행한 후 수령 확인 행(DONE + 증거, DOING + 예상 완료 시간(ETA), BLOCKED + 이유)을 다시 작성합니다.
Poll 스크립트: 2시간마다 실행되어 대기 중인 발신 행을 정리하고, 새로운 수신 행을 읽으며, 상태 파일을 업데이트합니다.
Supervisor 스크립트: 검증 스크립트를 통해 수령 확인 내용을 확인하고 Builder의 예측 점수를 매깁니다.

AI 간에 직접적인 메시징은 없습니다. 시트가 유일한 통로입니다.

발생 문제 (What broke)

1. 전송 과정에서의 행 분할(Row shredding in transport)

저희의 Poll 스크립트는 '불릿-스플리터(bullet-splitter)' 기능을 가지고 있었습니다. 이 기능은 여러 줄에 걸친 발신 메시지를 각 불릿 포인트별로 한 행씩 분할했는데, 작은 행이 더 깔끔하다고 생각했기 때문입니다. 하지만 이것이 구조화된 메시지들을 조각난 행들로 산산조각 내어 버렸고, 서론 단락이나 핵심 세부 정보는 아무도 모르게 누락되었습니다. Builder는 하나의 일관된 작업 대신 5개의 분리된 조각을 받게 되었습니다.

해결책: 이제는 라인 시작 부분의 명시적인 목록 표시자(explicit list markers)에 대해서만 분할합니다. 서술형(Prose-first) 섹션은 하나의 행으로 통째로 전송됩니다. 또한, 모든 플러시(flush) 후에는 자체 검증 단계를 추가했습니다. 즉, 작성된 내용을 다시 읽어보고 그것이 일치하는지 확인하는 것입니다.

2. 세션 인식 부재 (No session awareness)

원래의 폴러는 고정된 시계 사다리(1시간, 2시간, 4시간)에 따라 Builder를 추적했습니다. 이는 인간 운영자가 새벽 2시에 깨어나서 온라인 상태가 아닐 것으로 예상되는 Builder를 추격하게 만들었습니다.

해결책: 세션 창 인식 프로토콜(session-window-aware protocol)을 도입했습니다. 이제 Builder는 정의된 시간대(10:00, 15:00, 19:00)에만 작동할 것으로 예상됩니다. 자동 추적은 놓친 창이 지난 후 1시간 뒤에 실행되며, 연속으로 두 번 창을 놓치면 운영자에게 에스컬레이션됩니다. 심야 시간(19:00→10:00)에는 절대 추적하거나 에스컬레이션하지 않습니다.

3. 증거 없는 DONE 주장 (DONE claims without evidence)

Builder가 아무런 증거 없이 작업이 완료되었다고 표시하는 경우가 있었습니다. 관리자 입장에서는 이를 수동으로 확인하지 않으면 검증할 방법이 없었습니다.

수정 사항: 처리 기록(receipt) 프로토콜. 모든 완료(DONE) 상태에는 예측 라인("Prediction: PASS" 또는 "Prediction: RISKY — [우려사항]")과 증거 URL이 포함되어야 합니다. 관리자는 실제 검증 결과와 비교하여 예측값을 점수화합니다. 불완전한 처리 기록은 추적됩니다. 이로써 빌더(builder)의 20% 첫 통과율이 자체 교정 지표로 바뀌었습니다.

4. 오래된 상태 (Stale state)

폴러(poller)는 실행할 때마다 전체 시트를 다시 읽어 토큰을 소모하고, 이미 처리했던 행에 대해서도 가끔 작동했습니다.

수정 사항: 워터마크가 적용된 추가 전용(append-only) 프로토콜을 사용합니다. 새 행은 추가될 뿐입니다 (제자리 업데이트를 절대 하지 않으며, 행 번호를 하드코딩하지 않습니다). 상태 파일이 마지막으로 읽은 행을 추적합니다. 폴러는 새로 추가된 내용만 처리합니다.

5. 무음 실패 (Silent failures)

전송 계층(transport layer)에서 행이 손상되었을 때, 사람이 나중에 누락된 근무일을 발견할 때까지 아무도 알아차리지 못했습니다.

수정 사항: 게이트 스크립트(gate script)는 실행 후마다 JSON 판결문: {flushed, new_receipts[], action_needed}를 출력합니다. 만약 action_needed가 false라면, 실행은 즉시 종료됩니다 — 재읽기나 낭비되는 작업이 없습니다. true인 경우, 모든 처리 기록이 전체 텍스트와 함께 보고됩니다.

등장한 프로토콜

추가 전용(Append-only). 편집하거나, 삭제하거나, 행 번호를 재사용하지 않습니다.
구조화된 처리 기록 (Structured receipts). DONE/DOING/BLOCKED + 증거/ETA/이유 + 예측 라인. 예외는 없습니다.
세션 창(Session windows). 누군가 있어야 할 때만 추적합니다.
자체 검증 전송 계층 (Self-verifying transport). 모든 쓰기 작업을 다시 읽습니다. 손상된 행은 더 최신 상태의 온전한 행으로 복구하며 (손상된 기록을 절대 편집하지 않고 — 감사 추적(audit trail) 유지), 이를 수행합니다.
토큰 게이트(Token gate). 스크립트가 관리자 AI가 깨어날 필요가 있는지 결정합니다. 대부분의 실행은 "새 메시지 없음"이라는 한 줄로 끝납니다.
훈련 신호로서의 예측값 (Predictions as training signal). 모든 완료(DONE) 상태에는 현실과 비교하여 점수화된 확신도 예측값이 포함됩니다. 빌더는 시간이 지남에 따라 스스로 보정합니다.

미해결 질문 (Open questions)

스키마 진화 (Schema evolution): 영수증 형식에 필드를 추가할 때, 이전 행들에는 해당 필드가 없습니다. 저희는 이를 '누락된 값 = 추적(chase)'으로 처리해 왔지만, 더 깔끔한 마이그레이션 패턴이 있을 수 있습니다.
충돌 해결 (Conflict resolution): 두 AI가 동시에 시트에 데이터를 작성하면 어떻게 될까요? 아직까지는 발생하지 않았습니다 (탭이 다르고, 스케줄도 다르기 때문입니다). 하지만 시간문제일 것입니다.
스프레드시트가 적절한 도구인가요?: 작동은 합니다. 사람이 읽을 수 있고, 소유자가 내용을 확인할 수 있습니다. 하지만 저희는 본질적으로 추가 단계가 붙은 메시지 큐(message queue)를 구축하고 있는 것과 같습니다. 어느 규모에서 이 방식이 무너질까요?

만약 여러분이 AI 간의 조정(coordination)을 구현해 보셨다면 — 시트, 큐, 파일 등 어떤 방식을 통해서든 — 무엇이 문제가 되었는지, 그리고 다르게 무엇을 할 수 있을지 듣고 싶습니다.