1. 완벽한 프롬프트를 썼는데 AI는 정반대 코드를 생성했습니다
어제 회의에서 결정된 내용이 있습니다. "이번 API는 Express 대신 Fastify로 간다." 개발자는 이를 AI에게 설명했고, AI는 명확히 이해했습니다. 그런데 다음 날 새 세션을 열자, AI는 Express 기반 코드를 자신 있게 생성했습니다. 어제의 결정은 어디에도 없습니다.
고객 서비스 봇을 운영하는 기업도 비슷한 경험을 합니다. 고객이 3분 전에 이미 설명한 내용을 AI가 다시 묻습니다. 완벽하게 작성한 시스템 프롬프트에도 불구하고, 봇은 엉뚱한 제품 정보를 제공합니다. 담당자는 프롬프트를 수십 번 고쳐봤지만 결과는 달라지지 않습니다.
이 실패들은 프롬프트가 나빠서가 아닙니다. 프롬프트를 둘러싼 정보 환경 전체가 설계되지 않았기 때문입니다. 이것이 2025년 AI 업계가 "Prompt Engineering에서 Context Engineering으로" 무게 중심을 이동한 이유입니다.
이 글은 Context Engineering이 무엇인지, 왜 등장했는지, 실전에서 어떻게 적용하는지를 처음부터 차근차근 설명합니다.
2. Context Engineering이란 무엇인가 — 탄생 배경
2025년 6월, Tesla AI 전 총괄이자 OpenAI 공동 창립자인 Andrej Karpathy가 X(구 트위터)에 이런 글을 올렸습니다.
"'프롬프트 엔지니어링'보다 '컨텍스트 엔지니어링'이라는 표현이 훨씬 정확합니다. 모든 실제 LLM 애플리케이션에서 이것은 다음 단계를 위해 컨텍스트 윈도우를 올바른 정보로 채우는 섬세한 기술이자 과학입니다."
— Andrej Karpathy, 2025년 6월 25일
Shopify CEO Tobi Lütke도 바로 이에 동조했습니다. "이 용어가 핵심 스킬을 훨씬 잘 설명합니다. 작업이 LLM에게 그럴듯하게 해결 가능하도록 모든 맥락을 제공하는 기술." 이 두 사람의 공개 지지가 업계에 확산되면서, 2025년 10월 Gartner는 공식적으로 이렇게 선언했습니다.
"Context Engineering is in, and Prompt Engineering is out."
— Gartner, 2025년 10월
Gartner의 공식 정의는 이렇습니다. "AI 시스템이 의도를 이해하고, 더 나은 결정을 내리고, 수동 프롬프트에 의존하지 않고 정렬된 결과를 제공할 수 있도록 관련 데이터, 워크플로우, 환경을 설계하고 구조화하는 것."
단순히 표현 방식의 변화가 아닙니다. AI 작업의 무게 중심 자체가 '무엇을 말하느냐'에서 '무엇을 보여주느냐'로 이동한 것입니다.
3. 왜 Prompt Engineering만으로는 한계가 생겼을까
Karpathy는 LLM을 CPU에 비유했습니다. 그렇다면 컨텍스트 윈도우는 RAM입니다. 운영체제가 RAM에 무엇을 올릴지 세심하게 관리하듯, Context Engineering은 AI의 작업 메모리에 무엇을 넣을지 설계하는 일입니다. 이 비유를 기반으로 두 개념의 차이를 정리하면 명확해집니다.
단발성 질문에는 Prompt Engineering으로 충분합니다. 그러나 멀티턴 대화, 에이전트, 장기 프로젝트, 기업 서비스처럼 AI가 여러 세션에 걸쳐 일관되게 작동해야 하는 상황에서는 프롬프트 하나로 제어할 수 있는 범위가 근본적으로 부족합니다. 한 가지 중요한 점을 먼저 짚고 넘어가겠습니다.
⚠️ 오해 주의: Context Engineering이 Prompt Engineering을 대체하거나 무력화하는 것이 아닙니다. 모델 자체의 추론 능력과 좋은 프롬프트는 여전히 중요합니다. Context Engineering은 이를 대체하는 것이 아니라, 실제 시스템에서 그 성능을 제대로 끌어내기 위한 상위 레이어에 가깝습니다. 프롬프트는 Context Engineering의 한 구성 요소로 흡수됩니다.
| 구분 | Prompt Engineering | Context Engineering |
|---|---|---|
| 핵심 질문 | 무엇을 어떻게 말하는가 | AI에게 무엇을 보여주는가 |
| 작업 단위 | 단일 지시문 (문장·문단) | 전체 정보 환경 (시스템) |
| 비유 | 배우에게 대사를 주는 것 | 대사·무대·조명·스토리보드 전체를 설계하는 것 |
| 적용 범위 | 단발성 질의·응답에 효과적 | 멀티턴·에이전트·프로덕션 시스템에 필수 |
| 실패 원인 | 지시가 불명확하거나 모호함 | 잘못된 정보·과부하·맥락 오염 |
| 주요 스킬 | 문장 작성, 언어적 설득 | 정보 아키텍처, 시스템 설계 |
💡 핵심 통찰
Prompt Engineering이 사라지는 것이 아닙니다. Prompt는 Context Engineering의 한 구성 요소로 흡수됩니다. 아무리 완벽한 프롬프트를 써도, 주변 컨텍스트 윈도우가 관련 없는 정보로 오염되어 있거나 필요한 정보가 빠져 있다면 AI는 여전히 엉뚱한 답을 냅니다.
아래 비교표에서 두 개념의 차이를 한눈에 정리할 수 있습니다. 특히 '실패 원인'과 '주요 스킬' 항목에 집중해보면, 두 접근법이 완전히 다른 문제를 해결하려 한다는 것을 알 수 있습니다.
4. Context Engineering의 5가지 핵심 구성 요소
Context Engineering은 추상적인 개념이 아닙니다. LLM이 응답을 생성할 때 컨텍스트 윈도우에 담기는 정보는 다음 5가지 요소로 구성됩니다. 이 요소들을 어떻게 선택하고, 어떻게 구조화하고, 얼마나 압축해서 넣느냐가 Context Engineering의 실체입니다.
① 시스템 프롬프트 (System Prompt)
AI의 역할, 행동 방식, 제약 조건을 정의하는 지시문입니다. 전통적 의미의 "프롬프트 엔지니어링"이 주로 다루던 영역이지만, Context Engineering에서는 이것이 5요소 중 하나일 뿐입니다. 시스템 프롬프트가 아무리 완벽해도, 나머지 4가지가 부실하면 AI는 제대로 작동하지 않습니다.
② 외부 지식 주입 — RAG (Retrieval-Augmented Generation)
LLM의 학습 데이터 이후 생성된 정보나, 기업 내부 문서처럼 모델이 모르는 정보를 실시간으로 검색해 컨텍스트에 주입하는 방식입니다. 핵심은 "모든 문서를 다 넣는 것"이 아니라 지금 이 질문에 관련된 것만 정확히 골라 넣는 것입니다. 관련 없는 정보가 들어오면 오히려 성능이 떨어집니다.
③ 메모리 (Memory)
현재 세션의 대화 이력(단기 메모리)과, 이전 세션에서 저장된 사용자 선호·프로젝트 맥락(장기 메모리)을 컨텍스트에 포함하는 것입니다. 앞서 입문편에서 다뤘듯 LLM은 기본적으로 Stateless이므로, 이 메모리 계층이 없으면 AI는 매번 처음부터 시작합니다. Context Engineering에서 메모리 설계는 빠질 수 없는 핵심 요소입니다.
④ 툴 정의 (Tools)
AI가 호출할 수 있는 함수·API·외부 서비스의 목록과 사용법을 컨텍스트에 포함합니다. 검색 도구, 계산기, 데이터베이스 조회, 외부 서비스 연동 등이 여기에 해당합니다. 연구에 따르면 툴 설명을 RAG로 관리하고 30개 이하로 유지했을 때 툴 선택 정확도가 3배 향상됩니다.
⑤ 구조화된 출력 형식 (Structured Outputs)
AI가 생성해야 할 출력의 형식(JSON 스키마, 특정 포맷 등)을 컨텍스트에 명시합니다. 에이전트 파이프라인에서 AI의 출력이 다음 단계의 입력으로 사용될 때, 형식이 불일치하면 전체 시스템이 오작동합니다. 아래처럼 출력 형식을 사전에 정의하고 주입하는 것이 Context Engineering의 중요한 부분입니다.
{
"task_type": "customer_complaint",
"priority": "high",
"deadline": "2026-05-15",
"owner": "customer_support",
"requires_escalation": true
}
이 형식이 컨텍스트에 정의되어 있으면 AI는 항상 이 구조로 응답합니다. 다음 에이전트가 이 JSON을 받아 자동으로 티켓을 생성하거나 담당자에게 알림을 보내는 파이프라인이 안정적으로 작동합니다.
5. 왜 95%의 기업 AI 파일럿이 실패하는가 — Context의 부재
2025년 7월, MIT Media Lab의 Project NANDA(Networked Agents and Decentralized Architecture)가 발표한 보고서 「The GenAI Divide: State of AI in Business 2025」는 AI 업계에 충격을 줬습니다. 300개 이상의 공개 AI 배포 사례 검토, 52건의 구조적 인터뷰, 153명의 시니어 리더 설문을 기반으로 한 이 연구의 결론은 명확했습니다.
GenAI 파일럿의 95%
측정 가능한 비즈니스 성과(P&L 영향)를 내지 못함
출처: MIT Project NANDA, 「The GenAI Divide: State of AI in Business 2025」(2025년 7월)
보고서는 실패 원인을 이렇게 요약했습니다. "핵심 장벽은 인프라도, 규제도, 인재도 아닙니다. 바로 학습의 부재입니다. 대부분의 GenAI 시스템은 피드백을 보존하거나, 맥락에 적응하거나, 시간이 지남에 따라 개선되지 않습니다." Fortune이 보도한 이 연구 내용에서 리드 저자 Aditya Challapally는 이렇게 밝혔습니다. "기업들은 거의 어디에서나 자체 도구를 구축하려 했지만, 데이터는 외부에서 구매한 솔루션이 훨씬 나은 결과를 냈다고 보여줍니다."
Box CEO Aaron Levie는 이를 더 직접적으로 표현했습니다. "Context Engineering은 대부분의 조직에서 AI 에이전트 도입의 핵심 병목입니다. 주어진 워크플로우에 맞는 올바른 컨텍스트를 제공하는 경쟁에서 이기느냐 지느냐가 기업 AI의 승패를 가릅니다."
기업 현장에서 Context 실패가 나타나는 세 가지 전형적인 패턴이 있습니다.
🚨 Context 과부하 (Context Overload)
관련성을 따지지 않고 모든 문서를 컨텍스트에 밀어 넣습니다. 컨텍스트 윈도우는 방대해졌지만, AI는 정작 중요한 정보를 노이즈 속에서 찾지 못합니다.
🚨 맥락 오염 (Context Poisoning)
OWASP이 2026년 최대 에이전트 리스크로 꼽은 문제입니다. 오래된 정보, 상충하는 사실, 잘못된 데이터가 컨텍스트에 섞여 들어가 AI가 자신감 있게 틀린 답을 냅니다. "어제 Redis를 쓰기로 했다"는 오래된 메모가 오늘의 의사결정을 오염시키는 식입니다.
🚨 컨텍스트 단절 (Context Disconnect)
세션 간, 에이전트 간, 도구 간 컨텍스트가 공유되지 않아 AI가 매번 처음부터 추론합니다. 대화 이력·이전 결정·사용자 프로필이 다음 단계로 이어지지 않습니다.
6. Context Engineering 실전 사례와 적용 방법
Context Engineering이 실제 현장에서 어떻게 차이를 만드는지, 두 가지 대표 사례로 먼저 살펴보겠습니다.
| 사례 | Context 미적용 (Before) | Context Engineering 적용 (After) |
|---|---|---|
| 고객 서비스 봇 | 고객이 3분 전에 설명한 주문 번호를 다시 묻고, 단종된 제품 정보를 안내함 | 세션 메모리로 대화 이력 유지, RAG로 최신 제품 DB를 실시간 주입, 고객 프로필로 선호 이력 반영 |
| 코딩 에이전트 | 어제 결정한 "Express → Fastify 전환"을 새 세션에서 잊고 Express 코드 생성 | CLAUDE.md에 기술 스택 결정사항 기록, Auto Dream으로 세션 간 일관성 유지, 아키텍처 결정 로그 자동 갱신 |
Context Engineering은 개발자만의 영역이 아닙니다. AI를 업무에 적극 활용하는 일반 사용자도 이 원리를 적용하면 AI의 품질을 크게 끌어올릴 수 있습니다.
🙋 일반 사용자 수준
• 커스텀 지시사항 활용: AI에게 자신의 직업, 역할, 선호 스타일, 자주 다루는 주제를 한 번에 등록해두면 매번 설명 없이도 맥락이 주입됩니다.
• 관련 자료 직접 첨부: 질문할 때 관련 문서, 이전 결과물, 참고 자료를 함께 붙여넣는 것 자체가 수동 RAG입니다.
• 세션 맥락 정리문 작성: 긴 프로젝트를 새 세션에서 이어갈 때 "현재까지 진행 상황 요약:"으로 시작하는 맥락 주입문을 첫 메시지에 넣습니다.
👨💻 개발자·빌더 수준
• 동적 컨텍스트 주입: 사용자 쿼리 분석 → 관련 문서 검색(RAG) → 사용자 프로필 로드 → 이전 대화 요약 주입의 파이프라인을 구현합니다.
• 컨텍스트 압축·요약: 긴 대화 이력을 그대로 넣지 말고 핵심만 추출해 압축된 형태로 주입합니다. 토큰 비용을 줄이면서 성능을 유지합니다.
• 컨텍스트 신선도 관리: 오래된 정보, 모순된 정보를 주기적으로 정리해 Context Poisoning을 방지합니다. Claude Code의 Auto Dream 기능이 이 역할을 자동화합니다.
🏢 기업 아키텍처 수준
• 컨텍스트를 인프라로: 데이터 거버넌스, 접근 권한, 문서 최신화가 곧 AI 컨텍스트 품질 관리입니다. 데이터 엔지니어링과 AI 엔지니어링이 합류하는 지점입니다.
• MCP(Model Context Protocol) 도입: Anthropic이 주도하는 MCP는 AI 에이전트가 다양한 데이터 소스·툴과 표준화된 방식으로 컨텍스트를 주고받는 프로토콜입니다. 다음 시리즈에서 자세히 다룹니다.
7. 2026년 이후 — Context Engineering은 어디로 가는가
2026년 초 기준으로, Context Engineering은 이미 정착된 개념을 넘어 다음 단계로 진화하고 있습니다. GitHub의 Awesome-Context-Engineering 서베이는 2026년 3월 시점에서 이렇게 기록했습니다. "무게 중심이 '최고의 프롬프트를 어떻게 담느냐'에서 에이전트 시스템이 런타임 상태, 메모리, 툴, 프로토콜, 장기 실행을 어떻게 관리하느냐로 이동하고 있다."
주목할 세 가지 방향이 유력한 흐름으로 부상하고 있습니다.
① 자기 진화형 컨텍스트 (ACE: Agentic Context Engineering)
에이전트가 스스로 자신의 컨텍스트 구성을 업데이트하는 방식이 사실상 표준처럼 채택되기 시작했습니다. 모델 성능 피드백을 바탕으로 시스템 프롬프트를 자동 재작성하고, 어떤 도구와 메모리를 어떤 상황에 활용할지 스스로 학습하는 구조입니다. 다만 아직 업계 전반의 합의가 완성된 것은 아니며, 활발히 발전 중인 분야입니다.
② 계층적 메모리 아키텍처의 표준화
단기·작업·장기 메모리의 명확한 계층 분리와 각 계층 간 자동 요약·승격·삭제 메커니즘이 대표적인 설계 패턴으로 자리잡는 중입니다. 다음 시리즈에서 다룰 Mem0, Zep, Letta가 이 분야의 선두 프레임워크로 주목받고 있습니다.
③ Harness Engineering으로의 확장 가능성
2026년 이후 일부 연구자들은 한 단계 더 나아간 개념인 'Harness Engineering'을 제시하고 있습니다. Context Engineering이 세션 수준의 정보 아키텍처라면, Harness Engineering은 툴·메모리·제약·피드백 루프 전체를 포함한 에이전트 시스템 환경 설계입니다. Prompt → Context → Harness로 이어지는 계층화가 논의되고 있으며, 향후 방향으로 지켜볼 만한 흐름입니다.
📌 결론
Context Engineering은 AI를 쓰는 모든 사람의 핵심 스킬이 됐습니다. 프롬프트를 잘 쓰는 것만으로 AI를 잘 쓰는 시대는 끝났습니다. AI에게 무엇을 보여줄지, 어떤 정보를 언제 어떻게 주입할지를 설계하는 능력이 2026년 AI 경쟁력의 본질입니다. Gartner가 2026년 말까지 기업 애플리케이션 40%에 AI 에이전트가 내장될 것으로 전망하는 상황에서, 이 기술을 먼저 체계화하는 것이 분명한 선점 기회입니다.
✅ Context Engineering 셀프 진단 체크리스트
☑ AI에게 역할·배경·제약을 정의한 시스템 프롬프트가 설계되어 있는가?
☑ 질문·작업에 필요한 관련 문서·데이터를 실시간으로 주입하는 메커니즘이 있는가?
☑ 이전 세션의 중요 맥락이 다음 세션에 전달되는 메모리 구조가 있는가?
☑ 컨텍스트에 오래되거나 모순된 정보가 들어가는 것을 방지하는 신선도 관리가 있는가?
☑ AI 출력이 다음 단계에서 사용될 수 있도록 구조화된 형식이 지정되어 있는가?
📌 핵심 정리
- Context Engineering은 LLM이 응답을 생성할 때 컨텍스트 윈도우에 담기는 전체 정보 환경을 설계하는 기술이다.
- Andrej Karpathy(2025.6.25)가 명명하고 Gartner(2025.10)가 공식화했다. "Context Engineering is in, Prompt Engineering is out."
- Prompt Engineering은 사라지지 않는다. Context Engineering의 하위 구성 요소로 흡수되며, 모델 성능을 실제로 끌어내기 위한 상위 레이어다.
- 핵심 구성 요소는 시스템 프롬프트·RAG·메모리·툴·구조화 출력 5가지다.
- MIT Project NANDA 「The GenAI Divide」(2025년 7월, 300+ 사례 분석) 기준 95%의 기업 GenAI 파일럿이 P&L 성과를 내지 못했으며, 핵심 원인은 맥락 학습과 통합의 부재였다.
- Context 실패의 세 패턴은 과부하(Overload), 오염(Poisoning), 단절(Disconnect)이며, 이를 방지하는 설계가 Context Engineering의 핵심이다.
❓ 자주 묻는 질문 (FAQ)
Context Engineering을 배우면 Prompt Engineering은 더 이상 필요 없나요?
아닙니다. Prompt Engineering은 사라지는 것이 아니라 Context Engineering의 하위 구성 요소로 흡수됩니다. 좋은 시스템 프롬프트를 설계하는 능력은 여전히 중요합니다. 다만 프롬프트 하나로 AI를 완전히 제어할 수 있다는 생각에서 벗어나, 정보 환경 전체를 설계하는 관점으로 확장해야 합니다.
Context Engineering은 개발자만 해당되는 개념인가요?
아닙니다. 커스텀 지시사항 활용, 대화 시작 시 배경 정보 제공, 관련 문서 첨부 등 일반 사용자도 Context Engineering의 원리를 적용할 수 있습니다. 개발자는 RAG 파이프라인·메모리 시스템 설계로 확장하고, 기업은 데이터 거버넌스·MCP 아키텍처로 확장하는 것입니다. 원리는 동일합니다.
컨텍스트 윈도우가 100만 토큰으로 커졌으니 그냥 다 넣으면 되지 않나요?
오히려 역효과가 날 수 있습니다. 관련 없는 정보가 많이 들어올수록 AI가 중요한 정보를 찾아내는 능력이 떨어집니다. 연구에 따르면 문서를 무차별적으로 채우는 것보다 관련성 높은 정보만 선별해 넣는 것이 성능이 더 높습니다. Context Engineering의 핵심 기술 중 하나가 바로 '무엇을 넣지 않을지'를 결정하는 선택과 필터링입니다.
Context Engineering을 시작하기 위한 가장 현실적인 첫 단계는 무엇인가요?
가장 쉬운 첫 단계는 사용하는 AI 서비스의 '커스텀 지시사항' 기능을 채우는 것입니다. 자신의 직업, 역할, 자주 하는 작업 유형, 선호하는 출력 형식을 명확히 적어두면 즉시 컨텍스트 품질이 올라갑니다. 개발자라면 Claude Code의 CLAUDE.md 파일에 프로젝트 맥락을 작성하는 것이 ROI가 가장 높은 첫 단계입니다.
시리즈 다음 편
AI 에이전트가 서로 연결되려면?
MCP(Model Context Protocol) 완벽 이해 — AI 에이전트 연결 표준 (시리즈 ②)
Anthropic이 주도하는 에이전트 연결 표준이 왜 게임 체인저인지 다음 글에서 다룹니다.
📚 AI 메모리·컨텍스트 시리즈(순차적으로 업로드 예정입니다)
✅ AI는 왜 대화가 끝나면 모든 걸 잊는가 — 컨텍스트 윈도우의 구조적 한계 (입문편)
✅ Claude Dreaming — AI도 잠을 자야 똑똑해진다 (브릿지편)
▶ 현재 글: Context Engineering이란 — Prompt Engineering 이후의 시대 (시리즈 ①)
[[관련 정보: MCP(Model Context Protocol) 완벽 이해 — AI 에이전트 연결 표준 (시리즈 ②)]]
[[관련 정보: AI 에이전트 메모리 프레임워크 비교 — Mem0 vs Zep vs Letta vs MemGPT (시리즈 ③)]]
[[관련 정보: RAG(벡터DB)와 AI 에이전트 메모리의 차이 — 무엇을 선택해야 하는가 (시리즈 ④)]]
'AI' 카테고리의 다른 글
| AI는 왜 대화가 끝나면 모든 걸 잊는가 (1) | 2026.05.23 |
|---|---|
| Google I/O 2026 한국 사용자 완전 정리 — Gemini 3.5부터 AI 안경 출시 일정까지 (0) | 2026.05.22 |
| Multi-Agent 시스템 설계 — CrewAI + LangGraph 실전 가이드 (0) | 2026.05.21 |
| AI 서비스 아키텍처 — LangChain Agent + 멀티모달 실전 (0) | 2026.05.19 |
| RAG 만들었는데 왜 이상할까? — 벡터 DB·검색 고도화로 실무 수준 만들기 (1) | 2026.05.19 |