핵심 요약
Claude Opus 4.6의 100만 토큰 컨텍스트를 활용해 해리포터 주문 찾기 실험이 이루어졌고, 이를 두고 "컨텍스트 활용 vs 훈련 데이터 암기" 논쟁이 벌어졌다.
동시에 OpenAI·Anthropic 모델의 벤치마크 신뢰성, 시간에 따른 성능 변화, 그리고 Claude Code의 자동 메모리 기능 등 LLM 사용에서 점점 더 중요한 실무 쟁점들이 드러났다.
이 글은 그 논쟁들을 개념별로 재구성해, 앞으로 LLM을 평가·활용할 때 무엇을 조심해야 하는지 정리한다.
해리포터 주문 찾기 실험의 실제 의미
한 사용자가 Claude Opus 4.6(1M 컨텍스트)을 사용해 해리포터 1~4권 전체 텍스트(약 73만 토큰)를 넣고, 등장하는 모든 주문을 추출해 보았다.
공식적으로 문서화된 50개 주문 중 49개를 맞추고, "Slugulus Eructo" 하나만 놓쳤다고 보고했다.
표면적으로는 "와, 70만 토큰 안에서 거의 다 찾아내네, 문맥 추적 대단하다"라는 인상을 주지만, 이 결과만으로는 모델이 진짜로 컨텍스트를 활용했는지, 아니면 이미 알고 있던(훈련 데이터에 내재된) 지식을 재현했는지 구분할 수 없다.
게다가 일부 댓글에서 지적하듯, "Slugulus Eructo"라는 주문 이름 자체가 책에 직접 나오지 않거나, 다른 책에서만 언급되는 가능성도 있어, 무엇을 '정답 집합'으로 삼았는지도 애매하다.
즉, 이 실험은 "재미있는 데모"로서는 좋지만, 모델의 진짜 컨텍스트 활용 능력을 검증하는 정교한 테스트라고 보기는 어렵다.
컨텍스트 vs 훈련 데이터 암기: 어떻게 구분할까?
LLM을 테스트할 때 가장 중요한 질문 중 하나는 "지금 이 답은 내가 준 컨텍스트에서 온 건가, 아니면 모델이 이미 알고 있던(훈련 데이터) 것인가?"이다.
해리포터 주문처럼 이미 웹에 정리된 정보라면, 모델이 책 전체를 보지 않아도 인터넷 자료를 통해 충분히 내재화했을 수 있다.
그래서 "책을 컨텍스트로 줬더니 주문을 잘 찾더라"만으로는 컨텍스트 활용을 검증했다고 말하기 어렵다.
이 문제를 구분하는 간단한 아이디어가 몇 가지 제안되었다.
첫째, 책 속의 주문 이름을 전부 난수 같은 가짜 이름으로 치환한 뒤, 그 가짜 이름들을 제대로 찾아내는지 보는 방법이다.
이렇게 하면, 모델이 이전에 본 적 없을 법한 문자열을 얼마나 잘 인식·수집하는지 알 수 있다.
둘째, 아예 다른 LLM에게 "가짜 책"을 생성하게 하고, 그 안에 특정 패턴의 비밀 토큰을 심어놓은 후, 테스트 대상 모델이 그 토큰을 얼마나 잘 찾는지 보는 방법도 있다.
다만, 생성 과정 자체가 기존 모델의 분포에 영향을 받기 때문에, 정말 완전히 '훈련 데이터 밖'이라고 단언하긴 어렵다는 지적도 있었다.
결국 "훈련 데이터에 있을 법한 요소"를 최대한 제거한, 사람이 새로 쓴 텍스트(또는 최신 시점에 출간된 신간)를 사용하는 것이 가장 이상적인 테스트 데이터에 가깝다는 공감대가 있다.
"그냥 물어봤을 때"와 "컨텍스트를 줬을 때"의 차이
해리포터 주문 실험을 한 사용자는 같은 모델에게 "책 없이" 그냥 주문 목록을 물어봤을 때, 약 13~15개 정도의 주문을 빼먹었다고 보고했다.
즉,
컨텍스트 없이: 모델 내부 지식만 쓸 때는 상당수 주문을 누락했다.
컨텍스트와 함께: 책 전체를 넣어줬을 때는, 훨씬 더 완전한 목록을 뽑아냈다.
이 차이는 두 가지 가능성을 시사한다.
첫째, 모델이 해리포터 주문을 완벽히 암기하고 있지는 않고, 대중적인 것 위주로만 기억하고 있을 수 있다.
컨텍스트를 주면, "기억이 나지 않던 덜 유명한 주문들"도 텍스트 속에서 스캔·추출할 수 있게 되는 셈이다.
둘째, 모델이 "이 질문에 얼마나 성실히, 얼마나 오래 답할 것인가"를 결정하는 내부 휴리스틱 때문에, 컨텍스트 없이 "그냥 목록을 써 보라"고 하면 길고 귀찮은 답을 줄이려는 경향이 있을 수도 있다.
반면, 책이 컨텍스트로 주어지면, "지금은 문서 분석 태스크다"라고 인식해 더 체계적으로 추출하려 할 수 있다.
이 점은 우리도 활용할 수 있다.
단순히 "지식"을 묻기보다, 가능한 한 관련 텍스트(문서, 코드, 로그 등)를 함께 첨부해 "이 자료에서만 답을 찾으라"는 식으로 지시하면, 빠진 요소가 줄어들고 현실과의 정합성이 좋아지는 경우가 많다.
새로운 벤치마크 설계 아이디어들
댓글들에서는 기존 벤치마크의 한계를 보완할 여러 실험 아이디어가 제안되었다.
한 개발자는 "스크립트를 만들어 문장을 뒤섞고, 그 중간에 비밀 문구를 심어 넣는 '텍스트 버전 Where's Waldo'를 만들자"고 제안한다.
이렇게 하면, 모델이 긴 문서 속에서 특정 패턴을 얼마나 잘 찾아내는지, "단순 검색"이 아니라 문맥적 이해가 필요한 태스크도 함께 측정할 수 있다.
또 다른 제안은, 이미 존재하는 책이나 텍스트를 가져와 일부 요소를 체계적으로 변형(이름 치환, 순서 변경, 간단한 스타일 변경 등)한 후, 그 속에서 질의응답을 수행하게 하는 방식이다.
이렇게 하면 모델이 "원문을 암기해 재생하는지" vs "변형된 텍스트를 실제로 읽고 이해하는지"를 어느 정도 구분해 볼 수 있다.
핵심은,
훈련 데이터에 그대로 들어가 있을 가능성이 높은 유명 텍스트(해리포터, 반지의 제왕, 유명 논문 등)를 그대로 사용하는 벤치마크는 점점 덜 유의미해진다는 점이다.
따라서 비공개 또는 공개 직후의 텍스트, 또는 체계적으로 변형된 텍스트를 사용한 벤치마크가 점점 더 중요해질 것이라는 관점이 크다.
LLM의 '암기' 문제와 저작권 우려
한 댓글은 메타 Llama 3.1이 해리포터 1권의 42%를 단어 단위로 재현할 수 있었다는 연구를 링크하며, "요즘 LLM들은 주요 책들을 상당 부분 그대로 기억하고 있다"고 지적한다.
다른 논문에서는, 일부 모델에게 적절한 프롬프트와 우회 기법을 사용하면 해리포터 책을 거의 99%에 가깝게 재생하게 만들 수 있었다고 보고했다.
이 과정에서 여러 모델은 방어 기제가 있어 '그 트릭을 우회해야' 했지만, 어떤 모델(Grok, DeepMind 계열)은 별다른 우회 없이도 쉽게 재현했다고 한다.
이러한 결과는 두 가지 차원에서 중요하다.
첫째, 기술적 차원에서 보면, LLM이 "일반화된 지식"만 담는 것이 아니라, 고유 저작물의 긴 구간을 사실상 그대로 암기하고 있다는 이야기다.
둘째, 법적·윤리적 차원에서 보면, 저작권자의 허락 없이 책 전체를 재생하는 것이 허용될 수 있는지, 앞으로 얼마나 큰 소송 리스크가 생길지에 대한 우려가 커진다.
실제로 개인 웹사이트가 과도한 스크래핑으로 마비돼 사이트를 닫았던 경험을 공유하며, "이 콘텐츠를 무단 학습에 쓴 회사들을 상대로 소송을 하고 싶다"는 의견도 등장했다.
따라서 앞으로의 LLM 평가는 "문제를 얼마나 잘 푸나"뿐 아니라, "훈련 데이터 재현을 얼마나 잘 차단하나"라는 규제·윤리적 측면도 함께 보게 될 가능성이 크다.
AI 벤치마크 신뢰성 논쟁과 '벤치맥싱'
댓글 후반부에서는 OpenAI GPT-5.3 Codex가 특정 코딩 벤치마크에서 최고 점수를 기록했다는 소식이 나오며, "이 벤치마크들을 믿을 수 있는가?"라는 논쟁이 이어졌다.
여기서 중요한 키워드는 '벤치맥싱(benchmaxxing)'이다.
이는 모델을 실제 제품 용도보다 "특정 벤치마크에서 높은 점수를 내도록 과도하게 최적화하는 행위"를 의미한다.
예를 들어, 벤치마크 문제를 직접 학습 데이터로 사용하거나, 문제 스타일에 과적합을 일으키는 방식이 해당된다.
실제로 과거에 OpenAI와 Meta 연구진이 일부 벤치마크 데이터에 과도하게 노출된 모델을 발표했다는 논란이 있었고, 이는 "새 모델이 X 점수를 달성했다"는 발표를 곧이곧대로 신뢰하기 어렵게 만든다.
또한,
공개된 벤치마크(예: SWE-bench, MMLU 등)는 시간이 갈수록 모델이 '기억'하기 쉬워진다.
그래서 점수가 더 이상 실제 실력 향상을 반영하지 않고, 단지 데이터 노출 정도를 보여주는 지표가 될 위험이 있다.
이 때문에 요즘은 "비공개·프라이빗 테스트 세트"를 운용하거나, 벤치마크 자체를 자주 갱신하는 방식으로 이 문제를 완화하려는 시도가 늘고 있다.
사용자 입장에서는, 벤치마크 점수는 "대략적인 실력 지도" 정도로만 참고하고, 실제로는 자신의 작업(코딩, 글쓰기, 분석 등)에 맞는 작은 테스트를 직접 만들어 써보는 것이 필수적인 단계가 된다.
모델 성능, 시간·부하에 따라 변할까? (OpenAI의 입장)
여러 사용자는 "모델이 출시 직후에는 똑똑하다가, 시간이 지나면 둔해지는 것 같다", "서버가 바쁠 때는 답변 품질이 떨어지는 듯하다"는 체감을 공유했다.
이에 대해 OpenAI 직원이 댓글로 몇 가지를 명확히 했다.
첫째, API 상의 고정 모델들(예: gpt-5.2, gpt-4.1-mini 등)은 시간, 요일, 서버 부하에 따라 가중치나 내부 구조를 바꾸지 않는다고 밝혔다.
즉, 배포된 모델 파일 자체는 하루 종일, 또 출시 후 한동안 동일하게 유지된다는 것이다.
둘째, 다만 실제 운영에서 발생하는 미세한 비결정성(배치 연산 순서, 하드웨어 차이 등) 때문에 "완전히 같은 입력에 완전히 같은 출력"이 나오지 않을 수는 있고, 부하가 많을 때 속도가 느려지거나, 장애로 동작이 달라지는 경우는 예외적으로 있을 수 있다고 설명했다.
셋째, ChatGPT와 같은 완제품 서비스에서는, 모델 위에 얹힌 '하네스(harness)'—시스템 프롬프트, 도구 구성, 생각 시간("juice") 설정, UI 동작 등—이 수시로 업데이트되므로, 사용자가 느끼는 품질은 실제 모델이 아니라 하네스 변경 영향일 가능성도 크다고 했다.
이때도 "의도적으로 시간에 따라 성능을 떨어뜨리거나, 몰래 더 싼 모델로 교체하는 일은 하지 않는다"고 명시했다.
사용자 입장에서 이 말은,
API에서 정확히 같은 모델 버전을 쓰고 있다면, 장기적으로 성능이 "느낌상" 달라지더라도, 그 원인은 프롬프트 설계나 컨텍스트 관리, 또는 특정 버그·업데이트에 있을 가능성이 크다는 뜻이다.
반면 ChatGPT UI처럼 "제품 레이어"를 통해 사용하는 경우, 같은 이름의 모델이라도 동작이 달라질 수 있으니, 장기적 일관성이 특히 중요하다면 API 호출로 직접 관리하는 것이 더 안전하다는 의미도 된다.
Claude Code의 자동 메모리 기능과 프라이버시·품질 문제
Claude Code(터미널·VS Code 플러그인 등)에는 최근 "자동 메모리" 기능이 추가되었다.
요약하자면, 프로젝트별 디렉터리 아래에 ~/.claude/projects/{프로젝트-경로}/memory/ 폴더를 두고, 여기에 MEMORY.md와 여러 보조 파일을 만들어 과거 대화와 작업 정보를 지속적으로 기록·참조하는 구조다.
이 메모리 파일은 시스템 프롬프트에 항상 포함되며(단, 길이 제한이 있어 앞부분 위주로 반영된다), Claude는 여기에 "자주 헷갈리는 규칙, 프로젝트의 불변 조건, 이전에 시도했다 실패한 접근법, 내일 고치기로 한 버그" 같은 것을 적어 두라고 유도한다.
하지만 여러 사용자가 다음과 같은 우려를 제기했다.
첫째, 시간이 지나면 메모리 안에 불필요하거나 오래된 정보가 쌓이고, 오히려 모델이 잘못된 이전 맥락을 끌어와 실수를 양산할 수 있다.
예를 들어, 옛날 설계 결정이 뒤집혔는데도 메모리에 남아 있으면, Claude가 계속 그 오래된 규칙을 따르려고 할 수 있다.
둘째, 자동 기록이 얼마나 공격적인지, 사용자가 의도하지 않은 사소한 정보까지 저장되는지에 대한 걱정도 있다.
어떤 사람은 "메모리 지우기"를 했더니, 이후 며칠간 Claude Code가 확실히 덜 똑똑해진 느낌이었다고 말하기도 한다.
이는 메모리가 실제로 꽤 많은 도움을 주고 있다는 반증일 수도 있고, 혹은 지운 직후 재학습되는 과정에서 불안정해진 것일 수도 있다.
셋째, 프라이버시 관점에서, 특정 프로젝트에 대한 민감한 정보가 로컬 메모리에 쌓이는 것 자체는 괜찮더라도, 이 내용이 어떻게 모델에 전달되고, 클라우드로 전송되는 부분이 있는지에 대한 투명성이 중요하다.
실무적으로는,
장기 프로젝트나 복잡한 코드베이스에서는 이런 메모리가 "개발 파트너의 장기 기억" 역할을 해 줘 상당히 유용할 수 있다.
반대로 짧은 실험, 민감한 코드, 혹은 명확한 상태 초기화를 원하는 상황에서는 메모리를 꺼두거나, 특정 프로젝트만 별도 작업 디렉터리를 사용하는 식으로 범위를 제한하는 것이 안전하다.
지금 단계에서 가장 현실적인 전략은 "메모리를 쓰되, 주기적으로 청소하거나, MEMORY.md를 직접 열어보고 잘못된/오래된 내용을 손수 정리하는 것"이다.
인사이트
이 논의 전반에서 드러나는 공통 메시지는 "LLM을 제대로 쓰려면, 결과만 보고 감탄하는 데서 그치지 말고, 그 결과가 어디서 왔는지와 평가 방법의 한계를 늘 의심해야 한다"는 점이다.
컨텍스트 vs 암기, 공개 vs 비공개 벤치마크, 모델 vs 하네스, 자동 메모리의 이점과 리스크 등은 모두 "표면 성능 수치" 너머의 층위에 속한다.
실제 업무에서 LLM을 도입하려면, 다음과 같은 습관을 길들이는 것이 도움이 된다.
첫째, 내 사용 사례에 맞는 작은 벤치마크를 직접 만들어라.
실제 코드베이스, 실제 문서, 실제 로그를 기반으로, "이 모델이 나에게 중요한 문제를 얼마나 잘 푸는지"를 검증하는 것이 공개 리더보드보다 훨씬 중요하다.
둘째, 컨텍스트를 아끼지 말되, 컨텍스트가 정말로 활용되고 있는지 주기적으로 실험해 보라.
문자열을 살짝 변형하거나, 가짜 데이터를 삽입해 보는 식의 간단한 실험만으로도 모델의 '진짜 이해력'을 가늠해 볼 수 있다.
셋째, 자동 메모리·장기 컨텍스트·도구 호출 같은 고급 기능을 켤 때는, "이게 언젠가 나에게 불이익을 줄 수 있는가?"를 먼저 생각하고, 프로젝트별로 정책을 다르게 가져가는 것이 좋다.
이런 건강한 의심과 실험 습관이 있을 때, 새로운 모델 출시 뉴스나 벤치마크 점수는 "참고용 지도"로서만 사용되고, 실제 내 작업 환경에서 모델을 점점 더 효과적으로 길들이는 쪽으로 에너지를 쓸 수 있다.
출처 및 참고 : Claude Opus 4.6 | Hacker News
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.