AI 간 리뷰를 돌리기 전에 결정한 최소 거버넌스

서론

Codex에서 Claude Opus로 리뷰를 넘기는 운용을 시도하기 시작했을 때, 처음에 고민했던 것은 "어떻게 자동화할 것인가"가 아니라 "어디까지 자동화해도 괜찮은가"였습니다. 수중에 있는 2026-06-04 실제 handoff 파일을 1건 작성하였고, 2026-06-10의 운용 메모에서도 Opus 리뷰를 포함한 Codex로의 본격적인 이전을 재검토하고 있습니다.

그 과정에서 효과적이었던 것은 처음부터 broker나 공유 DB를 추가하는 것이 아니라, PoC(Proof of Concept) 상태에서도 사고가 나기 어려운 최소 거버넌스 (Minimum Governance)를 먼저 결정하는 것이었습니다. 이 기사에서는 실제로 읽은 ADR-2026-05-31-ai-handoff-governance.md, handoff 실체, 운용 feedback, 이전 spec을 바탕으로, AI 간 리뷰를 안전하게 돌리기 위해 먼저 고정한 규칙을 정리합니다.

1. 먼저 결정해야 할 것은 "자동화하는 것"보다 "책임의 경계"

수중의 feedback에서는 AI 간 handoff는 "자동화해야 비로소 의미가 있다"라고 명시되어 있었습니다. 요컨대, 인간이 매번 컨텍스트 (Context)를 복사하여 붙여넣고 있는 한, AI 간 리뷰의 가치는 상당히 희박해집니다.

반면, ADR 측에서는 책임의 경계도 상당히 명확했습니다.

• 외부 AI의 답변은 조언이며, Codex가 로컬 검증을 거친 후 반영한다
• handoff 본문은 Git으로 관리하지 않는다
• 여러 모델로의 fan-out은 원칙적으로 하지 않는다
• .env, token, cookie, SSH 키, API key는 handoff에 포함하지 않는다

이 4가지를 먼저 설정하면, AI 간 리뷰는 "다른 AI에게 일을 위임하는 메커니즘"이 아니라, 검증을 전제로 한 외부 리뷰 경로로 다룰 수 있습니다. 저 자신도 처음에는 handoff를 늘리면 정밀도가 올라갈 것이라고 생각했지만, 실제 운용에서는 "누가 최종 판단을 하는가"가 모호한 편이 더 위험했습니다.

2. broker를 만들기 전에, 수치로 확장 조건을 고정한다

이번에 가장 좋았던 점은 확장 조건을 감각이 아닌 수치로 결정했다는 점입니다. ADR과 feedback 모두에서 다음 조건 중 2개 이상이 지속되면 broker화를 검토한다는 방침이었습니다.

• handoff가 일 5건을 초과하는 상태가 2주간 지속된다
• 병렬 AI 세션이 주 3회 이상 동시에 가동된다
• 여러 모델 fan-out 요청이 월 10회 이상이 된다
• 답장 감지나 미독 관리(Unread management)를 수동으로 따라갈 수 없게 된다

이 임계치(Threshold)가 있으면 "조금 편리해 보이니까 기반을 늘리자"라는 과잉 설계 (Over-engineering)를 멈추기 쉽습니다. 실제로 이전 spec의 2026-06-04 실측에서는, Claude 측 scheduled-task artifacts가 46건, Codex automations가 15건, 이름이 완전히 일치하는 overlap이 5건 있었습니다. 우선 처리해야 할 것은 broker 추가가 아니라, 이중 발화나 무발화를 피하는 전환 관리였습니다.

AI 운용에서는 메커니즘을 늘리는 것보다 "언제 늘릴 것인가"를 먼저 적어두는 것이 효과적입니다.

3. handoff는 메시지가 아니라 감사 가능한 작업 기록으로 만든다

2026-06-04에 작성된 실제 handoff에는 의뢰 내용뿐만 아니라 대상 파일, 제약 사항, git 상태, 변경 파일 목록, 차이점(diff) 발췌까지 포함되어 있었습니다. 나아가 opus-review skill에서는 Claude 측을 read-only 상태로 유지하고, 답변은 동일한 handoff 파일에 추가하는 것을 전제로 합니다.

이런 형태로 해두면 나중에 다시 보았을 때 "무엇을 재료로 판단한 리뷰였는가"를 추적할 수 있습니다. 단순한 채팅 이력보다 다음 점이 중요했습니다.

• handoff는 00_Inbox/ai-handoff/에 남긴다
• status: open 상태로 7일이 경과하면, 요점을 정본(Source of truth)으로 옮기고 archive 한다
• 매 회차의 리뷰에는 예산 상한을 둔다
• prompt injection을 전제로, 차이점이나 인용도 신뢰할 수 없는 데이터로 취급한다

현재 수중의 00_Inbox/ai-handoff/ 하위에는 30개의 파일이 있었습니다. 건수가 아직 적을 때는 이 정도의 파일 기반 운용이 더 감사하기 쉽고, 트러블 발생 시에도 롤백(Rollback)이 간단합니다.

4. 이행기는 "owner"와 "shadow"를 나누면 사고가 줄어든다

Codex로의 본격적인 이전 spec에서는 scheduled task마다 owner_runtime, shadow_runtime, idempotency_key

、artifact_check

、last_verified_run

、rollback

을 갖도록 하는 안이었습니다. 이는 AI 간 리뷰에도 그대로 응용할 수 있습니다.

특히 중요했던 것은 다음 두 가지입니다.

• 어느 쪽이 운영 책임을 가질지를 owner로 하나만 결정한다.
• 비교 관측만 수행하는 측을 shadow로 분리한다.

리뷰 시스템은 "둘 다 동작하고 있으니 안심"이라고 생각하기 쉽지만, 실제로는 이중 실행이나 책임의 모호함을 초래하기 쉽습니다. 전환기일수록 병행시키는 것과 주 경로(main path)에 두는 것을 분리하여 다루는 것이 더 안전합니다.

요약

• AI 간 리뷰는 수동 복사-붙여넣기를 전제로 하지 않고, 문맥 패킹(context packing)과 결과 저장까지 자동화한다.
• 단, 최종 반영은 외부 AI가 아니라 로컬에서 검증하는 실행 주체가 가진다.
• broker나 공유 DB는 처음부터 추가하지 않고, 하루 5건, 주 3회, 월 10회와 같은 임계값(threshold)을 기준으로 확장 여부를 판단한다.
• handoff는 단순한 요청문이 아니라, 제약 사항·차이점·답변을 남기는 감사 로그(audit log)로 취급한다.
• 전환기에는 owner와 shadow를 분리하여, 편리함보다 이중 발화(double firing) 방지를 우선한다.

Discussion