결론부터 말하면, 혼자 쓰려고 만든 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
특정 순간에 자동으로 끼어들어 검사하거나 막는 스크립트 — 예: 검증을 통과하기 전엔 코드 업로드를 차단
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
세 도구 결과가 서로 맞는지 교차 확인
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 단계)에서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
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— 모든 프로젝트에 필요할까? 앱을 만드는 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개.
∅
미해결 열린 문제
AI 연구자 안드레이 카파시가 말한 '하네스 엔지니어링'도, 마이크로소프트의 에이전트 관리 시스템 'APM'도, 개인용 자가개선 루프 수준까지는 아직 도달하지 못했다.
≠
기술 문제 ≠ 조직 문제
사용자 대리 검증(user-proxy)에서 '판단 기준을 하나로 맞추는 일'은 기술이 아니라 조직 정치의 문제다. 누구의 기준으로 'QA 통과'를 판정할 것인가?
9.3 시도해볼 만한 방향들 (아직 미해결)
접근
설명
난이도
규칙을 계층으로 나누기
규칙을 5단계로 나눔 — 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단계 파이프라인을 직접 만들고 운영하며
몸으로 느낀 복잡도를 숫자로 기록한 것이다.