메타 Muse 런타임에서 정체불명 'azure/muse-special' 발견, OpenAI 모델 흔적

메타가 만든 에이전트 제품 Muse의 런타임을 뜯어본 개발자가 세션 로그에서 정체불명의 모델 하나를 발견했다. 이름은 azure/muse-special. 대부분의 에이전트 세션은 메타 내부 모델인 아보카도(Avocado)로 처리됐지만, 9월 21일 한 서브에이전트 세션만 이 모델을 썼다. 흔적은 OpenAI의 Responses API를 가리켰다.

단서는 여러 겹이었다. 해당 세션의 트랜스크립트에는 gpt_responses_v1 서명이 찍혀 있었고, gAAAAA로 시작하는 암호화 페이로드가 따라붙었다. 툴 호출 ID 형식도 달랐다. 아보카도 세션이 call_ 뒤에 32자리 16진수를 붙이는 반면, muse-special은 call_ 뒤에 대소문자가 섞인 24자리를 붙였다. 저장소 안에서는 GPT Responses 모델 클라이언트를 MAGI 네이티브 Azure OpenAI 레인으로 연결한다는 문구가 나왔고, 모델 카탈로그에는 azure/muse-special 바로 뒤에 azure/gpt-5.6-sol이 등록돼 있었다.

Muse의 에이전트 데몬에 실린 모델 목록은 이보다 넓다. 아보카도 변형이 약 15종, 그리고 OpenAI·Azure·Codex 경로를 통한 GPT-5.5와 GPT-5.6 변형, Fireworks와 메타 자체 호스팅 경로를 통한 Kimi K3가 포함된다. Claude 쪽은 모델 ID만 있는 게 아니라 요청 처리와 프롬프트 변환, 스트리밍 파서를 갖춘 Anthropic 클라이언트까지 들어가 있다. Anthropic과 OpenAI 등의 API 키 파일도 존재하지만 접근 권한은 inference-proxy 서비스로 제한돼 있고, 런타임 환경변수에는 프록시를 끊는 킬 스위치 설정도 있다.

왜 이런 구성이 들어갔을까. 한 가지 해석은 특정 작업에서 외부 모델이 더 나은 결과를 내기 때문에 선택적으로 라우팅한다는 것이고, 다른 해석은 모델 응답과 툴 호출을 A/B 테스트해 증류나 강화학습 데이터로 쓰기 위한 인프라라는 것이다. 어느 쪽이든 중요한 건 라우팅이 서버 측 결정이라는 점이다. 런타임에 여러 프로바이더 클라이언트가 들어 있으면 메타는 사용자에게 알리지 않고도 모델을 바꿔 끼울 수 있다.

개발자 입장에서 이 사례가 주는 실무적 시사점은 두 가지다. 첫째, 에이전트 제품에서 어떤 모델이 답을 만드는지는 이제 클라이언트 코드가 아니라 서버가 정하는 구성 요소가 됐다. 둘째, 모델 ID와 서명 태그, 툴 호출 ID 형식 같은 자잘한 로그 흔적이 실제 백엔드를 역추적하는 단서가 된다. 자체 모델과 외부 모델을 섞어 쓰는 구조는 앞으로 나올 개인 에이전트 제품에서 반복적으로 등장할 가능성이 크다.

다만 여기서 선을 그어야 할 부분이 있다. muse-special 세션의 원시 추론은 암호화돼 있고, 데몬은 이를 저장해 다음 턴에 Azure로 되돌려 보낸다. 바이너리에는 암호화된 추론이 RL 완료 서버의 오버라이드를 쓸 수 없다고 명시돼 있다. 메타가 확인할 수 있는 것은 응답과 툴 호출, 그리고 OpenAI나 Anthropic이 돌려줄 때의 짧은 추론 요약 정도다. 메타가 OpenAI나 Anthropic의 가중치를 복제한다는 근거는 없다.

반대로 아보카도 모델은 취급이 다르다. 사고 텍스트가 빈 서명과 함께 트랜스크립트에 그대로 기록되고 RL에 활용될 수 있다. 프라이버시 노트와 저장소 설명도 사용자가 옵트아웃하지 않는 한 대화가 메타의 AI 개발에 쓰일 수 있음을 시사한다.

정리하면, muse-special은 Azure를 통해 서빙되는 OpenAI 모델일 가능성이 높다는 추정이 가장 합리적이다. 정확히 어떤 GPT 모델인지, 왜 그 서브에이전트가 이 모델을 골랐는지는 로그만으로 알 수 없다. 개인 에이전트 런타임 내부를 이 정도로 들여다본 사례가 드물다는 점에서, 이번 분석은 앞으로의 구조를 가늠하는 초기 관측 기록에 가깝다.