02 — QUANTITATIVE ANALYSIS

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

2.1 구성 요소 인벤토리

먼저 한 사람짜리 시스템이 얼마나 큰지부터 보자. 표의 오른쪽 열이 중요하다. 부품마다 만들면 끝이 아니라 계속 관리해야 하는 일이 따라붙는다.

계층	수량	유형	관리 부담
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(중간에 묻지 말고 끝까지 일해라)은 멈추지 말라고 하고 completion-verification(끝났다고 말하기 전에 검증해라)은 멈춰서 검증하라고 한다. 범위가 다르니 공존할 수 있다는 게 설계 의도였는데 경계가 모호해서 Claude 자신도 어느 쪽을 따를지 헷갈려한다.

쉽게: 한쪽 벽에는 보고하지 말고 끝까지 일하라가, 다른 벽에는 끝나기 전에 꼭 검수받으라가 붙어 있는 사무실이다. 신입은 어느 벽을 봐야 하나.

사례 2 Hook 충돌

qa-gate-before-push(품질검사 통과 전에는 제출 금지)는 품질검사 통과 도장(.qa-cycle-passed)을 요구한다. 동료 AI의 검토 도장(.codex-review-passed)도 따로 요구한다. 둘 다 유효기간이 1시간이다. 그런데 작업물을 한 글자라도 고치면 작업물의 지문(해시)이 바뀌어서 두 도장이 동시에 무효가 되고, 처음부터 다시 받아야 한다.

쉽게: 서류 두 장이 다 유효기간 1시간인데, 서류 내용을 고치면 두 장 다 만료되는 민원창구다. 실제로 다섯 번 연속 반려당했다.

사례 3 Scaffold Bloat

self-improve가 fix 커밋마다 규칙을 하나씩 만들어낸다. 걸러내는 Curator 단계가 없으니 약한 규칙이 무한히 쌓인다. 결국 규칙을 정리하는 프로세스를 또 만들어야 했다. 규칙을 줄이려고 규칙을 늘리는 셈이다.

쉽게: 실수할 때마다 포스트잇을 붙이는 사람의 모니터는 석 달 뒤에 포스트잇으로 뒤덮인다. 어느 게 중요한지 아무도 모른다.

사례 4 Scope 경계 미확정

M2(Hook Scope Classifier)에서 3주를 멈췄다. 멈춰 세운 질문은 하나다. 이 hook은 global인가 project인가. 개인 컴퓨터 한 대에서도 답이 안 나온 문제다.

쉽게: 이 규칙이 회사 전체 규정인지 우리 팀 내규인지 정하는 문제다. 한 명짜리 회사에서도 3주를 못 정했다.

2.3 복잡도 증가 곡선 — 왜 제곱으로 느는가

여기가 이 글에서 제일 중요한 수학이다. 어렵지 않다. 단톡방을 떠올리면 된다. 두 명이 있는 방에는 대화 상대 조합이 1쌍이다. 다섯 명이면 10쌍, 열 명이면 45쌍이다. 사람이 한 명 늘 때마다 새 조합은 기존 인원수만큼 한꺼번에 늘어난다. 규칙도 똑같다. 규칙 하나하나는 멀쩡해도, 서로 영향을 주고받을 수 있는 쌍의 수는 제곱으로 는다.

규칙 수는 천천히 늘어도 충돌 후보 쌍은 제곱으로 — 50개면 1,225쌍이다

규칙 50개면 잠재적 상호작용이 최대 1,225개다. 물론 1,225쌍이 전부 실제로 충돌하지는 않는다(체감 5% 안팎). 그래도 5%면 60건이다. 머릿속에 들고 다닐 수 있는 숫자가 아니다. 사람의 인지 한계는 이미 한 명짜리 시스템에서 바닥났다.