원문은 twarx.com에서 처음 게시되었습니다 - 전체 인터랙티브 버전은 그곳에서 읽을 수 있습니다.

최종 업데이트: 2026년 6월 21일

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. Union Square에서 열린 제2회 연례 617 Day 소기업 서밋에서 MIT와 Toast의 전문가들은 약 60명의 지역 사업주들에게 AI에 '그저 뛰어들라'고 조언했습니다. 그 조언은 옳지만 — 불완전합니다. 현대 AI 기술의 어려운 점은 더 이상 모델 (Model)이 아닙니다. 그것은 에이전트 (Agents), 도구 (Tools), 그리고 인간 사이에 위치하는 조정 계층 (Coordination layer)입니다. 프로덕션 환경의 멀티 에이전트 (Multi-agent) 배포 사례를 직접 분석한 결과, 모델이 아니라 바로 이 인계 계층 (Handoff layer)에서 약 80%의 시스템이 무너지고 있습니다.

Cambridge Local First (400개 이상의 기업 네트워크)가 주최한 이번 서밋은 지역 상권(Main Street)이 AI, Amazon, 그리고 로컬 미디어의 붕괴 속에서 어떻게 살아남을 수 있는지에 초점을 맞췄습니다. LangGraph, RAG, MCP와 같은 도구들은 이미 오래전에 더 이상 어려운 부분이 아니게 되었습니다.

이 글을 다 읽을 때쯤이면, 대부분의 프로덕션 AI를 조용히 망가뜨리는 단 하나의 실패 모드(Failure mode), 즉 에이전트, 도구, 인간 사이의 조정 계층 (Coordination layer)에 대해 이해하게 될 것입니다. 제가 80%의 실패율을 언급하는 것은 프로덕션 배포에 대한 저희 자체 내부 검토를 지칭하는 것이며, 이 수치는 절대적인 진리라기보다 아래 EEAT 노트에서 자격 요건을 설명하겠습니다.

80% 수치에 대하여: 이는 저희가 감사하거나 재구축한 수십 개의 SMB(중소기업) 및 미드마켓(Mid-market) AI 배포 사례에 대한 Twarx의 내부 검토를 반영한 것입니다. 대다수는 모델이 아니라 오케스트레이션 (Orchestration) 단계에서 실패했습니다. 이는 피어 리뷰(Peer-reviewed)를 거친 설문 조사가 아니라, 방향성을 제시하는 직접적인 관찰 결과입니다. 아래의 복리 오차(Compounding-error) 계산(97%의 6단계 체인이 83%로 떨어지는 현상)은 이 패턴이 놀랍지 않은 이유를 보여줍니다. 이를 저희가 출처인 실무자의 현장 추정치로 간주해 주십시오.

'AI on Main Street' 패널은 Cambridge Vice Mayor인 Burhan Azeem이 진행했으며, MIT의 Tim Valicenti, MIT CISR 디렉터 Stephanie Woerner, 그리고 Toast의 Conor Henrie가 참여했습니다. 출처: Cambridge Day

발표된 내용 — 617 Day AI 서밋, 정확한 사실들

2026년 6월 17일 수요일, 매사추세츠주 캠브리지 유니언 스퀘어의 USQ 건물에서 제2회 617 Day Small Business Summit이 개최되었습니다. 이 내용은 Cambridge Day 기자 Madison Lucchesi에 의해 2026년 6월 21일에 보도되었습니다. 아래 패널 인용문은 해당 보고서에서 발췌한 것이며, 제가 현장에 있지 않았으므로 직접 참석했다고 주장하기보다는 보도를 인용하는 것입니다.

공식 출처에서 확인된 주요 사실들:

• 617 Day는 400개 이상의 사업체 네트워크인 Cambridge Local First가 만든 소상공인 기념일입니다. 이 이름은 그레이터 보스턴(Greater Boston)의 617 지역 번호와 날짜인 6월 17일을 활용한 것입니다.

• 참석자는 약 60명이었습니다.

• 개회 패널인 **'AI on Main Street'**은 Cambridge Vice Mayor Burhan Azeem이 진행했습니다.

• 패널리스트: MIT Sloan School of Management의 강사 Tim Valicenti; MIT Center for Information Systems Research 디렉터 Stephanie Woerner; 그리고 레스토랑 플랫폼 Toast의 제품 디렉터 Conor Henrie.

Cambridge Day에 따른 핵심 가이드는 다음과 같습니다. Valicenti는 '그냥 뛰어드세요(Just dive in)'라고 말했습니다. AI 엔진과 함께하는 단 하룻밤만으로도 유용한 지식을 얻을 수 있기 때문입니다. AI를 '인턴처럼' 대하십시오. 실수를 확인하고 추가로 교육하십시오. Henrie는 AI가 소유자들에게 '더 많은 시간을 되돌려준다'고 표현하면서도, '기술이 실제로 스며드는 데는 20~25년이 걸릴 수 있다'고 경고했습니다. Woerner는 소유자들이 '실수가 생명을 위협하지 않는' 비즈니스 영역을 찾고, '우리가 하는 방법을 모르는 일들을 수행하기 위해 AI를 사용하라'고 촉구했습니다.

단계별 신뢰도가 97%인 6단계 AI 파이프라인은 전체 프로세스(end to end) 관점에서 보면 신뢰도가 83%에 불과합니다. '그냥 뛰어드는 것'은 올바른 첫 번째 움직임이지만, 조정 계층(coordination layer) 없이 뛰어드는 것이 바로 그 17%의 오류가 소리 없이 배포되는 방식입니다.

AI 조정 격차(AI Coordination Gap)란 무엇인가? 쉬운 영어 정의

이제 단일 AI 작업들은 대부분 즉시 작동합니다. 메뉴 설명을 초안 작성하거나, 날씨와 금리를 요약하여 일일 이메일로 보내거나, 공과금 납부 알림을 설정하는 등의 작업 말입니다. Valicenti의 말은 이 부분에서 옳습니다. 저 또한 소유자들이 단 하룻밤 만에 유용한 결과물을 얻는 것을 목격해 왔습니다.

함정은 이러한 작업들을 실제 비즈니스가 의존하는 무언가로 사슬처럼 연결할 때 발생합니다. 예를 들어 예약을 읽고, 재고를 확인하고, POS(판매 시점 관리) 시스템을 업데이트하고, 고객에게 이메일을 보내며, 매니저에게 알림을 보내는 시스템 같은 것입니다. 개별 단계들은 작동합니다. 하지만 모든 것이 망가지는 지점은 바로 '단계 간의 인계(handoffs)'입니다. 그리고 아무도 당신에게 경고하지 않습니다. 왜냐하면 각 구성 요소는 자체적인 데모(demo)를 통과하기 때문입니다.

고안된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차는 작동하는 개별 AI 작업과 작동하지 않는 다단계 AI 시스템 사이의 신뢰도 절벽(reliability cliff)을 의미합니다. 이는 실패가 단일 모델 호출 내부에서 발생하는 것이 아니라, 모델 간의 인계(handoffs), 상태(state), 그리고 결정(decisions) 과정에서 발생하기 때문입니다. 이는 대부분의 팀이 이미 제품을 배포한 후에야 발견하게 되는 시스템적 문제를 지칭합니다.

Henrie의 '인턴으로서의 AI (AI as intern)' 비유는 들리는 것보다 더 정교합니다. 단 한 명의 인턴이 하나의 작업을 수행하는 것은 괜찮습니다. 하지만 매니저도, 공유된 메모도, 체크리스트도 없이 다섯 명의 인턴이 고객 주문을 서로 전달하며 작업한다면, 비록 각 인턴이 개별적으로는 매우 똑똑할지라도 그것은 재앙입니다. 부분의 역량이 전체의 역량을 보장하지는 않습니다. 부분과 전체 사이의 그 간극이 바로 조정 격차 (coordination gap)입니다.

83%
각 단계의 신뢰도가 97%인 6단계 체인의 엔드 투 엔드 (End-to-end) 신뢰도 (0.97⁶)
[오차 누적 원리 (Compounding error principle), arXiv](https://arxiv.org/)
...

시각화된 AI 조정 격차 (AI Coordination Gap): 개별적으로 신뢰할 수 있는 AI 단계들이 결합되어 취약한 엔드 투 엔드 (end-to-end) 시스템이 됩니다. 이것이 바로 모델의 품질이 아니라 오케스트레이션 (orchestration)이 진정한 병목 현상인 이유입니다.

왜 AI 기술은 모델이 아닌 조정 계층 (Coordination Layer)에서 무너지는가

현대 AI 시스템은 네 개의 계층을 가집니다. 정상급 전문가들의 조언은 가장 상위 계층을 다룹니다. 조정 격차는 중간의 두 계층, 즉 문제가 발생하기 전까지는 보이지 않기 때문에 소규모 비즈니스 컨퍼런스에서 아무도 이야기하지 않는 계층에 존재합니다.

프로덕션 AI 시스템의 4계층 스택 (Four-Layer Stack of a Production AI System)

  1

    **모델 계층 (Model Layer) (GPT, Claude, Gemini)**

가공되지 않은 추론 엔진입니다. 이는 소유자들이 '깊게 파고드는' 영역입니다. 입력(Input): 프롬프트 (prompt). 출력(Output): 텍스트 또는 도구 호출 (tool call). 잘 정의된 작업에 대한 호출당 신뢰도는 이제 높은 수준(~95-99%)입니다.

↓

  2
...

모델이 귀하의 실제 데이터 — POS, 예약 정보, 재고 — 에 도달하는 방법입니다. 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 이러한 연결을 표준화합니다. Pinecone 및 기타 벡터 데이터베이스 (vector databases)는 RAG를 통해 관련 컨텍스트 (context)를 제공합니다.

↓

  3
...

조정 격차 (Coordination Gap)가 바로 여기에 존재합니다. 이 계층은 다음 단계로 무엇을 실행할지 결정하고, 공유 상태 (shared state)를 유지하며, 실패 시 재시도 (retries)를 수행하고, 에이전트 (agents) 간의 라우팅 (routing)을 담당합니다. 이 부분을 잘못 설계하면 신뢰할 수 있는 개별 단계들이 모여서 결국 신뢰할 수 없는 시스템을 만들어냅니다.

↓

  4
...

Woerner의 조언이 담긴 핵심은 이것입니다: 신뢰를 얻을 때까지 '실수가 생명을 위협하지 않는' 단계에 인간을 배치하십시오. 승인 게이트 (Approval gates)는 조용한 실패 (silent failures)를 포착 가능한 실패로 전환해 줍니다.

소유자들은 레이어 1 (Layer 1)에 '몰입'하지만, 실제 비즈니스 시스템의 신뢰성은 대부분의 팀이 무시하는 오케스트레이션 계층 (orchestration layer)인 레이어 3 (Layer 3)에서 결정됩니다.

AI 에이전트 (AI agents)로 승리하고 있는 기업들은 최고의 모델을 가진 기업들이 아닙니다. 바로 레이어 3 (Layer 3) 문제를 해결한 기업들입니다. LangGraph (GitHub 별 15K개 이상)가 존재하는 이유는 단순한 프롬프트 체인 (prompt chains)이 인계 (handoffs) 과정에서 상태 (state)를 유지할 수 없기 때문입니다.

왜 격차가 발생할까요? 각 인계 (handoff) 과정에서 단일 호출 (single calls) 시에는 존재하지 않는 세 가지 새로운 실패 모드 (failure modes)가 발생하기 때문입니다: 상태 손실 (state loss) (3단계가 1단계에서 결정한 내용을 잊어버림), 오류 전파 (error propagation) (1단계의 작은 실수가 5단계에서 치명적인 동작이 됨), 그리고 모호한 라우팅 (ambiguous routing) (시스템이 다음에 어떤 에이전트가 행동해야 할지 알지 못함). 오케스트레이션 계층 (orchestration layer)의 전체 임무는 바로 이 세 가지를 관리하는 것입니다. 더 깊이 있는 아키텍처적 접근을 원하신다면, AI 에이전트 아키텍처 (AI agent architecture) 가이드를 참조하십시오.

더 나은 모델이 AI 조정 격차 (AI Coordination Gap)를 메워주지는 않습니다. 6단계 체인에서 99% 신뢰도를 가진 모델이라도 엔드 투 엔드 (end to end)로 가면 여전히 94%로 떨어집니다. 해결책은 구조적인 것입니다. 즉, 명시적인 상태 (explicit state), 라우팅 (routing), 재시도 (retries), 그리고 인간 게이트 (human gates)를 구축하는 것이지, 결코 더 똑똑한 프롬프트 (smarter prompt)를 만드는 것이 아닙니다.

전체 기능 목록: 조정된 AI 시스템이 실제로 할 수 있는 일

617 Day 패널들이 제기한 정확한 유스케이스 (use cases)에 맞춰, 제대로 조정된 시스템이 단순한 프롬프트 체인 (prompt chain)과 비교하여 실제로 제공하는 기능은 다음과 같습니다:

• 일일 통계 이메일 (Daily statistics email) (날씨, 이자율) — Woerner/패널의 제안. 조정된 (Coordinated) 버전은 여러 개의 라이브 API에서 데이터를 가져오고, 중복을 제거하며, 하나의 소스가 다운되더라도 우아하게 실패 (fails gracefully) 처리합니다.

• 정기적인 청구서 및 작업 알림 (Reminders for routine bills and tasks) — 패널의 제안. 오케스트레이션 (Orchestration)을 사용하면, 결제 누락 위험이 발생했을 때 단순히 로그에만 기록되는 것이 아니라 에스컬레이션 (escalation)을 트리거합니다.

• 학습 루프를 가진 인턴으로서의 AI (AI as intern with training loop) — Valicenti. 오케스트레이션은 수정 사항을 재사용 가능한 컨텍스트 (RAG memory)로 캡처하므로, '인턴'이 실제로 개선됩니다.

• 레스토랑 운영 (Restaurant operations) — Toast의 도메인: 예약 → 재고 확인 → POS 업데이트 → 고객 확인, 각 핸드오프 (handoff) 단계는 재시도되고 로그에 기록됩니다.

• '방법을 모르는 일을 수행하기' ('Doing things you don't know how to do') — Woerner. 멀티 에이전트 시스템 (Multi-agent systems)은 플래너 에이전트 (planner agent)와 실행 에이전트 (executor agents)를 결합하여 익숙하지 않은 워크플로우를 안전하게 시도합니다.

AI를 인턴처럼 대하라는 말은 맞습니다. 하지만 매니저도 없고, 공유된 노트도 없으며, 체크리스트도 없는 단 한 명의 인턴은 여전히 5단계의 프로세스를 망가뜨릴 것입니다. 매니저가 바로 오케스트레이션 계층 (orchestration layer)입니다.

사용 방법: 조정 격차를 해소하는 실무 시연

Toast 고객이라면 익숙할 실제 레스토랑 시나리오를 사용하여 실무에서의 차이점을 보여드리겠습니다. 단순한 접근 방식은 하나의 거대한 프롬프트 (mega-prompt)를 사용하는 것입니다. 조정된 접근 방식은 명시적인 상태 (explicit state)와 인간의 승인 단계 (human gate)를 갖춘 LangGraph를 사용하며, 이것이 바로 격차를 해소하는 계층입니다.

Python — LangGraph를 이용한 조정된 예약 워크플로우

샘플 입력: "금요일 오후 7시, 4명 예약, 고객은 단골이며 갑각류 알레르기가 있음"

from langgraph.graph import StateGraph, END
from typing import TypedDict

공유 상태 (Shared state) = 핸드오프 사이의 상태 손실을 해결하는 해결책

class ReservationState(TypedDict):
request: str
table_available: bool
allergy_flagged: bool
needs_human: bool
confirmation: str

def check_availability(state):
# 1단계: POS/예약 시스템 조회 (Toast 스타일 API)
state['table_available'] = True # 라이브 인벤토리에서 가져옴
return state

def flag_allergy(state):

단계 2: 오류 전파 방지(error propagation guard) — 안전 플래그를 조용히 누락하지 말 것

if 'allerg' in state['request'].lower():
state['allergy_flagged'] = True
state['needs_human'] = True # Woerner의 규칙: 위험한 단계에서는 사람이 개입함
return state

def route(state):

단계 3: 모호한 라우팅(ambiguous routing)을 명시적으로 해결

return 'human_review' if state['needs_human'] else 'confirm'

def confirm(state):
state['confirmation'] = '예약 완료. 확인 메시지가 전송되었습니다.'
return state

def human_review(state):
state['confirmation'] = '관리자 검토 대기 중: 알레르기 여부를 반드시 확인해야 합니다.'
return state