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