현실의 고통: 당신의 Agent에 20개 이상의 도구(Tool)가 설정되어 있어 이론적으로는 무엇이든 할 수 있습니다. 하지만 실제로는 도구를 빈번하게 잘못 사용합니다. 사용자가 운송비를 물으면 연락처를 검색하곤 하죠.
이 글을 읽고 나면: 시나리오 라우팅 (Scene Routing)을 배우게 됩니다. 하나의 라우팅 레이어를 사용하여 「전능한 Agent」를 6개의 시나리오 전문가로 분해하며, 각 시나리오는 자신에게 할당된 도구만 볼 수 있게 됩니다.

〇. 서문: 왜 이 시리즈를 OPC보다 먼저 진행하는가

이전 글인 「Agent에 『샌드위치』 아키텍처를 입혔다」를 게시한 후, 백엔드로 많은 메시지가 쏟아졌습니다.

팬들이 가장 많이 질문한 세 가지 유형은 다음과 같습니다:

• 「샌드위치 구조가 좋다는 건 알겠는데, 구체적으로 각 단계를 어떻게 구현(落地)하나요?」
• 「제 Agent는 여전히 복잡한 작업에서 혼란을 겪는데, 어떻게 해결하나요?」
• 「당신이 말한 『확률적인 LLM을 결정론적 코드(Deterministic Code)로 포위한다』는 개념을, 바로 가져다 쓸 수 있는 완전한 체계로 제공해 줄 수 있나요?」

솔직히 말씀드리면, 저 또한 이 문제들을 모두 겪어보았습니다. OPC를 만드는 과정에서 저는 「상업화 가능한 엔지니어링 체계」에 엄청난 시간을 투자했습니다. 모델이 똑똑하지 않아서가 아니라, 모델이 실제 비즈니스 환경에서 안정적이고, 제어 가능하며, 감사(Audit) 가능한 방식으로 정확한 결과를 출력하게 만드는 것이 너무나 어려웠기 때문입니다.

그래서 원래 계획했던 OPC 시리즈는 잠시 미뤄두기로 했습니다. 대신 「Agent 엔지니어링의 스캐폴딩(Scaffolding)과 제어 체계」라는 내용을 더 깊고, 넓고, 상세하게 다루고자 합니다. 이것이야말로 OPC(그리고 그 어떤 상업용 Agent 시스템)가 실제로 작동할 수 있게 만드는 진정한 기반이기 때문입니다.

이 시리즈를 통해, 저는 6편의 글을 사용하여 완전한 상업용 Agent 엔지니어링 체계를 처음부터 끝까지 분해하여 보여드릴 계획입니다:

01 · 시나리오 라우팅 — 왜 「전능한 Agent」는 반드시 실패하는가       ← 이 글
02 · 이중 분류 — 정규식(Regex) + 의미론적(Semantic), 놓치는 것 없는 분류
03 · 복합 프로세스 컨테이너 — 보고서는 시나리오가 아니라 파이프라인이다
...

왜 이 글을 끝까지 읽어야 할까요?

이것은 단순한 기술 튜토리얼이 아니라, 상업화가 가능한 체계이기 때문입니다. 각 편에서 다루는 내용은 모두 실제 시스템에서 구동된 솔루션이며, 이론에만 그치는 것이 아닙니다. 이 6편을 완전히 이해하고 따라 한다면, 당신이 구축한 Agent 시스템은 실제 비즈니스를 견뎌낼 수 있는 — 안정적이고, 신뢰할 수 있으며, 인도 가능한(Deliverable) 시스템이 될 것입니다.

자, 시작하겠습니다.

一. 문제점: 주방에 망치를 찾으러 들어가는 상황

상상해 보세요. 당신이 주방에 망치를 찾으러 들어갔는데, 차고에 식칼을 찾으러 들어가는 상황을 말입니다. 각 방에는 그에 맞는 도구가 있어야 합니다. 하지만 만약 모든 도구를 거실에 쌓아둔다면, 망치를 찾을 때 식칼, 렌치, 드라이버, 전기 드릴 등을 보게 될 것이고, 결국 잘못된 것을 선택하게 될 것입니다.

초기 Agent 아키텍처가 바로 그러했습니다. 저는 20개 이상의 도구를 설정했습니다: 이메일 검색, SQLite 쿼리, PDF 생성, 연락처 검색, 견적 계산, 운송비 조회 등... 이론적으로는 무엇이든 할 수 있었습니다. 하지만 실제로는 잘못된 시나리오에서 잘못된 도구를 빈번하게 호출했습니다.

전형적인 실패 사례:

• 사용자가 「XX 항공편 운송비가 얼마인가요?」라고 물으면, Agent는 연락처를 검색합니다.
• 사용자가 「이 화물의 진행 상황을 확인해 줘」라고 하면, Agent는 견적서를 생성하고 있습니다.

이유는 간단합니다. 도구가 너무 많기 때문입니다. LLM의 추론 경로(Reasoning Chain)가 여러 도구 영역 사이를 반복해서 건너뛰면서 컨텍스트(Context)가 파편화되고, 결국 잘못된 선택을 하게 됩니다.

💡 핵심 통찰: LLM의 도구 호출 정확도는 가시적인 도구의 수와 반비례합니다. 도구가 많아질수록 잘못 선택할 확률은 기하급수적으로 증가합니다.

▲ 시나리오 라우팅: 전능한 Agent → Router 분배 → 6개의 전용 Worker

二. 핵심 아이디어: 시나리오 격리

시나리오 라우팅의 핵심 사상은 다음과 같습니다: 하나의 Agent가 모든 시나리오를 처리하게 하지 마십시오.

먼저 라우팅 레이어(Routing Layer)가 현재 작업의 시나리오 유형을 판단한 다음, 해당 시나리오에 전용 SOP, 도구 세트 및 지식 베이스를 주입합니다.

이는 마이크로서비스 아키텍처(Microservices Architecture)와 유사합니다. 모든 요청을 처리하기 위해 단일 서비스(Monolithic Service)를 사용할 필요 없이, API 게이트웨이를 통해 대응하는 백엔드 서비스로 라우팅하는 것과 같습니다. 시나리오 라우팅은 Agent의 「API 게이트웨이」입니다.

물류 AI 어시스턴트는 이메일, 견적, 보고서, 연락처, 재무, 지식 조회를 처리해야 합니다. 만약 모든 도구를 LLM에 개방한다면, 매 호출마다 30개가 넘는 도구 중에서 골라야 하므로 오선택률이 매우 높아집니다.

해결책: task_dispatcher.classify()를 통해 요청을 6개의 시나리오로 분류하며, 각 시나리오는 자신만의 도구 화이트리스트, 스키마(Schema) 강제 및 SOP 주입을 가집니다.

효과는 즉각적입니다: 컨텍스트 길이는 60% 감소하고, 도구 호출 정확도는 40% 향상됩니다. LLM이 무관한 도구 더미 속에서 선택할 필요 없이, 자신의 시나리오에 있는 5~6개의 도구만 확인하면 되기 때문입니다.

三. 기술 구현

3.1 첫 번째 관문: task_dispatcher.classify()

모든 사용자 요청이 시스템에 들어오면 첫 번째 단계는 분류기(Classifier)입니다:

def classify(request_text: str) -> SceneContext:
    # 첫 번째 단계: 정규식(Regex) 정밀 매칭 (90% 커버)
    scene_id = regex_match(request_text)
...

분류 결과는 scene_id, sop_path 및 도구 화이트리스트를 포함하는 구조화된 SceneContext 객체입니다.

3.2 SCENE_CONFIG: 시나리오 설정 파일

각 시나리오는 자신만의 설정을 가집니다:

SCENE_CONFIG = {
    "email": {
        "tools": ["imap_fetch", "smtp_send", "contact_lookup"],  # 도구 화이트리스트 (Whitelist)
...

핵심: 화이트리스트에 포함되지 않은 도구는 아예 로드되지 않습니다. 이메일 시나리오는 데이터베이스 쓰기 기능을 호출할 수 없고, 재무 시나리오는 이메일을 보낼 수 없습니다. 서로 격리되어 각자 독립적으로 작동합니다.

✅ 검증: 시나리오 격리를 도입한 후, 도구 오선택률(Mis-selection rate)이 15%에서 2% 미만으로 감소했습니다 (실제 실행 로그 통계 기준).

🩸 시행착오: 처음에는 「도구가 많을수록 좋다」고 생각하여 LLM에게 모든 도구를 자유롭게 사용하도록 허용했습니다. 그 결과 오선택률이 15%에 달해, 5번 중 1번은 오류가 발생했습니다. 격리 도입 후에는 2%로 낮아졌습니다.

3.3 inject-sop: 실행 전 전용 SOP 로드

SOP 주입은 시나리오 라우팅의 핵심입니다. 시나리오가 결정되면, inject-sop 메커니즘이 해당 시나리오에 대응하는 SOP를 LLM 컨텍스트 (Context)에 주입합니다.

# inject-sop.sh —— LLM 호출 전 매번 시나리오 SOP 주입
scene_id=$(cat /tmp/task_context.json | jq -r '.scene_id')
sop_path="sops/${scene_id}_sop.md"
...

시나리오마다 서로 다른 SOP를 주입합니다: 이메일 시나리오에는 「이메일 작성 SOP」를, 견적 시나리오에는 「견적 SOP」를, 보고서 시나리오에는 「보고서 SOP」를 주입합니다.

SOP는 단 한 번만 주입되는 것이 아닙니다. inject-sop는 컨텍스트 윈도우 (Context Window)를 체크하여, 중요한 노드에서 SOP를 다시 주입함으로써 긴 대화로 인해 내용이 희석되는 것을 방지합니다.

💼 가치: 각 시나리오는 자신의 SOP와 도구만을 보게 되므로 컨텍스트가 깨끗하게 유지되며, 잘못된 호출이 대폭 감소합니다.

▸ 인지적 도약: 시나리오 라우팅의 본질은 기술적 혁신이 아니라 아키텍처 사고방식의 전환입니다 — Agent를 풀스택(Full-stack)이 아닌 전문화(Specialization)시키는 것.

4. 여섯 가지 시나리오 상세 설명

5. 장단점

✅ 장점

• 컨텍스트가 깨끗함 — LLM은 현재 시나리오와 관련된 도구 및 지식만을 확인
• 도구 호출 정확도 90% 이상 향상
• 출력 형식의 일관성 — 시나리오별 고정된 스키마 (Schema)
• 디버깅 용이 — 문제 위치를 시나리오 수준에서 파악 가능
• 확장이 간편함 — 새로운 시나리오 추가 시 SCENE_CONFIG 설정만 필요

⚠️ 단점

• 다중 시나리오 작업의 자동 분해 불가
• 시나리오 경계를 정밀하게 정의하기 어려움
• 라우팅 실패 시 비용이 높음 — 분류가 틀리면 전체가 틀림
• 설정의 복잡성 — 6개의 시나리오를 위해 6세트의 설정과 SOP를 유지 관리해야 함

6. 지금의 당신에게

지금의 당신은 더 이상 「Agent에게 수많은 도구를 주고 만능으로 활약하기를 기대하는」 낙관주의자가 아닙니다. 당신은 시나리오 격리를 통해 Agent의 행동 경계를 제어할 수 있는 시스템 설계자로 거듭나고 있습니다.

마치 회사가 영업부, 기술부, 재무부가 필요하듯, Agent 시스템 역시 「부서」의 구분이 필요합니다. 시나리오 라우팅은 각 Agent 시나리오가 한 가지 일을 제대로 수행하도록 만듭니다. 이는 「만능」이라는 환상을 희생하는 대신, 「신뢰할 수 있는」 현실을 얻는 과정입니다.

다음 편: 라우팅 계층에서 어떻게 누락되는 작업 없이 처리할 수 있을까? 정규표현식(Regex)과 의미론적(Semantic) 이중 분류를 통해 분류 정확도를 80%에서 100%로 끌어올리는 방법.

🏷️ 엔티티: 시나리오 라우팅, Agent, 도구 화이트리스트, SCENE_CONFIG
💼 가치: Agent 상용화, 도구 격리, 최소 권한
🧠 인지: 만능의 환상에서 시나리오 전문가로 — 전문화가 만능보다 더 신뢰할 수 있다