누락된 하부 계층: AI가 당신의 회사를 더 빠르게 만들지 못하는 이유

"비즈니스 하네스(business harness)": 인간 개입을 최소화하고 품질을 일정하게 유지하는 것.

이 글은 Singularity Society site에 게재된 일본어 기사를 영어로 각색한 것입니다. 이 내용은 'MulmoTerminal을 사용하여 하루 500 커밋 살기(Living at 500 commits a day with MulmoTerminal)'라는 강연(2026-09-06)에서 파생되었으며, 그 후반부는 인간이 모든 변경 사항을 읽지 않아도 AI가 소프트웨어를 작성할 수 있게 하는 3계층 하네스에 관한 것이었습니다. 여기의 예시는 미국식 비즈니스 관행에 맞게 다시 작성되었습니다. 섹션 4부터는 아직 검증되지 않은 가설입니다. 시간과 수치는 예시일 뿐, 측정된 것은 아닙니다.

목차

1. 초안 작성은 이제 30분 만에 끝난다. 읽기 속도는 빨라지지 않았다
2. 병목 현상이 '초안 작성 후'로 이동했다
3. 소프트웨어 개발에서 이미 일어나고 있는 일들
4. 비즈니스 하네스란 무엇인가
5. 당신이 이미 가지고 있는 도구에서 부족한 것들
6. 핵심 아이디어: AI가 산문(prose)이 아닌 필드(fields)를 생성하도록 만드는 것
7. 다섯 가지 시나리오: 유입 리드, 출장, 고객 저녁 식사, 비즈니스 케이스, 공급업체 송장
8. 인간의 판단을 메커니즘으로 전환하기
9. 어디서 시작할 것인가
10. 열린 질문들
11. 앱이 아닌 계층(layer)을 구축하라
12. 사이드바: 소프트웨어 어휘력
13. 부록: 용어집, 출처

1. 초안 작성은 이제 30분 만에 끝난다. 읽기 속도는 빨라지지 않았다

계정 담당자(account executive)가 생성형 AI를 사용하여 제안서를 초안 작성한다. 예전에는 반나절이 걸리던 일이 30분 만에 끝난다. 지금까지는 이 현상이 모든 곳에서 일어나고 있다.

문제는 그 이후부터 시작된다. 초안은 영업 부사장(VP of Sales)에게 전달되고, 그는 전체 내용을 읽는다. 가격 책정 섹션이 빈약하여 반송된다. AE가 이를 수정하고 재제출하면, VP는 전체 내용을 다시 읽는다. 법무팀(Legal)으로 넘어가면, 그들은 전체 내용을 읽는다. 가정(assumptions) 섹션이 빠져있어 다시 돌아온다. 수정하고 재제출하며, VP는 세 번째로 그것을 읽는다. 고객은 4~5 영업일 후에 이를 받게 된다. 인간들은 이 문서를 끝까지 다섯 번이나 읽었다.

AI는 '초안 작성(drafting)' 단계만 가속화했습니다. 하지만 '검토(checking)' 단계는 전혀 움직이지 않았습니다. 게다가 AI가 더 많은 초안을 생산할 수 있게 되면서, 검토 측은 이전보다 더 바빠졌습니다.

이것은 모델의 문제가 아닙니다. 프롬프팅(prompting)의 문제도 아닙니다. 인간이 확인하기 전에, AI가 만든 결과물이 중단될지 통과될지를 결정하는 비즈니스 워크플로우상의 메커니즘 자체가 존재하지 않는 것입니다.

소프트웨어 개발 분야에는 이미 그러한 메커니즘이 있습니다. 이 글에서는 이를 **하네스(harness)**라고 부르며, 이것을 비즈니스 업무에 어떻게 적용할 수 있을지 질문합니다.

2. 병목 현상이 '초안 작성 이후'로 이동하다

인간이 실제로 수행했던 행동으로 제안서 이야기를 재구성해 봅시다.

• 읽기(Read) — VP는 세 번, 법무팀(Legal)은 한 번, AE는 한 번
• 수정하기(Fix) — AE가 두 번
• 전달하기(Carry) — AE가 VP와 법무팀, 고객에게 이메일을 보냄
• 검색하기(Search) — 다음 달에 다른 AE가 같은 반대에 부딪히자, 왜 그런지 알아내기 위해 오래된 이메일 스레드를 뒤짐

AI는 오직 '초안 작성'만 했습니다. 그 외 모든 것은 인간의 손과 인간의 속도로 진행되었습니다. AI가 아무리 빨라져도, 전체 과정은 '인간이 읽을 수 있는 속도'에 의해 제한됩니다.

나머지 글에서는 두 가지 숫자가 다루어집니다.

• 인간 개입 횟수(Human interventions) — 결과물이 수신자에게 도달하기 전에 인간이 몇 번 읽거나, 수정하거나, 전달했는지의 횟수. 위의 이야기에서: 읽기 5회, 수정 2회, 전달 3회로 총 10회입니다.
• 결정 분할(Decision split) — 해당 결과물에 대해 내려진 결정들이 기계가 얼마나, AI가 얼마나, 인간이 얼마나 담당했는지의 비율. 위 사례에서는: 인간이 100%를 차지했습니다.

하네스는 이 두 가지 숫자, 즉 개입 횟수를 시작점과 끝점으로 이동시키고, 결정을 기계 쪽으로 전환시키는 역할을 합니다. 품질은 배포 후 반환(post-delivery returns), 수정 사항, 사고 등을 통해 별도로 측정됩니다. 만약 개입 횟수를 줄였는데 그 수치가 올라간다면, 잘못하고 있는 것입니다.

3. 소프트웨어 개발에서 이미 일어나고 있는 일

소프트웨어 팀들은 AI가 코드를 작성하기 시작했을 때 이 문제에 가장 먼저 직면했고, 이에 대한 답도 가장 먼저 얻었습니다. 저자의 환경에서는 AI가 작성한 변경 사항들이 하루에 수백 번 검토되고 병합됩니다. 아무도 그것들을 전부 읽지 않으며, 시도하는 사람도 없습니다.

작동하지 않는 변경 사항은 여전히 반영되지 않습니다. 왜냐하면 단계들 사이에 기계 검사(machine checks)가 존재하며, 검사에 실패할 경우 AI는 작업을 다시 수행하도록 되돌려 보내지기 때문입니다. 흐름은 다음과 같습니다:

1. 사람이 원하는 것을 작성하고, 요청당 하나의 티켓을 만듭니다. 초안도 괜찮으며, AI가 이를 다듬습니다.
2. AI가 변경 사항을 적용합니다.
3. 기계가 검사합니다. 스타일 규칙, 유형 일관성, 각 유닛의 동작, 엔드-투-엔드(end-to-end) 경로 등을 확인합니다. 무언가 실패하면 AI가 이를 수정하고 재실행합니다. 인간은 보지 않습니다.
4. 다른 AI가 읽고 코멘트를 남깁니다. AI가 이를 수정합니다. 검토자가 만족할 때까지 이 과정이 자동으로 반복됩니다.
5. 인간에게 도달하는 것은 '모든 것을 통과한 변경 사항'과 'AI가 인간의 판단을 원하는 지점들'입니다.
6. 인간이 병합(merge) 여부를 결정합니다. 몇 분 안에 이루어집니다.
7. 동일한 코멘트가 두 번 나타나면, 그것은 기계 규칙이 됩니다. 그 이후로는 인간도 AI도 다시는 볼 수 없습니다.

인간이 관여하는 단계는 1단계와 6단계입니다. 대부분의 결정은 기계에 의해 이루어지며, AI의 역할은 기계가 통과할 때까지 계속해서 재작업하도록 하는 것입니다. 요청, 변경 사항, 검사 결과, 코멘트, 결정 및 이력 전체가 한 곳(GitHub)에서 관리됩니다.

중요한 부분은 도구 이름이 아니라 구조입니다. 기계가 멈추고, AI가 초안을 작성하고 플래그를 지정하며, 인간은 예외 사항만 확인합니다. 모든 것이 한 곳에서 실행되며, 동일한 코멘트는 결코 인간에게 두 번 전달되지 않습니다. 도구들은 마지막 사이드바에 있습니다.

4. 비즈니스 하네스(business harness)란 무엇인가

정의

**비즈니스 하네스(business harness)**는 AI 에이전트가 인간의 개입을 최소화하면서도 일관된 품질의 결과물을 생성하도록 하는 제어 시스템입니다.

AI의 동작은 확률적입니다. 동일한 요청이라도 매번 다른 결과물이 나오며, 어떤 날은 가정이 누락되고 또 다른 날은 숫자에 출처가 없습니다. 하네스는 이러한 변동성(variance)을 결정론적 제약 조건으로 감싸고 기계가 내리는 결정의 수를 늘려, AI 자체는 변하지 않더라도 결과물이 안정화되게 합니다. 당신은 AI를 더 똑똑하게 만드는 것이 아니라, 그 주변 환경을 강화하는 것입니다.

세 가지 계층

제어는 세 개의 계층으로 구성됩니다. 계층이 낮을수록 더 넓고 강력합니다.

오직 결정론적인 계층인 머신만이 중지할 권한을 가질 수 있습니다. AI의 판단은 변동하기 때문에 게이트 역할을 할 수 없습니다. 만약 그것을 게이트로 만든다면, 같은 제안이 월요일에는 통과하고 화요일에는 실패하게 될 것입니다. 설명할 수 없는 판결은 아무도 따르지 않습니다.

그렇다면 AI는 무엇을 할까요? AI는 초안(drafts)을 작성하고 **플래그를 지정(flags)**합니다. AI가 "승인"하는 단계가 있지만, 그것은 게이트가 아닙니다. 두 개의 AI가 상호 댓글과 수정을 주고받으며 인간에게 도달하는 미해결 항목의 수를 줄이는 것입니다. AI가 승인하지 않은 모든 것은 "우려 사항(concern)"으로 첨부되며, 최종적으로는 인간이 결정합니다.

10가지 단계

제어 장치는 어디에 배치되어야 할까요? 워크플로우를 열 가지 단계로 나누고, 각 단계마다 "누가 여기서 결정하는지"라는 제어 지점을 두어야 합니다.

이 열 가지 단계는 **모두가 존재하는 한 곳(허브)**이 필요합니다. 만약 요청, 산출물(artifacts), 검사 결과, 결정 및 이력이 서로 다른 시스템에 존재한다면, 인간은 단계 사이에서 물건을 들고 이동해야 합니다.

하네스(harness)의 임무는 결정을 아래로 계속 밀어내는 것입니다. 인간이 읽어서 발견했던 지점들은 AI의 플래그로 가고; 규칙으로 작성될 수 있는 것은 머신으로 갑니다. 아래로 내려갈수록 개입은 적어지고 분산(variance)도 작아집니다.

중단뿐만이 아니다: 표면화 (Surfacing)

검사는 하네스의 절반에 불과합니다. 2단계는 단순히 "회사 표준을 건네주는" 것이 아닙니다. 그것은 인간이 잊어버린 기록까지 포함하여 이 작업과 관련된 모든 기록을 찾아내고, AI 앞에 제시하는 것입니다.

고객 방문 전: 마지막으로 이 담당자를 언제 만났는지, 무엇을 논의했는지, 무엇을 가져갔는지? 저녁 식사 자리에서 부사장(VP)은 무엇을 주문했고 무엇을 피했는지? 지난 한 달 동안 그 회사는 어떤 발표를 했는가? 웹 문의가 거래로 이어졌다면: 원래 문의 텍스트, SDR의 자격 검증 메모, 통화 기록, 과거 제안서 및 견적, 최신 10-K 보고서.

인간은 잊는다. 계정 소유자가 바뀌면 모든 것이 사라진다. 기계는 잊지 않는다. 기록이 허브에 있는 한, AI가 이를 읽고 다음 단계를 제안하는 주체가 된다: 선물 추천, 비즈니스 사례의 골격, 견적서 초안, 출장 보고서. 인간이 기억하고, 검색하고, 주변을 물어보는 데 썼던 시간이 사라진다.

(④)를 중단하고 (②③)를 표면화하는 것은 동일한 데이터와 동일한 허브에서 실행된다. 둘 중 하나만으로는 연결되지 않는다. 확인용으로 구조화했던 기록들이 제안서에 필요한 피드 데이터가 되는 것이다.

5. 이미 가지고 있는 도구들에서 부족한 점은 무엇인가요

기업들은 부품이 부족하지 않다. 오히려 너무 많은 경우가 많다.

• 초안 작성 (Drafting) — ChatGPT, Claude, Gemini, Microsoft 365 Copilot, Gemini for Google Workspace, Notion AI
• 저장된 지침 (Saved instructions) — 사용자 지정 지침(custom instructions), GPTs, Claude Projects, Copilot Studio 에이전트, 내부 프롬프트 라이브러리
• AI 검토 (AI review) — 누락된 조항이나 정책 위반 언어를 플래그하고 대체 방안을 제안하는 AI 플레이북 기반의 계약 수명 주기 관리(Ironclad, Evisort 등). Copilot과 Grammarly의 문서 검토 기능
• 인간 승인 (Human approval) — Salesforce, NetSuite, ServiceNow 또는 Jira에서의 승인 워크플로우; 누가 얼마까지 승인할 수 있는지 정의하는 권한 위임 매트릭스(delegation-of-authority matrices)
• 전송 및 서명 (Send and sign) — 전자 서명(DocuSign 등)으로, 계약 관리 및 검토 기능과 점점 더 통합되고 있음
• 기계적 확인 (Machine checks) — Salesforce와 ERP 시스템에서의 필드 유효성 검사; 회계 지급 부서의 3자 일치(PO, 수령증, 송장); 구매 시 정책 외 지출을 플래그하거나(Ramp의 경우 차단) 하는 경비 플랫폼(Ramp, Concur, Expensify); 이메일, 드라이브, 채팅 전반에 걸쳐 민감한 데이터를 감지하고 차단하는 데이터 손실 방지(Microsoft Purview 등)

이 모든 기능들은 각자의 영역 내에서 작동합니다. 부족한 것은 특정 기능 하나가 아닙니다. 네 가지 연결고리입니다.

격차 1: 단계들이 연결되어 있지 않고 한 곳에 존재하지 않습니다.
요청은 Slack에 있고, 맥락(context)은 Google Drive에 있으며, 초안은 채팅 창에, 승인은 Salesforce에, 전달은 이메일에, 기록은 각 시스템의 자체 로그에 있습니다. 모든 단계가 다른 장소에 있기 때문에 인간이 그 사이를 연결합니다. 운반자의 속도가 곧 회사의 속도가 됩니다.

Gap 2: 기계 레이어는 문서에 취약하다.
필드 유효성 검사(Field validation)는 시스템에 입력된 데이터에 대해 작동하며, Word나 Google Docs로 작성된 제안서에는 작동하지 않습니다. 삼자 일치(Three-way match)는 송장(invoices)에 대해 작동할 뿐, 견적서(quotes)에는 작동하지 않습니다. 비용 정책 엔진은 카드 거래에 대해서만 작동하며, 작업 명세서(SOW)에는 작동하지 않습니다. DLP(Data Loss Prevention)는 신용카드 번호를 잡아내지만, "가정 섹션이 누락됨" 또는 "임시로 표시된 가격이 최종으로 작성됨" 같은 개념적 오류는 포착하지 못합니다. 그리고 문서란 바로 AI가 대량으로 생산하는 것 그 자체입니다.

Gap 3: 반론(return)에서 규칙(rule)으로 이어지는 경로가 없다.
반대 의견(pushback)의 이유는 작성자에게 이메일로 끝납니다. 아무것도 기록되지 않기 때문에, 같은 코멘트가 두 번 나타났다는 사실을 누구도 알아차리지 못합니다. 이러한 경로가 없으면 인간이 도달하는 항목의 수는 줄어들지 않습니다.

Gap 4: 교차 영역 가시성이 없다.
사용자 본인의 승인 대기열은 볼 수 있습니다. 하지만 제안서, 계약서, 비즈니스 케이스, 송장 전반에 걸쳐 어떤 항목이 어디에서 얼마나 오랫동안 막혀 있는지(stuck)는 알 수 없습니다.

이 네 가지 간극은 독립적이지 않습니다. 허브(Gap 1)가 없으면 가시성(Gap 4)을 구축할 수 없고; 기계 레이어(Gap 2)가 없으면 새로운 규칙(Gap 3)이 자리 잡을 곳이 없습니다. 따라서 부품을 더 많이 구매한다고 해서 연결되는 것은 아닙니다. 이것은 가지고 있는 제품들을 대체하는 문제가 아닙니다. 그것은 이 모든 것을 하나의 제어 흐름으로 연결하는 "기반 레이어(bottom layer)"에 관한 문제입니다.

배선(wiring)의 조건: 모든 것이 데이터이며, 모든 것이 API를 통해 실행된다

이것이 도구 선택 기준을 명확히 합니다.

하네스(harness)란 인간이 아닌 기계와 AI가 단계 사이에서 작업을 전달하는 메커니즘입니다. 기계와 AI는 API(도구를 외부에서 작동시키기 위한 연결 지점, 사람이 화면을 클릭할 필요가 없는 방식)를 노출하는 도구만을 구동할 수 있습니다. 인간의 클릭이 있을 때만 움직이는 도구는 인간을 그 단계에 강제로 투입시킵니다. 그러한 도구는 하네스 밖에 존재합니다.

세 가지 규칙이 뒤따릅니다.