저는 그동안 이 뉴스레터에서 "AI가 짠 코드를 믿지 마라, 검증시켜라"를 여러 번 다뤘어요. Writer/Reviewer 패턴도 소개했고, 테스트 하니스도 다뤘고, 린팅 자동화도 다뤘고요.
근데 하나 빠진 게 있었어요. 코드 리뷰요.
테스트가 "작동하느냐"를 검증한다면, 코드 리뷰는 "이게 좋은 코드냐"를 검증하잖아요. 아키텍처가 맞는지, 기존 패턴을 따르는지, 불필요한 복잡성은 없는지. 이건 테스트로 잡히지 않아요.
이 뉴스레터에서 "코드 리뷰가 병목"이라는 이야기를 했잖아요. 에이전트가 코드를 쏟아내는데 사람이 전부 리뷰할 수 없다고요. 그때는 "자동화에 투자하라"고 했는데, 구체적인 방법을 못 보여드렸어요.
이번 주에 Stavros Korokithakis라는 개발자가 자기 LLM 코딩 워크플로우를 아주 상세하게 공개했는데요. 이 사람이 정확히 그 문제를 풀고 있었어요. 그리고 핵심이 생각보다 단순해요.
같은 모델한테 리뷰시키지 마세요. 다른 모델한테 시키세요.
AI한테 자기 코드를 리뷰시키면 어떻게 되냐면요
한번 생각해보세요. 회사에서 코드 리뷰를 할 때, 자기가 짠 코드를 자기가 리뷰하면 어때요? 의미 없잖아요. 자기가 좋다고 생각한 방식으로 짰으니까, 리뷰해도 "좋은데요?" 하게 되잖아요.
LLM도 똑같아요.
Stavros가 관찰한 건 이거예요. 특정 모델을 하나의 "사람"으로 생각할 수 있대요. 컨텍스트를 초기화해도 같은 의견, 같은 강점, 같은 약점을 유지한대요. 그래서 Claude Opus한테 코드를 짜게 하고, 같은 Claude Opus한테 리뷰를 시키면 — 자기 동의 편향(self-agreement bias)이 발생해서 거의 무의미한 리뷰가 나온다는 거예요.
"It's fairly useless to ask a model to review the code it just wrote, as it tends to mostly agree with itself." — Stavros
이건 제 경험과도 정확히 맞아요. 예전에 Claude한테 코드를 짜게 하고, 같은 세션에서 "이 코드 리뷰해줘"라고 했더니 뭐라고 하는지 아세요? "잘 구조화되어 있고, 에러 핸들링도 적절하며, 코드 품질이 높습니다." 자기가 짠 코드를 칭찬하는 거예요. 새 세션으로 바꿔도 마찬가지였어요. 같은 모델이니까 같은 관점으로 보는 거예요.
근데 다른 모델한테 리뷰를 맡기면 달라진대요. Stavros가 쓰는 조합을 보면요.
| 모델 | 특성 | 역할 |
|---|---|---|
| Opus 4.6 | 판단이 저자와 잘 일치, 피드백 선별 우수 | 아키텍트 (계획) |
| Sonnet 4.6 | 토큰 효율적, 지시 따르기 좋음 | 개발자 (구현) |
| Codex 5.4 | 꼼꼼하고 까다로움 (pedantic) | 리뷰어 |
| Gemini 3 Flash | 다른 모델이 놓친 해법 제시 | 보조 리뷰어 |
Codex가 코드를 짰으면 Opus가 리뷰하고, Opus가 계획을 짰으면 Codex가 검증하는 거예요. 서로 다른 "눈"으로 보니까 서로 다른 문제를 잡는 거예요.
이건 인간 팀에서도 당연한 거잖아요. 코드 리뷰의 가치는 "다른 관점"에서 오는 거예요. 같은 사람이 같은 관점으로 보면 놓치는 게 있잖아요. 그래서 팀에서 리뷰를 다른 사람한테 맡기는 거고요. LLM도 마찬가지인 거예요.
아키텍트-개발자-리뷰어 패턴
Stavros의 워크플로우를 좀 더 들여다볼게요. 이 사람이 쓰는 구조가 꽤 체계적이에요.
인간 ←→ 아키텍트(Opus) → 개발자(Sonnet) → 리뷰어(Codex/Gemini)
↑ │
└──── 의견 불일치 시 에스컬레이션 ────────┘아키텍트(Opus)는 인간이랑 직접 대화하는 유일한 에이전트예요. 기능이나 버그 수정 목표를 제시하면, 최대 30분간 대화하면서 계획을 세워요. 목표, 제약, 트레이드오프를 확정할 때까지요. 결과물은 개별 파일과 함수 수준의 저수준 계획이에요.
이전 뉴스레터에서 Boris Tane의 Annotation Cycle을 다뤘잖아요. plan.md를 열어서 인라인 노트를 달고, 3번이나 돌려보내고, 만족할 때까지 다듬는 거요. Stavros의 아키텍트 단계가 정확히 같은 역할이에요. 형태만 다른 거예요. Boris Tane은 파일에 메모를 달고, Stavros는 채팅으로 대화하는 거예요.
그리고 Stavros가 한 가지 재밌는 트릭을 쓰는데요. 아키텍트한테 "approved"라는 단어를 명시적으로 말할 때까지 구현을 시작하지 마라고 설정해놨대요. 왜냐면 일부 모델이 "이제 이해한 것 같으니 시작하겠습니다!"라고 성급하게 착수하는 경향이 있거든요.
이건 이전 뉴스레터에서 다뤘던 Human-in-the-Loop 패턴이에요. "되돌릴 수 없는 결정 직전에 인간이 개입한다." Stavros는 그걸 "approved"라는 명시적 게이트로 구현한 거예요.
개발자(Sonnet)는 계획대로 구현만 해요. 재량의 여지가 최소화되어 있으니까, 약하고 저렴한 모델로 충분해요. 토큰 절약이 여기서 나오는 거예요.
리뷰어는 최소 Codex, 때로 Gemini, 중요한 프로젝트에는 Opus까지 추가해요. 각 리뷰어가 독립적으로 계획과 diff를 검토하고 비평해요. 피드백이 일치하면 개발자가 수정하고, 리뷰어 간 의견이 불일치하면 아키텍트(Opus)에게 에스컬레이션돼요. Opus가 피드백을 선별해서, 너무 pedantic한(구현 대비 실질적 문제 가능성이 낮은) 피드백은 무시하기도 한대요.
이거 인간 시니어 엔지니어가 하는 것과 똑같아요. 주니어 개발자 2명이 PR에서 의견이 갈릴 때, 시니어가 와서 "이건 이 쪽이 맞아, 이건 무시해도 돼"라고 판단하잖아요.
이 뉴스레터에서 다뤘던 것들이 전부 여기서 합쳐져요
여기서 좀 재밌는 게 보여요. 이전에 다뤘던 내용들이 이 워크플로우 안에서 전부 자리를 잡거든요.
계획 문서가 코드를 이긴다 (Boris Tane) → 아키텍트 단계에서 30분간 계획을 세우는 것. plan.md든 대화든, "코드를 짜기 전에 생각한다"는 원칙은 동일.
코드를 안 짜는 팀이 100만 줄을 만들었습니다 (OpenAI 하네스 팀) → 엔지니어가 코드를 짜는 대신 에이전트가 일할 환경을 만들었잖아요. Stavros도 마찬가지예요. 직접 코드를 안 읽지만, 모든 아키텍처 결정에 관여하고 있어요.
에이전트 하나면 됩니다 (OpenAI 가이드) → 여기서 반전이 있어요. Stavros는 멀티 에이전트를 쓰거든요. 근데 이전 뉴스레터에서 "같은 모델 + 같은 권한으로 분할하는 건 의미 없다"고 했잖아요. Stavros도 정확히 같은 말을 해요. 각 에이전트가 다른 모델, 다른 역할, 다른 권한을 가지니까 의미가 있는 거예요. 모델도 같고 역할도 같은데 이름만 다른 에이전트 3개? 그건 한 사람이 모자만 바꿔 쓰는 거와 다를 바 없어요.
코드가 싸졌는데 왜 더 어려워졌을까 (Simon Willison) → Stavros의 워크플로우가 이 질문에 대한 하나의 답이에요. 코드를 짜는 건 Sonnet한테 시키면 되니까 싸요. "좋은 코드"를 만드는 건 아키텍트 단계의 30분 대화 + 크로스 모델 리뷰로 품질을 보장하는 거예요. 간극을 메우는 구체적인 시스템인 거죠.
이 뉴스레터를 처음부터 읽어오신 분이라면 이런 패턴이 보이실 거예요. 매 편마다 다른 사람의 워크플로우를 다뤘는데, 결국 같은 원칙들이 계속 반복돼요. 계획을 먼저 세우고, 검증 루프를 돌리고, 코드보다 시스템에 투자하고, 인간이 판단의 주인이 되는 것. 도구랑 형태는 다 달라도 핵심은 같아요.
코드를 안 읽어도 시스템을 "소유"할 수 있어요
여기서 하나 짚어야 할 게 있어요.
Stavros가 이런 말을 해요.
"I've made all these projects with LLMs, and have never even read most of their code, but I'm still intimately familiar with each project's architecture and inner workings."
코드를 안 읽었는데 시스템을 잘 안다? 모순처럼 들리잖아요. "바이브 코딩"에 대한 가장 흔한 비판이 이거예요. "코드를 이해하지 못하면 결국 문제가 생긴다"는 거요.
근데 Stavros의 포인트는 "이해"의 단위가 바뀌었다는 거예요.
| 시기 | 리뷰 수준 | 인간이 알아야 하는 것 |
|---|---|---|
| LLM 초기 (davinci) | 모든 코드 라인 | 문법, 로직, 변수명 |
| 중기 | 함수 단위 | 함수의 역할, 인터페이스 |
| 현재 (Opus 4.6 등) | 아키텍처 수준 | 시스템 구조, 트레이드오프 |
예전에는 코드를 한 줄씩 읽어야 시스템을 이해할 수 있었어요. 지금은 함수 수준 이상의 모든 아키텍처 결정에 관여했다면, 코드를 한 줄도 안 읽어도 시스템을 "소유"할 수 있는 거예요. 왜? 모든 "왜"를 알고 있으니까요. "왜 이 구조를 선택했는지", "왜 이 방식을 버렸는지", "이 트레이드오프가 뭔지".
이전 뉴스레터에서 "코드를 안 짜는 팀이 100만 줄을 만들었습니다"를 다루면서, OpenAI 하네스 팀이 코드를 안 쓰면서도 시스템을 완전히 이해하고 있었다는 점을 강조했잖아요. Stavros도 같은 상태인 거예요. 코드를 직접 안 읽지만, 아키텍처를 직접 결정했기 때문에 시스템을 소유할 수 있는 거예요.
근데 여기서 중요한 전제 조건이 있어요.
모르면 망해요. 진짜로요.
Stavros가 가장 솔직하게 인정하는 부분이 이거예요.
기반 기술을 잘 아는 프로젝트(예: 백엔드)에서는 수만 SLoC에서도 문제가 없대요. 근데 잘 모르는 기술(예: 모바일 앱)에서는 여전히 잘못된 선택이 누적되면서 코드가 엉망이 된대요.
같은 사람이에요. 같은 LLM이에요. 같은 워크플로우예요. 결과가 극단적으로 다른 거예요.
왜? LLM이 잘못된 아키텍처 결정을 내렸을 때, 인간이 그걸 잡아줘야 하는데 — 잘 모르는 기술이면 잡아줄 수가 없는 거예요. 잘못된 결정 위에 더 많은 코드가 쌓이고, 결국 LLM도 풀 수 없는 상태에 도달해요.
Stavros가 이 실패 모드를 아주 생생하게 묘사해요.
"You know this happens when you keep telling the LLM the code doesn't work, it says 'I know why! Let me fix it' and keeps breaking things more and more."
이거 경험해보신 분 있을 거예요. "안 돼" → "아, 알겠습니다! 고치겠습니다!" → 더 망가짐 → "아직도 안 돼" → "이번에는 확실히!" → 더더 망가짐. 이 루프에 빠지면 답이 없어요. git reset밖에 방법이 없어요.
이전 뉴스레터에서 "코드가 싸졌는데 왜 더 어려워졌을까"를 다루면서, 코드베이스 품질이 에이전트 성능을 결정한다고 했잖아요. Stavros의 관찰은 거기서 한 걸음 더 나가요. 코드베이스 품질뿐 아니라 인간의 도메인 지식도 에이전트 성능의 결정적 변수라는 거예요.
그래서 Stavros의 대응이 뭐냐면요. 익숙하지 않은 기술이라도 계획 단계에서 가능한 한 많이 이해하려고 노력한대요. LLM한테 질문하면서 핵심 개념, 트레이드오프, 일반적 패턴을 파악하는 거예요. 완전히 이해할 필요는 없어요. 잘못된 결정을 "감지"할 수 있을 정도면 충분해요. 감지 → 교정 루프가 작동하면 누적을 방지할 수 있거든요.
이건 이전 뉴스레터에서 계속 강조한 "코드를 짜기 전에 얼마나 생각했느냐"의 또 다른 버전이에요. Boris Tane의 Annotation Cycle도, Stavros의 30분 대화도, OpenAI 하네스 팀의 스캐폴딩 설계도 — 전부 "먼저 이해하고, 그 다음에 실행한다"예요.
스킬 파일은 AI한테 쓰게 하면 안 돼요
하나 더 인상 깊었던 게 있어요.
요즘 "CLAUDE.md를 AI한테 생성시켜라"는 조언이 꽤 돌아다니잖아요. "프로젝트를 분석해서 CLAUDE.md를 만들어줘"라고 시키면 편하니까요.
Stavros는 이거에 대해 아주 단호해요.
"It would be like asking someone to write up instructions on how to be a great engineer and then gave them their own instructions and said 'here's how to be a great engineer, now be one'. It obviously won't really make them better."
누군가한테 "훌륭한 엔지니어가 되는 법"을 쓰게 하고, 그 지침을 돌려주면서 "자, 이제 훌륭해져라"고 하는 거와 같다는 거예요. 당연히 안 되죠.
이게 왜 그러냐면요. LLM이 스킬 파일을 쓰면, 자기가 이미 알고 있는 것의 재진술에 불과해요. 새로운 제약이나 방향을 제공하지 못해요. 진짜 효과적인 스킬 파일은:
- LLM의 기본 행동과 다른 것을 지시해야 해요 (기본 행동과 같으면 redundant)
- 프로젝트 특유의 맥락을 포함해야 해요 (범용적 조언은 이미 학습됨)
- 구체적 예시와 반례가 있어야 해요 (추상적 원칙은 해석의 여지가 큼)
이건 이전 뉴스레터에서 "AGENTS.md는 백과사전이 아니라 목차다"를 다루면서 한 이야기와 보완 관계예요. AGENTS.md의 "형태"도 중요하지만, "누가 쓰느냐"도 중요하다는 거예요. 인간의 암묵지(tacit knowledge) — "이 프로젝트에서는 이렇게 해야 해", "이건 하면 안 돼" — 를 명시적으로 변환하는 건 LLM이 할 수 없어요. 인간만 할 수 있어요.
솔직히 이렇게 느꼈습니다
이 글이 제가 지금까지 뉴스레터에서 다뤘던 것들의 퍼즐 조각이 맞춰지는 느낌이었어요.
Simon Willison이 "코드는 싸졌지만 좋은 코드는 비싸다"는 프레임을 줬잖아요. Boris Tane이 "계획 문서로 그 간극을 메운다"는 방법을 보여줬고요. OpenAI 하네스 팀이 "스캐폴딩으로 에이전트가 일할 환경을 만든다"는 조직 수준의 답을 줬고요.
Stavros가 추가한 건 "크로스 모델 리뷰"예요. 계획 → 구현 → 검증 루프에서, 검증 단계를 다른 모델이 하게 해서 자기 동의 편향을 깨는 거예요.
이걸 합치면 이런 그림이 돼요.
| 단계 | 누가 하는가 | 뉴스레터에서 다룬 곳 |
|---|---|---|
| 계획 | 인간 + 강한 모델 (대화) | Boris Tane, Stavros |
| 구현 | 저렴한 모델 | Stavros, Simon Willison |
| 코드 검증 (테스트) | 다른 세션의 에이전트 | Writer/Reviewer, StrongDM |
| 코드 검증 (리뷰) | 다른 모델의 에이전트 | 이번 편 |
| 환경 설계 | 인간 | OpenAI 하네스 팀 |
이게 복리예요. 매 편마다 하나씩 쌓이고 있는 거예요.
동시에 솔직한 우려도 있어요. 이 워크플로우가 효과적이려면 도메인 지식이 있어야 한다는 전제가 있잖아요. 잘 모르는 기술에서는 똑같이 망한다는 거요. 이건 "LLM을 잘 쓰려면 먼저 기반 기술을 알아야 한다"는 메시지인데, 요즘 "코딩 몰라도 AI로 다 할 수 있다"는 분위기와 정면으로 충돌해요.
근데 이게 맞는 것 같아요. 도구가 강력해질수록 도구를 조종하는 능력이 중요해진다는 건 어떤 분야에서든 마찬가지니까요. F1 자동차가 빠를수록 드라이버의 실력이 더 중요하듯이요.
오늘 바로 해보세요
1. 같은 모델 리뷰를 멈추고 다른 모델로 바꿔보세요 (5분)
다음에 AI한테 코드를 짜게 한 후, 같은 모델한테 "이 코드 리뷰해줘"라고 하지 마세요. 다른 모델을 쓰세요.
Claude로 짰으면 → GPT나 Gemini로 리뷰. OpenCode나 Pi 같은 멀티모델 하네스를 쓰면 쉬워요. 아니면 웹 UI라도 괜찮아요. 코드를 복사해서 다른 모델한테 "이 코드의 문제점을 찾아줘"라고 해보세요. 같은 모델한테 했을 때와 결과가 다를 거예요.
2. "approved" 게이트를 CLAUDE.md에 추가하세요 (1분)
- 구현 계획을 세운 후, 내가 명시적으로 "approved"라고 말할 때까지 코드를 작성하지 마라
- 계획을 세운 후 반드시 나의 확인을 기다려라이 두 줄이면 돼요. 에이전트가 계획을 세우자마자 성급하게 구현에 착수하는 걸 막아줘요. 계획을 검토하고 교정할 시간을 확보하는 거예요.
3. 도메인 지식 자가 진단 해보세요 (3분)
지금 AI로 작업하고 있는 프로젝트에서, 이 질문에 답해보세요:
- LLM이 잘못된 아키텍처 결정을 내렸을 때, 내가 잡아낼 수 있는가?
- 이 기술 스택의 일반적인 패턴과 안티패턴을 알고 있는가?
- LLM이 제안한 방식이 왜 좋거나 나쁜지 판단할 수 있는가?
"아니요"가 하나라도 있으면, 코드를 짜기 전에 LLM한테 그 기술에 대해 질문부터 하세요. "이 기술의 핵심 트레이드오프가 뭐야?", "이 아키텍처 패턴의 장단점이 뭐야?" 30분 투자하면 나중에 "고쳐줘 → 더 망가짐" 루프를 예방할 수 있어요.
마무리
이 뉴스레터를 쓰면서 계속 느끼는 건데요. 결국 AI 코딩의 핵심은 "어떤 도구를 쓰느냐"가 아니라 "인간이 어디에 개입하느냐"인 것 같아요.
계획에 개입하고 (Boris Tane), 환경을 설계하고 (OpenAI 하네스 팀), 다른 모델로 검증하고 (Stavros), 도메인 지식으로 교정하고. 코드를 타이핑하는 것 빼고 전부 인간의 몫이에요. 그리고 그 "전부"가 점점 더 가치 있어지고 있어요.
제 강의에서 "설계하고, 시키고, 검증하라"를 핵심으로 다루는데요. Stavros의 글을 읽고 나니까 "검증"의 깊이가 한 단계 더 깊어져야 한다는 걸 느꼈어요. 테스트 돌리는 것만이 검증이 아니라, 다른 관점의 눈으로 보게 하는 것까지가 검증인 거예요.
레퍼런스
- How I write software with LLMs — Stavros Korokithakis. 아키텍트-개발자-리뷰어 다중 에이전트 워크플로우와 실제 코딩 세션 전체 공개
의견을 남겨주세요