저는 처음에 컨텍스트 엔지니어링 (Context Engineering)을 「프롬프트 엔지니어링 (Prompt Engineering)의 연장선」이라고 생각했습니다. 긴 프롬프트를 작성하는 유파 정도의 이해였습니다.

하지만 실제로 프로덕션 (Production)에서 사용해 보니 그것은 달랐습니다. 컨텍스트 엔지니어링은 독립된 7가지 요소를 조합하는 시스템 설계였습니다.

프롬프트는 그중 하나에 불과합니다.

コンテキストエンジニアリングの7要素 構成図

이 기사에서는 7가지 요소 각각의 역할, 효과적인 상황, 타 요소와의 관계, 그리고 실패 사례를 정리합니다. 긴 프롬프트 너머에서 무엇이 일어나고 있는지를 구조로서 이해하기 위한 지도입니다.

왜 「7가지 요소」로 정리하는가

Anthropic은 공식 블로그에서 컨텍스트 엔지니어링을 6개의 레이어 (Layer)로 설명하고 있습니다. System instructions, semantic context, operational memory, conversational history, retrieval systems, tool access의 6가지입니다.

LangChain과 LlamaIndex의 2026년판 문서에서는 Memory, State, Tools, Agents를 축으로 한 분류가 등장합니다.

연구자나 프레임워크에 따라 요소의 수와 명칭도 미묘하게 다릅니다.

그럼에도 불구하고 제가 현장에서 "이것을 의식하지 않으면 돌아가지 않는다"라고 느끼는 구성 요소는 결국 7가지로 수렴되었습니다. System Prompt, Few-shot, RAG, Tool Use, Memory, Compaction, 그리고 일곱 번째로 Agentic Control입니다.

숫자의 엄밀함은 중요하지 않습니다. 컨텍스트 엔지니어링은 「단일 기법」이 아니라 「조합론」이라고 인식하는 것, 이것이 출발점입니다.

요소 01: System Prompt ── 역할과 경계를 결정함

System Prompt는 LLM의 토대입니다. 역할, 말투, 해서는 안 되는 일, 모를 때의 행동 양식을 정의합니다.

제가 가장 뼈저리게 느낀 것은 System Prompt를 바꾼 것만으로 성실성 (Integrity)이 극적으로 변한다는 것이었습니다. Claude Sonnet 4의 성실성 스코어가 0.2에서 3.7로 뛰어오른 실험을 보았을 때, 이것은 「프롬프트 기술」이 아니라 「설계」라는 것을 이해했습니다.

언제 효과적인가

모든 태스크 공통의 전제를 전달하는 상황입니다. "당신은 누구인가", "모를 때는 모른다고 말하라"와 같이 매번 필요하지만 매번 쓰고 싶지는 않은 지시를 담당합니다.

타 요소와의 관계

System Prompt는 다른 6가지 요소의 거동의 전제 조건이 됩니다. RAG로 가져온 정보를 사용할 때의 태도, Tool Use의 권한 경계, Memory의 참조 정책. 이 모든 것을 System Prompt가 결정합니다.

흔한 실패 사례

"자세히 대답해 주세요"라고 써버리는 실패입니다. LLM은 "자세히"라는 말을 들으면 추측으로 빈틈을 메웁니다. 결과적으로 할루시네이션 (Hallucination)이 증가합니다.

"모를 때는 '불명'이라고 대답해 주세요"라고 쓰는 편이 실전에서는 더 효과적입니다.

요소 02: Few-shot Examples ── 출력의 형식을 보여줌

Few-shot은 예시를 통해 출력 포맷 (Format)을 전달하는 요소입니다.

"JSON으로 대답해"라고 100자를 쓰는 것보다, JSON 예시를 하나 보여주는 것이 더 빠르고 정확하게 전달됩니다. 설명보다 실례라는 것입니다.

언제 효과적인가

출력 포맷이 고정되어 있을 때, 또는 "설명하기는 어렵지만 보면 알 수 있는" 종류의 태스크일 때입니다. 코드 리뷰 코멘트, 메일 답장의 톤, SQL 쿼리 작성 방식 등이 해당합니다.

타 요소와의 관계

Few-shot은 System Prompt와 궁합이 좋습니다. System Prompt로 역할을 정의하고, Few-shot으로 구체적인 예를 보여줍니다. 역할과 실례의 2단계 구성은 현장에서 매우 효과적인 조합입니다.

단, RAG와는 충돌하기 쉽습니다. Few-shot으로 고정된 예시를 보여주면, RAG로 가져온 정보보다 예시를 더 모방해 버리는 경우가 있습니다.

흔한 실패 사례

예시를 너무 많이 늘리는 실패입니다. Few-shot은 5개를 넘어가면 컨텍스트 (Context)를 압박할 뿐 정밀도는 한계에 부딪힙니다. Anthropic도 "diverse, canonical examples"라고 말하고 있듯이, 양보다 대표성이 중요합니다.

요소 03: RAG ── 외부 지식을 끌어들임

RAG (Retrieval-Augmented Generation)는 외부 지식 베이스 (Knowledge Base)에서 관련 정보를 검색하여 프롬프트에 주입하는 메커니즘입니다.

제 경험상, 컨텍스트 엔지니어링 (Context Engineering) 개선 폭의 8할은 여기서 나옵니다.

언제 효과적인가

LLM이 학습 시에 알지 못하는 도메인 지식 (Domain Knowledge)이 필요할 때입니다. 사내 문서, 최신 API 명세, 고유명사로 가득한 업무 지식 등, 요컨대 Wikipedia에는 적혀 있지 않은 정보들입니다.

다른 요소와의 관계

RAG는 Memory와 경계가 모호해지기 쉽습니다. 제가 구분하여 사용하는 기준은, RAG = 정적인 지식 베이스 (Knowledge Base)의 검색, Memory = 사용자와의 동적인 상호작용의 축적입니다.

예를 들어 사용자 매뉴얼은 RAG, 사용자의 "이전에 이렇게 설정했다"라는 이력은 Memory입니다. 검색하는 장소가 다릅니다.

흔한 실수

"일단 전부 RAG에 넣는다"는 실수입니다. 사내 Slack의 과거 로그를 전부 벡터화(Vectorization)했지만, 검색 노이즈가 늘어나 정밀도가 떨어진 케이스를 수없이 보았습니다.

RAG는 "무엇을 넣지 않을 것인가"가 설계의 중심입니다.

요소 04: Tool Use / MCP ── 외부 세계에 작용한다

Tool Use는 LLM이 외부 시스템을 호출하여 결과를 가져오는 메커니즘입니다. MCP (Model Context Protocol)는 그 연결을 표준화하는 프로토콜입니다.

RAG가 "읽기"라면, Tool Use는 "읽기 + 쓰기 + 실행하기"입니다.

언제 효과적인가

LLM의 내부 지식만으로는 답을 확정할 수 없을 때, 또는 부작용 (Side Effect)이 필요할 때입니다. 현재 재고를 확인하거나, 메일을 보내거나, 코드를 실행하거나, 데이터베이스를 업데이트하는 작업 등입니다.

MCP는 2024년 말부터 Anthropic이 추진해 왔으며, 2026년 현재 Claude Code, Cursor 및 기타 에이전트 (Agent) 도구들이 표준으로 대응하고 있습니다.

다른 요소와의 관계

Tool Use는 Agentic Control과 한 쌍으로 움직입니다. "언제 도구를 호출할 것인가"를 판단하는 것이 Agentic Control이며, "무엇을 호출할 것인가"에 대한 메뉴가 Tool Use입니다.

도구가 20개나 되면 LLM은 무엇을 사용할지 망설이게 됩니다. 이것이 컨텍스트를 오염시킵니다. Anthropic은 "minimal viable set of tools"를 권장하며, 이는 현장의 감각과 일치합니다.

흔한 실수

"도구를 늘리면 똑똑해질 것"이라고 생각하여 무작정 집어넣는 실수입니다. LLM은 도구 정의 (Tool Definition) 또한 컨텍스트로서 읽습니다. 50개의 도구 정의를 매번 읽어야 하는 입장이라고 생각하면, 왜 정밀도가 떨어지는지 짐작할 수 있습니다.

요소 05: Memory ── 상태를 유지한다

Memory는 세션을 넘어 정보를 유지하는 메커니즘입니다.

Anthropic은 2026년 3월에 Memory 도구를 기본 기능으로 구현했습니다. 사용자의 직업, 선호하는 도구, 반복해서 등장하는 토픽을 자동으로 기억합니다.

언제 효과적인가

지속적인 대화, 장기 프로젝트의 동행, 사용자별 개인화 (Personalization)가 필요할 때입니다. 한 번 말한 설정을 매번 다시 말할 필요가 없는 세상을 만들고 싶을 때입니다.

다른 요소와의 관계

Memory는 단기 (Buffer), 중기 (Summary), 장기 (Vector 또는 Knowledge Graph)로 계층화됩니다. Compaction을 중기 Memory를 만드는 수단 중 하나라고 파악하면 정리가 쉬워집니다.

System Prompt와의 관계도 잊기 쉽습니다. "Memory를 어떻게 참조할 것인가"에 대한 정책은 System Prompt에 작성합니다.

흔한 실수

"전부 기억시킨다"는 실수입니다. Memory는 쌓이면 검색 정밀도가 떨어집니다. 오래된 정보의 자동 만료, 모순되는 정보의 해소 로직을 나중에 따로 만드는 상황에 처하게 됩니다.

처음부터 "무엇을 잊을 것인가"를 설계해 두면 나중에 편합니다.

요소 06: Compaction ── 문맥을 압축하여 수명을 연장한다

Compaction은 길어진 대화 이력을 요약 및 압축하는 기술입니다.

Anthropic 공식 정의에 따르면 Compaction은 "더 이상 필요하지 않은 것을 폐기하고 이를 압축된 표현으로 대체하는 능동적인 메모리 관리 (active memory management that discards what is no longer needed and replaces it with a compressed representation)"입니다.

Claude Code는 5단계의 점진적 Compaction을 가지고 있으며, Budget reduction → Snip → Microcompact → Context collapse → Auto-compact 순으로 발동합니다.

언제 효과적인가

긴 호흡의 태스크와 장시간 동작하는 에이전트. 1시간 이상 동작하는 코딩 에이전트, 100턴이 넘는 대화, 대량의 툴 결과(Tool results)를 처리하는 워크플로우.

다른 요소와의 관계

Compaction은 다른 모든 요소를 "축약하여 남기는" 역할을 하므로, 하나의 요소라기보다 메타 요소 (Meta-element) 에 가깝습니다. System Prompt는 보통 살아남지만, 대화 도중의 중요한 결정은 Compaction 과정에서 사라질 가능성이 있습니다.

이 때문에 Anthropic은 "critical rules는 CLAUDE.md(=System Prompt)에 두라"고 명시하고 있습니다. Compaction에만 맡기면 핵심적인 규칙이 압축 과정에서 사라질 수 있기 때문입니다.

흔한 실수

"Compaction에 맡기면 길게 동작할 것이다"라고 생각하여, 핵심적인 정보를 대화 중반에 방치하는 실수입니다. 그러면 압축되어 사라집니다.

규칙은 System Prompt에 고정하고, 상태는 Memory에 영속화하며, 그 위에 Compaction을 사용합니다. 순서가 중요합니다.

요소 07: Agentic Control ── 6개 요소를 묶는 판단층

7번째는 다른 6개 요소를 언제, 얼마나 사용할지를 판단하는 메타 요소입니다.

고정된 파이프라인으로 "System Prompt → RAG → Tool Use → 출력"을 매번 흘려보내는 것은 제1세대 CE입니다. 제2세대는 상황에 따라 요소를 선택하는 판단층이 올라갑니다.

언제 효과적인가

입력의 종류가 다양하여 매번 같은 처리를 하는 것이 비효율적일 때입니다. 사용자의 질문이 지식 검색으로 끝날 문제인지, 툴 호출(Tool calling)이 필요한지, 혹은 과거의 Memory를 참조해야 하는지를 판정하는 장면입니다.

LangGraph, Claude Code, 최근의 Cursor 등은 이 판단층을 구현하고 있습니다. Agentic RAG라고 불리는 파생 형태도 있습니다.

다른 요소와의 관계

Agentic Control은 다른 6개 요소의 "상위 레이어 (Upper layer)"입니다. 지휘자와 오케스트라의 관계와 비슷합니다.

흔한 실수

"처음부터 완전한 판단 로직을 작성하려고 하는" 실수입니다. Agentic Control은 우선 고정된 파이프라인으로 동작시키고, 판단이 필요하다고 판단되는 가지(Branch)만 나중에 동적으로 만드는 순서가 현실적입니다.

LLM에게 전부 맡기면, 저렴한 태스크에 매번 Claude Opus를 호출하는 것과 같은 낭비가 발생합니다.

요소 간의 관계 맵

7개 요소는 독립적이지만, 조합하면 상호작용이 발생합니다. 제 경험상 특히 의식하고 있는 관계는 다음과 같습니다.

System Prompt × 다른 모든 요소: System Prompt는 다른 요소들의 행동에 대한 "전제"를 만듭니다. System Prompt가 느슨하면 RAG를 통해 좋은 정보가 들어와도 LLM이 추측을 섞게 됩니다.

RAG × Memory: 정적 지식과 동적 기억의 역할 분담을 명확히 하지 않으면, 양쪽 모두에 같은 정보가 들어가 혼란을 초래합니다.

Tool Use × Agentic Control: 툴 선택 판단을 그르치면, 저렴한 태스크에 고비용 툴을 사용하거나 그 반대의 상황을 저지르게 됩니다.

Compaction × 모든 요소: Compaction은 하위 레이어의 정보를 축약하므로, "축약되어도 사라지지 않도록" 설계할 책임이 다른 요소들에게 있습니다.

이것은 "조합론 (Combinatorics)"이라고 부를 수밖에 없는 세계입니다. 요소별로 배우는 것에 만족하지 않고, 조합의 패턴을 익혀 나가는 것이 현장의 방식입니다.

어떤 요소부터 시작해야 하는가

7개를 한꺼번에 구현하는 것은 불가능합니다. 제가 현장에서 자주 권장하는 순서는 다음과 같습니다.

System Prompt 정비 (수 시간): 우선 여기서 성실성(Integrity)을 확보한다 -
RAG 도입 (12주): 효과의 8할은 여기서 얻을 수 있다 -
Few-shot 추가 (수 시간): 출력 포맷을 안정화한다 -
Tool Use / MCP (12주): 외부 세계와의 연계가 필요하다면 -
Memory (12주): 지속적인 대화가 필요하다면 -
Compaction (API에 맡겨도 OK): 긴 호흡의 태스크가 등장한다면 -
Agentic Control (수 주): 파이프라인이 복잡해진 이후부터

순서를 거꾸로 하면 토대가 약한 상태에서 위를 쌓게 됩니다. 예를 들어 System Prompt가 허술한 상태에서 Agentic Control을 만들면 판단의 근거가 무너집니다.

요약

컨텍스트 엔지니어링은 프롬프트의 확장이 아닙니다. 7개의 독립된 요소를 조합하는 시스템 설계입니다.

7개 요소를 다시 정리하겠습니다.

• System Prompt: 역할과 경계 -
  Few-shot Examples: 출력의 형식 -
  RAG: 외부 지식 검색 -
  Tool Use / MCP: 외부 세계에 대한 작용 -
  Memory: 상태 유지 -
  Compaction: 문맥 압축 -
  Agentic Control: 6개 요소를 하나로 묶는 판단 계층

각각 역할이 다르고, 효과가 나타나는 상황이 다르며, 실패하는 방식도 다릅니다. 프롬프트를 길게 쓰는 기술이라고 생각한다면 이 전체상을 볼 수 없습니다.

저는 요소를 하나씩 이해하고, 조합의 패턴을 늘려가는 것이 컨텍스트 엔지니어링 (Context Engineering)을 배우는 방법이라고 생각합니다. 지도를 가지고 걸으면 길을 잃을 확률이 낮아집니다.

참고 링크

• Effective context engineering for AI agents - Anthropic 공식
• Context engineering: memory, compaction, and tool clearing - Claude Cookbook
• What Is Context Engineering? Complete 2026 Guide - Atlan
• LangChain vs LlamaIndex in 2026 - 프레임워크 비교

Discussion