컨텍스트 엔지니어링: 긴 AI 대화가 부정확해지는 이유와 해결법

컨텍스트 엔지니어링에서 살펴봐야 할 문제 중 하나는 컨텍스트 로트(context rot)입니다. 에이전트에 입력한 내용이 명시된 컨텍스트 윈도우 안에 들어가더라도 정확도는 떨어질 수 있습니다. 언어 모델 18개를 분석한 Chroma 연구에서는 입력 길이에 따라 신뢰성이 달라졌습니다. 실무에서는 다음 행동에 필요한 근거를 보존하면서 관련 없는 대화 이력을 줄이는 방식으로 대응할 수 있습니다.

AI의 컨텍스트 로트란 무엇인가요?

컨텍스트 로트는 언어 모델에 제공하는 정보가 늘어날수록 신뢰성이 떨어지는 현상입니다. 사실을 놓치거나, 정보 사이의 관계를 잘못 짚거나, 이미 정한 결정을 따르지 않는 답변으로 나타날 수 있습니다. 모델이 긴 대화를 입력으로 받아들이더라도 그 내용을 정확하게 활용하기는 점점 어려워질 수 있습니다.

컨텍스트 윈도우는 모델이 요청을 처리할 때 사용할 수 있는 작업 공간입니다. 여기에는 지시사항, 대화 이력, 문서, 툴 실행 결과가 들어갈 수 있습니다. 토큰은 모델이 처리하는 콘텐츠의 단위로, 단어의 일부인 경우가 많습니다. 어떤 내용이 이 공간을 차지하는지는 컨텍스트 윈도우 가이드에서 설명합니다.

장애 대응 상황실을 떠올려 보겠습니다. 벽에는 현재 계획뿐 아니라 폐기한 가설, 더 이상 유효하지 않은 경과 기록, 오래된 로그까지 붙어 있습니다. 벽을 넓히면 자료를 더 많이 붙일 수는 있습니다. 하지만 다음에 들어온 사람이 어떤 결정을 따라야 하는지까지 알려 주지는 않습니다.

에이전트를 디버깅할 때는 이 차이를 구분해야 합니다. 모델에 요청이 전달되기 전에 필요한 사실이 빠졌다면 입력 잘림이나 검색 과정을 점검해야 합니다. 사실이 입력에 있었는데도 답변에서 놓치거나 잘못 활용했다면 모델이 주어진 컨텍스트를 어떻게 처리했는지 살펴봐야 합니다. 어느 쪽이든 그 증상만으로 입력 길이가 원인이라고 단정할 수는 없습니다.

문서 확인일: 2026년 10월 24일. 아래에서 소개하는 제공사 지침은 Anthropic의 공개된 최신 문서와 대조했습니다. 워크플로 예시는 설계 제안이며, 실제 운영 성과를 보고한 사례가 아닙니다.

컨텍스트 로트 연구에서 확인한 사실

2025년 7월 14일 발표된 Chroma 보고서는 의미상 대응 관계를 파악하기 어렵거나 관련 있어 보이는 방해 정보가 섞일수록 긴 입력에서 정보를 찾아내는 작업의 신뢰성이 낮아졌다고 밝혔습니다. 통제된 과제로 얻은 결과는 유용한 근거이지만, 여러분의 에이전트 성능을 측정한 벤치마크는 아닙니다. 연구 원문.

Chroma는 정제한 LongMemEval 대화 벤치마크에서 평균 약 113,000토큰인 306개 프롬프트와, 관련 내용에 집중하도록 줄인 평균 약 300토큰의 입력을 비교했습니다. 평가 대상 모델 모두에서 필요한 내용에 집중한 입력의 점수가 더 높았습니다. 다만 이 짧은 입력은 관련성이 표시된 구절을 골라 수작업으로 조정한 결과입니다. 자동 검색 시스템을 평가해 얻은 결과가 아니라는 점이 중요합니다. 연구 방법과 결과.

Chroma의 연구 결과는 어디까지 적용할 수 있나요?

이 보고서는 현상의 근본 원인을 규명하지 않으며, 모든 상황에서 안전한 토큰 수를 제시하지도 않습니다. 반복 텍스트 실험은 짧은 답을 찾는 검색 실험과 달리 입력이 늘면 출력도 함께 늘어납니다. 연구의 한계와 과제 설명.

개발자에게 중요한 질문은 자신의 시스템이 필요한 근거를 찾아 보존할 수 있느냐는 것입니다. 엄선한 근거와 전체 이력을 비교한 차트만으로는 실제 검색 인덱스, 필터, 요약기가 그 근거를 제대로 골라낼지 알 수 없습니다. 근거를 선택하는 과정은 별도로 평가해야 합니다.

컨텍스트가 길어지면 왜 활용하기 어려워질까요?

관련 자료를 주변의 다른 정보와 구분할 수 있어야 합니다. 오래된 배포 계획은 전혀 무관한 문서보다 현재 계획과 더 비슷해 보일 수 있습니다. 문장 하나를 찾지 못하는 것만이 문제가 아닙니다. 지금 상황에 맞지 않는 문장을 적용할 위험도 있습니다.

Anthropic의 컨텍스트 엔지니어링 지침은 아키텍처의 제약과 주로 짧은 시퀀스로 이루어진 학습을 긴 컨텍스트 처리의 어려움에 영향을 주는 요인으로 설명합니다. 특정 경계를 넘는 순간 능력이 사라지기보다는 정밀도가 서서히 떨어진다는 설명입니다. 현상을 이해하는 데 참고할 설명이지, 인과관계 전체를 입증한 것은 아닙니다.

고객 지원 에이전트의 이력에 초기 진단, 실패한 우회 조치, 나중에 확인한 해결책이 함께 있다고 가정해 보겠습니다. 이후 툴 호출에서 이전 버전의 문제 해결 가이드를 가져오면, 다음 답변을 작성할 때 정보의 선후 관계와 어느 출처를 우선할지 모두 판단해야 합니다. 사용자의 질문은 그대로인데 텍스트가 늘면서 판단은 더 복잡해졌습니다.

이 판단에 필요한 정보를 명시해야 합니다. 현재 상태를 적고, 이전 진단은 기각되었다고 표시하며, 채택한 해결책을 뒷받침하는 출처를 남깁니다. 목표는 프롬프트를 무조건 짧게 만드는 것이 아니라, 상태가 분명한 근거를 충분히 제공하는 것입니다.

개발자와 운영자는 무엇부터 점검해야 할까요?

모델을 탓하기 전에 같은 판단을 서로 다른 컨텍스트로 비교해야 합니다. 개발자라면 애플리케이션이 실제로 구성한 요청을 기록해야 한다는 뜻입니다. 화면에 보이는 대화 기록에는 모델로 전달된 시스템 지시사항, 검색 결과, 툴 응답이 빠져 있을 수 있습니다.

운영자라면 놓친 요구사항이나 잘못된 행동을 구체적으로 짚어야 합니다. “대화 품질이 떨어진 것 같다”는 진술은 조사하기 어렵습니다. “장애 기록에서 이미 기각한 우회 조치를 다시 권했다”는 진술이라면 같은 상황을 재현해 볼 수 있습니다.

저장해 둔 사례에 다음 진단 순서를 적용합니다.

1. 1

   판단 조건을 고정합니다

   질문, 모델 설정, 충족해야 할 결과를 고정합니다. 원래 입력과 판단의 기준이 되는 근거를 저장합니다. 비교 과정에서 사례 자체가 바뀌지 않도록 외부 동작을 실제로 실행하지 않는 방식으로 재현합니다.

2. 2

   근거가 실제로 전달되었는지 확인합니다

   실제 요청에서 필요한 구절을 찾습니다. 없다면 검색, 입력 잘림, 상태 불러오기부터 고칩니다. 대신 오래된 출처가 전달되었다면 출처 선택과 최신성 관리를 바로잡습니다.

3. 3

   필요한 내용에 집중한 비교 입력을 만듭니다

   동일한 작업 지시사항과 답에 필요한 근거를 모두 유지하면서, 관련 없는 이력과 더 이상 유효하지 않은 툴 결과를 제거합니다. 기대하는 정답을 넣거나 과제를 쉽게 바꾸면 안 됩니다. 대표적인 사례를 재현하며 정확성, 출처 활용, 제약 조건 준수 여부를 비교합니다.

4. 4

   실패 원인에 맞는 개선책을 고릅니다

   필요한 내용에 집중한 입력이 도움이 된다면 컨텍스트를 선택하고 구성하는 방식을 조사합니다. 두 입력 모두 실패한다면 과제, 지시사항, 근거의 품질, 모델의 역량을 점검합니다. 요약 이후부터 실패한다면 요약에서 무엇이 빠졌는지 살펴봅니다.

이 비교는 진단 방법이지, 길이만이 오류의 원인이었다는 증명은 아닙니다. 자료를 제거하면 구성도 함께 달라지기 때문입니다. 길이의 영향을 더 엄밀히 확인하려면 관련 근거와 그 배치를 통제한 상태에서 무관한 자료를 추가합니다. 우연히 잘된 재실행 한 번으로 일반화해서는 안 됩니다.

이력이 늘어날 때마다 예방할 수 있었던 실수가 반복된다면 개선에 나서야 합니다. 짧고 범위가 명확하며 정확성 검사를 통과하는 워크플로라면 단순한 설계를 유지해도 됩니다. 확인한 실패를 해결할 역할이 있을 때 오케스트레이션을 추가합니다.

컨텍스트 엔지니어링으로 에이전트의 컨텍스트 로트 줄이기

문제를 일으키는 자료의 성격에 맞춰 대응해야 합니다. 컨텍스트 압축은 누적된 이력을 관리하고, 검색은 근거를 선택하며, 하위 에이전트는 탐색 범위를 분리합니다. 배치 순서는 과제를 명확히 하고, 간결한 툴 응답은 불필요한 입력을 줄입니다. 서로 보완하는 수단이지만 실패하는 방식도 각각 다릅니다.

이력을 압축하되 작업 상태는 보존합니다

컨텍스트 압축(compaction)은 오래된 대화 내용을 작업을 이어 갈 수 있는 짧은 기록으로 대체하는 방식입니다. Anthropic의 현재 컨텍스트 압축 문서는 활성 컨텍스트를 작게 유지해야 하는 이유를 **“대화가 길어질수록 응답 품질이 저하됩니다”**라고 설명합니다. API는 애플리케이션이 요청하는 압축과, 설정한 토큰 임계값에 도달하면 시작하는 압축을 모두 지원합니다.

다음 행동에 필요한 내용을 중심으로 인계 기록을 설계합니다. 장애 대응 사례라면 현재 목표, 확인한 원인, 기각한 우회 조치와 그 이유, 남은 불확실성, 출처 위치, 다음 행동을 남깁니다. 정확성이 특정 식별자나 문구에 달려 있다면 그 내용을 그대로 보존합니다.

“문제를 조사했고 진전이 있었다”는 인계 기록만으로는 부족합니다. “우회 조치는 필수 동작을 깨뜨리므로 기각했으며, 채택한 해결책은 장애 문서에 기록되어 있고, 검증은 아직 남아 있다”는 기록이라면 유용합니다. 조사 과정을 모두 되풀이하지 않고도 다음 작업을 이어 갈 수 있기 때문입니다.

한계: 요약 과정에서 나중에 중요해질 세부사항을 버릴 수 있습니다. 원본 기록에 접근할 수 있게 유지하고, 작업을 재개한 에이전트가 그 세부사항이 필요한 질문에도 답할 수 있는지 평가합니다. 상태를 영속적으로 저장하는 일과 다시 불러올 내용을 고르는 일은 별개입니다. 이 차이는 에이전트 메모리 해설에서 다룹니다.

과제에 필요할 때 근거를 검색합니다

큰 자료는 참조 정보를 보관하고, 관련 부분을 필요할 때 불러옵니다. Anthropic은 이를 적시 컨텍스트(just-in-time context)라고 설명합니다. 에이전트가 파일 경로, 쿼리, 링크를 보관한 뒤 필요에 따라 자료를 가져오는 방식입니다. 컨텍스트 검색 지침.

장애 대응 에이전트라면 현재 장애 기록과 해당 서비스 문서에서 시작합니다. 진단에 필요해지면 과거 장애 사례를 가져옵니다. 각 구절에는 출처를 붙이고, 확인할 수 있다면 버전이나 날짜도 함께 반환합니다. 예외 조항을 이해할 수 있을 만큼의 주변 문맥도 포함합니다.

한계: 검색에서 결정적인 조항을 놓치거나, 그럴듯하지만 오래된 자료를 가져올 수 있습니다. 답변 품질을 측정하기 전에 필요한 근거가 실제로 있는지 검사합니다. 발췌문만으로 판단하기 어렵다면 에이전트가 검색 범위를 넓히거나 원문 전체를 읽을 수 있게 합니다.

검색 결과가 적다는 점은 판단에 필요한 내용이 보존될 때만 장점이 됩니다. “모두 밀어 넣지 말고 검색하라”는 자료 선택 원칙이지, 다루기 곤란한 맥락을 숨기라는 뜻이 아닙니다.

하위 에이전트에 범위가 명확한 과제와 독립된 컨텍스트를 줍니다

메인 에이전트에 탐색 과정의 원자료까지 필요하지 않다면 별도 컨텍스트에서 탐색하도록 합니다. Anthropic의 Claude Code 하위 에이전트 문서는 각자의 컨텍스트 윈도우에서 작업하고 결과를 메인 대화로 반환하는 에이전트를 설명합니다.

로그를 조사하는 하위 에이전트에는 구체적인 질문, 관련 서비스 정보, 로그 위치를 전달할 수 있습니다. 조사 결과, 이를 뒷받침하는 위치, 불확실성, 아직 해소하지 못한 의존 관계를 반환하도록 요청합니다. 메인 에이전트는 전체 탐색 이력을 떠안지 않고도 그 결과를 활용할 수 있습니다.

한계: 컨텍스트를 분리하면 공유하던 지식도 함께 사라집니다. 하위 에이전트에 필요한 제약 조건을 전달하고 결론과 함께 근거를 요구해야 합니다. 오케스트레이션 프레임워크가 실제로 무엇을 전달하는지 확인합니다. 상위 에이전트의 이력을 통째로 복사한다면 분리하려던 목적이 무너집니다. 모든 하위 에이전트의 대화 기록을 다시 상위 에이전트에 붙여 넣어도 그곳에 같은 혼잡이 생깁니다.

이 방식은 분리 가능한 조사에 활용합니다. 공유 기록에 밀접하게 의존하는 판단이라면 메인 컨텍스트에서 필요한 자료를 골라 검색하는 편이 더 쉬울 수 있습니다.

문서와 현재 요청의 배치 순서를 설계합니다

현재 과제와 이를 뒷받침하는 자료를 쉽게 구분할 수 있게 합니다. Anthropic의 긴 컨텍스트 프롬프팅 지침은 긴 문서를 프롬프트 상단에 두고 출처를 구분하며, 질문은 그 뒤에 배치할 것을 권합니다. 문서에 관한 질문에 답하기 전에 관련 인용문을 찾는 방법도 권장합니다.

애플리케이션에서는 작업을 통제하는 지시사항을 해당 지시 채널에 유지합니다. 과제 입력 안에서는 현재 장애 기록과 과거 메모를 구분해 표시한 다음, 질문과 요구하는 출력 형식을 명확히 적습니다. 검색한 텍스트의 위치를 옮겼다는 이유만으로 그 내용을 작업을 통제하는 지시사항으로 취급해서는 안 됩니다.

한계: 순서를 바꾼다고 처음부터 불러오지 않은 근거가 생기지는 않습니다. 어떤 배치도 모든 모델과 과제에서 효과를 보장하지 않습니다. 자체 사례로 배치를 비교합니다. 현재 과제를 간결하게 명시하는 것으로 충분하다면 매 대화 차례마다 규칙 문서 전체를 반복하지 않습니다.

툴 출력은 필요한 내용만 전달하고 원본에 접근할 수 있게 합니다

다음 판단에 필요한 결과를 반환하되 전체 결과물로 돌아갈 경로도 남깁니다. Anthropic의 툴 설계 지침은 의미 있는 응답과 함께 필터링, 페이지네이션, 잘라내기 같은 제어 수단을 권합니다. 별도의 컨텍스트 편집 문서에서는 대화 이력에서 오래된 툴 결과를 지우는 방법을 설명합니다.

검사에 실패했다면 실패 사실, 관련 오류 발췌문, 저장된 보고서의 위치를 반환합니다. 검색이라면 관련 구절과 출처를 반환합니다. 작업이 성공했다면 상태와 후속 작업에 필요한 식별자를 반환합니다. 툴이 보고서를 생성했다는 이유만으로 전체 내용을 입력에 넣지는 않습니다.

한계: 무작정 잘라내면 결정적인 오류나 단서까지 사라질 수 있습니다. 생략한 부분이 있음을 알리고 에이전트가 추가 내용을 요청할 수 있게 합니다. 나중에 점검해야 할 전체 출력은 활성 컨텍스트 밖에 보존합니다.

이러한 선택은 요청을 구성하는 계층에서 구현해야 합니다. 지시사항, 메모리, 툴, 검색한 자료가 어떻게 맞물리는지는 더 넓은 범위를 다루는 컨텍스트 엔지니어링 가이드에서 설명합니다.

컨텍스트 로트, 어디까지가 과장일까요?

모든 에이전트에 공통으로 적용할 수 있는 대화 초기화 시점은 없습니다. 메시지 수나 컨텍스트 윈도우 사용률만으로 정할 수 없다는 뜻입니다. 요청이 용량을 초과하지 않도록 막는 임계값은 용량 설정입니다. 특정 워크플로의 신뢰성이 떨어지는 시점은 실제 과제를 기준으로 측정해야 합니다.

긴 대화에서 나온 나쁜 답변이 모두 컨텍스트 로트를 입증하는 것도 아닙니다. 근거 누락, 상충하는 지시사항, 고장 난 툴, 지원하지 않는 과제도 비슷한 증상을 만들 수 있습니다. 유용한 장애 보고서는 어떤 판단이 실패했는지 명시하고 모델이 받은 내용을 기록합니다.

컨텍스트 압축은 무손실이 아니며, 외부 메모리가 관련성을 자동으로 보장하지도 않습니다. 둘 다 출력 검사가 필요한 구성 요소로 다뤄야 합니다. 잘못된 결론을 더 효율적으로 보존하면 워크플로가 일관되게 잘못된 결과를 낼 수 있습니다.

캐싱 역시 다른 목적의 수단입니다. KV 캐시는 어텐션 연산을 재사용합니다. 어떤 문서가 중요한지 판단하거나 오래된 이력을 제거하지는 않습니다. 캐싱이 잘된 요청이라도 다음 판단에 부적절한 자료를 담고 있을 수 있습니다.

이번 주에 적용할 짧은 점검 목록

같은 실패가 반복되는 에이전트에 다음을 적용합니다.

• 판단에 실패한 시점의 실제 입력을 저장하고, 필요했던 근거를 확인합니다.
• 요구사항을 바꾸지 않은 채 필요한 근거에 집중한 입력으로 과제를 재현하고, 대표적인 사례들에서 정확성을 비교합니다.
• 불필요한 정보가 가장 많은 툴 응답을 관련 발췌문과 전체 결과물의 위치로 대체합니다.
• 결정 사항, 기각한 접근법, 제약 조건, 출처, 미완료 작업을 보존하는 압축 인계 기록을 정의합니다.
• 탐색 과정에서 불필요한 정보가 쌓인다면, 분리 가능한 조사를 독립된 하위 에이전트 컨텍스트로 옮깁니다.
• 재개한 워크플로가 필요한 사실을 유지하면서 목표로 삼은 실패를 개선할 때만 변경 사항을 배포합니다. 이전 동작으로 되돌릴 수 있는 상태도 유지합니다.

재현할 수 있는 실패에서 시작합니다. 그러면 단순히 “컨텍스트가 줄었다”를 성공 기준으로 삼는 대신, 변경 사항의 효과를 판단할 명확한 인수 테스트를 마련할 수 있습니다.

컨텍스트 로트에 관한 자주 묻는 질문

컨텍스트 로트는 지금도 발생하나요?

Anthropic의 현재 컨텍스트 압축 문서는 대화가 길어질수록 응답 품질이 저하된다고 여전히 명시합니다. 컨텍스트를 계속 관리해야 한다는 근거는 되지만, 현재의 모든 모델이 어떻게 동작하는지 보여 주는 것은 아닙니다. 실제로 배포하는 모델과 워크플로를 평가해야 합니다.

컨텍스트 로트를 줄이려면 어떻게 해야 하나요?

현재 지시사항과 필요한 근거를 유지하고, 오래되거나 중복된 자료를 제거하며, 이력을 신중하게 압축하고, 필요할 때 세부사항을 검색합니다. 도움이 된다면 불필요한 정보가 많이 생기는 부수 작업을 분리합니다. 변경할 때마다 다음 행동에 필요한 사실이 보존되는지 확인합니다.

컨텍스트 로트의 원인은 무엇인가요?

컨텍스트 길이, 주변 자료의 관련성, 정보 제시 방식이 신뢰성에 영향을 줄 수 있습니다. 원 연구는 단일한 근본 원인을 규명하지 않았습니다. 에이전트에 적용할 개선책을 고르기 전에 제공된 근거와 작업 상태부터 살펴봐야 합니다.

AI 워크플로를 구축하고 운영하는 데 필요한 실용적인 가이드를 받아보려면 뉴스레터를 구독하세요.