Complexity Analysis Report

Enterprise Harness is
Fundamentally Hard

지난 6개월간 직접 구축한 AI 협업 시스템과 분산 설계 문서 분석을 통해 도달한 결론 — 기업용 AI 하네스 시스템의 O(n²) 복잡도 문제는 기술이 아니라 조직의 문제다. 현재 AI 하네스 생태계에서 "개인 최적화 → 조직 확장"은 미해결 열린 문제이다.

작성일 2026-05-01

근거 6개월 직접 구축 실증 + 분산 설계 문서 v0.1

01 — Background

왜 이 분석을 하게 되었는가

1.1 개인 하네스 구축 여정

지난 6개월간 Claude Code 기반 AI 협업 시스템(~/.claude/)을 구축·진화시켜 왔다. 이 시스템은 다음을 포함한다:

50+

Global Rules

코드 리뷰, 보안, 프론트엔드, 백엔드, Flutter, QA 등

15+

HARD Hooks

qa-gate-before-push, no-localstorage, mid-loop-question-detector 등

100+

Skills

self-improve, init-project, user-proxy-agent, autoresearch 등

30+

Agents

bug-fixer, code-reviewer, frontend-specialist 등

Supervisor Pipeline Phases

Codex loopy-era 자가개선 루프

Dual Model Review

Claude + Codex(GPT-5.4) 병렬 adversarial review

1.2 분산 확장 시도

이 개인 시스템의 성공에 힘입어 distributed-harness-design_1.md를 작성했다. 핵심 아이디어:

• 각 Worker가 독립 하네스를 유지하며 Host의 task를 수행
• Capability Manifest 기반 작업 매칭
• Ed25519 서명 + TLS 보안

1.3 결론에 도달한 순간

"왠만한 기업이나 대규모 사용자 레벨에선 이거 쓰기 힘들겠다는 생각이 강하게 듭니다, 너무 복잡해요."

이 판단은 직감이 아니라 6개월간의 실증적 경험에서 나온 구조적 결론이다.

02 — Quantitative Analysis

개인 하네스 복잡도의 정량적 분석

2.1 구성 요소 인벤토리

Global Rules

HARD Hooks

Skills

Pipeline Phases

Interactions O(n²)

계층	수량	유형	관리 부담
Rules (글로벌)	50+	마크다운 규칙 파일	모순 감지, 장기 미트리거 정리, cross-project 승격
HARD Hooks	15+	Bash 스크립트	exit code 관리, classify() 동시 업데이트, 순서 의존성
Skills	100+	SKILL.md + 스크립트	트리거 조건 관리, 버전 호환성
Agents	30+	타입별 전문화	도구 권한 분리, prompt 최적화
Supervisor Pipeline	14단계	Python + Bash	단계 간 상태 전달, 실패 복구
Signal Collectors	5종	fix_commit, recurrence 등	오탐/미탐 튜닝
QA Gate	3중	web-qa-tester + agent-browser + expect-cli	크로스체크 정합성
Dual Model Review	2모델	Claude + GPT-5.4	비교 테이블 생성, 의견 충돌 해결
Memory System	2종	memory-bank + episodic-memory	검색 정확도, 만료 관리
Sync	1시스템	cc-sync	user-scope ↔ project-scope 경계

2.2 규칙 간 상호의존성

개인 하네스에서 이미 발생한 복잡성 폭발 사례:

사례 1규칙 모순

convergence-loop-no-mid-question(멈추지 마) vs completion-verification(멈춰서 검증해) — 범위가 다르지만 경계가 모호하여 Claude 자신도 어느 규칙을 따를지 혼란.

사례 2Hook 충돌

qa-gate-before-push가 .qa-cycle-passed 요구 → 그런데 .codex-review-passed도 별도 요구 → 시간 제약(1시간) 내에 양쪽 다 만족해야 함. 새 커밋을 만들면 해시가 바뀌어 양쪽 모두 갱신 필요.

사례 3Scaffold Bloat

self-improve가 fix 커밋마다 새 규칙 생성 → Curator 단계 부재로 약한 규칙이 무한 누적. 별도 정리 프로세스가 필요해짐.

사례 4Scope 경계 미확정

M2(Hook Scope Classifier)에서 3주간 정체 — global vs project scope 결정이 본질적 난제. 개인 1대에서도 해결 못한 문제.

2.3 복잡도 증가 곡선

핵심 통찰: 규칙 수가 선형으로 늘어나도, 규칙 간 상호작용은 O(n²)로 증가한다. 50개 규칙 = 최대 1,225개의 잠재적 상호작용.

03 — Distributed Protocol

분산 프로토콜이 추가하는 복잡도 레이어

3.1 레이어별 복잡도 증가

레이어	개인 하네스	분산 하네스 추가 사항	배수
신뢰 (Trust)	같은 프로세스, 암묵적	Ed25519 keypair, TLS, 서명, 세션 토큰, nonce/replay 방어, pubkey 화이트리스트	×5
가입 (Join)	코드에서 즉시 등록	승인 게이트 + pubkey 화이트리스트 + 운영자 UI + PENDING→APPROVED 상태머신	×3
통신 (Comm)	함수 호출 / IPC	WebSocket over TLS + JSON-RPC 2.0 + 서명 메시지 + permessage-deflate	×4
장애 (Failure)	프로세스 단위	네트워크 파티션, 노드 다운, Heartbeat(10s/30s/60s), idempotency_key, 중복 결과 처리	×6
능력 (Capability)	정적 코드 명시	동적 Capability Manifest + 런타임 갱신(CAPABILITY_UPDATE) + dispatch 매칭	×3
결과 검증	로컬 QA 게이트	Schema 검증 + 서명 검증 + redundant execution(선택) + Aggregator	×3
관찰성 (Observability)	로컬 로그 + 텔레그램	Audit Log(append-only) + 메트릭(Worker별/Host별/Task별) + trace_id 분산 추적	×3

3.2 상태 머신의 폭발

상태 조합: 7(task) × 6(worker) = 42가지 상태 조합. 각 조합에 대한 처리 로직이 필요하다.

3.3 장애 시나리오 매트릭스

장애	개인 하네스	분산 하네스
프로세스 크래시	재시작	Heartbeat 타임아웃 → STALE → 재할당
중간 결과 손실	로컬 파일 복구	idempotency_key 기반 재시도 + 중복 결과 dedup
능력 부족	즉시 에러	TASK_REJECT → 다른 Worker 선택 → 능력 매칭 재실행
부분 실패	전체 재시도	fail-fast / best-effort / retry-then-fail 정책 선택
Host 다운	N/A	Worker 로컬 큐 저장 → 재연결 시 flush → audit log 복원

04 — Enterprise Layers

기업용 하네스가 추가하는 시스템 계층

4.1 개인에서 기업으로 갈 때 쌓이는 레이어

개인 하네스 위에 기업 운영을 위한 레이어가 올라가면, 각 레이어가 곱셈으로 복잡도를 증가시킨다:

4.2 비유: 이것은 무엇을 만드는 것인가

구축 요소	기존 서비스 비유
분산 task 할당 + 결과 수집	AWS Lambda + Step Functions
Capability 매칭 + dispatch	Kubernetes Scheduler
하네스 규칙 거버넌스	Terraform Policy as Code (OPA/Sentinel)
팀 간 scope 조율	GitHub CODEOWNERS + Branch Protection
Observability + SLA	Datadog + PagerDuty

결론: Kubernetes + Terraform + GitHub Enterprise를 동시에 만드는 것에 가까움.

05 — Five Structural Barriers

조직 확장이 본질적으로 어려운 5가지 이유

5.1 암묵적 지식 → 명시적 전파 Difficulty: 5/5

개인

규칙의 "왜"를 본인만 앎

기업

모든 팀원이 이해해야 함

50개 rules의 각각에는 "근거(마찰 사례)"가 있다. 예를 들어 tone-and-honorific.md는 "2026-04-21 '커밋해?' 발언에 사용자 강한 불만"이라는 구체적 사건에서 파생됐다. 이런 컨텍스트를 10명의 팀원에게 전달하는 비용은?

정량화: 50개 규칙 × 평균 3개 근거 = 150개 사건 컨텍스트 전달 필요.

5.2 즉각적 피드백 → 비동기 피드백 Difficulty: 4/5

개인

실패하면 본인이 바로 수정

기업

실패가 다른 Worker에서 발생

분산 디버깅은 로컬 디버깅의 10배 어렵다. "내 하네스에서는 됐는데 저 Worker에서 안 되는" 상황에서 Capability Manifest 불일치인지, 네트워크 문제인지, 버전 차이인지 판별해야 한다.

5.3 단일 진화 경로 → 다중 진화 경로 Difficulty: 5/5

개인

self-improve가 1개 방향으로 수렴

기업

각 Worker의 harness가 독립 진화

설계 문서 9.3절의 "공유 메모리" 문제:
• 각 Worker가 학습한 패턴을 공유 KG에 push → 노이즈 폭발 위험
• contribution gate + provenance tracking + 신뢰도 점수 필요
• "누가 KG의 schema governance를 하는가?" — 미해결 문제

5.4 커뮤니케이션 비용 0 → N² Difficulty: 4/5

개인

모든 결정이 내 머릿속

기업

Worker 간 capability 교차, 결과 합의

Brook's Law의 AI 에이전트 버전: Worker가 N대이면 잠재적 통신 경로는 N(N-1)/2. 10대 → 45경로, 100대 → 4,950경로.

5.5 무제한 실험 → 제한된 실험 Difficulty: 3/5

개인

실패해도 나만 손해

기업

실패하면 다른 사람의 작업에 영향

loopy-era의 핵심인 "자가개선 루프"는 실험과 실패를 전제한다. 그러나 조직에서는:
• self-improve가 만든 규칙이 다른 팀원의 워크플로우를 깨뜨릴 수 있음
• rollback이 분산 상태에서는 극도로 어려움
• "checkpoint-before-mutation"의 분산 버전은 분산 트랜잭션 문제

06 — The Core Bottleneck

user-proxy의 확장 불가능성 — 가장 핵심적인 병목

convergence-loop-no-mid-question의 "사용자가 시작을 명시했으므로 수렴까지 무정지 반복"이라는 전제는, "시작을 승인한 사람 = 결과를 받는 사람 = 품질 기준을 정한 사람"일 때만 성립한다. 기업에서 이 세 역할은 거의 항상 다른 사람이다.

07 — M2 Stall

M2 정체의 의미 — scope 경계 결정은 본질적 난제

7.1 loopy-era-runtime-alignment 현황

DONEM0Baseline Freeze현재 상태 스냅샷

DONEM1Runtime Drift Sync설치된 런타임과 소스 정렬

STALLEDM2Hook Scope Classifierglobal → project scope 전환 (3주 정체)

PENDINGM3Project Installerproject-scope 설치 자동화

PENDINGM4Staged Migration점진적 이관

PENDINGM5Self-Evolve Alignment자가개선 정렬

PENDINGM6Scorecard Split메트릭 분리

PENDINGM7Operationalization운영화 + 드리프트 방지

7.2 M2가 어려운 이유

M2의 핵심 질문: "이 hook은 모든 프로젝트에 적용되어야 하는가(global), 아니면 특정 프로젝트에만 적용되어야 하는가(project)?"

개인 1대에서도 이 판단이 어려운 이유:

1. qa-gate-before-push — 모든 프로젝트에 필요? Flutter 프로젝트도? 문서 전용 repo도?
2. no-localstorage — 웹 프로젝트에만 해당. 백엔드 전용 프로젝트에서는 불필요한 검사
3. portless-required — dev 서버가 있는 프로젝트만. 라이브러리 프로젝트에서는 의미 없음

7.3 조직으로 확장하면

08 — UFC-Harness Lessons

UFC-Harness 경험에서의 현실 인식

8.1 비용 현실

항목	v1	v2
Anthropic API (judge)	$200/mo	$0 (제거)
OpenAI API (judge)	$50/mo	$0 (제거)
Vercel	$20	$20
Supabase	$25	$25
Total	$295/mo	$45/mo

v1→v2의 가장 큰 교훈: "서버 측 LLM 호출을 0으로 만들어야만 운영 가능"

8.2 "공정한 비교"의 비자명성

하네스끼리 경쟁시키는 것만으로도:

• commit history 검증 (author, 시간 분포, force-push 탐지)
• AI marker 강제 (Co-Authored-By)
• Single squash commit 거부
• 참가자 코드 실행 sandbox 선택 (Vercel Sandbox vs GitHub Actions vs Deno isolate)

이것이 동일 조직 내 하네스 품질 비교로 확장되면 더 복잡해진다.

09 — Conclusion

결론과 시사점

9.1 결론에 도달한 경로

발견

개인 시스템 6개월
85~90% 완성

장벽

M2 Scope 경계
본질적 어려움

확장 시도

분산 하네스
설계 문서 작성

현실 인식

N² 복잡도
체감

결론

조직 확장은
열린 문제

9.2 이 결론이 정확한 이유

O(n²)

이차적 복잡도 증가

규칙 수 n에 대해 상호작용은 O(n²)로 증가. 50개 규칙 = 1,225개 잠재적 상호작용.

∅

미해결 열린 문제

Karpathy의 "harness engineering", Microsoft APM 모두 개인 loopy-era 수준의 자가개선 루프까지 도달 못함.

≠

기술 ≠ 조직

user-proxy의 "판단 기준 통일"은 기술 문제가 아니라 조직 정치 문제. 누구의 기준으로 QA PASS를 판정하는가?

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

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

9.4 최종 판단

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

만드는 것은 엔지니어링이지만, 운영하는 것은 조직 문화의 변화를 수반한다. 개인 loopy-era를 조직으로 확장하는 것은 아직 누구도 해결하지 못한 열린 문제이며, 이 복잡도를 정직하게 인식하는 것이 해결의 첫 걸음이다.

이 분석은 6개월간의 실증적 경험에서 나온 구조적 결론이다. "직감"이 아니라 50+개 rules, 15+개 hooks, 14단계 파이프라인을 직접 구축하고 운영하면서 체감한 복잡도의 정량적 기록이다.

Deep Dives

상세 분석 페이지

Part 01

개인 하네스의 은밀한 복잡성

50+ rules, 15+ hooks, 14단계 파이프라인의 정량적 분석. 규칙 간 O(n²) 상호작용과 self-improve의 Scaffold Bloat 문제.

ruleshooksself-improvecomplexity

Part 02

분산 프로토콜의 복잡도 폭발

네트워크 경계가 추가하는 7개 레이어. 42가지 상태 조합, 장애 시나리오 매트릭스, 기업 확장 시 지수적 복잡도.

protocolsecurityfailureenterprise

Part 03

조직 확장의 구조적 한계