Claude Code 성능 저하 감지를 위한 일일 벤치마크 트래커
Claude Code daily benchmarks for degradation tracking
TL;DR Highlight
Marginlab이 Claude Code(Opus 4.6)의 SWE-Bench-Pro 성능을 매일 자동으로 측정하는 독립 트래커를 통해 통계적으로 유의미한 저하를 감지하고 AI 모델의 조용한 품질 저하를 제3자 검증한다.
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 --versionTerminology
관련 논문
2,000명이 내 AI 어시스턴트를 해킹하려 한 뒤 벌어진 일
실제로 6,000개 이상의 이메일로 AI 에이전트에 prompt injection 공격을 시도한 공개 실험 결과로, Claude Opus 4.6이 비밀 파일 유출을 한 번도 허용하지 않았지만 실험 설계의 현실성에 대한 논란이 뜨거웠다.
언제 LLM을 조합하면 효과가 있나? 67개 Frontier 모델에서 Routing, Voting, Mixture-of-Agents의 Co-Failure Ceiling 분석
여러 LLM을 조합해도 '모든 모델이 동시에 틀리는 비율(β)'이 성능 상한선이며, 업계가 쓰는 pairwise 상관계수(ρ)는 이 상한선을 예측하지 못한다.
Function Calling을 넘어서: Tool-Environment 신뢰성 문제 하에서의 Tool-Using Agent 벤치마크
실제 환경처럼 API가 망가지거나 결과가 이상할 때 LLM 에이전트가 얼마나 잘 버티는지 측정하는 벤치마크 ToolBench-X 공개.
LG 스마트 TV 앱의 절반 가까이에 Residential Proxy SDK가 심어져 있다
6,038개의 LG·Samsung 스마트 TV 앱을 스캔했더니 2,058개에서 사용자의 IP를 몰래 팔아 트래픽을 중계하는 Residential Proxy SDK가 발견됐다. TV는 컴퓨터처럼 감시받지 않아서 프록시 호스트로 거의 이상적인 환경이다.
Prompt Injection의 본질은 Role Confusion이다
LLM이 시스템 프롬프트, 사용자 입력, 툴 출력을 구분하지 못하는 구조적 결함이 prompt injection의 근본 원인이라는 ICML 2026 논문으로, 현재 LLM 보안 아키텍처의 한계를 명확히 분석한다.
GPT-5.5의 환각(Hallucination) 비율이 MIT 라이선스 GLM-5.2보다 3배 높다
모델 크기가 커질수록 성능이 좋아진다는 통념에 반해, 오픈소스 753B 모델 GLM-5.2가 추정 1~2T 규모의 GPT-5.5보다 환각 비율이 3배 낮다는 벤치마크 결과가 나왔다. 단순히 파라미터 수와 벤치마크 점수만으로 모델을 선택하면 실제 업무에서 낭패를 볼 수 있다는 경고다.