AI가 조용히 멍청해지고 있는 걸까? LLM 성능 저하를 포착하는 24/7 벤치마크

아마 여러분도 이런 경험을 해보셨을 겁니다. 어제까지만 해도 AI가 아주 예리하게 느껴졌고, 묻지도 않았는데 버그를 고쳐주며 추가적인 코드 정리까지 깔끔하게 해줬습니다. 그런데 오늘 똑같은 종류의 문제가 발생하자, 갑자기 명시적으로 지시하지 않은 부분은 건드리지 않으려 하거나 뱅뱅 돌기 시작합니다. 그러면 이런 의문이 들기 시작하죠. "잠깐, AI가 조용히 멍청해지고 있는 건가?"

많은 사람이 이런 느낌을 받지만, 이를 명확히 짚어내기는 어렵습니다. 제공업체가 모델을 건드리고 있는 걸까요? 오늘의 문제가 실제로 더 어려운 걸까요? 아니면 단순히 기분 탓일까요? 지표로 나타낼 수 있는 숫자가 없다면, 이는 그저 도시 전설로 남을 뿐입니다.

그래서 이 포스트는 AIStupidLevel이라는 사이트에 대해 다루고자 합니다. 이름에서 이미 모든 것을 말해주고 있죠. 이 사이트는 주요 AI 모델들을 대상으로 24시간 내내 테스트를 수행하며, "AI가 멍청해지고 있는가"라는 의문을 실제로 눈으로 확인할 수 있는 곡선(curve)으로 변환해 줍니다.

애초에 왜 AI가 "멍청해질" 수 있는 걸까요?

합리적인 반론이 있을 수 있습니다. 모델은 한 번 학습되면 동결(frozen)되는 것 아닌가요? 하지만 실제로는 배후에서 몇 가지 일들이 일어나고 있습니다:

조용한 업데이트 (Silent updates). API를 사용해 보셨다면 gpt-4.0-20240924와 같은 버전 문자열을 본 적이 있을 것입니다. 뒤에 붙은 날짜는 특정 빌드(build)를 암시합니다. 하지만 Codex나 유사한 도구 내에서 모델을 선택할 때는 그 정도 수준의 세부 정보를 볼 수 없습니다. 어떤 모델들은 버전이 지정된 ID조차 없이 단순히 gpt-4와 같은 일반적인 이름만 가지고 있기도 합니다. 따라서 실제로 어떤 빌드에 접속하고 있는지 알 수 없으며, 조용한 교체(silent swap)를 알아차리기는 매우 어렵습니다.
양자화 (Quantization). 전 세계적인 피크 트래픽을 처리하고 연산 자원 (compute)을 절약하기 위해, 제공업체들은 때때로 모델을 압축합니다.
제한된 연산 자원 (Throttled compute). 사용량이 임계값을 넘어서면, 제공업체는 각 사용자가 끌어다 쓸 수 있는 연산 자원의 양을 제한할 수 있으며, 이는 출력 결과가 더 나빠진 것처럼 느껴지게 만듭니다.
연산 자원 이전 (Compute migration). 새로운 모델이 출시될 예정일 때, 제공업체들은 때때로 이전 모델로부터 연산 자원을 옮깁니다. 제가 직접 API를 사용하며 겪은 바로는, 이것이 가장 자주 관찰되는 현상입니다. 동일한 프롬프트가 갑자기 하룻밤 사이에 성능이 저하되었다가, 며칠 후 더 강력한 버전이 출시되면, 그 직후에 이전 버전이 다시 정상으로 돌아오는 식입니다.

양자화 (Quantization)에 대해서는 직접 LLM을 실행하고 싶으신가요? 잘못된 모델을 선택하지 않기 위한 모델 파라미터 및 양자화 이해하기에서 더 자세히 다루었습니다. 요약하자면, 이는 자원을 절약하지만 일부 세부 사항을 잃게 되는 압축 기술입니다.

따라서 AI 모델은 실제로 고정된(frozen) 존재가 아닙니다. 제공업체는 모델을 조용히 업데이트하거나, 양자화하거나, 제한하거나, 또는 연산 자원을 이전할 수 있으며, 이 중 어떤 것이든 여러분이 경험하는 결과물을 변화시킬 수 있습니다. 어려운 점은, 대개 이를 알아차릴 수 없다는 것입니다.

그렇다면 AIStupidLevel이란 정확히 무엇인가요?

AIStupidLevel은 AI 모델이 퇴보하고 있는지 여부를 지속적으로 모니터링하는 제3자 벤치마크 플랫폼 (오픈 소스, MIT 라이선스)입니다. 이를 AI 모델의 "건강 상태"를 점검하는 시스템 상태 점검(system health check)이라고 생각하면 됩니다. 이 플랫폼은 7개의 제공업체로부터 나온 21개의 프로덕션 모델 — OpenAI, Anthropic, Google, xAI, DeepSeek, Kimi, GLM — 을 대상으로 24시간 내내 테스트를 수행하며, 각 모델의 현재 성능을 대시보드 상의 점수로 변환합니다.

이 플랫폼은 어떤 AI 기업에 의해서도 운영되지 않으며, 이 점이 여기서 매우 중요합니다. 모델을 채점하는 사람이 모델을 판매하는 사람이어서는 안 되기 때문입니다.

실제로 어떻게 테스트하나요?

핵심 아이디어는 간단합니다:

고정된 문제 은행을 반복 실행합니다. 고정된 작업 세트를 유지하며, 정해진 일정에 따라 각 모델에 문제를 던지고 점수를 기록합니다.
동일한 작업을 N번 수행합니다. 모델의 출력은 확률적(stochastic)이기 때문에, 각 작업을 5번 실행하여 중앙값(median)과 95% 신뢰 구간(confidence interval)을 산출합니다.

순환되는 4가지 스위트(suites)

단 한 종류의 테스트만 실행하는 것이 아니라, 서로 다른 요소를 감시하는 4가지 스위트가 교대로 실행됩니다:

테스트 스위트	빈도	테스트 내용
속도 (코딩)	4시간마다	147개의 코딩 문제, 전반적인 코딩 능력
...

매시간 실행되는 카나리(canary) 테스트는 파수꾼 역할을 합니다. 무언가 이상해 보이기 시작하면 경보를 울립니다. 매일 실행되는 심층 추론(deep reasoning) 및 도구 호출(tool-calling) 실행은 더 무거운 전신 검진과 같습니다.

도구 호출(tool-calling) 스위트는 제가 특히 흥미롭다고 생각하는 부분입니다. 이 스위트는 실제로 Docker 샌드박스(격리된 미니 컴퓨터라고 생각하면 됩니다)를 구동하여, AI가 단순히 도구를 사용할 수 있다고 "말로" 주장하는 대신 그 안에서 실제 명령어를 실행하게 합니다. 그 결과는 AI를 사용하여 코드를 작성할 때 실제로 느끼는 경험과 훨씬 더 유사하게 나타납니다.

점수 산정은 단순히 맞음 vs 틀림이 아닙니다

단일 코딩 작업은 9개의 가중치가 부여된 차원에 따라 점수가 매겨집니다:

차원	가중치
정확성 (Correctness)	40%
...

정확성이 분명히 지배적인 비중을 차지하지만, 설령 답이 실행된다 하더라도 코드가 엉망이거나, 예외 케이스(edge cases)를 놓치거나, 쓰레기 같은 포맷팅을 쏟아낸다면 여전히 점수를 잃게 됩니다.

모델이 멍청해지기 시작하는 순간을 어떻게 포착할까요?

단순히 점수만 가지고 있는 것으로는 충분하지 않습니다. AI는 비결정론적 (non-deterministic)이기 때문에 점수는 자연스럽게 변동하기 마련입니다. 진짜 질문은 이것입니다: 이 하락이 실제 성능 저하 (regression)인가, 아니면 단순한 노이즈인가?

이 지점이 이 프로젝트가 기술적으로 흥미로워지는 부분입니다. 이 프로젝트는 CUSUM이라 불리는 알고리즘을 사용합니다. 이는 누적 합 제어 차트 (Cumulative Sum Control Chart)의 약자입니다. CUSUM은 AI 연구에서 나온 것이 아니라, 제조업에서 사용되는 오래된 품질 관리 (quality-control) 방식입니다. 핵심 아이디어는 관찰된 성능과 기준선 (baseline) 사이의 격차를 계속해서 누적하는 것입니다. 누적된 격차가 임계값 (threshold)을 넘어서면, 이를 확정합니다: 이것은 노이즈가 아니라, 실제로 무언가 변했다는 것을 말이죠.

CUSUM에 더해, 오경보 (false alarms)를 줄이기 위해 2차 검증 단계로 통계적 유의성 검정 (statistical significance testing, 차이가 통계적으로 의미 있는지 확인하며 p-value가 0.05 미만인지 체크)을 실행합니다.

진정한 승부처는 이 통계적 메커니즘 덕분에, 사람들이 소셜 미디어에서 "AI가 멍청해졌다"며 불만을 터뜨릴 때까지 기다리는 대신, 성능 저하가 시작된 지 몇 시간 이내에 이를 감지할 수 있다는 점입니다. 이 시스템에는 다양한 이상 패턴 (anomaly patterns)을 위해 구축된 29가지 경고 카테고리가 내장되어 있습니다.

멍청함 측정기 (Stupid Meter) 읽기

각 모델 옆에는 0~100 사이의 실시간 점수가 표시되며, 높을수록 좋습니다. 점수 옆에는 모델이 다음 네 가지 상태 중 어느 상태에 있는지 알려주는 상태 태그가 붙습니다:

STABLE (안정) — 정상적으로 작동 중
VOLATILE (변동) — 요동치는 중
DEGRADED (저하) — 이미 성능이 나빠짐
RECOVERING (회복) — 다시 상승 중

현재 점수 외에도 각 모델의 과거 곡선을 보여주므로, "이 모델은 지난주에 매우 견고했는데, 왜 이번 주에는 요동치고 있는가"와 같은 시나리오를 비교할 수 있습니다.

실제로 사용해 보면 마치 주식 거래 대시보드처럼 느껴집니다. 정적인 순위를 보는 것이 아니라, "바로 지금 이 순간, 어떤 모델을 사용하는 것이 가장 가치 있는가"를 확인하는 것이죠. 만약 처음에 어떤 AI 도구를 선택해야 할지 여전히 고민 중이라면, 저의 이전 포스트인 Which AI Coding Tool Should You Pick in 2026?가 이 글과 잘 어울릴 것입니다.

Smart Router: 성능이 저하된 모델을 자동으로 우회하기

모니터링을 넘어, AIStupidLevel은 이 프로젝트의 매우 흥미로운 확장 기능인 Smart Router라는 기능을 함께 제공합니다.

이 기능은 OpenAI 호환 API 엔드포인트(API endpoint)로 작동하므로, OpenAI를 대상으로 작성한 코드를 거의 수정할 필요가 없습니다. 각 제공업체의 API 키를 입력하고(AES-256 암호화로 저장됨), 기본 URL(base URL)을 이 엔드포인트로 지정하면, 실시간 모니터링을 기반으로 현재 상태가 가장 좋은 모델로 각 요청을 라우팅(routing)합니다.

여섯 가지 라우팅 전략(routing strategies)을 제공하며, API 호출 시 model 필드를 이 중 하나로 설정하기만 하면 동적으로 선택됩니다:

auto-best — 종합적인 선택, 현재 결합 점수가 가장 높은 모델
auto-coding — 현재 코딩에 가장 뛰어난 모델
auto-reasoning — 추론 (reasoning) 능력이 가장 강력한 모델
auto-creative — 창의적인 결과물에 치중하는 모델
auto-cheapest — 품질 기준을 충족하는 모델 중 가장 저렴한 모델
auto-fastest — 품질 기준을 충족하는 모델 중 가장 빠른 모델

단순히 auto를 전달하면 사용자가 기본값으로 설정한 전략을 사용합니다. 그리고 특정 모델 이름(예: claude-opus-4-7)을 전달하면 해당 모델을 직접 고정(pin)하고 라우터를 건너뜁니다. 따라서 특정 모델의 성능이 조용히 떨어지기 시작하고 Smart Router가 이를 포착하면, 트래픽은 여전히 상태가 양호한 형제 모델로 자동 라우팅됩니다. AI를 실제 제품에 연결하고자 한다면 매우 유용한 기능입니다.

요약

그렇다면 AIStupidLevel이란 무엇일까요?

7개의 제공업체(OpenAI, Anthropic, Google, xAI, DeepSeek, Kimi, GLM)에 걸친 21개의 프로덕션 AI 모델을 24시간 내내 모니터링하는 독립적인 오픈 소스 (MIT) 제3자 벤치마크 사이트
방법: 고정된 질문 은행을 반복 실행 — 각 태스크는 5회 실행되며, 4개의 테스트 스위트(test suites)를 순환하며 중앙값(median)과 95% 신뢰 구간(confidence interval)을 산출
CUSUM 변화점 탐지 (CUSUM change-point detection) 및 통계적 검정을 사용하여 모델의 성능이 몇 시간 내에 조용히 저하되는 것을 포착
실시간 모니터링을 기반으로 현재 상태가 가장 좋은 모델로 API 트래픽을 자동 라우팅하는 Smart Router 제공

다음에 AI가 갑자기 멍청해졌다고 느껴질 때, 바로 자신을 탓하지 마세요. 대시보드를 열어보면 실제로 그 증거를 찾을 수도 있습니다.