Claude에게 코드를 맡기지 않는다 — 11년차 개발자의 AI 작업 방식

11년 동안 개발하며 오래 끈 문제를 돌아보면, 문법 오류보다 전제를 잘못 잡은 경우가 많았다. 요구를 다르게 이해했거나 테스트가 실제 사용 경로를 지나지 않았고, 때로는 ‘이 정도면 끝났다’는 기준부터 틀렸다. 빌드가 성공해도 이런 문제는 남는다.

같은 대화 안에서 계획과 구현, 리뷰를 모두 시키면 모델은 자기가 왜 그렇게 만들었는지 이미 알고 있다. 코드를 의심하기보다 기존 선택을 설명하는 쪽으로 흐르기 쉽다. 나는 그래서 일을 정하는 역할과 코드를 고치는 역할, 결과를 의심하는 역할을 따로 둔다.

Fable은 어디까지 해야 끝인지 정한다. Codex Sol은 저장소를 읽고 실제 파일을 고친다. Opus는 처음 요청과 완성된 diff가 맞는지 다시 본다. 모델을 많이 쓰려는 게 아니라, 한 모델이 처음 잡은 방향을 끝까지 밀어붙이지 못하게 하려는 것이다.

Fable은 모델 이름이 아니라 내 Claude Code에 붙여 둔 커스텀 오케스트레이터다. 지휘 역할만 맡겨 내 요청을 목표와 범위, 완료 조건으로 나누고 어떤 모델을 얼마나 깊게 돌릴지 정한다. 파일 검색과 수정, 테스트와 브라우저 확인은 Sol에게 넘긴다.

Sol에게 대화 전체를 통째로 보내지는 않는다. 이번 작업에 필요한 내용만 추려 짧은 작업 패킷을 만든다. 바꿀 대상만큼 건드리면 안 되는 범위도 분명히 적는다. 실제로는 저장소 경로와 위험도, 결과 형식까지 붙이지만 핵심만 줄이면 이렇다.

goal: Ghostty·tmux 이미지를 본문 폭 안에 맞춘다
scope: 해당 글의 figure 한 곳
out_of_scope: 공통 레이아웃, 다른 글의 넓은 표
acceptance:
  - 1280px에서 figure 폭이 본문 폭과 같다
  - 390px에서 가로 넘침이 없다
  - 전체 사이트 빌드가 통과한다
verification: build + browser 390 / 768 / 1280

이 정도로 조건이 분명한 일은 Sol을 medium으로 돌린다. 설계 선택이 결과를 가를 때만 추론 수준을 올린다. Sol은 저장소에서 원인을 찾아 파일을 고친 뒤, 테스트 결과와 실제 diff를 함께 가져온다. 요구가 잘못 전달됐으면 Fable이 패킷을 고치고, 구현이 틀렸으면 같은 조건으로 Sol에게 다시 보낸다.

Sol의 완료 설명만 읽으면 검토도 그 설명을 따라가기 쉽다. 그래서 Opus에게는 처음 요청한 조건과 실제 git diff, 빌드·테스트 결과를 함께 준다. 검토 대상의 커밋이나 작업 트리 상태도 하나로 고정한다. Sol이 고친 상태와 Opus가 확인한 상태가 다르면, 검토를 통과해도 아무 의미가 없다.

artifact_ref: <Sol과 Opus가 함께 볼 최종 상태>
diff_scope: <이번 작업에서 바뀐 파일>
review_focus:
  - 처음 요청한 동작이 실제로 들어갔는가
  - 관계없는 파일까지 바뀌지 않았는가
  - 성공 근거를 다시 실행할 수 있는가
evidence:
  - build / test output
  - browser measurements

Opus가 먼저 보는 건 세 가지다. 요청한 동작이 실제 코드에 들어갔는지, 관계없는 부분까지 바뀌지 않았는지, Sol이 성공했다고 본 근거를 직접 다시 따라갈 수 있는지다. 배포나 개인정보가 걸렸다면 공개하면 안 되는 값이 diff에 섞이지 않았는지도 본다.

최근에는 콘텐츠 자동화 프로젝트에서 이 흐름을 그대로 썼다. Fable이 배치 작업을 나눠 Sol에게 넘겼고, Sol은 2개 파일에 189줄을 구현한 뒤 구문 검사와 16개 입력 데이터 대조, dry-run까지 마쳤다. 그다음 Opus를 별도 검토자로 붙여 같은 완료 조건을 다시 확인했고 결과는 PASS였다. 검증용 작업이라 실제 제작과 업로드, 유료 API 호출은 하지 않았다.

문제가 있으면 Opus가 코드를 대신 고치지 않는다. 어느 파일의 어느 부분이 왜 문제인지 적는다. Fable이 그 지적을 Sol에게 다시 보내고, Sol이 다시 고치면 Opus도 바뀐 결과를 처음부터 다시 본다. 구현자와 검토자가 같은 답을 서로 강화하지 않게 하려는 장치다.

주로 쓰는 컴퓨터는 Apple M1 Pro 10코어·32GB 맥북 프로다. Ghostty 창 하나에 tmux 화면을 네 칸으로 나눠 둔다. 위쪽 왼쪽에는 Fable의 작업 패킷과 진행 상황을 두고, 위쪽 오른쪽에서는 Sol이 코드를 고치고 테스트를 돌린다. 아래쪽 두 칸은 필요할 때 빌드 로그나 Opus의 검토 결과를 띄우고, 쓰지 않을 때는 비워 둔다.

Ghostty 설정은 화려하지 않다. 글꼴과 투명도, 분할 단축키 정도만 정해 두었다. 마우스 입력을 터미널 앱이 잡아갈 때 바로 끌 수 있는 단축키도 넣었다.

# ~/.config/ghostty/config
font-family = "Source Code Pro"
background-opacity = 0.9
background-blur-radius = 10
keybind = super+shift+o=new_split:auto
keybind = ctrl+shift+m=toggle_mouse_reporting

tmux의 명령 키는 Ctrl+A로 바꿨다. 마우스와 vi 복사 모드를 켜고, y로 고른 내용을 macOS 클립보드에 바로 넣는다.

# ~/.tmux.conf
set -g prefix C-a
set -g mouse on
setw -g mode-keys vi
bind -T copy-mode-vi y send -X copy-pipe-and-cancel "pbcopy"

내가 이 구성을 계속 쓰는 이유는 작업 흐름이 끊기지 않아서다. Ghostty 창을 닫았다 다시 열어도 tmux 세션에는 터미널 상태와 출력이 남는다. 여러 앱 창을 오가며 ‘어디까지 했지?’를 다시 찾는 시간이 줄었다.

처음 요청은 “Ghostty와 tmux 단락의 이미지 사이즈를 확인해”였다. 당시 1280px 화면에서 본문은 704px인데 figure는 1024px였다. 처음 올린 재현 이미지는 1022×579px로, 본문보다 좌우 160px씩 튀어나와 있었다.

원인은 figure에 붙은 article-breakout 클래스였다. Sol이 바꾼 코드는 한 줄뿐이었다.

- <figure class="article-breakout overflow-hidden ...">
+ <figure class="overflow-hidden ...">

줄 하나를 지웠다고 끝내지는 않았다. 사이트 63페이지를 다시 빌드하고, 390·768·1280px 화면에서 이미지 폭과 가로 넘침을 봤다. 기존 글 레이아웃과 제목 순서, 메타데이터, 댓글 영역도 함께 훑었다.

당시 측정값
viewport 1280px
body      704px
figure    1024px  →  704px
image     1022×579  →  702×398
overflow  0px

이 작업은 위험이 낮은 한 줄 수정이라 Opus까지 부르지는 않았다. Sol이 고친 diff와 빌드 결과, 세 화면의 수치를 검토한 뒤 040af06으로 커밋해 main에 푸시했고, Cloudflare Pages에 배포한 뒤 공개 주소에서 같은 수치를 다시 쟀다. 빌드 성공만 봤다면 “화면에서 너무 크다”는 처음 문제는 해결됐는지 알 수 없었을 것이다.

파일을 읽기만 하는 간단한 조사라면 Fable이 Sol에게 맡기고 결과만 받는다. Opus까지 부를 이유가 없다. 코드를 바꾸는 작업에는 독립 검증을 한 번 붙이지만, 위험이 낮은 한 파일 수정에 별도 코드 리뷰까지 겹치지는 않는다. 배포·결제·개인정보·권한처럼 잘못됐을 때 손해가 큰 작업에서만 검토를 더 세게 건다.

한 줄 고치는 데 여러 모델이 차례로 같은 말을 반복하면 안전해지는 게 아니라 그냥 느려진다. 구독료가 고정이어도 쓸 수 있는 시간과 한도는 무한하지 않다. 완료 조건이 흐린 상태에서 에이전트만 늘리면 같은 일을 여러 번 설명하느라 사람이 더 바빠진다.

내 기준은 단순하다. 실제 파일 수정은 Sol, 상태를 바꾼 결과의 독립 검증은 Opus, 추가 코드 리뷰가 필요한지는 실패했을 때의 손해를 보고 정한다. 그 경계를 정하는 일이 Fable의 역할이다.

당신은 구현과 코드 검토를 같은 모델에 맡기나, 따로 나누나? 나누고 있다면 어떤 작업부터 별도 검토를 붙이는지도 댓글로 듣고 싶다.