고충 (The Pain): 장면 라우팅 (Scene routing)은 단일 장면 작업의 90%를 해결했습니다. 하지만 나머지 10%인 복합적인 작업들은 어떻게 해야 할까요? 단일 상태 보고서에는 문의(inquiries), 견적(quotations), 리마인더(reminders), DN(Delivery Notes) 및 POD(Proof of Delivery)가 포함되어 있습니다. 단일 장면으로는 이를 모두 담을 수 없습니다.
학습 내용:

• 왜 보고서는 **장면(Scene)이 아니라 파이프라인 컨테이너 (Pipeline container)**인가 — 보고서는 스스로 장면이 되는 대신 장면들을 오케스트레이션 (Orchestrate)합니다.
• 5단계 파이프라인: 집계 (Aggregate) → 분해 (Decompose) → 배정 (Dispatch) → 실행 (Execute) → 보고 (Report)
• 왜 "제한 없는 도구 (unrestricted tools)"는 장면 라우팅의 위반이 아니라 컨테이너의 특수한 사례인가
• 왜 스크립트 (Scripts)가 힘든 작업을 수행하고 LLM은 최종 조립만 수행하는가
• 우리 시스템에서 보고서 안정성이 약 60%에서 약 95%로 향상된 방법

1. 문제점: 보고서는 "작은 작업들"로 가득 차 있습니다

장면 라우팅 (Scene-routing) 시스템이 가동된 후, 단일 장면 작업의 품질은 극적으로 향상되었습니다. 보고서 생성은 예외였습니다.

운송 중 보고서 (In-transit report)는 단순한 하나의 출력 작업처럼 보이지만, 실제로는 다음과 같은 하위 작업들로 가득 차 있습니다:

• 받은 편지함 (INBOX)의 모든 이메일 읽기 (이메일 장면의 기능)
• 모든 화물의 현재 상태 조회 (조회 장면의 기능)
• 미수금 및 미지급금 대조 (재무 장면의 기능)
• 모든 상태 라인에 대한 판단 제공 (결정 장면의 기능)

더 심각한 문제는 보고서 내부의 모든 이메일이 각각 자체적인 판단을 필요로 한다는 점입니다. 이 화물을 종결해야 할까요? 새로운 DN이나 POD가 도착했나요? 에이전트에게 재촉해야 할까요? 이러한 판단들은 여러 장면을 하나로 엮어냅니다.

우리의 첫 번째 시도는 보고서를 "보고서 장면 (Report scene)"으로 취급했습니다. 즉, 모든 도구를 넘겨주고 LLM이 즉흥적으로 처리하게 했습니다. 결과는 짐작하실 수 있을 것입니다. LLM은 도구 도메인 사이를 방황했고, 출력은 불안정했으며, 때로는 중요한 이메일을 놓치고 때로는 중복된 리마인더를 보냈습니다.

💡 핵심 통찰: 보고서는 장면이 아니라 파이프라인 컨테이너 (Pipeline container)입니다. 보고서는 스스로 장면이 되는 대신, 여러 장면의 실행을 오케스트레이션 (Orchestrate)합니다.

▲ 보고서는 장면(Scene)이 아니라 파이프라인 컨테이너(Pipeline container)입니다: 5단계의 과정, 사전에 정의된 결정론적 스크립트(Deterministic scripts), 그리고 마지막에 조립되는 LLM.

2. 핵심 아이디어: 5단계 파이프라인

보고서 생성을 다음의 5단계로 재정의합니다:

aggregate (집계) → decompose (분해) → dispatch (배정) → execute (실행) → report (보고)

1단계 — Aggregate (집계). 보고 기간 내의 _모든 것_을 읽습니다: 모든 이메일, 데이터 업데이트, 이벤트 로그를 포함합니다. 이 단계에서는 분류, 판단, 필터링을 수행하지 않습니다. 오직 수집만 합니다.

2단계 — Decompose (분해). 집계된 자료를 이메일별, 선적(Shipment)별, 주제별로 독립적인 작업 단위(Work units)로 나눕니다. 각 작업 단위는 원시 데이터(Raw data), 판단을 기다리는 항목들, 그리고 관련 선적 번호를 포함합니다.

3단계 — Dispatch (배정). 각 작업 단위를 해당 작업을 소유한 장면 핸들러(Scene handler)로 라우팅(Route)합니다. 이메일은 이메일 장면으로, 재무는 재무 장면으로, 수금(Collections)은 수금 장면으로 전달됩니다. 모든 하위 작업(Sub-task)은 각자의 독립적인 컨텍스트(Context)에서 실행됩니다.

4단계 — Execute (실행). 각 하위 작업은 독립적으로 실행되어 구조화된 하위 결과(Sub-result)를 반환합니다. 이메일 장면은 "분류됨 + 판단됨"을 출력하고, 재무 장면은 "미수금/미지급금 요약"을 출력하며, 수금 장면은 "리마인더 제안"을 출력합니다.

5단계 — Report (보고). 모든 하위 결과물을 통일된 형식의 하나의 완전한 보고서로 조립합니다.

▲ 5단계 컨테이너: 1~4단계는 결정론적 스크립트(Deterministic scripts)이며, 5단계는 LLM입니다 — 각 단계는 명확한 입력(Input), 출력(Output), 그리고 검증(Validation) 과정을 가집니다.

3. 기술적 구현

3.1 컨테이너의 특수 사례: 제한 없는 도구 (Unrestricted Tools)

보고서 파이프라인(report pipeline)의 경우, 장면 라우팅(scene routing)에 한 가지 예외가 있습니다: 도구 제한 없음 (no tool restriction).

이는 장면 라우팅을 위반하는 것이 아니라, "파이프라인 컨테이너 (pipeline container)" 개념이 실제로 작동하는 모습입니다. 보고서 파이프라인은 이메일 접근 권한 (email scene tools), 데이터베이스 쿼리 (query scene tools), 그리고 표 생성 (report scene tools) 기능이 모두 필요합니다. 이 중 어느 한 카테고리라도 제한한다면 불완전한 보고서가 생성될 것입니다.

하지만 "제한 없는 도구 (unrestricted tools)"가 "규칙 없음"을 의미하는 것은 아닙니다. 보고서 파이프라인은 여전히 모든 철칙을 준수하며, 게이트 시스템 (gate system)은 여전히 임계 노드(critical nodes)에서 행동 준수 여부를 확인합니다.

3.2 파이프라인 코드 (The Pipeline Code)

def generate_report(period):
    # stage 1 — aggregate: 해당 기간의 모든 데이터를 읽음
    all_mails = fetch_inbox(period)
...

3.3 핵심: 스크립트가 힘든 일을 처리하고, LLM은 조립만 수행한다

왜 처음 4단계에서는 LLM 대신 스크립트 (scripts)를 사용할까요?

그 이유는 힘든 일(dirty work) — 이메일 스캔, 데이터 정제, 통계 실행 — 은 LLM에 적합하지 않기 때문입니다. LLM은 느리고, 비용이 많이 들며, 불안정합니다. 스크립트는 힘든 일을 빠르고 정확하게 수행하며, LLM은 일관된 스타일로 최종 조립 (final assembly)을 수행합니다. 각자 가장 잘하는 일을 하는 것입니다.

# stage 4 — execute: 순수 스크립트 (no_agent)
def process_scene(scene, units):
    if scene == "email":
...

▲ 구성(Composition) 및 분기(fork): 작업 단위(work units)가 이메일, 재무, 수집 장면(scenes)으로 각각의 컨텍스트 내에서 퍼져 나간 뒤, 하나의 보고서로 수렴합니다.

✅ 검증됨 (Verified): 재작업 이후 보고서 안정성이 약 60%에서 약 95%로 상승했습니다. 데이터 소스는 추적 가능하며, 판단 근거는 명시적이고, 출력 형식은 균일합니다.

🩸 함정 (Pitfall): 초기 버전에서는 LLM이 보고서 전체를 "자유롭게 즉흥적으로 작성 (freely improvise)"하도록 두었습니다. 때로는 상세하게, 때로는 단 세 줄로 작성되기도 했습니다. 전환점은 _스케줄링된 작업 (scheduled task)에서 거대 모델이 즉흥적으로 행동하게 두는 것은 본질적으로 불안정하다_는 피드백을 수용하고, 5단계 파이프라인 (pipeline)으로 전환한 것이었습니다.

💼 가치 (Value): 이제 모든 단계는 명확한 입력 (input), 출력 (output), 그리고 검증 기준 (validation criteria)을 가집니다. LLM의 역할은 "보고서 작성자"에서 "SOP 실행자"로 전환되었습니다.

▸ 인지적 도약 (Cognitive leap): 원자적 장면 (atomic scenes)은 품질을 보장하며, 복합 흐름 (composite flows)은 업무를 완수합니다. 장면 (scene)은 원자적 (atomic)이고, 흐름 (flow)은 복합적 (composite)입니다. 이는 서로 다른 입도 (granularity)를 가진 두 가지 추상화 수준입니다.

4. 장단점 (Pros and Cons)

✅ 장점 (Pros)

• 안정적인 보고서 — 5단계 SOP가 매번 동일한 흐름을 보장합니다.
• 모든 이메일 분류 및 처리 — 해당 기간 내의 어떤 것도 누락되지 않습니다.
• 초안의 단일 저장소 관리 — 보고서 초안을 추적하고 검토할 수 있습니다.
• 모든 결론에 데이터 소스 인용 — 판단에 근거가 있습니다.
• 하위 작업 간 격리 (Cross sub-task isolation) — 하나의 하위 작업 오류가 다른 작업에 영향을 주지 않습니다.

⚠️ 단점 (Cons)

• 상세한 SOP에 의존 — SOP가 부실하면 LLM이 즉흥적으로 행동합니다.
• 다중 장면 자동 분해 (Multi-scene auto-decomposition)에 여전히 오케스트레이션 프레임워크 (orchestration framework)가 필요 — 현재 흐름은 수동으로 연결 (hand-wired)되어 있습니다.
• 컨테이너로 인한 지연 시간 (latency) 발생 — 5단계 방식은 단일 장면보다 약 30% 더 많은 시간이 소요됩니다.
• 복합 작업의 경계가 모호함 — 일부 작업은 단일 장면과 복합 작업 사이에 걸쳐 있습니다.

5. 현재 당신의 모습 (The You Right Now)

당신은 더 이상 보고서를 하나의 장면으로 취급하며, 에이전트에게 모든 도구를 건네주고 즉흥적으로 행동하게 두던 낙관주의자가 아닙니다. 당신은 흐름 컨테이너 (flow containers)로 복잡한 작업을 오케스트레이션하는 시스템 설계자가 되어가고 있습니다.

보고서는 장면이 아닙니다. 그것은 파이프라인 컨테이너 (pipeline container)입니다. 장면은 원자적이며 단일 책임 작업 (single-responsibility tasks)을 처리합니다. 흐름은 복합적이며, 복잡한 목표를 향해 여러 원자적 장면을 오케스트레이션합니다.

다음 단계: 시스템이 실행됩니다 — 하지만 그것이 신뢰할 수 있는지 어떻게 알 수 있을까요? 관측성(Observability)의 삼중주 — 게이트(gate) + 감사(audit) + 교정 침전(correction sedimentation) — 상용 에이전트가 지속적으로 개선될 수 있게 하는 피드백 루프(feedback loop).

저자 소개: Wu Ji (无记) — 에이전트 엔지니어링(Agent engineering), 루프 엔지니어링(Loop Engineering), 디지털 전환(digital transformation)에 집중하는 AI 및 디지털화 실무자. 실용적이고 직접 따라 할 수 있는 튜토리얼 — 따라 하기만 하면 바로 작동합니다.