Complexity Analysis Report · Enterprise Harness is Fundamentally Hard · Why Organizational Scaling Fails
하네스라는 AI 감시 장치를 회사로 넓히는 건 아직 아무도 못 푼 문제다
이 글의 출발점은 한 가지 질문이다. 혼자 쓰려고 만든 AI 작업 감시·자동화 장치, 즉 하네스(harness — AI가 '다 됐다'고 거짓말하지 못하게 규칙과 검증을 강제하는 장치)를 회사 전체로 넓힐 수 있을까? 답을 찾으려고 지난 6개월간 직접 만들어 굴린 AI 협업 시스템을 숫자로 뜯어봤다. 그리고 여러 대의 컴퓨터에 일을 나눠 돌리는 '분산' 설계 문서를 직접 써서 무엇이 더 필요한지 따져 봤다. 결론은 '아직 아무도 못 푼 숙제'다. 이유는 두 가지다. 첫째, 규칙이 하나씩 늘면 규칙끼리 부딪힐 수 있는 경우의 수는O(n²), 즉 규칙 수의 제곱에 비례해 폭발한다. 둘째, 그렇게 남는 문제는 기술로는 풀 수 없는 조직의 문제다. 지금의 AI 하네스 판에서'혼자 최적화한 시스템을 여러 사람이 함께 쓰도록 넓히기'는 아직 아무도 풀지 못한 열린 문제다.
작성일2026-05-01
근거직접 만들어 6개월 운영한 실측 + 분산 설계 초안 문서(v0.1)
01 — Background
왜 이 분석을 하게 되었는가
1.1 개인 하네스 구축 여정
지난 6개월간 Claude Code(터미널에서 AI에게 코딩을 시키는 도구) 위에 나만의 AI 협업 시스템(설정이 모여 있는 폴더 ~/.claude/)을 만들고 키워 왔다. 이 시스템은 다음으로 이뤄져 있다:
50+
Global Rules
여러 프로젝트에 공통으로 적용되는 작업 규칙. 코드 리뷰·보안·프론트엔드·백엔드·Flutter·QA 등을 다룬다
15+
HARD Hooks
훅(hook)은 특정 순간에 자동으로 끼어들어 검사하거나 막는 스크립트(작은 자동 실행 프로그램)다. '하드' 등급은 어기면 무조건 차단하는 강제 규칙이라는 뜻이다. 예: 검증을 통과하기 전엔 코드 업로드를 차단
100+
Skills
필요할 때 불러 쓰는 자동화 묶음. 자가개선(self-improve), 프로젝트 초기화, 사용자 대리 검증 등이 있다
30+
Agents
역할을 나눠 맡는 전문 AI 일꾼. 버그 수정, 코드 리뷰, 프론트엔드 담당 등이 있다
14
Supervisor Pipeline Phases
AI가 스스로 실수를 찾아 고쳐 나가는 자가개선 루프의 처리 단계
2
Dual Model Review
서로 다른 AI 둘(Claude와 GPT-5.4)이 동시에 서로의 결과를 트집 잡아 검증
1.2 분산 확장 시도
이 개인용 시스템이 잘 돌아가자, 이걸 여러 대의 컴퓨터로 나눠 돌리는 '분산' 설계 문서(distributed-harness-design_1.md)를 써 봤다. 핵심 아이디어는 이렇다:
• 각 일꾼(Worker) 컴퓨터가 자기 하네스를 그대로 갖고, 중앙(Host)이 내려준 작업(task)을 처리한다 • 각 일꾼이 '무슨 일을 할 수 있는지' 적어둔 능력 명세서(Capability Manifest)를 보고 알맞은 작업을 배정한다 • 위조를 막는 전자서명과 도청을 막는 암호화 통신으로 보안을 건다. 전자서명 방식은 Ed25519이고, 암호화 통신은 웹 주소창의 자물쇠 표시를 만드는 규약을 쓴다. (암호화 규약의 이름: TLS)
1.3 결론에 도달한 순간
"왠만한 기업이나 대규모 사용자 레벨에선 이거 쓰기 힘들겠다는 생각이 강하게 듭니다, 너무 복잡해요."
이 말은 6개월간 직접 굴려 보며 얻은 구조적 결론이다. 감으로 한 말이 아니다.
02 — Quantitative Analysis
개인 하네스가 실제로 얼마나 복잡한지 숫자로 따져보기
2.1 구성 요소 목록
0
Global Rules
0
HARD Hooks
0
Skills
0
Pipeline Phases
0
Interactions O(n²)
구성 요소
수량
형태
관리 부담
Rules (공통 규칙)
50+
마크다운 규칙 파일
규칙끼리 모순 감지, 오래 안 쓰인 규칙 정리, 여러 프로젝트 공통으로 승격
HARD Hooks
15+
Bash 스크립트
통과/차단 판정(종료 코드) 관리, 새 검사 추가 시 분류 로직 동시 갱신, 실행 순서 의존성
Skills
100+
설명 파일 + 스크립트
언제 실행될지(트리거) 조건 관리, 버전 호환성
Agents
30+
역할별 전문화
각자 쓸 수 있는 도구 권한 분리, 지시문(prompt) 다듬기
Supervisor Pipeline
14단계
Python + Bash
단계 사이 상태 전달, 실패 복구
Signal Collectors
5종
'고침 커밋(코드 변경을 저장소에 기록한 단위) 발생'·'같은 실수 반복' 감지 등
잘못 잡거나 놓치는 걸 줄이는 튜닝
QA Gate
3중
web-qa-tester(웹 화면을 사람처럼 눌러 보는 검사 도구) + agent-browser + expect-cli
세 도구(화면을 사람처럼 눌러 보는 웹 QA 테스터, 브라우저를 자동 조작하는 도구, 기대한 값이 나왔는지 확인하는 명령줄 검사기)의 결과가 서로 맞는지 교차 확인
Dual Model Review
2모델
Claude + GPT-5.4
비교 표 생성, 의견 충돌 조정
Memory System
2종
memory-bank + episodic-memory
두 기억 장치(대화에서 뽑은 사실을 쌓는 것과 세션별 일화를 쌓는 것)의 검색 정확도, 만료 관리
Sync
1시스템
cc-sync
설정 폴더를 백업 저장소와 맞추는 동기화 도구. 공통 설정과 프로젝트별 설정의 경계 관리
2.2 규칙끼리 서로 얽히는 문제
개인용 하네스인데도 이미 복잡성이 터진 실제 사례들:
사례 1규칙끼리 서로 모순
convergence-loop-no-mid-question(작업이 끝날 때까지 멈추지 말라는 규칙)과, 정반대인 completion-verification(중간에 멈춰서 결과를 검증하라는 규칙)이 부딪힌다. 적용 범위는 다르지만 경계가 흐릿해서, AI인 Claude조차 어느 쪽을 따라야 할지 헷갈린다.
사례 2검사 스크립트끼리 충돌
qa-gate-before-push라는 검사는 코드를 올리기 전에 'QA 통과 도장' 파일(.qa-cycle-passed)을 요구한다. 그런데 다른 검사는 'AI 교차 리뷰 통과 도장' 파일(.codex-review-passed)도 따로 요구한다. 결국정해진 1시간 안에 두 도장을 모두 받아야 한다. 새로 커밋하면 지문(해시)이 바뀌어서 두 도장을 다시 받아야 한다.
사례 3Scaffold Bloat
자가개선 기능(self-improve)은 실수를 고친 커밋이 생길 때마다 새 규칙을 만든다. 그런데쓸모없어진 규칙을 솎아내는 정리 단계(Curator)가 없어서, 약한 규칙이 끝없이 쌓인다(이게 'Scaffold Bloat', 규칙 비대화다). 그래서 따로 청소하는 과정이 또 필요해진다.
사례 4적용 범위 경계를 못 정함
M2 단계, 즉 검사 스크립트를 '모든 프로젝트 공통'과 '이 프로젝트 전용' 중 어디에 둘지 자동 분류하는 작업(7장에서 다루는 하네스 개조 계획의 세 번째 이정표)에서3주째 진전이 없다. 공통(global)으로 할지 프로젝트 전용(project)으로 할지 정하는 것 자체가 본질적으로 어려운 문제라서다. 컴퓨터 한 대, 사람 한 명인데도 못 풀었다.
2.3 복잡도가 늘어나는 그래프
핵심: 규칙 수는 한 칸씩(직선으로) 늘어도, 규칙끼리 부딪힐 수 있는 경우의 수는 그 제곱으로 커진다. 규칙 50개면 서로 짝지을 수 있는 쌍이 최대1,225개다(50×49÷2). 규칙 하나가 다른 규칙과 어긋날 잠재적 지점이 그만큼 많다는 뜻이다.
03 — Distributed Protocol
여러 컴퓨터로 나누면 복잡도가 얼마나 더 쌓이나
3.1 항목별로 늘어나는 복잡도
항목
개인 하네스
분산 하네스에서 더해지는 것
배수
신뢰 (Trust)
한 프로그램 안이라 서로 믿음
위조 못 하게 전자서명, 세션 토큰(접속 허가증 역할의 임시 문자열), 재전송 공격 방어, 미리 승인된 참가자만 접속, 그리고 도청 못 하게 암호화 통신(웹 주소창의 자물쇠와 같은 규약인 TLS)
×5
가입 (Join)
코드에 적으면 바로 등록
관리자 승인 절차, 허용 목록, 운영자 화면, '대기→승인' 상태 관리
×3
통신 (Comm)
그냥 함수 호출(같은 컴퓨터 안)
암호화된 실시간 연결로 규격화된 메시지를 주고받고, 메시지마다 서명·압축
×4
장애 (Failure)
프로그램 하나만 죽음
네트워크 단절, 컴퓨터 다운, 살아있는지 확인하는 신호(10·30·60초), 같은 작업 두 번 실행 방지, 중복 결과 정리
×6
능력 (Capability)
코드에 고정으로 적어둠
각 일꾼의 능력 명세서를 실행 중에도 갱신하고, 작업을 능력에 맞게 배정
×3
결과 검증
내 컴퓨터에서 QA 검사
형식 검증·서명 검증·(선택적으로) 같은 작업을 여러 대에 돌려 대조·결과 취합
×3
관찰성 (Observability)
내 컴퓨터 로그 + 텔레그램
지워지지 않는 감사 기록, 일꾼·중앙·작업별 지표, 작업 하나를 여러 대에 걸쳐 추적하는 ID
×3
3.2 처리해야 할 '상태'가 폭발한다
상태 조합: 작업의 상태 7가지 × 일꾼의 상태 6가지 =42가지 조합이 나온다. 이 42가지 각각에 대해 '이럴 땐 이렇게' 처리하는 코드를 따로 만들어야 한다.
3.3 고장 났을 때 대처 비교
고장 상황
개인 하네스
분산 하네스
프로그램이 죽음
재시작
생존 신호 끊김 → '멈춤' 표시 → 다른 일꾼에 재배정
중간 결과 손실
내 컴퓨터 파일에서 복구
'같은 작업 중복 방지 키'로 다시 시도하고, 중복 결과는 걸러냄
능력 부족
즉시 에러
작업 거절 → 다른 일꾼 선택 → 능력에 맞게 다시 배정
부분 실패
전체 재시도
'즉시 중단' / '되는 만큼만' / '몇 번 재시도 후 실패' 중 정책 선택
중앙(Host) 다운
N/A
일꾼이 작업을 자기 대기열에 저장 → 다시 연결되면 밀어넣기 → 감사 기록 복원
04 — Enterprise Layers
회사용으로 만들면 시스템 층이 몇 겹 더 쌓인다
4.1 개인용에서 회사용으로 갈 때 얹히는 층
개인용 하네스 위에 회사 운영에 필요한 층이 하나씩 올라간다. 문제는 각 층이 앞 층의 복잡도에 자기 배수를곱하기로얹는다는 점이다. 더하기였다면 견딜 만했을 것이다:
4.2 비유로 보면 결국 무엇을 만드는 셈인가
직접 만들어야 하는 것
이미 있는 대형 서비스로 치면
작업을 여러 대에 나눠주고 결과 모으기
AWS Lambda + Step Functions
능력에 맞춰 작업 배정하기
Kubernetes Scheduler
하네스 규칙을 누가·어떻게 관리할지(거버넌스). 오른쪽은 규칙을 코드로 적어 자동으로 강제하는 정책 도구다
Terraform Policy as Code (정책을 코드로 적어 검사하는 엔진 OPA/Sentinel)
팀마다 규칙 적용 범위 조율. 오른쪽은 깃허브에서 파일별 담당자와 승인 규칙을 정하는 기능이다
GitHub CODEOWNERS(파일마다 담당자를 지정해 두는 파일) + Branch Protection
Observability + SLA (service level agreement)
Datadog + PagerDuty
결론: 결국 쿠버네티스·테라폼·깃허브 엔터프라이즈 같은 대형 인프라 시스템을 한꺼번에 만드는 셈이다.
05 — Five Structural Barriers
조직으로 넓히는 게 근본적으로 어려운 5가지 이유
5.1머릿속 지식 → 말로 다 풀어 전달Difficulty: 5/5
개인
규칙이 왜 생겼는지 나만 안다
기업
팀원 모두가 이해해야 한다
규칙 50개에는 각각 '왜 만들었는지'(겪은 문제 사례)가 붙어 있다. 예를 들어tone-and-honorific.md라는 규칙은 '2026-04-21에 AI가 반말로 커밋해? 라고 물어 사용자가 크게 불쾌해한' 사건에서 나왔다. 이런 배경 하나하나를 팀원 10명에게 전부 전달하려면 비용이 얼마나 들까?
숫자로 따지면: 규칙 50개 × 규칙당 평균 3개 사례 =150개 사건 배경을 일일이 전달해야 한다.
5.2바로 오는 피드백 → 시차를 두고 오는 피드백Difficulty: 4/5
개인
실패하면 내가 그 자리에서 고침
기업
실패가 멀리 있는 다른 일꾼에서 터짐
여러 대에 흩어진 오류를 잡는 건 내 컴퓨터에서 잡는 것보다 10배 어렵다. '내 쪽에선 됐는데 저 일꾼 컴퓨터에선 안 되는' 상황에서,능력 명세서가 안 맞는 건지, 네트워크 문제인지, 버전 차이인지를 일일이 가려내야 한다.
5.3한 방향 진화 → 제각각 진화Difficulty: 5/5
개인
자가개선이 한 방향으로 모임
기업
일꾼마다 하네스가 따로따로 변해감
설계 문서 9.3절이 짚은 '공유 기억'(여러 일꾼이 배운 걸 함께 저장) 문제: • 일꾼마다 배운 걸 공용 지식 저장소(지식 그래프)에 밀어넣으면 → 쓸데없는 정보가 폭발할 위험 • 아무거나 못 들어오게 거르는 관문, 출처 추적, 신뢰도 점수가 필요해짐 • '그 공용 지식 저장소의 구조는 누가 정하고 관리하나?'는 아직 못 푼 문제다
5.4소통 비용 0 → 사람 수의 제곱Difficulty: 4/5
개인
모든 결정이 내 머릿속에서 끝남
기업
일꾼끼리 능력을 조율하고 결과에 합의해야 함
'브룩스의 법칙'(사람이 늘수록 서로 소통할 통로가 급증해 오히려 느려진다는 소프트웨어 공학 법칙)의 AI 일꾼 버전: 일꾼이 N대면 서로 이어질 수 있는 통신 통로는 N×(N-1)÷2개다. 10대면 45개, 100대면4,950개로 늘어난다.
5.5마음껏 실험 → 조심스러운 실험Difficulty: 3/5
개인
실패해도 나만 손해
기업
실패하면 다른 사람 작업까지 영향
이 시스템의 핵심인 '자가개선 루프'(스스로 실수를 겪고 고쳐 나가기)는 실험과 실패를 전제로 한다. 그런데 조직에서는: • 자가개선이 만든 새 규칙이다른 팀원의 작업 흐름을 망가뜨릴 수 있다 • 문제가 생겨 되돌리기(롤백)를 하려 해도, 여러 대에 흩어진 상태에선 극도로 어렵다 • '바꾸기 전에 저장해두기'(안전용 스냅샷) 규칙도, 여러 대로 확장하면'분산 트랜잭션'이라는 난제가 된다
06 — The Core Bottleneck
'사용자 대리 검증'(user-proxy)이 조직으로 확장되지 않는 이유. 이것이 가장 큰 병목이다
convergence-loop-no-mid-question라는 규칙에는 '사용자가 시작하라고 했으니, 다 될 때까지 멈추지 않고 반복한다'는 전제가 깔려 있다. 여기서 사용자 대리 검증(user-proxy)은 사람 대신 '이 작업이 정말 됐는지' 검사하고 판정하는 역할이다. 이 전제는'시작을 승인한 사람 = 결과를 받는 사람 = 품질 기준을 정한 사람'이 모두 같은 한 사람일 때만 성립한다. 그런데 회사에서는 이 세 역할이 거의 항상 다른 사람이다. 그래서 '누구 기준으로 다 됐다고 판정하지?'가 막힌다.
07 — M2 Stall
M2 단계(검사 스크립트의 적용 범위를 자동 분류하는 이정표)가 3주째 막힌 이유. '적용 범위'를 정하는 일은 근본적으로 어렵다
7.1 하네스 개조 계획의 진행 현황 (계획의 코드 이름 loopy-era-runtime-alignment)
DONEM0Baseline Freeze지금 상태를 그대로 저장(스냅샷)
DONEM1Runtime Drift Sync실제 돌아가는 버전과 원본 코드 맞추기
STALLEDM2Hook Scope Classifier공통 적용에서 프로젝트별 적용으로 전환 (3주째 정체)
PENDINGM3Project Installer프로젝트별 설정 설치 자동화
PENDINGM4Staged Migration점진적 이관
PENDINGM5Self-Evolve Alignment자가개선 정렬
PENDINGM6Scorecard Split평가 지표 분리
PENDINGM7Operationalization실제 운영 전환 + 설정이 어긋나는 것 방지
7.2 M2, 즉 적용 범위 분류가 왜 어려운가
M2 단계의 핵심 질문은 이거다:'이 검사 스크립트를 모든 프로젝트에 공통으로 적용할까(global), 아니면 특정 프로젝트에만 적용할까(project)?'
컴퓨터 한 대, 혼자 쓰는데도 이 판단이 어려운 이유:
1. qa-gate-before-push(코드를 올리기 전에 QA 통과 증거를 요구하는 검사). 모든 프로젝트에 필요할까? 앱을 만드는 Flutter 프로젝트도? 문서만 있는 저장소도?
2. no-localstorage(브라우저 저장소에 사용자 데이터를 두지 못하게 막는 검사). 웹 프로젝트에만 해당한다. 서버(백엔드)만 있는 프로젝트에선 쓸데없는 검사다
3. portless-required(개발 서버를 고정 포트 번호 없이 띄우게 강제하는 검사). 개발용 서버를 띄우는 프로젝트에만 필요하다. 라이브러리 프로젝트엔 의미 없다
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
1세대(v1)에서 2세대(v2)로 오며 얻은 가장 큰 교훈은 이것이다. "서버에서 AI(LLM) 호출을 0으로 만들어야만 운영이 된다"
8.2 '공정하게 비교하기'가 생각보다 어렵다
하네스끼리 겨루게 하는 것만으로도 이런 게 필요하다:
• 커밋 기록 검증 (누가 썼는지, 시간대 분포, 이력을 강제로 덮어썼는지 탐지) • AI가 참여했다는 표시 강제 (커밋에 공동 작성자 표기) • 여러 작업을 커밋 하나로 뭉쳐 제출하는 것 거부 • 참가자 코드를 어디서 안전하게 격리 실행할지 선택 (Vercel·GitHub Actions·Deno 격리 환경 중)
이걸같은 조직 안에서 하네스들의 품질을 비교하는 일로 넓히면 훨씬 더 복잡해진다.
09 — Conclusion
결론과 시사점
9.1 이 결론까지 온 과정
발견
개인 시스템 6개월 85~90% 완성
장벽
M2: 적용 범위의 벽 본질적 어려움
확장 시도
분산 하네스 설계 문서 작성
현실 인식
N² 복잡도 체감
결론
조직 확장은 열린 문제
9.2 이 결론이 정확한 이유
O(n²)
복잡도가 제곱으로 증가
규칙이 n개면 규칙끼리 부딪힐 수 있는 경우의 수는 n의 제곱에 비례해 늘어난다. 규칙 50개면 잠재적 충돌 지점이 1,225개.
∅
미해결 열린 문제
APM(마이크로소프트가 만든 에이전트, 즉 자율적으로 일하는 AI 일꾼의 관리 시스템)도, AI 연구자 안드레이 카파시가 말한 '하네스 엔지니어링'도, 개인용 자가개선 루프 수준까지는 아직 도달하지 못했다.
≠
기술 문제 ≠ 조직 문제
사용자 대리 검증(user-proxy)에서 '판단 기준을 하나로 맞추는 일'은 기술 문제가 아닌 조직 정치의 문제다. 누구의 기준으로 'QA 통과'를 판정할 것인가?
9.3 시도해볼 만한 방향들 (아직 미해결)
접근
설명
난이도
규칙을 계층으로 나누기
규칙을 5단계로 나눔. 0단계는 절대 불변, 1단계는 조직, 2단계는 팀, 3단계는 프로젝트, 4단계는 개인이다. (단계 이름은 차례로 L0·L1·L2·L3·L4)
4/5
필요한 것만 골라 선언
APM(마이크로소프트의 에이전트 관리 시스템)처럼 프로젝트마다 설정 파일에 꼭 필요한 기능만 골라 적기
3/5
점진적 채택
하네스 전체 대신 QA 검문 하나부터 도입하고, 조직이 익숙해지면 넓히기
2/5
하네스를 패키지로 배포(만든 것을 남이 설치해 쓰게 내보내기)
검증된 하네스 구성을 조직 공용 패키지로 배포 (npm·pip 같은 배포 방식)
5/5
9.4 최종 판단
회사용 분산 하네스는 '만들 수 있느냐'의 문제가 아니라 '운영할 수 있느냐'의 문제다.
만드는 것은 엔지니어링이지만, 운영하는 것은 조직 문화 자체가 바뀌어야 하는 일이다.
개인용 자가개선 루프(loopy-era)를 조직으로 넓히는 것은 아직 아무도 못 푼 열린 문제이며,
이 복잡함을 있는 그대로 인정하는 것이 해결의 첫걸음이다.
이 글은 6개월간 직접 굴려 본 경험에서 나온 구조적 결론이다.
감으로 쓴 글이 아니다. 규칙 50개 이상·검사 스크립트(hook) 15개 이상·14단계 파이프라인(작업을 단계별로 이어 처리하는 흐름)을 직접 만들고 운영하며
몸으로 느낀 복잡도를 숫자로 기록한 것이다.