컨텍스트 라우팅

요청하신 ‘컨텍스트 라우팅’ (유형: workflow)에 관한 고품질의 한국어 위키 노트를 성공적으로 작성하여 llm-wiki/wiki/컨텍스트 라우팅.md에 저장했습니다.

---

📄 생성된 위키 노트 미리보기

---
type: workflow
status: draft
core: false
tags:
  - llm
  - agent
aliases:
  - Context Routing
sources:
  - 'raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md'
created: '2026-08-27'
updated: '2026-08-27'
---
 
# 컨텍스트 라우팅
 
## 한 줄 정의
컨텍스트 라우팅(Context Routing)은 멀티 에이전트 시스템 또는 복합 오케스트레이션 파이프라인에서, 중앙 오케스트레이터나 상태 관리 코드가 각 전문 서브 에이전트(Specialist Agent)의 역할에 꼭 필요한 최적의 맥락 서브셋(State Subset)만을 동적으로 필터링하여 분배·전달하는 구조적 맥락 제어 기법이다.
 
## 핵심 요지
- **최소 권한 맥락 전달(Least-Privilege Context Handoff)**: 파이프라인 내 모든 에이전트에게 전체 대화 이력과 원시 데이터를 무차별 전송하는 대신, 특정 노드의 역할 완수에 필요한 맥락 정보만 분배함으로써 [[컨텍스트 세금]] 발생과 관심사(Attention) 분산을 막는다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
- **Attention 분산 및 비선형 성능 저하 방지**: 2025년 7월 Chroma의 연구에 따르면 Claude 4, GPT-4.1, Gemini 2.5 등 18개 주요 LLM 테스트 결과, 단순 검색(Retrieval) 과제조차 컨텍스트 길이가 길어질수록 성능이 비선형적으로 파괴되는 것으로 확인되었다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`). 컨텍스트 라우팅은 불필요한 노이즈를 제거하여 하류 에이전트의 환각(Hallucination)을 대폭 줄인다.
- **상태의 계약(Contract) 및 선별 필터링**: `AgentState` 내의 지속적(Persistent), 시의적(Time-sensitive), 일시적(Transient) 맥락을 구분하고, 오케스트레이터 노드가 하류 노드별 수신 계약에 맞추어 시의적 맥락만 정제해 넘겨주는 방식을 채택한다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
 
## 상세
 
### 필요성과 배경
대부분의 멀티 에이전트 프로젝트는 초기 단계에서 단일 서브 에이전트의 System Prompt 조율에 집중하지만, 시스템이 확장되어 3개 이상의 에이전트가 연동되는 순간 무너진다. 이는 개별 LLM의 추론 능력 부족이 아니라, 이전 에이전트가 어떤 맥락에서 결정을 내렸는지 전달받지 못하거나(맥락 결손), 반대로 무관한 원시 데이터가 과다 전달되어 하류 에이전트가 존재하지 않는 사실을 상상해 내는 **[[컨텍스트 핸드오프]] 오류**에 기인한다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
 
Andrej Karpathy는 "Context engineering이란 다음 단계를 위해 정확히 필요한 정보만으로 context window를 채우는 정교한 기술이자 과학"이라고 규정했다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`). 모든 에이전트에 전체 맥락을 무차별 공유하는 것은 회사 전체 직원을 모든 회의에 참석시키는 것과 같아서, 겉보기엔 완전해 보여도 시스템 운영적으로는 비효율과 환각을 유발한다.
 
### 계층적 컨텍스트 라우팅 메커니즘
컨텍스트 라우팅은 상태 객체(State Object)의 3개 계층별로 다르게 작용한다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
 
1. **지속적 컨텍스트 (Persistent Context)**: 사용자 최상위 목표, 세션 ID, 도메인 규제 및 임계값 등. 파이프라인 전체 에이전트에게 공통 보존되어 항상 전달된다.
2. **시의적 컨텍스트 (Time-sensitive Context)**: RAG 검색 문서 요약, 최신 API 응답, 현재 단계의 검색 결과. 라우팅 로직을 통해 **해당 정보가 필요한 에이전트에게만 선별적 전달**된다.
3. **일시적 컨텍스트 (Transient Context)**: 원시 JSON 페이로드, 무거운 intermediate reasoning 로그, 이전 도구 호출의 상세 트레이스. 다음 노드로 라우팅되는 시점에서 **적극적으로 덤프/제거**되어 Context Window 오염을 방지한다.
 
### 산업 현황 및 지표
- **생태계 변화**: 2026년 조사 결과 IT 및 데이터 리더의 82%가 단순 프롬프트 엔지니어링만으로는 프로덕션 AI 구축에 불충분하다고 보았으며, 95%의 데이터 팀이 Context Engineering 역량 확보에 투자하고 있다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
- **풀링(Pulling)형 라우팅과 MCP**: 모든 문맥을 밀어 넣는(Push) 대신, 표준 프로토콜인 [[모델 컨텍스트 프로토콜]](MCP)을 통해 필요 시점에 동적으로 필요한 맥락 소스를 라우팅/조회하는 아키텍처가 확산되고 있다. 2025년 말 기준 1만 개 이상의 공개 MCP 서버가 배포되었다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
 
## 예시
 
### LangGraph 기반 컨텍스트 라우팅 코드 구조
LangGraph 오케스트레이터가 전체 `ResearchAgentState` 중 하류 서브 에이전트 노드가 필요로 하는 서브셋만 선별하여 인스턴스화 및 라우팅하는 패턴이다 (`raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md`).
 
```python
from typing import TypedDict, Optional, List
from langgraph.graph import StateGraph
 
# 파이프라인 전체 맥락 계약 정의
class ResearchAgentState(TypedDict):
    # Persistent context (모든 노드 공유)
    user_goal: str
    domain_constraints: List[str]
    session_id: str
 
    # Time-sensitive context (선별 라우팅 대상)
    retrieved_docs: List[str]
    current_findings: str
    last_tool_result: Optional[str]
 
    # Transient context (라우팅 시 필터링/삭제 대상)
    raw_api_payload: Optional[str]
    intermediate_reasoning: Optional[str]
 
# 컨텍스트 라우터 / 오케스트레이터 노드 로직
def route_context_to_specialist(state: ResearchAgentState) -> dict:
    """
    데이터 수집 노드의 원시 API 페이로드(raw_api_payload)와 무거운 추론 과정은 필터링하고,
    코드 작성 및 요약 서브 에이전트에 필요한 핵심 요약과 지속적 맥락만 서브셋으로 라우팅함.
    """
    return {
        "user_goal": state["user_goal"],
        "domain_constraints": state["domain_constraints"],
        "current_findings": state["current_findings"],
        # transient 정보인 raw_api_payload, intermediate_reasoning은 라우팅 대상에서 제외하여 제거
    }

프로덕션 실전 적용 시나리오

1. 의학 파이프라인 내 서브 에이전트 분리: 의료 정보 수집 에이전트가 다량의 의학 문헌 API 데이터(raw_api_payload)를 가져왔을 때, 코드 작성 에이전트나 환자 요약 에이전트에 전량 전달하지 않고 요약된 current_findings만 라우팅한다. 이를 통해 수만 토큰에 달하는 원시 의학 문헌 노이즈가 다른 에이전트의 환자 이력 환각을 유발하는 현상을 방지했다 (raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md).
2. NL-to-SQL 오케스트레이션: DB 스키마가 수시로 변하는 환경에서 이전 세션의 구 스키마 맥락이 전파되는 스키마 드레이프(Schema Drift) 오류를 막기 위해, SQL 생성 에이전트에 항상 최신 검증된 스키마 서브셋만 라우팅하도록 라우팅 경계(Routing Boundary)를 고정한다 (raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md).

충돌

전체 맥락 브로드캐스팅 vs 역할 기반 최소 권한 라우팅

• 전체 맥락 브로드캐스팅(Full Context Broadcasting): 에이전트가 임의의 상황에 유연하게 대응하기 위해 이전 단계의 모든 실행 로그, 도구 출력을 복사하여 전달하는 방식. 초기 멀티 에이전트 시스템에서 흔히 사용되었으나, Context Window 압박과 노이즈 유입으로 상류 정보의 환각 및 사소한 힌트에 미치는 과도한 시선(Attention Hijacking) 문제를 유발한다 (raw/AI 에이전트에게 Prompt Engineering은 죽었다. 이제 진짜 중요한 것은 Context Engineering이다.md).
• 역할 기반 최소 권한 라우팅(Role-Based Least-Privilege Routing): 각 에이전트가 미리 선언한 계약(TypedDict 등) 기반으로 필터링된 맥락만 받는 방식. 토큰 비용 절감 및 환각 방지 면에서 압도적으로 우수하나, 오케스트레이터의 라우팅 분기 설계 공수가 증가하고 잘못 설계할 경우 하류 에이전트에 필요한 맥락이 누락되는(Under-context) 부작용이 발생할 수 있다.

관련 노트

• 컨텍스트 핸드오프
• 모델 컨텍스트 프로토콜
• 적시 컨텍스트 로딩
• 컨텍스트 세금
• 컨텍스트 윈도우 한계 극복 요령
• 로컬 LLM 롱 컨텍스트 추론 병목
• AI 환각 현상