컨텍스트 엔지니어링이란 무엇인가
2025년 6월, 전 OpenAI 연구원 안드레이 카르파티(Andrej Karpathy)는 X(트위터)에 이런 글을 남겼다.
컨텍스트 엔지니어링은 다음 단계에 필요한 딱 맞는 정보로 컨텍스트 윈도우를 채우는 섬세한 기술이자 과학이다.
이처럼 컨텍스트 엔지니어링은 모델에 문서를 많이 넣는 작업이 아니다. LLM의 컨텍스트 윈도우에 무엇을 넣고 무엇을 버릴지 설계하는 작업이다. 비슷한 맥락에서 AI 애플리케이션 개발 도구를 만드는 LangChain은 이를 컴퓨터에 비유한다.
“LLM은 CPU이고, 컨텍스트 윈도우는 RAM이다. 운영체제가 CPU의 RAM에 무엇을 올릴지 관리하듯, 컨텍스트 엔지니어링도 같은 역할을 한다.”
아무리 RAM이 커도 필요한 것만 올려야 빠르게 동작하듯, 컨텍스트 윈도우(Context Window도 마찬가지다. 컨텍스트 윈도우에는 여러 종류의 정보가 들어갈 수 있다.
컨텍스트 윈도우에 들어갈 수 있는 것들
- 시스템 프롬프트: 역할, 제약, 출력 형식 등 고정 지시
- 대화 이력: 이전 질문과 답변의 흐름
- 검색 문서: RAG로 가져온 관련 문서나 단락
- 도구 출력: 함수 호출 결과, API 응답, 코드 실행 결과
- 사용자 입력: 현재 질문과 첨부 파일
- 메모리: 장기 기억으로 주입하는 요약 정보
이 중 어떤 것을 얼마만큼 어떤 순서로 넣는지가 응답 품질을 직접 좌우한다. 핵심은 정보량이 아니라 적합성이다.
왜 등장했는가
컨텍스트 엔지니어링이 주목받기 시작한 데는 두 가지 흐름이 맞물려 있다.
첫 번째는 컨텍스트 윈도우의 급격한 확장이다. 초기 GPT 계열 모델의 컨텍스트 윈도우는 수천 토큰 수준이었지만, 최근 모델들은 수십만에서 수백만 토큰을 한 번에 처리할 수 있게 됐다. 쉽게 말하면, LLM이 한 번에 읽을 수 있는 분량이 짧은 글 한 편 수준에서 책 한 권 이상 수준으로 늘어난 것이다. “넣을 수 있는 공간”이 커지자, 자연스럽게 “무엇을 어떻게 넣을지”가 새로운 문제가 됐다.
두 번째는 LLM의 활용 범위가 단순 텍스트 생성을 넘어 에이전트 시스템과 비즈니스 자동화 영역으로 확장되면서다. GPT-5, Gemini 2.5 Pro 같은 최신 모델들은 외부 API 호출, 멀티모달 데이터 이해, 실시간 상태 추적까지 가능해졌다. 이런 복잡한 작업에서는 프롬프트를 잘 작성하는 것만으로는 한계가 있다. LLM이 필요한 정보와 환경 속에서 작동하도록 설계하는 것이 중요해졌고, 이 영역을 컨텍스트 엔지니어링이라 부르기 시작했다.
프롬프트 엔지니어링과 무엇이 다른가
컨텍스트 엔지니어링의 등장은 프롬프트 엔지니어링을 대체하는 것이 아니라, 그 위에 쌓이는 자연스러운 진화에 가깝다. 차이를 더 구체적으로 보기 위해, 고객 문의를 처리하는 CS 챗봇을 예로 들어보자.
프롬프트 엔지니어링만 적용한 경우
“고객이 배송 관련 문의를 하면, 배송 조회 방법을 알려줘”와 같은 지시문을 작성하면 일반적인 응대는 가능하다. 그러나 고객이 “내 주문번호가 ABC1234인데, 지금 어디까지 왔나요?”라고 물으면 LLM은 정확한 답을 줄 수 없다. 외부 데이터에 접근하는 기능 자체가 없기 때문이다.
컨텍스트 엔지니어링을 적용한 경우
단순히 프롬프트를 작성하는 것을 넘어, 다음과 같은 정보 환경을 함께 설계하고 구축한다.
- 외부 데이터 연동: 고객 주문 DB와 배송 시스템 API를 LLM과 연결
- 워크플로우 설계: 주문번호 입력 시 배송 API를 자동 호출하도록 설계
- 동적 맥락 구성: API로 얻은 실시간 배송 상태를 컨텍스트에 주입해 답변 생성
프롬프트 엔지니어링이 “어떻게 답할지”를 설계한다면, 컨텍스트 엔지니어링은 “무엇을 알고 답할지”를 설계한다.
두 개념의 차이를 항목별로 정리하면 다음과 같다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 주요 목표 | 프롬프트 자체를 최적화해 출력 품질 향상 | AI 시스템의 전체적인 맥락과 정보 흐름을 설계 |
| 적용 범위 | 단일 질의-응답 등 단편적인 입출력에 초점 | 복잡한 AI 에이전트 시스템, 비즈니스 자동화 등 포괄적 시스템 설계 |
| 활용 기술 | 지시문 작성, Few-shot, 역할 부여 등 프롬프트 관련 기법 | RAG, Function Calling, MCP 등 외부 데이터 및 도구 연동 기술 |
| 비유 | ‘질문’을 잘 만드는 기술 | ‘정보 환경’ 자체를 설계하는 기술 |
컨텍스트가 실패하는 방식
컨텍스트를 많이 넣는다고 성능이 올라가는 것은 아니다. LangChain 블로그는 Drew Breunig의 분석을 인용해 컨텍스트 실패 유형을 네 가지로 정리한다.
Context Poisoning (컨텍스트 오염) 한 번 잘못 들어간 정보가 이후 대화 전체에 걸쳐 사실처럼 전달되는 현상이다. 챗봇이 첫 응답에서 환불 기간을 “30일”로 잘못 답했고, 이 내용이 대화 이력에 남으면 이후 질문에서도 모델은 그 잘못된 정보를 사실로 받아들인다.
Context Distraction (컨텍스트 산만) 관련 없는 정보가 너무 많이 섞이면 모델이 핵심 근거를 놓친다. 2025년 연구에 따르면 의미상 일관되지만 과제와 무관한 정보를 섞었을 때 주요 모델들의 성능이 평균 45% 이상 떨어졌다.
Context Confusion (컨텍스트 혼란) 불필요한 정보가 모델의 판단에 영향을 미치는 현상이다. 법률 챗봇에 판례 요약 수십 페이지를 넣었을 때, 핵심 조항보다 무관한 사례들이 답변을 흐리는 경우가 여기에 해당한다.
Context Clash (컨텍스트 충돌) 시스템 프롬프트와 사용자 입력 또는 검색 문서가 서로 상충하는 경우다. 시스템 프롬프트에는 “공식적인 어조로 답변해라”고 되어 있는데, 대화 이력에 “친근하게 말해줘”라는 요청이 남아 있다면 모델은 두 지시 사이에서 흔들린다.
어떻게 하는가
컨텍스트 엔지니어링 환경을 구축하기 위해서는 RAG(Retrieval-Augmented Generation), Function Calling, MCP(Model Context Protocol), LLM Orchestration 등 다양한 기술에 대한 이해와 적용이 필요하다.
접근 방식은 팀마다 다를 수 있지만, LangChain은 컨텍스트 엔지니어링 전략을 크게 네 가지 범주로 분류한다. 각 범주는 상황에 따라 독립적으로 적용할 수 있다.
쓰기(Write) / 선택(Select) / 압축(Compress) / 분리(Isolate)
1) 쓰기: 필요한 정보를 컨텍스트 밖에 저장해둔다
컨텍스트 윈도우는 유한하기 때문에, 모든 정보를 그 안에 담으려 하면 안 된다. 중요한 정보는 외부에 저장해두고 필요할 때 꺼내 쓰는 방식이 효율적이다.
에이전트가 장시간 작업을 수행할 때는 중간 메모(scratchpad)를 활용한다. Anthropic의 멀티 에이전트 연구 시스템은 이 방식을 이렇게 설명한다.
“LeadResearcher는 계획을 수립한 뒤 메모리에 저장한다. 컨텍스트 윈도우가 200,000 토큰을 초과하면 잘릴 수 있기 때문에, 계획을 보존하는 것이 중요하다.”
장기 기억(long-term memory)도 이 범주에 속한다. OpenAI의 ChatGPT, Cursor, Windsurf 같은 제품들이 세션 간 사용자 정보를 기억하는 방식이 여기에 해당한다.
2) 선택: 지금 필요한 정보만 컨텍스트 윈도우에 넣는다
질문과 관련 없는 문서는 넣지 않는 것이 원칙이다. 필터링 기준으로 고려할 수 있는 항목은 다음과 같다.
버전/날짜: 최신 문서 우선, 만료된 문서 제외
권한 scope: 요청자의 플랜/지역/역할에 맞는 문서만 포함
언어/지역: 질문 언어와 대상 서비스 지역 일치 여부
문서 상태: 초안, 폐기, 내부 전용 문서 제외
질문 재작성(query rewriting)도 선택 품질을 높이는 방법이다. 사용자가 입력한 짧고 구어체인 질문을 검색에 더 적합한 형태로 바꾸면, 더 관련성 높은 문서가 선택된다.
원본 질문: "환불 수수료 있나요?"
재작성: "국내 사용자 대상 2025년 환불 수수료 정책"
재정렬(re-ranking)도 선택 단계에서 활용할 수 있다. 검색된 문서 단락을 질문과의 관련도 순으로 다시 정렬하고 상위 몇 개만 컨텍스트에 포함하는 방식이다.
3) 압축: 긴 문서보다 핵심 근거만 남긴다
모든 문서를 통째로 넣으면 중요한 근거가 오히려 묻힌다. 질문과 직접 연결된 조항, 예외, 조건만 남기고 나머지를 버리면 토큰 사용량이 줄고 모델이 핵심 근거에 집중할 수 있다.
Anthropic의 Claude Code는 컨텍스트 윈도우의 95%를 초과하면 자동으로 대화 이력 전체를 요약하는 “auto-compact” 기능을 사용한다. 이처럼 압축 방식은 상황에 따라 다르게 접근할 수 있다.
- 요약: 대화 이력이나 도구 출력이 길어지면, 별도 모델로 핵심만 압축한 뒤 컨텍스트에 넣는다.
- 트리밍: 오래된 대화 이력을 순서대로 잘라내는 단순하지만 효과적인 방법이다.
4) 분리: 맥락을 분리해 각각 처리한다
하나의 에이전트가 모든 정보를 한 컨텍스트 윈도우 안에 담기 어려운 경우, 역할별로 나눠 처리하는 방식이 있다.
Anthropic의 멀티 에이전트 연구 시스템은 서브 에이전트들이 각자의 컨텍스트 윈도우를 갖고 병렬로 작업하는 방식을 택했다. 단일 에이전트보다 품질이 높았지만, 토큰 사용량은 채팅 대비 최대 15배까지 늘어날 수 있다는 점은 비용 측면에서 고려해야 한다.
마무리
프롬프트 엔지니어링이 “모델에게 무엇을 시킬지”를 설계하는 일이라면, 컨텍스트 엔지니어링은 “모델이 무엇을 알고, 무엇을 보고 대답하게 할지”를 설계하는 일이다.
LLM이 추론 능력을 갖추고 에이전트 시스템과 비즈니스 자동화 영역으로 확장될수록, 단순히 문장을 잘 만드는 기술만으로는 한계가 있다. LLM이 필요한 정보를 적시에 제공받고 상황에 맞게 동작하도록 만드는 기술, 즉 컨텍스트 엔지니어링의 중요성은 계속 커질 것이다.