엉클 밥과 에이전트 Part 1: 코드를 읽지 않는 이유

이 글은 Claude Opus 5.5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity.”

2026년 7월 23일, Robert C. Martin 이 X 에 남긴 답글입니다. 엉클 밥이라는 별명으로 더 알려진 사람, 『Clean Code』 와 『The Clean Coder』 를 쓰고 TDD 를 수십 년 설파해 온 바로 그 사람입니다. 자기가 책임질 코드라면 이해해야 하지 않느냐는 질문에 그는 1960년대 말부터 코드를 짰다는 말로 답을 시작했고, 읽지 않는 대신 에이전트를 “extreme constraints” 로 둘러싼다고 덧붙였습니다. 그가 든 제약은 단위 테스트, Gherkin 테스트, QA 절차, 품질 지표, 뮤테이션 테스트, 테스트 커버리지 같은 것들입니다. 그는 이 관문을 통틀어 “gauntlet” 이라고 부릅니다.

저는 그의 책을 읽었고 TDD 를 실천해 본 사람이라 이 문장이 처음엔 농담처럼 읽혔습니다. 그런데 지난 Pi 시리즈를 쓰면서 그가 만든 swarm-forge 를 잠깐 들여다보고 나니 궁금한 게 많아졌습니다. 이 방식을 팀에 들일 만한가. AGENTS.md 나 CLAUDE.md 에 그의 규칙을 자세히 적어 두면 같은 효과가 나는가. 그리고 이 주장을 어디까지 믿어야 하는가. 이 시리즈는 그 세 질문을 따라가고, 이 편에서는 먼저 그가 무엇을 했고 왜 그렇게 하는지를 봅니다.

열 달 동안 한 일#

그의 GitHub 와 X 를 시간순으로 놓고 보면 방식이 몇 달 단위로 바뀌어 왔습니다. 처음에는 Claude Code 를 혼자 붙잡고 있다가, 검사 도구를 직접 만들고, 여러 에이전트를 묶는 도구를 만들었다가, 10월에는 다시 에이전트 하나로 돌아갔습니다.

이 열 달의 경험을 그는 Justin Martin 과 함께 cleancoders.com 의 「Clean AI: Agentic Discipline」 이라는 영상 연재로 정리하고 있습니다. 1화 소개문의 첫 문장이 이 방식 전체의 문제의식입니다. “The greatest danger of using AI agents is to use an undisciplined approach.” 강력한 도구를 규율 없이 쓰면 되돌리기 어려운 난장판이 된다는 경고입니다. 그래서 이름이 vibe 가 아니라 discipline 입니다.

코드 대신 읽는 것#

그가 코드를 읽지 않는다고 해서 아무것도 보지 않는 건 아닙니다. 읽는 대상이 코드 한 층 위로 올라갔습니다. 2화 소개문은 이렇게 씁니다. “When using AI agents, code cannot be the source because it has become the domain of the AI.” 시스템을 다시 만들 수 있는 원본, 즉 source 는 이제 코드가 아니라 사람이 쓰는 더 높은 수준의 문서여야 한다는 겁니다. 2화에서 그는 문서 하나만 원본으로 삼아 같은 시스템을 다섯 개 언어와 플랫폼으로 만들어 보였다고 합니다.

그 문서의 중심에 Gherkin 이 있습니다. Given/When/Then 으로 쓴 인수 테스트입니다. 그가 5월에 공개한 Acceptance-Pipeline-Specification 은 이 Gherkin 을 JSON 중간 표현으로 바꾸고, 그걸로 실행 가능한 테스트를 생성해 돌리는 파이프라인을 에이전트가 프로젝트에 직접 설치하게 하는 명세입니다. 여기에 한 단계가 더 붙습니다. Gherkin 의 예시 값을 일부러 바꿔 보고 테스트가 실패하는지 확인하는 인수 테스트 뮤테이션입니다. 시나리오에 적힌 값이 실제로 프로그램과 연결돼 있는지, 그냥 장식으로 붙어 있는지를 가려내려는 장치입니다.

에이전트가 쓴 코드는 그 아래에서 검사 도구들이 지킵니다. 7월의 답글에 나온 목록이 곧 그의 관문입니다. 단위 테스트는 TDD 로 먼저 쓰고, 인수 테스트와 QA 절차는 명세에서 나오고, 그 위에 품질 지표와 뮤테이션 테스트가 얹힙니다. 그는 10월에 이 과정을 이렇게 묘사했습니다. 에이전트와 시스템을 이야기하면 에이전트가 명세를 쓰고, 자기라면 일주일 걸렸을 시스템을 한두 시간에 짓고, 그다음 crapper·dryer·mutator 검사를 돌리게 하면 “dozens of bugs, oversight, dead code” 를 찾아낸다는 것입니다.

세 개의 검사 도구#

관문의 핵심인 세 도구는 모두 오래된 아이디어를 에이전트 시대에 맞게 다시 쓴 것입니다.

CRAP 점수는 2007년 Alberto Savoia 가 동료 Bob Evans 와 함께 Artima 블로그에 발표한 지표입니다. 함수의 순환 복잡도(CC)와 테스트 커버리지를 하나로 묶습니다.

CRAP = CC² × (1 − coverage)³ + CC

복잡한 함수가 테스트로 덮여 있지 않을수록 점수가 가파르게 오릅니다. 분기 19개짜리 함수가 커버리지 32% 라면 132점이 넘고, 같은 함수를 테스트로 다 덮으면 19점, 복잡도 4짜리 함수들로 쪼개 다 덮으면 4점이 되는 식입니다. 엉클 밥의 저장소들은 이 점수에 문턱을 겁니다. empire-2025 의 AGENTS.md 는 8 이하, swarm-forge 의 정리 담당 에이전트는 10 이하입니다. 10월 11일의 게시물을 보면 이 문턱을 사람과 에이전트에게 다르게 둡니다. 자기 코드는 순환 복잡도를 4 정도로 제한하지만 에이전트에게는 10까지 허용한다고 했습니다. 에이전트는 단기 기억이 사람보다 크고 정확해서 그 정도는 감당하는 것 같다는 가설도 덧붙였습니다.

뮤테이션 테스트는 코드를 일부러 망가뜨려 보는 검사입니다. > 를 >= 로, + 1 을 - 1 로 바꾼 돌연변이를 하나씩 만들고 테스트를 돌려서, 어떤 테스트든 실패하면 그 돌연변이는 죽은(killed) 것이고 모든 테스트가 그대로 통과하면 살아남은(survived) 것입니다. 살아남은 돌연변이는 그 동작을 어떤 테스트도 붙잡고 있지 않다는 뜻입니다. 커버리지가 100% 여도 단언(assert)이 허술하면 돌연변이는 살아남습니다. 에이전트가 통과만 하는 약한 테스트를 쓰는 버릇을 잡는 데 이만한 도구가 드뭅니다.

중복 검사(DRY)는 함수의 구조를 정규화해 비교합니다. 변수 이름과 리터럴을 지우고 호출과 연산자, 트리의 모양만 남긴 지문이 얼마나 겹치는지 보는 방식이라, 이름만 바꿔 복사한 코드를 찾아냅니다.

그는 9월 말에 이 셋을 Clojure·Java·Go·TypeScript·Rust·Python 을 다루는 crapper·mutator·dryer 로 일반화해 공개했습니다. 흥미로운 건 10월 10일 게시물의 당부입니다. 이 도구들을 그대로 쓰지 말고, 에이전트에게 템플릿으로 보여 줘서 각자 필요에 맞는 도구를 만들게 하라고 했습니다. 라이선스도 조건이 없는 0BSD 로 풀었습니다. 도구 자체도 에이전트가 만드는 것이라는 전제가 깔려 있는 셈입니다.

규칙을 프롬프트에서 도구로#

이런 도구가 왜 필요했는지는 개발자 Alex Rusin 이 8월에 정리한 글에 나옵니다. 엉클 밥은 처음에 TDD 와 클린 코드 규칙을 프롬프트로 설명했는데, 그 문서가 5~10쪽까지 불어나자 모델이 규칙을 규칙이 아니라 가이드라인처럼 다루더라고 합니다. 그 원인을 그는 긴 컨텍스트의 가운데가 흐려지는 “lost in the middle” 현상으로 봤고, 프롬프트를 줄이는 대신 규칙을 지키게 하는 일을 결정론적 도구로 옮겼다고 합니다. 다만 Rusin 은 출처를 밝히지 않았고, 저는 이 이야기를 엉클 밥 본인의 글이나 저장소에서 찾지 못했습니다. 그가 실제로 한 일, 즉 짧은 역할 프롬프트와 도구 문턱을 보면 이 설명과 어긋나지는 않습니다.

여기서 짚어 둘 것이 있습니다. “Lost in the Middle” 은 2023년에 나와 2024년 TACL 에 실린 Nelson Liu 등의 논문으로, 긴 문서 가운데에 있는 정보를 모델이 덜 찾아낸다는 검색 실험입니다. 규칙을 얼마나 지키는지를 잰 연구는 아닙니다. 규칙 파일이 실제로 어떻게 작동하는지에 대한 2026년의 연구들은 3편에서 따로 봅니다. 결론부터 말하면 엉클 밥의 경험과 크게 다르지 않습니다.

역할을 나눠 맡긴 에이전트들#

도구만으로는 부족하다고 본 그가 다음에 한 일은 일을 쪼개는 것이었습니다. 한 에이전트에게 명세부터 구현, 정리, 뮤테이션까지 다 맡기면 컨텍스트가 금세 차니까, 역할마다 좁은 에이전트를 두고 일을 사슬처럼 넘기는 방식입니다. 시작은 소박했습니다. 1월에는 Claude 창 두 개를 서로 다른 클론에 띄워 하나는 계획만, 하나는 코드 수정만 맡겼고, empire-2025 저장소의 로컬 규칙 파일에는 worktree 다섯 개(본체, research, review, reviewer, planner)와 함께 “Never execute a plan until it has been marked reviewed.” 라는 규칙이 적혀 있습니다. Agentic Discipline 3화에서는 에이전트 네 개가 함께 큰 애플리케이션을 짓는 모습을 보였고, 5화에서는 architect·integrator·coder 세 에이전트로 swarm-forge 자체를 만들기 시작했습니다.

4월에 공개한 swarm-forge 는 이 분업을 팩(pack)이라는 이름으로 굳혔습니다. two-pack 은 coder 와 cleaner, four-pack 은 specifier → coder → refactorer → architect, six-pack 은 specifier → coder → cleaner → architect → hardener → QA 순서로 일을 넘깁니다. 역할 프롬프트마다 맡는 일(Owns)과 하지 않는 일(Does Not Own)이 적혀 있는데, 핵심은 오히려 뒤쪽입니다.

coder 는 자기 코드의 CRAP 을 재지 않고, refactorer 는 동작을 바꾸지 못하며, QA 는 API 를 거치지 않고 화면으로만 확인합니다. 저장소에는 이런 분업을 Go 로 시험한 기록도 있습니다. 6월의 experiment-htw-go-swarm 은 Codex 에이전트 네 개(specifier, coder, refactorer, architect)로 Hunt the Wumpus 를 Go 로 만든 실험이고, 여기서 refactorer 에게는 CRAP 을 6 이하로 낮추라고 요구했습니다. 역할을 나누는 이유를 그는 주로 컨텍스트로 설명하지만, 프롬프트를 나란히 놓고 보면 어느 역할도 자기 작업을 자기가 검사하지 않게 하려는 설계로도 읽힙니다. 이 부분은 제 해석입니다.

그런데 10월 16일, Agentic Discipline 7화 소개문에서 그는 방향을 틀었습니다. 몇 달 전만 해도 큰 작업에는 swarm-forge 같은 하네스의 규율이 필요했지만, 모델이 크게 바뀌어 이제는 에이전트 하나가 큰 일을 해낸다는 판단입니다. “So it’s time to step away from the swarm-forge harness and look at a disciplined approach to using a single agent to get such large tasks done.” 버리는 건 하네스지 규율이 아닙니다. 같은 소개문은 Crap·Mutate·Dry 도구의 새로운 변형과, 에이전트가 만든 것을 코드 바로 위 수준에서 살피는 도구를 다룬다고 예고합니다. 그가 9월에 공개한 uml-viewer 가 모듈과 의존 관계를 그리고 각 모듈을 CRAP·뮤테이션 점수로 색칠하는 도구니까, 코드를 안 읽는 대신 그 지도를 읽는 셈입니다. 3편에서는 그가 옮겨 간 단일 에이전트 방식과 그 전의 역할 분담을 Claude Code 와 Codex 로 각각 흉내 내 봅니다.

사람의 리뷰를 무엇이 대신하나#

코드를 읽지 않는다는 말이 아무도 검토하지 않는다는 뜻은 아닙니다. 사람이 하던 코드 리뷰를 역할 사슬의 뒤쪽이 나눠 맡습니다. 이름과 중복과 함수 크기는 cleaner 나 refactorer 가, 모듈 경계와 의존 방향은 architect 가, 테스트가 정말 동작을 붙잡고 있는지는 hardener 가, 사용자가 보는 동작은 QA 가 봅니다. 6월 14일에 swarm-forge 의 실험 브랜치로 추가된 adversaries 는 이걸 더 노골적으로 보여 줍니다. 구성은 Codex 에이전트 둘, coder 와 reviewer 입니다. reviewer 의 프롬프트는 사람 리뷰어의 점검표와 다르지 않습니다. 코드와 테스트와 커밋 이력을 읽고, 이름·제어 흐름·중복·오류 처리·경계 조건과 의존 방향을 보고, coder 가 TDD 를 했는지 확인하고, CRAP 과 중복 검사를 직접 돌립니다. 제품 코드는 고치지 못하고 review/ 아래의 권고 파일만 쓸 수 있으며, 만족하면 review/approval.md 를 남기고 끝냅니다. 프롬프트에는 “Be adversarial but concrete: every recommendation must name the issue, the risk, and the expected change.” 라고 적혀 있습니다. 코드 리뷰를 없앤 것이 아니라 에이전트에게 넘긴 셈입니다.

그 대신 테스트가 평소보다 훨씬 엄격합니다. 단위 테스트는 TDD 로 먼저 쓰고, 인수 테스트는 사람이 승인한 Gherkin 에서 생성하며, 그 Gherkin 의 예시 값까지 뮤테이션으로 흔들어 명세가 실제 코드에 연결돼 있는지 확인합니다. 코드 뮤테이션은 살아남은 돌연변이를 남기지 않는 것이 목표이고, 구조 담당은 property test 로 넓은 입력 범위를 덮고, QA 는 명세에 적힌 절차를 스크립트로 바꿔 화면으로만 돌립니다. CRAP 문턱은 저장소마다 6(Go 실험), 8(empire-2025), 10(swarm-forge)으로 다릅니다.

사람에게 남는 일도 분명히 있습니다. 시스템을 에이전트와 이야기해 명세를 만들고, 명세가 확정되는 지점에서 승인하고, 에이전트의 질문에 답하고, 코드 대신 uml-viewer 같은 지도를 봅니다. 9월 24일 Aviator 채널에 올라온 인터뷰 소개문이 이 구도를 요약합니다. 그의 말로 인용된 문장은 “My working hypothesis is that human beings are too slow when dealing with code. If we’re going to move at the speed of the agents, we’re all going to have to back off a little bit and maintain high-level supervision.” 이고, 소개문은 코드 리뷰가 팀을 느리게 만든다는 주장과 함께 에이전트가 만든 것에 책임질 수 있는 건 사람뿐이라는 이야기를 다룬다고 적었습니다. 장(chapter) 제목에는 “Human judgment as the final arbiter” 와 “Architecture diagrams as a review surface” 가 있습니다. 사람은 줄 단위 리뷰에서 손을 떼고, 명세와 구조도와 최종 판단을 붙잡는 셈입니다.

그가 스스로 보여 준 대가#

엉클 밥은 자기 도구의 한계도 직접 실험으로 남겼습니다. 8월의 negative-test-experiment 에서 그는 Hunt the Wumpus 라는 고전 게임을 빈 디렉터리에서 여덟 번 만들었습니다. TDD 의 세 법칙을 따르거나, 테스트를 나중에 쓰거나, 함수마다 테스트를 묶거나, 아예 쓰지 않는 방식에 CRAP 을 4 미만으로 강제하느냐 마느냐를 곱한 조합이고, 여덟 개 모두 같은 인수 테스트 25개를 통과했습니다.

결과 요약의 결론은 이렇습니다. “CRAP buys coverage and spends cleanliness. It does not improve design.” CRAP 을 강제하자 프로그램이 331~396줄에서 478~603줄로, 함수가 33~52개에서 86~118개로 늘었습니다. 커버리지는 올랐지만 함수가 잘게 부서져 읽기는 더 어려워졌고, 설계가 나아지지는 않았다는 게 그의 평가입니다. 인수 테스트는 이 차이를 하나도 구별하지 못했습니다.

이 실험이 제게 가장 크게 다가온 이유가 있습니다. Claude Code 나 Codex 로 일하면서 제가 가장 아쉬웠던 게 코드가 장황하고 복잡하다는 것, 그리고 사람이 리뷰할 양이 너무 많다는 것이었기 때문입니다. 그런데 엉클 밥의 지표를 문턱으로 걸면 코드는 오히려 길어질 수 있다는 겁니다. 그가 코드를 안 읽는다면 이건 문제가 아니지만, 팀에서 사람이 리뷰하는 코드라면 문제가 됩니다.

바깥의 반응도 같은 지점을 찌릅니다. “코드를 읽지 않는다” 는 게시물이 Hacker News 에 올라왔을 때 달린 질문 가운데 하나가 “Does he read his tests and constraints?” 였습니다. 코드를 안 읽는다면 테스트와 제약은 누가 읽고 검증하느냐는 물음입니다. 그보다 앞선 5월, 그의 발언을 옮긴 Reddit 글 「Uncle Bob: It’s Over」 가 Hacker News 에 올라왔을 때는 함수를 잘게 쪼개 주는 에이전트를 두고 “a morass of tiny functions. Well tested (CRAP says so!)” 라는 비아냥이 달렸습니다. 그가 석 달 뒤 자기 실험으로 확인한 바로 그 현상입니다.

받아들일 것과 미룰 것#

정리해 보면 그의 방식에서 그대로 가져가고 싶은 게 둘 있습니다. 하나는 사람의 검토를 코드 한 줄 한 줄에서 검증 장치로 옮기는 발상입니다. 에이전트가 하루에 쓰는 코드를 사람이 다 읽는 건 이미 불가능에 가깝고, 그렇다면 읽지 않아도 믿을 수 있는 근거를 만드는 데 시간을 쓰는 게 맞습니다. 다른 하나는 그 근거를 프롬프트가 아니라 결정론적 도구에 두는 것입니다. 뮤테이션 테스트는 특히 에이전트가 쓴 테스트의 허술함을 기계적으로 드러내 줍니다.

미루고 싶은 건 “코드를 읽지 않는다” 를 팀의 규칙으로 삼는 일입니다. 그의 실험은 대부분 혼자 만드는 게임과 도구, 자기가 쓸 프로그램이었고 언어도 주로 Clojure 였습니다. 운영 장애를 같이 받고, 남이 고칠 코드를 리뷰하고, 규정 때문에 변경 이력을 사람이 설명해야 하는 팀과는 조건이 다릅니다. 그리고 그 자신이 보여 줬듯 지표를 문턱으로 걸면 지표에 맞춘 코드가 나옵니다. 그가 7화에서 말한 “코드 바로 위 수준” 의 검토가 무엇인지, 그 수준에서 사람이 무엇을 읽어야 하는지가 아직 그의 공개 자료로는 분명하지 않습니다.

자료에 대해#

엉클 밥의 발언은 그의 X 게시물(fxtwitter API 로 원문 확인)과 cleancoders.com 의 Agentic Discipline 1~7화 소개문, GitHub 저장소에 기댔습니다. 영상 본편은 유료라 보지 못했고, 1~6화의 공개일은 확인하지 못했습니다. 1월의 Claude 창 두 개 이야기는 Chris Rickard 가 LinkedIn 에 옮긴 게시물 화면으로 확인했습니다. 5~10쪽짜리 규칙 문서와 “lost in the middle” 이야기는 Alex Rusin 의 글에만 있고 그 글은 출처를 밝히지 않았습니다. 줄 수와 함수 수는 negative-test-experiment 저장소의 결과 요약을 옮긴 것이고, 저장소 날짜는 GitHub API 의 생성일입니다. 역할별 맡는 일과 하지 않는 일은 swarm-forge 의 four-pack·six-pack·adversaries 브랜치와 experiment-htw-go-swarm 저장소의 역할 프롬프트를 옮겨 줄인 것입니다. Aviator 인터뷰는 영상 소개문과 장 제목만 읽었고, 그 소개문 가운데 그의 말로 인용된 문장 외에는 게시자의 요약입니다. Hacker News 반응은 댓글 일부를 고른 것이라 여론의 대표값이 아닙니다.

References#

최신 자료 (2026)

• Robert C. Martin, X 게시물 2080257779395154409 (2026-07-23) · 2108914390980342164 (2026-10-10) · 2109397613082563048 (2026-10-11) · 2111161176831021418 (2026-10-16) · 2112921741689237915 (2026-10-21) [본인 발언]
• Justin Martin · Robert C. Martin, 「Clean AI: Agentic Discipline」 1~7화 소개문, cleancoders.com (7화 2026-10-16) [본인 영상 소개]
• Robert C. Martin, GitHub 저장소 empire-2025 · Pharaoh · swarm-forge · Acceptance-Pipeline-Specification · negative-test-experiment · crapper · mutator · dryer · uml-viewer (조회 2026-10-24) [본인 저장소]
• Robert C. Martin, swarm-forge four-pack·six-pack·adversaries 브랜치 역할 프롬프트 · experiment-htw-go-swarm (2026-06-02 생성) (조회 2026-10-24) [본인 저장소]
• Aviator, 「Uncle Bob: Why I Stopped Reading Code and Building Harnesses」 (2026-09-24) [인터뷰 영상 소개문]
• Alex Rusin, 「How Uncle Bob Uses AI Coding Agents」 (2026-08-20) [제3자 정리]
• Chris Rickard, LinkedIn 게시물 (2026-01-29) [제3자 서술]
• Hacker News, 스레드 49074693 (2026-07-27) · 스레드 47998601 (2026-05-03) [커뮤니티 반응]

비교·배경 자료 (2007~2024)

• Alberto Savoia, 「Pardon My French, But This Code Is C.R.A.P. (2)」, Artima (2007-07-19) [개인 글]
• Nelson F. Liu 외, 「Lost in the Middle: How Language Models Use Long Contexts」, TACL 12 (2024) [논문]