기업용 AI에는 하나의 환상이 있습니다. 언더라이팅(underwriting), 보험금 청구(claims), 서비스(servicing), 지원(support) 등 모든 것을 수행하는, 모든 것을 다스리는 단 하나의 프롬프트와 전지전능한 모델에 대한 환상입니다. 실제로 배포되고 생존하는 아키텍처는 거대한 단일체(monolith)라기보다는 **조직도(org chart)**에 더 가깝습니다. 즉, 정의된 업무를 가진 특화된 에이전트(narrow agents), 명확한 인수인계(handoffs), 그리고 중요한 결정에는 인간이 참여하는 구조입니다. 이것은 타협안이 아닙니다. 규제가 엄격하고 높은 책임이 요구되는 영역에서는 이것이 올바른 설계입니다.

단일체(Monolith)가 실패하는 이유

• 검사가 불가능합니다. 하나의 거대한 모델이 모든 결정을 내릴 때, "왜 그렇게 했는가?"라는 질문에 깔끔한 답을 내놓을 수 없습니다. 보험(및 금융, 의료) 분야에서는 어떤 컴포넌트가 무엇을 왜 수행했는지 말할 수 있어야 합니다. 단일체는 감사(audit)의 블랙홀입니다.
• 폭발 반경(Blast radius). 보험금 청구 처리를 개선하기 위해 프롬프트를 변경하면, 모든 것이 뒤엉킨 하나의 컨텍스트(context)이기 때문에 언더라이팅 성능이 조용히 저하됩니다. 특화된 에이전트들은 고립된 상태에서 실패합니다.
• 컨텍스트 희석(Context dilution). 모든 도구, 정책, 지침을 하나의 컨텍스트 윈도우(context window)에 밀어 넣으면 모델의 모든 성능이 저하됩니다. 집중된 컨텍스트와 도구를 가진 전문가가 모든 것을 저글링하는 일반가(generalist)보다 더 나은 성능을 발휘합니다.
• 최소 권한 원칙(Least privilege) 부재. FAQ에 답변하는 에이전트가 돈을 이체하는 도구를 가져서는 안 됩니다. 하나의 단일체는 곧 하나의 과도한 권한을 가진 폭발 반경을 의미합니다.

작동하는 형태

팀처럼 모델링하세요:

        ┌─────────────┐
        │ Orchestrator│  의도에 따라 라우팅하며, 도메인 권한은 갖지 않음
        └──────┬──────┘
...

각 에이전트는:

• **단일 업무(single job)**를 가지며, 해당 업무에 필요한 도구만 가집니다(최소 권한 원칙),
• 채팅 기록의 덩어리가 아닌 **구조화된 컨텍스트(structured context)**로 업무를 인수인계하며,
• 어떤 에이전트가 어떤 입력을 받아 무엇을 결정했는지 **변경 불가능한 감사 추적(immutable audit trail)**에 기록합니다.

에이전트가 '행동'하는 순간의 세 가지 필수 조건

에이전트가 단순히 '보조'하는 단계에서 벗어나 실제 행동을 '조율(orchestrating)'하는 순간, 다음이 필요합니다:

1. 중요한 단계에서의 Human-in-the-loop (인간 참여) 게이트 (승인, 결제, 취소 등).
2. 모든 결정과 인계(handoff)에 대한 불변의 감사 추적 (immutable audit trail).
3. 적대적 입력에 대한 가드레일 (guardrails) (프롬프트 인젝션 (prompt injection) 참조) — 신뢰할 수 없는 데이터를 읽는 특화된 에이전트(narrow agents)는 권한이 부여된 도구(privileged tools)를 보유해서는 안 되기 때문입니다.

이것은 AGI가 아닙니다 — 훌륭한 시스템 설계입니다

승리하는 패턴은 더 똑똑한 모델이 아닙니다. 그것은 우연히 소프트웨어의 형태를 띤, 잘 운영되는 부서입니다. 깨끗한 인계(handoff) 프로세스를 갖추고, 검사 가능하며, 최소 권한 원칙(least-privilege)을 따르는 특화된 에이전트들은 디버깅할 수 없고, 감사할 수 없으며, 안전하게 권한을 부여할 수 없는 거대한 단일 모델(monolith)보다 훨씬 뛰어납니다. 흥미로운 엔지니어링은 단일 모델의 크기가 아니라, 그 기저(substrate)가 되는 **오케스트레이션 (orchestration), 인계 (handoffs), 그리고 가드레일 (guardrails)**에 있습니다.

보험 프레임워크를 적용한 전체 글:

거대한 AI 하나로는 보험사를 운영할 수 없습니다. 에이전트 팀이라면 가능할지도 모릅니다. →

IntelliBooks의 보험 AI 하의 데이터 기반 시리즈 중.

여러분의 스택은 단일 모델(monolith)인가요, 아니면 멀티 에이전트(multi-agent)인가요? 여러분은 에이전트의 경계를 어디에 설정하셨나요?