프롬프트 엔지니어링은 끝났다? 컨텍스트 엔지니어링 완벽 가이드

작성자:

Key Takeaways

컨텍스트 엔지니어링은 AI 모델에게 ‘무엇을 말할지’가 아니라 ‘무엇을 알아야 하는지’를 설계하는 기술로, 프롬프트 엔지니어링을 감싸는 상위 개념입니다. 같은 모델이라도 컨텍스트 창에 무엇을, 어떤 순서로, 얼마나 넣느냐에 따라 결과 품질이 완전히 달라집니다. 앤트로픽은 이를 유한한 자원인 ‘어텐션 예산’을 배분하는 문제로 정의하고, 드루 브뢰니히는 컨텍스트가 망가지는 4가지 실패 모드를 정리했습니다. 이 글은 그 원리와 Write·Select·Compress·Isolate 4대 전략을 처음부터 짚습니다.

  • 트랜스포머는 n개 토큰에 n²개의 관계를 계산해 ‘어텐션 예산’이 빠르게 고갈됩니다 (Anthropic)
  • 컨텍스트가 망가지는 4대 실패 모드: 중독·산만·혼동·충돌 (Drew Breunig)
  • 4대 전략: Write(쓰기)·Select(선택)·Compress(압축)·Isolate(격리) (LangChain)
  • 핵심 원칙은 ‘신호가 높은 최소한의 토큰’을 넣는 것 — 창을 꽉 채우는 게 아닙니다

AI 챗봇에게 똑같은 질문을 두 번 던졌는데 한 번은 정확하고 한 번은 엉뚱한 답이 돌아온 경험, 한 번쯤 있으실 겁니다. 모델은 그대로인데 결과가 갈리는 이유, 그 답을 다루는 기술이 바로 컨텍스트 엔지니어링(Context Engineering)입니다. 같은 모델이라도 그 순간 컨텍스트 창(context window)에 무엇이 담겨 있었느냐에 따라 완전히 다른 답을 내놓기 때문입니다.

2025년을 지나며 업계에서는 “프롬프트 엔지니어링의 시대가 저물고 컨텍스트 엔지니어링의 시대가 왔다”는 말이 자주 들립니다. 다소 과장된 선언이지만, 방향은 정확합니다. 프롬프트를 다듬는 것만으로는 AI 에이전트를 안정적으로 굴릴 수 없다는 사실을 많은 개발팀이 확인했기 때문입니다.

이 글에서는 그것이 정확히 무엇인지, 왜 컨텍스트가 망가지는지, 그리고 이를 다루는 실전 전략은 무엇인지를 처음부터 정리합니다. 코드를 짜지 않는 독자도 “우리 회사 챗봇이 왜 자꾸 헛소리를 하는지”를 진단하는 감각을 얻어 가실 수 있습니다.

AI-generated illustration — 빛나는 반투명 큐브(컨텍스트 창)로 도구·문서·메모리에서 나온 데이터 흐름이 모여드는 3D 그래픽
컨텍스트 엔지니어링은 도구·메모리·문서 등 여러 출처의 정보를 하나의 컨텍스트 창에 어떻게 담을지 설계하는 일이다 — AI-generated illustration (OpenAI gpt-image-1-mini)

프롬프트 엔지니어링은 왜 한계에 부딪혔나

몇 년 전만 해도 AI를 잘 쓰는 기술의 대명사는 프롬프트 엔지니어링이었습니다. 질문을 어떻게 던지느냐에 따라 답의 질이 크게 달라졌기 때문입니다. “단계별로 생각해봐” 같은 한 줄을 붙이는 것만으로 성능이 오르던 시절이었습니다.

문제는 AI가 단순한 질의응답을 넘어 에이전트(agent)로 진화하면서 시작됐습니다. 에이전트는 여러 단계를 스스로 계획하고, 도구를 호출하고, 이전 대화와 문서와 검색 결과를 참고하며 작업을 이어갑니다. 이때 모델에 들어가는 정보는 사용자의 질문 한 줄이 아니라, 수만에서 수십만 토큰에 달하는 거대한 묶음이 됩니다.

안드레이 카르파티(Andrej Karpathy)는 이 변화를 짚으며 컨텍스트 엔지니어링을 “컨텍스트 창을 다음 단계에 딱 맞는 정보로 채우는 섬세한 기술이자 과학”이라고 정의했습니다. 여기서 핵심은 ‘질문’이 아니라 ‘창을 채우는 방식’으로 무게중심이 옮겨갔다는 점입니다.

그렇다면 프롬프트 엔지니어링은 죽은 걸까요. 그렇지 않습니다. 프롬프트는 여전히 중요하지만, 이제는 더 큰 그림의 한 겹(layer)이 되었습니다. 카르파티와 앤트로픽이 공통적으로 이 기술을 ‘프롬프트 엔지니어링을 포함하는 상위 개념’으로 설명하는 이유입니다.

💡 함께 읽으면 좋은 글
AI 에이전트 vs 챗봇 vs LLM 차이 완벽 정리 2026

컨텍스트 엔지니어링이란 무엇인가: 어텐션 예산이라는 핵심

앤트로픽은 컨텍스트 엔지니어링을 시스템 지시·도구·외부 데이터·메시지 히스토리 등 추론(inference) 시 모델에 들어가는 모든 토큰의 최적 구성을 큐레이팅하고 유지하는 작업으로 정의합니다. 프롬프트가 “무엇을 말할지”라면, 컨텍스트는 “모델이 잘 답하기 위해 무엇을 알아야 하는지” 전체를 가리킵니다.

왜 이 ‘구성’이 그렇게 중요할까요. 트랜스포머(Transformer) 구조의 근본적인 제약 때문입니다. 트랜스포머는 n개의 토큰이 있으면 모든 토큰이 서로를 참조하는 n²개의 쌍(pairwise) 관계를 계산합니다. 토큰이 두 배가 되면 계산할 관계는 네 배가 되는 셈입니다.

앤트로픽은 이 현상을 ‘어텐션 예산(attention budget)’이라는 개념으로 설명합니다. 모델이 한 번에 기울일 수 있는 ‘주의’에는 정해진 총량이 있고, 토큰을 하나씩 밀어 넣을 때마다 그 예산이 조금씩 소진된다는 뜻입니다. 컨텍스트 창은 무한한 저장고가 아니라 유한한 자원인 것입니다.

여기서 흥미로운 반전이 나옵니다. 컨텍스트 창이 크다고 무조건 좋은 게 아니라는 사실입니다. 앤트로픽은 창이 커질수록 정보 검색 정확도가 떨어지는 ‘컨텍스트 로트(context rot)’ 현상을 지적합니다. 급격히 무너지는 절벽이 아니라, 창이 길어질수록 정밀도가 서서히 낮아지는 완만한 저하입니다.

쉽게 말하면: 어텐션 예산은 회의실 화이트보드와 비슷합니다. 보드는 넓지만 무한하지 않고, 아무 메모나 잔뜩 붙여 놓으면 정작 중요한 항목이 묻혀 버립니다. 핵심은 크게 쓰는 게 아니라, 꼭 필요한 것만 남기는 것입니다.
A close up of a computer circuit board
토큰이 늘수록 n²로 불어나는 연산이 어텐션 예산을 갉아먹는다 — Photo by Luke Jones on Unsplash

컨텍스트는 어떻게 망가지는가: 4대 실패 모드

컨텍스트가 유한한 자원이라면, 그 자원은 구체적으로 어떻게 낭비되고 오염될까요. 개발자 드루 브뢰니히(Drew Breunig)는 긴 컨텍스트가 실패하는 방식을 중독·산만·혼동·충돌 네 가지로 정리했습니다. 각각을 실제 사례와 함께 살펴보겠습니다.

첫 번째는 컨텍스트 중독(Poisoning)입니다. 모델이 만들어 낸 잘못된 정보(할루시네이션)나 오류가 컨텍스트에 한 번 들어가면, 이후 단계에서 반복적으로 참조되며 판단을 오염시키는 현상입니다. 브뢰니히는 Gemini 2.5가 포켓몬 게임을 플레이하던 사례를 듭니다. 잘못 인식한 게임 상태가 ‘목표’ 섹션에 각인되자, 에이전트가 달성 불가능한 목표에 집착하기 시작했습니다.

두 번째는 컨텍스트 산만(Distraction)으로, 컨텍스트가 너무 길어지면 모델이 학습으로 익힌 능력보다 눈앞의 긴 히스토리에 과도하게 몰입하는 현상입니다. 100만 토큰을 지원하는 Gemini 2.5 Pro조차 포켓몬 에이전트에서 약 10만 토큰을 넘어서자 새로운 계획을 세우기보다 과거 행동을 반복했습니다. 별개의 Databricks 연구에서도 Llama 3.1 405b의 정확도가 약 3만 2천 토큰 지점부터 하락하기 시작했습니다.

세 번째는 컨텍스트 혼동(Confusion)입니다. 당장 필요 없는 정보가 컨텍스트에 섞여 들어가면, 모델이 그걸 굳이 사용해 답의 질을 떨어뜨리는 현상입니다. Berkeley Function-Calling Leaderboard에서는 도구를 한 개보다 많이 쥐여 주면 모든 모델의 성능이 나빠졌습니다. GeoEngine 벤치마크에서는 양자화한 Llama 3.1 8b가 46개의 도구를 받았을 때(16k 창 안에 들어갔음에도) 실패했지만, 19개만 남기자 성공했습니다.

네 번째는 컨텍스트 충돌(Clash)로, 컨텍스트 안에 서로 어긋나는 정보나 도구가 쌓이면 모델이 갈피를 못 잡는 현상입니다. 마이크로소프트와 세일즈포스의 연구는 같은 정보를 한 번에 주지 않고 여러 메시지로 나눠(sharded) 전달하는 실험을 했습니다. 그 결과 모델 성능이 평균 39% 하락했고, OpenAI o3의 점수는 98.1점에서 64.1점으로 떨어졌습니다.

정리하면, 네 가지 실패 모드는 모두 “컨텍스트에 무언가를 더 넣는 것”이 오히려 독이 될 수 있음을 보여 줍니다. 여기서 핵심은 정보의 양이 아니라 신호 대 잡음비라는 점입니다. 이 진단은 AI 에이전트가 벤치마크에서는 잘하다가 현실에서 무너지는 이유와도 맞닿아 있습니다.

실패 모드무엇이 문제인가실측 사례
중독 (Poisoning)오류·할루시네이션이 컨텍스트에 박혀 반복 참조Gemini 2.5 포켓몬 — 불가능한 목표에 집착
산만 (Distraction)너무 긴 히스토리에 과몰입, 학습 능력 무시Gemini 2.5 Pro 10만 토큰 이후 저하 / Llama 405b 3만2천 토큰
혼동 (Confusion)불필요한 정보·도구를 굳이 사용도구 46→19개로 줄이자 성공 (GeoEngine)
충돌 (Clash)어긋나는 정보·도구가 누적분할 전달 시 평균 39%↓, o3 98.1→64.1
핵심: 네 실패 모드의 공통 교훈은 하나입니다. 컨텍스트는 많이 넣을수록 좋아지는 게 아니라, 잘못 넣으면 성능이 측정 가능한 수준으로 떨어진다는 것입니다.
💡 함께 읽으면 좋은 글
AI 에이전트 벤치마크의 붕괴: 점수는 100%인데 현실에선 왜 무너질까
A group of blue and green balls on a black background
토큰 하나하나가 서로 연결되는 구조 — 많을수록 관계망이 복잡해진다 — Photo by Ecliptic Graphic on Unsplash

컨텍스트 엔지니어링 4대 전략: Write·Select·Compress·Isolate

문제를 알았으니 이제 해법입니다. 랭체인(LangChain)은 실전에서 쓰이는 컨텍스트 관리 전략을 Write(쓰기)·Select(선택)·Compress(압축)·Isolate(격리) 네 가지로 정리했습니다. 대부분의 AI 에이전트 시스템은 이 넷을 조합해 작동합니다.

Write(쓰기)는 정보를 컨텍스트 창 ‘밖’에 저장해 두는 전략입니다. 창에 다 넣으면 어텐션 예산이 터지니, 지금 당장 필요 없는 건 외부에 적어 두는 것입니다. 앤트로픽의 멀티 에이전트 리서처는 컨텍스트가 20만 토큰을 넘어 잘릴 위험이 생기면 계획을 메모리(스크래치패드)에 저장합니다. ChatGPT·커서(Cursor)·윈드서프(Windsurf)가 세션이 바뀌어도 사용자 정보를 기억하는 것도 이 방식입니다.

Select(선택)는 저장해 둔 것 중 지금 필요한 것만 골라 컨텍스트 창으로 불러오는 전략입니다. 우리가 흔히 아는 RAG(검색 증강 생성)가 바로 이 Select에 해당합니다. 흥미롭게도, 도구 설명 자체에 RAG를 적용해 필요한 도구만 골라 주면 도구 선택 정확도가 약 3배 향상된다는 결과도 있습니다. Claude Code가 프로젝트 규칙을 담은 CLAUDE.md 파일을 불러오는 것도 Select의 한 형태입니다.

Compress(압축)는 작업에 필요한 토큰만 남기고 나머지를 요약해 부피를 줄이는 전략입니다. 긴 대화가 창 한계에 가까워지면 오래된 부분을 요약으로 갈음합니다. Claude Code의 오토컴팩트(auto-compact)는 컨텍스트 창이 95% 용량에 도달하면 자동으로 대화 요약을 트리거합니다.

Isolate(격리)는 하나의 큰 컨텍스트를 여러 개로 쪼개 서로 오염되지 않게 하는 전략입니다. 대표적인 방식이 멀티 에이전트 구조입니다. 앤트로픽의 멀티 에이전트 리서처에서 각 서브에이전트(sub-agent)는 단일 챗보다 약 15배 많은 토큰을 소모하지만, 작업을 병렬로 나눠 탐색하기 때문에 더 나은 성능을 냅니다. 각 서브에이전트는 결과를 통째로 넘기지 않고 1,000~2,000 토큰짜리 요약만 부모 에이전트에게 돌려줍니다.

전략한 줄 정의실제 시스템
Write (쓰기)창 밖에 저장해 두기스크래치패드(20만 토큰↑ 시), ChatGPT·Cursor 메모리
Select (선택)필요한 것만 불러오기RAG, 도구 선택(정확도 3배↑), CLAUDE.md
Compress (압축)요약으로 토큰 절약Claude Code 오토컴팩트(95% 도달 시)
Isolate (격리)서브에이전트로 분리멀티 에이전트(서브당 15배 토큰, 요약 1~2천 토큰만 반환)
pastel spheres on gradient background
Write·Select·Compress·Isolate는 대체재가 아니라 함께 쓰는 도구 세트다 — Photo by Milad Fakurian on Unsplash

좋은 컨텍스트를 만드는 실무 원칙

전략의 틀을 알았다면, 실제로 컨텍스트를 구성할 때 지킬 원칙이 궁금해집니다. 앤트로픽은 몇 가지 실무 지침을 제시합니다. 관통하는 하나의 원칙은 “원하는 결과를 낼 확률을 최대로 높이는, 신호가 가장 높은 최소한의 토큰 집합”을 찾으라는 것입니다.

첫째, 시스템 프롬프트는 ‘적절한 고도(right altitude)’로 씁니다. 모든 경우를 하드코딩한 딱딱한 규칙 뭉치도, 너무 추상적이고 모호한 지침도 둘 다 실패합니다. 사람이 읽고 바로 이해할 만큼 구체적이면서도, 판단의 여지를 남기는 균형점을 찾는 일입니다.

둘째, 도구는 최소한으로, 서로 겹치지 않게 설계합니다. 앞서 본 ‘혼동’ 실패 모드가 정확히 도구 과잉에서 나왔습니다. 기능이 애매하게 중복되는 도구가 많을수록 모델은 어느 것을 쓸지 헷갈립니다. 도구 목록은 짧고 명확할수록 좋습니다.

셋째, 긴 작업에는 컴팩션과 에이전트 메모를 씁니다. 대화가 길어지면 아키텍처 결정 같은 중요한 내용은 보존하고 중복 출력은 버리는 요약(컴팩션)을 걸고, 필요한 메모는 NOTES.md 같은 외부 파일에 적어 창 밖에 둡니다. 이렇게 하면 긴 세션에서도 핵심 맥락을 잃지 않습니다.

넷째, 데이터는 적시에(just-in-time) 불러옵니다. 모든 문서를 미리 컨텍스트에 밀어 넣지 않습니다. 대신 가벼운 식별자만 들고 있다가, 실제로 필요할 때 도구를 호출해 그때그때 가져오는 방식입니다. 이는 어텐션 예산을 아끼는 가장 직접적인 방법입니다.

이 원칙들은 결국 하나로 수렴합니다. 컨텍스트는 정보 창고가 아니라 예산이라는 관점입니다. 무엇을 넣을지보다 무엇을 넣지 않을지를 고민하는 순간, 컨텍스트 엔지니어링이 시작됩니다.

핵심: 실무 원칙은 ‘적절한 고도의 시스템 프롬프트 + 최소·비중복 도구 + 컴팩션·메모 + 적시 검색’으로 요약됩니다. 모두 ‘어텐션 예산 절약’이라는 한 가지 목표를 향합니다.

컨텍스트 엔지니어링 vs RAG vs 프롬프트 엔지니어링

여기까지 오면 용어들이 서로 어떻게 얽히는지 헷갈릴 수 있습니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, RAG는 경쟁하는 대체 기술이 아닙니다. 서로를 포함하는 동심원 관계에 가깝습니다.

가장 안쪽 원이 프롬프트 엔지니어링입니다. 모델에게 주는 ‘지시’를 다듬는 일이며, 여전히 컨텍스트 구성의 중요한 한 요소입니다. 그 바깥을 감싸는 큰 원이 컨텍스트 엔지니어링으로, 지시가 제대로 작동하도록 근거·도구·메모리·검색 결과 전체를 설계합니다.

RAG는 어디에 있을까요. RAG는 컨텍스트 엔지니어링의 4대 전략 중 Select(필요한 정보를 골라 창으로 불러오기)에 해당하는 한 갈래입니다. 즉 RAG는 그 부분집합이지, 별개의 경쟁 개념이 아닙니다. 바깥 원은 RAG 외에도 Write·Compress·Isolate를 함께 다룹니다.

이 지도를 손에 쥐면 실무 대화가 명확해집니다. “프롬프트를 더 다듬을까”는 가장 안쪽 원의 문제이고, “어떤 문서를 검색해 넣을까”는 Select의 문제이며, “히스토리가 너무 길어졌는데 어떻게 줄이지”는 Compress의 문제입니다. 문제를 올바른 층위에 놓는 것만으로 해법의 절반은 찾은 셈입니다.

개념다루는 범위관계
프롬프트 엔지니어링모델에게 주는 ‘지시’ 문구가장 안쪽 — 컨텍스트의 한 요소
RAG필요한 외부 정보 검색·주입컨텍스트 엔지니어링의 Select 전략
컨텍스트 엔지니어링창에 들어가는 모든 토큰의 구성바깥 원 — 위 둘을 포함

AI를 다루는 관점이 ‘질문 잘하기’에서 ‘정보 환경 설계하기’로 넓어지는 것, 그것이 컨텍스트 엔지니어링이 말하는 변화의 본질입니다. 같은 흐름은 추론 모델이나 프롬프트 인젝션 보안처럼 에이전트 시대의 다른 주제들과도 자연스럽게 이어집니다.

자주 묻는 질문 (FAQ)

Q1. 컨텍스트 엔지니어링과 프롬프트 엔지니어링의 차이는 무엇인가요?

프롬프트 엔지니어링은 ‘모델에게 어떻게 지시할지’를 다듬는 기술입니다. 컨텍스트 엔지니어링은 그 지시가 제대로 작동하도록 시스템 프롬프트·도구·메모리·검색 결과 등 모델에 들어가는 모든 정보를 설계하는 상위 작업입니다. 프롬프트 엔지니어링은 그 상위 작업의 한 겹입니다.

Q2. 컨텍스트 창이 크면 무조건 좋은 것 아닌가요?

아닙니다 — 트랜스포머는 토큰 수의 제곱에 비례해 계산량이 늘어 ‘어텐션 예산’이 빠르게 고갈됩니다. 창이 커질수록 검색 정확도가 떨어지는 ‘컨텍스트 로트’ 현상도 나타납니다. Gemini 2.5 Pro는 100만 토큰을 지원해도 약 10만 토큰을 넘으면 성능이 저하됐습니다. 창을 채우는 것보다 ‘신호가 높은 최소한의 토큰’을 넣는 것이 중요합니다.

Q3. RAG와 컨텍스트 엔지니어링은 같은 건가요?

RAG(검색 증강 생성)는 컨텍스트 엔지니어링의 한 갈래입니다. 랭체인의 4대 전략 중 ‘Select(필요한 정보를 컨텍스트 창으로 불러오기)’에 해당합니다. 이 개념은 RAG 외에도 쓰기(Write)·압축(Compress)·격리(Isolate) 전략을 함께 포함하는 더 넓은 개념입니다.

Q4. 어텐션 예산이 정확히 무슨 뜻인가요?

트랜스포머 모델은 n개의 토큰이 있으면 모든 토큰이 서로를 참조하는 n²개의 관계를 계산합니다. 토큰이 늘어날수록 이 계산이 급증하고, 각 토큰에 배분되는 ‘주의(attention)’가 얕아집니다. 앤트로픽은 이를 유한한 자원인 ‘어텐션 예산’으로 부르며, 이 예산을 아껴 쓰는 것이 그 핵심이라고 설명합니다.

Q5. 컨텍스트 압축(컴팩션)은 어떻게 동작하나요?

긴 작업 도중 대화 히스토리가 컨텍스트 창 한계에 가까워지면, 오래된 내용을 요약해 핵심만 남기고 나머지는 버립니다. Claude Code의 오토컴팩트는 창 용량이 95%에 도달하면 요약을 자동 실행합니다. 이때 아키텍처 결정 같은 중요한 정보는 보존하고 중복 출력은 제거하는 것이 원칙입니다.

Q6. 개발자가 아니어도 컨텍스트 엔지니어링을 알아야 하나요?

AI 에이전트를 쓰거나 도입을 검토하는 사람이라면 알아두면 좋습니다. 같은 모델이라도 어떤 정보를 어떤 순서로 주느냐에 따라 결과 품질이 크게 달라지기 때문입니다. 4대 실패 모드(중독·산만·혼동·충돌)를 이해하면 ‘왜 우리 챗봇이 자꾸 헛소리를 하는지’를 진단하는 감각이 생깁니다.

References

트렌드를 먼저 읽는 사람들

AI, 테크, 경제의 핵심 인사이트를 한국어와 영어로 동시에 제공합니다.

더 많은 글 보기