마지막 장은 방법이 아니라 질문을 다룬다. 인간이 loop의 어디에 서야 하는가, 하네스를 설계할 판단력은 어디서 오는가, 그리고 그 판단력이 자라는 토양이 마르면 무슨 일이 벌어지는가.
Martin Fowler 팀의 Kief Morris가 그림 하나를 그렸다 — AI 코딩에서 인간의 위치를 세 층으로 나눈 것이다.
agent의 출력을 한 줄씩 심사하고, 마음에 안 드는 코드를 손으로 고친다. 모든 것이 손을 거친다.
코드 자체를 보지 않고 하네스를 만들고 개선한다 — 명세, 품질 검사, 워크플로 유도. 고삐를 관리하고 말의 다리는 관여하지 않는다.
원하는 것만 말하면 agent가 알아서 해낸다. Vibe coding.
On the loop는 더 나은 작업 방식처럼 들린다. 반복 노동 대신 시스템 자체를 개선하는 것이니까. 그러나 여기에 성가신 문제가 있다. 인간을 너무 일찍 on the loop로, 심지어 out of the loop로 옮기면, 장래에 누가 하네스를 설계하는가. Morris의 원래 표현 — 신입이 첫날부터 코드의 세부를 만지지 않고 고층에서 agent만 조작한다면, 하네스에 문제가 생겨 저층에서 무슨 일이 벌어졌는지 이해할 사람이 필요할 때, 누가 하는가.
이 우려는 근거 없는 것이 아니다. Shopify는 인턴 프로그램을 25명에서 1,000명으로 확대했다 — 인턴들이 AI를 쓰는 방식이 더 흥미롭다는 이유였다. Block은 AI로 인한 효율 향상을 이유로 40%를 감원했다. 두 개의 방향, 하나의 문제 — 중간층이 사라지고 있다.
Ghostty의 하네스를 잘 쓸 수 있는 이유 — 터미널 에뮬레이터의 모든 세부를 이해하기 때문이다. 설정 파일의 모든 줄이 agent의 과거 실수 하나에 대응하며, 그는 그 실수들이 왜 실수인지를 안다.
100만 라인의 산출을 부릴 수 있는 이유 — 어떤 아키텍처가 좋은지, 무엇이 3개월 뒤에 터지는지를 알기 때문이다.
TDD 주도의 CLAUDE.md를 쓸 수 있는 이유 — 극한 프로그래밍을 발명했고 좋은 코드가 무엇인지 수십 년을 이해해 왔기 때문이다. 처음 두 번은 복잡도 누적으로 AI가 완전히 갇혀 실패했고, 세 번째에야 올바른 개입 방식을 찾았다.
좋은 하네스를 설계하는 사람들은 모두 깊은 도메인 경험을 갖고 있다. 문제는 그 경험이 어디서 오는가다.
저자는 코드를 손으로 써 본 적이 없다. 모든 제품이 AI가 쓴 것이다. 小猫补光灯은 AppStore 유료 앱 1위에 올랐고 누적 사용자는 백만을 넘겼다. 저자의 하네스는 제로에서 시작해 AI와의 상호작용 속에서 조금씩 자라났으며, 이전할 프로그래밍 경험은 전혀 없었다. 그러나 스스로에게 정직해야 한다.
저자가 하네스를 설계할 수 있는 것은 타고난 시스템 설계 감각 때문이 아니다. AI와 협업한 수천 시간 동안 그 행동 패턴을 관찰했기 때문이다. 언제 게으름을 피우는지, 언제 환각을 일으키는지, 언제 부드러운 당부가 아니라 하드 제약이 필요한지. 이 판단력은 코드 작성 경험이 아니라 다른 경험 — AI와 반복해서 씨름한 경험 — 에서 온다.
문제는 — 이런 경험을 가르칠 수 있는가. 저자의 답: 말할 수 없다.
CLAUDE.md를 어떻게 쓰는지는 알지만, 왜 그렇게 쓰는지를 남에게 가르치라 하면 막힌다. 많은 결정이 직관으로 이뤄진다. 직관은 구덩이를 밟는 데서 오고, 구덩이는 대량의 반복에서 오고, 대량의 반복은 시간에서 온다. 노련한 프로그래머의 「몇만 줄을 쓰면 자연히 안다」와 사실 같은 이야기다.
그러므로 문제는 「코드 작성 경험」이 대체 가능한가가 아니다. 어떤 경험을 축적하든, 충분히 많은 경험 그 자체가 하네스 설계의 전제라는 것이다. 지름길은 없다. 트랙을 바꿨을 뿐이다.
고통의 형태는 변했다. 고통의 총량은 아마 변하지 않았다.
어쩌면 Martin Fowler가 걱정하는 것은 「아무도 코드를 쓰지 않는다」가 아니라 — 「아무도 충분한 시간을 들여 충분한 구덩이를 밟으려 하지 않는다」일지 모른다.
엔지니어는 업무의 60%에서 AI를 쓰지만 완전히 위임할 수 있는 과제는 0–20%뿐이다. 그 사이의 40–60%가 인간과 AI가 협업하는 지대다. 판단력이 자라는 토양이다.
Karpathy는 이미 몸으로 실천하고 있다. 2025년 12월부터 코드를 손으로 쓰지 않는다. 그의 AutoResearch 프로젝트 — 630줄의 코드에 markdown prompt 하나 — 는 이틀간 700회의 실험을 돌렸다. 한 사람에 하네스 한 벌이 팀의 몇 주치 작업량을 해냈다.
그러나 Karpathy가 이렇게 할 수 있는 것은 그가 Karpathy이기 때문이다. 어떤 실험이 돌릴 가치가 있는지, 어떤 결과를 추적할 가치가 있는지, 어떤 발견이 소음인지를 안다. 그 markdown prompt가 유효한 이유는 그것을 쓴 사람에게 수십 년의 연구 직관이 있기 때문이다.
그 토양이 전면 자동화로 말라 버린다면? — 저자는 답을 모른다고 쓴다.
저자가 아는 것은 자신의 하네스가 수천 시간의 씨름 속에서 자라났다는 것뿐이다. 하네스 설계를 빨리 배우는 법을 묻는다면 첫마디는 이것이다 — 빨리는 안 된다.
한 가지 더. GitHub Copilot은 2026년 4월 24일부터 무료·Pro 사용자의 상호작용 데이터를 기본적으로 모델 훈련에 사용한다. 당신이 AI와 협업하는 방식, 당신의 하네스 발상, 당신의 지시 파일 스타일이 모두 다음 세대 모델의 훈련 데이터가 된다.
이 순환 안에서, 누가 고삐를 설계하는가가 누가 말을 타는가보다 중요할 수 있다.
이것도 확실하지 않다. 당신의 생각에 맡긴다. — 원저는 이렇게 끝난다.
Part 1은 단어의 기원과 60년의 관계 전환을, Part 2는 다섯 구성 요소와 감법의 철학을, Part 3은 일곱 개의 실전 하네스를, Part 4는 빈 파일에서 편성까지의 실제 구축을 다뤘다. 그리고 Part 5는 이 모든 것의 전제 — 경험과 판단력 — 가 어디서 오고 어디로 가는지를 물었다.
고삐는 말을 강하게 만들지 않는다. 말의 힘을 쓸모 있게 만든다.