업데이트 내역

운영 원칙

• 근거 기반: 외부 자료를 읽은 날짜와 자료 발행일을 함께 기록합니다.
• 해석 우선: 새 소식을 적는 것보다, 그 변화가 이 책의 해석을 어떻게 바꾸는지 먼저 적습니다.
• 문서 구조와 해석 분리: 목차 수정, 역링크 추가 같은 편집 변화와 관점 변화는 나눠 기록합니다.
• 관찰 목록 유지: 어떤 소스를 계속 볼지 명시해 업데이트 감각이 개인 의존이 되지 않게 합니다.

관찰할 외부 소스

변경 기록

2026-04-01

문서 구조 변경

• 하네스 엔지니어링 신규 핸드북 초판 작성
• 하네스의 정의를 프롬프트 기법이 아니라 작업 환경/평가/운영 설계로 정리
• repo-readable-systems, evaluation-loops, team-rollout 장 추가
• engineering-mechanics 장 추가
• 사례 허브에서 끝나지 않도록 case-openai, case-anthropic, case-toss, case-gstack, case-revfactory 상세 페이지 추가
• domain-playbooks, scenario-frontend-team, scenario-platform-team, scenario-payments-team, scenario-ai-product-team 추가
• OpenAI, Anthropic, Toss, gstack, revfactory/harness 사례 비교를 아코디언과 비교표로 확장
• Files, Tabs, Steps, Mermaid 기반 시각화 전면 보강
• 팀이 바로 사용할 수 있는 체크리스트, 점수표, rollout 플랜, 운영 루틴 장 추가
• engineering-mechanics와 checklist에 최소 하네스 아키텍처, MVP 패키지, load-bearing vs ritual 판정 기준 보강
• verification.mdx 추가
• 기존 관련 책들에 역링크 추가
• handbook 책 생성을 위한 scaffold-book.mjs 스크립트 추가
• handbook ESLint ignore에 .next-* 생성 디렉터리 제외 규칙 추가

해석 변경

• 이전 해석: 범용 하네스는 시작점이고 결국 자기 하네스로 수렴한다.
• 새 해석: 자기 하네스로 수렴한다는 말의 핵심은 "개인 비법 축적"이 아니라, repo-readable 시스템, load-bearing 검증 루프, executable SSOT, domain layer, garbage collection을 팀 운영체계로 외재화하는 데 있다.
• 추가 해석: 하네스는 추상적 작업 방식이 아니라 입력 구조, 상태 외재화, 검증 인터페이스, 승인 경계, retry budget, cleanup 루틴을 설계하는 엔지니어링 레이어다.
• 추가 해석 2: 하네스는 회사 사례로만 이해하면 추상적일 수 있고, 프론트엔드/플랫폼/결제/AI 제품처럼 도메인별 실패 모드에 맞춘 플레이북으로 번역될 때 비로소 실제 도입 문서가 된다.
• 추가 해석 3: 좋은 하네스는 문서 수나 단계 수가 아니라, 없어졌을 때 다시 실패가 늘어나는 요소만 남기는 구조여야 하며, 최소 하네스 패키지와 과설계 경계를 함께 제시해야 실무 문서로 완결된다.
• 변경 이유: 전달받은 다섯 자료를 함께 읽으면, 공통으로 반복되는 축이 repo/doc structure, planner/evaluator, workflow distribution, domain-specific validation, cleanup이라는 점이 더 명확하게 드러난다. 또한 사례를 비교만 하면 추상적으로 남기 쉬워, 실제 도입 장면과 기술 메커니즘을 사례별 페이지로 해부하는 편이 더 실무적이라고 판단했다.

영향 챕터

• index.mdx
• foundations.mdx
• repo-readable-systems.mdx
• five-elements.mdx
• engineering-mechanics.mdx
• evaluation-loops.mdx
• case-studies.mdx
• case-openai.mdx
• case-anthropic.mdx
• case-toss.mdx
• case-gstack.mdx
• case-revfactory.mdx
• domain-playbooks.mdx
• scenario-frontend-team.mdx
• scenario-platform-team.mdx
• scenario-payments-team.mdx
• scenario-ai-product-team.mdx
• make-it-yours.mdx
• team-rollout.mdx
• checklist.mdx
• operations.mdx
• verification.mdx
• updates.mdx
• apps/handbook/scripts/scaffold-book.mjs
• packages/eslint-config/base.js

근거 링크

• https://openai.com/ko-KR/index/harness-engineering/
• https://www.anthropic.com/engineering/harness-design-long-running-apps
• https://toss.tech/article/harness-for-team-productivity
• https://github.com/garrytan/gstack
• https://github.com/revfactory/harness

기록 템플릿

YYYY-MM-DD

문서 구조 변경

• ...

해석 변경

• 이전 해석:
• 새 해석:
• 변경 이유:

영향 챕터

• ...

근거 링크

• ...