긴 컨텍스트 관리 — lost in the middle과 압축 전략

긴 컨텍스트 관리는 모델의 컨텍스트 창(context window)에 무엇을, 얼마나, 어떤 순서로 넣을지를 다루는 문제다. 요즘 모델은 수십만~100만 토큰까지 받지만, "다 넣으면 다 잘 읽는다"는 착각은 위험하다. 창이 크다고 성능이 비례하지 않고, 넣는 방식에 따라 정확도와 비용이 크게 갈린다. 창을 넓히는 것과 잘 쓰는 것은 다른 문제다.

나는 컨텍스트 창이 커졌다는 소식에 신나서 관련 문서를 몽땅 밀어넣은 적이 있다. 결과는 실망스러웠다 — 답이 오히려 더 뭉툭해지고, 정작 중요한 근거를 흘려버렸다. 비용은 비용대로 나왔다. 그때부터 "얼마나 넣느냐"보다 "무엇을 어디에 넣느냐"를 고민하기 시작했다.

Lost in the Middle

가장 유명한 현상이 lost in the middle(중간에서 길을 잃음)이다. 긴 컨텍스트에 정보를 넣으면, 모델은 맨 앞과 맨 뒤의 정보를 잘 활용하는 반면 중간에 묻힌 정보는 놓치는 경향이 있다. 사람이 긴 목록에서 처음과 끝만 기억하는 것과 비슷하다.

그래서 검색된 근거 문서를 컨텍스트 한복판에 아무렇게나 쌓으면, 정답이 중간에 파묻혀 무시될 수 있다. 가장 중요한 문서는 앞쪽이나 뒤쪽 같은 눈에 띄는 위치에 배치하는 게 낫다.

실무적 함의는 분명하다. 많이 넣는 것보다 관련도 높은 것만 추려 넣는 게 낫다. 리랭커로 상위 몇 개만 남기고, 그것들을 관련도 순으로 배치하는 편이 무작정 top-50을 쏟아붓는 것보다 정확했다. 컨텍스트는 넓은 창고가 아니라 좁은 책상이라고 생각하면 판단이 쉬워진다.

컨텍스트를 줄이는 세 가지 도구

대화가 길어지거나 문서가 많아 창을 넘길 위험이 있을 때, 세 가지 접근을 상황에 맞게 쓴다.

가지치기는 이제 쓸모없어진 오래된 도구 출력이나 낡은 턴을 잘라낸다. 요약이 아니라 삭제라 구조는 남는다. 압축/요약은 앞쪽 대화를 요약으로 갈아끼워 자리를 확보한다 — 다만 요약 과정에서 세부가 날아갈 수 있으니, 무엇을 요약하고 무엇을 원문 유지할지 정하는 게 중요하다. 외부 메모리(또는 RAG)는 애초에 다 넣지 않고 필요할 때만 검색해 가져오는 방식이다. 셋은 배타적이지 않고, 긴 에이전트는 셋을 함께 쓴다.

비용과 캐시 관점

컨텍스트를 크게 쓰면 매 요청 입력 토큰이 그만큼 늘어 비용이 커진다. 여기서 프롬프트 캐싱이 큰 지렛대가 된다. 시스템 프롬프트나 고정 문서처럼 매번 같은 앞부분을 캐시해두면, 반복 요청에서 그 부분은 훨씬 싸게 처리된다. 단, 캐싱은 접두사(prefix) 일치라서 앞부분의 한 글자만 바뀌어도 그 뒤 캐시가 전부 무효화된다.

# 자주 저지르는 캐시 파괴: 시스템 프롬프트에 현재 시각을 박음
system = f"오늘은 {datetime.now()}입니다. ..."   # ← 매 요청 프리픽스가 달라짐
# 개선: 고정 내용은 앞에 두고, 변하는 값은 뒤쪽 메시지로 뺀다

그래서 컨텍스트 설계와 캐시 설계는 한 몸이다. 안정적인 내용(고정 지시, 참고 문서)을 앞에, 매번 바뀌는 값(타임스탬프, 이번 질문)을 뒤에 두면 캐시 적중률이 오른다. 나는 시스템 프롬프트에 무심코 넣은 현재 시각 하나 때문에 캐시가 한 번도 안 걸렸던 걸 뒤늦게 발견하고 허탈했던 적이 있다.

자주 묻는 질문

컨텍스트 창이 크면 그냥 다 넣으면 되지 않나요?

권하지 않는다. lost in the middle 때문에 중간 정보가 무시되기 쉽고, 관련 없는 내용이 답을 흐리며, 입력 토큰이 늘어 비용과 지연도 커진다. 창이 크더라도 관련도 높은 것만 추려 넣는 편이 정확도·비용 모두에서 유리한 경우가 많다.

중요한 문서는 어디에 배치하나요?

모델이 상대적으로 잘 활용하는 앞쪽이나 뒤쪽에 두는 게 안전하다. 리랭킹으로 관련도 순위를 매긴 뒤, 가장 관련 높은 문서를 눈에 띄는 위치에 배치하는 방식이 실무에서 무난했다. 정답 근거를 여러 문서 한복판에 뒤섞어 넣는 배치는 피하는 게 좋다.

압축(요약)과 가지치기 중 뭘 써야 하나요?

낡은 도구 결과처럼 더는 쓸모없는 내용이 쌓이는 상황이면 가지치기(삭제)가 깔끔하다. 창 한도에 다다라 대화 전체를 줄여야 하면 요약이 필요하다. 다만 요약은 세부 정보를 잃을 수 있으니, 반드시 남겨야 할 원문은 요약 대상에서 빼는 판단이 필요하다. 긴 세션에서는 둘을 함께 쓴다.

프롬프트 캐시가 왜 자꾸 안 걸리죠?

캐시는 접두사 일치라, 앞부분에 매 요청 바뀌는 값(현재 시각, 랜덤 ID, 정렬 안 된 JSON)이 있으면 그 뒤가 전부 무효화된다. 고정 내용을 앞에, 변하는 값을 뒤로 옮기면 해결되는 경우가 많다. 캐시 적중 여부는 응답의 사용량 정보(캐시 읽기 토큰)로 확인할 수 있다.