AI context engineering은 긴 프롬프트를 잘 쓰는 기술이 아니라, 모델이 실제로 봐야 할 정보를 비용과 품질 기준에 맞게 고르는 설계입니다.
context window가 커지면 더 많은 정보를 넣을 수는 있지만, 그 정보가 매번 토큰 비용과 응답 지연으로 돌아온다는 점을 잊기 쉽습니다.
그래서 운영 환경에서는 “얼마나 많이 넣을까”보다 “무엇을 빼도 답이 흔들리지 않을까”가 더 중요한 질문이 됩니다.
AI context engineering을 비용 문제로 봐야 하는 이유
LLM 호출 비용은 대체로 입력 토큰과 출력 토큰의 합으로 계산됩니다. 입력에 문서 20개를 넣으면 모델은 그 20개를 모두 읽는 셈이고, 같은 요청이 반복되면 낭비도 반복됩니다.
긴 컨텍스트는 품질을 높일 수도 있지만, 관련 없는 문서가 섞이면 모델이 엉뚱한 단서를 따라갈 가능성도 생깁니다.
컨텍스트는 많이 넣는 자원이 아니라, 매 호출마다 예산을 쓰는 입력 설계 대상으로 봐야 합니다.
토큰 예산을 먼저 정해야 한다
실무에서는 기능별로 토큰 예산을 먼저 정하는 편이 좋습니다. 예를 들어 고객 문의 요약, 사내 문서 Q&A, 코드 리뷰 도우미는 필요한 근거의 양이 다릅니다.
- 항상 들어가야 하는 시스템 지침
- 사용자 요청 원문
- 검색해서 넣을 문서 조각
- 도구 호출 결과
- 모델이 답변으로 써야 하는 출력 여유
이 다섯 영역이 같은 context window 안에서 경쟁합니다. 검색 문서를 많이 넣을수록 답변 출력 여유가 줄고, 도구 결과가 길어질수록 사용자 요청의 핵심이 밀릴 수 있습니다.
따라서 “검색 결과 상위 10개를 모두 넣자”보다 “이 기능은 근거 3개, 총 1,500토큰 안에서 답하게 하자”처럼 운영 기준을 잡는 편이 관리하기 쉽습니다.
RAG에서 검색보다 packing이 더 어려운 순간
RAG를 붙이면 검색 결과를 가져오는 데까지는 비교적 빨리 갑니다. 실제 난점은 그 다음입니다. 검색된 문서 중 어떤 부분을 넣고, 어떤 순서로 넣고, 중복되는 내용을 어떻게 줄일지 결정해야 합니다.
같은 문서 조각이 여러 번 들어가면 비용은 늘지만 정보량은 거의 늘지 않습니다. 반대로 중요한 반례가 빠지면 답은 깔끔해 보여도 실제로 틀릴 수 있습니다.
- 질문 의도와 직접 맞는 문단만 남긴다
- 같은 주장의 중복 문단은 하나로 줄인다
- 숫자, 버전, 정책처럼 틀리면 위험한 근거는 출처와 함께 남긴다
- 모델에게 판단을 맡길 부분과 고정 규칙으로 처리할 부분을 분리한다
이 작업이 context packing입니다. 단순히 잘라 넣는 것이 아니라, 모델이 답을 만들 때 필요한 증거의 순서를 설계하는 일입니다.
프롬프트 캐싱은 구조가 고정될 때 효과가 크다
OpenAI와 Anthropic 문서 모두 반복되는 입력 부분을 캐싱할 수 있는 방식을 설명합니다. 하지만 캐싱은 마법처럼 모든 요청을 싸게 만드는 기능이 아닙니다.
캐싱 효과를 보려면 반복되는 prefix가 안정적이어야 합니다. 예를 들어 시스템 지침, 정책 문서, 도구 설명처럼 자주 바뀌지 않는 긴 내용이 앞부분에 고정되어 있으면 이득이 커질 수 있습니다.
반대로 매 요청마다 앞부분 구조가 바뀌고, 검색 문서 순서도 계속 흔들리면 캐싱 효율은 낮아집니다.
{
"stable_prefix": ["system_policy", "tool_contracts", "answer_format"],
"dynamic_context": ["user_question", "retrieved_chunks", "latest_tool_result"],
"budget": {
"retrieved_chunks": "max 3",
"answer": "leave enough output tokens"
}
}운영 기준은 품질, 비용, 지연을 함께 봐야 한다
context engineering을 잘했는지는 답이 그럴듯한지만 보면 부족합니다. 같은 품질을 더 낮은 비용으로 만들었는지, 응답 시간이 줄었는지, 실패 케이스가 줄었는지도 같이 봐야 합니다.
- 정답률 또는 사용자 승인률
- 입력 토큰 평균과 상위 95% 값
- 응답 지연 시간
- 검색 문서 개수와 실제 인용 문서 개수
- 근거 없는 단정이 나온 비율
이 지표를 같이 보면 “컨텍스트를 줄였더니 비용은 줄었지만 답이 흔들렸다”거나 “문서를 더 넣었는데 품질은 그대로고 비용만 늘었다” 같은 상황을 빨리 발견할 수 있습니다.
정리
AI context engineering은 프롬프트를 멋지게 쓰는 일이 아니라, 모델에게 줄 정보를 운영 가능한 비용과 품질 기준으로 고르는 일입니다.
출처 확인: OpenAI prompt caching 문서와 OpenAI retrieval 문서를 기준으로, 반복 컨텍스트와 검색 문서 투입 범위를 함께 확인했습니다.
처음부터 토큰 예산을 정하고, RAG 문서를 선별하고, 반복되는 prefix를 고정하고, 품질과 비용을 함께 평가하면 긴 context window를 더 현실적으로 쓸 수 있습니다.
관련해서는 RAG에서 context engineering이 중요한 이유와 AI eval은 왜 필요할까를 함께 보면 흐름이 이어집니다.
