AI Orchestration Harness — 기준 찾기 (작업 노트)

이 문서는 출간용 글이 아니라 소재를 모으는 노트다. 단일 글로 갈지, 시리즈로 갈지는 분량과 결을 보고 나중에 결정한다.

스코프 정리 — 두 가지를 헷갈리지 않기

이 글은 개발팀이 만드는 시스템에 대한 글이지, 조직 전환 이야기가 아니다.

둘은 자주 같이 등장하지만 혼동되면 어느 쪽도 못 푼다. 본 글은 시스템 설계의 기준에 집중한다. AX는 별도 노트로 뗀다.

0. 중심 질문

우리 팀이 만드는 (사용자에게 제공할) AI 오케스트레이션 하네스의 좋고 나쁨을 어떤 기준으로 판단할 것인가?

부가 질문들:

• 하네스를 만들면서 우리가 실제로 측정/관찰하는 것은 무엇인가?
• 어떤 신호가 들어오면 "이건 잘못 가고 있다"고 말할 수 있나?
• "더 자유롭게 풀어주자"와 "더 가두자"의 임계점은 어디인가?

1. 가설 — 두 축

판단의 두 축을 이렇게 잡고 시작한다.

1. AI가 잘 동작하는가 — 효능(efficacy). 결과의 품질, 일의 진척, 사람이 기대한 것에 도달하는 빈도.
2. 그 안에서 우리가 컨트롤할 수 있는가 — 통제 가능성(controllability). 관찰·중단·교정·롤백·책임 추적이 되는가.

두 축은 trade-off로 자주 등장하지만 trade-off가 아니어야 좋은 하네스다. 한쪽을 깎아 다른 쪽을 사는 설계는 임시방편이다.

2. 핵심 명제

방임하면 안 된다. 위임해야 한다.

이 한 줄이 글 전체를 끌고 갈 것 같다. 풀어보면:

• 방임(abandon) — AI가 알아서 하길 바라며 손을 뗀다. 결과가 좋으면 좋은 줄, 나쁘면 그제야 안다.
• 위임(delegate) — 권한과 범위를 명시적으로 넘기되, 보고 라인·중단 권한·교정 루프는 사람이 쥔다.

둘 다 사람이 일을 안 하는 것처럼 보이지만 본질은 정반대다. 위임은 가장 비싼 행위 중 하나다.

3. 두 축의 2x2

특히 우상단(잘 동작 + 통제 불가)이 가장 함정이다. 결과가 좋기 때문에 모두가 만족하고, 어느 날 갑자기 무너진다. "운영되고 있는 줄 알았다"가 사후에 나오는 자리.

4. "Harness"라는 단어

마구(馬具). 말을 멈추게 하는 도구가 아니라 달리게 하면서 방향을 잡는 도구. 굴레(bridle), 안장(saddle), 고삐(rein)가 모두 harness의 일부다.

• 멈추는 도구가 아니다 → 가드레일(guardrail)·필터(filter)와 다르다.
• 매어 두는 도구도 아니다 → 새장(cage)·샌드박스(sandbox)와도 다르다.
• 같이 일하는 도구다 → 사람과 AI가 짝을 이뤄 일하는 형상.

이 어휘 차이가 글의 톤을 결정할 듯. "AI를 가두는 것"이 아니라 "AI와 같이 일하기 위해 짜는 형식."

5. 모을 소재 (계속 추가)

5.1 위임의 조건 (관리학에서)

• 명확한 결과(outcome)와 명확한 권한 경계
• 보고 주기와 중단(escape) 조건
• 책임의 잔류 — 위임해도 책임은 위임자에게 남는다
• 위임은 사람이 더 한가해지는 게 아니라 다른 일을 하는 것이다

5.2 AI 하네스에서의 대응

• outcome = 작업 명세(task spec) / 평가 함수
• 권한 경계 = 도구 권한, 파일 시스템 범위, 네트워크, 비용
• 보고 = 로그, trace, tool call 기록, 결과물 diff
• 중단 = kill switch, budget cap, human-in-the-loop 트리거
• 책임의 잔류 = "AI가 그랬어요"라는 변명이 통하지 않는 구조

5.3 효능을 측정하는 어려움

• 일이 완료되었는가 vs 잘 완료되었는가
• "잘"의 정의를 우리가 사전에 쓸 수 있는가
• 회고에서만 잘잘못이 보이는 일들 (창작·리서치·코드 설계)
• "결과 좋음 = 시스템 좋음"의 함정

5.4 통제의 비용

• 모든 step에 사람이 들어가면 → 위임이 아니라 마이크로매니징
• 통제는 언제든 들어갈 수 있는 가능성이지 상시 개입이 아니다
• 관찰 가능성(observability)이 곧 통제 가능성의 8할

5.5 방임이 일어나는 메커니즘 (관찰)

• 처음엔 자세히 본다 → 잘 돌아간다 → 안 본다 → 안 보이는 게 정상이 된다 → 사고
• "이 정도면 알아서 하겠지"의 누적
• 보고/관찰 비용을 줄이면 위임이 아니라 방임으로 미끄러진다

5.6 End image — 사람을 움직이는 첫 조건

사람을 움직일 때 가장 중요한 것은 end image다. "이런 결과가 나와야 한다"는 끝그림.

• 끝그림이 없으면 위임이 성립하지 않는다 → 자동으로 방임이 된다. 비교할 대상이 없어서 잘잘못도 못 판단한다.
• 위임의 "권한 경계"와 "보고 라인"은 다 그다음 이야기. end image가 1번이다.
• AI harness에서의 번역:
  • end image = 작업의 결과 명세 / acceptance criteria / 평가 기준
  • 이게 없는 prompt와 spec은 그대로 방임 트리거다
  • 좋은 harness는 사용자가 end image를 쉽게 쓰고, 쉽게 고치고, 시스템이 거기에 맞춰 자기 진척을 점검하게 한다
• 본인 bootstrap 글의 "끝그림과 최소 스펙 사이" — 같은 축. 끝그림이 있으면 최소 스펙이 보이고, 부트스트랩이 시작된다.
• 변형 질문: end image는 고정인가, 진화하는가? 진화한다면 그 진화 자체를 시스템이 추적할 수 있어야 한다 (= 통제 가능성의 일부).

위임의 3종 세트: 끝그림 · 권한 경계 · 중단 조건. 셋 중 끝그림이 먼저, 그리고 가장 자주 빠진다.

끝그림은 "이래도 되고 저래도 되고"여서는 안 된다.

• 모호한 끝그림 = 끝그림 없음. 받는 쪽(사람이든 AI든)이 자기 편한 쪽으로 해석해 버린다.
• "둘 다 괜찮다"가 진짜라면, 그건 선택지가 좁혀진 끝그림("A 또는 B, 단 C는 아님")이지 방임된 끝그림이 아니다. 둘은 다르다.
• harness 설계 함의: 사용자의 spec을 받을 때 시스템이 모호함을 감지하고 되묻거나, 구체화하거나, 거절할 수 있어야 한다. "알아서 해줘"를 그대로 받아들이는 시스템은 방임 기계다.
• 자기 점검 질문: 내가 지금 AI에게 주는 지시가 "이래도 되고 저래도 되고"인가? 그렇다면 결과를 평가할 권리도 잃는다.

5.7 실제 사례 — 사람 조직에서도 같은 원리가 작동했다 (2026-05-12, 사내)

인용·출간 시 처리 메모: 슬랙 원문은 글에 직접 넣지 않는다. 인물명·제품명(가칭 MSW 2.0 / 넥슨월드 등) 익명화 또는 일반화. 본 노트에는 맥락 보존을 위해 거친 채로 남겨둔다.

상황

• 시범서비스(10월) 오픈 준비. 두 가지가 동시에 테이블에 올라옴:
  1. 제품 개선 항목 7~8개 (모바일 조작감, 최적화, 3D/2D UX, 3D 리소스 관리, 크레딧, 웹툰 프롬프트, 검수/플레이 에이전트 등)
  2. 유닛 간 작업 분장 희망 — 백엔드 구조/스케일아웃은 백엔드 유닛, 제작 영역(게임뷰·만들기·멀티·게임서버)은 퓨처유닛, 콘텐츠 딜리버리(썸네일·좋아요·댓글·조회)는 플랫폼 유닛
• 즉 다른 유닛에 영역을 넘기는 = 사람 사이의 위임 시나리오.

내가 보낸 입장 (요지)

• 5월 목표: 우리 유닛 주도로 내부테스트/CBT 가능한 구조 구축
• 5월 진행: 협업을 위한 기획·명세 구체화
• 결론 한 줄: "기획·명세가 정리된 상태에서 작업 분장을 진행하는 편이 협업 효율이 높을 것"

이 사례가 드래프트의 명제와 정확히 일치하는 지점

• = 끝그림(end image)이 정해지기 전에는 작업 분장(권한 경계 분배)을 미루겠다는 입장
• 명세 없는 분장은 "이래도 되고 저래도 되고"가 되어 위임이 아니라 방임으로 미끄러진다
• 위임의 3종 세트 — 끝그림 · 권한 경계 · 중단 조건 — 중 끝그림이 먼저, 라는 원리가 사람 조직에서도 그대로 적용됨
• 즉 이 글의 프레임은 AI에 한정된 이야기가 아니다. AI harness가 어려운 이유 한 자락은: 이미 알려진 인간 위임의 원리를 다시 발견하고 있기 때문

같은 회의에서 나온 메타 신호 하나

• 회의록의 한 줄: "검수 및 플레이 에이전트 추가를 통해 한 번에 좋은 결과물 출력 가능성 높이기" — 우리가 AI harness에서 만드는 그 패턴(생성 → 에이전트 평가 → 통과분만 다음 단계)이 동일한 회의 안에서 의제로 떠올랐음. 시스템 안의 위임 구조와 조직 안의 위임 구조가 같은 자리에서 동시에 논의되고 있음 — 글 후반부 구체 예시 후보.

글에 박을 한 줄 후보

• "명세 없는 분장은 위임이 아니라 방임의 분장이다."
• "AI든 사람이든, 끝그림 없는 일은 누구의 잘잘못도 가릴 수 없다."

5.8 동작하는 기획서 — 만들어둔 것이 명세가 되는 길

전통적인 순서가 아니다. 보통은 기획서 → 명세 → 작업 분장 → 구현인데, 이번에는 순서가 뒤집혔다.

• 우리가 이미 만들어둔 것(프로토타입/시범 빌드)이 모호하던 부분을 구체화한 결과물이다.
• 즉 그 자체가 동작하는 기획서(executable spec / running spec). 종이 위 명세보다 덜 거짓말한다 — 실제로 굴러가니까 해석의 여지가 줄어들어 있다.
• 다음 일감은 이 동작하는 기획서를 글로 풀어 일감(work item)으로 떼어내는 것. 다른 유닛에 넘기려면 그래야 한다.

이게 위임/방임 프레임과 만나는 자리

• 끝그림(end image)이 문서에 먼저 생긴 게 아니라 시스템에 먼저 생겼다. 시간 순서는 비전통적이지만 결과는 같다 — 끝그림이 존재한다는 사실이 중요하다.
• 단, 시스템 안에만 있는 끝그림은 만든 사람만 읽을 수 있다. 다른 유닛에 위임하려면 판독 가능한 형태로 추출되어야 한다 → 그게 지금의 일감.
• 추출되지 않은 채 "직접 보면 알아" 모드로 분장하면, 그건 다시 "이래도 되고 저래도 되고"로 회귀한다. 동작은 하고 있지만 명시가 안 되어 있는 위임 = 잠재적 방임.

AI harness 글로 가져갈 함의

• 좋은 harness는 자기 자신이 동작하는 기획서가 되는 시스템이다. 무엇을 하기로 했는지가 코드/실행/로그/데이터에 그대로 드러난다.
• 그러나 그것만으로는 부족하다. 동작하는 기획서가 다른 사람·다른 에이전트·미래의 자신에게 위임 가능하려면, 역명세화(reverse-specification) 의 작업이 따로 필요하다. 시스템에서 명세를 꺼내 일감 단위로 자르는 일.
• 즉 harness의 산출물에는 두 갈래가 있다:
  1. 실행 결과 — 시스템이 무엇을 했는가
  2. 읽을 수 있는 명세 — 그래서 그것이 무엇이었는지

동작하는 기획서는 끝그림을 증명하지만, 일감은 끝그림을 전달한다. 둘 다 필요하다.

§5.7 사례와의 접합

• 본인이 보낸 "5월 진행: 협업을 위한 기획·명세 구체화"가 바로 역명세화 작업이다. 우리는 이미 동작하는 기획서를 가지고 있고, 그것을 다른 유닛이 받을 수 있는 일감 단위로 잘라내는 중. 분장은 그다음.

5.9 R&R도 같은 원리 — Input/Output이 R&R의 본체다

조직 간 R&R(Roles & Responsibilities)도 결국 위임의 인터페이스 계약이다. 그리고 인터페이스 계약은 input/output이 구체화돼야 비로소 존재한다.

• "퓨처유닛이 제작 영역을 맡는다" 는 R&R이 아니라 R&R의 라벨이다. 진짜 R&R은:
  • input: 어떤 명세·자산·결정을 받아야 시작할 수 있는가
  • output: 어떤 형태의 산출물·합격 기준·납기로 넘기는가
  • 경계: 무엇을 안 함 (negative scope)
• 이 셋이 비어 있으면 라벨만 남는다. 그리고 라벨만 있는 R&R은 자동으로 방임으로 미끄러진다 — "그건 너희 영역이잖아"와 "이렇게 줄지 몰랐지"가 동시에 나오는 자리.

왜 그래도 다들 라벨만으로 R&R을 정하려고 하는가

• 명세를 구체화하는 비용이 비싸다 (= 위임이 비싸다는 자리와 동일)
• 라벨만 정하면 합의된 것처럼 보인다 — 협업의 외양만 만든다
• 일이 안 풀릴 때 누구 책임인지가 모호한 것을 모두가 묵계하기 좋다

Harness 글로 가져갈 함의

• AI harness 안에서 에이전트들끼리의 R&R도 동일하다. "이 에이전트가 검수를 맡는다"는 라벨이고, 진짜 R&R은 어떤 입력 형태로 받아 어떤 판정과 어떤 신호를 다음 단계로 넘기는지의 명세.
• 동작하는 기획서(§5.8)와 역명세화가 R&R에도 그대로 적용된다 — 시스템이 실제로 어떻게 흘러가는지를 보고, 그것을 읽을 수 있는 인터페이스로 추출하는 일.
• 즉 좋은 harness는 각 단계의 input/output이 자기 자신을 설명하는 시스템이다. 별도 R&R 문서를 두기 전에 시스템이 R&R을 증명하고, 그다음 그것을 전달한다.

한 줄 후보

• "라벨만 있는 R&R은 위임이 아니라 방임의 분장이다."
• "Input과 output이 구체화되지 않은 R&R은 R&R이 아니라 R&R의 그림자다."

5.10 (열어둠) 후보 키워드

• delegation surface / abandonment risk
• trust budget — 신뢰는 예산이다, 다 쓰면 회수해야 한다
• human-in-the-loop ≠ human-on-the-loop ≠ human-out-of-the-loop
• "사람이 마지막에 본다"의 자리와 빈도

6. 글의 후보 골격

대략 이런 흐름이면 단일 글로 좋을 것 같다:

1. 하네스를 짜다가 멈춰 선 자리 — 무엇을 기준으로 평가해야 하는지 모르겠더라
2. 두 질문으로 줄어들었다 — 잘 동작하는가, 컨트롤 가능한가
3. 사분면, 그리고 우상단(방임)의 함정
4. 방임과 위임을 가르는 것 — 관리학의 위임 조건이 AI에서 어떻게 번역되는가
5. harness라는 어휘 — 가두는 게 아니라 같이 달리는 것
6. 그래서 지금 나는 무엇을 짜고 있나 (구체 예시 1~2개)
7. (열린 결론) 위임은 비싸다. 그러나 방임은 더 비싸다.

7. 인용/참고 후보 (검증 전)

• (TBD) 관리학의 위임 단계 (Tannenbaum-Schmidt continuum 등)
• (TBD) Karpathy, Simon Willison 등의 agent harness 관련 글
• (TBD) "human-in-the-loop"의 정의가 분야별로 다른 점
• (TBD) 본인의 ai-gratitude — "도구로서 보여주기"와 연결할 여지

8. 작업 로그

• 2026-05-12 — 드래프트 시작. 두 축 가설·2x2·"방임 vs 위임" 명제·harness 어휘 정리. 소재 슬롯 6개 열어둠.
• 2026-05-12 — 스코프 정정. AX(조직 전환)와 본 글(개발팀이 만드는 시스템의 평가 기준)을 분리. AX는 별도 드래프트로 뗄 예정.
• 2026-05-12 — 5.6 보강: end image의 첫 조건성, "이래도 되고 저래도 되고는 안 됨". 위임 3종 세트(끝그림·권한 경계·중단 조건) 정식 등록.
• 2026-05-12 — 5.7 신설: 사내 MSW 2.0 작업 분장 사례. "기획·명세가 정리된 상태에서 작업 분장" 발언이 본 글 명제와 동일 모양. AI에 한정된 얘기가 아님을 받쳐주는 보편성 근거로 활용.
• 2026-05-12 — 5.8 신설: "동작하는 기획서(executable spec)" 개념. 비전통적 순서(빌드 → 명세 → 분장)에서 끝그림은 시스템에 먼저 생긴다. 위임을 위해 역명세화가 별도 작업으로 필요하다는 점이 harness 산출물 이원 구조(실행 결과 / 읽을 수 있는 명세)로 연결됨.
• 2026-05-12 — content/에 MDX로 미러링. visibility: unlisted + status: draft로 site에서 본인이 읽을 수 있게 신설. docs/drafts/ 원본과 둘을 사람이 손으로 동기화.
• 2026-05-12 — 5.9 신설: 조직 간 R&R도 같은 원리. input/output·negative scope가 구체화돼야 R&R이 성립. 라벨만 있는 R&R은 방임의 분장. 에이전트 간 R&R에도 동일 적용.