컨텍스트 윈도우가 100만, 200만 토큰까지 커지면서 “이제 자료를 통째로 넣으면 AI가 알아서 다 읽겠지”라는 기대가 생겼습니다. 그런데 한 개발자는 정반대 경험을 합니다. AI에게 필요한 정보를 분명히 다 넣어줬고, 화면으로 그 정보가 컨텍스트 안에 그대로 있는 것까지 확인했는데, AI는 그걸 못 본 듯 텅 빈 껍데기 같은 결과만 내놨습니다.

O’Reilly의 Andrew Stellman이 컨텍스트 관리 시리즈에서 바로 이 현상을 파고들었습니다. 정보가 컨텍스트 윈도우 안에 멀쩡히 들어 있는데도 모델이 그걸 쓰지 못하는 실패, 이른바 “Lost in the Middle(중간에서 길을 잃다)” 문제입니다. 같은 시기에 RAG 시스템을 다룬 분석과, AI 에이전트로 실제 성과를 낸 PostHog의 사례도 서로 다른 입구에서 똑같은 결론에 도달했습니다. 컨텍스트는 많이 넣는 게 아니라 잘 골라 넣는 것이라는 결론입니다.

출처: So Long and Thanks for All the Context – O’Reilly Radar

중간을 잃어버리는 건 버그가 아니라 구조다

Stellman이 겪은 문제의 정체는 ‘U자 곡선’이었습니다. 모델은 컨텍스트의 맨 앞과 맨 뒤에 있는 정보는 잘 활용하지만, 가운데 묻힌 정보는 놓치는 경향이 있습니다. 정보 위치에 따른 성능을 그래프로 그리면 양 끝이 높고 중간이 푹 꺼진 U자 모양이 나옵니다.

이건 한 모델의 변덕이 아닙니다. 스탠퍼드의 Nelson Liu 연구팀은 「Lost in the Middle」 논문에서 정답을 문서의 여러 위치에 심어놓고 모델이 찾아내는지 측정했는데, 정답이 앞이나 끝에 있을 때 가장 잘 찾고 중간에 있을 때 성능이 뚝 떨어지는 현상이 여러 모델 계열에서 공통으로 나타났습니다. 학계는 앞쪽을 선호하는 성향을 primacy bias, 최근 정보를 선호하는 성향을 recency bias라 부르고, 이 둘을 합친 결과가 U자입니다.

더 흥미로운 건 최근 연구들이 이 U자를 학습 과정에서 생긴 부작용이 아니라 트랜스포머 구조 자체의 성질로 보기 시작했다는 점입니다. 한 연구는 학습이 전혀 이뤄지지 않은 무작위 가중치 상태, 즉 모델이 태어나는 순간부터 이미 U자가 존재한다는 걸 수학적으로 증명했습니다. 구조에서 비롯된 성질이라면 데이터를 더 붓거나 미세조정을 더 한다고 사라지지 않습니다. 우리가 계속 안고 가야 할 제약이라는 뜻입니다.

그래서 “컨텍스트 윈도우를 키우면 해결되지 않을까”라는 직관도 절반만 맞습니다. 긴 문서에서 문장 하나를 찾아내는 단순 검색은 윈도우가 커지면서 확실히 좋아졌습니다. 하지만 윈도우가 200만 토큰이 됐다는 건, 정보가 빠질 수 있는 중간 지대가 그만큼 넓어졌다는 뜻이기도 합니다.

양을 늘리면 오히려 나빠진다

같은 함정이 RAG(검색 증강 생성) 시스템에서도 그대로 반복됩니다. Techstrong.ai의 분석에 따르면, 많은 팀이 RAG의 실패를 검색 성능 문제로 보고 벡터 검색을 튜닝하는 데 매달리지만 진짜 문제는 그 위쪽, 즉 데이터 품질과 컨텍스트 조립 단계에 있습니다.

특히 눈에 띄는 지적이 컨텍스트의 양에 관한 부분입니다. 큰 컨텍스트 윈도우에 저품질 정보를 잔뜩 넣으면, 그 안에 정답이 섞여 있더라도 좋은 방법이 못 됩니다. 정작 필요한 세 덩어리를 두고도 모델이 깔끔하게 추론하던 것이, 그 세 덩어리가 별 관련 없는 서른 덩어리 사이에 묻히는 순간 신뢰할 수 없게 됩니다. 앞서 본 context rot, 곧 중간 정보 망각과 정확히 같은 현상입니다.

여기서 나오는 원칙이 재현율(recall)보다 정밀도(precision)입니다. 관련 있을 법한 걸 모조리 끌어오는 게 아니라, 딱 필요한 것만 가져오고 나머지는 빼는 것. 신호 대비 잡음 비율이 떨어질수록 모델의 추론 능력도 같이 떨어지기 때문입니다.

개인이 AI를 쓸 때 바로 적용되는 원칙

여기까지는 거대한 시스템 이야기처럼 들릴 수 있지만, Stellman이 정리한 실전 기법들은 개인이 Claude Code나 챗봇으로 작업할 때 그대로 적용됩니다.

1. 쌓지 말고 골라낸다. 긴 세션을 계속 이어가면 컨텍스트가 노후화됩니다. 중요한 내용을 따로 문서로 정리한 뒤, 새 세션을 그 문서로 다시 시작하는 편이 낫습니다. 이미 코드베이스를 ‘아는’ 세션은 새 지시를 대충 훑고 과거 가정대로 즉흥 처리하는 반면, 새 세션은 브리핑을 더 꼼꼼히 읽습니다.
2. 중요한 정보는 가장자리에 둔다. U자가 앞과 끝을 선호하니, 핵심 정보는 그 위치에 놓고 중간에는 덜 중요한 것을 둡니다.
3. 짧은 세션을 여러 번. 하나의 긴 세션 대신, 매번 디스크에서 새로 읽어오는 짧은 세션을 반복합니다. 상태를 파일에 적어두고 세션은 갈아 끼우는 소모품처럼 다루는 방식입니다.
4. 쓰는 지점 바로 옆에서 다시 말한다. 모델이 지금 적용해야 할 규칙은 지금 다시 진술합니다. 앞에서 한 지시가 중간을 통과해 끝까지 전달되리라 믿지 않는 것이죠. Stellman이 껍데기 결과를 고친 방법도 “기억으로 재구성하지 말고 파일을 다시 읽어라”는 한 줄을 행동 직전에 끼워 넣은 것이었습니다.
5. 중간을 검증한다. 에이전트가 안다고 주장하는 것과 디스크에 실제로 적힌 것을 매 단계 대조합니다. 둘이 어긋나면 그게 바로 신호입니다.

이 원칙이 실제로 성과를 낸다는 증거가 PostHog의 사례입니다. PostHog는 AI 온보딩 마법사를 만들며 처음엔 에이전트 계층을 정교하게 다듬는 데 집중했지만 개선은 미미했습니다. 효과가 컸던 건 잘 정제된 컨텍스트를 충분히 공급하는 쪽이었습니다. 흩어진 사내 지식을 모아 에이전트에 전달하는 체계를 갖춘 뒤, 마법사 사용자의 유료 전환율은 2.6%에서 14.2%로 약 5배, 활성화 속도는 2배가 됐습니다. 추론이 병목이 아니라 컨텍스트 공급이 병목이었던 셈입니다.

작업 기억은 믿을 게 못 된다

세 글을 관통하는 메시지는 하나로 모입니다. 모델의 작업 기억(working memory)은 본질적으로 믿을 게 못 되니, 중요한 정보는 그보다 더 오래가는 곳에 두어야 한다는 것입니다. 컨텍스트가 사라지는 문제(compaction)든, 멀쩡히 있는데 안 쓰이는 문제(U-shape)든 뿌리는 같고, 대응 원칙도 같습니다. 작업 집합을 작게 유지하고, 핵심은 가장자리에 놓고, 모델의 주장을 디스크의 진실과 대조하는 것.

컨텍스트 윈도우는 앞으로도 계속 커지고 압축 기술도 더 똑똑해질 겁니다. 일부 기법은 언젠가 불필요해질 수도 있습니다. 하지만 U자가 트랜스포머 구조에서 비롯된 기하학적 성질이라면, 이 제약 자체는 쉽게 사라지지 않습니다. 컨텍스트를 다루는 능력이 새로운 핵심 역량으로 떠오르는 이유입니다.

O’Reilly 원문은 다섯 가지 기법 각각에 실제 프롬프트와 디버깅 과정을 함께 담고 있어, 직접 적용해보려는 분께는 원문이 훨씬 구체적입니다.

참고자료:

• RAG Fails Upstream and Most Teams Are Fixing the Wrong Problem – Techstrong.ai
• We used context engineering to 5x conversion and 2x activation – PostHog
• Lost in the Middle: How Language Models Use Long Contexts – Nelson F. Liu 외, Stanford