ChatGPT가 이전에 말한 내용을 잊어버리는 이유
컨텍스트 창에는 끝이 있지만, 우리 눈에는 보이지 않습니다
모든 모델에는 최대 컨텍스트가 있습니다. 긴 대화는 결국 이 한계를 초과하게 되며, 이 시점에서는 무언가를 버려야 합니다. 최근 대화 내용을 채워 넣기 위해 이전 대화 차례가 누락되거나 압축됩니다.
인터페이스는 이를 보여주지 않습니다. 대화 스레드에는 모델의 시야가 시작되는 지점을 표시하는 선이 없습니다. 따라서 사용자 입장에서는 메시지가 눈에 뻔히 보이는데 무시당하는 것처럼 느껴지고, 모델 입장에서는 그 메시지가 존재하지 않는 것입니다. 이러한 불일치가 이 문제의 본질이며, 해결책이 항상 더 단호하게 말을 반복하는 것처럼 보이는 이유입니다.
컨텍스트 창 내부에서도 위치가 중요합니다
이 부분은 대부분의 사람들이 잘 모르는 사실이며, 대화 스레드가 분명히 컨텍스트 창 안에 들어맞는 경우를 더 잘 설명해 줍니다.
이 발견은 Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2023) 연구에서 비롯되었습니다. 연구진은 관련 정보의 위치를 이동시키면서 다중 문서 질의응답 및 키-값 검색을 테스트했으며, "관련 정보가 입력 컨텍스트의 시작이나 끝에 나타날 때 성능이 가장 높은 경우가 많고, 명시적으로 긴 컨텍스트를 지원하는 모델이라 할지라도 긴 컨텍스트의 중간에 있는 관련 정보에 액세스해야 할 때 성능이 크게 저하된다"고 보고했습니다.
이를 채팅에 대입해 보겠습니다. 초기 설정 지침은 시작 부분에 있으므로 좋은 위치입니다. 가장 최근 메시지는 끝 부분에 있으므로 좋은 위치입니다. 90개의 메시지 중 30번째 메시지에서 추가한 제약 조건은 중간에 위치하게 되며, 이는 입력에서 가장 취약한 위치입니다. 제약 조건 자체에 모호한 점은 없었습니다. 단지 시간이 흐르면서 위치가 나빠졌을 뿐입니다.
실제 유효 용량은 광고된 수치보다 작습니다
두 번째 효과는 명시된 컨텍스트 크기가 실제 작동 용량이 아니라 상한선이라는 점입니다.
RULER: What's the Real Context Size of Your Long-Context Language Models? (Hsieh et al., 2024) 연구는 단순한 '바늘찾기(needle-in-a-haystack)' 검색을 넘어 멀티홉 추적 및 집계를 포함하는 합성 벤치마크를 구축하고 17개의 롱 컨텍스트 모델을 평가했습니다. 그들의 결론은 다음과 같습니다. 기본적인 검색 테스트에서 거의 완벽한 점수를 받았음에도 불구하고, "거의 모든 모델이 컨텍스트 길이가 증가함에 따라 큰 성능 저하를 보였으며," 모델들이 모두 32K 토큰 이상을 지원한다고 주장했지만 "그중 절반만이 32K 길이에서 만족스러운 성능을 유지할 수 있었습니다."
이 평가는 2024년에 이루어진 것이고 특정 모델들은 이후 교체되었으므로, 이를 현재의 리더보드가 아닌 문제의 양상을 규명한 것으로 이해해야 합니다. 이 양상은 계속 유지되고 있습니다. 사양서에 적힌 숫자는 들어갈 수 있는 용량을 설명할 뿐, 모델이 잘 활용할 수 있는 용량을 의미하지 않습니다. 그리고 흩어진 정보 조각들을 가로질러 추론해야 하는 작업은 단순히 하나의 사실을 검색하는 작업보다 더 빨리 성능이 저하됩니다.
무엇이 누락되었는지 알려주지 않습니다
문제를 악화시키는 요인은 침묵입니다. 이전 대화 차례가 잘려 나가거나 압축될 때 어떠한 알림도 받지 못합니다. 긴 에이전트 세션에 대해 글을 쓰는 실무자들은 툴링 측면에서 동일한 현상을 설명합니다. 세션 초반의 지침이 무시되는 것이 아니라, 모델이 더 이상 그 지침에 안정적으로 도달할 수 없는 것입니다.
따라서 "제약 조건을 따르지 않았다"와 "제약 조건이 더 이상 모델의 시야에 없다"를 구분할 수 없으며, 이 두 가지 상황은 서로 반대되는 대응을 필요로 합니다. 전자는 더 명확한 지침을 요구합니다. 후자는 대화의 구조 조정을 요구하며, 아무리 강조해서 말해도 해결되지 않습니다.
사람들이 시도하는 방법들
지침 반복하기. 즉각적으로 효과가 있지만, 왜 그랬는지에 대해서는 아무것도 알려주지 않습니다. 또한 대화 스레드를 부풀려 다음 실패를 더 빨리 불러옵니다. 이것이 대부분의 사람들이 겪는 쳇바퀴 같은 상황입니다.
첫 번째 메시지에 중요한 모든 것을 넣기. 정말 영리한 방법입니다. 시작 부분은 강력한 위치이기 때문입니다. 하지만 대화 스레드가 너무 길어져 시작 부분이 잘려 나갈 때까지만 유효하며, 40번째 메시지쯤에서 발견하게 되는 제약 조건에는 도움이 되지 않습니다.
새 대화 시작하기. 가장 확실한 단일 조치이며, 숙련된 사용자들이 끊임없이 이 방법을 쓰는 이유입니다. 대가로 유용한 정보까지 모두 버려야 하므로, 성능이 저하된 스레드를 비어 있는 스레드와 맞바꾸는 셈입니다.
계속하기 전에 요약해 달라고 요청하기. 실제 사용되는 기술입니다. 제약 조건을 다시 서술하게 한 다음, 컨텍스트 끝부분에 있는 그 요약본을 바탕으로 작업하는 것입니다. 효과적이지만 손실이 발생합니다. 정보를 압축하는 과정에서 무엇을 버릴지는 모델이 결정하기 때문입니다.
고정된 부분에 맞춤 지침(Custom instructions) 사용하기. 과소평가되어 있지만 유용한 방법입니다. 대화 기록에 남아 있는 것이 아니라 매 요청마다 다시 제공되기 때문입니다. 용량이 작기 때문에 이번 작업의 세부 사항이 아니라 몇 가지 상시 규칙을 담아두기에 적합합니다. 제대로 활용할 가치가 있으며, 설정했지만 적용되지 않는 지침과는 다른 문제입니다.
문서 다시 업로드하기. 흔히 쓰이는 방법이며, 동일한 흐름에 맞서는 것입니다. 대화 중간에 업로드한 파일이 컨텍스트에서 벗어나는 현상은 파일 관점에서 본 동일한 메커니즘입니다.
모든 임시방편의 공통점을 주목해 보십시오. 모두 저장소로 사용되고 있는 대화 기록을 관리하려는 방식들입니다.
해결책: 대화를 저장소로 사용하는 것 중단하기
구조적인 실수는 대화 스레드를 기록 보관소로 취급하는 것입니다. 대화는 작업 공간입니다. 생각하기에는 좋지만 기억하기에는 나쁘며, 길어질수록 확실히 나빠집니다. 요구 사항이 메시지로만 존재하게 되면 위치 효과, 잘림, 압축의 영향을 받게 되며, 이 중 어느 것도 사용자가 직접 확인할 수 없습니다.
그러므로 요구 사항을 외부로 이동시키십시오. 제약 조건, 사양, 스키마, 결정을 어시스턴트가 읽을 수 있는 저장소에 보관하고, 각 대화는 짧고 일회성으로 유지하십시오. 짧은 스레드에는 정보가 유실될 '중간 영역'이 존재하지 않습니다.
이것이 솔직한 메커니즘이며, 이 방식이 할 수 있는 일과 할 수 없는 일을 명확히 짚고 넘어갈 필요가 있습니다. 메모리 레이어는 컨텍스트 창을 확장하거나 긴 입력 내에서 주의력(attention) 문제를 해결해 주지 않습니다. 그 어떤 것도 그렇게 할 수 없습니다. 이 방식이 바꾸는 것은 대화 스레드를 길게 유지할 필요가 없어진다는 점입니다. 지속되어야 할 자료는 매번 다시 말하는 대신 검색되어 제공되기 때문입니다. 따라서 모델이 불안정하게 작동하는 영역을 관리하느라 애쓰는 대신, 모델이 안정적으로 작동하는 영역에서 작업할 수 있게 됩니다.
MemoryLake는 이를 위한 메모리 레이어입니다. 문서, 제약 조건, 결정을 하나의 저장소에 보관하고, API를 통해 ChatGPT에서 읽거나 Claude 및 Codex 같은 MCP 지원 도구에서 직접 읽을 수 있습니다. 새로운 채팅에서도 동일한 지식을 활용하며, 90개의 메시지가 쌓인 스레드는 필요 없습니다.
1단계: API 키 생성하기
키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 키를 채팅 창에 붙여넣는 대신 환경 변수나 시크릿 관리자에 보관하십시오.
2단계: 첫 번째 메모리 업로드하기
현재 매번 다시 설명하고 있는 문서, 이미지, 파일을 업로드하십시오. 사양, 제약 조건, 스타일 가이드, 스키마, 결정 사항 등이 이에 해당합니다. 가능하면 요약본 대신 원본 소스를 업로드하십시오. 모든 것이 다른 무언가의 압축본이 되는 워크플로에서 벗어나는 것이 핵심 목표이기 때문입니다.
3단계: AI 및 에이전트 연결하기
Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하십시오. ChatGPT에는 MCP 클라이언트가 없으므로, API를 통해 필요한 정보를 검색하여 프롬프트, 맞춤형 GPT(Custom GPT)의 지침 또는 모델을 호출하는 워크플로에 주입하십시오. MCP를 지원하는 도구들은 동일한 저장소를 직접 읽습니다.
실제 업무에서 달라지는 점
첫 번째 차이점은 대화 스레드가 짧아진다는 것이며, 이것이 가장 큰 수확입니다. 각각 동일한 검색 컨텍스트에서 시작하는 10개의 짧은 대화가 중간에 성능이 저하되는 하나의 90개짜리 메시지 스레드보다 훨씬 낫습니다. 단순히 더 깔끔해서가 아니라, 짧은 입력이야말로 모델이 실제로 제 성능을 발휘하는 영역이기 때문입니다.
두 번째는 "잊어버린 것인가, 아니면 지시를 거부한 것인가?"에 대해 답할 수 있게 된다는 점입니다. 제약 조건이 30개 전의 메시지에 묻혀 있는 것이 아니라 요청과 함께 직접 제공될 때, 이를 따르지 않는 것은 진짜 지시 불이행입니다. 따라서 실제로 일어나는 상황에 맞게 대응할 수 있습니다.
세 번째는 새로 시작하는 데 아무런 비용도 들지 않는다는 점입니다. 지금은 새로운 채팅을 시작한다는 것이 다시 설명해야 함을 의미합니다. 이 때문에 사람들이 신뢰성 한계를 훨씬 넘어서까지 대화 스레드를 끌고 가는 것입니다. 지식이 자동으로 검색되면 새로운 채팅을 시작하는 데 부담이 없으며, 끊임없는 재설명이 깨끗한 컨텍스트를 얻기 위한 대가가 되지 않습니다.
또한 내장된 메모리와 충돌하지 않고 조화를 이룹니다. 저장된 메모리는 본연의 장점, 즉 서류 캐비닛처럼 사용하지 않기 때문에 가득 차지 않는 한두 페이지 분량의 안정적인 개인 선호도를 유지하는 역할을 계속 수행할 수 있습니다.
긴 대화를 위한 모범 사례
대화 스레드 길이를 소비하는 리소스로 취급하십시오
작업 스레드가 대략 어느 정도까지 길어질지 미리 정해두고, 그 기준을 넘어서면 새 스레드를 시작하십시오. 대부분의 사람들은 다시 설명해야 하는 번거로움 때문에 신뢰성 한계를 훨씬 지나쳐 대화를 이어갑니다. 재설명 문제를 해결하면 이 과정이 매우 쉬워집니다.
중요한 제약 조건은 시작뿐만 아니라 끝에도 배치하십시오
위치 효과는 불리하게 작용할 수도 있지만 유리하게 작용할 수도 있습니다. 다음 답변에서 반드시 지켜져야 할 사항이 있다면 보내는 메시지에 다시 언급하십시오. 입력의 끝부분은 강력한 위치입니다. 이것이 반복이 효과가 있는 이유이며, 모든 것에 대해 사후 대응식으로 반복하는 것보다 중요한 두세 가지 사항에 대해 의도적으로 반복하는 것이 훨씬 효과적입니다.
직접 선택한 시점에 의도적으로 요약하십시오
대화 스레드가 길어지면 요구 사항을 명시적으로 다시 서술해 달라고 요청하고, 이를 확인 및 수정한 다음, 그 내용을 첫 메시지로 삼아 새 대화를 시작하십시오. 보이지 않는 자동 잘림 기능이 임의로 결정하게 두는 대신, 직접 검토하면서 압축을 수행하는 것입니다.
결정 사항이 대화 기록에만 존재하게 하지 마십시오
다음 주에도 여전히 유효한 내용이라면 40번째 메시지가 아니라 문서나 저장소에 보관해야 합니다. 이것이 이 문제 유형 전체를 예방하는 단 하나의 습관이며, 대화 스레드를 미련 없이 버릴 수 있게 해주는 비결입니다.
모델을 의심하기 전에 위치를 먼저 의심하십시오
지침이 더 이상 적용되지 않을 때는 지침을 다시 작성하기 전에 대화 내에서 어느 위치에 있는지 확인하십시오. 긴 스레드의 초반에 설정된 내용은 입력에서 가장 취약한 위치에 있게 되며, 올바른 대응은 문구를 바꾸는 것이 아니라 구조를 조정하는 것입니다.
결론
ChatGPT가 같은 대화에서 이전에 말한 내용을 잊어버리는 이유는 긴 입력이 불균일하게 처리되기 때문입니다. 긴 컨텍스트의 중간에 있는 정보는 시작이나 끝에 있는 정보보다 덜 안정적으로 사용됩니다. 이것이 Lost in the Middle 연구의 발견이며, 명시적으로 긴 컨텍스트를 위해 구축된 모델에서도 마찬가지였습니다. 또한 실제 사용 가능한 용량은 광고된 수치보다 훨씬 적습니다. 이는 32K를 지원한다고 주장하는 모델의 절반이 32K에서 버티지 못했음을 보여준 RULER의 테스트 결과가 증명합니다. 여러분의 제약 조건이 무시된 것이 아닙니다. 90번째 메시지에 이르렀을 때, 그 조건은 모델이 잘 처리할 수 있는 수준보다 길어진 입력의 가장 최악의 위치에 있었던 것입니다.
즉, 해결책은 프롬프트 기술이 아닙니다. 대화 기록을 기록 보관소로 사용하는 것을 중단하십시오. 지속되어야 할 자료는 어시스턴트가 읽을 수 있는 저장소에 보관하고, 대화는 짧게 유지하며, 자유롭게 새 대화를 시작하십시오. 결국 모델이 불안정하게 작동하는 영역을 관리하는 데 능숙해지는 대신, 모델이 안정적으로 작동하는 범위 내에서 작업하게 될 것입니다.