운영: 엔트로피와 가비지 컬렉션
하네스가 시간이 지나며 망가지는 이유와 이를 줄이는 운영 루틴을 설명합니다.
하네스는 한 번 잘 만든다고 끝나지 않습니다. 오히려 시간이 지날수록 더 쉽게 망가집니다.
왜 하네스는 망가지는가
1. 문서 드리프트
코드는 바뀌었는데 문서는 그대로 남습니다. 특히 팀 규칙이 여러 문서에 분산돼 있으면 stale context가 빠르게 쌓입니다.
2. 워크플로우 드리프트
처음에는 잘 맞던 slash command, hook, checklist가 새 릴리즈 흐름이나 새 모델 특성과 어긋날 수 있습니다.
3. 기준의 노후화
예전에는 꼭 필요했던 review 단계나 보조 역할이, 모델 성능이 좋아진 뒤에는 과한 오버헤드가 될 수 있습니다.
4. 암묵지 재유입
사람들이 급할수록 규칙을 문서화하지 않고 채팅이나 구두로 해결합니다. 그러면 하네스 바깥에 또 다른 "진짜 규칙"이 생깁니다.
OpenAI 관점에서 보면 왜 cleanup이 핵심인가
OpenAI 글이 강조하는 "garbage collection"의 요지는 단순 정리가 아닙니다. 에이전트가 읽는 리포가 점점 더 중요한 만큼, 지식 저장소의 엔트로피가 곧 생산성 저하로 연결된다는 뜻입니다.
즉:
- 오래된 문서 = 잘못된 컨텍스트
- 깨진 command = 잘못된 실행 경로
- 과도한 절차 = 느린 throughput
운영 루틴
좋은 하네스는 정리 작업을 정기 업무로 포함합니다.
| 주기 | 해야 할 일 |
|---|---|
| 매주 | 깨진 링크, 실패한 명령, 자주 발생한 QA 이슈 확인 |
| 격주 | stale 문서, unused skill, 중복 규칙 정리 |
| 매월 | 승인 정책, 테스트 게이트, 도메인 규칙 재검토 |
| 모델 업그레이드 시 | 불필요해진 scaffolding 제거, 새 실패 모드 확인 |
- broken link / broken command 확인
- 최근 QA 누락 패턴 수집
- release note / updates 동기화
- 오래된 규칙 제거
- approval policy와 release gate 재검토
- 도메인 문서 ownership 확인
- planner/evaluator가 여전히 load-bearing인지 재검토
- 과도한 review 단계 삭제 검토
- 새 실패 모드와 새 자동화 기회 점검
점검해야 할 운영 지표
- 같은 요청에 대한 결과 편차
- 리뷰에서 반복 지적되는 항목 수
- QA에서 뒤늦게 발견되는 결함 비율
- stale 문서 발견 건수
- 승인 누락 또는 잘못된 승인 건수
- 브라우저/로그 검증 없이 머지된 변경의 사고 비율
garbage collection backlog 예시
| 대상 | 왜 위험한가 | 처리 방식 |
|---|---|---|
| 너무 긴 규칙 파일 | 읽히지 않거나 stale 될 확률이 높음 | TOC 문서 + 하위 docs로 분리 |
| 거의 안 쓰는 slash command | 팀을 혼란스럽게 함 | usage 기준으로 삭제 또는 통합 |
| 존재만 하고 검증 안 되는 checklist | false confidence를 줌 | 자동화하거나 폐기 |
| 예전 모델 기준으로 만든 보조 역할 | 속도만 늦추고 품질 이득이 적음 | 실험 후 삭제 또는 축소 |
가비지 컬렉션 대상
다음은 정기적으로 버리거나 줄여야 할 것들입니다.
- 더 이상 읽히지 않는 거대한 규칙 파일
- 한 번 만들고 쓰지 않는 slash command
- 현재 아키텍처와 맞지 않는 예전 설계 문서
- 모델이 이미 충분히 잘하는데도 남아 있는 과도한 수동 체크
- 근거 없이 늘어난 역할 분리
운영 원칙
하네스의 목적은 통제 그 자체가 아니라, 적은 비용으로 안정적인 성능을 얻는 것입니다. 더 이상 load-bearing이 아닌 절차는 과감히 줄여야 합니다.
하네스 운영의 책임자
이상적으로는 다음이 분리되어야 합니다.
| 책임 | 담당 |
|---|---|
| 도메인 규칙 최신화 | 팀 리드 또는 도메인 오너 |
| 문서/링크/규칙 정리 | 문서 오너 또는 rotating owner |
| 평가 기준 유지 | 리뷰어/QA/플랫폼 역할 |
| 모델 업그레이드 후 재검토 | AI 플랫폼 오너 또는 도입 리드 |
한 사람이 전부 책임지더라도, 책임 자체는 명시되어 있어야 합니다.
운영이 잘 되는 팀의 특징
- 변경 이유가
updates로그에 남아 있다 - 문서와 워크플로우가 함께 수정된다
- 모델이 좋아졌다고 무조건 단계를 빼지 않고 실제 품질로 판단한다
- 개인의 비법이 반복되면 바로 명령, 스킬, 체크리스트로 외재화한다
운영이 무너지는 전형적 패턴
| 패턴 | 결과 |
|---|---|
| command만 늘고 삭제는 안 함 | 아무도 뭘 써야 하는지 모름 |
| 문서만 늘고 검증은 안 함 | stale context가 쌓임 |
| 새 모델이 나올 때마다 모든 절차를 다시 붙임 | 복잡성만 증가 |
| 승인 기준이 사람마다 다름 | 위험 작업에서 일관성이 무너짐 |
결론
하네스 엔지니어링의 마지막 단계는 설계가 아니라 운영입니다. 잘 만든 하네스를 오래 유지하려면, 엔트로피를 전제로 두고 정리 작업을 시스템화해야 합니다.