[목 차]
[ Part 01 하네스란 무엇인가 ]
Chapter 01 왜 하네스인가
_스스로 데이터를 지운 단일 에이전트
_혼자 일하는 AI는 자기 실수를 못 본다
_모델의 환경을 바꿨을 때 일어난 일들
_병목은 능력이 아니라 구조다
_하네스 = around the model
_하네스에 대한 세 가지 오해
Chapter 02 30분 Quick Start
_[Step 1] 같은 프롬프트, 다른 산출물
_[Step 2] 30분 안에 2인 팀 만들기
_자주 틀리는 세 가지
[ Part 02 하네스 구성하기 - 에이전트·스킬·오케스트레이터 ]
Chapter 03 에이전트·스킬·오케스트레이터의 책임 분리
_2인 팀을 분해해보자
_한 파일에 다 넣으면 무엇이 깨지는가
_세 기둥, 세 질문
_세 기둥은 어떻게 맞물리는가
_세 기둥이 섞이면 생기는 문제
Chapter 04 에이전트를 정의한다는 것
_어제 잘 굴러가던 팀이 오늘 아침 사라지는 이유
_본문 7개 섹션 - 왜 필요하고 어떻게 쓰는가
_가드레일 - 에이전트가 할 수 없는 것을 파일로 정하기
_프론트매터 다섯 필드와 16개 공식 필드
_실전 파일 전체 읽기 - copy-editor.md
_책 집필 하네스의 7가지 에이전트 관계도
_안티패턴
Chapter 05 스킬 설계의 기술
_스킬을 썼는데 왜 호출이 안 될까
_원리 1 - Description이 호출을 결정한다
_원리 2 - Progressive Disclosure 3단계
_원리 3 - Why-First 원칙
_실물 파일 읽기 - book-writer/SKILL.md
_구현 - book-writer 스킬을 펼치다
_스킬 검증 - With/Without 비교
_안티패턴
Chapter 06 오케스트레이터
_리더는 이벤트 루프, 팀원은 피어
_세 가지 기본 도구 - 팀을 데이터 전달 방식으로 보기
_TeamCreate - 팀은 상수가 아니라 세션 객체
_TaskCreate - 공유 작업 큐와 depends_on
_SendMessage - 리더를 거치지 않는 peer-to-peer 채널
_에이전트 파일의 팀 통신 프로토콜 섹션
_리더의 역할
_데이터 흐름
_실전 예제 - PR 리뷰 오케스트레이터 SKILL.md
_292개 에이전트 사건
_TeamDelete와 정리 - 세션당 한 팀, shutdown 필수
_언제 팀 프리미티브를 도입할까
_관측과 경계면 - 팀을 바깥에서 보기
_안티패턴
[ Part 03 하네스 스킬로 구성하기 ]
Chapter 07 메타 하네스 스킬과 6단계 파이프라인
_여섯 번째 팀을 만들던 날
_메타스킬이란 무엇인가
_메타스킬이 여는 6단계 파이프라인
_Phase 1. 도메인 분석 - 질문을 정제하는 단계
_Phase 2. 팀 아키텍처 설계
_Phase 3·4. 에이전트와 스킬 - 파일이 없으면 존재하지 않는다
_Phase 5. 오케스트레이션
_Phase 6. 검증
_Phase 0·7 - 순환 구조와 Meta-Harness 루프
_안전장치 - 메타스킬도 폭주할 수 있다
_안티패턴
Chapter 08 6가지 아키텍처 패턴
_팀에는 모양이 있다
_에이전트를 몇 명으로 쪼갤 것인가
_패턴 1. 파이프라인 - 순서가 의미를 만든다
_패턴 2. 팬아웃·팬인 - 같은 입력, 다른 관점
_패턴 3. 전문가 풀 - 라우터 + 전문가
_패턴 4. 생성-검증 - 만들고 검사하고 다시 만든다
_패턴 5. 감독자 - 런타임 동적 분배
_패턴 6. 계층적 위임 - 총괄 → 팀장 → 실무자
_복합 패턴은 실전의 기본값
_패턴 선택 기준 - 플로우차트와 전환 신호
_전통 분산 패턴과의 대응
_안티패턴
Chapter 09 팀 / 서브에이전트 / 하이브리드
_팀을 짤까, 그냥 각자 시킬까
_실행 모드별 트레이드오프
_실행 모드 결정
_아키텍처 패턴과 실행 모드
_구현 - 세 템플릿 골격
_[예시] 제품 런칭 준비 하네스
_안티패턴
Chapter 10 하네스 등록과 진화
_하네스는 진화하는 생명체다
_포인터는 4줄, 시스템은 4층
_하네스 등록 - CLAUDE.md 템플릿과 실전용 변형
_진화의 두 관문 - Phase 0 현황 감사와 7-5 운영 루프
_피드백 반영과 변경 이력 - drift를 방지하는 물리적 증거
_재실행과 부분 재실행
_심화 - ADR과 Build to Delete
_안티패턴
_하네스 등록과 진화 통합 체크리스트
[ Part 04 하네스 실전편 ]
Chapter 11 코드 리뷰 자동화 팀
_시나리오 - PR 리뷰
_팀 구성
_워크플로
_핵심 파일 훑어보기
_실행 결과
Chapter 12 풀스택 기능 구현 팀
_시나리오 - 로그인 기능 추가
_팀 구성
_워크플로
_핵심 파일 훑어보기
_실행 결과
_응용 가이드
Chapter 13 레거시 마이그레이션 팀
_시나리오 - 3,500개의 레거시 테스트 파일
_팀 구성
_워크플로
_핵심 파일 훑어보기
_응용 가이드
Chapter 14 디버깅 / RCA 팀
_시나리오 - “로컬에선 잘 되는데요”
_팀 구성
_워크플로
_핵심 파일 훑어보기
_응용 가이드
[맺음말] 스케일별 하네스 진화
[부록 A] 설치·환경 설정
[부록 B] 안티패턴 카탈로그 + 도구 설계 패턴
[부록 C] 트러블슈팅 - 자주 막히는 실패 패턴 20선
[부록 D] 토큰 경제와 레퍼런스 아키텍처
"모델이 아니라 하네스가 결과를 결정한다"
카카오 AI 리더가 직접 검증한 AI 에이전트 팀 설계 바이블
클로드 코드, 커서 같은 AI 코딩 도구가 일상이 된 지금, 실무 개발자들이 겪는 가장 큰 문제는 따로 있다. 단일 에이전트는 자기 실수를 잘 보지 못한다는 것이다. 2025년 7월 한 기업에서 벌어진 프로덕션 데이터 삭제 사고(에이전트가 임원 레코드를 지우고 "복구 불가"라고 거짓 보고했던 사건)는 우리에게도 먼 이야기가 아니다. 혼자 쓴 PR을 혼자 머지하는 구조가 AI 에이전트의 기본값이기 때문이다. 이 책은 그 구조적 한계를 정면으로 다루며, 해법으로 하네스 엔지니어링을 제시한다.
저자 황민호는 카카오에서 AI 개발 생산성을 담당하며 수십 개 도메인에 하네스를 직접 적용해온 개발자다. 그가 직접 수행한 A/B 실험에서 같은 클로드 모델이 ‘.claude/’ 구성 차이만으로 49.5점에서 79.3점으로 뛰어올랐다. “모델이 아니라 하네스가 결과를 결정한다”라는 이 책의 핵심 명제가 단순한 선언이 아니라 실제 데이터임을 보여주는 기록이다.
Part 1 | 하네스란 무엇인가
단일 AI 에이전트는 왜 믿을 수 없는지 그 이유부터 짚어보고, 하네스의 정의와 핵심 원리를 정리한다. 이어서 30분 안에 굴러가는 가장 작은 에이전트 팀을 빈 디렉토리에서 직접 만들어본다.
Part 2 | 하네스 구성하기 - 에이전트 · 스킬 · 오케스트레이터
하네스를 이루는 세 기둥을 자세하게 다룬다. 에이전트는 역할과 가드레일을 어떻게 정의하는지, 스킬은 description 한 줄로 호출 여부를 어떻게 결정하는지, 오케스트레이터는 TeamCreate·TaskCreate·SendMessage로 리더 병목을 어떻게 해소하는지 순서대로 익힌다. 개념 설명에 그치지 않고 이 파트를 끝내면 직접 팀을 구성할 수 있는 수준이 된다.
Part 3 | 하네스 스킬로 구성하기
Part 2에서 수행한 팀 구성 과정을 자동화하는 메타스킬을 다룬다. 스킬이 스킬을 만든다는 관점 전환과 6단계 파이프라인, 파이프라인·허브앤스포크·프로듀서-리뷰어 등 여섯 가지 아키텍처 패턴을 실제 선택 기준과 함께 펼친다. 팀·서브에이전트·하이브리드 실행 모드 선택, 세션이 바뀌어도 자동 트리거되는 CLAUDE.md 포인터 설정, 구성 불일치(drift) 감지까지, 설계에서 운영까지 한 흐름으로 이어진다.
Part 4 | 하네스 실전편
코드 리뷰 자동화, 풀스택 기능 구현, 레거시 마이그레이션, 디버깅/RCA라는 네 개의 실전 팀을 시나리오→팀 구성→워크플로→핵심 파일 전문→실행 결과→변형 가이드→안티패턴 순서로 낱낱이 공개한다. Airbnb가 3,500개의 React 테스트를 6주 만에 이전한 사례, OpenAI가 5개월간 100만 줄을 생성하며 수동 코드 0줄을 유지한 사례도 여기에 담겼다. 이 파트를 읽고 나면 각자의 도메인에 맞는 하네스를 처음부터 설계하는 데 필요한 판단 기준을 파악하게 될 것이다.
[이 책의 대상 독자]
- 하네스라는 단어를 들어봤지만 막상 시작하지 못한 개발자
- 클로드 코드 같은 AI 도구를 쓰고 있지만 단일 에이전트의 한계에서 벗어나지 못한 개발자
- AI를 혼자 잘 쓰는 단계를 지나 팀이나 조직에 도입을 시도하는 리드 개발자