점진적 하네스 통합 — *기존 프로젝트가 무너지지 않는 단계적 도입*
9.1 들어가며 — 달리는 기차 위에서 안전벨트 갖추기
다시 김OO 의 화요일. 그러나 이번에는 6 개월 된 기존 프로젝트 에 합류한 첫 주다. Chapter 8 에서 다룬 4 대 요소 (Commands · Rules · Skills · Hooks) 가 모두 비어 있다. CLAUDE.md 도 없고, Hooks 도 없고, 표준 커맨드도 없고, Skills 도 없다. 김OO 는 의욕 넘치게 "이번 주말에 4 대 요소 다 갖추겠습니다" 라고 팀에 선언했다. 그리고 월요일, 팀 전체가 작업을 멈추고 김OO 의 PR 100 줄짜리 변경을 리뷰하는 사태가 벌어진다 — 매일 쓰던 워크플로가 모두 바뀌어 어느 누구도 자기 작업을 진행할 수 없는 자리.
무엇이 잘못됐는가? 새 프로젝트와 기존 프로젝트는 도입 방식이 완전히 다르다. 새 프로젝트는 Chapter 8 의 30 분 워크플로 로 4 대 요소를 한 번에 갖춘다 — 모래 위에 집을 짓는 자리라 한 번에 4 개 기둥을 세워도 무너지지 않는다. 기존 프로젝트는 달리는 기차 다. 멈출 수 없고, 한 번에 다 손보려면 기차가 탈선 한다. 비유하면 근력 운동의 점진적 과부하 (Progressive Overload) — 한 번에 100 kg 들겠다고 덤비면 부상, 각 단계마다 5% 씩 늘리면 단계적으로 100 kg 에 도달.
본 장의 주제 — 점진적 하네스 통합(Progressive Harness Integration) — 은 기존 프로젝트에 4 대 요소를 한 단계씩 누적적으로 도입하는 전략이다. 1980 년대 ERP 도입의 Big Bang vs 단계적 도입 교훈, DORA(DevOps Research & Assessment) 의 운영 안정성 측정 지표, Anthropic 의 slow and small is fast 권고가 모두 한 결로 수렴한다 — 점진적이 결국 빠르다. 본 장은 4 절로 흐른다. 첫째, 점진적 통합의 정의와 근력 운동 점진적 과부하 비유. 둘째, 한 번에 vs 점진적의 9 행 비교. 셋째, 4 대 요소 도입 우선순위 (Rules → Hooks → Commands → Skills) + DORA 측정. 넷째, 6 개월 된 프로젝트의 단계적 도입 워크플로.
9.2 핵심 개념 — 근력 운동의 점진적 과부하
9.2.1 정의 — 점진적 통합이란
점진적 하네스 통합 은 한 줄로 정의된다 — 기존 프로젝트에 4 대 요소(Commands · Rules · Skills · Hooks)를 한 번에가 아니라 우선순위에 따라 단계적으로 도입하며, 각 단계의 운영 안정성을 측정 후 다음 단계로 진행하는 자세. 핵심은 측정 후 진행 이다. 한 단계를 도입하면 DORA 4 대 지표 (배포 빈도 / 변경 리드타임 / 변경 실패율 / 평균 복구 시간) 가 나빠지지 않는지 를 충분한 적응 기간 동안 관찰한 후에야 다음 단계로 넘어간다.
이 정의를 근력 운동의 점진적 과부하 비유로 풀면 손에 잡힌다. 헬스장의 첫 운동 날 100 kg 스쿼트에 도전하는 사람은 부상을 입고 한 달을 쉰다. 같은 100 kg 목표라도 60 → 70 → 80 → 90 → 100 kg 로 단계마다 5~10% 씩 늘리는 사람은 단계 누적 후 무사히 도달한다. 차이는 근육과 관절의 적응 시간 이다. 팀의 워크플로 적응 도 같다 — Rules 한 가지를 도입하면 팀이 그것에 익숙해질 적응 기간 이 필요하다. 4 가지를 한 번에 들이밀면 팀이 모두 거부 하거나 모두 무시 한다. 4 가지를 5 단계로 나누어 한 가지씩 들이면 모두 자연스럽게 받아들인다.
concept/agentic-engineering 의 마지막 자리 — "slow and small is fast" — 가 본 장의 메시지를 미리 명시한다. 천천히 작게 시작하는 것이 결국 가장 빠르다.
9.2.2 같은 프로젝트, 두 가지 도입 접근 — Big Bang vs 점진적
이 차이를 손에 잡히게 살펴보자. 같은 6 개월 된 SaaS 프로젝트 에 4 대 요소를 도입하는 두 가지 접근.
Big Bang 접근 (한 번에 다) — 김OO 가 주말 동안 CLAUDE.md, .claude/commands/, .claude/skills/, .claude/hooks/ 를 모두 한 번에 작성한다. 월요일 PR 1,200 줄. 팀의 5 명이 매일 쓰던 워크플로가 모두 바뀐다. "새 커맨드 외워야 하나?", "Skills 가 자꾸 발동되어서 작업이 막힌다", "Pre-commit hook 때문에 커밋 못 한다" 같은 불만이 쏟아진다. 얼마 지나지 않아 팀 회의에서 "다 되돌리자" 결정이 나고, 김OO 의 1,200 줄은 PR 페이지에서 closed (not merged) 로 끝난다. 1980 년대 ERP 도입의 70% 실패율 이 정확히 이 자리.
점진적 접근 (한 단계씩 누적) — 1 단계에 Rules (CLAUDE.md) 만 도입. 기존 코드 변경 ❌, 새 작업에만 적용. 팀이 "이건 그냥 헌장이네, 받아들이자" 며 자연스럽게 익숙해진다. 2 단계에 Hooks (pre-commit lint + post-tool test) 만 도입 — DORA 변경 실패율 측정 기준선 잡기. 3 단계에 Commands 1 개 (/test-all). 4 단계에 Skills 1 개 (도메인 핵심). 5 단계 통합 + 회고. 5 단계 완료 후 4 대 요소가 모두 자리잡고, 팀의 변경 실패율은 -30%, 배포 빈도는 +40%.
| 축 | Big Bang 접근 | 점진적 접근 |
|---|---|---|
| 같은 목표 | 4 대 요소 모두 도입 | 동일 |
| 기간 | 한 번에 (1 주말 이상) | 5 단계 (대략 1~2 개월 — 단계 사이 적응 기간 포함) |
| PR 크기 | 1,200 줄 한 번에 | 단계마다 100~200 줄 (총 5 회) |
| 팀 적응 시간 | 0 (강제) | 매 단계 한 차례 적응 기간 |
| 운영 안정성 측정 | 없음 | 단계마다 DORA 4 지표 |
| 부작용 | 워크플로 거부, 작업 정지 | 자연스러운 적응 |
| 6 개월 후 정착률 | 30% (산업 평균) | 90% 이상 |
| 도입 비용 | 1 주말 + 1 달 디버깅 | 단계마다 1~2 시간 (총 5 단계 누적 8 시간) |
| 결과 | 되돌리자 | 모두 자리잡음 |
같은 4 대 요소 도입 이라도 Big Bang 의 1 주말 + 1 달 디버깅 + 되돌리기 와 점진적 5 단계 (대략 1~2 개월, 누적 8 시간) + 안정 정착 의 비교는 명확하다 — 전자가 짧아 보이지만 결국 길고, 후자가 길어 보이지만 결국 짧다. 1980 년대 ERP 의 Big Bang 70% 실패 가 2026 년 AI 하네스 도입에서 다시 반복되지 않으려면 점진적이 답 이다.
9.2.3 slow and small is fast — 산업 격언의 자리
이 메시지는 단순한 방법론 추천이 아니다. Big Bang vs 점진적 의 패턴은 SW 도입의 반복되는 사실 이다. 1980 년대 ERP, 1990 년대 CRM, 2000 년대 Agile 전환, 2010 년대 DevOps, 2020 년대 마이크로서비스 — 모든 대규모 도입에서 Big Bang 70% 실패 / 점진적 80% 정착 패턴이 일관되게 보고되었다. 2026 년 AI 하네스도 같은 결로 따라간다.
entity/karpathy 가 "slow and small is fast" 한 줄로 정리한 이유가 여기다. 작은 단계로 천천히 시작하는 것이 결국 가장 빠른 도달 경로. 본 책 표어 "설계 없이는 코딩이 안 된다" 의 마지막 자리도 같은 결 — 설계의 도입도 설계의 도입 자체에 설계가 있어야 작동한다.
9.3 역사적 · 기술적 맥락 — 도입 우선순위와 측정
9.3.1 4 대 요소 도입 우선순위 — Rules → Hooks → Commands → Skills
4 대 요소를 어떤 순서로 도입할지가 5 단계 단계적 도입 워크플로의 핵심이다. 산업 사례 누적의 결론이 기록된 우선순위는 다음과 같다.
1 순위 — Rules (CLAUDE.md). 가장 먼저 도입한다. 이유 — 기존 코드 변경 ❌, 새 작업에만 적용. 가장 침투력 있으면서 가장 부담 없다. 프로젝트 헌장 5 항목 + 코딩 컨벤션 한 줄. 팀의 적응 비용 거의 0.
2 순위 — Hooks (pre-commit + post-tool). 두 번째로 도입한다. 이유 — 측정 기준선 박기. Hooks 가 들어가면 DORA 4 지표 가 자동 측정 가능해진다. 이 측정이 없으면 다음 단계의 효과를 알 수 없다. 단, 처음에는 경고만, 차단은 나중에 — 팀 적응 후 단계적으로 강제.
3 순위 — Commands 1 개. 세 번째로 도입한다. 이유 — 팀이 가장 자주 쓰는 작업 1 개 를 표준화. 효과가 즉시 체감된다. 전체 커맨드 박기 ❌ — 처음에는 1 개만, 다음 도입 사이클에 2 개, 누적적으로.
4 순위 — Skills 1 개. 마지막 도입. 이유 — Skills 는 자동 트리거되므로 잘못 박으면 매 작업마다 충돌. Rules + Hooks + Commands 가 자리잡은 후에야 Skills 의 조건 매칭 이 안전하게 작동한다. 첫 Skills 는 도메인 핵심 1 개 만 — 결제 SaaS 라면 payment-pci, 데이터 파이프라인이라면 data-validation.
이 순서가 우연 이 아닌 이유는 각 요소의 팀 적응 비용 과 측정 가능성 의 곱이 가장 작은 순서이기 때문이다. Rules 는 비용 1 / 측정 0 — 부담 없이 도입. Hooks 는 비용 2 / 측정 5 — 측정 시작점. Commands 는 비용 3 / 측정 3 — 효과 체감. Skills 는 비용 5 / 측정 5 — 가장 무거우나 마지막.
9.3.2 DORA 4 대 지표로 측정하기
도입 후 각 단계의 운영 안정성 을 어떻게 측정하는가? 산업 표준은 DORA(DevOps Research & Assessment) 4 대 지표 다.
- 배포 빈도(Deployment Frequency) — 일주일에 몇 번 배포하는가
- 변경 리드타임(Lead Time for Changes) — 코드 작성 → 운영 배포까지 시간
- 변경 실패율(Change Failure Rate) — 배포된 변경 중 사고를 일으킨 비율
- 평균 복구 시간(MTTR, Mean Time to Recovery) — 사고 후 복구까지 시간
각 지표는 Hooks 도입 시점 에 자동 측정 시작된다. 각 단계 1 회 5 분간 4 지표를 점검 — 나빠진 지표가 있으면 마지막 도입 단계의 효과를 의심 하고 보강 또는 롤백. 2026 년 산업 평균 — Elite 팀: 일 1 회 배포 / 1 시간 리드타임 / 5% 실패율 / 1 시간 복구 / Low 팀: 월 1 회 배포 / 1 달 리드타임 / 30% 실패율 / 1 일 복구 의 격차가 6 배~30 배.
5 단계 완료 후 측정 가능한 변화 를 기대할 수 있다. 한 산업 사례 (가공): 변경 실패율 28% → 19% (-32%), 배포 빈도 주 2 회 → 주 3 회 (+50%), MTTR 4 시간 → 1.5 시간 (-62%). 5 단계 투자가 연 단위 운영비 절감 으로 회수되는 자리.
9.3.3 ERP 도입 70% 실패의 교훈
이 점진적 자세가 AI 시대의 새 발견 이 아니라 80 년대 ERP 도입의 교훈을 다시 적용 한 것이라는 사실이 결정적이다. 1980~90 년대 SAP·Oracle ERP 의 Big Bang 도입 은 일관되게 70% 실패 했다. 사례별 원인은 달랐지만 공통 패턴은 모듈 한 번에 도입 → 팀 거부 → 되돌림. 1990 년대 후반 단계적 도입(phased rollout) 으로 전환 후 정착률이 30% → 80% 로 뒤집혔다.
같은 패턴이 2010 년대 DevOps 전환, 2020 년대 마이크로서비스 마이그레이션에서 반복되었다. 2026 년 AI 하네스 도입에서 또다시 같은 패턴이 재현될 위험이 매우 크다. 본 장의 5 단계 단계적 도입 워크플로 는 그 위험을 미리 회피하는 산업 누적 지혜의 적용 이다.
9.4 도구의 관점 — 기존 프로젝트의 단계적 도입 워크플로
[[DIAGRAM:9-1]]
[[DIAGRAM:9-2]]
다이어그램 9-1 은 5 단계 단계적 도입 타임라인 을, 9-2 는 각 단계의 DORA 지표 변화 를 한 컷에 담는다.
9.4.1 실무 워크플로 — 5 단계 단계적 도입 타임라인
추상 우선순위가 아니라 김OO 가 6 개월 된 SaaS 에 합류해 5 단계로 진행하는 구체 단계 를 살펴보자.
1 단계 — Rules 만 (CLAUDE.md, 1 시간). 첫 단계로 1 시간 투자. 프로젝트 헌장 5 항목 (보안 / 성능 / 사용 금지 패턴 / 코딩 컨벤션 / 도구 명시) + 왜 이 헌장인지 한 단락 추가. 팀에 "새 작업부터만 적용, 기존 코드 변경 ❌" 알림. 다음 단계로 넘어가기 전 팀이 자연 적응하는 기간 확보.
👁 화면: VS Code 에 CLAUDE.md 1 페이지 작성. PR 30 줄. 팀 Slack 에 한 줄 공지.
2 단계 — Hooks + 측정 시작 (1.5 시간). 1 단계 적응 후 다음 단계로 1.5 시간 투자. pre-commit lint (실패 시 경고만, 차단 ❌) + post-tool test 자동 실행. DORA 4 지표 측정 시작 — 기준선 잡기 위해 충분한 데이터 수집 기간 확보. 다음 단계 전 측정 + 안정성 모니터링.
👁 화면: .claude/hooks/pre-commit.sh 30 줄. Grafana 대시보드에 DORA 4 지표 표시.
3 단계 — Commands 1 개 (1 시간). 2 단계 안정 확인 후 1 시간 투자. 팀이 가장 자주 쓰는 작업 — 예: "전체 테스트 실행 + 커버리지 리포트" — 를 /test-all 1 개 커맨드로 표준화. 팀이 즉시 효과 체감 (이전 5 분 → 5 초). 다음 단계 전 사용량 모니터링 + DORA 측정.
👁 화면: .claude/commands/test-all.md 한 파일. 팀 Slack 에 "이 커맨드 써 보세요" 한 줄.
4 단계 — Skills 1 개 (2 시간). 3 단계 안정 확인 후 2 시간 투자. 도메인 핵심 1 개 — 결제 SaaS 라면 payment-pci, 데이터 파이프라인이라면 data-validation. 자동 트리거 조건을 좁게 (특정 파일 패턴만) 설정. 팀에 "이 조건에서만 발동, 끄려면 X" 알림. 다음 단계 전 충돌 모니터링.
👁 화면: .claude/skills/payment-pci/SKILL.md 기록. 자동 발동 로그 확인.
5 단계 — 통합 + 회고 (3 시간). 1 시간 통합 검증 — 작은 의뢰 하나로 4 대 요소가 함께 작동 하는지. 이어서 1 시간 팀 회고 — 4 가지 중 어느 것이 가장 효과적이었는지, 어느 것이 충돌이었는지. 마지막 1 시간 DORA 5 단계 비교 — 1 단계 기준선 vs 5 단계 완료 시점 현재. 다음 5 단계 도입 계획 (Skills 2 번째, Commands 2 번째 등). 👁 화면: 회고 노트 한 페이지. DORA 그래프 5 단계 비교. 팀에 "5 단계 완료 후 우리 변경 실패율 -30%" 발표.
이 5 단계 누적 8 시간 투자 가 프로젝트 수명 동안 매 작업마다 30 분~1 시간씩 시간을 절약 한다. ROI 의 본질은 5 단계 누적 8 시간 → 그 후부터 매 작업마다 회수 의 비대칭이다. Big Bang 의 1 주말 + 1 달 디버깅 + 되돌리기 의 정반대 자리.
9.5 닫으며 — 책 한 권의 마무리
본 장의 핵심을 한 줄로 정리하면 — Chapter 8 의 4 대 요소를 Big Bang 으로 한 번에 (1 주말) 도입하면 80 년대 ERP 70% 실패 를 반복한다. Rules → Hooks → Commands → Skills 의 5 단계 단계적 도입 (대략 1~2 개월 누적 8 시간) 으로 근력 운동의 점진적 과부하 처럼 천천히 들이밀어야 한다. slow and small is fast — 천천히 작게가 결국 가장 빠르다.
본 장으로 Part 3 (자율형 에이전트를 위한 하네스 엔지니어링) 이 마무리된다. 책 전체의 흐름을 한 줄로 정리하자. Part 1 은 AI 와의 대화 를 다뤘다 — 프롬프트가 컨텍스트로 진화하면서 AI 의 입력 을 어떻게 박는지의 자세. Part 2 는 바이브 코딩의 환상과 명세 중심 개발로의 회귀 를 다뤘다 — 마법이 끝난 자리에서 산업이 다시 명세서 라는 닻을 잡은 결. Part 3 은 자율 에이전트와 하네스 를 다뤘다 — 명세 위에서 AI 가 자율적으로 안전하게 일하는 시스템 골격.
세 Part 가 합쳐져 책 표어 "AI-Native Vibe Coding: No Design, No Code" 와 명제 "설계 없이는 코딩이 안 된다" 의 마지막 자리에 도달한다. 설계는 더 이상 코드를 짜기 전 그리는 그림 이 아니다. 설계는 AI 가 작동하는 시스템 그 자체 다 — 명세서 (Part 2) 위에서 4 대 요소 (Part 3) 가 자율 에이전트 (Ch 7) 와 함께 작동하는 살아있는 시스템. 마지막 마무리 (다음 단위) 가 책 한 권을 닫는 자리다.
9.6 용어 정리
- 점진적 하네스 통합 (Progressive Harness Integration): 기존 프로젝트에 4 대 요소를 우선순위에 따라 단계적으로 도입하며 각 단계의 운영 안정성을 측정 후 다음 단계로 진행하는 자세
- Big Bang 도입 (Big Bang Rollout): 새 시스템을 한 번에 모두 도입하는 자세 — 1980 년대 ERP 에서 70% 실패율을 기록한 패턴
- 점진적 도입 (Phased Rollout): 단계별로 일부씩 도입하며 매 단계의 안정성을 측정 후 진행하는 자세 — 1990 년대 후반 ERP 에서 정착률을 30% → 80% 로 뒤집은 패턴
- DORA (DevOps Research & Assessment, 2014~): Google 의 DevOps 측정 프레임워크. 4 대 지표로 운영 성숙도 측정
- 배포 빈도 (Deployment Frequency, DORA 1 지표): 일주일/하루에 몇 번 배포하는가
- 변경 리드타임 (Lead Time for Changes, DORA 2 지표): 코드 작성 → 운영 배포까지 시간
- 변경 실패율 (Change Failure Rate, DORA 3 지표): 배포된 변경 중 사고를 일으킨 비율
- MTTR (Mean Time to Recovery, DORA 4 지표 — 평균 복구 시간): 사고 후 복구까지 시간
- 점진적 과부하 (Progressive Overload, 운동 생리학 비유): 단계마다 5~10% 씩 부하를 늘리는 운동 원리. 한 번에 모두 늘리면 부상, 점진적이면 6 개월 후 목표 도달
- slow and small is fast (천천히 작게가 결국 빠르다): Karpathy 가 박은 산업 격언 — 점진적 자세의 핵심 명제
9.7 더 읽을거리
위키 카드:
- concept/agentic-engineering — 에이전틱 엔지니어링의 마무리 자리
- concept/multi-layer-guardrail — 4 대 요소 협력의 결
- entity/karpathy — slow and small is fast 인용
- term/architecture-fitness-harness — 아키텍처 적합성 검증 패턴
- concept/hooks-6-events — Hooks 6 이벤트 정의
1차 출처:
- DORA Accelerate State of DevOps Report — 2014 ~ 매년 발행
- Forsgren et al., Accelerate: The Science of Lean Software and DevOps (2018) — DORA 4 지표 표준화
- 1980 년대 ERP Big Bang 도입 사례 연구 (SAP, Oracle 사례)
- Karpathy "slow and small is fast" (2026)
Diagram 명세 블록
[[DIAGRAM:9-1]] 5 단계 단계적 도입 타임라인
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 9-1] Big Bang (1 주말) vs 점진적 (5 단계 ≈ 1~2 개월) — 같은 4 대 요소 도입 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ Big Bang 접근 │
│ ───────── │
│ 한 번에: ████████████████████████ 4 대 요소 모두 (PR 1,200 줄) │
│ 직후 : ██ 팀 거부 + 작업 정지 │
│ 다음 : ██ 되돌림 결정 │
│ 결과 : ❌ closed (not merged) │
│ │
│ ════════════════════════════════════════════════════════ │
│ │
│ 점진적 접근 │
│ ────── │
│ 1 단계: ██ Rules (`CLAUDE.md`) ─ 1 시간 │
│ 2 단계: ███ Hooks + 측정 시작 ─ 1.5 시간 │
│ 3 단계: ██ Commands 1 개 ─ 1 시간 │
│ 4 단계: ████ Skills 1 개 ─ 2 시간 │
│ 5 단계: ██████ 통합 + 회고 + DORA 비교 ─ 3 시간 │
│ 결과 : ✅ 4 대 요소 안정 정착 + 변경 실패율 -30% │
│ │
│ ╳ 같은 목표 → 다른 결과 │
│ ╳ Big Bang: 1 주말 작성 + 1 달 디버깅 + 되돌림 / 점진적: 5 단계 ≈ 1~2 개월 (누적 8 시간) + 정착 │
│ │
├────────────────────────────────────────────────────────────────────┤
│ 출처: 본 책 §9.4 + ERP 도입 사례 연구 │
└────────────────────────────────────────────────────────────────────┘
[[DIAGRAM:9-2]] DORA 4 지표 5 단계 변화
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 9-2] 5 단계 단계적 도입 시 DORA 4 지표 변화 (산업 평균 사례) │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ① 배포 빈도 (주당 회수) │
│ 1 단계: ██ 2 회 (기준선) │
│ 3 단계: ███ 2.5 회 │
│ 5 단계: ███ 3 회 (+50%) │
│ │
│ ② 변경 리드타임 (시간) │
│ 1 단계: ████ 4 시간 │
│ 3 단계: ███ 3 시간 │
│ 5 단계: ██ 2 시간 (-50%) │
│ │
│ ③ 변경 실패율 (%) │
│ 1 단계: ████ 28% (기준선) │
│ 3 단계: ███ 23% │
│ 5 단계: ██ 19% (-32%) │
│ │
│ ④ MTTR (평균 복구 시간) │
│ 1 단계: ████ 4 시간 │
│ 3 단계: ██ 2 시간 │
│ 5 단계: █ 1.5 시간 (-62%) │
│ │
│ ╳ 5 단계 누적 8 시간 투자 → 4 지표 모두 30~62% 개선 │
│ ╳ ROI 회수 시점: 5 단계 완료 직후부터 매 작업마다 누적 │
│ │
├────────────────────────────────────────────────────────────────────┤
│ 출처: 본 책 §9.3.2 + DORA Accelerate Report │
└────────────────────────────────────────────────────────────────────┘