Harness Engineering — 18장: 다음 세대의 고삐는 누가 설계하는가

In · On · Out of the Loop — 사람이 서 있는 세 위치

원문은 Martin Fowler 팀의 Kief Morris가 제시한 세 층을 출발점으로 삼는다. 사람은 Agent의 코드 안에 직접 들어갈 수도 있고, 코드 대신 Harness를 개선할 수도 있으며, 요구만 말하고 완전히 결과를 맡길 수도 있다.

IN THE LOOP

코드 자체를 만지는 사람

Agent가 낸 코드를 줄 단위로 검토하고, 마음에 들지 않는 부분을 사람이 직접 고친다. 모든 변경이 사람의 손을 거친다.

결과가 마음에 들지 않으면 코드를 수정한다.

ON THE LOOP

고삐를 고치는 사람

코드 그 자체보다 Specification, 품질 검사, Workflow, Guardrail을 설계한다. 실행자의 다리를 고치기보다 실행자가 움직이는 구조를 바꾼다.

결과가 마음에 들지 않으면 Harness를 수정한다.

OUT OF THE LOOP

결과만 요구하는 사람

무엇을 원하는지만 말하고 Agent가 구현과 판단을 대부분 스스로 처리하게 한다. 원문은 이를 Vibe Coding과 연결한다.

사람이 실행 과정에서 사실상 빠진다.

In the loop의 사람은 결과가 나쁘면 코드를 고친다.
On the loop의 사람은 다음 결과가 나아지도록 Harness를 고친다.

On the loop는 반복 노동을 시스템 개선으로 바꾼다. 그러나 바로 그 효율성 때문에 더 어려운 질문이 생긴다. 사람이 너무 일찍 코드에서 멀어지면, 훗날 Harness가 잘못되었을 때 밑바닥을 이해할 사람은 어디에서 오는가.

Junior의 가치는 오늘의 산출물이 아니라 내일의 Senior에 있다

원문은 Martin Fowler의 우려를 더 날카롭게 옮긴다. Junior Developer의 가장 중요한 속성은 현재 생산량이 아니라 앞으로 Senior Developer로 성장할 가능성이라는 것이다. AI가 Junior의 산출물만 대체한다면 효율일 수 있지만, 성장 경로까지 함께 없애면 미래의 판단력을 당겨 쓰는 셈이 된다.

생산성의 역설

사람을 코드의 세부에서 빨리 떼어낼수록 현재 생산은 빨라질 수 있다. 그러나 코드가 왜 깨지는지, 아키텍처가 왜 무너지는지, 어느 종류의 오류가 위험한지를 몸으로 배우는 경로도 짧아질 수 있다.

원문이 제시한 서로 다른 조직 신호

장은 이 문제가 이미 현실의 조직 변화 속에서 드러난다고 서술한다. 하나는 더 많은 초보자를 AI와 함께 일하게 하는 방향이고, 다른 하나는 AI 효율화를 이유로 인력을 줄이는 방향이다. 서로 반대처럼 보이지만 “중간에서 배우는 층이 사라지는가”라는 같은 문제로 묶인다.

25 → 1000 Shopify 인턴 프로그램 · 원문 수치

AI를 사용하는 인턴의 방식이 흥미롭다는 이유로 확대했다고 서술.

40% Block 인력 감축 · 원문 수치

AI 기반 효율 향상을 이유로 든 사례로 제시.

조직은 산출물을 자동화할 수 있다. 그러나 경험까지 자동 생성할 수 있는지는 별개의 문제다. 사람의 생산을 줄이는 결정과 사람의 성장 경로를 줄이는 결정은 같은 문장이 아니다.

좋은 Harness 뒤에는 이미 깊게 실패해 본 사람이 있다

원문은 앞선 사례를 다시 돌아보며 공통점을 찾는다. Harness를 잘 만든 사람들은 모델 사용법만 잘 아는 것이 아니라 자신이 다루는 시스템의 실패 양상을 오랫동안 알고 있었다.

Mitchell Hashimoto

Ghostty의 Harness를 세밀하게 만들 수 있었던 이유를 터미널 에뮬레이터의 세부를 깊게 이해했기 때문이라고 해석한다. AGENTS.md의 각 줄은 과거 Agent의 실제 오류와 연결된다.

오류가 왜 오류인지 아는 도메인 지식

OpenAI의 3명 엔지니어

약 100만 줄 규모의 코드 생산을 다룰 수 있었던 이유를 좋은 아키텍처와 몇 달 뒤 폭발할 구조를 구별할 판단력이 있었기 때문이라고 설명한다.

현재 동작보다 미래 붕괴를 보는 설계 감각

Kent Beck

TDD 기반 CLAUDE.md는 수십 년의 소프트웨어 공학 경험 위에서 나왔다. BPlusTree3의 앞선 두 시도가 복잡성 누적으로 실패하고 세 번째 시도에서 개입 방식을 찾았다는 사례를 다시 든다.

반복 실패 속에서 만들어진 개입의 타이밍

Harness의 규칙은 추상적인 Best Practice에서만 나오지 않는다. 무엇이 세 달 뒤 문제가 되는지 이미 여러 번 보아온 사람의 시간이 규칙의 배경에 깔려 있다.

코드를 쓰지 않아도 다른 종류의 경험은 쌓인다

저자는 자신의 사례를 다시 꺼낸다. 수기 코딩 경험 없이 모든 제품을 AI로 만들었고, Harness도 기존 프로그래밍 경험을 이식한 것이 아니라 AI와의 반복적인 상호작용 속에서 자랐다고 서술한다.

1000h+ AI와 반복해서 부딪힌 시간

정확한 계량값이라기보다 원문의 “상천 시간” 서술을 시각화

코드가 아니라 행동 패턴을 학습한다

저자는 Harness를 설계할 수 있게 된 이유를 타고난 시스템 설계 능력보다 AI의 행동을 오래 관찰한 데서 찾는다. 무엇을 잘하는지가 아니라 언제 흐트러지는지를 반복해서 보았다는 것이다.

언제 일을 대충 끝내려 하는가

언제 hallucination이 생기는가

언제 부드러운 알림보다 Hard Constraint가 필요한가

어떤 규칙 표현을 실제로 잘 따르는가

문제는 이 판단력을 다른 사람에게 그대로 가르칠 수 있는가다. 원문 저자는 명확한 답을 내놓지 않는다. 많은 결정이 직관으로 이루어지고, 직관은 반복된 시행착오와 시간에서 나온다고 적는다.

경험은 반드시 코드 타이핑의 형태일 필요는 없다. 그러나 경험 자체를 건너뛰는 것은 다른 문제다. 새 경기장에서도 판단은 반복과 실패를 먹고 자란다.

질문은 “코딩 경험을 대체할 수 있는가”가 아닐지 모른다

원문은 논점을 바꾼다. 중요한 것은 경험의 종류가 아니라 충분한 경험 자체가 Harness 설계의 전제인지 여부다. 그리고 여기에는 지름길이 없다는 방향으로 기운다.

이전의 경기장

전통적인 소프트웨어 개발에서 판단력을 만드는 반복.

직접 코드 작성
버그 디버깅
리팩터링
운영 장애와 야간 대응

→

새로운 경기장

AI 협업 시대에 판단력을 만드는 다른 반복.

CLAUDE.md 작성
Hooks와 Guardrail 설계
AI hallucination 분석
실패한 Workflow 재설계

고통의 모양은 바뀌었다. 고통의 총량은 크게 줄지 않았을 수 있다.
원문은 이 변화 속에서도 배움의 핵심이 충분한 시간과 충분한 실패라는 점을 놓지 않는다.

학습의 비용을 없애는 자동화는 매력적이다. 그러나 판단력까지 자동화할 수 없다면, 실패와 반복을 없애는 일은 동시에 판단력이 자랄 토양을 없애는 일이 될 수 있다.

엔지니어의 핵심 기여는 코드보다 판단력이다

원문은 Boris Cherny의 말을 빌려 엔지니어의 핵심 기여를 Judgment로 압축한다. 코드는 Agent가 더 많이 쓸 수 있어도 무엇을 만들지, 어떻게 검증할지, 언제 믿고 언제 반박할지는 별도의 능력으로 남는다.

JUDGMENT 코드보다 위에 있는 선택 무엇을 만들고 · 어떻게 확인하고 · 언제 의심할지 결정

무엇을 만들 것인가

가능한 구현 중 무엇이 실제로 가치 있는 문제를 푸는지 선택한다.

어떻게 검증할 것인가

성공을 어떤 테스트·평가·운영 신호로 확인할지 정의한다.

언제 신뢰할 것인가

Agent의 결과가 충분히 신뢰할 만한 근거를 갖췄는지 판단한다.

언제 반박할 것인가

그럴듯한 결과가 사실은 잘못된 방향일 때 멈추고 다른 길을 요구한다.

판단력은 규칙집을 외워서 생기지 않는다. 많이 해본 뒤 어떤 길이 막히는지 기억하는 데서 생긴다. 그래서 이 장의 질문은 도구 선택보다 교육 구조의 문제로 돌아간다.

사람과 AI가 겹치는 40–60% — 판단력이 자랄 수 있는 중간 지대

원문은 AI 사용이 빠르게 늘고 있지만 완전 위임은 훨씬 적다고 서술한다. 그 간극을 사람과 AI가 함께 일하며 판단을 훈련하는 공간으로 읽는다.

84% 개발자 AI 도구 사용/사용 계획

원문이 제시한 수치.

60% 엔지니어 업무 중 AI 사용

원문이 Anthropic 보고서 수치로 제시.

0–20% 완전 위임 가능한 업무

원문이 같은 맥락에서 제시한 범위.

원문은 그 사이의 40–60%를 사람이 AI와 협력하는 영역으로 본다. AI가 일부를 수행하지만 사람이 맥락을 설명하고, 결과를 의심하고, 검증하고, 다시 방향을 잡는 공간이다. 이 중간 지대가 판단력이 자라는 토양일 수 있다는 주장이다.

완전 자동화는 효율의 종착점처럼 보인다. 그러나 사람이 결과에 개입할 이유가 완전히 사라지는 순간, 다음 세대가 판단을 연습할 장소도 함께 사라질 수 있다.

Karpathy의 AutoResearch — Harness가 팀의 시간을 압축할 때

원문은 코드 생성의 미래를 극단적으로 보여주는 사례로 Karpathy를 든다. 2025년 12월 이후 직접 코드를 쓰지 않고, AutoResearch에서 작은 코드와 Markdown Prompt를 결합해 대량의 실험을 자동화했다고 서술한다.

원문에 제시된 AutoResearch 규모

한 사람과 Harness가 전통적으로 팀이 수주 동안 할 법한 실험량을 짧은 시간에 밀어붙이는 사례로 제시된다.

630 lines of code

1 Markdown prompt

700 experiments

2 days execution window

하지만 Harness가 실험의 가치를 결정하지는 않는다

원문은 이 사례를 “누구나 같은 생산성을 얻는다”는 증거로 쓰지 않는다. 어떤 실험을 돌릴 가치가 있는지, 어떤 결과를 더 파고들지, 무엇이 발견이고 무엇이 noise인지 판단하는 연구 직관이 Harness의 바깥에 존재한다고 강조한다.

Markdown Prompt가 효과적인 이유는 Prompt 문법 자체보다 그것을 작성한 사람이 오랜 연구 경험을 통해 무엇을 실험하고 어떻게 실패를 읽어야 하는지 알고 있기 때문이라는 해석이다.

Harness는 경험을 증폭할 수 있다. 그러나 무엇을 증폭할 가치가 있는지 결정하는 경험까지 자동으로 만들어주지는 않는다.

사람이 AI를 가르치고, AI는 사람이 가르치는 법을 학습한다

장의 끝에서 원문은 새로운 피드백 루프를 던진다. 2026년 4월 24일부터 GitHub Copilot Free와 Pro 사용자의 상호작용 데이터가 기본적으로 모델 학습에 사용된다고 서술하며, Harness와 Instruction Style 자체가 미래 모델의 데이터가 될 수 있다고 지적한다.

사람의 판단어떻게 시킬지 결정

→

Harness규칙 · 제약 · 평가

→

AI 상호작용사람이 AI를 가르침

→

다음 모델AI가 가르치는 방식을 학습

코드에서 멀어진 세대가 Harness를 고칠 수 있는가

밑바닥 구현을 직접 경험하지 않고도 충분히 좋은 아키텍처·테스트·제약을 설계할 수 있는지 장은 답하지 않는다.

AI 협업 경험은 전통적 개발 경험을 대신할 수 있는가

다른 종류의 경험이 판단을 만들 수 있다는 사례는 있지만, 그 경험을 얼마나 재현 가능하게 교육할 수 있는지는 열려 있다.

완전 자동화가 학습의 토양을 말려버리면 어떻게 되는가

사람과 AI가 함께 판단하는 중간 영역이 줄어들 때 다음 세대가 실패를 충분히 경험할 장소도 줄어드는지 묻는다.

다음 고삐를 누가 설계할 것인가

모델이 사람의 Instruction Style까지 학습하는 순환 속에서 결국 더 중요한 역할이 “타는 사람”인지 “고삐를 만드는 사람”인지 다시 질문한다.

원문은 이 질문들에 답하지 않는다.
다만 한 가지는 분명하게 말한다.

Harness를 빨리 배우는 지름길은 없다.
충분히 많이 해보고, 충분히 많이 실패하는 시간을 건너뛸 수 없다.

고삐는 말을 타지 않는 사람이 만들 수 있다.
그러나 말이 어디에서 놀라고,
어느 비탈에서 미끄러지는지 전혀 모르는 사람이
좋은 고삐를 만들기는 어렵다.

그렇다고 모든 사람이 평생 말의 발굽만 보아야 하는 것도 아니다.
어느 순간에는 눈을 들어 길 전체를 보아야 한다.

문제는 언제 올라갈 것인가다.
너무 오래 아래에 있으면 시스템을 못 보고,
너무 빨리 위로 올라가면 밑바닥의 이유를 잃는다.

그래서 다음 세대의 Harness를 만드는 일은
새로운 도구를 가르치는 일만으로 끝나지 않는다.
충분히 실패할 시간과, 실패를 판단으로 바꿀 자리를 남기는 일까지 포함한다.

이 웹페이지는 첨부 문서 《Harness Engineering》의 §18 「经验工程：谁来设计下一代的缰绳 / Experience Engineering: Who Will Design the Next Harness」 (PDF 95–98쪽)에만 근거해 재구성했다. PDF 99쪽은 문서 후면·홍보 페이지이므로 18장 본문에서 제외했다. Kief Morris의 In / On / Out of the Loop 구분, Martin Fowler의 Junior 성장 경로 문제, Shopify·Block에 대한 원문 사례, Mitchell Hashimoto·OpenAI·Kent Beck 사례의 재해석, 저자의 제로 코딩 경험과 AI 협업 기반 직관, 경험 자체가 Harness 설계의 전제라는 논지, Boris Cherny의 Judgment 관점, AI 사용·완전 위임 사이의 협업 지대, Dario Amodei 전망과 Karpathy AutoResearch 사례, GitHub Copilot 상호작용 데이터에 대한 원문 시점의 서술, 그리고 결론을 내리지 않는 마지막 질문까지 모두 포함했다. 시점 의존적인 기업·제품·인력·통계·모델 학습 관련 정보는 외부에서 검증하거나 갱신하지 않고 첨부 원문의 주장으로만 다뤘다.