메타가 최근 공개한 개인용 에이전트 제품 'Muse'를 두고, 한 개발자가 자신에게 할당된 실행 환경(VM)의 파일시스템과 로그를 직접 뒤지며 관찰한 기록이 화제가 되고 있다. 이 글은 그 두 번째 편으로, 웹사이트를 만들어 주던 Muse의 서브에이전트 하나가 다른 세션과 달리 'azure/muse-special'이라는 이름의 모델로 라우팅된 흔적을 발견한 데서 출발한다. 대부분의 세션은 메타 내부 모델로 보이는 'Avocado'로 처리됐지만, 유독 이 한 세션만 예외였다는 것이다. 겉으로는 하나의 통합된 에이전트처럼 보이는 제품 뒤에서 실제로 어떤 모델이 돌고 있는지를 사용자가 통제하거나 확인하기 어렵다는 점을, 이 사례는 구체적으로 드러낸다.
무엇이 발견됐나
필자가 코드 저장소를 검색하다 찾은 문구는 'MAGI 네이티브 Azure OpenAI 레인을 통한 GPT Responses 모델 클라이언트'였고, 모델 카탈로그에는 azure/muse-special에 이어 azure/gpt-5.6-sol 같은 항목이 나열돼 있었다고 한다. 로그에 찍히는 호출 식별자의 형식도 Avocado 세션(‘call_’ 뒤 32자리 16진수)과 달랐다. 이런 정황을 근거로 필자는 muse-special이 Azure를 통해 서빙되는 OpenAI 계열 모델, 혹은 OpenAI의 Responses API일 가능성을 제기한다. 다만 그는 파일과 로그만으로는 정확히 어느 GPT 모델인지, 왜 그 서브에이전트가 이 모델을 골랐는지는 알 수 없다고 분명히 선을 긋는다. 즉 이것은 확증이 아니라 관찰에 기반한 추정이다.
Muse의 에이전트 데몬에 함께 실린 모델 카탈로그에는 약 15종의 Avocado 버전 외에도 클로드(Claude) 지원이 포함돼 있었다고 한다. 그것도 단순한 모델 ID 수준이 아니라 요청 처리, 프롬프트 변환, 스트리밍 파싱까지 갖춘 앤트로픽 클라이언트 형태였다는 설명이다. 실제로 Anthropic·OpenAI 등의 API 키 파일이 존재했고, 접근 권한은 내부 추론 프록시 서비스로 제한돼 있었으며, 프록시를 끄는 킬 스위치 설정까지 환경 변수에 있었다고 한다.
핵심은 '서버가 정한다'는 구조
이 관찰에서 실무적으로 가장 중요한 대목은 특정 모델의 정체 자체가 아니라, 어떤 모델을 쓸지가 전적으로 서버 측 선택이라는 점이다. 런타임이 여러 공급사 클라이언트를 모두 품고 있다는 것은, 메타가 사용자에게 알리거나 동의를 구하지 않고도 라우팅을 바꿀 수 있는 인프라를 갖췄다는 뜻이다. 필자의 사례에서는 Avocado가 아닌 세션이 단 하나뿐이었지만, 그 하나가 전체 구조의 성격을 보여준다. 특정 순간에 어떤 모델이 응답했는지는 사후에 로그를 파헤쳐야 겨우 짐작할 수 있을 뿐, 제품 표면에서는 드러나지 않는다.
그렇다면 메타가 다른 프런티어 랩의 모델에서 지식을 증류(distillation)하는 것 아니냐는 의심이 자연스럽게 따라온다. 그러나 필자가 확인한 처리 방식은 오히려 반대 방향의 신중함을 보여준다. muse-special의 원시 추론 과정(raw reasoning)은 암호화된 상태로 저장돼 다음 턴에 다시 Azure로 전송되며, 바이너리에는 이 암호화된 추론이 RL(강화학습) 컴플리션 서버 오버라이드를 사용할 수 없다고 명시돼 있었다고 한다. 결국 메타 쪽에서 볼 수 있는 것은 최종 응답과 도구 호출, 그리고 OpenAI·앤트로픽이 반환하는 짧은 추론 요약뿐이며, 원시 사고 사슬은 암호화돼 RL 서버가 그 데이터를 거부한다는 것이다. 필자는 메타가 타사 가중치를 복제한다는 정황은 없다고 밝힌다.
반면 Avocado 모델은 취급이 다르다. 사고 과정 텍스트가 서명 없이 트랜스크립트에 그대로 기록되며 RL 용도로 활용될 수 있는 형태로 남는다. 그리고 개인정보 안내와 저장소 내용에 따르면, 자체 모델을 쓰는 대화는 사용자가 옵트아웃하지 않는 한 메타의 AI 개발에 사용될 수 있다고 표시돼 있다. 자사 모델과 외부 모델을 데이터 활용 측면에서 다르게 다루는 셈이다.
한국 실무자에게 주는 시사점
이 관찰기는 어디까지나 한 개인이 자신의 실행 환경을 들여다본 결과이며, 메타의 공식 문서나 관계자 발언에 기반한 확증은 아니라는 한계를 안고 있다. 그럼에도 통합 에이전트 제품을 도입하거나 벤치마크하려는 조직에는 분명한 메시지를 준다. 하나의 브랜드 뒤에서 실제 추론이 여러 공급사로 분산되고 그 라우팅이 서버에서 언제든 바뀔 수 있다면, '이 제품은 어떤 모델을 쓴다'는 전제 자체가 고정값이 아니게 된다. 응답 품질과 지연, 비용, 그리고 데이터가 학습에 쓰이는지 여부까지 세션마다 달라질 수 있다는 뜻이다. 외부 에이전트를 평가할 때 특정 모델명에 의존하기보다, 데이터 취급 정책과 옵트아웃 옵션, 그리고 라우팅 투명성을 계약과 검증의 기준으로 삼아야 하는 이유가 여기에 있다.