컨텍스트는 매번 새로 컴파일된다
프로덕션 AI 서비스에서 컨텍스트는 문서 한 장이 아니다. 매 요청마다 조립되는 실행 입력이다. 사용자가 같은 질문을 해도 사용자 권한, 세션 상태, 최신 문서, 사용 가능한 도구, 비용 한도, 선택된 모델과 서빙 설정이 달라지면 모델에 들어가는 컨텍스트도 달라져야 한다.
그래서 실제 서비스에는 컨텍스트 컴포저(Context Composer)가 필요하다. 컨텍스트 컴포저는 여러 정보원을 받아 지금 이 호출에 필요한 입력만 골라 모델 요청으로 변환하는 런타임 컴포넌트다. IBM은 컨텍스트 엔지니어링의 범위에 시스템 프롬프트, 사용자 질의, 외부 검색 정보, 구조화 데이터, 대화 이력, 도구 출력이 모두 포함된다고 설명한다1. 이 말은 곧 컨텍스트 엔지니어링이 "프롬프트를 잘 쓰는 일"이 아니라, 이런 요소를 안정적으로 조립하는 소프트웨어 파이프라인이라는 뜻이다.
프로덕션 파이프라인은 보통 다음 순서로 흐른다.
요청 수신: 사용자 메시지, 세션 ID, 조직 ID, 권한, 채널 정보를 받는다.
의도와 작업 유형 분류: 단순 답변인지, 문서 검색이 필요한지, 도구 실행이 필요한지 판단한다.
컨텍스트 소스 조회: 사용자 메모리, 최근 대화, RAG 검색 결과, 업무 상태, 도구 레지스트리를 조회한다.
슬롯별 예산 할당: 시스템 지시, 메모리, 검색 결과, 도구 정의, 출력 스키마, 사용자 메시지에 토큰 예산을 나눈다.
검증과 정제: 권한, 개인정보, 정책, 최신성, 중복, 충돌 여부를 검사한다.
최종 조립: 모델별 메시지 형식에 맞춰 순서를 정하고 입력을 만든다.
호출과 기록: 모델 응답, 사용된 컨텍스트 조각, 비용, 지연시간, 검색 결과 ID를 남긴다.
이 구조에서 핵심은 "문자열 붙이기"가 아니다. 각 정보 블록의 출처, 목적, 만료 시간, 권한, 우선순위, 토큰 크기를 함께 관리하는 것이다.
컨텍스트 컴포저의 슬롯 설계
컨텍스트 컴포저는 하나의 큰 프롬프트를 만들기보다, 슬롯을 채우는 방식으로 동작해야 한다. 대표적인 슬롯은 다음과 같다.
시스템 지시 슬롯: 서비스의 역할, 금지 행동, 응답 원칙, 보안 정책을 담는다.
개발자 또는 운영 지시 슬롯: 제품별 규칙, 도메인별 판단 기준, 에스컬레이션 조건을 담는다.
사용자 요청 슬롯: 현재 사용자의 원문 요청을 담는다. 해석한 내용과 원문을 분리해 보관하는 것이 좋다.
대화 상태 슬롯: 최근 대화, 압축 요약, 미해결 과업, 이전 도구 호출 결과를 담는다.
메모리 슬롯: 사용자 선호, 장기 프로젝트 정보, 과거 결정 사항을 담는다.
검색 결과 슬롯: 문서, 데이터베이스, 로그, 그래프에서 가져온 근거를 담는다.
도구 정의 슬롯: 호출 가능한 도구 이름, 설명, 입력 스키마, 사용 조건을 담는다.
출력 스키마 슬롯: JSON, 표, 보고서, 액션 플랜 등 원하는 출력 형식을 담는다.
각 슬롯에는 예산이 있어야 한다. 예를 들어 32K 토큰 모델을 쓴다고 해서 32K를 모두 입력에 쓰면 안 된다. 출력 토큰, 도구 호출 재시도, 검색 결과 추가 삽입을 위한 여유가 필요하다. 실무에서는 전체 입력 예산을 먼저 정하고, 필수 슬롯과 선택 슬롯을 나눈다.
필수 슬롯은 모델 호출 실패를 막기 위해 항상 들어간다. 예를 들면 시스템 지시, 현재 사용자 요청, 출력 스키마가 여기에 해당한다. 선택 슬롯은 점수에 따라 들어간다. 검색 결과, 장기 메모리, 과거 대화, 예시는 관련성·최신성·신뢰도·권한 통과 여부를 기준으로 선택한다.
이때 컴포저는 다음 질문을 매 요청마다 답해야 한다.
이 정보는 지금 작업을 해결하는 데 직접 필요한가?
같은 의미의 정보가 이미 들어가 있지 않은가?
이 사용자가 이 정보를 볼 권한이 있는가?
더 최신 정보와 충돌하지 않는가?
이 정보를 넣는 비용이 응답 품질 개선보다 큰가?
좋은 컨텍스트 컴포저는 많이 넣는 시스템이 아니다. 넣을 이유가 있는 것만 넣고, 그 이유를 기록할 수 있는 시스템이다.
캐시를 고려한 배치: 고정 접두사와 동적 꼬리
모델 호출 비용을 줄이려면 컨텍스트의 순서도 설계해야 한다. 많은 LLM 제공자는 동일한 접두사가 반복될 때 캐시를 활용한다. 따라서 자주 바뀌지 않는 정보는 앞쪽에 안정적으로 두고, 매번 바뀌는 정보는 뒤쪽에 두는 편이 유리하다.
실무적으로는 컨텍스트를 두 구역으로 나눌 수 있다.
첫 번째 구역은 안정 구역이다. 시스템 지시, 에이전트 정체성, 핵심 정책, 자주 쓰는 도구 스키마, 고정 출력 규칙을 둔다. 이 영역은 순서와 문구를 자주 바꾸지 않는다. 작은 수정 하나도 캐시 적중률을 떨어뜨릴 수 있기 때문이다.
두 번째 구역은 동적 구역이다. 검색 결과, 세션 요약, 최근 도구 결과, 사용자별 메모리, 현재 사용자 메시지를 둔다. 이 영역은 요청마다 달라진다. 오픈소스 Context Assembly Layer는 안정 접두사와 동적 청크를 분리하고, 관련성 점수는 선택에만 쓰며 위치는 결정적 순서로 유지해 캐시 효율을 높이는 방식을 제안한다2. 중요한 교훈은 단순하다. "가장 관련 높은 순서로 매번 재정렬"하면 의미상 좋아 보이지만, 캐시 관점에서는 손해가 될 수 있다.
그렇다고 모든 고정 정보를 앞에 몰아넣기만 하면 되는 것은 아니다. 모델은 긴 컨텍스트에서 앞과 끝의 정보에 더 민감하고, 중간 정보는 놓칠 수 있다. Google ADK는 컨텍스트를 세션·메모리·아티팩트 같은 저장 상태로부터 매 호출마다 계산되는 작업 뷰로 보고, 명시적인 프로세서를 통해 필터링·압축·캐싱을 수행하는 구조를 제안한다3. 이 관점이 중요하다. 컨텍스트는 저장소 그 자체가 아니라, 저장소에서 뽑아낸 현재 호출용 뷰다.
따라서 배치 원칙은 다음처럼 잡을 수 있다.
정책과 역할처럼 모든 요청에 필요한 정보는 앞쪽 안정 구역에 둔다.
현재 질문과 직접 관련된 핵심 근거는 사용자 요청 가까이에 둔다.
긴 검색 결과는 요약, 인용, 원문 조각으로 나눠 중요도에 따라 배치한다.
도구 스키마는 모두 싣지 말고 작업 유형에 맞게 줄인다.
과거 대화는 원문 전체보다 상태 요약과 최근 몇 턴을 함께 둔다.
이 설계는 캐시 효율과 모델의 주의 집중을 동시에 다룬다.
컨텍스트 경제성: 품질만큼 중요한 비용 곡선
프로덕션에서는 "정확한가?"와 함께 "감당 가능한가?"를 물어야 한다. 컨텍스트가 길어질수록 비용, 지연시간, 실패 가능성이 함께 증가한다. 긴 입력은 모델 비용을 늘리고, 검색은 외부 시스템 비용을 만들며, 재순위화와 압축은 추가 모델 호출을 요구한다.
컨텍스트 경제성은 다섯 가지 지표를 함께 봐야 한다.
첫째, 토큰 예산이다. 입력 토큰, 출력 예약 토큰, 도구 호출 재시도 토큰을 분리한다. 검색 결과가 많아지면 대화 기록을 줄이고, 도구 설명이 길어지면 검색 원문을 압축하는 식의 교환 규칙이 필요하다.
둘째, 지연시간이다. 사용자는 전체 응답 시간을 경험한다. 검색 300ms, 재순위화 500ms, 압축 1초, 모델 호출 3초가 누적되면 서비스는 느려진다. 그러므로 모든 요청에 고급 검색과 압축을 적용하지 말고, 작업 난이도에 따라 단계적으로 적용한다.
셋째, 모델 라우팅이다. 모든 요청을 가장 비싼 모델로 보낼 필요는 없다. 의도 분류, 개인정보 탐지, 짧은 요약, 검색 쿼리 재작성은 작은 모델이나 규칙 엔진으로 처리할 수 있다. 최종 추론이나 민감한 판단에만 큰 모델을 쓴다.
넷째, 캐시 적중률이다. 안정 접두사를 얼마나 재사용하는지, 같은 문서 요약이 반복 사용되는지, 도구 스키마가 매번 바뀌지 않는지 측정한다. MemServe 같은 연구는 LLM 서빙이 점점 상태ful 시스템이 되고 있으며, 컨텍스트 캐싱과 분리형 추론을 결합해 재사용성을 높일 수 있음을 보여준다4. 애플리케이션 레벨의 프롬프트 캐시와 인프라 레벨의 KV 캐시를 함께 고려해야 하는 이유다.
다섯째, 검색 비용이다. 벡터 검색, 키워드 검색, 그래프 탐색, 웹 검색, SQL 조회는 비용과 지연시간이 다르다. 질문 하나에 모든 검색기를 동시에 호출하는 방식은 초기에 편하지만 오래가지 못한다. 먼저 라우터가 검색 필요성을 판단하고, 필요한 소스만 호출해야 한다.
경제성 설계의 목표는 무조건 싸게 만드는 것이 아니다. 같은 품질을 더 낮은 비용으로, 같은 비용이면 더 높은 신뢰도로 만드는 것이다.
모델 호출 전 검증: 잘못된 컨텍스트를 넣지 않는다
컨텍스트 실패의 상당수는 모델이 잘못 생각해서가 아니라, 잘못된 정보가 입력되었기 때문에 발생한다. 그래서 프로덕션 파이프라인에는 모델 호출 전 검증 단계가 반드시 있어야 한다.
먼저 권한 검사를 한다. 검색 결과가 사용자 권한 범위를 벗어나면 컨텍스트에 넣지 않는다. RAG 시스템에서 가장 위험한 실수는 검색은 전사 문서 전체에서 하고, 응답만 사용자에게 조심스럽게 하도록 모델에 맡기는 것이다. 권한은 모델 지시가 아니라 검색 전후의 필터로 처리해야 한다.
다음은 개인정보와 민감정보 마스킹/삭제다. 주민번호, 계좌번호, 의료정보, 내부 토큰, API 키, 비공개 계약 조건은 모델 호출 전에 제거하거나 마스킹한다. 흔히 redaction이라고 부르는 이 처리는 응답 후처리가 아니라 입력 전처리여야 한다. 모델이 보지 않은 정보는 유출할 수 없다.
셋째, 정책 검사를 한다. 사용자가 요청한 작업이 금지된 행동인지, 도구 호출이 위험한 변경을 일으키는지, 사람이 승인해야 하는 단계인지 판단한다. 특히 결제, 삭제, 권한 변경, 외부 발송 같은 도구는 모델의 자연어 판단만으로 실행해서는 안 된다.
넷째, 데이터 최신성 검사를 한다. 문서에는 작성일, 갱신일, 만료일, 데이터 기준 시점이 있어야 한다. 오래된 가격표, 폐기된 정책, 이전 버전 API 문서가 검색 결과로 들어오면 모델은 그럴듯하게 틀린 답을 만든다. 최신성이 중요한 도메인에서는 검색 점수보다 날짜와 상태값이 더 중요할 수 있다.
다섯째, 충돌 검사를 한다. 두 문서가 서로 다른 정책을 말한다면 컴포저는 둘 다 그대로 넣고 모델에게 알아서 판단하라고 맡기지 말아야 한다. 최신 문서를 우선하거나, 권위 있는 소스를 우선하거나, "충돌이 있으므로 확인 필요" 상태로 라우팅해야 한다.
이 단계는 응답 품질보다 더 근본적인 안전장치다. 모델은 컨텍스트 안의 정보를 근거로 답한다. 그러므로 컨텍스트에 들어가기 전의 문이 가장 중요하다.
기록 가능한 컨텍스트가 운영 가능한 컨텍스트다
마지막 단계는 기록이다. 프로덕션에서 재현할 수 없는 오류는 고치기 어렵다. 따라서 매 요청마다 최종 프롬프트 전체를 무작정 저장하기보다, 컨텍스트를 구성한 조각의 ID와 메타데이터를 남겨야 한다.
기록해야 할 항목은 다음과 같다.
요청 ID, 사용자 ID 또는 익명화 ID, 세션 ID
선택된 모델과 라우팅 이유
각 슬롯의 토큰 수와 예산 초과 여부
검색 쿼리, 검색 소스, 문서 ID, 점수, 필터 조건
포함된 메모리 ID와 갱신 여부
사용 가능한 도구 목록과 실제 호출된 도구
민감정보 마스킹/삭제, 권한 필터, 정책 검사 결과
캐시 키, 캐시 적중 여부, 지연시간, 비용
최종 응답과 사용자 피드백
이런 기록은 다음 장에서 다룰 평가와 관측성의 기반이 된다. 컨텍스트 인식 로깅 프로젝트들이 요청 단위의 넓은 이벤트를 남기고, 그 로그를 다시 RAG 분석에 활용하려는 이유도 여기에 있다5. 컨텍스트 파이프라인은 생성 시스템인 동시에 관측 가능한 데이터 시스템이어야 한다.
좋은 프로덕션 파이프라인은 모델 앞에서 끝나지 않는다. 모델 호출 전에는 조립하고 검증한다. 호출 중에는 비용과 지연시간을 관리한다. 호출 후에는 어떤 컨텍스트가 어떤 결과를 만들었는지 기록한다.
이 장의 핵심은 단순하다. 컨텍스트 엔지니어링은 문서 작성 기술이 아니다. 매 요청마다 필요한 정보를 선택하고, 예산에 맞게 압축하고, 안전하게 검증하고, 재현 가능하게 기록하는 런타임 정보 조립 파이프라인이다. 이 파이프라인을 갖춘 팀만이 AI 서비스를 데모에서 운영으로 옮길 수 있다.
참고
1IBM, What Is Context Engineering?
2Context Assembly Layer GitHub Repository
3Google Developers Blog, Architecting efficient context-aware multi-agent framework for production
4MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.