오케스트레이션

도구가 준비되어 있어도 언제, 어떤 순서로, 어떤 맥락에서 호출할지 결정하는 게 오케스트레이션이고, 이게 에이전트의 실질적인 지능을 결정해. 단순한 태스크는 도구 하나에 컨텍스트 좀만 넣으면 되지만, 현실의 복잡한 워크플로는 계획 수립, 메모리 회수, 동적 컨텍스트 조립까지 필요하거든.

에이전트를 추론 깊이 기준으로 여섯 가지로 분류할 수 있어. 가장 단순한 건 반사형 에이전트(Reflex Agent) — "if 이 조건이면 → 이 도구 호출" 수준의 조건-행동 매핑이야. 추론 과정 없이 입력을 받으면 미리 정해진 규칙에 따라 바로 행동하지. 빠르고, 예측 가능하고, 구현이 쉽지만, 규칙에 없는 상황이 오면 손을 놓아. "에이전트"라기보다는 자동화 스크립트에 가까워.

**리액트 에이전트(ReAct Agent)**는 2022년 Yao et al.이 제안한 Reasoning + Acting 프레임워크야. 에이전트 아키텍처의 사실상 표준이 됐지. 핵심은 Think → Act → Observe 루프인데 — 생각(Thought): 현재 상황을 추론하고, 행동(Action): 도구를 호출하고, 관찰(Observation): 도구 응답을 받아서 다시 생각 단계로 돌아가. 이 루프를 답이 나올 때까지 반복해. 반사형과의 차이는 매 단계마다 다음에 뭘 할지 추론한다는 거야. 도구 응답을 보고 계획을 수정할 수 있어서 유연하지. 다만 한 단계씩 순차적으로만 생각하다 보니, 큰 그림을 못 보고 비효율적인 경로로 빠지는 경우가 생겨. "숲을 보지 못하고 나무만 보는" 문제야.

**계획 후 실행 에이전트(Plan-and-Execute Agent)**는 ReAct의 이 문제를 해결하려는 접근이야. 먼저 전체 계획을 세우고, 그 다음에 실행하는 구조지. 계획(Planning) 단계에서 강한 모델(예: Opus 급)이 태스크를 하위 단계로 분해한 실행 계획을 세우고, 실행(Execution) 단계에서 가벼운 모델이나 전문화된 에이전트가 각 단계를 순차적으로 실행해. 계획과 실행을 분리하면 각각에 다른 LLM을 쓸 수 있어. 계획에는 비싸지만 똑똑한 모델, 실행에는 빠르고 저렴한 모델 — 이게 비용 최적화에서 큰 차이를 만들지. 단점은 초기 계획이 틀리면 전체가 꼬인다는 거야. 그래서 실무에서는 실행 중간에 계획을 수정하는 **적응형 계획(Adaptive Planning)**을 함께 써.

**쿼리 분해 에이전트(Query Decomposition Agent)**는 복잡한 질문을 여러 개의 단순한 하위 질문으로 쪼개. "2024년 한국과 일본의 GDP 성장률 비교해줘"가 들어오면 각각의 성장률을 따로 찾고, 두 결과를 비교해서 종합하는 식이야. Plan-and-Execute와 비슷해 보이지만 초점이 달라 — Plan-and-Execute는 행동 단계를 분해하고, Query Decomposition은 질문 자체를 분해하거든. 주로 RAG 시스템에서 검색 정확도를 높이는 데 많이 쓰이고, 하위 질문 간의 의존성 파악이 핵심이야.

**성찰형 에이전트(Reflection Agent)**는 ReAct에 자기 비평 레이어를 추가한 거야. 초기 응답을 생성하고, 비평 모드로 전환해서 자기 출력을 평가해 — 정확한가? 빠진 건 없나? 제약 조건을 지켰나? 문제가 발견되면 수정해서 다시 생성하지. 사람이 글 쓰고 → 퇴고하고 → 다시 고치는 과정과 같아. 외부 피드백 없이도 자체적으로 품질을 개선할 수 있다는 게 핵심 이점이지만, 같은 문제를 여러 번 돌리니까 비용과 지연 시간이 늘어나.

가장 복잡한 유형은 **심층 리서치 에이전트(Deep Research Agent)**야. OpenAI Deep Research, Gemini Deep Research, Claude의 리서치 기능 같은 것들이 여기 속하지. 오케스트레이터-워커 패턴으로 리드 에이전트가 전략을 수립하고 전문화된 서브 에이전트들이 병렬로 탐색하고, 반복적 심화로 검색 결과를 읽고 후속 질문을 만들어서 더 깊이 파고들고, 종합 레이어에서 수집된 모든 정보를 구조화된 보고서로 통합해. 계획 수립, 쿼리 분해, 성찰을 전부 결합한 복합 에이전트인 셈이야.

에이전트가 도구를 3-5개만 가지고 있으면 그냥 전부 프롬프트에 넣으면 돼. 문제는 도구가 수십, 수백 개가 될 때야. 표준 도구 선택은 사용 가능한 모든 도구를 시스템 프롬프트에 넣고 모델이 알아서 고르게 하는 건데, 도구 수가 늘어나면 컨텍스트 낭비와 선택 혼란 문제가 생기거든.

시맨틱 도구 선택은 사용자 쿼리의 의미를 기반으로 관련 도구만 필터링해서 모델에 제공하는 방식이야. 도구 설명을 임베딩 벡터로 만들어두고, 쿼리가 들어오면 코사인 유사도로 가장 관련 높은 도구 k개만 뽑아서 프롬프트에 넣는 거지. 다른 말로 하면 도구를 위한 RAG야. 도구 수에 상관없이 컨텍스트를 효율적으로 쓸 수 있지만, 임베딩 유사도가 항상 정확하지는 않아.

계층적 도구 선택은 도구를 카테고리 트리로 조직하는 방식이야. 상위 라우터가 카테고리를 선택하고, 하위 라우터가 구체적인 도구를 선택하지. 대규모 에이전트 시스템에서 확장성이 좋고, MCP 같은 표준이 이 계층적 접근을 지원하는 방향으로 발전하고 있어 — 각 MCP 서버가 하나의 도구 카테고리 역할을 하는 셈이지.

도구를 선택했으면 실행해야 하는데, 단순히 함수 호출하고 끝이 아니야. 파라미터 생성 — 모델이 도구의 파라미터를 올바르게 생성해야 하고, API 스키마가 복잡할수록 실수 확률이 높아. 실행 결과 처리 — 도구 응답이 너무 길면 잘라야 하고, 에러가 나면 재시도하거나 대체 도구를 써야 하지. 확인-실행 패턴 — 위험한 도구(데이터 삭제, 결제 등)는 실행 전에 사용자 확인을 받는 게 좋아. 타임아웃과 재시도 — 외부 API는 느리거나 실패할 수 있으니까 지수 백오프로 재시도하는 건 기본이야. 샌드박싱 — 코드 실행 도구 같은 건 Docker 컨테이너나 WebAssembly 같은 격리된 환경에서 돌려야 해.

에이전트가 여러 도구를 조합해야 할 때, 그 조합의 **구조(topology)**가 성능과 효율성을 결정해. 단일(Single) — 하나의 도구를 한 번 호출하고 끝. 병렬(Parallel) — 독립적인 여러 도구를 동시에 호출해서 시간을 절약하지. 핵심 조건은 호출들 사이에 의존성이 없어야 한다는 거야. 최신 모델들은 한 번의 응답에서 여러 개의 tool call을 동시에 반환하는 병렬 도구 호출을 네이티브로 지원하거든.

**체인(Chain)**은 도구들을 순차적으로 연결해서, 앞 도구의 출력이 뒤 도구의 입력이 되는 구조야. 파이프라인이라고도 부르지. "내 최근 이메일을 요약해서 슬랙에 보내줘" 같은 거야 — email_fetch() → summarize() → slack_send(). 체인에서는 에러 전파가 중요한 이슈야. 중간 단계가 실패하면 뒤의 모든 단계가 블록되거든.

**그래프(Graph)**는 가장 유연하고 복잡한 토폴로지야. 도구 간의 의존 관계를 DAG(방향 비순환 그래프)로 모델링해서, 어떤 도구는 병렬로 돌리고 어떤 도구는 순차적으로 돌리는 걸 하나의 구조 안에서 표현할 수 있어. LangGraph가 이 패턴을 프레임워크 레벨에서 지원하지. 현실의 복잡한 작업은 대부분 이 그래프 토폴로지가 필요해 — 순수한 체인도 아니고 순수한 병렬도 아닌, 둘이 뒤섞인 구조거든. 다만 복잡도가 올라가는 만큼 디버깅 난이도도 올라가.

프롬프트 엔지니어링이 하나의 프롬프트를 잘 쓰는 기술이었다면, 컨텍스트 엔지니어링은 에이전트가 매 순간 필요로 하는 전체 정보 환경을 설계하는 기술이야. 2025년 중반부터 업계에서 본격적으로 쓰이기 시작한 용어지. 에이전트는 한 번의 프롬프트가 아니라 여러 단계에 걸쳐 동작하고, 각 단계마다 모델에 전달되는 컨텍스트가 다르고, 이 컨텍스트의 품질이 곧 에이전트의 판단 품질을 결정하거든.

핵심 요소들을 보면 — 시스템 프롬프트 설계는 에이전트의 역할, 제약 조건, 행동 가이드라인을 정의하는 거고, 동적 컨텍스트 조립은 매 호출마다 관련 메모리, 도구 응답, 사용자 히스토리에서 필요한 정보만 선별해서 넣는 거야. 전부 넣으면 컨텍스트 윈도가 터지고, 너무 적으면 모델이 맥락을 못 잡아. 메모리 통합은 단기 메모리(현재 대화), 장기 메모리(과거 상호작용에서 학습한 선호도), 작업 메모리(현재 태스크의 중간 결과)를 적절히 조합하는 거지. 컨텍스트 압축은 긴 대화나 많은 도구 응답이 쌓이면 요약하거나 덜 중요한 부분을 잘라내는 건데, 단순 잘라내기보다는 의미 기반 요약이 효과적이야. 도구 응답 포맷팅은 도구가 반환하는 원시 데이터를 모델이 이해하기 쉬운 형태로 가공하는 건데, JSON을 그대로 넘기는 것보다 자연어 설명을 추가하는 게 모델 추론 정확도를 높여.

결국 메모리 관리, 출력 라우팅, 각 의사결정 단계의 입력 구조화가 전부 컨텍스트 엔지니어링이라는 큰 우산 아래에 있어.

---

정리

5장 읽고 기억할 거 세 가지:

1. 에이전트 유형은 추론 깊이의 스펙트럼이야. 반사형(규칙) → ReAct(단계별 추론) → 계획 후 실행(전체 계획) → 성찰형(자기 비평) → 심층 리서치(복합). 복잡할수록 좋은 게 아니라, 태스크에 맞는 유형을 골라야 하거든
2. 도구가 많아지면 선택 전략이 아키텍처 결정이 돼. 표준 → 시맨틱 → 계층적으로 갈수록 확장성은 좋아지지만 시스템 복잡도도 올라가지
3. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로. 에이전트 시대에는 하나의 프롬프트가 아니라, 매 단계의 전체 정보 환경을 설계하는 능력이 핵심이야