AI·자동화 트렌드
AI 에이전트가 같은 질문을 또 묻는다면? 컨텍스트 엔지니어링 4가지 질문
AI 에이전트 '컨텍스트 엔지니어링' — 프롬프트 엔지니어링 다음에 설계자가 챙겨야 할 것
컨텍스트 엔지니어링은 추론 한 턴마다 모델에 남길 토큰을 고르는 설계입니다.
새벽에 걸어둔 에이전트를 아침에 열어봤더니, 같은 티켓을 세 번 조회하고 이미 받아둔 승인 정보를 또 묻고 있어요. 프롬프트는 어제와 한 글자도 다르지 않고, 모델도 그대로입니다. 달라진 건 하나예요. 세션이 길어졌습니다.
자동화 워크플로우의 품질은 프롬프트의 문장력이 아니라 컨텍스트의 수납 설계에서 갈립니다.
한눈 요약
- 프롬프트 엔지니어링은 한 번의 호출을, 컨텍스트 엔지니어링은 수십 턴에 걸쳐 쌓이는 상태를 다룹니다.
- Anthropic은 컨텍스트를 한계 수익이 체감하는 유한한 자원으로 규정합니다.1
- 윈도우를 키워도 중간에 놓인 근거의 회상률은 떨어집니다.2
- 설계 단계에서 최소 집합·영속 정보·툴 응답 상한·실패 잔여물을 숫자로 적어두세요(컨텍스트 예산 4문).
프롬프트 엔지니어링과 어디서 갈리나요
"한 번"과 "계속"에서 갈립니다. 프롬프트 엔지니어링은 한 번의 호출에 들어갈 지시문을 벼리는 일이고, 컨텍스트 엔지니어링은 턴이 쌓이는 동안 윈도우에 남을 것과 버릴 것을 정하는 일이에요.
Anthropic은 2025년 엔지니어링 블로그에서 이를 "LLM 추론 중 최적의 토큰 집합을 선별하고 유지하는 전략"으로 정의하고, 목표를 가능한 가장 작은 고신호 토큰 집합으로 못박았습니다.1 트랜스포머는 토큰 사이의 관계를 전부 계산하니, 넣을 수 있는 분량과 별개로 주의력에 예산이 있다는 뜻이죠.
용어는 2025년 6월 Shopify CEO 토비 뤼트케가 "프롬프트 엔지니어링보다 컨텍스트 엔지니어링이 핵심 기술을 더 잘 설명한다"고 쓴 뒤 업계로 번졌습니다.3
보충. 같은 예산을 나눠 쓰는 건 프롬프트만이 아닙니다. 시스템 지시문, 대화 이력, 검색된 문서, 툴 정의, 툴이 토해낸 JSON, 에이전트가 스스로 남긴 메모까지 전부입니다.
왜 에이전트에서만 이 문제가 터지나요
루프를 돌 때마다 툴 응답 전문이 컨텍스트에 그대로 얹히기 때문입니다.
단발 질의응답은 한 번 묻고 한 번 받고 끝났어요. 에이전트는 툴을 부르고, 결과를 읽고, 다음 행동을 고르는 루프를 수십 번 돕니다. 재고 API가 500행 JSON을 돌려주면 그 500행이 다음 턴의 판단 재료에 섞여요. 열 바퀴면 5,000행입니다. 설계자가 손대지 않으면 컨텍스트는 쓰레기통처럼 차오릅니다.
프롬프트를 고쳐서 막으려 들면 여기서 벽에 부딪혀요. 문제가 지시문이 아니라 누적이니까요.
컨텍스트가 무너질 때 먼저 나타나는 세 신호
환각 재발, 툴 오호출, 이미 답한 걸 또 묻는 반복 질문입니다. 셋 다 세션 초반에는 보이지 않고, 턴이 쌓인 뒤에 나타나요. 데모가 멀쩡했는데 운영에서 깨지는 이유가 대개 여기 있습니다.
| 신호 | 직접 원인 | 자동화에서 터지는 것 |
|---|---|---|
| 초반엔 정확했는데 후반에 사실을 지어냄 | 근거 문서가 긴 컨텍스트 중간에 묻혀 회상률 하락 | 잘못된 값으로 후속 단계가 전부 오염 |
| 엉뚱한 툴을 부르거나 인자를 틀림 | 툴 정의가 누적된 호출 로그에 희석됨 | 실패 호출 재시도로 API 비용·레이트리밋 소모 |
| 이미 받은 정보를 다시 요구 | 중간 결론이 요약 없이 원문으로만 남아 유실 | 루프 미완결, 사람이 개입해 수동 처리 |
윈도우가 100만 토큰이면 해결되나요
안 됩니다. 길이를 늘리는 것과 길이를 쓰는 것은 다른 문제예요.
Liu 등의 「Lost in the Middle」은 관련 정보가 입력의 맨 앞이나 맨 뒤에 있을 때 성능이 가장 높고 중간에 놓이면 떨어진다는 U자 곡선을 실증했습니다. 중간 배치에서는 문서를 아예 주지 않은 설정보다 낮은 정확도를 보인 모델도 있었고, 긴 컨텍스트를 전용으로 지원하는 모델에서도 입력이 길어질수록 성능이 내려갔습니다.2 Chroma의 2025년 보고서 『Context Rot』는 모델 18종에서 과제 난이도를 고정하고 입력 길이만 늘렸는데, 저하가 길이에 비례해 매끄럽게 오지 않고 들쭉날쭉하게 무너졌습니다.4
돈과 시간도 같이 걸립니다. 컨텍스트에 넣은 토큰은 턴마다 다시 과금되고, 입력이 길어지면 첫 토큰까지의 지연도 늘어나요. 윈도우는 책상입니다. 넓어졌다고 서류를 다 펴놓으면 커피잔 놓을 자리가 없어집니다.
무엇을 남기고 무엇을 버릴까요
지금 이 턴의 결정에 필요한 최소한의 고신호 토큰만 남깁니다. LangChain은 실무 기법을 쓰기·선택·압축·격리 네 갈래로 정리했고, 아래 표는 그 분류를 자동화 설계 관점으로 옮긴 것입니다.5
적시 검색(RAG)은 문서를 미리 다 넣지 않고 필요할 때 꺼내오는 방식이고, 압축(compaction)은 쌓인 이력을 요약으로 갈아 끼우는 작업입니다. 서브에이전트 격리는 탐색 과정을 별도 컨텍스트에서 돌리고 메인에는 결과만 넘기는 구조예요.
| 기법 | 언제 켜나요(임계값) | 잃는 것 |
|---|---|---|
| 적시 검색(RAG) | 참조 문서 총량이 윈도우보다 클 때 | 검색이 틀리면 근거가 아예 안 들어옴 |
| 요약·압축(compaction) | 대화 이력이 윈도우의 절반을 넘길 때 | 요약 과정에서 세부 수치 유실 |
| 툴 응답 필터링 | 툴 하나의 반환이 정한 상한 토큰을 넘길 때 | 필터를 좁히면 예외 케이스 누락 |
| 외부 메모 쓰기 | 결론을 세션이 끝난 뒤에도 유지해야 할 때 | 저장·조회 단계가 늘어 설계 복잡도 상승 |
| 서브에이전트 격리 | 탐색 중간 과정이 최종 판단에 섞이면 안 될 때 | 총 토큰과 호출 수는 오히려 증가 |
설계 전에 던지는 네 질문 — 컨텍스트 예산 4문
워크플로우를 그릴 때 쓰는 질문은 네 개입니다. 컨텍스트 예산 4문이라고 부릅니다.
1문. 이 턴의 최소 집합은 무엇인가요. 이 한 번의 결정에 정말 필요한 토큰만 꼽으세요. 꼽히지 않은 건 빼는 게 기본값입니다.
2문. 100턴 뒤에도 남아야 하는 정보는 무엇인가요. 영속과 휘발을 구분하지 않으면, 지워도 될 로그가 남고 남겨야 할 결론이 사라집니다.
3문. 툴 응답의 상한은 몇 토큰인가요. 툴마다 반환 크기 계약을 숫자로 적으세요. 상한 없는 툴 하나가 컨텍스트 절반을 먹습니다.
4문. 실패하면 무엇이 남나요. 실패한 호출의 스택트레이스와 재시도 기록이 그대로 쌓이면, 모델은 자기 실패 로그를 판단 근거로 읽습니다. 가장 흔하고 가장 안 보이는 누수예요.
네 질문의 답을 문서로 가진 워크플로우와 그렇지 않은 워크플로우는, 서른 턴쯤 지나면 눈에 보이게 갈립니다.
FAQ
Q. 컨텍스트 엔지니어링은 프롬프트 엔지니어링을 대체하나요? A. 대체가 아니라 포함입니다. 좋은 시스템 프롬프트는 여전히 컨텍스트의 한 구성요소예요. 관리 대상이 문장 하나에서 턴마다 변하는 상태 전체로 넓어졌을 뿐입니다.
Q. 대화 이력을 그냥 전부 넣으면 안 되나요? A. 짧은 세션이면 괜찮습니다. 다단계 에이전트에서는 권하지 않아요. 긴 입력의 중간 정보 회상률이 떨어지고, 같은 토큰이 턴마다 재과금됩니다.
Q. 요약을 넣으면 정보가 손실되는데 괜찮을까요? A. 손실은 전제입니다. 그래서 무엇을 잃어도 되는지 미리 정해요. 금액·ID·날짜처럼 식별 가능한 값은 원문 그대로 보존하고, 서술형 맥락만 압축하는 쪽이 안전합니다.
Q. 비개발자도 이걸 다룰 수 있나요? A. 다룰 수 있습니다. 4문은 코드가 아니라 설계 질문이에요. 클래스도산은 비개발자·실무자를 대상으로 클로드 바이브 코딩 원데이 클래스를 5시간 동안 진행하며 결과물 하나를 완성하는데, 그 안에서도 어떤 정보를 어디에 남길지가 품질을 가릅니다.
지금 돌고 있는 워크플로우 하나를 열어, 툴 응답 상한부터 숫자로 적어보세요.
출처
- 1 Anthropic Engineering, 『Effective context engineering for AI agents』 (2025): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- 2 Liu et al., 『Lost in the Middle: How Language Models Use Long Contexts』, TACL 2024 (arXiv 2307.03172): https://arxiv.org/abs/2307.03172
- 4 Chroma Research, 『Context Rot: How Increasing Input Tokens Impacts LLM Performance』 (2025): https://research.trychroma.com/context-rot
- 3 LangChain Blog, 『The rise of context engineering』 (2025): https://blog.langchain.com/the-rise-of-context-engineering/
- 5 LangChain Blog, 『Context Engineering for Agents』 (2025): https://blog.langchain.com/context-engineering-for-agents/