AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링

컨텍스트는 AI 에이전트에게 매우 중요하지만 한정된 자원입니다. 이 글에서는 에이전트를 움직이게 만드는 컨텍스트를 효과적으로 선별·관리하는 전략을 살펴봅니다.

몇 년 동안 적용형 AI 분야에서 관심의 초점이 프롬프트 엔지니어링에 맞춰져 있었다면, 이제는 컨텍스트 엔지니어링(context engineering) 이라는 새로운 개념이 부상하고 있습니다.
언어 모델을 활용해 무언가를 만드는 일은 점점 “프롬프트에 어떤 단어와 문장을 넣을 것인가”를 넘어서,

“모델이 원하는 방식으로 행동하게 만들기 위해 어떤 컨텍스트 구성을 선택할 것인가?”

라는 더 넓은 질문으로 이동하고 있습니다.

여기서 말하는 컨텍스트란, 대규모 언어 모델(LLM)에서 샘플링할 때 함께 포함되는 토큰들의 집합을 뜻합니다.
현재 우리가 풀어야 할 엔지니어링 문제는, LLM이 가진 구조적 제약 안에서 이 토큰들의 효용을 최대화하도록 구성해, 원하는 결과를 안정적으로 얻는 것입니다.
LLM을 잘 다루려면 “컨텍스트 관점에서 생각하기”가 중요합니다. 다시 말해,

“지금 이 순간 LLM이 어떤 전체 상태(context state)를 보고 있는지,
그리고 그 상태가 어떤 행동을 유발할지”

를 함께 고려해야 합니다.

이 글에서는 새롭게 떠오르고 있는 컨텍스트 엔지니어링이라는 기술을 살펴보고,
조종 가능하고 효과적인 에이전트를 만들기 위한 정교한 사고 모델을 제안합니다.

쉬운 목차

컨텍스트 엔지니어링 vs 프롬프트 엔지니어링

Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 확장으로 보고 있습니다.

프롬프트 엔지니어링은, 최적의 결과를 얻기 위해
LLM에 넘기는 지시문(prompt)을 어떻게 작성·구성할지에 초점을 둔 방법론입니다.
(개요와 유용한 전략은 문서에서 다루고 있습니다.)
컨텍스트 엔지니어링은, 프롬프트뿐 아니라
추론 시점에 LLM에 들어가는 전체 토큰 집합(정보) 을
어떻게 선별·관리할지에 대한 전략을 의미합니다.
즉, 프롬프트 이외에 컨텍스트에 포함될 수 있는 모든 정보까지 포함합니다.

LLM 엔지니어링 초기에는 대부분의 활용 사례(일상적인 채팅을 제외하고)가
원샷 분류나 텍스트 생성처럼 비교적 단일 작업이었기 때문에,
프롬프트를 잘 만드는 일이 AI 엔지니어링의 대부분을 차지했습니다.
이 시기 프롬프트 엔지니어링의 핵심은
“효과적인 프롬프트, 특히 시스템 프롬프트를 어떻게 쓰느냐”였습니다.

하지만 이제는,
여러 차례의 추론과 긴 시간축에 걸쳐 동작하는 더 강력한 에이전트를 설계해야 합니다.
이 과정에서는 시스템 지침, 도구(tool), Model Context Protocol(MCP), 외부 데이터, 메시지 기록 등으로 이루어진 전체 컨텍스트 상태를 관리하는 전략이 필요합니다.

루프 안에서 동작하는 에이전트는 매 턴마다
다음 추론에 관련 있을 수 있는 새로운 정보를 계속 만들어 냅니다.
이 정보는 주기적으로 정제·선별되어야 합니다.

컨텍스트 엔지니어링이란,
이 끊임없이 변하는 정보의 우주 속에서,
제한된 컨텍스트 창(context window)에 어떤 정보를 넣을지를 결정하는
“선별의 기술이자 과학”입니다.

프롬프트 엔지니어링이 프롬프트 한 덩어리를 잘 쓰는 일이라면,
컨텍스트 엔지니어링은 매번 모델에 어떤 전체 맥락을 보낼지를 결정하는
반복적·동적인 작업입니다.

왜 컨텍스트 엔지니어링이 중요할까

LLM은 빠르게 동작하고 점점 더 큰 데이터도 다룰 수 있지만,
우리가 관찰한 바에 따르면 사람과 비슷하게 어느 정도에서 집중력을 잃거나 혼란을 겪습니다.

특히 “needle-in-a-haystack(건초더미 속 바늘 찾기)” 스타일의 벤치마크 연구를 통해
컨텍스트 로트(context rot) 라는 현상이 드러났습니다.
컨텍스트 창에 포함된 토큰 수가 많아질수록,
모델이 그 안에 있는 특정 정보를 정확히 찾아내는 능력이 떨어지는 현상입니다.

모델에 따라 성능 저하의 기울기는 다르지만,
이 현상은 모든 모델에서 공통으로 나타납니다.
따라서 컨텍스트는 한계가 있는 자원이며,
추가 토큰을 넣을수록 수익이 체감하는 구조로 이해해야 합니다.

사람에게 한정된 작업 기억(working memory) 용량이 있듯이,
LLM에도 주의(attention) 예산이 있습니다.
컨텍스트에 새로운 토큰을 하나 추가할 때마다
이 예산이 조금씩 줄어들고,
그만큼 “어떤 토큰을 보여줄지” 더 신중한 선별이 필요해집니다.

이런 주의력 부족은 LLM의 구조적(아키텍처) 제약에서 비롯됩니다.
LLM은 트랜스포머(transformer) 아키텍처를 기반으로 하는데,
이 구조에서는 한 토큰이 컨텍스트 전체의 모든 다른 토큰을 참조(attend) 할 수 있습니다.
즉, 토큰 수가 n이라면 n² 개의 쌍(pairwise) 관계가 생기는 구조입니다.

컨텍스트 길이가 늘어날수록,
모델이 이 모든 쌍 관계를 충분히 포착하기가 점점 더 어려워지고,
컨텍스트 크기와 주의 집중력 사이에 자연스러운 긴장이 생깁니다.

추가로, 모델은 학습 데이터 분포에 기반해 주의 패턴을 형성하는데,
일반적으로 짧은 시퀀스가 긴 시퀀스보다 훨씬 많이 등장합니다.
그 결과, 모델은 짧은 문맥에는 더 많은 경험과 파라미터를 가지고 있지만,
컨텍스트 전체에 걸친 긴 의존 관계에는 상대적으로 약할 수 있습니다.

포지션 인코딩 보간(position encoding interpolation) 같은 기법은
원래보다 긴 시퀀스를 처리할 수 있도록 돕지만,
그 과정에서 토큰 위치에 대한 이해가 일부 손상될 수 있습니다.

이런 요인들이 합쳐져,
성능이 갑자기 떨어지는 “절벽”이라기보다
긴 컨텍스트로 갈수록 정보 검색·장거리 추론 능력이
서서히 낮아지는 성능 경사(gradient) 를 만들어 냅니다.

이 모든 이유 때문에,
컨텍스트 엔지니어링은 강력한 에이전트를 만드는 데 필수적인 요소가 됩니다.

효과적인 컨텍스트의 구성 요소

LLM의 주의 예산이 한정되어 있다는 전제를 바탕으로,
좋은 컨텍스트 엔지니어링의 목표는 다음과 같습니다.

“원하는 결과를 낼 가능성을 최대화하는,
가장 작고 고신호(high-signal)인 토큰 집합을 찾는 것”

이를 실제로 구현하는 일은 말처럼 쉽지 않지만,
아래에서는 이 원칙이 컨텍스트의 다양한 구성 요소에
어떻게 적용되는지 구체적으로 살펴봅니다.

시스템 프롬프트(System prompt)

시스템 프롬프트는 매우 명확하고 단순한 언어로 작성되어야 하며,
에이전트를 위해 “적절한 높이(altitude)”에서 개념을 제시해야 합니다.

여기서 말하는 적절한 높이란,
두 가지 흔한 실패 모드의 가운데에 있는 골디락스 존(Goldilocks zone) 입니다.

한쪽 극단:
복잡한 if-else 로직을 프롬프트 안에 하드코딩해
아주 구체적인 행동을 강요하는 방식
→ 프롬프트가 깨지기 쉽고, 시간이 지날수록 유지보수 비용이 크게 증가합니다.
다른 극단:
너무 추상적이고 포괄적인 지시만 주거나,
모델이 사용자와 같은 배경 지식을 공유한다고 가정하는 방식
→ 모델이 어떤 행동을 해야 하는지 명확한 신호를 받지 못합니다.

이 두 극단 사이에서 균형을 맞추는 것이 중요합니다.
즉,

행동을 충분히 잘 안내할 만큼 구체적이면서도,
모델이 스스로 유연하게 판단할 수 있을 정도로 여지를 남겨 주는 것입니다.

프롬프트는 <background_information>, <instructions>,
## Tool guidance, ## Output description 같은 섹션으로 나누고,
XML 태그나 마크다운 헤더로 영역을 구분하는 방식을 추천합니다.
다만 모델이 점점 더 강력해질수록,
이런 형식상의 구조는 점차 덜 중요해지는 방향으로 가고 있습니다.

어떤 구조를 택하든 간에,
시스템 프롬프트는 기대하는 행동을 완전히 설명하는 최소한의 정보를 담는 것이 목표입니다.
여기서 최소한이란 짧다는 의미가 아니라,
중복 없이 핵심적인 정보만 담으라는 뜻입니다.
에이전트가 원하는 행동을 꾸준히 따르려면
어느 정도 충분한 정보량이 필요합니다.

실무적으로는,
먼저 가장 좋은 모델에 대해 정말 최소한의 프롬프트로 시작해
작업 수행 능력을 확인하고,
초기 테스트에서 드러난 실패 사례를 바탕으로
명확한 지시와 예시를 단계적으로 추가해 나가는 방식을 추천합니다.

도구(Tools)

도구는 에이전트가 환경에 작용하고, 새로운 컨텍스트를 가져오는 수단입니다.
도구는 에이전트와 정보/행동 공간 사이의 계약을 정의하기 때문에,
다음 두 가지 측면에서 효율성을 보장해야 합니다.

토큰 효율적인 정보 반환
에이전트가 효율적인 행동 패턴을 취하도록 유도

“Writing tools for AI agents – with AI agents” 글에서,
우리는 LLM이 잘 이해할 수 있고 기능 중복이 적은 도구 설계 원칙을 다뤘습니다.
좋은 코드베이스의 함수와 마찬가지로, 도구는 다음을 만족해야 합니다.

자기 완결적(self-contained)일 것
오류에 강할 것
의도된 사용 목적이 매우 명확할 것

입력 파라미터 역시 설명적이고 모호함이 없어야 하며,
모델이 잘 다룰 수 있는 형태여야 합니다.

우리가 자주 보는 실패 사례 중 하나는,
너무 많은 기능을 담거나
어떤 상황에서 어떤 도구를 써야 할지 애매한 비대한 도구 세트입니다.
사람 엔지니어조차 “이 상황에서 어느 도구를 써야 하는지”
명확히 답하지 못한다면,
AI 에이전트에게 더 나은 판단을 기대하기는 어렵습니다.

또한 후반부에서 다시 다루겠지만,
에이전트에게 최소 기능 도구 세트(minimal viable set of tools) 를 제공하는 것은
긴 상호작용 동안의 컨텍스트 유지·정리에도 큰 도움이 됩니다.

예시(Examples)

예시 제공, 즉 퓨샷(few-shot) 프롬프트는 이미 잘 알려진 베스트 프랙티스이며,
우리는 여전히 이를 강하게 추천합니다.

다만, 팀에서 흔히 저지르는 실수는
에이전트가 따라야 할 모든 규칙과 엣지 케이스를 예시로 가득 채우는 것입니다.
우리는 이런 방식은 권장하지 않습니다.

대신,
에이전트가 보여야 할 기대 행동을 잘 드러내는
다양하고 대표적인(canonical) 예시 세트를 큐레이션하는 편이 더 좋습니다.

LLM 입장에서 예시는 그야말로

“말로 된 설명 수천 줄보다 값어치 있는 그림”

역할을 합니다.

시스템 프롬프트, 도구, 예시, 메시지 기록 등
컨텍스트의 각 요소에 대한 우리의 전반적인 조언은 단순합니다.

정보량은 충분히, 그러나 컨텍스트는 촘촘하고 타이트하게 유지하라.

이제 런타임에서 컨텍스트를 동적으로 가져오는 전략으로 넘어가겠습니다.

컨텍스트 검색과 에이전트 기반 검색(Agentic search)

“Building effective AI agents” 글에서는
LLM 기반 워크플로우와 에이전트의 차이를 설명했습니다.
그 이후로 우리는 에이전트를 다음과 같이 단순하게 정의하게 되었습니다.

“루프 안에서 자율적으로 도구를 사용하는 LLM”

고객과 함께 작업하면서,
이 단순한 패러다임으로 현장이 점차 수렴하고 있음을 확인했습니다.
모델이 더 스마트해질수록,
에이전트의 자율성 역시 높아집니다.
더 똑똑한 모델은 복잡한 문제 공간을 스스로 탐색하고,
오류에서 회복할 수 있게 해 줍니다.

지금은 에이전트 컨텍스트를 설계하는 사고방식에도 변화가 생기고 있습니다.
많은 AI 네이티브 애플리케이션은
추론 전에 임베딩 기반 검색을 통해
에이전트가 참조할 중요한 컨텍스트를 미리 모으는 방식을 사용합니다.

그러나 보다 에이전트적인 접근법으로 옮겨 가면서,
이러한 사전 검색 시스템을
“정시(just in time) 컨텍스트 전략”으로 보완하는 사례가 늘고 있습니다.

이 방식에서는,
처음부터 모든 관련 데이터를 컨텍스트에 밀어 넣는 대신,

파일 경로나 저장된 쿼리, 웹 링크 같은 가벼운 식별자만 유지하고,
에이전트가 도구를 사용해 런타임에 필요한 데이터를 동적으로 로드합니다.

Anthropic의 에이전트 기반 코딩 솔루션인 Claude Code는
이 방식을 사용해 대규모 데이터베이스에 대한 복잡한 데이터 분석을 수행합니다.
모델은

타깃이 되는 쿼리를 작성하고,
결과를 저장하고,
head, tail 같은 Bash 명령을 활용해

전체 데이터를 컨텍스트로 불러들이지 않고도
큰 데이터셋을 분석할 수 있습니다.

이 접근법은 인간의 인지 방식과도 닮아 있습니다.
우리는 거대한 텍스트를 통째로 외우기보다는
파일 시스템, 메일함, 북마크 같은 외부 조직화·인덱싱 시스템을 활용해
필요할 때마다 정보를 꺼내 쓰기 때문입니다.

이뿐만 아니라,
참조(레퍼런스)에 붙어 있는 메타데이터는
에이전트의 행동을 세밀하게 조정하는 데에도 활용됩니다.

예를 들어, 파일 시스템에서
tests 폴더 안의 test_utils.py와
src/core_logic/ 폴더 안의 test_utils.py는
이름은 같지만 암시하는 역할이 전혀 다릅니다.
폴더 계층 구조, 이름 규칙, 타임스탬프 등은
언제 어떤 정보를 사용해야 할지에 대한 중요한 힌트를 제공합니다.

에이전트가 스스로 데이터를 탐색하고 검색하게 두면,
점진적 공개(progressive disclosure) 도 가능해집니다.
즉, 에이전트가 탐색을 통해
점점 더 많은 관련 컨텍스트를 찾아가도록 만드는 것입니다.

각 상호작용은 다음 결정을 위한 새로운 컨텍스트를 제공합니다.

파일 크기는 복잡도를 암시합니다.
네이밍 규칙은 목적을 암시합니다.
타임스탬프는 최신성·관련도의 지표가 됩니다.

에이전트는 이렇게 단계별로 이해를 쌓아 가며,
작업 기억에는 정말 필요한 정보만 유지하고,
추가로 필요한 내용은 메모 전략을 통해 외부에 보관합니다.
이렇게 자기 관리되는 컨텍스트 윈도우 덕분에
에이전트는 방대한 비관련 정보에 묻히지 않고,
진짜 중요한 부분에 집중할 수 있습니다.

물론 트레이드오프도 존재합니다.

런타임 탐색은,
미리 계산된 데이터를 한 번에 가져오는 것보다 더 느립니다.
LLM이 정보 환경을 효과적으로 탐색할 수 있도록,
적절한 도구와 휴리스틱을 설계하는 데 의견 있는 엔지니어링이 필요합니다.

이런 가이드가 없다면, 에이전트는

도구를 잘못 사용해 컨텍스트를 낭비하고,
막다른 길을 계속 파고들거나,
중요한 정보를 놓치는 등

비효율적인 행동을 할 수 있습니다.

어떤 환경에서는,
에이전트가 일부 데이터는 속도를 위해 미리 가져오고,
나머지는 필요할 때 자율적으로 탐색하는 하이브리드 전략이 가장 효과적일 수 있습니다.

Claude Code는 이런 하이브리드 모델을 사용합니다.

CLAUDE.md 파일은 처음부터 컨텍스트에 단순 투입하고,
glob, grep 같은 원시 도구를 활용해
환경을 탐색하고 파일을 정시에(just in time) 가져옵니다.

이 방식은 오래된 인덱스와 복잡한 AST(추상 구문 트리) 문제를
우회하는 데 효과적입니다.

하이브리드 전략은
법률이나 금융 업무처럼 상대적으로 변화가 적은 도메인에
더 잘 맞을 수도 있습니다.
모델 능력이 향상될수록
에이전트 설계는 점점 “똑똑한 모델이 똑똑하게 행동하도록 두는 방향”으로 나아갈 것이고,
인간의 개입·큐레이션은 점점 줄어들 것입니다.

이 분야의 발전 속도를 고려하면,
Claude 기반 에이전트를 만드는 팀에게는
앞으로도 아마 아래 조언이 유효할 것입니다.

“작동하는 가장 단순한 방법부터 시도하라.”

긴 시간축(Long-horizon) 작업을 위한 컨텍스트 엔지니어링

긴 시간축 작업은,
토큰 수가 LLM의 컨텍스트 창을 초과하는 상황에서도
에이전트가 일관성, 컨텍스트, 목표 지향적 행동을 유지해야 합니다.

수십 분에서 수 시간에 이르는 연속 작업(예: 대규모 코드베이스 마이그레이션,
대형 리서치 프로젝트 등)을 수행하려면,
에이전트는 컨텍스트 창의 크기 제약을 우회하기 위한
특별한 기법이 필요합니다.

컨텍스트 창을 키우는 것이
겉보기에는 가장 쉬운 해결책처럼 보일 수 있습니다.
하지만 앞으로도 상당 기간 동안,
어떤 크기의 컨텍스트 창을 쓰든

컨텍스트 오염(context pollution),
정보 관련성 문제

는 남을 가능성이 큽니다.
특히 가장 강력한 에이전트 성능이 필요한 상황에서는 더욱 그렇습니다.

우리는 긴 시간축에서도 에이전트가 효과적으로 일하게 만들기 위해,
컨텍스트 오염 문제를 직접 겨냥하는 몇 가지 기법을 개발했습니다.

압축(Compaction)
구조화된 노트(Structured note-taking)
서브 에이전트 아키텍처(Sub-agent architectures)

1. 압축(Compaction)

압축은, 컨텍스트 창 한계에 가까워진 대화를
요약한 뒤,
이 요약을 기반으로 새로운 컨텍스트 창을 시작하는 기법입니다.

압축은 긴 시간축에서 일관성을 유지하기 위한 1차 레버 역할을 합니다.
핵심은, 컨텍스트 창의 내용을 고충실(high-fidelity)로 응축·정리해,
최소한의 성능 저하로 작업을 이어 나가는 것입니다.

Claude Code에서는 이를 다음과 같이 구현합니다.

메시지 기록을 모델에 넘겨
가장 중요한 정보를 요약·압축하게 합니다.
이때 모델은
- 아키텍처 결정사항,
- 해결되지 않은 버그,
- 구현 상세 등은 유지하고,
- 중복된 도구 출력이나 메시지는 버립니다.
그런 다음, 이 압축된 컨텍스트에
최근에 접근한 5개의 파일을 추가해
새 컨텍스트를 구성합니다.

사용자 입장에서는
컨텍스트 창 한계를 의식하지 않고도
연속적인 경험을 얻을 수 있습니다.

압축의 핵심은
무엇을 유지하고 무엇을 버릴지를 결정하는 일입니다.
너무 공격적으로 압축하면,
나중에 중요해지는 미묘한 컨텍스트를 잃어버릴 수 있습니다.

압축 시스템을 설계하는 엔지니어에게는 다음을 권장합니다.

복잡한 에이전트 실행 로그(trace)에 대해
압축용 프롬프트를 신중히 튜닝할 것.
먼저 재현율(recall) 을 최대화해,
압축 프롬프트가 모든 중요한 정보를 잡아내도록 만든 뒤,
이후 정밀도(precision) 를 높이는 방향으로
불필요한 내용을 줄여 나갈 것.

도구 호출 결과를 지우는 것은
가장 손쉬운 “낮은 곳에 열린 열매(low-hanging fruit)”에 속합니다.
이미 오래전 메시지 기록에 있는 도구 결과의 원문 전체를
에이전트가 다시 볼 필요는 거의 없습니다.

Claude Developer Platform에서는
도구 결과를 지우는 기능을 제공하는데,
이는 가장 안전하면서도 가벼운 형태의 압축 기법 중 하나입니다.

2. 구조화된 노트(Structured note-taking)

구조화된 노트, 혹은 에이전트 메모리(agentic memory) 는
에이전트가 컨텍스트 창 외부에 유지되는 메모를
정기적으로 작성하고,
나중에 다시 컨텍스트로 불러들이는 전략입니다.

이 방식은 최소한의 오버헤드로 지속적인 메모리를 제공합니다.
예를 들어:

Claude Code가 TODO 리스트를 만드는 것,
사용자가 만든 에이전트가 NOTES.md 파일을 관리하는 것

과 같은 패턴은,
에이전트가 복잡한 작업의 진행 상황과 의존성을 추적할 수 있게 해 주어,
수많은 도구 호출 사이에서 잃어버릴 뻔한 중요한 컨텍스트를 지켜 줍니다.

Claude가 포켓몬 게임을 플레이하는 예시는
코딩이 아닌 영역에서도 메모리가 에이전트 성능을 어떻게 변화시키는지 잘 보여 줍니다.

에이전트는 수천 번의 게임 스텝에 걸쳐
“지난 1,234 스텝 동안 Route 1에서 포켓몬을 훈련했고,
피카츄는 목표 10레벨 중 8레벨을 올렸다” 같은 목표를 정확히 추적합니다.
별도의 메모리 구조에 대한 프롬프트 없이도
탐색한 지역의 맵을 만들고,
어떤 업적을 달성했는지 기억하며,
각 상대에게 어떤 공격이 잘 먹히는지에 대한
전투 전략 노트를 남깁니다.

컨텍스트가 리셋된 이후에도,
에이전트는 스스로 남긴 노트를 다시 읽고,
여러 시간에 걸친 훈련이나 던전 탐험을 이어 나갈 수 있습니다.
이런 요약-복원 과정에서도 일관성을 유지하는 능력 덕분에,
컨텍스트 창만으로는 불가능한 장기 전략이 가능한 것입니다.

Sonnet 4.5 출시와 함께,
우리는 파일 기반 시스템을 활용해
컨텍스트 창 밖에 정보를 저장·조회할 수 있는 메모리 도구를
Claude Developer Platform에서 공개 베타로 선보였습니다.

이를 통해 에이전트는

시간이 지남에 따라 지식 베이스를 쌓고,
세션 간 프로젝트 상태를 유지하며,
모든 정보를 컨텍스트에 넣지 않고도
이전 작업을 참조할 수 있습니다.

3. 서브 에이전트 아키텍처(Sub-agent architectures)

서브 에이전트 아키텍처는
컨텍스트 제약을 우회하는 또 다른 방법입니다.

한 개의 에이전트가 전체 프로젝트의 모든 상태를 유지하려 애쓰는 대신,
특화된 서브 에이전트들이 집중된 작업을 각각 담당하고,
각자는 깨끗한 컨텍스트 창을 유지합니다.

메인 에이전트는 상위 수준의 계획을 관리하고,
서브 에이전트는
- 깊이 있는 기술적 작업을 수행하거나,
- 도구를 활용해 관련 정보를 검색합니다.

각 서브 에이전트는
수만 토큰 수준의 탐색을 수행할 수도 있지만,
결국에는 1,000~2,000 토큰 정도의 응축된 요약만
메인 에이전트에게 돌려줍니다.

이 방식은 관심사의 분리를 분명히 해 줍니다.

상세한 탐색 컨텍스트는 서브 에이전트 내부에 고립되고,
메인 에이전트는 결과를 통합·해석하는 데 집중합니다.

“How we built our multi-agent research system”에서 다룬 이 패턴은,
복잡한 리서치 작업에서 단일 에이전트 시스템보다
상당한 성능 향상을 보여 주었습니다.

어떤 접근법이 적절한지는 작업의 특성에 따라 달라집니다. 예를 들면:

압축(Compaction)
→ 많은 대화 왕복이 필요한 작업에서
대화 흐름을 유지하는 데 적합
노트 작성(Note-taking)
→ 명확한 마일스톤을 가진 반복적 개발 작업에 적합
멀티 에이전트(Multi-agent)
→ 병렬 탐색이 가치 있는 복잡한 리서치·분석 작업에 적합

모델이 계속 좋아지더라도,
오랜 상호작용 전반의 일관성을 유지하는 문제는
더 효과적인 에이전트를 만드는 데 있어 중심 과제로 남을 것입니다.

결론

컨텍스트 엔지니어링은
LLM을 사용하는 방식의 근본적인 전환을 의미합니다.

모델이 더 강력해질수록,
과제는 단순히 “완벽한 프롬프트를 만드는 것”에서
각 단계마다 모델이 사용할 제한된 주의 예산(컨텍스트) 에
어떤 정보를 넣을지 신중하게 선별하는 일로 옮겨가고 있습니다.

긴 시간축 작업을 위해 압축을 설계하든,
토큰 효율적인 도구를 만들든,
에이전트가 환경을 정시에(just-in-time) 탐색·검색할 수 있게 하든,

핵심 원칙은 같습니다.

원하는 결과를 낼 가능성을 최대화하는
가장 작고 고신호(high-signal)인 토큰 집합을 찾아라.

우리가 소개한 기법들은
모델이 더 발전함에 따라 계속 진화할 것입니다.
이미 더 똑똑한 모델일수록
세세한 엔지니어링이 덜 필요해지고,
에이전트는 더 높은 자율성을 갖게 되는 경향이 있습니다.

그럼에도 불구하고,
컨텍스트를 귀하고 한정된 자원으로 다루는 태도는
신뢰할 수 있고 효과적인 에이전트를 만드는 데
여전히 핵심으로 남을 것입니다.

Claude Developer Platform에서
컨텍스트 엔지니어링을 바로 시작해 보시고,
메모리 및 컨텍스트 관리 쿡북에서
유용한 팁과 베스트 프랙티스를 참고해 보세요.

출처: https://www.claude.com/blog/best-practices-for-prompt-engineering