결론과 시사점

9.1 결론에 도달한 경로

개인 시스템 6개월에 85~90% 완성 → M2 scope 경계에서 정체 → 분산 하네스 설계 문서 작성 → N² 복잡도 체감 → 조직 확장은 열린 문제라는 결론.

9.2 이 결론이 정확한 이유

O(n²)이차 복잡도 증가 — 규칙 수 n에 대해 상호작용은 제곱으로 증가. 규칙 50개 = 잠재 상호작용 1,225개.
∅ 미해결 열린 문제 — Karpathy(OpenAI 창립 멤버이자 전 테슬라 AI 총괄로, 이 분야의 흐름을 이름 짓는 인물)가 harness engineering이라는 말을 만들 만큼 업계가 주목하는 영역이고, Microsoft도 APM이라는 방식으로 달려들고 있다. 그런데 둘 다 개인 수준의 자가개선 루프에는 도달하지 못했다. 최전선이 아직 여기다.
≠ 기술 ≠ 조직 — user-proxy의 판단 기준 통일은 기술 문제가 아니다. 누구 기준으로 합격을 판정하느냐는 조직 정치의 문제다.

9.3 가능한 접근 방향 (미해결)

접근	설명	난이도
계층적 추상화	규칙을 L0(불변) / L1(회사) / L2(팀) / L3(프로젝트) / L4(개인)로 계층화	4/5
Manifest 기반 선언	Microsoft APM 방식 — 프로젝트별 manifest.yml로 필요한 부품만 선언	3/5
점진적 채택	전체 하네스가 아니라 품질 게이트 1개부터 시작, 조직이 성숙하면 확장	2/5
하네스 패키지 배포	검증된 하네스 구성을 회사 표준 패키지로 배포 (npm/pip 모델)	5/5

네 가지를 풀어 보면 이렇다. 계층적 추상화는 규칙에 직급을 부여하는 것 — 회사 헌법(불변)부터 개인 취향까지 층을 나눠서, 아래층이 위층을 못 건드리게 한다. Manifest 기반 선언은 뷔페식 — 풀세트를 강제로 먹이지 않고 프로젝트마다 필요한 부품만 골라 적게 한다. 하네스 패키지 배포는 앱스토어 모델 — 검증된 구성을 설치 한 번으로 받게 한다(가장 이상적이고 가장 어렵다). 그리고 점진적 채택.

주목할 건 난이도가 가장 낮은 점진적 채택이다. 전부 갖춘 하네스를 이식하려 들지 말고, 자동 품질 검사 하나부터 팀에 깔아 보는 것. 효과를 본 팀이 다음 부품을 스스로 원하게 만드는 것. 이 글의 모든 분석이 가리키는 현실적인 출발점이 그거다.

9.4 최종 판단

기업용 분산 하네스는 만들 수 있느냐의 문제가 아니다. 운영할 수 있느냐의 문제다.

만드는 건 엔지니어링이지만 운영하려면 조직 문화가 바뀌어야 한다. 개인 loopy-era의 조직 확장은 아직 누구도 풀지 못한 열린 문제고, 이 복잡도를 인정하는 데서 해결이 시작된다.

이 분석은 6개월 실증의 기록이다. rules 50+, hooks 15+, 14단계 파이프라인을 직접 만들고 굴리면서 몸으로 잰 복잡도를 숫자로 남긴 것이다.

상세 분석

근거 문서

분산 하네스 설계 v0.1 ~/Downloads/distributed-harness-design_1.md
loopy-era runtime alignment claude-code-site/docs/…/loopy-era-runtime-alignment/state.md
UFC-Harness SPEC v2 ~/Project/ufc-harness/SPEC.md
Codex loopy-era 분석 claude-code-site/start-harness-analysis.md
개인 하네스 시스템 ~/.claude/CLAUDE.md (rules, hooks, skills, agents)