Part 03 — Organizational Limits

AI 검증 장치(하네스)를 회사 전체로 넓히면
기술보다 조직이 먼저 막힌다

혼자 쓰던 AI 하네스를 회사 전체로 넓히려다 막혔다. 하네스(harness)란 AI에게 일을 맡기고 그 결과가 제대로 됐는지 자동으로 검증하는 장치 묶음이다. 막힌 곳은 조직이었다. 사용자 한 명을 대신해 품질을 판정하던 자동 검사원(user-proxy)은 여러 명 앞에서는 작동하지 않는다. '늦은 프로젝트에 사람을 더 투입하면 오히려 더 늦어진다'는 옛 소프트웨어 격언(브룩스의 법칙)이 AI 에이전트에서도 똑같이 반복된다. 전환 작업은 여덟 단계 가운데 세 번째, 규칙 적용 범위를 가르는 단계에서 3주째 멈춰 있다. 본문의 단계 표는 번호를 0부터 세므로, 이 세 번째 단계에는 이런 이름표가 붙어 있다: M2

5 Structural Barriers
개인용 하네스를 조직 전체로 확장하기가 본질적으로 어려운 5가지 이유
01
혼자 알던 것 → 팀에 말로 풀어 전달
개인
규칙이 왜 생겼는지 나만 안다
기업
규칙 50개 × 규칙마다 생긴 배경 3개 = 사건 배경 150개를 팀원에게 일일이 설명해야 한다
난이도: ★★★★★
02
즉시 수정 → 뒤늦게 돌아오는 피드백
개인
실패하면 그 자리에서 바로 고친다
기업
여러 대에 흩어진 오류를 찾는 일은 내 컴퓨터 한 대에서 찾을 때보다 10배 힘들다
난이도: ★★★★☆
03
한 방향 진화 → 여러 갈래로 제각각 진화
개인
스스로 규칙을 고치는 자동 개선(self-improve)이 한 방향으로만 정리된다
기업
AI 작업자(Worker)마다 따로 진화해, 규칙을 함께 쌓는 공용 지식 저장소가 잡음으로 뒤엉킨다
난이도: ★★★★★
04
조율 비용 0 → 팀 규모의 제곱으로 폭증
개인
모든 결정이 내 머릿속에서 끝난다
기업
에이전트가 10대면 서로 조율할 대화 경로가 45개, 100대면 4,950개로 늘어난다
난이도: ★★★★☆
05
마음껏 실험 → 조심스러운 실험
개인
실패해도 손해 보는 건 나뿐이다
기업
내 자동 개선(self-improve)이 다른 팀원의 작업 흐름을 망가뜨릴 수 있다
난이도: ★★★☆☆
Core Bottleneck
자동 검사원(user-proxy)은 왜 여러 명에게 확장되지 않는가
가장 강력하지만, 가장 확장하기 어려운 부품
개인: 자동 검사원이 사용자 한 명의 판단 습관을 학습한다 → 그 기준(판단 규칙을 정리한 체계, 온톨로지)에 따라 스스로 판정한다 → 결론이 날 때까지 멈추지 않고 반복한다 → 사람에게 올려 물어보는 경우는 딱 5가지뿐이다
기업: 자동 검사원이 팀원 여러 명의 판단 습관을 모두 배워야 한다 → 그런데 누구의 기준을 따르나? 팀장? 최고기술책임자(CTO)? 다수결? → 판단 기준을 팀마다 다르게 둬야 하나? → 사람에게 올릴 결정은 누가 받나?
이것은 기술로 풀 문제가 아니다. 조직 정치 문제다.
convergence-loop-no-mid-question이라는 규칙이 있다. 중간에 멈춰 사람에게 되묻지 않고, 결론이 날 때까지 자동으로 반복한다는 원칙이다. 이 규칙은 한 가지를 전제한다. 시작을 승인한 사람, 결과를 받는 사람, 품질 기준을 정한 사람이 모두 같은 사람이라는 전제다. 조직에서는 이 전제가 성립하지 않는다.
M2 Stagnation
M2 단계가 3주째 멈춘 이유
Milestone상태핵심 과제
M0 Baseline Freeze✓ completed지금 상태를 사진 찍듯 기록해 기준점 만들기
M1 Runtime Drift Sync✓ completed실제 설치돼 돌아가는 버전을 원본 코드와 일치시키기
M2 Hook Scope Classifier⚠ 3주째 정체규칙 적용 범위(scope)를 '전체 공통(global)'에서 '프로젝트별(project)'로 나누기. 규칙을 어디까지 적용할지 경계를 긋는 일은 본질적 난제다
M3 Project Installer— pending프로젝트별 규칙을 자동으로 설치하기
M4 Staged Migration— pending한꺼번에 바꾸지 않고 조금씩 옮기기
M5 Self-Evolve Alignment— pending스스로 개선하는 루프끼리 서로 어긋나지 않게 맞추기
M6 Scorecard Split— pending성과 측정 지표를 범위별로 나누기
M7 Operationalization— pending실제 운영에 올리고, 시간이 지나며 설정이 원본에서 어긋나는 것(드리프트) 막기
사용자 1명 × 에이전트 1대 개인 범위(user)와 프로젝트 범위(project) 사이 경계 정하기 M2 단계에서 지금 멈춤
여러 명 × 여러 대 user ↔ project ↔ team ↔ org scope 팀(team)·조직(org)까지 겹쳐 난이도가 폭발적으로 커짐
Possible Approaches
시도해볼 만한 해결 방향 (아직 정답은 없음)
규칙을 계층으로 나누기
규칙을 5개 층으로 나눈다. 0층은 절대 안 바뀌는 기본, 1층은 조직 전체, 2층은 팀, 3층은 프로젝트, 4층은 개인이다. 층 이름은 L 뒤에 층 번호를 붙여 같은 순서로 이렇게 쓴다: L0 / L1 / L2 / L3 / L4
난이도: ★★★★☆
설정 파일로 필요한 것만 선언하기
마이크로소프트가 제안한 에이전트 패키지 관리자(Agent Package Manager) 방식이다. 프로젝트마다 설정 파일 하나에 그 프로젝트에 필요한 기능 부품만 골라 적어 둔다. 이 방식의 줄임말과 그 설정 파일의 이름은 차례로 이렇다: APM · manifest.yml
난이도: ★★★☆☆
조금씩 도입하기
전체를 한꺼번에 들이지 말고, 품질 검문소(qa-gate) 하나부터 시작한다. 조직이 익숙해지는 만큼 넓혀 간다
난이도: ★★☆☆☆
하네스 장터(마켓플레이스)
검증된 하네스 구성을 하나의 묶음 상품으로 판다. 이를 위한 분산 설계 문서만 11장에 이른다.
난이도: ★★★★★
Final Verdict
최종 판단
"만들 수 있는가?"의 문제가 아니라
"운영할 수 있는가?"의 문제
만드는 것은 기술의 문제다. 운영하는 것은 조직 문화를 바꾸는 일이다. 혼자 돌리던 자가개선 루프(스스로 반복하며 나아지는 방식, loopy-era)를 조직 전체로 확장하는 일은 아직 아무도 풀지 못한 미해결 과제다. 이 어려움을 부풀리지도 줄이지도 않고 정직하게 인정하는 것이 해결의 첫걸음이다.

지금 AI 하네스 분야에서 가장 큰 숙제가 바로 이것이다. 한 사람에게 딱 맞춘 시스템을 조직 전체로 넓히는 일이다. AI 연구자 안드레이 카파시가 '하네스 엔지니어링(harness engineering, 하네스를 설계하는 기술)'이라 이름 붙인 것도 이 문제를 겨눈다. 앞에서 본 마이크로소프트의 에이전트 패키지 관리자가 설정 파일 하나로 풀려는 것도 같은 문제를 겨눈 시도다. 그러나 두 방법 모두 스스로 개선하는 루프(loopy-era)까지는 다루지 못한다. 마이크로소프트 쪽의 줄임말과 설정 파일 이름은 앞 절과 같다: APM · manifest.yml
Part 02: 분산 프로토콜 Overview