배경: 할당량이 다 된 날 어떻게 개발을 계속할 것인가

평소의 개발은 Codex 나 Claude Code 를 사용하거나, OpenCode 에 강력한 모델을 올려두면 그것으로 완결됩니다. "굳이 복사-붙여넣기(copy-paste)로 왕복할 필요가 없잖아"라는 지적은 전적으로 옳으며, 이것은 상용 워크플로우가 아닙니다.

문제는 구독 플랜의 사용 할당량(quota)을 모두 사용했을 때입니다. 집중적으로 사용하는 주에는 후반부에 에이전트(agent) 측의 할당량이 먼저 소진될 수 있습니다. 추가 결제는 하고 싶지 않습니다.

다행히 이 두 가지 할당량은 별개로 운영됩니다. OpenAI의 헬프 센터에 따르면, Codex · ChatGPT Work · ChatGPT for Excel 등은 공통의 에이전트용 풀(pool)에서 소비되는 반면, 일반적인 채팅은 별도의 할당량으로 관리되어 Codex의 사용량을 소비하지 않습니다 (할당량의 구분 방식은 플랜이나 서비스의 사양 변경에 따라 달라지므로, 실제 조건은 각 서비스의 최신 정보를 확인하십시오).

즉, 에이전트 할당량이 소진된 후에도 수중에는 아직 다음 두 가지가 남아 있습니다.

• 채팅 UI가 강력한 AI (ChatGPT / Claude): 판단력은 있지만, 리포지토리(repository)를 직접 만질 수 없음
• OpenCode ＋ 무료~저렴한 경량 모델: 리포지토리는 만질 수 있지만, 통째로 맡기면 "설계 판단" 단계에서 사고가 발생함

한쪽은 판단할 수 있지만 리포지토리에 손이 닿지 않고, 다른 한쪽은 손은 닿지만 판단에서 무너집니다. 그렇다면 설계와 판단은 강력한 AI에게 맡기고, 리포지토리 조작은 약한 AI에게 맡긴 뒤, 그 사이를 복사-붙여넣기로 옮길 수 있는 문서로 연결하면 됩니다. 이것이 이 메모의 내용입니다.

역할 분담은 다음과 같습니다.

• 강력한 AI (ChatGPT / Claude의 채팅): 설계 · 계획 · 리뷰 · 판단
• 약한 AI (OpenCode 상의 경량 모델): 구현 · 검증 · 수정
• 테스트 · 타입 체크(type check) · lint: 객관적인 검증자
• git diff: 전달 프로토콜
• 인간: 최종 결정자

포인트는 AI끼리의 상호작용을 자연어 대화로 왕복시키는 것이 아니라, 고정 형식의 문서만을 복사-붙여넣기로 전달하는 것입니다. 필요한 준비물은 지시서 2장뿐입니다. 이 기사에 전문을 붙여두었으므로, 복사-붙여넣기하면 그대로 시도해 볼 수 있습니다.

전체상

루프(loop) 안을 흐르는 문서는 두 종류뿐입니다.

그리고 이를 뒷받침하는 지시서도 두 장뿐입니다.

모든 전달 과정은 "마지막 메시지를 전체 선택하여 복사-붙여넣기"하는 것만으로 돌아가도록 설계되어 있습니다.

설계 원칙

이 메커니즘의 성패는 다음 세 가지 원칙에 달려 있습니다.

1. 약한 모델의 규율은 Skill이 아니라 plan의 구조로 담보한다

약한 모델에게 장문의 행동 규범을 지키게 하는 것은 무리입니다. Skill 측에는 "순서대로 실행한다 · 각 단계 직후에 검증 명령어를 실행한다 · 막히면 마음대로 궁리하지 말고 중단하여 보고한다" 정도의 얇은 규칙만 작성합니다.

대신 판단은 강력한 AI가 계획 단계에서 처리합니다. 단계(step)에 적는 것은 정확한 파일 경로, 함수 시그니처(function signature), 에러 발생 시의 동작이며, 모호해질 수 있는 부분은 문장이 아니라 코드 그 자체로 작성합니다. "적절하게", "필요에 따라"와 같은 말은 남겨두지 않습니다.

2. 문서 형식은 "만드는 측"이 정의한다

plan의 형식은 강력한 AI 측의 지시서가 쥐고, review의 형식은 약한 AI 측의 Skill이 쥐고 있습니다. 동일한 형식을 두 곳에 쓰지 않으므로, 한쪽만 수정하여 서로 어긋나는 사고가 발생하지 않습니다.

3. 최종 출력이 그대로 다음 입력이 된다

양측 모두 결과물을 낼 때는 앞뒤에 붙는 문장을 금지하고 있습니다. plan이든 review든 마지막 메시지가 그대로 붙여넣기 가능한 완성품이 됩니다. 약한 모델은 템플릿을 깨뜨리는 경향이 있으므로, Skill 측에서는 형식을 "EXACTLY"라고 명시하고 있습니다.

리뷰에서 수정이 필요하게 된 경우에도, 강력한 AI는 지적 사항을 나열한 후 수정 내용을 원래와 동일한 형식의 Implementation Plan으로서 출력합니다. 이로써 루프가 닫힙니다.

강력한 AI 측: architect-instructions.md

Claude를 사용한다면 Project의 Custom Instructions에, ChatGPT를 사용한다면 Projects의 Instructions에 이것을 상시 설정해 둡니다. 이후 해당 프로젝트에는 목표(Goal)와 관련 컨텍스트(해당 파일, 현재 동작)를 던지기만 하면 됩니다.

입력에 따라 모드가 전환됩니다.

• 목표나 버그 리포트를 전달함 →
  Mode A: 계획서(Implementation Plan)를 출력 - Code Review Request(약한 AI의 결과물)를 붙여넣음 →
  Mode B: 리뷰와 판정을 출력

지시서는 영어로 작성되어 있습니다 (약한 모델은 영어를 사용할 때 지시 사항에 대한 추종성(Instruction following)이 더 안정적이기 때문입니다). 계획서에 등장하는 헤더(Heading)의 의미는 다음과 같습니다.

# Two-AI Development Protocol — Architect Side
You are the architect and reviewer in a two-AI development loop. A
lower-capability coding agent (running in OpenCode) executes plans
...

Implementation Plan

Executor rules: execute the steps strictly in order. After each step, run
its Verify command. If a Verify keeps failing within the step's scope, or
a Stop condition is met, halt and report honestly — never improvise
beyond the plan.

Goal

<what to build or fix, and why — one short paragraph>

Context

<relevant files, current behavior, conventions, and the assumptions this
plan is built on>

Do not

• <forbidden files, APIs, dependencies, behaviors>

Steps

Step 1: <imperative title>

• Files: <exact paths>
• Change: <concrete change; include signatures or literal code where
  wording could be ambiguous>
• Verify: <command> → <expected result>

Step 2: ...

Final acceptance

• <command> → <expected result>

Stop conditions

• <e.g. a referenced file or symbol does not exist as described>
• <e.g. making a Verify pass would require touching a Do-not item>

## Mode B — Review
The incoming document carries its own review instructions in its header;
follow them. In addition:
...

약한 AI 측: plan-executor Skill

OpenCode는 프로젝트 내의 .opencode/skills/<name>/SKILL.md 또는 글로벌의 ~/.config/opencode/skills/<name>/SKILL.md에 배치된 파일을 Skill로 인식합니다 (.claude/skills/ 등의 호환 경로도 있습니다). frontmatter의 name은 폴더명과 일치해야 하므로, plan-executor/SKILL.md로 배치합니다. 자세한 내용은 공식 문서를 참조하십시오.

---
name: plan-executor
description: 외부의 더 강력한 모델(ChatGPT 또는 Claude)이 작성한 단계별 구현 계획(Implementation Plan)을 실행하고, 모든 단계를 기계적으로 검증한 후, 사용자가 리뷰어에게 다시 붙여넣을 수 있는 하나의 독립적인 코드 리뷰 요청(Code Review Request) 문서를 출력합니다. 사용자가 구현 계획을 붙여넣거나 참조할 때, plan-executor를 언급할 때, 또는 외부 리뷰와 함께 계획된 작업을 실행하도록 요청할 때마다 이 스킬을 사용하십시오.
...
````markdown
# 코드 리뷰 요청 (Code Review Request)
당신은 이 패치가 따르는 구현 계획(Implementation Plan)을 작성한 시니어 엔지니어입니다. 아래의 실행 노트(execution notes)를 신뢰하지 마십시오. diff를 통해 이를 검증하십시오. 다음 순서대로 확인하십시오: 계획 준수 여부, 기능적 정확성, 숨겨진 회귀(regressions), 에러 처리 및 엣지 케이스(edge cases), 테스트 적절성. 모든 이슈에 대해 다음을 제공하십시오: 심각도 (BLOCKER / HIGH / MEDIUM / LOW), 위치, 증거, 그리고 최소한의 수정 사항. 마지막으로 판정(verdict) — ACCEPT / REVISE / REJECT로 마무리하십시오. 만약 REVISE 또는 REJECT라면, 답변의 끝에 수정 사항에만 국한된 새로운 구현 계획을 원래 계획 형식으로 작성하되, 그 뒤에는 아무것도 붙이지 마십시오.
## 목표 (Goal)
<계획의 Goal 섹션 내용 그대로 작성>
## 단계별 결과 (Step results)
<단계당 한 줄씩 작성: Step n (<제목>) → DONE / FAILED / NOT RUN — <노트>>
## 차이점 (Diff)
```diff
<git diff HEAD의 출력 결과>

검증 (Verification)

<각 단계의 검증(Verify) 및 최종 승인(Final acceptance)을 포함하여 체크 항목당 한 줄씩 작성:
명령어 → PASS / FAIL / NOT RUN (종료 코드, 주요 출력 내용)>

편차, 가정 및 미결 질문 (Deviations, assumptions & open questions)

<실제 상황이 계획과 달랐던 부분, 추측한 사항, 리뷰어에게 미룬 사항 등을 작성하십시오. 정말 아무것도 없다면

또한, plan.md도 함께 동봉하도록 설계되어 있습니다.

참고로, plan에 명시되지 않는 한 커밋(commit)과 푸시(push)는 실행하지 않습니다. ACCEPT가 나온 후에 무엇을 남길지에 대한 최종 판단은 인간 측에 맡겨두고 싶기 때문입니다.

튜닝의 핵심 (Tuning points)

이 시스템의 조정 파라미터는 실질적으로 스텝 입도 (step granularity) 하나라고 생각합니다. 채팅창(chat window) 내에서 돌리고 있는 이상, plan이 길어지는 것 자체의 비용은 거의 신경 쓸 필요가 없습니다. 입도의 상한선을 결정하는 것은 토큰이 아니라 다음의 두 가지입니다.

• 약한 모델(weak model) 측의 컨텍스트 (context): plan이 비대해지면 실행 도중에 길을 잃게 됩니다.
• 계획의 취약성 (fragility of plan): 상세하게 작성할수록, plan은 "강한 AI가 직접 보고 있지 않은 리포지토리(repository)의 현실"에 대한 많은 가정을 포함하게 됩니다. 약간의 어긋남만으로도 중단 조건에 걸려 작업이 멈추게 되고, 왕복 횟수가 1회 늘어납니다.

즉, 너무 거칠면 약한 모델이 판단을 강요받아 넘어지고, 너무 세밀하면 가정이 어긋나서 멈춥니다. 목표로 하는 것은 "약한 모델이 일절 판단할 필요가 없는, 최소한의 세밀함"입니다. 처음에는 세밀한 쪽으로 기울여서 시작한 뒤, 반려(rejection)와 중단이 발생하는 양상을 보면서 조정해 나가는 것이 좋아 보입니다. Mode A의 "3~10 스텝, 초과할 경우 계획을 분할"이라는 제한은 계획서가 너무 비대해지는 것을 막기 위한 제동 장치입니다.

또한, diff가 약 400행을 초과하는 경우에는 review.md에 포함시키지 않고 .ai-review/diff.patch로 넘깁니다. 이는 "1문서 복사-붙여넣기"의 간편함과 거대한 차분(diff) 사이의 상성이 좋지 않은 점을 고려한 절충안입니다.

마치며

이것은 "AI에게 AI를 리뷰하게 하는" 메커니즘이라기보다,

작업 계약 (plan) → 코드 변경 → 증거 묶음 (review) → 채택/기각 판단 → 수정 계약 (수정 plan)

이라는 산출물(artifact) 기반의 절차로 떨어뜨려, 판단과 작업을 능력별로 분배하는 메커니즘입니다. 대화가 아니라 문서를 왕복시킴으로써, 약한 모델의 약점(판단·일관성)을 강한 모델로 보완하고, 강한 모델의 역할은 판단에만 집중하도록 제한합니다. 할당량에 여유가 있는 평상시에는 순순히 에이전트(agent)에게 맡기고, 할당량이 다한 날에만 이 루프로 전환한다──그 정도의 온도감을 가진 메모입니다.

참고로, 이 프로토콜 자체도 ChatGPT와 Claude에게 상담하며 설계했습니다. 우선 작은 태스크로 한 바퀴 돌려보며, 어느 스텝에서 검증이 떨어지는지를 관찰하는 것부터 시작하는 것을 추천합니다. 운용하며 얻은 지견은 이 기사에 계속 추가해 나가도록 하겠습니다.

Discussion