메타 Muse, 내부적으로 'azure/muse-special'이라는 OpenAI 모델 사용 정황
한 개발자가 Meta의 AI 웹사이트 빌더 Muse의 파일시스템과 세션 로그를 분석한 결과, 대부분의 세션은 Meta 내부 모델 'Avocado'를 사용하지만 일부 서브에이전트가 'azure/muse-special'이라는 모델을 사용했으며, 응답 시그니처와 툴콜 ID 패턴으로 미루어 OpenAI(GPT) 모델일 가능성이 높다는 것. Muse 에이전트 데몬에는 Claude, GPT, Kimi 등 다양한 외부 모델 클라이언트가 포함되어 있어 Meta가 사용자 동의 없이 서버 측에서 모델 라우팅을 변경할 수 있는 인프라를 갖추고 있으나, OpenAI/Anthropic 모델의 원시 추론(chain of thought)은 암호화되어 RL에 활용되지 않으므로 지식 증류(distillation) 증거는 없다는 결론.
Muse가 제 웹사이트를 만들고 있을 때 'azure/muse-special'이라는 라벨이 붙은 모델을 발견했습니다. 그래서 더 깊이 파고들었습니다. 이번 주 제 글이 해커뉴스(Hacker News) 메인 페이지에 오른 후 Muse 파일시스템을 파헤친 시리즈의 2부입니다. 이 글에서는 로그에서 발견한 'muse-special'이라는 모델에 집중하고, Muse가 실제로 이면에서 OpenAI와 Claude 모델을 사용하는지라는 질문에 정면으로 마주합니다.
이상한 세션 하나 Muse는 각 에이전트 세션이 어떤 모델을 사용하는지 기록합니다. 제 VM의 거의 모든 세션 로그는 Meta의 내부 모델인 'Avocado'로 라우팅되어 있었습니다. 하지만 한 서브에이전트가 'azure/muse-special'이라는 이름의 모델을 사용했습니다. 흥미롭군요...
이름 추적하기 궁금해진 저는 Cursor 안의 저장소 전체를 검색해서 다음을 발견했습니다: "GPT Responses model client via MAGI native Azure OpenAI lane." (MAGI 네이티브 Azure OpenAI 레인을 통한 GPT Responses 모델 클라이언트). 알겠습니다. 모델 카탈로그에는 'azure/muse-special' 다음에 'azure/gpt-5.6-sol'이 나열되어 있는 것 같습니다. 그래서 제 세션 트랜스크립트를 검색해봤습니다...
여기서 눈에 띄는 두 가지 세부 사항을 발견했습니다: 시그니처에 'gpt_responses_v1'이라는 태그가 붙어 있고, OpenAI가 사용하는 'gAAAAA'로 시작하는 암호화된 페이로드를 포함하고 있습니다. 툴콜 ID는 'call_' 뒤에 대소문자 혼합 24자리를 사용했습니다. 이는 Avocado 세션이 출력한 다른 모든 라인들('call_' 뒤에 16진수 32자리)과 달랐습니다. 이런 작은 세부 사항들이 muse-special 모델이 OpenAI 모델 또는 OpenAI의 Responses API일 가능성이 있음을 말해줍니다. 그렇다면 muse-special은 Azure를 통해 제공되는 GPT 모델의 별칭일까요? 파일과 로그만으로는 정확히 어떤 GPT 모델인지, 왜 서브에이전트가 그것을 선택했는지 알 수 없지만, 한 걸음 물러나 더 탐구해봅시다...
모델 카탈로그 Muse의 에이전트 데몬에 포함된 전체 모델 카탈로그에는 약 15개 버전의 Avocado와 함께 다음이 나열됩니다:
- Claude Opus 4.6 / 4.7 / 4.8
- Sonnet 4.6 및 Haiku 4.5
- OpenAI, Azure, Codex를 통한 GPT-5.5 및 GPT-5.6 변형
- Fireworks 및 Meta 자체 호스팅 경로를 통한 Kimi K3
Anthropic 연동 내부 Claude 지원은 단순한 모델 ID를 넘어, 요청 처리, 프롬프트 변환, 스트리밍 파서를 포함한 Anthropic 클라이언트를 포함합니다:
- anthropic/request_flow.rs
- anthropic/convert_prompt.rs
- anthropic/parse_sse_stream.rs
자, 이제 궁금해집니다... 왜일까요? Anthropic, OpenAI 등의 API 키 파일이 존재하며, inference-proxy 서비스만 접근할 수 있도록 제한되어 있습니다. ...하지만 환경설정에는 프록시 킬스위치(kill-switch) 설정도 있습니다. 왜 이 모든 것을 탑재해서 배포하는 걸까요?
이유는 몇 가지 있을 것 같습니다. 첫째, 특정 작업에서 OpenAI나 Anthropic 모델이 Muse가 현재 충족할 수 없는 더 우수한 성능을 발휘하고, 그것을 선택적으로 라우팅하는 것일 수 있습니다. 둘째, 이 모든 VM이 증류(distillation)와 RL을 목적으로 모델 응답, 툴콜 등을 A/B 테스트할 수 있는 능력을 갖추고 배포된 것일 수 있습니다. 증디 또는 RL? 글쎄요, 모르겠습니다.
이것이 우리를 진실로 이끕니다. 즉, Muse 뒤에 있는 모델은 궁극적으로 서버 측의 선택이라는 것입니다. 런타임은 여러 프로바이더의 클라이언트를 갖추고 있어, Meta가 사용자에게 동의를 구하지 않고도 라우팅을 변경할 수 있습니다. 제 경우 Avocado(Meta) 모델을 사용하지 않은 세션은 단 하나의 이상치(outlier)였지만, 그런 인프라는 존재합니다.
Meta는 증류를 하고 있나? 잠깐, 그럼 Meta가 다른 프론티어 연구소들로부터 증류를 하고 있는 걸까요? (기술적으로 들어갑니다. 요약: 아닙니다.) muse-special 모델의 경우 원시 추론(reasoning)이 암호화되어 있습니다. 데몬은 이를 다음 턴에 Azure로 다시 보내기 위해 저장합니다. 바이너리에는 암호화된 추론이 RL completion-server 오버라이드를 사용할 수 없다고 명시되어 있습니다. 따라서 Meta가 여기서 볼 수 있는 것은 응답, 툴콜, 그리고 OpenAI/Anthropic이 반환할 경우 짧은 추론 요약뿐입니다. 원시 사고 과정(chain of thought)은 암호화되어 있으며 RL 서버는 그 블롭을 거부합니다. Meta가 OpenAI나 Anthropic의 가중치를 복사했다는 징후는 없습니다.
다만 Avocado 모델은 다르게 취급됩니다. 추론 텍스트는 빈 시그니처와 함께 트랜스크립트에 직접 기록되며, RL에 사용 가능합니다. 따라서 개인정보 보호 안내와 저장소에 따르면, Avocado 모델의 경우 대화가 Meta의 AI 개발에 사용될 수 있다는 점을 시사합니다(단, 원문이 여기서 끊김).