왜 결국 자기 하네스로 가는가
범용 하네스를 참고하되, 왜 결국 팀 고유의 하네스로 수렴해야 하는지 설명합니다.
핵심 요약
- 핵심 답은 "시작은 빌리고, 성능은 결국 자기 것으로 만든다"이며, Borrow → Observe → Encode → Refine 4단계로 팀 고유 하네스에 수렴합니다.
- 범용 하네스는 일반적인 습관은 가르쳐주지만, 우리 팀이 어디서 자주 무너지는지(도메인 특화 실패)까지는 모릅니다.
- 자기 하네스는 암묵지가 아니라 외재화된 팀 운영체계로, 자동/승인 경계·최신 진실 문서·통과 기준·역할 분리·아키텍처 불변식을 리포와 workflow에 명시합니다.
- 폴더 구조·문서 진입점·역할 이름은 그대로 가져와도 되지만, 도메인 규칙·승인 지점·테스트 게이트·handoff 포맷은 팀에 맞게 재설계해야 합니다.
- "나는 이 파일부터 읽는다", "여기서 승인받는다" 같은 개인 요령을 AGENTS.md 읽기 경로·release gate·자동화 스크립트로 바꿀 때 비로소 하네스가 됩니다.
질문은 보통 이렇게 시작합니다.
남이 만든 하네스를 잘 익히면 되는가, 아니면 결국 우리만의 하네스를 만들어야 하는가?
답은 둘 다입니다. 시작은 빌리고, 성능은 결국 자기 것으로 만든다가 더 정확합니다.
왜 그대로 복제하면 한계가 오는가
범용 하네스는 대체로 아래를 잘 제공합니다.
- 기본 역할 분리 아이디어
- 범용 리뷰/QA/배포 흐름
- 문서/스킬/커맨드 구조 예시
- 자주 발생하는 실수에 대한 가드레일
하지만 팀이 실제로 부딪히는 실패는 대개 도메인에 따라 다릅니다.
예를 들면:
- 결제 팀은 승인과 정합성 검증이 핵심일 수 있음
- 백오피스 팀은 권한/감사 로그가 핵심일 수 있음
- 앱 팀은 브라우저/디바이스 QA와 배포 검증이 핵심일 수 있음
- 플랫폼 팀은 아키텍처 불변식과 공통 모듈 준수가 핵심일 수 있음
범용 하네스는 "좋은 일반 습관"은 가르쳐주지만, 우리 팀이 어디서 자주 무너지는지까지는 모릅니다.
자기 하네스가 된다는 뜻
자기만의 하네스를 만든다는 말은 감각과 비법을 머릿속에 쌓는다는 뜻이 아닙니다. 오히려 반대입니다.
다음을 리포와 워크플로우 안에 또렷이 남긴다는 말입니다.
- 어떤 작업은 자동으로 진행하고 어떤 작업은 사람 승인을 받을지
- 어떤 문서가 최신 진실인지
- 어떤 테스트와 브라우저 시나리오를 통과해야 하는지
- 어떤 역할 분리가 실제로 성능을 올리는지
- 어떤 금지 규칙과 아키텍처 불변식을 항상 지킬지
중요한 차이
자기 하네스는 "암묵지"가 아니라 "외재화된 팀 운영체계"입니다.
복사할 것과 재설계할 것
| 그대로 가져오기 좋은 것 | 팀에 맞게 재설계해야 하는 것 |
|---|---|
| 기본 폴더 구조, 문서 진입점, 업데이트 로그 방식 | 도메인 규칙, 승인 지점, 테스트 게이트 |
| planner/reviewer/qa 같은 역할 이름 | 실제 역할 간 계약과 handoff 포맷 |
| 공통 slash command 패턴 | 어떤 명령을 누구에게 공개할지 |
| 브라우저/로그/테스트 연동 아이디어 | 어떤 시그널을 품질 판단에 쓸지 |
| cleanup cadence 개념 | 정리 주기, 책임자, 실패 보고 방식 |
어디서 무엇을 가져올 것인가
| 필요 감각 | 먼저 볼 사례 페이지 |
|---|---|
| 리포와 문서의 시작점 설계 | case-openai |
| 평가 루프와 retry budget | case-anthropic |
| 팀 배포와 executable SSOT | case-toss |
| sprint와 release gate | case-gstack |
| 하네스 생성 자체의 템플릿화 | case-revfactory |
자기 하네스로 수렴하는 4단계
Borrow: OpenAI, Anthropic, Toss, gstack, revfactory/harness 같은 외부 사례에서 패턴을 빠르게 흡수합니다.
Observe: 우리 팀의 반복 실패를 찾습니다. 어떤 작업에서 품질이 흔들리고, 어떤 승인 누락이 사고를 만들며, 어떤 브라우저/로그 검증이 빠져 있는지 봅니다.
Encode: 반복 실패를 문서, 테스트, 슬래시 커맨드, 스킬, 훅, 체크리스트로 바꿉니다.
Refine: 새 모델이 나오고 팀 구조가 바뀌면 하네스도 다시 단순화하거나 재구성합니다. 줄일 수 있는지는 감이 아니라 실험으로 판단합니다.
도메인별로 달라지는 지점
| 팀 유형 | 자기 하네스에서 특히 중요해지는 것 |
|---|---|
| 결제/정산 | 승인 지점, 정합성 검증, audit trail |
| 모바일 앱 | 브라우저/디바이스 QA, 배포 검증, 스토어 운영 체크 |
| 백오피스 / Admin | 권한, role-based access, 운영 런북 |
| 플랫폼 팀 | 아키텍처 불변식, 공유 모듈 경계, release gate |
| AI 제품 팀 | 평가셋, 모델 교체 검증, 안전 정책 |
판단 기준
자기 하네스가 잘 되고 있는지 보려면 아래를 봅니다.
- 새 팀원이 기존 고수와 비슷한 기본 품질로 작업을 시작할 수 있는가
- 같은 요청에 대한 결과 편차가 줄어드는가
- 리뷰어가 반복 지적하던 문제가 사전에 걸러지는가
- 문서와 워크플로우가 함께 업데이트되는가
- 모델 교체 후에도 핵심 작업 품질이 무너지지 않는가
"나만의 노하우"를 팀 시스템으로 바꾸는 체크포인트
| 개인 요령 상태 | 팀 시스템 상태 |
|---|---|
| "나는 이럴 때 브라우저를 꼭 켠다" | /qa-browser 같은 command로 공통화 |
| "나는 이 파일부터 읽는다" | AGENTS.md의 읽기 경로로 명시 |
| "나는 여기서 멈추고 승인 받는다" | release gate와 approval policy로 고정 |
| "나는 PR 전에 이걸 확인한다" | lint / typecheck / browser / release script로 자동화 |
당신 해석을 더 정확히 다듬으면
결국 자신만의 하네스 노하우를 쌓아야 한다는 방향은 맞습니다. 다만 그 노하우는 개인 감각으로 쌓이는 게 아니라, 팀이 재사용 가능한 규칙과 workflow로 외재화될 때 비로소 하네스가 됩니다.
결론
남의 하네스를 공부하는 일은 필요합니다. 하지만 목표는 그 방식을 암기하는 게 아니라, 우리 조직의 실패 패턴을 줄이는 실행 시스템으로 다시 짜는 것입니다.
당신이 읽고 느낀 "결국 자신만의 하네스 엔지니어링 노하우를 쌓아야 한다"는 감각은 맞습니다. 다만 그 노하우는 개인의 감이 아니라 팀의 코드화된 운영 규칙으로 쌓여야 합니다.