프롬프트에서 컨텍스트로
같은 에이전트에게 같은 질문을 해도 답이 달라진다. 모델이 같아도 그렇다. 에이전트가 무엇을 보고 있는지에 따라 달라진다. 어떤 도구를 쓸 수 있는지에 따라서도 달라진다.
Andrej Karpathy는 LLM을 추론 엔진이라고 설명했다. 주어진 맥락을 바탕으로 추론한다는 뜻이다. LLM은 대규모 언어 모델(Large Language Model)이다. 컨텍스트 윈도우는 에이전트의 작업 책상에 비유할 수 있다. 책상 위에 무엇을 놓느냐가 결과를 바꾼다[1].
| 구분 | 프롬프트 엔지니어링 | Context Engineering |
|---|---|---|
| 범위 | 지시문과 예시의 설계 | 지시문을 포함한 전체 맥락 설계 |
| 산출물 | 작업 지시와 예시 | 정보 검색·기억·도구·이력 관리 체계 |
| 수행자 | 사용자·개발자 | 개발자·시스템 설계자·운영팀 |
| 목표 | 원하는 응답 유도 | 여러 단계에서 일관된 업무 수행 |
| 수준 | 지시문 설계 기술 | 맥락을 구성·관리·평가하는 기술 |
컨텍스트의 5가지 구성 요소
에이전트에 제공하는 맥락은 실무적으로 5가지로 나눌 수 있다[8]. 반드시 이 순서로 구성되는 것은 아니다.
다섯 요소를 다 채우는 것이 목표가 아니다. Anthropic은 컨텍스트 엔지니어링을 정보를 선택하고 압축하고 갱신하는 일로 설명한다[8]. 넣을 수 있는 것을 다 넣는 일이 아니라는 뜻이다.
근거도 있다. 긴 입력의 중간에 중요한 정보가 놓이면 모델이 그것을 놓칠 수 있다[7]. 정보를 더 넣는 것과 그 정보가 실제로 쓰이는 것은 다른 문제다. 그래서 선택이 기술이 된다.
MCP — 컨텍스트 통합의 표준
Anthropic이 2024년 11월 모델 컨텍스트 프로토콜(MCP, Model Context Protocol)을 공개했다. AI와 외부 데이터·도구를 연결하는 방법을 표준화한 공개 규약이다[2].
MCP의 3가지 기본 기능은 이렇다.
GitHub과 Slack, 데이터베이스를 공통 방식으로 연결할 수 있다. 그러나 MCP가 통합 문제를 다 풀어 주지는 않는다. 권한 관리와 데이터의 의미, 정보의 정확성은 별도로 설계해야 한다.
RAG vs GraphRAG vs Fine-tuning
기업이 가장 자주 묻는 질문은 "어떤 방식을 써야 하나"다. GraphRAG는 문서에서 개체와 관계를 뽑아 그물망으로 검색하는 방식이다.
| 차원 | RAG | GraphRAG | Fine-tuning |
|---|---|---|---|
| 지식 업데이트 | 검색 대상 갱신 | 그래프·색인 갱신 | 모델 재학습 또는 외부 검색 병행 |
| 최적 용도 | 문서 검색, 사실 조회 | 관계 분석, 여러 단계의 정보 연결 | 문체·출력 형식·특정 작업 적응 |
| 환각 위험 | 검색 품질에 좌우 | 그래프·근거 품질에 좌우 | 학습 품질에 좌우 |
| 설명 가능성 | 원문 출처 추적 가능 | 관계와 근거 추적 가능 | 판단 근거 확인이 어려울 수 있음 |
| 기업 적합도 | 문서 중심 업무 | 관계가 중요한 복합 업무 | 반복적·특화된 업무 |
실전 기준은 이렇다. 새로운 기업 정보는 RAG다. 관계를 따라 분석해야 하는 정보는 GraphRAG다. 조직도와 공급망이 그렇다.
일정한 문체와 출력 형식은 Fine-tuning이다. 반복적인 작업 방식도 그렇다. 세 가지는 서로 배타적이지 않다. 함께 쓸 수도 있다[3].
엔터프라이즈 실전: 누가 하고 있는가
Klarna가 2024년 2월에 성과를 공개했다. AI 고객 상담 시스템이 상담원 700명분의 업무를 처리했다. 실제로 700명을 해고했다는 뜻은 아니다. 고객의 주문·결제 정보와 상담 절차를 연결했다. 평균 해결 시간은 11분에서 2분 미만으로 줄었다[4].
Morgan Stanley는 내부 지식 검색 시스템을 만들었다. GPT-4를 썼다. 내부 문서 약 10만 건이 대상이다. 금융 상담사가 필요한 정보를 찾도록 돕는다.
상담사 약 1만 6천 명을 대상으로 도입했다. 핵심은 문서를 많이 넣는 것이 아니다. 검증된 자료를 검색하는 것이다. 답변의 정확성을 꾸준히 평가하는 것이다[5].
두 사례의 공통점은 정보의 양이 아니다. 어떤 정보를 어떤 업무 절차에 연결했는지다. 그리고 그 답이 맞는지 계속 확인했는지다.
JK's Take
Context Engineering은 기술 용어지만, 본질은 경영학이다.
30년간 기업에서 데이터 프로젝트를 해왔다. 성공한 프로젝트와 실패한 프로젝트의 차이는 자주 같은 곳에서 나타났다. "어떤 정보를 어떤 순서로 의사결정자에게 전달했느냐." Context Engineering도 이 질문에서 출발한다.
에이전트의 컨텍스트 윈도우는 의사결정자의 보고서와 같다. 불필요한 정보를 넣으면 핵심이 묻힌다. 필요한 정보가 빠지면 판단이 틀어진다. 출처와 시점이 불분명하면 잘못된 결론에 이를 수 있다.
컨텍스트 윈도우가 100만 토큰까지 늘었다. 그렇다고 "더 많이 넣으면 된다"가 되지 않는다. 많이 받아들이는 능력과 정확히 쓰는 능력은 다르다. 더 많이 넣을수록 더 정교한 설계가 필요하다. 이것이 엔지니어링이 되어야 하는 이유다.
What to Watch
— MCP 생태계가 확장되고 있다. 기업 시스템(ERP, CRM, HR)을 잇는 공통 규약이 퍼진다. 앞으로 볼 것은 연결 가능한 도구의 수가 아니다. 접근 권한과 정보 품질이다.
— 프롬프트 캐싱의 경제학을 보라. Anthropic은 반복되는 입력을 저장해 재활용하는 방식을 내놨다. 입력 처리 비용을 최대 90% 줄일 수 있다고 밝혔다. 다만 모든 요청에 적용되는 수치는 아니다. 공통 지시문과 변하지 않는 정보를 어떻게 재사용하느냐가 비용을 좌우한다[6].
— GraphRAG의 성숙도를 지켜보라. Microsoft가 공개한 GraphRAG는 문서의 개체와 관계를 연결해 복합적인 질문에 답한다. 기업 적용에서는 그래프 구축 비용이 과제다. 정보 갱신과 운영 관리도 그렇다[3].
— "Lost in the Middle"이 풀리는지 보라. 긴 문서의 중간에 있는 정보를 AI가 놓치는 현상이다. 연구에 따르면 정보의 위치에 따라 답변 정확도가 달라질 수 있다. 무조건 길게 넣기보다 필요한 정보를 찾아 배치하는 설계가 중요하다[7].
References
[1] Andrej Karpathy & Tobi Lütke, "Context Engineering Discussion", 2025-06. https://x.com/karpathy/status/1937902205765607626 — 컨텍스트 엔지니어링은 모델의 다음 작업에 필요한 지시문, 예시, 검색 결과, 도구와 이력을 구성하는 기술이다. 작업 책상 비유는 원문 직접 인용이 아니라 필자의 설명이다.
[2] Anthropic, "Introducing the Model Context Protocol", 2024-11-25. https://www.anthropic.com/news/model-context-protocol — MCP는 AI 애플리케이션과 외부 시스템을 연결하는 공개 규약이다. 기본 기능은 Resources, Tools, Prompts다. 기업의 의미 체계와 정보 품질을 자동으로 보장하지는 않는다.
[3] Microsoft Research, "From Local to Global: A Graph RAG Approach to Query-Focused Summarization", 2024. https://www.microsoft.com/en-us/research/publication/from-local-to-global-a-graph-rag-approach-to-query-focused-summarization/ — GraphRAG는 문서에서 개체와 관계를 추출하고 이를 활용해 검색과 답변을 구성한다. 모든 업무에서 일반 RAG보다 우수한 것은 아니다.
[4] Klarna, "AI Assistant Handles Two-Thirds of Customer Service Chats in Its First Month", PR Newswire, 2024-02-27. https://www.prnewswire.com/news-releases/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month-302072744.html — 700명은 실제 해고 인원이 아니라 업무량 환산치다. 평균 해결 시간은 기존 11분에서 2분 미만으로 개선됐다고 발표했다.
[5] OpenAI, "Morgan Stanley Uses AI Evals to Shape the Future of Financial Services". https://openai.com/index/morgan-stanley/ — 내부 문서 약 10만 건에 대한 검색 및 평가 체계를 구축한 사례다. 기존 원문의 검색시간 20~30% 단축 수치는 확인되지 않아 제외했다.
[6] Anthropic, "Prompt Caching with Claude". https://claude.com/blog/prompt-caching — 반복되는 입력을 재사용하면 긴 프롬프트에서 최대 90%의 비용을 절감할 수 있다고 설명한다. 실제 절감액은 캐시 적중률과 요금 조건에 따라 달라진다.
[7] Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", Transactions of the Association for Computational Linguistics, 2024. https://aclanthology.org/2024.tacl-1.9/ — 긴 입력의 중간에 관련 정보가 있을 때 일부 모델의 검색·활용 성능이 저하되는 현상을 분석했다.
[8] Anthropic, "Effective Context Engineering for AI Agents", 2025-09-29. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — 컨텍스트 엔지니어링을 지시문 작성의 확장으로 설명한다. 모델에 제공할 정보를 선택하고, 압축하고, 필요할 때 갱신하는 접근법을 제시한다.
