나 역시 이와 비슷한 경험을 했음. 특히 Gemini Pro를 사용할 때 긴 텍스트 레퍼런스를 제공하면, 여러 문서를 한 번에 컨텍스트 윈도우에 넣는 것보다 먼저 각 문서를 요약해서 질문을 한 다음, 필요하면 세부 문서 전체를 RAG 스타일 또는 간단한 에이전트 루프로 제공하는 것이 훨씬 더 좋은 답변을 얻을 수 있었음. 비슷하게 Claude Code를 Opus나 Sonnet과 함께 쓸 때도, 컴팩션(compaction)이 많이 일어날수록 결과가 나빠지는 걸 직접 경험함. 요약의 질이 떨어져서 그런 건지, 아니면 컨텍스트 윈도우 내에 덜 관련된 데이터 비중이 높아져서 그런 건지는 확실하지 않지만, 컨텍스트를 비우고 관련 파일만 다시 읽으라고 하면 (이전 요약에서 이미 언급됐다 해도) 훨씬 더 결과가 괜찮았음
Gemini는 챗 컨텍스트 한계에 이르기 전에 이미 일관성과 추론력에서 무너지기 시작함. 그런데도 이 보고서에 따르면 여러 면에서 최고 모델임. 결론은 컨텍스트 엔지니어링이 여전히 중요하고, RAG 접근법도 여전히 유효함
"컴팩션"은 결국 트랜스크립트를 요약으로 단축하는 것 아닌가? 그렇다면 정보가 실제로 손실되기 때문에 성능이 나빠지는 건 당연함. 하지만 이건 컨텍스트 로트(context rot) 때문이 아님. 진짜 컨텍스트 로트 신호는 오토-컴팩트(자동 축약) 임계점에 다가갈 때 나타남. 내가 제대로 이해하고 있는 것 같음?
최적의 코딩 에이전트라면 이런 과정을 자동으로 해줄 것 같음. 필요한 코드, MCP 응답, 레포 맵 등을 수집해서 가끔 요약하고, 모두를 새로운 챗 메시지로 합쳐서 정말 필요한 부분만 남겨놓는 식임. 난 aider라는 도구로 이미 이런 스타일을 쓰고 있는데, 많은 컨텍스트가 필요한 상황에선 에이전틱하거나 자동화된 워크플로보다 훨씬 성능이 좋았음. 단, 손이 많이 감
NotebookLM을 써봤는지? 이 앱은 백그라운드에서 문서를 쪼개고 요약해주며, RAG를 통해 전체 문서에 챗 형태로 질문할 수 있음
Cursor에서 새로운 기능이나 코드 변경에 대해 오랜 시간 대화할수록 결과물이 점점 안 좋아지는 것을 경험함. 가장 좋은 결과는 명확하고 구체적인 지침과 계획을 먼저 세우고, 수정할 파일들을 컨텍스트 프롬프트에 직접 끌어다 놓았을 때 나왔음
"Explore → plan → code → test → commit" 흐름으로 진행하는 게 훨씬 더 도움이 되었음. 필요하다면 각 단계마다 컨텍스트를 클리어해서 효과를 높일 수 있음
특정 작업을 위한 충분한 정보가 모이면, 그때 컨텍스트를 저장함. 품질이 떨어지는 게 보이면, 지금까지의 작업을 다시 요약해서 이전 체크포인트에 덧붙임
이 현상은 잘 알려져 있지만 제대로 문서화된 곳이 별로 없어서 이번 글이 매우 반가움. 벤치마크로 쉽게 측정하기 힘들 정도로 실질적 영향이 더 크다고 생각함. 진짜 쓸모 있는 LLM 기반 앱들은 모델이 해낼 수 있는 한계점에 머물러 있음. 즉, 실제 질문이나 작업에서 논리적으로 몇 번씩 "점프"해야 하는 컨텍스트를 따라가야 할 때 의미가 큼. 여러 번의 논리적 "점프"가 필요할수록 컨텍스트 로트 문제가 폭발적으로 심해진다고 생각함. 각 점프마다 주의해야 할 대상이 늘어나기 때문임
컨텍스트를 손쉽게 잘라낼 방법이 꼭 필요함. 모델과 전체 대화를 내가 직접 관리할 수 있으면, 대략 20만 토큰짜리 코딩 세션에서 훨씬 더 많은 퍼포먼스를 뽑아낼 수 있을 것 같음. 그런데 현실은 좋은 인스턴스를 쓰더라도 2만 토큰쯤 지나면 모델이 자꾸 이상해지고, 세션도 완전히 로트됨. 그냥 이 부분을 잘라내버릴 수 있으면 좋겠음
로컬 LLM은 원하는 대로 컨텍스트를 편집할 수 있어서, LLM의 응답 자체를 수정해 두면 나중에 모델이 자신이 원래 말한 것처럼 착각할 수도 있음. 그래서 원하는 방향으로 유도하는 데 유리함. 반면 LLM-as-a-service 모델은 이런 기능을 제공하지 않는데, 검열 우회를 쉽게 만들 수 있기 때문임
"헤이 Claude, 이제 컨텍스트를 리셋할 건데 앞으로 계속 작업할 수 있도록 프롬프트 하나 만들어줘"라고 요청한 뒤, Claude가 제안한 프롬프트를 미리 살펴보고 다듬어서 다시 넣는 실험을 해봤음
이전 체크포인트로 쉽게 롤백할 수 있으면 정말 최고의 기능일 것 같음
대부분의 CLI 에이전트에서는 /compress 명령어로 이런 작업을 할 수 있음
Claude code를 쓰다 보면 점점 자신의 실수와 내 지시를 구분하지 못함. 헷갈리기 시작하면, 세션을 새로 여는 게 답임. 세션이 길어질수록 같은 루프를 돌거나 스스로 테스트가 이미 깨졌다고 우겨서 무시해버림(실제로는 이 세션에서 깨졌는데도). 내가 프롬프트를 잘못 넣은 탓이겠지만, 요즘 Claude가 어느샌가 30 IQ 정도 떨어진 것 같음
나도 똑같이 느낌. 맥스 플랜인데도 성능 좋을 때와 안 좋을 때가 확실히 있음
"내 프롬프트와 컨텍스트가 문제겠지"라고 생각하는 거, 우리 모두 내면화된 가스라이팅 느낌임
이건 정보 검색 문제의 한 유형이지만, 컨텍스트 길이 변화에 의한 성능 저하는 단순 검색 답변과 다르게 작동할 수 있다고 생각함. 예를 들어 “이 버튼을 빨갛게 수정하려면?” 같은 질문이나 “위의 문장들은 어떤 카테고리에 속하는가?” 같은 문제에서는 다르게 동작할 수 있음. 예전에 인상적이었던 논문으로 Many-Shot In-Context Learning 있었음. 이 연구에선 예시로 컨텍스트를 채울수록 성능이 크게 뛰는 현상을 보임. 결국 문제마다 실제로 직접 테스트해봐야 LLM이 컨텍스트 내용과 길이에 따라 어떻게 바뀌는지 알 수 있음. 항상 컨텍스트 길이가 길어지면 성능이 낮아진다고 가정하면 안 됨
내 직관상 추론이 필요한 질문은 단순 검색 질문보다 예외 없이 항상 성능이 낮음. 특히 부정형 질문이나 덜 관련된 정보가 포함되어 있을 땐 더함. 그래도 직관이 데이터는 아니라는 점, 실제 숫자가 궁금함. In-context learning 현상은 장문 컨텍스트로 인한 성능 저하와 별개임. 두 현상은 동시에 존재함. 'lost-in-the-middle' 문제처럼, 예시 위치에 따라 성능이 달라질 수 있음
내용이 매우 쿨하고 통찰 많은 기사임. 다만 미디어 리터러시 관점에서 Chroma는 벡터DB 회사라는 점을 참고하면 좋겠음
Chroma는 벡터, 전체 텍스트, 정규식 검색까지 모두 지원함. 그리고 AI 애플리케이션에서 많이 쓰는 멀티테넌트 워크로드 환경에 최적임. 단순 벡터DB만 하는 회사가 아님
최근 Gemini 2.5 Flash로 장편 소설을 여럿 썼는데, 컨텍스트 로트는 분명히 느껴지지만 이 기사에서 제시한 것보다 훨씬 더 나중에 나타남. 내 경우 5만~10만 토큰 정도 지나야 초반 컨텍스트(예: 출력 언어 등)를 무시하기 시작했음. 아마 창작 같은 복잡한 태스크는 효과 측정이 더 어렵거나 덜 뚜렷할 수도 있음. 어쨌거나, 가끔 빠진 컨텍스트만 다시 넣어주면 쓸 만한 수준은 유지함
소설 얘기 좀 더 듣고 싶음. 재밌게 잘 나왔는지, 출간 계획은 있는지 궁금함
나도 비슷하게 경험함. 프로젝트 중 영상 트랜스크립트 검색기능을 개발하는데, 텍스트 길이가 아주 길었음. GPT 4.1 같은 모델이 컨텍스트 윈도우가 크니까 RAG가 필요 없을 줄 알았는데, 특히 작은 모델에서 이상한 현상이 자주 발생했음. 질문에 제대로 답변하지 않고, 그냥 콘텐츠 전체 요약만 하는 경우가 있었음
흥미로운 리포트임. 모델별로 추천하는 컨텍스트 크기 같은 게 있는지 궁금함. 내 유스케이스에 어느 선까지가 적절한지 알 수 있는 방법이 있는지 알고 싶음
Hacker News 의견
나 역시 이와 비슷한 경험을 했음. 특히 Gemini Pro를 사용할 때 긴 텍스트 레퍼런스를 제공하면, 여러 문서를 한 번에 컨텍스트 윈도우에 넣는 것보다 먼저 각 문서를 요약해서 질문을 한 다음, 필요하면 세부 문서 전체를 RAG 스타일 또는 간단한 에이전트 루프로 제공하는 것이 훨씬 더 좋은 답변을 얻을 수 있었음. 비슷하게 Claude Code를 Opus나 Sonnet과 함께 쓸 때도, 컴팩션(compaction)이 많이 일어날수록 결과가 나빠지는 걸 직접 경험함. 요약의 질이 떨어져서 그런 건지, 아니면 컨텍스트 윈도우 내에 덜 관련된 데이터 비중이 높아져서 그런 건지는 확실하지 않지만, 컨텍스트를 비우고 관련 파일만 다시 읽으라고 하면 (이전 요약에서 이미 언급됐다 해도) 훨씬 더 결과가 괜찮았음
Gemini는 챗 컨텍스트 한계에 이르기 전에 이미 일관성과 추론력에서 무너지기 시작함. 그런데도 이 보고서에 따르면 여러 면에서 최고 모델임. 결론은 컨텍스트 엔지니어링이 여전히 중요하고, RAG 접근법도 여전히 유효함
"컴팩션"은 결국 트랜스크립트를 요약으로 단축하는 것 아닌가? 그렇다면 정보가 실제로 손실되기 때문에 성능이 나빠지는 건 당연함. 하지만 이건 컨텍스트 로트(context rot) 때문이 아님. 진짜 컨텍스트 로트 신호는 오토-컴팩트(자동 축약) 임계점에 다가갈 때 나타남. 내가 제대로 이해하고 있는 것 같음?
최적의 코딩 에이전트라면 이런 과정을 자동으로 해줄 것 같음. 필요한 코드, MCP 응답, 레포 맵 등을 수집해서 가끔 요약하고, 모두를 새로운 챗 메시지로 합쳐서 정말 필요한 부분만 남겨놓는 식임. 난 aider라는 도구로 이미 이런 스타일을 쓰고 있는데, 많은 컨텍스트가 필요한 상황에선 에이전틱하거나 자동화된 워크플로보다 훨씬 성능이 좋았음. 단, 손이 많이 감
NotebookLM을 써봤는지? 이 앱은 백그라운드에서 문서를 쪼개고 요약해주며, RAG를 통해 전체 문서에 챗 형태로 질문할 수 있음
Cursor에서 새로운 기능이나 코드 변경에 대해 오랜 시간 대화할수록 결과물이 점점 안 좋아지는 것을 경험함. 가장 좋은 결과는 명확하고 구체적인 지침과 계획을 먼저 세우고, 수정할 파일들을 컨텍스트 프롬프트에 직접 끌어다 놓았을 때 나왔음
"Explore → plan → code → test → commit" 흐름으로 진행하는 게 훨씬 더 도움이 되었음. 필요하다면 각 단계마다 컨텍스트를 클리어해서 효과를 높일 수 있음
특정 작업을 위한 충분한 정보가 모이면, 그때 컨텍스트를 저장함. 품질이 떨어지는 게 보이면, 지금까지의 작업을 다시 요약해서 이전 체크포인트에 덧붙임
이 현상은 잘 알려져 있지만 제대로 문서화된 곳이 별로 없어서 이번 글이 매우 반가움. 벤치마크로 쉽게 측정하기 힘들 정도로 실질적 영향이 더 크다고 생각함. 진짜 쓸모 있는 LLM 기반 앱들은 모델이 해낼 수 있는 한계점에 머물러 있음. 즉, 실제 질문이나 작업에서 논리적으로 몇 번씩 "점프"해야 하는 컨텍스트를 따라가야 할 때 의미가 큼. 여러 번의 논리적 "점프"가 필요할수록 컨텍스트 로트 문제가 폭발적으로 심해진다고 생각함. 각 점프마다 주의해야 할 대상이 늘어나기 때문임
컨텍스트를 손쉽게 잘라낼 방법이 꼭 필요함. 모델과 전체 대화를 내가 직접 관리할 수 있으면, 대략 20만 토큰짜리 코딩 세션에서 훨씬 더 많은 퍼포먼스를 뽑아낼 수 있을 것 같음. 그런데 현실은 좋은 인스턴스를 쓰더라도 2만 토큰쯤 지나면 모델이 자꾸 이상해지고, 세션도 완전히 로트됨. 그냥 이 부분을 잘라내버릴 수 있으면 좋겠음
로컬 LLM은 원하는 대로 컨텍스트를 편집할 수 있어서, LLM의 응답 자체를 수정해 두면 나중에 모델이 자신이 원래 말한 것처럼 착각할 수도 있음. 그래서 원하는 방향으로 유도하는 데 유리함. 반면 LLM-as-a-service 모델은 이런 기능을 제공하지 않는데, 검열 우회를 쉽게 만들 수 있기 때문임
"헤이 Claude, 이제 컨텍스트를 리셋할 건데 앞으로 계속 작업할 수 있도록 프롬프트 하나 만들어줘"라고 요청한 뒤, Claude가 제안한 프롬프트를 미리 살펴보고 다듬어서 다시 넣는 실험을 해봤음
이전 체크포인트로 쉽게 롤백할 수 있으면 정말 최고의 기능일 것 같음
대부분의 CLI 에이전트에서는 /compress 명령어로 이런 작업을 할 수 있음
Claude code를 쓰다 보면 점점 자신의 실수와 내 지시를 구분하지 못함. 헷갈리기 시작하면, 세션을 새로 여는 게 답임. 세션이 길어질수록 같은 루프를 돌거나 스스로 테스트가 이미 깨졌다고 우겨서 무시해버림(실제로는 이 세션에서 깨졌는데도). 내가 프롬프트를 잘못 넣은 탓이겠지만, 요즘 Claude가 어느샌가 30 IQ 정도 떨어진 것 같음
나도 똑같이 느낌. 맥스 플랜인데도 성능 좋을 때와 안 좋을 때가 확실히 있음
"내 프롬프트와 컨텍스트가 문제겠지"라고 생각하는 거, 우리 모두 내면화된 가스라이팅 느낌임
이건 정보 검색 문제의 한 유형이지만, 컨텍스트 길이 변화에 의한 성능 저하는 단순 검색 답변과 다르게 작동할 수 있다고 생각함. 예를 들어 “이 버튼을 빨갛게 수정하려면?” 같은 질문이나 “위의 문장들은 어떤 카테고리에 속하는가?” 같은 문제에서는 다르게 동작할 수 있음. 예전에 인상적이었던 논문으로 Many-Shot In-Context Learning 있었음. 이 연구에선 예시로 컨텍스트를 채울수록 성능이 크게 뛰는 현상을 보임. 결국 문제마다 실제로 직접 테스트해봐야 LLM이 컨텍스트 내용과 길이에 따라 어떻게 바뀌는지 알 수 있음. 항상 컨텍스트 길이가 길어지면 성능이 낮아진다고 가정하면 안 됨
내용이 매우 쿨하고 통찰 많은 기사임. 다만 미디어 리터러시 관점에서 Chroma는 벡터DB 회사라는 점을 참고하면 좋겠음
최근 Gemini 2.5 Flash로 장편 소설을 여럿 썼는데, 컨텍스트 로트는 분명히 느껴지지만 이 기사에서 제시한 것보다 훨씬 더 나중에 나타남. 내 경우 5만~10만 토큰 정도 지나야 초반 컨텍스트(예: 출력 언어 등)를 무시하기 시작했음. 아마 창작 같은 복잡한 태스크는 효과 측정이 더 어렵거나 덜 뚜렷할 수도 있음. 어쨌거나, 가끔 빠진 컨텍스트만 다시 넣어주면 쓸 만한 수준은 유지함
나도 비슷하게 경험함. 프로젝트 중 영상 트랜스크립트 검색기능을 개발하는데, 텍스트 길이가 아주 길었음. GPT 4.1 같은 모델이 컨텍스트 윈도우가 크니까 RAG가 필요 없을 줄 알았는데, 특히 작은 모델에서 이상한 현상이 자주 발생했음. 질문에 제대로 답변하지 않고, 그냥 콘텐츠 전체 요약만 하는 경우가 있었음
흥미로운 리포트임. 모델별로 추천하는 컨텍스트 크기 같은 게 있는지 궁금함. 내 유스케이스에 어느 선까지가 적절한지 알 수 있는 방법이 있는지 알고 싶음