Claude Code 성능 저하 감지를 위한 일일 벤치마크 트래커

Who Should Read

Claude Code나 Claude API를 업무에 쓰는 개발자 중 '요즘 예전보다 성능이 떨어진 것 같다'는 느낌이 드는 사람. 특히 여러 명의 개발자가 AI 도구를 쓰는 팀에서 QoS(서비스 품질)를 객관적으로 검증하고 싶은 엔지니어링 리드.

Core Mechanics

• Marginlab은 Claude Code CLI를 직접 실행해 SWE-Bench-Pro(실제 GitHub 이슈를 코드로 해결하는 벤치마크) 중 오염 방지 처리된 50개 태스크를 매일 돌리고 결과를 공개한다. '커스텀 하네스 없이 그대로 쓴다'는 게 포인트다.
• 현재(2026-03-13 기준) 기준선(Baseline) 통과율은 56%이며, 오늘 통과율 57%, 7일 평균 54%, 30일 평균 56%로 통계적으로 유의미한 저하는 없는 '정상(Nominal)' 상태다.
• 통계 유의성 기준은 p < 0.05이며, 샘플 수에 따라 유의미한 변화로 인정받으려면 1일(50건)은 ±13.3%, 7일(350건)은 ±4.7%, 30일(1,450건)은 ±2.3% 이상 변동이 필요하다. 즉 하루 단위 측정은 노이즈가 너무 커서 신호를 잡기 어렵다.
• Anthropic Claude Code 팀이 댓글에 직접 등장해서 '2026-01-26에 하네스 버그가 도입됐고 1-28에 롤백했다'고 공식 확인했다. `claude update`로 최신 버전 유지를 권고했다.
• SWE-bench 공동 저자는 50개 하루 1회 실행은 통계적으로 너무 약하다고 지적했다. 최소 300개 태스크, 하루 5~10회 평균을 내야 Anthropic 서버 부하 같은 외부 변수를 잡을 수 있다고 조언했다.
• 통계 방법론에도 비판이 있었다. 현재 트래커가 '이전 값의 신뢰구간 안에 새 값이 드는지'로 판단하는 것 같은데, 이건 틀린 방법이다. 차이 자체의 신뢰구간을 구해서 0을 포함하는지 봐야 한다는 지적이다.
• 커뮤니티에서 실사용자들의 '체감 성능 저하' 목소리가 많았다. 일정 토큰 이상 쓰면 모델이 엉뚱한 짓을 한다거나(한 줄 버그 수정을 해야 하는데 기능 전체를 삭제함), Opus 4.5가 워크플로우를 오히려 느리게 만든다는 불만이 공유됐다.
• 모델 제공업체가 비용 절감을 위해 '조용히 양자화(quantization)'를 적용하거나 MoE(Mixture of Experts) 아키텍처에서 피크 시간대 expert 수를 줄일 수 있다는 우려가 제기됐다. 이런 변화는 사용자가 감지하기 매우 어렵다.

Evidence

• Anthropic 내부 팀이 직접 댓글에서 1월 하네스 버그를 인정하고 수정 완료 사실을 알린 것은 이례적이었다. 커뮤니티에서는 이런 투명한 소통을 긍정적으로 받아들이면서도, '이 정도 사고도 이렇게 늦게 알았는데 더 미묘한 성능 저하는 어떻게 알겠냐'는 반응도 있었다.
• 실사용자 중 'API 모드에서 일정 토큰 이후 모델이 완전히 망가진다'는 경험이 공유됐다. 한 줄 수정이 필요한데 기능 전체를 삭제하는 식의 황당한 동작이 나왔다는 구체적인 사례도 있었다. 이에 대해 일부는 '모델 자체 문제가 아니라 컨텍스트 길이 한계일 수 있다'는 반론을 제기했다.
• ChatGPT도 45k 입력 토큰 이상에서 추론 능력이 급격히 떨어진다는 경험담이 나왔다. 사용자는 '조용한 다운그레이드 대신 차라리 '처리 불가' 응답이 낫다'고 했고, AI 툴 투명성에 대한 강한 요구가 공감을 받았다.
• 서버가 다운됐다가 복구된 직후 속도가 3배 빨라졌다는 경험이 공유됐다. '리소스 제약이 없으면 이렇게 빠를 수 있다는 걸 잠깐 봤다'는 표현과 함께, 현재 성능 변동의 상당 부분이 서버 부하 때문일 수 있다는 시각이 제시됐다.
• 기업 입장에서 벤치마크 트래킹의 필요성을 강조하는 댓글이 주목받았다. '수십~수백 명이 AI 툴을 쓰는 조직이라면 계약한 QoS 수준이 실제로 지켜지는지 제3자 검증이 반드시 필요하다'는 주장이었고, AI 제공업체의 비용 압박이 심해질수록 이런 투명성이 중요해진다는 데 많은 공감이 있었다.

How to Apply

• Claude Code나 Claude API를 쓰는데 성능이 들쑥날쑥하다 싶으면 marginlab.ai 트래커를 주기적으로 체크해본다. 특히 30일 그래프가 기준선 대비 통계적으로 유의미하게 내려갔을 때(±2.3% 이상)는 실제 모델 변화가 있을 가능성이 있다.
• claude update 명령어를 주기적으로 실행해 Claude Code CLI를 최신 버전으로 유지한다. 이번 사례처럼 CLI 자체 버그가 성능 저하처럼 보이는 경우가 있기 때문이다.
• 팀 내에서 AI 도구 성능을 모니터링해야 한다면, 단순 체감이 아닌 고정된 태스크 셋으로 정기 측정하는 방식을 도입한다. 태스크 수는 최소 100개 이상, 주 단위로 집계해야 통계적 의미가 생긴다. 50개 하루 1회는 신호보다 노이즈가 크다.
• 장시간 세션에서 모델 동작이 이상해진다면 컨텍스트 길이 한계를 먼저 의심한다. 모델 품질 저하가 아니라 컨텍스트가 너무 길어져서 추론 품질이 떨어지는 케이스가 많다. 세션을 나누거나 /compact로 컨텍스트를 정리해보는 게 우선이다.

Code Example

# Claude Code CLI 최신 버전으로 업데이트
claude update

# 현재 설치된 버전 확인
claude --version

Terminology

관련 논문

• LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크

  LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.

• Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법

  Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.

• ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?

  LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.

• MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정

  티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.

• LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다

  13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.

• LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개

  스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.

Related Resources

• https://marginlab.ai/trackers/claude-code/
• https://marginlab.ai/trackers/codex/
• https://www.swebench.com/