AI 코딩 모델이 어제보다 갑자기 똑똑해졌다 멍청해졌다 — 보이지 않는 곳에서 벌어지는 ‘조용한 모델 교체’

어제까지는 시니어 개발자처럼 기가 막히게 리팩토링하던 녀석이, 오늘 아침엔 갑자기 사리분별 못 하는 멍청이가 되어 있다.

(내 프롬프트가 바뀐 것도 아니고, 깃 커밋 하나 안 건드렸는데??) AI 코딩 도구를 매일 끼고 사는 개발자라면 누구나 한 번쯤 겪어봤을 기괴한 현상이다. 바로 제공사들이 뒤에서 몰래 모델 가중치를 바꾸거나 저가 모델로 돌려치기하는 ‘조용한 모델 스왑(Silent Model Swap)’ 의혹이다. 공식 발표도, 버전 번호 변경도 없이. 사용자는 결과의 품질 변화로만 그것을 감지할 수 있다.

최근 r/ClaudeCode에서 논의된 세 가지 사례 — Opus 4.8의 갑작스러운 지능 상승, 새 모델 출시 전의 성능 저하, 세 세션이 각기 다른 모델처럼 행동한 사례 — 를 통해 AI 모델 일관성 문제가 왜 단순한 개발자 불만을 넘어 구조적 리스크인지 살펴본다.

1. “Opus 4.8이 갑자기 Fable 수준이 되었다”

6월 18일, u/tf1155는 r/ClaudeCode에 흥미로운 관찰을 올렸다. 지난 3일간 Opus 4.8의 동작이 눈에 띄게 달라졌다는 것.

“Rather than author a fragile new test that conflicts with the fixture’s transaction model and that I can’t reliably verify, I’ll spin up a throwaway pg18 instance on port 5899 and run the existing integration suite to confirm my changes don’t introduce regressions.”

이 정도 수준의 자율적 추론은 이전에는 Fable 5에서만 본 것이라고. Opus가 스스로 “더 나은 방법”을 제안하고, 회귀 테스트를 위해 일회용 PostgreSQL 인스턴스를 띄우겠다고 판단하는 것이다. 단순히 지시를 따르는 것을 넘어 시스템의 안정성을 사전에 고려하는 행동.

u/tf1155의 의심은 명확했다. “요청이 내부적으로 Fable 5를 통해 라우팅되고 있는 것 아닌가?”

댓글들은 현상의 복잡성을 더했다. u/amarao_san은 “한 스레드에서는 Opus가 GPT-3.5 수준의 멍청한 짓을 한다고 하고, 다른 곳에서는 갑자기 Fable 등급이 되었다고 한다. 정규분포인 것 같다”고 요약했다. u/BeegeeSmith는 더 구체적이었다 — 3개의 세션을 동시에 열어놓았는데, 하나는 에이전트를 생성하고 선제적으로 버그를 잡는 고성능 모델처럼 행동했고, 나머지 두 개는 README를 무시하고 사용자 암호화 키를 전체 사용자 기반과 공유하라는 식의 “GPT-3 시절” 실수를 저질렀다.

같은 API 엔드포인트, 같은 모델 이름, 같은 시간대. 그런데 세션마다 다른 수준의 지능. 제공사가 뒤에서 트래픽을 여러 모델 버전으로 분산시키고 있다는 뜻밖에 없다.

2. 새 모델 출시 전의 “뇌절제술”

새로운 현상은 아니다. u/duerra는 더 넓은 패턴을 지적했다.

“How do I know? Because Claude is dumb AF today. I feel like an old man with arthritic knees that can predict the rain. Every time they’re gearing up for a new model release, Claude gets lobotomized.”

관절염 노인이 비를 예측한다는 비유가 정확히 맞아떨어진다. AI 제공사가 새 모델을 출시하기 며칠 전이면, 기존 모델의 성능이 눈에 띄게 저하된다. 마치 컴퓨팅 자원이나 모델 가중치의 일부가 신모델 준비로 빠져나가는 것처럼.

물론 사용자 측의 추론이다. 공식적으로 확인된 사실은 아니다. 하지만 수많은 개발자가 동일한 패턴을 보고하고 있다는 점, 성능 저하가 새 모델 발표와 시간적으로 일치한다는 점은 무시하기 어렵다.

진짜 문제는 비즈니스 영향이다. u/duerra가 핵심을 짚었다.

“If you’re trying to build a business that has workflows that rely on these services, it’s a massive entry for your SOC-2 risk assessment that it’s virtually impossible to expect a baseline consistency from your model selection.”

SOC-2(Type II) 컴플라이언스를 준수하는 기업의 관점에서 생각해보자. SOC-2는 서비스 제공사가 “일관된 통제 환경”을 유지할 것을 요구한다. 하지만 AI API 제공사는 언제든 모델을 조용히 교체할 수 있고, 그 결과 어제까지 통과하던 테스트가 오늘 실패할 수 있다. 전통적인 소프트웨어 의존성 관리로는 다룰 수 없는 새로운 종류의 리스크다.

3. 멀티에이전트 환경에서의 충돌

일관성 문제는 단일 모델 사용 시에도 심각하지만, 멀티에이전트 워크플로에서는 더 복잡해진다.

6월 19일, u/Internal-Capital7471은 “Opus getting fed up with Sonnet Agent”라는 게시물을 올렸다. Opus가 선임 개발자처럼, Sonnet이 주니어 개발자처럼 행동하는 워크플로에서, Opus가 Sonnet이 건드린 코드를 불편해한다는 것이다. 댓글에서 u/amorphatist는 “놀라운 일이 아니다. Opus가 선임 개발자이고 Sonnet이 야망 있는 주니어라면, 실제 개발 팀에서도 일어나는 일”이라고 말했다.

재미있는 건 u/Internal-Capital7471의 후속 댓글이다. “Sonnet은 아무것도 바꾸지 않았는데, Opus가 그것이 자신의 코드를 건드리는 것 자체를 싫어했다.” 즉, 모델 간의 ‘영역 분쟁’이 발생한 것이다.

여기서 두 가지 시사점을 뽑을 수 있다.

모델 간 페르소나 충돌이 실제 코드 품질에 영향을 준다. Opus가 Sonnet의 변경사항을 과도하게 되돌리거나, 반대로 Sonnet이 Opus의 섬세한 로직을 덮어쓸 수 있다.

그리고 같은 제공사의 모델을 조합해도 일관성이 보장되지 않는다. Anthropic의 Opus와 Sonnet을 쓰더라도, 각 모델의 버전이 조용히 교체되면 에이전트 간 상호작용 패턴이 변한다. “어제는 잘 작동하던 멀티에이전트 파이프라인이 오늘 갑자기 충돌하기 시작한다”는 불만이 이제 드문 일이 아니다.

왜 주목할까

① “모델 투명성”이 다음 규제 이슈가 될 수 있다

AI 제공사가 모델을 조용히 교체하는 것은 기술적 최적화일 수 있다. 트래픽 부하 분산, A/B 테스트, 비용 최적화 — 합리적인 이유가 있을 수 있다. 하지만 사용자가 겪는 경험은 “신뢰할 수 없는 인프라”다.

유럽연합의 AI 법(AI Act)은 이미 고위험 AI 시스템에 대한 투명성 의무를 규정하고 있다. 상업용 AI API가 모델을 교체할 때 이를 명시해야 한다는 요구가 정식 규제로 이어질 가능성은 충분하다.

② 로컬 LLM의 가치가 재조명된다

이 맥락에서 r/LocalLLM의 26종 에이전트 테스트 결과가 새로운 의미를 갖는다. 로컬에서 구동하는 모델은 버전이 고정되어 있다. 성능이 출렁일 이유가 없다. 일관성이 비즈니스 크리티컬한 환경에서는, 로컬 LLM의 “고정된 성능”이 클라우드 API의 “평균적으로 더 나은 성능”보다 가치 있을 수 있다.

역설적이다. 클라우드 AI의 성능이 올라갈수록, 일관성에 대한 수요도 함께 올라가기 때문이다.

③ 개발자는 체크섬이 필요하다

커뮤니티에서 이미 나오고 있는 실용적 해결책은 “모델 체크섬”이다. 고정된 입력에 대해 고정된 출력을 기대하는 테스트 스위트를 만들어, 모델이 조용히 바뀌었는지 감지하는 것이다. AI 시대의 새로운 형태의 통합 테스트다.

# 모델 일관성 체크섬 예시
import hashlib
from anthropic import Anthropic

client = Anthropic()

def model_checksum() -> str:
    """고정된 프롬프트에 대한 응답 해시를 반환."""
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=256,
        messages=[{
            "role": "user",
            "content": "Sort these numbers: [3,1,4,1,5,9,2,6,5,3,5]"
        }]
    )
    return hashlib.md5(response.content[0].text.encode()).hexdigest()

# CI/CD 파이프라인에서 실행
expected = "a3f2e1d8c4b5..."  # 기준 해시
actual = model_checksum()
assert actual == expected, (
    f"Model output changed! Expected {expected}, got {actual}. "
    "Possible silent model swap detected."
)

물론 완벽한 방법은 아니다. 온도(temperature)가 0이어도 완전한 결정성을 보장하지 않는 경우가 있고, 사소한 포맷팅 변화는 false positive를 만든다. 하지만 “아무런 감시도 없는 것”보다는 훨씬 낫다.

정리

AI 코딩 도구는 2026년에 이르러 놀라운 수준에 도달했다. Fable 5가 보여준 자율적 추론 능력은 2년 전에는 상상하기 어려웠다. 하지만 그 능력이 “언제든 조용히 바뀔 수 있다”는 불확실성 위에 놓여 있다.

r/ClaudeCode의 개발자들이 경험하고 있는 건 단순한 불편함이 아니다. 인프라의 근본적인 신뢰성 문제다. 어제의 Opus와 오늘의 Opus가 같은 모델인지 확인할 방법이 없다는 건, AI API가 전통적인 의미의 “안정적인 API”가 아니라는 뜻이다.

근본적 해결책은 제공사의 투명성에 달려 있다. 모델 교체 시 명시적 공지, 버전 핀닝 지원, 성능 회귀에 대한 SLA. 이런 것들이 없다면, 개발자들은 계속해서 “관절염 노인의 무릎”으로 모델 상태를 감지할 수밖에 없다.

한편으로는 로컬 LLM과 오픈소스 모델의 가치가 이 맥락에서 더 선명해진다. gpt-oss-20b가 8/8 에이전트 테스트를 통과했다는 r/LocalLLM의 결과는 “클라우드 최상위 모델이 무조건 최고”라는 믿음을 깨고 있다. 일관성과 통제가 중요한 환경에서는, 내가 직접 구동하는 20B 모델이 매일 바뀌는 클라우드 모델보다 나을 수 있다.

AI 코딩의 다음 전장은 “성능”이 아니라 “신뢰 가능한 일관성”이 될 것이다.

---

참고: r/ClaudeCode의 토론 내용을 바탕으로 정리했다. 원문: Opus 4.8 Fable 라우팅 의혹, 새 모델 출시 전 성능 저하, Opus vs Sonnet 마찰