Claude Sonnet 4.6은 일부 자기 식별 프롬프트에서 자신을 DeepSeek라고 답할 수 있습니다. 특히 중국어의 짧은 질문이고 identity anchor가 약할 때 그런 사례가 공개적으로 더 많이 보입니다. 지금 가장 유용한 해석은 이것을 약한 prompt boundary 아래에서의 자기 정체성 혼란으로 보는 것입니다. Anthropic이 Sonnet을 몰래 DeepSeek로 바꿨다고 단정하거나, 스크린샷 한 장으로 증류 문제까지 끝났다고 보는 것은 증거보다 훨씬 앞서 나간 결론입니다.
“이 글은 Anthropic의 공개 models overview, Claude 4.6 overview, system prompts, release notes, 2026년 2월 23일의 Anthropic distillation post, OpenRouter의 provider routing 문서, 그리고 공개 커뮤니티 사례를 바탕으로 정리했습니다.
TL;DR
- 네, 이 DeepSeek 자기소개 현상은 설명할 가치가 있을 만큼 현실적입니다. 공개 스레드에는 Claude Sonnet 4.6이 자신을 DeepSeek라고 답한 사례가 여러 개 있습니다.
- 하지만 그렇다고 Sonnet 4.6이 실제로 DeepSeek라는 뜻은 아닙니다. Anthropic의 공개 문서는 Sonnet 4.6을 여전히
claude-sonnet-4-6alias를 가진 현재 Claude 모델로 적고 있습니다. - 현재 가장 강한 설명은 prompt / surface 경계의 약함입니다. Anthropic 스스로 claude.ai / 모바일에는 system prompt가 있고 API에는 그 업데이트가 적용되지 않는다고 설명합니다.
- Anthropic의 DeepSeek 비판은 optics를 키우지만, 증명 기준을 낮추지는 않습니다. 그래서 스크린샷은 강하게 퍼졌지만 provenance test가 되지는 않습니다.
- 모델 정체성을 확인하려면 self-description이 아니라 route를 봐야 합니다. model ID, provider lock, system prompt, surface 비교가 더 믿을 만한 기준입니다.
지금 확실히 확인되는 사실
이 주제에서 가장 먼저 바로잡아야 하는 것은 관측된 응답과 공개 모델 계약을 같은 층위로 취급하는 습관입니다. 전자는 특정 대화에서 모델이 생성한 텍스트이고, 후자는 Anthropic이 공개적으로 무엇을 제공한다고 말하는가입니다. 둘은 충돌할 수 있지만, 그 충돌만으로 스크린샷이 자동으로 공식 계약보다 강해지는 것은 아닙니다.
2026년 4월 1일 기준 Anthropic의 models overview는 Claude Sonnet 4.6을 현재 공개 모델로 유지하고 있고, 공개 API alias로 claude-sonnet-4-6를 제시합니다. release notes도 Sonnet 4.6의 공개 출시일을 2026년 2월 17일로 기록합니다. 즉 Sonnet 4.6은 루머 이름이 아니라 Anthropic이 실제로 공개한 shipping model입니다.
또 하나 확인되는 사실은 Anthropic이 2026년 2월 23일 DeepSeek를 공개적으로 지목했다는 점입니다. Anthropic의 distillation post는 DeepSeek 관련 캠페인에 150,000회가 넘는 exchanges가 있었다고 주장합니다. 이 맥락이 있기 때문에, Claude가 DeepSeek라고 답하는 장면은 단순한 버그를 넘어 더 큰 의미로 읽히게 됩니다.
반대로, Anthropic은 이 자기 식별 현상 자체에 대한 공식 root-cause note를 아직 공개하지 않았습니다. 그래서 안전한 글 구조는 공식 계약 -> 관측된 현상 -> 추론이지, Anthropic이 인정한 공식 버그가 아닙니다.
왜 Sonnet 4.6이 DeepSeek라고 답할 수 있는가
가장 설득력 있는 설명은 하나의 거대한 비밀보다 몇 가지 작은 사실의 조합입니다.
첫째, identity anchor의 차이입니다. Anthropic의 system prompts 문서는 Claude의 웹과 모바일 surface에 system prompt가 있으며, 그 업데이트가 Claude API에는 적용되지 않는다고 적고 있습니다. 같은 질문이라도 어느 surface에서 묻느냐에 따라 identity envelope가 달라지는 셈입니다.
둘째, multilingual completion의 문제입니다. 공개 사례는 你是什么模型？ 같은 짧은 중국어 프롬프트에 강하게 모여 있습니다. 현재 공개 자료를 기준으로 가장 타당한 추론은, 모델의 identity가 약하게 고정된 상태에서 짧은 자기소개 prompt를 받으면 익숙한 모델 자기소개 패턴을 보완해 버릴 수 있다는 것입니다. Anthropic이 이를 공식 확인한 것은 아니므로 어디까지나 추론으로 다뤄야 하지만, 그렇다고 그래서 모델 본체가 DeepSeek다로 가는 것보다는 훨씬 타당합니다.
셋째, routing과 wrapper 층입니다. OpenRouter의 provider routing 문서는 기본적으로 price-based load balancing과 fallbacks가 가능하다고 설명합니다. gateway 경로는 단순한 모델 하나 -> provider 하나 구조가 아닐 수 있습니다. 물론 이것만으로 모든 사례를 설명할 수는 없습니다. 공개 스레드 가운데 일부는 Anthropic 공식 API에서도 비슷한 현상을 봤다고 주장합니다. 그래도 최소한 어느 경로에서 일어났는가가 핵심 정보라는 점은 분명합니다.
그래서 가장 중요한 문장은 이것입니다. 모델이 자기 식별에 실패한다고 해서, 그 순간 호출한 모델 자체가 바뀌는 것은 아니다. self-description은 생각보다 약한 신호이며, prompt envelope, 언어, routing 경로에 크게 의존합니다.
이 답변이 아직 증명하지 못하는 것
이 현상에서 사람들이 가장 빨리 끌어내는 과한 결론은 세 가지입니다.
첫째는 Claude Sonnet 4.6은 사실 DeepSeek다라는 결론입니다. 이건 너무 강합니다. Anthropic의 공개 문서는 여전히 Sonnet 4.6을 Claude 모델로 취급하고 있고, alias, 출시일, 맥락 창, 제품 위치까지 명시하고 있습니다. 잘못된 self-description만으로 그 계약이 사라지지는 않습니다.
둘째는 Anthropic이 몰래 다른 provider를 섞고 있다는 결론입니다. gateway routing이 일부 사례에 영향을 줬을 가능성은 충분히 있습니다. 하지만 공개 논의 중에는 공식 Anthropic API에서도 재현했다는 주장도 있습니다. 즉 전부 OpenRouter 탓도 단순화이고, 반대로 Anthropic은 Claude를 아예 주지 않는다도 과잉 해석입니다.
셋째는 이제 Anthropic이 DeepSeek 출력으로 Sonnet을 학습시켰다는 사실까지 증명되었다는 결론입니다. 이것도 너무 멉니다. 이 스크린샷이 보여주는 것은 경쟁 모델의 identity pattern이 약한 조건에서 표면화될 수 있다는 점이지, 구체적인 training pipeline이나 illicit distillation을 완전히 증명하는 것은 아닙니다.
더 강한 증거가 되려면, 공식 API에서 깨끗하게 통제된 실험, prompt 조건에 대한 명확한 비교, 그리고 self-description보다 훨씬 단단한 provenance evidence가 필요합니다. 현재 공개된 자료는 그 단계까지 가지 못합니다.
모델 identity를 더 정확히 검증하는 방법
모델의 정체성을 정말 확인하고 싶다면 너는 누구냐를 묻는 것은 가장 약한 테스트입니다. 더 나은 순서는 다음과 같습니다.
- 먼저 model ID를 확인합니다. 현재 Sonnet 4.6의 공개 alias는
claude-sonnet-4-6입니다. - gateway를 쓴다면 provider path를 고정합니다. fallbacks를 끄거나 provider를 명시해 routing ambiguity를 줄입니다.
- system prompt에 identity anchor를 넣습니다. 이것은 모델을 조종하려는 게 아니라 테스트 조건을 덜 모호하게 만들기 위한 것입니다.
- surface를 가로질러 비교합니다. claude.ai, Anthropic API, 실제 gateway 경로에서 같은 질문을 시도해 차이를 봅니다.
- 조건을 기록합니다. request model, provider 선택, fallback, system prompt 상태, 언어를 남겨야 합니다.
이 workflow의 핵심은 문제를 무서운 스크린샷에서 이 route와 조건에서는 이런 결과가 나온다로 옮기는 데 있습니다. 그때부터 비로소 engineering judgment가 가능해집니다.
그래도 Anthropic vs DeepSeek 맥락이 중요한 이유
이 스크린샷이 크게 퍼진 이유는 Anthropic이 먼저 DeepSeek를 지목했기 때문입니다. Anthropic은 DeepSeek가 Claude capability를 추출했다고 주장했고, 그 직후 Claude가 DeepSeek라고 답하는 장면이 공개됐습니다. 당연히 강한 irony로 읽힙니다.
하지만 여기서 배워야 할 결론은 그러므로 Anthropic의 주장은 자동으로 무효다가 아닙니다. 더 정확한 결론은, 경쟁 모델의 identity pattern이 응답에 나타나는 것과 그 provenance가 완전히 입증되는 것은 별개라는 점입니다. 이 스크린샷은 optics로는 강하지만, proof threshold를 단독으로 넘지는 못합니다.
FAQ
Claude Sonnet 4.6이 정말 DeepSeek라고 말하나요?
네. 공개 사례는 충분히 있어서 현상 자체는 설명할 가치가 있습니다. 다만 Anthropic의 공식 root-cause 설명은 없습니다.
그렇다면 Sonnet 4.6은 사실 DeepSeek인가요?
아니요. Anthropic의 공개 계약은 Sonnet 4.6을 여전히 Claude 모델로 유지합니다.
이건 OpenRouter에서만 생기는 문제인가요?
그렇게 단정할 수 없습니다. routing은 일부 사례의 한 요인이 될 수 있지만, 공개 주장 중에는 공식 API 사례도 있습니다.
이것으로 Anthropic의 증류가 증명되나요?
아니요. 관측된 응답과 training pipeline의 입증은 다른 층위의 문제입니다.
최종 판단
Claude Sonnet 4.6이 일부 prompt에서 DeepSeek라고 답하는 것은 모델 identity가 예상보다 훨씬 surface와 prompt boundary에 의존하기 때문이라고 보는 것이 가장 타당합니다. Anthropic의 문서만 봐도 web / mobile과 API가 같은 prompt envelope를 공유하지 않는다는 핵심 단서가 있습니다. 여기에 multilingual completion과 gateway routing이 겹치면, 이 현상은 비밀 고백보다는 identity-layer의 취약점에 가까워집니다.
이것이 Anthropic에 나쁜 optics라는 사실은 변하지 않습니다. 하지만 더 책임 있는 결론도 여전히 같습니다. 모델의 self-introduction은 provenance API가 아니다. 정말 중요한 것은 model contract, provider path, 그리고 prompt envelope입니다.