2026년 7월 6일, Meta는 Llama API의 퍼블릭 프리뷰(Public Preview)를 종료했습니다. 이제 해당 API에 대한 요청은 모델의 결과값 대신, 어디로 이동해야 하는지를 안내하는 서비스 종료(sunset) 응답을 받게 됩니다. 사흘 뒤인 7월 9일, 회사는 Muse Spark 1.1 모델에 대해 새로운 셀프 서비스(self-serve) 액세스인 Meta Model API를 공개했으나, 현재는 미국 개발자들에게로 제한되어 있습니다. 기술 사양서에 단순히 "Meta AI와의 통합"이라고 적어둔 팀에게 이 두 사건은 같은 주의 서로 다른 두 사건이며, 그 중 어느 것도 사용자가 휴대폰 앱에서 보는 채팅 어시스턴트와는 관련이 없습니다.

"Meta AI"라는 브랜드는 서로 다른 생애 주기, 서로 다른 액세스 조건, 그리고 누구를 허용할지에 대한 서로 다른 결정권자를 가진 제품들을 하나로 묶고 있습니다. 구체적으로 문서화된 접점(surface)이 아닌 브랜드 이름에 따라 통합을 계획하는 것은, 실제 운영(prod) 환경에서 필요해지는 순간 전까지는 검증이 불가능한 의존성을 아키텍처에 심는 것을 의미합니다.

이후 저는 2026년 7월 18일 기준으로 확인된 Meta의 1차 자료를 바탕으로 이 브랜드를 각 접점별로 분류하고, 이를 하나의 허용 기준(criteria)으로 통합했습니다: 시나리오는 문서화된 접점과 확인된 액세스 권한이 모두 있을 때만 계획에 포함됩니다. 이 지도는 채팅 어시스턴트가 언젠가 자체적인 API를 갖게 될 것인지에 대한 질문에는 답하지 않습니다. 그것은 사실이 아니라 예측이기 때문입니다. 대신 이 지도는 다른 질문에 답합니다: 2026년 7월 18일 오늘, 아키텍처에 무엇을 반영할 수 있는가?

Meta AI 브랜드가 네 가지 서로 다른 제품을 숨기는 이유

일반 사용자에게 보이는 것부터 시작하겠습니다. 소비자용 어시스턴트인 Meta AI는 meta.ai, Meta AI 앱, 그리고 WhatsApp, Instagram, Messenger, Facebook 내부에 통합된 기능입니다. Meta의 자체 문서에 따르면, 이는 "Ask, Chat, Create"라는 슬로건 아래 개인용으로 제공되는 제품이며, 회사는 이 채팅 인터페이스를 위한 개발자용 API를 공개하지 않습니다. 이에 대한 직접적인 출처는 Meta AI 제품 페이지인 ai.meta.com/meta-ai (2026-07-18 접속)입니다.

여기서 첫 번째 괴리가 발생합니다. 개발자는 휴대폰을 켜고 어시스턴트가 질문에 답하거나 이미지를 생성하는 것을 보며 다음과 같은 결론을 내립니다. '화면에서 기능이 작동하고 있으니, 어딘가에 엔드포인트 (endpoint)가 있을 것이다.' 사용자가 기능을 볼 수 있다는 사실과 프로그래밍 방식의 호출 (programmatic call)이 가능하다는 사실은 서로 다른 두 가지 사실이며, 하나가 다른 하나를 자동으로 의미하지는 않습니다.

두 번째 괴리는 그 위에 겹쳐져 있으며, 훨씬 더 미묘합니다. Meta가 실제로 모델에 대한 프로그래밍 방식의 접근 권한을 제공하더라도, 그것은 모델에 대한 접근이지 소비자용 제품 전체에 대한 접근이 아닙니다. Muse Spark 1.1의 출시 방식이 이를 잘 보여줍니다. Meta AI Blog의 발표에 따르면, 이 모델은 Meta AI 앱 내부의 'Thinking' 모드에서 사용 가능함과 동시에 별도의 프로그래밍 인터페이스인 Meta Model API를 통해 제공됩니다. API는 어시스턴트라는 제품이 아닌 모델을 호출 가능하게 만듭니다. 즉, 사용자용 래퍼 (wrapper)와 코드에서의 호출은 동일한 모델을 다루지만, 서로 다른 규칙이 적용되는 서로 다른 접점 (surface)에 존재합니다.

검색창에 'meta ai api'를 입력하며 단일한 진입점을 찾으려 할 때, 실제 검색 결과는 '이것이 프로그래밍 방식으로 호출 가능한가'라는 질문에 대해 네 가지 서로 다른 답변을 가진 네 가지의 다른 제품을 뒤섞어 놓습니다. 기술 사양서 (technical specification)를 작성하기 전에 이들을 다시 분류하는 것이 통합 설계 (integration design) 작업의 절반입니다.

Матрица четырёх поверхностей Meta и их доступности из кода

무엇이 실제로 코드에서 호출되는가

출처가 없는 시나리오는 계획에 포함될 수 없으므로, 각 접점을 출처와 함께 하나씩 분석해 보겠습니다.

소비자용 어시스턴트인 Meta AI, 즉 meta.ai 및 Meta의 소셜 네트워크 내부의 채팅은 프로그래밍 방식의 API를 제공하지 않습니다 (ai.meta.com/meta-ai, 2026-07-18 접속). '우리의 서버가 Meta AI 어시스턴트를 백엔드 (backend)처럼 사용하게 하자'와 같은 모든 시나리오는 문서화된 계약 (contract)에 근거하지 않으며, 이를 아키텍처 (architecture)에 포함시켜서는 안 됩니다.

반면 Meta Model API는 진정한 소프트웨어 관문 (software door)입니다. Meta는 2026년 7월 9일에 이를 퍼블릭 프리뷰 (public preview)로 출시했습니다 (developer.meta.com/ai/products/meta-model-api). 이는 Muse Spark 1.1 모델에 대한 OpenAI SDK와 호환되는 셀프 서비스 (self-serve) 액세스이며, 시작 단계에서는 미국 개발자로 제한됩니다. 단, 주의 사항이 있습니다. 확인 시점에서 프리뷰는 출시된 지 단 9일밖에 되지 않았으며, 명백히 미국 전용 (US-only)입니다. 또한 조건, 가격 및 서비스 지역은 일반 공개 (general availability) 전까지 거의 확실하게 변경될 것입니다. 이는 프리뷰의 예상 경로에 대한 저의 추론일 뿐 Meta의 약속이 아니며, 이 인터페이스를 너무 이른 시점에 안정적인 장기적 지점으로 신뢰해서는 안 됩니다.

lama.developer.meta.com에서 Llama 모델의 인퍼런스 (inference)를 위한 Meta의 기존 주요 호스팅 제품이었던 Llama API는 종료됩니다. 퍼블릭 프리뷰는 2026년 7월 6일에 종료되었으며, 그 이후부터는 요청 시 모델 결과 대신 선셋 (sunset) 응답을 받게 됩니다 (Llama Developer docs, 2026-07-18 접속). 만약 코드에 여전히 이 경로가 하드코딩되어 있다면, 그것은 더 이상 모델의 소스가 아니라 리다이렉트 (redirect) 경로입니다. 여기서 소스에 대한 제한 사항을 솔직하게 밝히자면, 디프리케이션 (deprecation) 페이지는 현재 Meta 로그인이 필요하여 닫혀 있습니다. 해당 페이지의 문구는 독립적인 검색 스니펫 (search snippets)을 통해 확인되었으나 직접 캡처한 것은 아니므로, 인용된 내용은 스크린샷이 아닌 재구성된 확인 결과로 간주해야 합니다.

Llama의 오픈 웨이트 (open weights)는 별개의 이야기이며, 이는 API가 아닙니다. 웨이트 파일은 커스텀 커뮤니티 라이선스 (community license)를 수락한 후 Meta를 통한 직접 다운로드로만 사용할 수 있습니다 (llama.com/llama-downloads, 2026-07-18 접속). 이는 자체 배포 (self-deployment) 및 미세 조정 (fine-tuning)을 위한 경로로, 아키텍처 측면에서 Meta의 모든 호스팅 API와는 분리되어 있습니다. 즉, 자체 하드웨어, 자체 인퍼런스, 자체 운영이 필요합니다. 본 자료는 Llama의 로컬 배포를 위한 지침서가 아니며, 단지 그러한 경로가 존재한다는 점과 이것이 "Meta AI 호출"이 아니라는 점을 기록하는 것입니다.

브랜드 옆에 위치하지만 브랜드의 일부는 아닌 것으로, 메시징을 위한 플랫폼 API (Platform APIs)가 있습니다. WhatsApp Business Platform (Cloud API 및 Business Management API, developers.facebook.com/docs/whatsapp)은 어시스턴트 브랜드와 구조적 연결 없이 비즈니스 메시징을 위해 오래전부터 문서화되어 온 별도의 API 제품군입니다 (Meta for Developers, 2026-07-18 접속). 그리고 2026년 6월 3일, Meta는 WhatsApp, Messenger, Instagram의 비즈니스 대화 위에 AI 에이전트를 구축하기 위한 확장 기능인 Meta Business Agent 및 Meta Business Agent Platform을 발표했습니다 (Meta Newsroom, 2026-07-18 접속). 공식 문서에 따르면, 이 플랫폼은 자체 플랫폼 API와 웹후크 (Webhooks)를 통해 접근하며, 접근 권한은 Meta Model API와 같은 개방형 셀프 서비스 (Self-serve) 등록 방식이 아니라 WhatsApp Business Account, 적절한 국가, 적절한 비즈니스 버티컬 (Business Vertical)과 같은 요구 사항을 통해 게이트키핑(Gated)됩니다 (Meta for Developers, 2026-07-18 접속).

Диагностический маршрут от сценария к поверхности

허용 테이블: 시나리오와 접점(Surface)을 연결하는 방법

이 테이블의 의미는 제품을 나열하는 데 있는 것이 아니라 오른쪽 열에 있습니다. 문서화된 출처가 없고 시나리오가 접점과 일치하지 않으면 계획(Plan)을 통과할 수 없습니다.

이 테이블은 놓치기 쉬운 충돌을 가시화합니다. 동일한 Muse Spark 1.1 모델이 소비자용 애플리케이션과 프로그래밍 방식의 문 뒤에 모두 존재하지만, 그 문은 어시스턴트가 아니라 Meta Model API라고 불립니다. 사용자에게 보이는 기능과 코드에서 호출되는 모델은 모델 이름은 일치하지만 접근 접점(Surface)은 서로 다릅니다. 바로 이 접점에서 기대치가 어긋나게 됩니다.

개발자의 기대가 실제로 어긋나는 지점

가장 빈번한 오류는 브랜드에 기반하여 계획을 세우는 것입니다. 팀이 요구사항에 "Meta AI"라고 적을 때, 어떤 이는 채팅을, 어떤 이는 모델을, 또 어떤 이는 WhatsApp의 에이전트(Agent)를 의미하며 각 참여자는 자신만의 방식으로 해석합니다. 구체적인 소스(Source)가 있는 접점(Surface)이 명시되지 않는 한, 논쟁은 실체가 없는 상태로 계속됩니다.

두 번째 오류는 눈에 보이는 기능을 약속된 API로 오해하는 것입니다. 어시스턴트가 앱 내에서 이미지를 생성할 수 있다면, 개발자는 Meta AI를 대신하여 이미지를 생성하는 엔드포인트(Endpoint)가 존재할 것이라고 추론합니다. 하지만 문서(Documentation)를 통해 이를 확인할 수는 없습니다. 특정 소비자용 기능이 "결코" API가 되지 않을 것이라는 주장 또한 사실이 아닌 추측일 뿐입니다. 더 정직한 표현은 다음과 같습니다: 2026-07-18 기준으로 채팅 인터페이스를 위한 그러한 공개 접점(Public Surface)은 존재하지 않으며, 해당 기능이 문서에 나타나기 전까지는 이를 기반으로 구축해서는 안 됩니다.

세 번째 오류는 공식적인 경로가 없을 때 비공식적인 경로로 우회하는 것입니다. 쿠키 기반 인증(Cookie-based authorization)을 통해 Meta AI 소비자용 어시스턴트에 대한 API를 모방하는 리버스 엔지니어링(Reverse-engineering)된 클라이언트 라이브러리들이 존재합니다. 이들은 Meta의 승인을 받지 않았으며 본 자료에서는 소스로 간주하지 않습니다. 오히려 이는 본 분석에서 경고하는 '잘못된 의존성'의 전형적인 사례입니다: 제품이 내일 당장 쿠키를 변경하고 예고 없이 작동을 중단할 수 있는 채널 위에 구축되고 있기 때문입니다. 이 채널에는 SLA(Service Level Agreement)나 문서(Documentation)가 없습니다.

네 번째는 조용히 발생하는 오류로, 사라져가는 접점에 의존하는 것입니다. Llama API를 사용한 코드가 수년간 안정적으로 작동했을 수 있지만, 2026년 7월 6일 이후에는 선셋(Sunset) 응답을 반환할 수 있습니다. 기능 폐지(Deprecation)가 항상 요란한 뉴스로 다가오는 것은 아닙니다. 때로는 모델의 응답 대신 단순한 리다이렉트(Redirect)가 발생할 뿐이며, 이는 모니터링 상의 에러 수치 증가를 통해서만 발견되기도 합니다.

Таксономия режимов ложной зависимости от Meta AI

시나리오에 맞는 접점(Surface)을 선택하는 방법

규칙은 단 하나입니다: 오직 문서화된 특정 접점의 시나리오만을 계획하십시오. 이는 네 단계로 전개됩니다.

첫 번째 단계, 요구사항을 브랜드에서 접점(Surface)으로 재정의하십시오. "Meta AI와의 통합"이 아니라, "HTTP를 통한 모델 호출", "오픈 웨이트(Open Weights) 기반의 자체 추론(Inference)", 또는 "WhatsApp 내의 에이전트"와 같이 정의해야 합니다. 요구사항이 브랜드 수준에 머물러 있다면, 그것은 출처(Source)를 갖지 못합니다.

두 번째 단계, 접점의 일차적 출처와 날짜를 찾으십시오. Meta Model API의 경우 Meta for Developers의 제품 페이지와 Meta AI 블로그가 출처이며, 오픈 웨이트의 경우 llama.com/llama-downloads가, 에이전트의 경우 Meta Newsroom과 개발자 문서(Developer Documentation)가 출처입니다. 출처가 없다면 계획에 포함할 수 없습니다.

세 번째 단계, 아이디어를 구상하는 시점이 아니라 구축하는 시점의 접근 권한(Access)을 확인하십시오. Meta Model API는 현재 미국 전용(US-only) 프리뷰 상태이며, Business Agent Platform은 계정, 국가 및 적절한 버티컬(Vertical)을 요구합니다. 개발자가 자신의 계정에서 직접 자격 요건(Eligibility)을 확인하기 전까지는, 특정 시나리오가 이러한 게이트(Gate)와 일치할지 여부는 가설에 불과합니다.

네 번째 단계, 프리뷰의 불안정성과 경로 변경에 대비한 여유분을 확보하십시오. 확인 시점을 기준으로 단 9일간 진행된, 조건 변경이 명시된 퍼블릭 프리뷰(Public Preview)는 강력한 의존성을 구축하기 위한 토대로 적합하지 않습니다. 또한 Llama API의 사례는 성숙한 접점조차 사라질 수 있음을 보여줍니다. 이러한 제약을 완화하는 방법 중 하나는 통합을 단일 제공업체에 종속시키지 않는 것입니다. 별도의 출처와 진입 조건을 가진 독립적인 카탈로그 접점으로서 provod.ai를 언급할 수 있습니다. 이는 Meta AI의 인터페이스도, Llama 셀프 호스팅(Self-host)의 대체재도 아니며, 자체 모델 카탈로그를 보유한 러시아의 애그리게이터(Aggregator)입니다.

이러한 백업 경로를 곁에 두어야 하는 실질적인 이유는 Meta Model API가 OpenAI SDK와 호환되기 때문입니다. 이는 provod.ai가 Claude, GPT, Gemini, DeepSeek, Qwen과 같은 자체 모델 카탈로그를 제공하는 바로 그 규약(Contract)입니다. 러시아 팀에게 이는 미국 전용(US-only) 프리뷰가 가진 두 가지 구체적인 제약을 제거해 줍니다. 즉, VPN이나 해외 카드 없이도 루블화 잔액, 러시아 카드, SBP(Faster Payments System) 또는 계좌 이체를 통해 결제가 가능하며, 안정적인 멀티채널 라우팅(Multichannel routing)을 통해 상위 채널 중 하나가 일시적으로 사용할 수 없을 때도 요청을 계속해서 전달할 수 있습니다.