AI 하나에 다 맡기지 않습니다: 설계·구현·검수 나누기

원고 7편을 다른 AI에게 검수시키자 지적 8건이 나왔습니다. 원고는 ClaudeClaude 클로드 Anthropic이 만든 AI 모델 이름. 크기에 따라 Opus·Sonnet·Haiku로 나뉩니다.눌러서 용어 설명서 보기 →가 쓰고, 검수는 GPTGPT 지피티 OpenAI가 만든 AI 모델 이름. ChatGPT 안에서 돌아가는 모델입니다.눌러서 용어 설명서 보기 →가 했습니다.

그래서 설계하는 AI, 짜는 AI, 검수하는 AI를 따로 둡니다. 그 설정과 실제 검수 기록을 그대로 공개합니다.

하네스는 AI 여러 개에 일을 나눠 맡기는 규칙·스크립트 묶음입니다. 모델 이름·설정 이름·검수 횟수는 10월 27일 실제 설정 파일과 검수 기록 그대로입니다.

한 AI에 다 맡기면 생기는 일

한 대화 안에서 설계하고, 짜고, 스스로 검토까지 하면 같은 눈으로 세 번 보게 됩니다. 같은 대화에서 검토하면 처음의 잘못된 전제를 놓칠 수 있습니다.

혼자 다 하는 구조에서 자주 막히는 지점은 이렇습니다.

• 설계가 흐릿한 채로 코드부터 나옵니다. 고칠수록 처음 의도에서 멀어집니다.
• 대화가 길어지면 앞에서 정한 조건을 놓칩니다.
• 같은 대화에서 검토하면 처음의 잘못된 전제를 놓칠 수 있습니다. 이번에는 별도 검수에서 수정할 항목을 찾았습니다.
• “완료했습니다”라는 말과 실제 결과가 따로 놉니다.

그래서 역할을 나누고, 역할 사이에 넘기는 물건을 정했습니다. 설계는 명세서로, 구현은 결과물로, 검수는 지적 목록으로 넘깁니다. 대화 기록이 아니라 결과물만 넘기는 게 핵심입니다.

누가 무엇을 맡나

주요 역할 일곱 가지를 추렸습니다. 구현과 기본 검수에는 모두 GPT Sol을 배정하며, 여기서 소개하는 다른 회사 검수 사례는 Claude 원고를 GPT가 검토한 경우입니다.

역할	맡은 모델	하는 일
설계·판단	Claude Opus	무엇을 만들지 정하고, 명세를 쓰고, 끝났는지 판정
구현	GPT Sol	모양과 구조까지 정해진 명세대로 코드 작성
검수	GPT Sol	결과 검토. Claude가 쓴 원고는 다른 회사 모델로 검토하는 셈
조사	GPT LunaLuna 루나 OpenAI GPT 계열의 가볍고 저렴한 모델. 이 블로그의 해설서 도구가 쓰는 모델입니다.눌러서 용어 설명서 보기 →	읽기만 하는 조사·감사
화면 확인	GeminiGemini 제미나이 Google이 만든 AI 모델 이름. Flash는 그중 빠르고 저렴한 쪽입니다.눌러서 용어 설명서 보기 →	캡처·디자인 점검
그림	gptimage2	설명 그림 생성
대량 반복	Gemini 저강도	단어 목록·분류 같은 반복 작업

설정 파일에는 이 밖에도 백엔드백엔드 backend 화면 뒤에서 자료 저장과 계산을 맡는 부분.눌러서 용어 설명서 보기 → 설계, 대체 구현, 세션 관리 같은 칸이 더 있습니다. 매일 쓰는 것만 추렸습니다.

서로 다른 계열이 서로를 보도록 짰습니다.

• Claude가 쓴 것(설계·원고) → GPT Sol이 검수합니다.
• GPT Sol이 짠 것(코드) → Claude가 결과를 확인하고 끝을 판정합니다.

이 구조에도 남은 빈칸이 있습니다. 구현과 기본 검수가 모두 GPT 계열이라, 코드만 놓고 보면 같은 계열 판정 문제가 남습니다. 다른 계열 모델을 검수 후보로 더 붙이는 방안을 조사하고 있지만, 아직 정하지 않았습니다.

일을 어느 칸에 보낼지 정하는 기준

일을 받으면 먼저 “이건 어느 칸 일인가”부터 정합니다. 설정 파일의 use 칸에 적힌 설명이 그 기준입니다.

칸	설정에 적힌 용도	이런 일이 오면 보냄
설계	화면, UI, 움직임, 시각 방향, 큰 구조 설계	새 화면, 디자인 개편, 전체 구조 변경
구현	확정된 명세 구현, 리팩터링, 이전 작업, 반복 버그	명세가 다 나온 기능, 같은 버그가 또 날 때
조사	읽기 전용 조사, 감사, 넓은 탐색	”이 저장소에서 X를 쓰는 곳 다 찾아 줘”
화면 확인	이미지 이해, 캡처·디자인 점검	만든 화면 캡처가 의도대로인지
대량 반복	스크립트 안의 대량 반복 텍스트	단어 수백 개 분류, 초안 대량 생성

크기 기준도 하나 있습니다. 설계 칸은 20줄 이하 수정이나 되풀이되는 버그만 직접 고칩니다. 그보다 큰 구현은 명세를 써서 구현 칸에 넘깁니다.

이 기준이 없으면 가장 똑똑한 모델이 모든 일을 붙잡게 됩니다. 실제로 그랬습니다.

2026년 10월 9일에 사흘치 작업 기록을 점검했습니다. 그 사이 Claude 세션 402개가 전부 Opus로 돌았고, 대부분 설계가 아니라 직접 구현을 하고 있었습니다.

원인은 두 가지였습니다.

• “구현은 넘긴다”는 규칙이 세션이 읽는 지침 어디에도 없었습니다.
• 스크립트에 모델 이름이 박혀 있어서, 단어 목록을 대량으로 만드는 반복 작업 236회가 가장 비싼 모델로 돌았습니다.

역할 칸과 이 기준은 그 점검 뒤에 생겼습니다. 대량 반복은 저강도 칸으로, 구현은 구현 칸으로 보내고, 스크립트에서는 모델 이름을 뺐습니다.

모델 이름 대신 역할 이름으로 부릅니다

스크립트 안에는 모델 이름을 쓰지 않습니다. 구현, 검수처럼 역할 이름으로 부르고, 어느 모델이 그 역할을 맡는지는 설정 파일 한 곳에만 적습니다.

실제로는 이렇게 부릅니다.

# 검수를 맡길 때: 역할 이름(review)만 적는다
route exec review --prompt-file review-request.txt --cwd ~/project

# 지금 어느 모델이 어느 역할인지 보기
route table

설정 파일(model-routing.json)의 검수 칸은 이렇게 생겼습니다.

"review": { "alias": "sol", "use": "cross-family code or diff review" }

• 새 모델이 나오면 → 설정 파일에서 그 역할 줄만 바꿉니다. 스크립트를 하나씩 찾아 고치지 않습니다.
• 어떤 모델을 쓰지 않기로 하면 → 그 역할을 다른 모델에 넘기는 줄만 고칩니다.
• use 칸에 그 역할이 무엇을 위한 것인지 적어 둡니다. 나중에 보면 왜 이렇게 나눴는지 바로 압니다.

명세는 모양까지 정해서 넘깁니다

설계는 구현 칸에 넘기지 않습니다. 화면 디자인이나 전체 구조는 Opus가 정하고, 구현 칸에는 그 결과를 명세로 넘깁니다.

숫자 조건만 주면 엉뚱한 모양이 나옵니다. “버튼 3개, 폭 390px에서 깨지지 않게”는 조건일 뿐 모양이 아닙니다. 어떻게 보여야 하는지까지 정해서 넘깁니다.

명세에는 이 순서로 적습니다.

1. 목적: 이 화면(기능)으로 사용자가 끝내야 하는 일 한 줄
2. 모양: 배치, 순서, 색, 글자 크기, 빈 상태와 오류 상태의 모습
3. 구조: 파일 위치, 재사용할 기존 함수, 새로 만들지 말아야 할 것
4. 하지 말 것: 바꾸면 안 되는 파일, 쓰면 안 되는 라이브러리
5. 끝 조건: 어떤 명령을 돌려 어떤 결과가 나오면 끝인지

모양까지 적게 된 계기가 있습니다. 3D 스크롤 화면 시제품을 만들 때, 명세에 기술 요구와 숫자 기준만 적어 구현 칸에 넘겼습니다.

• 결과: 숫자 기준은 전부 통과했습니다.
• 그런데 나무 모양, 열차 모양, 화면 구도는 구현 칸이 사실상 정했습니다.
• 나무는 빗자루처럼, 열차는 장난감처럼 나와서 반려됐습니다.

검수도 같은 Sol이 맡아서 같은 계열끼리 판정한 셈이었습니다. 이 일 뒤로 화면·디자인은 설계 칸이 정하고, 구현 칸에는 모양이 확정된 명세만 넘깁니다. 시각 품질은 스크립트 점수로 판정되지 않기 때문입니다.

5번이 가장 중요합니다. “잘 동작하면 끝”이 아니라 “이 테스트가 통과하고, 이 주소가 200을 돌려주면 끝”처럼 적습니다. 그래야 구현 칸이 끝났다고 할 때 바로 확인할 수 있습니다.

두 번 실패하면 넘겨받습니다

구현 칸이 같은 명세로 두 번 실패하면, 그다음은 Opus가 직접 맡습니다. 세 번째 시도를 같은 모델에 시키지 않습니다.

• 같은 모델이 같은 명세로 또 하면 → 비슷한 곳에서 또 막힙니다.
• 두 번 실패했다면 명세가 모자랐을 가능성도 큽니다. 넘겨받는 쪽이 명세를 다시 봅니다.
• 화면 품질처럼 눈으로 판단해야 하는 일은 처음부터 Opus 쪽에 둡니다.

이 규칙도 설정 파일에 역할로 들어 있습니다. 넘겨받는 칸의 이름은 implement-rescue이고, 설명에 “같은 명세로 두 번 실패했거나 결과가 화면 품질에 달린 경우”라고 적혀 있습니다.

검수는 다른 대화에서 결과만 보고 합니다

검수에는 대화 기록을 넘기지 않습니다. 결과물과 확인 기준만 넘깁니다.

검수 요청은 이렇게 씁니다. 2026년 10월 27일 재검수 때 실제로 보낸 요청의 앞부분입니다.

읽기 전용 재검수. 아래는 이전 검수 지적을 반영한 수정본이다.
각 지적 1~8이 해소됐는지 판정하고, 수정 과정에서 새로 생긴
사실 오류·과장만 짚어라. 근거 확인용 파일: (경로 목록)
출력: 지적별 해소/미해소 한 줄씩, 새 문제는 파일:줄·근거·고칠 문장.
마지막 줄에 편별 판정(KEEP/고침 필요).

요청문에서 지키는 것은 네 가지입니다.

• 읽기 전용이라고 못박습니다. 검수가 파일을 직접 고치면 무엇이 바뀌었는지 놓칩니다.
• 근거 파일 경로를 줍니다. 검수가 “그럴 것 같다”가 아니라 원자료와 대조하게 합니다.
• 범위를 좁힙니다. “전부 다시 봐 줘” 대신 “지난 지적이 풀렸는지와 새로 생긴 문제만”입니다.
• 출력 형식을 정합니다. 줄 번호, 근거, 고칠 문장, 마지막 판정 줄입니다.

결과가 이 형식으로 오면 바로 반영할 수 있습니다. 고칠 문장까지 받으면 해석할 필요가 없고, 마지막 판정 줄만 보면 다음 단계로 갈지 정해집니다.

실제 기록 1: 원고 묶음을 세 차례 검수했습니다

2026년 10월 27일, 원고 7편 묶음으로 시작해 GPT Sol 검수를 총 세 차례 받았습니다. 작성은 Claude가 했습니다. 마지막에는 미해소 지적이 남은 1편만 다시 보내 KEEP을 받았습니다.

• 1차(7편): 지적 8건. 7편 중 4편이 “고침 필요”, 3편이 “KEEP”이었습니다.
• 2차(7편): 8건 중 7건 해소, 1건 미해소. 고치면서 새로 생긴 문제는 없다고 봤습니다.
• 3차(1편): 남은 1건을 고친 뒤 0건, KEEP.

1차 지적을 종류별로 묶으면 이렇습니다.

종류	무엇이 문제였나
고치라고 쓴 예시가 새 문제를 만듦	원고 속 “이렇게 고치면 된다”는 예시가 같은 글의 다른 예시와 겹쳤음
확정이 아닌 것을 확정처럼 씀	AI 판단이 섞인 결과를 “확실한 오류”라고 설명함
보증처럼 읽히는 표현	”이것만 보면 된다”가 놓칠 가능성을 지움
기록에 없는 주장	결정 기록에 없는 판단·비교 결과를 붙임
역할과 모델을 섞음	”검수는 다른 회사 모델”이라 썼지만 실제 설정은 구현·검수가 같은 Sol

마지막 줄은 바로 이 글의 초안 이야기입니다. 설정 파일을 근거로 주니, 검수가 글과 설정의 어긋남을 찾아냈습니다.

2차의 미해소 1건도 같은 문제였습니다. 역할 표는 고쳤는데 “끝났다는 판단은 다른 모델의 검증으로 한다”는 문장이 남아 있었습니다. 검수가 줄 번호와 고칠 문장을 같이 줘서, 그대로 반영하고 3차에서 끝났습니다.

실제 기록 2: 같은 문제가 두 번 나왔습니다

같은 날 앞서 쓴 다른 원고도 Claude가 쓰고 GPT가 검수했습니다. 이때는 같은 종류의 지적이 두 차례 연속 나왔습니다.

2026년 10월 27일 블로그 원고 검수 기록입니다. 이번 원고 검수에서는 Claude 작성물을 GPT가 확인했습니다. 첫 번째는 6건, 수정 후 두 번째는 3건을 지적했습니다.

예문 정답이 하나로 정해지지 않는 문제는 두 차례 모두 나왔습니다.

• 1차 검수: 지적 6건 (예문 정답 둘, 인과 단정 등)
• 2차 검수: 지적 3건 (고친 예문도 여전히 정답 둘)

두 번째에 고친 예문은 검수가 제안한 문장으로 바꿨습니다. 같은 지적이 두 번 나오면, 쓴 쪽이 다시 고치기보다 검수가 준 고칠 문장을 그대로 쓰는 편이 빨랐습니다.

검수 지적을 반영하는 규칙

지적을 받았다고 전부 그대로 고치지 않습니다. 지적도 결과물이라서 확인한 뒤 반영합니다.

• 사실 지적(숫자가 다름, 기록에 없음, 설정과 어긋남)은 근거 파일과 대조해 맞으면 그대로 반영합니다.
• 문장 제안은 뜻만 가져오고, 문장은 원래 글의 말투로 다시 씁니다.
• 단정 표현에 대한 지적은 단서를 줄마다 달지 않고, 앞에 한 번 밝힙니다.
• 검수 판단이 근거 파일과 다르면 반영하지 않고, 왜 안 했는지 기록에 남깁니다.

재검수는 범위를 좁혀 새 대화에 보냅니다. 이번 두 재검수의 실제 사용량입니다.

• 7편·8건을 확인할 때: 67,010 토큰토큰 token AI가 글을 세는 단위로, 요금도 토큰 수로 매깁니다. 로그인 글에서는 접속을 증명하는 출입증을 뜻합니다.눌러서 용어 설명서 보기 →
• 1편·1건을 확인할 때: 19,348 토큰

원고 수와 지적 수, 확인 범위가 함께 달라서 단순 비교는 어렵습니다. 남은 지적만 확인하는 재검수에는 해당 원고만 보냈습니다.

그림 속 글자도 원고처럼 봅니다. 1차 검수는 역할 그림 속 “검수 GPT Sol · 다른 회사”라는 글자를 짚었습니다. 그런데 다른 도식 제목 “쓴 모델이 넘긴 실수를 검수가 두 번 잡았습니다”는 짚지 않았습니다.

그 제목도 기록에 없는 판단이었습니다. 검수 지적을 반영하며 그림을 다시 그리다가 설계 칸이 찾아서 “다른 모델 검수에서 두 번 지적이 나왔습니다”로 고쳤습니다. 검수가 KEEP을 줘도, 반영하는 쪽이 같은 기준으로 주변을 한 번 더 봅니다.

”다 했어요”는 끝이 아닙니다

끝났다는 판정은 실제 결과물로만 합니다. AI가 “완료했습니다”라고 해도, 결과를 다른 대화에서 별도로 검수하기 전에는 끝이 아닙니다.

위 원고 묶음을 “끝”으로 판정할 때 실제로 돌린 확인은 다섯 가지입니다.

1. 형식 검사 스크립트: 오류 0, 경고 0
2. 문체 점검: 기계적인 문장 패턴이 얼마나 강한지 점수로 확인
3. 다른 계열 재검수: 마지막 판정 줄이 KEEP
4. 비공개 미리보기 주소: HTTP 200
5. 휴대폰 폭 390px 캡처: 가로로 넘치는 곳 없음

하나라도 빠지면 “거의 끝”입니다. 다섯 개 결과가 다 나와야 사람에게 보여 줍니다. 명세의 “끝 조건”을 이렇게 명령과 결과로 적어 두는 이유가 여기 있습니다.

이 글을 다듬던 날에도 같은 일이 있었습니다. 다른 글에 넣을 휴대폰용 검사 결과 화면을 “생성됨”으로 넘겨받았는데, 한 장씩 열어 보니 5장의 숫자가 그 글 본문과 달랐습니다.

AI가 판정하는 검사 도구라 다시 실행할 때마다 경고 수가 달라졌기 때문입니다. → 본문에 인용한 결과와 같은 회차의 캡처로 바꿨습니다.

막는 곳은 되돌릴 수 없는 곳뿐

모든 단계에 승인 버튼을 두지 않습니다. 사람이 막는 곳은 외부 게시처럼 되돌릴 수 없는 곳뿐입니다.

• 원고 작성·그림·검수·미리보기 → AI끼리 알아서 돕니다.
• 블로그 공개·스레드 게시 → 제가 전문을 보고 승인해야만 나갑니다.

승인 단계에서는 요약이 아니라 전문을 봅니다. 요약만 보고 승인하면, 요약에 빠진 문장이 그대로 나갑니다. 이 글도 같은 절차로 나갑니다.

승인 요청에는 다섯 가지를 한 화면에 묶어 받습니다.

• 최종 제목과 본문 전문
• 들어갈 그림 전부
• 글 안의 링크
• 올라갈 채널(블로그, 짧은 글 계정 등)
• 올라갈 날짜와 시각

그래서 승인 요청은 늘 이 다섯 가지를 한 번에 올립니다. 조각조각 확인하면, 합쳐진 뒤의 모습은 아무도 안 본 셈이 되기 때문입니다.

미리보기는 휴대폰 화면 폭으로도 한 번 찍어 둡니다. 짧은 글 계정에서 넘어오는 사람은 대부분 휴대폰으로 읽어서, 표나 도식이 옆으로 넘치면 읽기 어렵습니다.

이 글이 만들어진 순서

이 글 자체도 같은 구조로 만들었습니다. 처음 초안은 약 2천 5백 자에 그림 4장이었고, “내용을 더 풍부하게, 설명 그림과 도식을 더”라는 요청을 받아 다시 만들었습니다.

1. 설계(Claude): 기준부터 바꿨습니다. 형식 검사 스크립트의 분량 기준을 8,000자 이상, 본문 그림을 8~14장으로 올리고 테스트 18개가 통과하는지 확인했습니다.
2. 그림(gptimage2): 설명 그림 6장을 동시에 요청하고, 기다리는 동안 원고를 썼습니다.
3. 도식(Claude): 숫자와 구조가 들어가는 도식 5장은 직접 그렸습니다. 설정 파일과 검수 기록의 숫자를 그대로 옮겨야 해서입니다.
4. 확인(Claude): 그림과 도식을 한 장씩 열어 봤습니다. 다른 글의 화면 캡처 하나가 엉뚱한 탭으로 찍힌 걸 여기서 찾아 다시 찍었습니다.
5. 검수(GPT Sol): 완성 원고와 근거 파일 경로만 넘깁니다. 판정이 KEEP이 나와야 사람에게 보입니다.

2번처럼 서로 기다릴 필요가 없는 일은 동시에 돌립니다. 그림을 기다리는 동안 원고를 쓰고, 검수를 기다리는 동안 미리보기를 만듭니다.

해 볼 것

지금 쓰는 AI 도구에서 “쓰는 모델”과 “검수하는 모델”만이라도 나눠 보세요. 검수는 쓰던 대화와 분리해서 맡기는 게 핵심입니다.

작게 시작하면 이 정도입니다.

1. 쓰는 대화와 검수하는 대화를 따로 엽니다. 가능하면 다른 회사 모델로 엽니다.
2. 검수 대화에는 결과물과 근거 자료만 붙입니다. 쓰는 과정의 대화는 붙이지 않습니다.
3. 아래 요청문을 그대로 붙입니다.

읽기 전용으로 검수해 주세요. 고칠 곳만 짚어 주세요.
각 지적마다: 위치(줄 번호), 근거(아래 자료의 어느 부분), 고칠 문장.
사실 오류와 과장만 보고, 문체 취향은 빼 주세요.
마지막 줄에 "판정: KEEP" 또는 "판정: 고침 필요"를 적어 주세요.

4. 지적을 반영한 뒤, 같은 검수 대화가 아니라 새 대화에 다시 보냅니다. “지난 지적이 풀렸는지와 새로 생긴 문제만” 보게 합니다.
5. 판정이 KEEP이 될 때까지 반복합니다.

역할 이름으로 부르는 설정 파일이나 넘겨받기 규칙은 그다음입니다. 이번에는 검수를 분리했을 때 별도 검수에서 고칠 항목이 나왔습니다. 시작은 그 정도로 충분합니다.