10 장. 검증 루프 — Boris Cherny 의 하네스 정의
"Claude Code 를 잘 쓰는 사람은 AI 한테 일을 잘 시키는 사람 이 아닙니다. AI 가 자기 작업을 스스로 검증하게 만드는 사람입니다." — Boris Cherny, Anthropic Claude Code 책임자
도입 — 짧지만 깊은 한 장
이 장은 3 부에서 가장 짧다. 동시에 가장 깊다. 한 줄의 정의 가 8·9 장의 모든 도구 를 왜 그렇게 만들었는가 에 답하기 때문이다.
그 한 줄을 다시 기록한다.
하네스 = AI 가 자기 작업을 스스로 검증 하게 만드는 시스템.
이 정의를 깊이 이해하면 — 8 장의 4 계층 아키텍처 도, 9 장의 Superpowers 5 단계 도, 14 장의 CLAUDE.md 도, 16 장의 5 종 체크리스트 도 — *모두 같은 목적의 서로 다른 형태 * 임이 보인다.
AI 한테 시키는 사람 vs 스스로 검증하게 만드는 사람
이 장 전체가 두 종류의 사람 의 차이에 관한 것이다. 표로 본다.
| 종류 | 행동 | 결과 |
|---|---|---|
| A. AI 한테 일을 시킨다 | "이거 만들어 줘" → 받는다 → 끝 | 7 건 사고의 자리 |
| B. AI 가 스스로 검증 하게 만든다 | "이거 만들고, 테스트 짜고, 실행해서 통과 확인까지" | Crossbeam 2 일 / Elisa 1 주일의 자리 |
A 와 B 의 행동 차이 는 한 문장이지만 결과 차이 는 수십 배 다. 왜 이렇게 차이가 나는가?
A 의 사람은 *AI 의 응답을 그대로 믿는다. 검증을 나중 으로 미룬다. 코드가 작동하는지 는 나중에 알게 된다 — 보통 너무 늦게.
B 의 사람은 *AI 의 응답에 검증 단계를 지시 안에 * 넣는다. AI 가 자기 결과를 스스로 테스트해서 검증 한 뒤에 최종 결과 를 가져온다.
이 한 가지 차이가 3 개월의 벽 (4 장) 의 답이다. 벽은 검증이 누적되지 않은 코드 가 만든다. 매번 검증한 코드는 벽을 만들지 않는다.
좋은 지시 vs 나쁜 지시 — 한 예
추상적 표현을 지시 한 줄 차이로 본다.
❌ 검증 없는 지시:
"이 기능 만들어 줘."
✅ 검증 루프 포함 지시:
"이 기능을 구현해 줘. 작동 확인용 테스트 코드 도 같이 작성해 줘. 마지막으로 테스트를 실행 해서 통과 여부를 확인해 줘."
이 두 줄의 차이가 Claude 를 코드 생성기 에서 자기 검증 에이전트 로 전환 시킨다. 차이는 세 동사 다 — "작성해 / 실행해 / 통과 여부 확인해". 이 세 동사가 들어가면 — AI 의 마지막 응답 이 검증 통과 기록 으로 끝난다.
여러분이 Cursor 를 쓸 때 주변 친구 중 잘 쓰는 사람 의 지시 를 옆에서 보면 — 대부분 이 세 동사가 들어 있다. 그게 그 친구가 잘 쓰는 유일한 비결 이다.
후배에게 일 줄 때 — Boris 의 비유
Boris 가 즐겨 쓰는 비유. AI 협업 = 후배 협업.
❌ 후배에게 던지는 나쁜 지시:
"보고서 만들어놔."
✅ 후배에게 던지는 좋은 지시:
"보고서 만들어 줘. 숫자 출처 맞는지 확인하고, 맞춤법 검토 후 공유해 줘."
후배가 처음 일하는 신입 이라면 — 첫 번째 지시로 받은 보고서는 십중팔구 어딘가가 어긋난다. 두 번째 지시는 숫자 검증 + 맞춤법 검증 이라는 후배 자신의 검증 단계 를 강제한다.
핵심 비유: *AI = 매우 똑똑하지만 처음 회사에 온 신입.
매우 똑똑한 신입에게 "보고서 만들어놔" 라고 던지는 것이 위험 이다. 그 신입은 자기가 옳다고 생각하는 방식 으로 보고서를 만들 것이다. 하지만 그 방식이 우리 회사의 컨벤션과 다를 수 있다. *나쁜 의도가 있어서가 아니라 — 우리 회사의 컨벤션을 모르기 때문에 *.
이 비유가 *11 장 경험 = 검증자 * 의 출발점이다. 우리 회사의 컨벤션 = 시니어 경험 이고, 그것이 AI 에 외재화되어야 한다.
CLAUDE.md 의 가장 중요한 요소 — 하지 말아야 할 것
검증 루프의 문서적 형태 가 CLAUDE.md (14 장에서 자세히) 다. 그 안에서 가장 중요한 부분 이 무엇인가에 대한 Boris 의 발언.
"실무에서는 Claude 가 잘하는 일을 더 잘하게 만드는 것보다 하면 안 되는 일을 못 하게 막는 것 이 훨씬 중요할 때가 많다."
이 한 줄이 역설적 이다. 잘하게 만드는 게 더 중요하지 않나? 라고 생각하기 쉽다. 그러나 Boris 의 결론은 그 반대 다.
이유는 비대칭성 이다.
- 잘하는 일을 더 잘하게 — 좋은 결과 → 더 좋은 결과. 이득은 점진적.
- 하면 안 되는 일을 못 하게 — 재앙 → 재앙 차단. 손실 방지는 극단적.
4 장의 7 건 사고 가 모두 후자의 비대칭 을 보여 준다. DB 삭제 한 번 이 100 시간을 날리는 비대칭. 인증 역전 한 번 이 170 개 앱을 깨는 비대칭. *재앙은 평균이 아니라 극단 * 이다.
그래서 CLAUDE.md 의 75% 는 하지 마라 (Don't), 25% 만 해라 (Do) 가 황금 비율이 된다 (14 장). 재앙 차단이 점진적 개선보다 압도적으로 가치 크기 때문이다.
CLAUDE.md 실전 예시:
# 절대 금지
- 마이그레이션 파일은 사용자 승인 없이 수정하지 않는다
- 프로덕션 DB 관련은 절대 자동 실행하지 않는다
# 새 기능 구현 전 필수
- 반드시 *테스트 전략* 을 먼저 설명한다
세 줄의 Don't 두 줄 + Do 한 줄. 이 비율이 Boris 가 권하는 황금 비율 이다.
CLAUDE.md 길이 원칙 — 약 2,500 토큰
마지막으로 길이. Boris 의 권유는 명확하다.
약 2,500 토큰 정도. 심플하게. 길면 독.
2,500 토큰 ≈ 영어 1,800 단어 ≈ 한국어 1,000 ~ 1,500 자 ≈ 65 ~ 100 줄. Karpathy 의 65 줄짜리 CLAUDE.md 가 GitHub 10 만 스타 인 사례 (14 장에서 자세히) 가 정확히 이 권유에 맞다.
길면 왜 독인가. 세 가지 이유.
- 세션마다 전부 로드 됨 — 1M context 의 0.25% 가 항상 차지. 길어지면 AI 의 작업 공간 자체 가 좁아진다.
- 세션 중 수정 → 캐시 prefix 무효화 → 토큰 전액 재청구 (캐시 hit 의 ~20 배). 길수록 수정 위험 증가.
- 분석 마비 — 학생이 300 줄 CLAUDE.md 를 작성하면 그 자체가 새로운 부채.
이 세 이유가 14 장의 정량 근거 절에서 다시 깊이 다뤄진다. 10 장에서는 원리만 — 짧을수록 강하다.
권한 설계 — 하네스의 경계선
검증 루프와 함께 작동하는 경계선 이 있다. AI 가 무엇까지 자율로, 무엇은 승인이 필요하고, 무엇은 절대 금지인가.
허용 (자동): 테스트 실행, 파일 *읽기*
승인 필요: 패키지 설치, 커밋
금지: 위험한 삭제 명령, 프로덕션 DB 접근
이 3 단계 권한 구조는 *OS 의 루트 / sudo / 일반 사용자 * 와 정확히 같은 모양이다. 여러분이 Linux 를 써 봤다면 이 모델이 친숙하다.
Boris 의 한 줄.
"신입 개발자에게 처음부터 모든 서버 권한 을 다 주지 않듯, AI 도 마찬가지다. 똑똑한 만큼 더 큰 실수 를 할 수 있다."*
이 한 줄에 전체 사고 예방의 핵심 철학 이 기록되어 있다. AI 가 똑똑해질수록 사고의 규모 도 커진다. 그래서 권한 분리가 더 중요해진다. 4 장의 PocketOS DB + 백업 삭제 가 정확히 이 권한 분리 부재의 사례다.
장시간 검증 3 종 세트
마지막으로 — AI 가 30 분 ~ 1 시간 단위로 작업할 때 의 3 가지 검증 도구.
| 방법 | 동작 |
|---|---|
| 테스트 자동 실행 | 구현 → 테스트 작성 → 실행 → 실패 시 재수정 |
| Stop Hook | Claude 완료 시 빌드 / 테스트 / 린트 자동 실행 |
| UI 검증 | 스크린샷 / 브라우저 자동화로 화면 확인 |
Stop Hook 이 특히 강력하다. *AI 가 "끝났다" 고 선언하는 그 순간 — *시스템이 자동으로 빌드 / 테스트 / 린트 를 돌린다. 테스트가 깨지면 — AI 가 끝난 게 아니다. 자동으로 재작업 모드 로 전환된다.
이게 *Superpowers 의 TDD 철칙 시스템 훅 * 과 같은 자리 (9 장 참조). 두 도구 모두 "AI 의 끝났다 선언을 시스템이 검증한다" 는 같은 원리.
이 3 종이 합쳐져서 — *AI 가 모르게 망친 코드 가 그대로 남는 일 * 을 시스템적으로 차단 한다.
검증 루프 = 하네스의 정수
10 장의 한 줄을 다시 기록한다.
하네스 엔지니어링의 정수 = AI 가 자기 결과를 스스로 검증 하게 만드는 시스템 설계 * .
이 한 줄이 왜 4 장의 7 건 사고가 일어났는지 의 답이고 — 왜 Crossbeam / Elisa 의 시간 압축 이 가능했는지 의 답이며 — 왜 5 종 체크리스트 (16 장) 의 Verification 항목이 5 가지 중 가장 강력한지 의 답이다.
표어로 닫는다.
AI-Native Vibe Coding: No Design, No Code. — No Design 의 No 는 검증 루프가 없는 상태다. Design 의 정수는 AI 가 자기를 검증하게 만드는 시스템.
다음 11 장에서 — 그러면 무엇을 금지해야 하는가 의 답 을 본다. 답은 시니어의 경험 에서 온다. 경험을 시스템으로 외재화하는 것이 곧 CLAUDE.md.
"신입에게 하지 마라 천 줄을 던지면 마비된다. 5 ~ 10 개 핵심 + 나머지는 모듈별 lazy."