최고급 모델을 유료로 결제했는데, 성능은 떨어지고 나를 낙인찍었다
요약
Codex 모델의 성능 저하 의혹을 로그 분석을 통해 조사한 결과, 특정 모델(GPT-5.5)의 추론 토큰 수가 특정 수치(516)에서 고정되는 현상이 발견되었습니다. 이는 모델의 사고 과정이 특정 경계에서 강제로 잘려나가고 있음을 시사하며, 모델의 지능 저하가 아닌 추론 프로세스의 기술적 결함 가능성을 보여줍니다.
핵심 포인트
- Codex 모델의 추론 토큰 수가 516개 등 특정 수치에 고정되는 현상 발견
- GPT-5.5 응답의 약 44%가 516개 토큰 경계에서 사고가 중단됨
- 토큰 분포가 연속적이지 않고 518 단위의 빗 모양(comb) 패턴을 보임
- 모델 성능 저하가 단순한 체감이 아닌 데이터 기반의 기술적 문제임을 입증
그날 밤 나는 Codex에게 작업을 맡기고 잠자리에 들었다.
지난 몇 달 동안 내가 자리 잡은 습관이다. 대규모 리팩토링 (refactor): 낮 동안 작업을 나누고, 명확한 AGENTS.md를 작성한 뒤, 밤새 실행되도록 두고, 아침에 결과를 수집하는 방식이다. 나는 이 루프를 충분히 반복해 왔기에 작업이 얼마나 걸릴지, 어디서 막힐지, 무엇이 잘 작동할지에 대해 직관적인 감각을 가지고 있었다. 나는 그것을 방치해 두는 것에 익숙했다.
다음 날 아침, 진행 표시줄은 놀라울 정도로 얕은 지점에서 멈춰 있었다.
처음에는 내 탓이라고 의심했다. AGENTS.md가 불분명했나? 문서 구조가 엉망이었나? 어떤 도구가 잘못 설정되었나? 그래서 나는 하네스 (harness)와 씨름하기 시작했다. 프롬프트 (prompts)를 조정하고, 디렉토리 구조를 재편성하고, 작업을 더 작은 단위로 나누었다. 이틀 내내 만지작거렸지만, 제자리걸음을 하고 있다는 느낌은 변하지 않았다. 그것은 설명할 수 없는 지점들을 계속 맴돌다가, 작업이 절반밖에 진행되지 않았음에도 자신 있게 완료되었다고 말했다.
사흘째 되는 날, 나는 마침내 팀 채팅창에 불만을 토로했다. 내가 말을 마치기도 전에 여러 사람이 동시에 끼어들었다. “최근 Codex의 모델 성능이 저하되었습니다. 최근 들어 정말 심해졌어요. 출시 당시와는 전혀 다릅니다.”
웃어야 할지 울어야 할지 알 수 없었다. 나는 하네스 (harness)를 붙잡고 사흘을 보냈는데, 문제는 전혀 내 쪽에 있지 않았다.
고정된 숫자: 516
나는 “모두가 성능이 떨어졌다고 느낀다”라는 말로 적당히 넘어가고 싶지 않았다. 분위기 (Vibes)는 반증할 수 없다. 오늘의 나쁜 기분은 언제든 모델 성능 저하 (model degradation) 탓으로 돌릴 수 있기 때문이다. 나는 확실한 증거를 원했다.
커뮤니티를 살펴보던 중, 누군가 이미 이 문제의 바닥까지 파헤쳤다는 것을 발견했다.
한 사용자가 완전히 포렌식 (forensic) 수준으로 조사했다. 불평하는 대신, 그들은 로컬 ~/.codex 디렉토리 아래에 있는 모든 세션 로그를 추출했다. 2월 1일부터 6월 27일까지, 865개 세션에 걸친 390,195개의 응답 기록이 있었으며, 모든 기록에는 턴당 token_count 메타데이터가 포함되어 있었다. 그들은 수치를 분석했고 매우 이상한 점을 발견했다.
모델의 추론 토큰 (reasoning-token) 수가 정확히 516이었던 경우가 3,363번 있었다.
하나도 더 많지 않았고, 하나도 더 적지 않았다. 정확히 516이었다.
숫자 그 자체만으로는 큰 의미가 없습니다. 무서운 부분은 분포입니다. GPT-5.5는 전체 응답의 19.3%만을 차지했지만, '정확히 516개'인 이벤트의 82.0%를 차지했습니다. 더 자세히 살펴보면, 다른 모델들의 경우 reasoning token (추론 토큰) 수가 516개와 같거나 516개에서 멈춘 비율이 단 1.3%였던 반면, GPT-5.5 응답의 44%는 516개와 같거나 그 지점에서 멈춰 있었습니다. 월별 추세는 더 심각했습니다. 정확히 516개인 비율은 5월에는 0.11%에 불과했으나, 6월에는 53.30%로 급증했습니다. 한편, GPT-5.5의 평균 reasoning token (추론 토큰) 수는 2월 268개에서 5월 107개로 감소했습니다.
모든 응답의 토큰 수를 히스토그램 (histogram)으로 그리면, 516, 1034, 1552와 같이 각각 정확히 518씩 차이 나는 기묘한 빗 모양 (comb)이 나타납니다. 이것은 정상적인 모델의 모습이 아닙니다. 다양한 난이도의 문제에 직면하는 모델이라면 질문이 쉬울 때는 짧게, 어려울 때는 길게 사고하는 과정이 연속적인 분포를 보여야 합니다. 이 빗 모양은 무언가가 고정된 경계에서 사고를 잘라내고 있음을 의미합니다.
더 멍청해진 것이 아니라, 사고를 마칠 수 없었던 것이다
이는 지난 3일 동안 제가 느꼈던 직감과 일치했습니다.
이전에는 Codex가 때때로 다소 느릿하게, 아주 오랫동안 생각하곤 했습니다. 무언가 억제하고 있다는 느낌을 받을 수 있었습니다. 최근 들어 그 피드백은 비정상적으로 빨라졌고 기이할 정도로 일관되었습니다. 매번 약 30초 정도의 사고 후에 답변을 내놓는 리듬을 보였습니다. 저는 그들이 추론 속도 (inference speed)를 최적화한 것이라고 생각했습니다. 돌이켜보니, 그것은 빠른 것이 아니라 완료되기 전에 잘려 나간 것이었습니다.
그 516이라는 빗 모양이 바로 차단 지점 (cutoff point)입니다.
커뮤니티의 지배적인 추측은 Codex 내부의 GPT-5.5용 시스템 프롬프트 (system prompt)를 지목합니다. 프롬프트 끝부분 근처에 ## Intermediary updates라고 불리는 섹션이 있는데, 이는 모델에게 작업하는 동안 진행 상황을 업데이트하도록 요청합니다. 일부에서는 이 지침이
이 기술적인 설명이 반드시 옳다고 주장하는 것은 아닙니다. 하지만 여기서 도출된 한 가지 해결책을 제가 직접 시도해 보았고, 그것은 정말로 효과가 있었습니다.
한 문장이 지능의 절반을 되찾아준다
해결책은 터무니없을 정도로 간단합니다. AGENTS.md 파일에 다음 한 줄을 추가하세요:
Spend time on thinking; you do not need to use
the commentary channel to report progress to me.
번역: 생각하는 데 시간을 할애하세요. 나에게 진행 상황을 보고하기 위해 해설 채널 (commentary channel)을 사용할 필요는 없습니다. "파일을 읽고 있습니다" 또는 "편집을 시작하려 합니다"와 같은 메시지에 연산 자원 (cycles)을 낭비하지 말고, 그 노력을 실제로 추론 (reasoning)을 완료하는 데 사용하세요.
저는 이것을 추가하고 며칠 동안 실행해 보았습니다. 교착 상태 (deadlocked)에 빠져 있던 프로젝트들이 실질적인 진전을 보이기 시작했습니다. 막연한 개선의 느낌이 아니라, 이전에 막혀 있던 일들이 이제는 앞으로 나아갈 수 있다는 구체적인 확신이었습니다. 커뮤니티의 일부에서는 이 한 줄의 효과가 제한적이라고 말합니다. 더 철저한 해결책은 시스템 프롬프트 (system prompt)에서 ## Intermediary updates 섹션 전체를 삭제하는 것이며, 이렇게 하면 516 현상이 사라진다고 보고되었습니다.
하지만 여기서 느껴지는 황당함이 있으신가요?
저는 가장 높은 추론 예산 (reasoning-budget) 등급인 GPT-5.5 xhigh를 유료로 결제하고 있습니다. 저는 어려운 문제에 대해 깊이 생각하는 최상위 모델을 기대했습니다. 대신 저는 모델이 이미 갖추고 있어야 할 지능의 일부를 되찾기 위해, 설정 파일에 "제발 신중하게 생각하고 보고를 서두르지 마세요"라는 문장을 적으며 아이를 달래듯 모델을 구슬려야 합니다.
이것은 돈의 문제가 아닙니다. 비용도 같고 모델 이름도 같습니다. 제가 원하는 것은 안정적이고 예측 가능한 능력입니다. 이제 제가 알 수 없는 글로벌 업데이트가 저에게 아무런 말도 없이 조용히 그 능력을 축소시킬 수 있습니다.
공식적인 대응은 가장 아이러니한 부분이었습니다. 516 현상을 보고한 첫 번째 이슈는 23분 만에 not_planned로 종결되었습니다. 전체 통계가 포함된 메인 이슈에는 100개가 넘는 댓글이 달렸지만, OpenAI 직원은 단 한 명도 답변하지 않았습니다. 이 이슈가 Hacker News 메인 페이지에 올라간 후에야 비로소 무언가 움직이기 시작했습니다.
블랙박스는 단순한 출력 저하보다 훨씬 더 많은 것을 숨길 수 있다
만약 Codex 사건을 그저 미숙한 최적화 과정으로 치부할 수 있다면, 같은 주에 발견된 Claude Code 역시 순진한 실수로 무시할 수 없습니다.
누군가 Anthropic이 서명하고 난독화(minified)된 JS 번들을 담은 Claude Code 설치 파일을 역분석하여 특정 사용자를 눈에 띄지 않게 표시하는 코드를 찾아냈습니다.
트리거 조건은 교묘합니다. 이 로직은 ANTHROPIC_BASE_URL을 설정하고 요청을 비공식 제3자 중계(relay)로 보내는 경우에만 활성화됩니다. 공식적인 직접 사용자들은 완전히 건너뜁니다. 이는 프록시와 중계기를 사용하는 사람들을 겨냥합니다. 사실상 Claude Code가 중국에서 사용되는 방식입니다.
활성화되면 세 가지 검사를 수행합니다. 첫째, 시스템 시간대가 Asia/Shanghai 또는 Asia/Urumqi인지 확인합니다. 둘째, 프록시 도메인이 .cn 도메인, baidu.com, alibaba-inc.com, bytedance.net을 포함하여 약 147개 항목의 숨겨진 목록과 일치하는지 확인합니다. 셋째, 해당 도메인에 AI 연구소 키워드(예: deepseek, moonshot, minimax, zhipu)가 포함되어 있는지 확인합니다.
감지되면 어떻게 표시할까요? 저에게는 이 부분이 가장 음침하게 느껴집니다.
Anthropic 서버로 전송되는 시스템 컨텍스트를 수정합니다.
탐지를 피하기 위해, 두 개의 탐지 목록은 평문(plaintext)으로 저장되지 않았습니다. 이들은 먼저 Base64로 인코딩된 후, 91이라는 키로 XOR 암호화되었습니다. 이는 특히 사용자가 strings 명령어로 목록을 덤프(dump)하는 것을 방지하기 위함이었습니다.
이것은 더 이상 "데이터 수집"이 아닙니다. 이것은 "나는 수집해서는 안 될 정보를 수집하고 싶으며, 감사(audit)나 문제 해결(troubleshooting) 과정에서 내가 무엇을 하고 있는지 드러나지 않도록 그 의도를 숨기기 위해 엄청난 노력을 기울이겠다"는 뜻입니다. 이는 교과서적인 스파이웨어(spyware)의 동작 방식입니다.
그 이후의 결과는 더욱 많은 것을 시사합니다
이 코드는 2026년 4월 2일, Claude Code v2.1.91과 함께 조용히 배포되었습니다. 릴리스 노트(release notes)에는 단 한 마디의 언급도 없었습니다. 6월 30일, 한 Reddit 사용자와 독립 개발자가 동시에 이를 발굴하여 Hacker News에 게시했습니다.
Anthropic은 빠르게 대응했습니다. Claude Code 팀의 엔지니어는 X(구 트위터)를 통해 이를 공개적으로 인정하며, 이것은 무단 리셀러(reseller)의 계정 남용을 방지하고 모델 증류(model distillation)를 막기 위해 3월에 시작된 실험이었다고 밝혔습니다. 다음 날, v2.1.197 버전에서 해당 코드가 제거되었습니다.
책임을 지는 것처럼 들릴 수도 있습니다. 하지만 타임라인을 보십시오. 조용히 배포되었고, 의도적으로 난독화(obfuscated)되었으며, 폭로된 후에야 인정되었고, 제거된 버전의 변경 로그(changelog)에도 여전히 아무런 언급이 없었습니다. 과정 전체를 통틀어, 그들이 들킨 순간만이 그들의 통제 밖에 있었을 뿐입니다. 그 외의 모든 단계는 의도적으로 설계되었습니다. 숨기고, 목록을 암호화하고, 조용히 삭제하는 것 말입니다.
증류(distillation)와 도용에 맞서려는 그들의 상업적 동기는 충분히 이해합니다. 하지만 기업이 국적과 인프라를 기반으로 한 기계 판독 가능한 표식(machine-readable marks)이라는 수단을 선택했을 때, 이러한 종류의 클라우드 서비스에 대한 신뢰는 타버리고 맙니다. 오늘은 증류 방지를 위해 이 방법을 쓰지만, 내일은 다른 이유로 또 어떤 속임수를 쓸지 알 수 없습니다. 사용자가 검증할 수 없을 정도로 충분히 잘 숨기기 때문입니다.
후속 상황: 7월 5일, 보고에 따르면 Alibaba는 내부적으로 Claude Code 사용을 금지하고 직원들에게 내부 도구로 전환하라고 지시했습니다.
Pokémon Go 플레이어들이 드론 내비게이션을 위해 지도를 만들고 있었다
데이터가 전혀 예상치 못한 곳으로 흘러 들어가는 것은 기술 업계에서 새로운 일이 아닙니다.
아마도 Pokémon GO를 기억하실 것입니다. 전 세계적으로 수년간 플레이된, 어디서나 생명체를 잡는 AR (증강 현실) 모바일 게임입니다. 최근 네덜란드 매체는 하나의 흐름을 추적했습니다. 플레이어들이 게임 내에서 현실 세계를 스캔하며 축적한 데이터가 군용 드론의 내비게이션 (navigation) 기술을 공급하는 데 사용되었다는 사실입니다.
이 연결 고리는 단순히 "데이터를 판매하는" 것보다 더 미묘하며, 더 우려스럽습니다.
먼저, 흔한 오해를 바로잡겠습니다. 누군가가 가공되지 않은 지도 데이터를 패키징하여 군대에 직접 판매했다는 증거는 없습니다. 실제 연결 고리는 다음과 같습니다.
2021년 이후, Pokémon GO는 게임 내 보상을 활용하여 플레이어들이 랜드마크 주변을 걷고 위치를 스캔하도록 유도했습니다. 이러한 보행자 수준의 사진들은 사진 측량 (photogrammetry)에 사용되어 센티미터 단위의 정밀도를 가진 3D 포인트 클라우드 (point-cloud) 지도를 생성하는 데 쓰였습니다. 이는 위성이나 스트리트 뷰 차량이 포착할 수 없는 각도, 즉 사람들이 실제로 걷는 경로의 지면과 가까운 곳을 촬영한 것입니다. Niantic은 이러한 스캔 데이터들을 Large Geospatial Model (대규모 지리 공간 모델)이라고 불리는 거대 모델에 입력했습니다. 이를 물리적 공간의 GPT라고 생각하면 이해가 쉬울 것입니다. 이 모델은 수십억 개의 정밀하게 위치가 지정된 사진들을 물리적 공간에 대한 "이해"로 압축합니다.
2025년 말, Niantic에서 분사된 공간 비즈니스 부문은 Vantor라는 회사와의 파트너십을 공개적으로 발표했습니다. Vantor의 전신은 미국 국가 지리정보국 (NGA)의 주요 계약업체인 Maxar였습니다. 그들이 함께 구축하고자 했던 것은 GPS가 차단된 환경에서의 내비게이션이었습니다. 위성 신호가 재밍 (jamming)되거나 전자전 (electronic warfare)에 의해 억제되는 전장에서는, 드론이 탑재된 카메라 피드를 사전에 구축된 고정밀 3D 지도와 실시간으로 비교함으로써 위치를 유지합니다. 우크라이나의 전장은 현대전에서 GNSS (글로벌 위성 항법 시스템) 신호가 얼마나 취약한지를 반복해서 보여주었으며, 시각적 내비게이션 (visual navigation)은 필수 요구 사항이 되었습니다. 그들의 공동 테스트 결과에 따르면, 위치 오차가 최대 70%까지 감소하여 약 1.5미터의 정확도를 기록했다고 보고되었습니다.
논란의 핵심은 바로 이 미묘한 지점입니다. 군대에 흘러 들어간 것은 가공되지 않은 데이터 (raw data) 그 자체가 아니라, 그 데이터를 학습함으로써 생성된 모델의 능력 (model capability)이었습니다. Niantic과 Vantor 모두 Pokémon GO의 가공되지 않은 스캔 데이터를 넘겨준 적은 없다고 부인합니다. 하지만 Niantic은 플레이어의 스캔 데이터가 자사 파운데이션 모델 (foundation model)의 초기 버전을 학습시키는 데 사용되었음을 인정했습니다. 가공되지 않은 데이터는 폐쇄된 상태로 유지되어 타인에게 전달되지 않을 수 있지만, 학습된 모델 가중치 (model weights)에는 그 능력이 내재되어 있으며, 그것이 정당하든 아니든 모델이 이동하는 곳마다 그 능력을 실어 나릅니다.
이 회사의 계보 자체도 시사하는 바가 큽니다. Niantic의 창립자 John Hanke는 2001년에 Keyhole이라는 회사를 설립했습니다. 2003년 이 회사는 CIA의 벤처 부문인 In-Q-Tel로부터 자금을 지원받았습니다 (이 자금은 주로 NGA의 전신으로부터 나왔습니다). 이후 Google이 Keyhole을 인수하여 Google Earth로 탈바꿈시켰습니다. 이번 거래의 파트너인 Vantor 또한 동일한 정보 기관의 계약업체입니다. 20년이 지난 후, 이 두 계보는 2025년에 다시 하나로 합쳐졌습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기