Context Engineering: 프롬프트를 넘어, 에이전트 시대의 핵심 설계 역량

같은 모델에게 같은 요청을 했는데 결과가 완전히 다릅니다. 한쪽은 "Thank you for your message. Tomorrow works for me."라고 답하고, 다른 쪽은 "Hey Jim! Tomorrow's packed, back-to-back all day. Thursday AM free if that works for you?"라고 답합니다. 모델은 동일합니다. 프롬프트도 동일합니다. 차이는 오직 하나, 모델이 볼 수 있었던 정보의 범위 입니다.

Phil Schmid(Hugging Face)가 제시한 이 비유는 간단하지만 핵심을 찌릅니다. 첫 번째 에이전트는 사용자 메시지만 봤고, 두 번째 에이전트는 캘린더 일정, Jim과의 과거 이메일, 연락처 정보, 그리고 일정 초대 도구까지 갖추고 있었습니다. 모델의 능력이 아니라 컨텍스트의 설계 가 결과를 결정한 것입니다.

2025년 하반기부터 AI 업계에서 하나의 용어가 급부상하고 있습니다. Context Engineering. 프롬프트 엔지니어링이 "어떻게 물어볼까"에 집중했다면, Context Engineering은 "모델이 작업을 수행할 때 어떤 정보 생태계 안에 있어야 하는가"를 설계합니다. 이 글에서는 이 새로운 패러다임이 왜 지금 등장했고, 무엇을 의미하며, 우리의 작업 방식을 어떻게 바꾸고 있는지를 분석하겠습니다.

Vibe Coding에서 Context Engineering으로

흐름을 짚어보겠습니다. 2025년 2월, Andrej Karpathy가 "Vibe Coding" 이라는 용어를 제시했습니다. AI에게 대충 지시하고, 결과물의 "느낌(vibe)"이 괜찮으면 넘어가는 코딩 방식이었습니다. 불과 4개월 뒤인 2025년 6월, 같은 Karpathy가 이번에는 Context Engineering을 지지합니다.

+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions... Context engineering is the delicate art and science of filling the context window with just the right information for the next step.

Vibe Coding에서 Context Engineering으로의 전환은 단순한 용어 교체가 아닙니다. MIT Technology Review는 이를 "2025년 소프트웨어 개발의 핵심 흐름"으로 분석했습니다. 직관적으로 AI를 사용하던 단계에서, 체계적으로 AI의 정보 환경을 설계하는 단계로 넘어가고 있다는 신호입니다.

이 용어의 대중화에 불을 붙인 것은 Shopify CEO Tobi Lutke의 발언이었습니다.

I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.

Karpathy와 Lutke, 두 사람의 발언 이후 Anthropic, LangChain, Gartner, Elastic 등 주요 기업과 기관이 공식적으로 Context Engineering을 다루기 시작했습니다. Gartner가 기업 AI 전략 아티클로 채택했다는 점은, 이것이 단순한 버즈워드가 아니라 실무 영역으로 진입했다는 신호로 읽힙니다.

Context Engineering이란 무엇인가

Anthropic의 정의를 빌리겠습니다.

Building with language models is becoming less about finding the right words and phrases for your prompts, and more about answering the broader question of 'what configuration of context is most likely to generate our model's desired behavior?'

풀어서 설명하면, Context Engineering은 LLM에게 올바른 정보를, 올바른 형식으로, 올바른 시점에 제공하는 동적 시스템을 설계하는 분야 입니다. 여기서 "동적 시스템"이라는 표현이 중요합니다. 한 번 작성하고 마는 정적 프롬프트가 아니라, 상황에 따라 정보를 선택하고, 압축하고, 배치하는 시스템 아키텍처 를 설계하는 것입니다.

Karpathy는 이를 더 직관적인 비유로 설명합니다.

LLM은 CPU이고, 컨텍스트 윈도우는 RAM이다.

CPU가 아무리 빨라도 RAM에 올바른 데이터가 올라와 있지 않으면 의미 있는 작업을 할 수 없습니다. 마찬가지로, 모델이 아무리 똑똑해도 컨텍스트에 올바른 정보가 없으면 실패합니다. 그리고 RAM이 유한한 것처럼 컨텍스트 윈도우도 유한합니다. 무엇을 올리고 무엇을 내릴지 결정하는 것이 핵심 설계 과제가 됩니다.

컨텍스트의 7가지 구성 요소

Phil Schmid는 LLM의 컨텍스트를 7가지로 분류합니다.

1. System Prompt -- 행동 규칙, 역할 정의, 예시
2. User Prompt -- 현재 작업이나 질문
3. Short-term Memory -- 현재 대화 이력
4. Long-term Memory -- 사용자 선호도, 과거 프로젝트 요약
5. Retrieved Information (RAG) -- 외부 문서, DB, API에서 가져온 최신 지식
6. Available Tools -- 호출 가능한 함수와 API 정의
7. Structured Output -- 응답 형식 명세 (JSON 스키마 등)

여기서 핵심적인 관찰이 있습니다. 프롬프트 엔지니어링이 주로 1번(System Prompt)과 2번(User Prompt)만 다뤘다면, Context Engineering은 7가지 전부를 설계 대상으로 삼습니다. 프롬프트 엔지니어링은 Context Engineering의 부분집합인 셈입니다.

왜 지금인가 -- 에이전트 시대의 필연

"프롬프트를 잘 쓰면 되는 거 아닌가?" 이 질문에 대한 대답이 바뀐 데에는 구체적인 이유가 있습니다.

에이전트가 보편화되었습니다

2025년은 AI 에이전트가 본격 상용화된 해입니다. LLM이 단일 질의응답을 넘어 도구를 호출하고, 루프를 돌며, 자율적으로 작업을 수행하게 되었습니다. Claude Code가 파일을 읽고 쓰고, 테스트를 실행하고, Git 커밋까지 하는 세상입니다. 이 수준의 자율성에서는 "프롬프트 하나 잘 쓰기"로는 부족합니다. 에이전트가 수십 단계를 거치는 동안 어떤 정보를 어떤 시점에 갖고 있어야 하는지를 설계해야 합니다.

컨텍스트 윈도우의 역설이 드러났습니다

모델의 컨텍스트 윈도우가 100K, 200K, 1M 토큰으로 커졌습니다. 하지만 창이 커진다고 문제가 해결되지 않았습니다. "Lost-in-the-middle" 현상 -- 긴 컨텍스트의 중간에 있는 정보를 모델이 놓치는 문제 -- 이 확인되었고, 컨텍스트가 늘수록 정확도가 오히려 하락하는 "context rot" 도 관찰되었습니다. "무조건 많이 넣기" 전략이 통하지 않는다는 것이 실증적으로 드러난 것입니다.

프로젝트 컨텍스트 파일이 보편화되었습니다

CLAUDE.md, .cursorrules, AGENTS.md 같은 파일이 실무에서 보편화되었습니다. 그리고 개발자들이 인식하기 시작했습니다 -- "내가 매일 CLAUDE.md를 고치는 이 작업이, 사실 컨텍스트를 엔지니어링하는 행위였구나." 이미 하고 있던 일에 이름이 붙은 것입니다.

Phil Schmid의 통찰이 이 흐름을 한 문장으로 요약합니다.

Most agent failures are not model failures anymore, they are context failures.

대부분의 에이전트 실패는 모델의 한계가 아니라, 모델에게 제공된 정보의 문제입니다. 모델은 이미 충분히 똑똑합니다. 부족한 것은 올바른 컨텍스트입니다.

다섯 가지 핵심 전략

Context Engineering이 추상적 개념에 머물지 않는 이유는, 구체적인 전략과 기법이 정립되고 있기 때문입니다. Faros AI와 Anthropic의 가이드를 종합하면 다섯 가지 핵심 전략이 도출됩니다.

Selection -- 적게, 정확하게

"More context does not equal better performance. Optimal density wins." 100개 파일 전체를 컨텍스트에 넣는 것이 아니라, 현재 작업에 필요한 5개 파일만 선별하는 것이 핵심입니다.

인증 기능을 수정한다고 가정하겠습니다. 프로젝트에 프론트엔드 코드 50,000줄이 있더라도, 실제로 필요한 것은 세 개의 파일뿐입니다.

// 컨텍스트에 포함할 파일들 (Selection 적용)
const relevantFiles = [
  'src/middleware/auth-middleware.ts',   // 500줄 - 인증 로직
  'src/models/user-model.ts',           // 200줄 - 사용자 모델
  'src/config/auth-config.ts',          // 50줄 - 인증 설정
]

// 포함하지 않을 파일들
// src/components/**  (프론트엔드 50,000줄 - 현재 작업과 무관)
// src/utils/**        (유틸리티 - 필요 시 동적 로드)

Anthropic은 이를 "Just-in-Time Retrieval" 패턴으로 발전시킵니다. 사전에 모든 데이터를 로드하지 않고, 경량 식별자(파일 경로, URL)만 유지하다가 필요한 시점에 도구를 통해 동적으로 로드하는 방식입니다. Claude Code가 파일 시스템을 탐색하면서 필요한 데이터만 읽어오는 것이 바로 이 패턴입니다.

Compression -- 핵심만 남기기

컨텍스트 윈도우가 한계에 도달하면, 대화를 종료하는 대신 기존 컨텍스트를 압축하고 이어갈 수 있습니다. Anthropic의 Claude Code는 "compaction" 이라는 기법을 사용합니다. 메시지 히스토리를 모델로 요약하되, 아키텍처 결정이나 미해결 버그 같은 핵심 정보는 보존하고, 중복된 도구 출력은 폐기하는 전략입니다.

Ordering -- 위치가 성능을 좌우합니다

같은 정보라도 컨텍스트 내 어디에 배치하느냐에 따라 결과가 달라집니다. Lost-in-the-middle 현상에 대응하는 전략입니다.

# 컨텍스트 배치 전략
context_ordering:
  beginning:    # 중요 규칙 (보안 요구사항, 코딩 컨벤션)
    - "오버라이드 방지 위해 최상단 배치"
  middle:       # 참고 예제, 관련 코드
    - "모델이 참조하되 반드시 따를 필요 없는 정보"
  end:          # 현재 작업 내용
    - "최근 정보 편향(recency bias) 활용"

이것은 이론이 아니라 실측 데이터가 뒷받침합니다. Faros AI에 따르면, AGENTS.md를 파일 중간에서 처음으로 옮겼을 때 코드 스타일 위반이 35~40% 감소 했습니다. 같은 내용이지만 위치만 바꿨을 뿐인데 이 정도의 차이가 발생한 것입니다.

Isolation -- 관심사를 분리하기

복잡한 작업을 하나의 에이전트에 모두 맡기면 컨텍스트가 비대해지고, 서로 무관한 정보가 뒤섞이면서 성능이 하락합니다. 해결책은 여러 전문 에이전트로 분할 하는 것입니다.

// Anthropic의 서브에이전트 패턴
interface AgentOrchestration {
  mainAgent: {
    role: 'high-level planning'
    contextWindow: 'clean, focused'
    receives: 'summaries only (1,000-2,000 tokens)'
  }
  subAgents: {
    role: 'specialized task execution'
    contextWindow: 'dedicated, isolated'
    produces: 'detailed work → compressed summary'
    // 서브에이전트가 수만 토큰 소비 후
    // 1,000~2,000 토큰 요약만 메인에 반환
  }
}

서브에이전트가 수만 토큰을 소비하며 상세 작업을 수행하더라도, 메인 에이전트에는 1,000~2,000 토큰의 요약만 반환합니다. 상세 검색 컨텍스트는 서브에이전트 내부에 격리되어 메인 에이전트의 컨텍스트를 오염시키지 않습니다.

Format Optimization -- 같은 정보, 다른 효율

정보를 어떤 형식으로 제공하느냐도 성능에 영향을 미칩니다. 토큰 효율성 측면에서 YAML이나 XML이 JSON보다 효율적이고, 마크다운 헤더로 구조를 잡으면 모델이 정보를 더 잘 파악합니다. 비교 데이터는 표 형식이 효과적입니다.

이미 하고 있는 일의 이름

Context Engineering이 흥미로운 것은, 완전히 새로운 행위를 요구하는 것이 아니라 이미 하고 있는 일에 체계를 부여한다 는 점입니다. 구체적인 사례를 살펴보겠습니다.

CLAUDE.md 작성 = Context Engineering

CLAUDE.md, .cursorrules, AGENTS.md 같은 프로젝트 컨텍스트 파일을 작성하는 행위는 Context Engineering의 가장 직접적인 실체입니다. 이것은 단순한 프롬프트 작성이 아닙니다. System Prompt를 프로젝트 단위로 설계하는 행위이며, 코딩 규칙, 아키텍처 패턴, 금지 사항을 통해 모델에게 "어떤 맥락에서 작업하는지"를 알려주는 영구적 컨텍스트 시스템 의 설계입니다.

Faros AI가 정리한 효과적인 작성 원칙은 참고할 만합니다.

• 추상적 원칙("DRY 따르기") 대신 구체적 예제 ("좋은 패턴 vs 나쁜 패턴")를 제시할 것
• 하나의 거대 파일 대신 폴더별/작업별 특화 컨텍스트를 구성할 것
• 분기별 검토로 오래된 항목을 제거하고 모순을 해결할 것
• 에이전트 실패가 발생할 때마다 컨텍스트 파일을 업데이트할 것(반응형 유지보수)

반대로, 흔한 세 가지 실수도 있습니다. 모든 것을 하나의 거대 파일에 넣어서 중요 규칙이 중간에 묻히게 하거나, 규칙을 추상적 원칙으로만 작성해서 실행력이 떨어지거나, 한 번 작성 후 방치해서 오래된 규칙이 누적되는 것입니다.

MCP 서버 구성 = Context Engineering

Model Context Protocol(MCP)은 Anthropic이 2024년 말 도입한 표준으로, "AI를 위한 USB-C"로 불립니다. MCP 서버를 구성하는 행위 역시 Context Engineering입니다. 어떤 MCP 서버를 연결하느냐에 따라 에이전트의 능력과 행동이 근본적으로 달라지기 때문입니다.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "..." }
    },
    "database": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "..." }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_TOKEN": "..." }
    }
  }
}

GitHub MCP 서버를 연결하면 에이전트가 PR을 생성하고 이슈를 조회할 수 있습니다. DB MCP 서버를 연결하면 직접 쿼리를 실행합니다. Slack MCP 서버를 연결하면 팀과 소통합니다. 각 서버의 도구 정의 -- description과 parameter schema를 얼마나 잘 설계하느냐가 에이전트 성능을 좌우합니다. 이것이 바로 Available Tools(컨텍스트 구성요소 6번)를 설계하는 Context Engineering입니다.

RAG 파이프라인 설계 = Context Engineering

RAG(Retrieval-Augmented Generation)에서의 모든 설계 결정도 Context Engineering의 범주에 들어갑니다. 청킹 전략은 "어떤 크기로 정보를 잘라서 컨텍스트에 넣을 것인가"를 결정하고, 검색 전략은 "어떤 정보를 가져올 것인가"를 결정하며, 재순위(re-ranking)는 "가져온 정보 중 어떤 것을 우선할 것인가"를 결정합니다.

Weaviate의 분석에 따르면, 청킹 크기에는 명확한 트레이드오프가 있습니다. 작은 청크는 정밀도가 높지만 주변 맥락이 부족하고, 큰 청크는 맥락이 풍부하지만 임베딩이 "noisy"해져 검색 정밀도가 하락합니다. 코드 문서에서는 AST(Abstract Syntax Tree) 기반 청킹이 효과적입니다 -- 함수나 클래스의 경계를 존중해서 의미 있는 단위로 자릅니다.

이 모든 결정이 궁극적으로 모델의 컨텍스트 윈도우에 어떤 정보가 올라가느냐를 결정합니다. RAG 엔지니어는 이미 Context Engineer였던 셈입니다.

비판적 시선 -- 이름만 새로운 것은 아닌가

Context Engineering에 대한 비판도 존재합니다. 건강한 회의론은 필요합니다.

"이미 하고 있던 일에 새 이름만 붙인 것 아닌가." 가장 흔한 비판입니다. RAG를 설계하고, 시스템 프롬프트를 다듬고, 도구를 정의하는 일은 이미 하고 있었으니까요. 이 비판에는 일리가 있습니다. 하지만 "이미 하던 일에 이름을 붙이는 것"의 가치를 과소평가해서는 안 됩니다. 이름이 붙으면 체계가 생기고, 체계가 생기면 방법론이 발전하고, 방법론이 발전하면 재현 가능한 성과가 나옵니다. "DevOps"가 개발과 운영의 협업에 이름을 붙인 것처럼요.

정답이 없습니다. 최적의 컨텍스트 구성은 작업, 모델, 도메인마다 다릅니다. One-size-fits-all 솔루션이 없다는 것은 이 분야의 본질적 한계입니다.

측정이 어렵습니다. 컨텍스트 품질 개선 효과를 정량적으로 측정하기 쉽지 않습니다. "CLAUDE.md를 개선했더니 코드 품질이 올랐다"를 어떻게 수치로 증명할까요? Faros AI의 "스타일 위반 35~40% 감소" 같은 사례가 있긴 하지만, 범용적인 측정 프레임워크는 아직 부족합니다.

멀티에이전트의 취약성. Cognition의 연구에 따르면, 멀티에이전트 시스템은 fragile할 수 있습니다. 공유 컨텍스트가 필요한 상황에서는 오히려 단일 스레드가 더 안정적일 수 있습니다. Isolation 전략이 항상 정답은 아니라는 뜻입니다.

OpenAI Developer Community에서는 "Context Engineering조차 이미 낡았고, 자동화된 워크플로우 아키텍처가 미래다"라는 도발적 논쟁도 진행되고 있습니다. 하지만 현재 주류 합의는 Context Engineering이 가장 실용적인 프레이밍이라는 쪽입니다.

Context Engineer라는 새로운 역할

ODSC(Open Data Science Conference)는 Context Engineer를 2026년 신규 AI 직무로 소개했습니다. Prompt Engineer가 좋은 질문을 던지는 사람이라면, Context Engineer는 모델이 답을 잘 할 수 있는 환경 전체를 설계하는 사람 입니다.

구체적인 업무 범위를 보면 이것이 얼마나 넓은 역할인지 알 수 있습니다.

• 시스템 프롬프트 및 AGENTS.md/CLAUDE.md 설계
• MCP 서버 구성 및 도구 스키마 설계
• RAG 파이프라인 설계 (청킹 전략, 검색 전략, 재순위)
• 에이전트 메모리 아키텍처 설계 (단기/장기 메모리)
• 멀티에이전트 오케스트레이션에서 정보 흐름 설계
• 컨텍스트 품질 평가 프레임워크 구축

SDG Group은 2026년 전망에서 이렇게 분석합니다.

2026년에 프롬프트 엔지니어 역할은 확고히 자리잡겠지만, 새로운 관점에서: AI 에이전트가 컨텍스트를 더 잘 이해하고 설계된 작업을 효율적으로 자동화할 수 있도록 돕는 핵심 역할로.

이 분석이 시사하는 것은, 프롬프트 엔지니어링이 사라지는 것이 아니라 Context Engineering이라는 더 넓은 분야의 일부로 흡수 된다는 것입니다.

실무에서의 의미 -- 무엇이 달라지는가

그렇다면 Context Engineering이라는 렌즈를 통해 우리의 일상적인 AI 활용이 어떻게 달라질까요?

CLAUDE.md를 "한 번 쓰고 잊는 파일"이 아니라 "살아있는 시스템"으로 관리하게 됩니다. 에이전트가 실패할 때마다 원인을 분석하고 컨텍스트 파일을 업데이트하는 반응형 유지보수가 핵심입니다. 분기별 검토로 오래된 항목을 제거하고, 모순된 규칙을 해결합니다.

"더 많이 넣으면 더 좋다"는 직관을 버리게 됩니다. Optimal density, 즉 최적 밀도가 목표입니다. 필요한 정보만 정확하게 선택하고, 불필요한 정보는 과감히 제외합니다. 이것은 비용 절감으로도 직결됩니다 -- 불필요한 토큰 제거는 API 비용과 지연시간을 모두 줄입니다.

정보의 위치에 신경 쓰게 됩니다. 중요한 규칙은 컨텍스트의 시작과 끝에 배치하고, 참고 자료는 중간에 배치합니다. 이것만으로도 AGENTS.md 위치 조정으로 스타일 위반이 35~40% 감소한 Faros AI의 사례처럼 유의미한 개선을 얻을 수 있습니다.

에이전트에게 "무엇을 말할까"보다 "무엇을 볼 수 있게 할까"를 먼저 고민하게 됩니다. MCP 서버를 어떤 조합으로 연결할지, RAG 파이프라인을 어떻게 설계할지, 에이전트 간 정보 흐름을 어떻게 구성할지 -- 이것들이 프롬프트 문구를 다듬는 것보다 훨씬 큰 영향을 미칩니다.

마무리 -- 컨텍스트는 유한한 자원입니다

Anthropic의 가이드가 전하는 핵심 메시지로 마무리하겠습니다. 컨텍스트는 유한한 자원입니다. RAM이 유한하듯, 컨텍스트 윈도우도 유한합니다. 무엇을 넣고 무엇을 뺄지, 어디에 배치하고 언제 불러올지를 설계하는 것이 AI 에이전트 시대의 핵심 역량이 되고 있습니다.

Context Engineering은 완전히 새로운 것이 아닙니다. CLAUDE.md를 작성하고, MCP 서버를 구성하고, RAG 파이프라인을 설계하는 우리는 이미 Context Engineering을 하고 있었습니다. 달라진 것은 이 행위들에 이름이 붙었고, 체계가 생기기 시작했다는 점입니다. 그리고 역사적으로, 이름이 붙는 순간이 분야가 본격적으로 성장하는 시작점이었습니다.

프롬프트를 잘 쓰는 것은 여전히 중요합니다. 하지만 그것만으로는 부족한 시대가 왔습니다. 이제 질문은 "어떻게 물어볼까"가 아니라, "모델이 올바른 답을 낼 수 있는 환경을 어떻게 설계할까" 입니다.