Prism을 호출하는 세 가지 새로운 방법 — CLI, MCP, 그리고 SDKs

v1.x 버전의 대부분 기간 동안 Prism을 _운영(operate)_하는 유일한 방법 — 캐시 설정 변경, 라우팅 정책 설정, 예산 제한, 누가 무엇을 했는지에 대한 감사(audit) — 은 웹 대시보드(web dashboard)를 통해서뿐이었습니다. 제품이 OpenAI 호환 채팅 엔드포인트(chat endpoint)와 작은 마케팅 사이트에 불과했을 때는 괜찮았습니다. 하지만 고객들에게 운영 환경(production)에서 Prism을 사용해 달라고 요청하는 순간, 그 방식은 더 이상 적절하지 않게 되었습니다.

v1.8은 그 격차를 해소합니다. 동일한 기반 API를 지원하는 세 가지 새로운 인터페이스(surfaces)가 추가되었습니다:

• prism CLI — pip install ssimplifi-cli를 통해 설치하며, 19개의 명령어를 제공합니다. 대시보드에서 수행하던 모든 운영 작업을 스크립트로 작성할 수 있습니다.
• prism-mcp 서버 — npm install -g ssimplifi-prism-mcp를 통해 설치하며, Claude Desktop / Cursor / Zed / Continue / Cline에서 실행됩니다. Prism의 도구(tools)를 그곳에서 실행 중인 어떤 AI에게도 노출합니다.
• Python + Node SDKs — pip install ssimplifi / npm install ssimplifi-prism를 통해 설치하며, 각 언어에서 OpenAI SDK를 즉시 대체할 수 있으며 Prism용 키워드 인자(kwargs)가 추가되어 있습니다.

또한 API 자체도 개선되었습니다. 이제 모든 대시보드 경로(route)에서 일반 API 키를 수락하며, OpenAPI 명세(spec)는 https://api.ssimplifi.com/v1/openapi.json에서 확인할 수 있고, Swagger UI는 /v1/docs에 마운트되어 있습니다. 대시보드는 여전히 가장 친숙한 인터페이스로 남겠지만, 이제 더 이상 유일한 인터페이스는 아닙니다.

왜 세 가지이며, 왜 지금인가

솔직한 이유는 마찰(friction) 때문입니다. 저 스스로도 개발 작업의 절반 정도를 CLI를 통해 수행하고 있음을 발견했습니다. 제가 Prism을 보여준 엔지니어들도 마찬가지입니다. 개발자가 배포 작업에 몰두하고 있을 때 "캐시 TTL을 업데이트하려면 웹 대시보드에 로그인하세요"라고 말하는 것은 잘못된 UX(사용자 경험)입니다. 제품이 개발자를 위해 만들어졌다면, 모든 운영 인터페이스는 프로그래밍 가능해야 합니다.

MCP는 더 어려운 결정이었습니다. Anthropic이 2024년 10월에 이 프로토콜을 출시했으며, 2026년 중반이면 모든 진지한 AI 코딩 클라이언트가 이를 지원하게 될 것입니다. 이것은 하나의 배포 채널(distribution channel)입니다. AI 어시스턴트가 당신의 게이트웨이(gateway)를 도구로서 직접 호출할 수 있게 되면, 질문은 "Prism을 통합해야 할까"에서 "Prism이 이미 거기 있네"로 바뀝니다. 3개월 전만 해도 이는 추측에 불과했겠지만, 이제는 개발자 대상 AI 인프라 제품이라면 반드시 갖춰야 할 기본 요건(table-stakes)입니다.

SDKs는 가장 적은 비용으로 얻을 수 있는 승리였습니다. 우리는 고객들에게 "우리는 OpenAI와 호환됩니다 — 기본 URL(base URL)만 변경하세요"라고 말해왔습니다. 기술적으로는 맞는 말이지만, 실제로 X-Prism-* 헤더(mode, session_id, cache)를 사용하려면 매 호출마다 extra_headers={"X-Prism-Mode": "..."}와 같은 번거로운 절차(ceremony)가 필요합니다. 이를 Python의 kwargs나 TypeScript 필드로 노출하는 퍼스트 파티 SDK(first-party SDK)를 제공하면, API가 "OpenAI에 이상한 헤더가 붙은 것"이 아니라 진정한 제품처럼 느껴지게 됩니다.

API의 새로운 기능

v1.8 P1(API 완성도 개선 단계)은 다른 모든 것의 전제 조건입니다. 두 가지 실질적인 변화가 있습니다:

모든 대시보드 경로에 대한 이중 인증(Dual auth). P1a 이전에는 캐시(cache), 정책(policy), 예산(budget), 감사(audit), 워크스페이스(workspaces)와 같은 계정 관리 엔드포인트(endpoints)에 Supabase JWT(즉, 웹 로그인)가 필요했습니다. P1a 이후에는 JWT 또는 일반 prism_sk_* API 키 중 하나를 모두 수용합니다. 키 경로는 티어(tier)에 따라 제한됩니다. Pro/Team 플랜은 프로그래밍 방식의 접근 권한을 얻으며, Free/PAYG 플랜은 업그레이드 URL이 포함된 깔끔한 402 tier_upgrade_required 에러를 받게 됩니다. 이것이 우리가 설정한 구분선입니다: 소비(consumption) + 사용자의 자체 사용 데이터는 보편적으로 제공되지만, 운영 오케스트레이션(operational orchestration)은 Pro+ 이상에서 제공됩니다.

OpenAPI 스펙 + Swagger UI. 모든 경로에는 태그, 설명, 응답 모델이 포함되어 있습니다. 웹훅(Webhooks)은 공개 스펙에 유출되지 않도록 명시적으로 숨겨져 있습니다. 그 결과 https://api.ssimplifi.com/v1/openapi.json에서 발행 가능한 문서를 얻을 수 있으며, 자동 생성된 SDK 클라이언트가 이를 직접 사용할 수 있습니다. /v1/docs의 Swagger UI는 잠재 고객이 가입하기 전에 상호작용할 수 있는 인터페이스를 제공합니다.

이것이 v1.8의 지루한 절반입니다. 하지만 동시에 다른 모든 것을 가능하게 한 절반이기도 합니다. 아래의 다른 모든 요소들은 P1이 깔끔하게 프로그래밍 가능하도록 만든 API 표면(API surface) 위의 얇은 계층일 뿐입니다.

CLI

pip install ssimplifi-cli
prism configure              # prism_sk_... 키를 붙여넣으세요
prism chat "What is..."      # 원샷 컴플리션(one-shot completion), 모든 티어 가능
...

19개의 명령어와 약 40개의 서브 명령어(sub-commands)가 있습니다. 일부는 공통 명령어(chat, models, whoami, balance, usage, keys list)입니다. 대부분은 Pro+ 전용(cache, policy, budget, audit, orgs, projects, members, invites, subscription, provider-health)입니다.

티어(tier) 확인은 깔끔하게 이루어집니다. 만약 Free 계정에서 prism cache stats를 시도하면, CLI는 다음과 같이 출력합니다:

Tier upgrade required.
  Current tier: free
  Programmatic access to this endpoint requires Pro ($19/mo) or Team ($49/mo).
...

JSON 덤프가 포함된 401 에러가 아닙니다. 반쯤 망가진 상태도 아닙니다. 정확히 무엇을 해야 하는지 알려주는 깔끔하고 실행 가능한 메시지입니다.

CLI는 또한 소프트 게이트(soft-gate) 태세를 취하고 있습니다: prism chat과 prism models는 모든 티어에서 작동합니다. Free 티어에서도 CLI를 설치하여 터미널에서 채팅을 사용하고, 관리자 명령어가 존재함을 발견한 뒤, 실제로 필요할 때 업그레이드할 수 있습니다. 이는 올바른 방향이라고 느껴집니다. 도구의 진입점 자체를 차단하는 것은 호기심 많은 개발자들이 제품을 시도해보기도 전에 멀어지게 만들 것입니다.

MCP 서버

이것이 제가 가장 기대하고 있는 부분입니다. Claude Desktop(또는 Cursor, Zed, Continue, Cline)을 Prism의 MCP 서버로 설정하고 나면, AI가 Prism의 카탈로그를 호출하고, 비용을 추정하며, 사용량을 확인하고, 피드백을 제출할 수 있습니다. 또한 선택적인 쓰기 권한 키(write-scope key)가 있다면 캐시 설정을 변경하고, API 키를 취소하며, 라우팅 정책(routing policy)을 설정할 수도 있습니다. 이 모든 것이 대화 도중에 이루어집니다.

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
...

총 22개의 도구(tools)가 있으며, 12개는 읽기 전용(read-only), 10개는 쓰기(write) 전용입니다. 쓰기 도구는 두 개의 조정된 레이어에 의해 제한됩니다:

Layer 1 — 도구별 확인 (Per-tool confirmation). 모든 쓰기 도구는 기본값이 false인 confirmed: boolean 인자를 받습니다. 이 인자가 없으면, 도구는 수행할 작업과 그에 따른 구체적인 결과를 설명하는 구조화된 confirmation_required 응답을 반환합니다. AI 클라이언트는 그 결과를 자연어로 사용자에게 보여줍니다 ("이 작업은 현재 운영 환경에서 사용 중인 3월 14일 생성된 API 키를 취소합니다. 정말 진행하시겠습니까?"). 사용자가 동의하면, AI는 confirmed: true와 함께 다시 호출하며, 작업이 실행됩니다. 이는 표준 MCP 파괴적 도구(destructive-tool) 형태입니다. Anthropic의 레퍼런스 서버들도 파일 삭제 및 git 작업에 동일한 패턴을 사용합니다.

Layer 2 — 별도의 쓰기 범위 키 (Separate write-scope key). 일반적인 prism_sk_* API 키로는 MCP를 통해 상태를 변경(mutate)할 수 없습니다. 끝입니다. 쓰기를 활성화하려면 CLI에서 prism mcp enable-writes를 실행하고, 확인 이메일을 받아 링크를 클릭한 뒤, 별도의 prism_msk_* 키를 발급받아 MCP 설정에 PRISM_MCP_WRITE_KEY로 추가해야 합니다. 2단계 옵트인(opt-in) 방식입니다. 이 설정이 없으면 쓰기 도구는 활성화를 위한 링크가 포함된 깔끔한 write_disabled 응답을 반환합니다.

위협 모델(Threat-model) 관점에서 보면: AI가 사용자의 키를 취소하도록 유도하는 프롬프트 인젝션(prompt injection)은 Layer 2에서 차단됩니다 (범위 내에 쓰기 키가 없음). 악의적인 공격자가 MCP 설정 파일을 훔치더라도 읽기 권한만 유출될 뿐입니다. 대화 도중 AI가 실수로 쓰기 도구를 호출하는 경우 Layer 1에서 포착됩니다 (결과 텍스트가 표시되므로 사용자가 맹목적으로 동의하지 않게 됩니다). 이 두 층은 벨트와 멜빵(belt + suspenders, 이중 안전장치)처럼 함께 작동합니다.

저는 MCP를 읽기 전용으로만 제한해야 하는지에 대해 고민을 거듭했습니다. 제한해야 한다는 논거는 다음과 같습니다: AI 클라이언트는 본질적으로 노이즈가 많은 환경이므로, 잘못된 프롬프트 인젝션이나 잘못 읽힌 지시가 운영 상태를 변경해서는 안 된다는 것입니다. 반대 논거는 다음과 같습니다: MCP를 읽기 도구로만 제한하면 AI가 "내 캐시 히트율(cache hit rate)이 얼마인가요?"에는 답할 수 있지만, "TTL을 50%로 낮춰줘"에는 답할 수 없게 되어 제품의 절반만 제공하는 셈이 된다는 것입니다. 이 2계층 설계는 그 사이의 절충안을 찾았습니다: 기능은 존재하되 명시적으로 옵트인(opt-in)해야 하며, 옵트인한 후에도 모든 파괴적인 호출은 먼저 물어봅니다.

읽기(read) 측면의 경우, PRISM_API_KEY 외에 별도의 옵트인(opt-in)은 필요하지 않습니다. MCP 서버는 시작 시 /v1/whoami를 확인하며, 계정이 Pro+가 아닐 경우 어떤 도구(tool)의 등록도 거부합니다 (Free/PAYG 사용자는 "0 tools available" 메시지와 함께 명시적인 업그레이드 메시지를 보게 됩니다). 그 외의 경우에는 즉시 12개의 읽기 도구(read tools)를 활성화합니다.

SDKs

ssimplifi (PyPI) 및 ssimplifi-prism (npm)이 있습니다. 두 가지 모두 각 언어의 공식 openai SDK에 대한 얇은 래퍼(thin wrapper)입니다. 여기서 openai SDK는 OpenAI 호환 API를 위한 표준 클라이언트(canonical client)입니다. 저희는 재구현하기보다 확장하는 방식을 택했으므로, OpenAI SDK의 스트리밍(streaming), 재시도(retries), 타입 안정성(type safety) 및 응답 형태(response shape)를 그대로 무료로 사용할 수 있습니다.

from ssimplifi import Prism

client = Prism(api_key="prism_sk_...")
...

이것이 일반적인 openai.OpenAI와 비교했을 때의 전체 차이점(diff)입니다. 임포트(import) 라인 두 줄만 바꾸면 자동 라우팅(auto-routing) + 멀티 턴 메모리(multi-turn memory) + 캐싱(caching) + 멀티 프로바이더 페일오버(multi-provider failover)를 얻을 수 있습니다. mode, session_id, model_prefer, cache, request_tags 키워드 인자(kwargs)는 X-Prism-* 헤더로 변환되므로, 헤더 이름을 일일이 기억할 필요가 없습니다.

또한 관리자 인터페이스(admin surface)도 제공합니다: client.models.list(), client.usage.summary(days=7), client.cache.stats(days=7), client.keys.create(name="staging"), client.whoami(). 이 기능들은 httpx 사이드 채널(side-channel)을 통해 CLI가 통신하는 것과 동일한 대시보드 엔드포인트(dashboard endpoints)에 직접 접근합니다.

Node SDK도 구조적으로 동일합니다. import { Prism } from "ssimplifi-prism", new Prism({ apiKey }), 그리고 동일한 키워드 인자(kwargs)를 사용합니다.

이로써 저희의 competitive-gaps 문서에 명시된 세 번째 항목이 해결되었습니다. 모든 개발 도구 비교(dev-tool comparison)에서는 퍼스트 파티 SDK(first-party SDKs)의 존재 여부를 확인합니다. "OpenAI SDK와 호환됨"은 기술적으로는 맞지만 비교 매트릭스(matrix) 상에서는 격차(gap)로 읽히지만, "prism-python 및 prism-node를 보유함"은 그렇지 않습니다.

다시 한번 강조하는 티어(Tier) 전략

CLI를 Pro 플랜 뒤에 가두고 싶은 유혹이 생길 수도 있습니다. Stripe 방식처럼, 월 19달러를 지불하면 개발자 경험(Developer Experience)을 잠금 해제하는 방식 말이죠. 하지만 우리는 의도적으로 그렇게 하지 않습니다. Free 및 PAYG (Pay-As-You-Go) 티어 계정도 CLI를 설치하고 채팅 용도로 사용할 수 있습니다. 다만 관리자 명령(Admin commands)을 프로그래밍 방식으로 실행할 수 없을 뿐입니다. 이것이 옳다고 생각합니다. 도구 사용을 제한하는 것은 호기심 많은 개발자들이 제품을 실제로 사용해 보기도 전에 멀어지게 만드는 방법입니다. 우리는 고객을 설치 단계에서 차단하기보다, Free 고객들이 터미널에서 prism chat "..."를 입력하며 Prism을 발견하게 하는 쪽을 택하겠습니다.

MCP는 더 제한적입니다. Pro가 아닌 계정에서는 서버가 어떠한 도구(Tools)도 등록하지 않습니다. 이유는 다릅니다. MCP는 본질적으로 운영(Operational)을 위한 것이지, 가볍게 체험해 보는 용도가 아니기 때문입니다. MCP를 가지고 노는 Free 고객들은 대부분 막다른 길에 부딪힐 것입니다. 가치가 실현되는 곳은 Pro/Team 플랜입니다.

SDK는 보편적입니다. SDK는 제품이 아니라 라이브러리(Libraries)이기 때문입니다. SDK가 감싸고 있는 채팅 엔드포인트(Chat endpoint)는 보편적이며, SDK가 노출하는 관리자 엔드포인트(Admin endpoints)는 Pro가 아닌 호출자에게 깔끔한 에러를 반환합니다. 라이브러리 설치를 제한하는 것은 의미가 없습니다.

출시된 것과 출시되지 않은 것

현재 프로덕션(Production)에 출시된 항목: P1 API 완성, P2 CLI (로컬 준비 완료, 게시 대기 중), P3 쓰기 방지 기능이 포함된 MCP 서버 (로컬 준비 완료), P4 Python + Node SDKs (로컬 준비 완료).

남은 작업: 실제 pip / npm 게시 작업입니다. 각 작업에는 게시용 머신에 제 자격 증명(Credentials)이 있어야 합니다. PyPI를 위한 ~/.pypirc, npm의 @ssimplifi 스코프를 위한 npm login이 필요합니다. 저는 의도적으로 이러한 토큰들을 CI(지속적 통합) 환경에 두지 않으며, 이 프로젝트의 배포는 수동으로 유지됩니다. 제가 네 개의 게시 명령과 여덟 개의 방어적인 이름 점유(Name claims) 작업을 위해 30분 정도 시간을 내고 나면, 위의 설치 스니펫(Snippets)들이 로컬 체크아웃(Local checkout) 방식이 아닌 pip install / npm install을 통해 작동하기 시작할 것입니다.

우리가 의도적으로 연기한 것: 기존 v1.8 계획에는 두 가지 하위 단계가 더 있었습니다 — P1d (/v1/dashboard/*를 표준 경로인 /v1/account/*로 변경)와 P2d (CLI를 위한 브라우저 OAuth 흐름). P1d는 외관상의 문제로 밝혀졌습니다 — Swagger UI는 URL 접두사가 아닌 태그별로 그룹화되므로, 이름 변경은 고객에게 눈에 띄는 개선 없이 혼란만 가중시킵니다. 따라서 /dashboard/*를 유지하기로 했으며, v2.0에서 적절한 폐기(deprecation) 기간과 함께 다시 검토할 예정입니다. P2d는 JWT 전용 라우트에 맞춰 설계되었습니다; P1a의 이중 인증(dual-auth)으로 인해 해당 카테고리가 사라졌으므로, CLI를 통한 OAuth는 더 이상 사용 사례가 없습니다. 두 개의 하위 단계가 사라졌지만, 기능적 손실은 없습니다.

더 큰 패턴

v1.7이 제공자(providers)를 추가하는 것에 관한 것이었다면, v1.8은 제공자에 접근하는 방법을 추가하는 것에 관한 것이었습니다 — 동일한 접점(surface)에 더 많은 진입로를 만든 것입니다. 중요한 패턴은 다음과 같습니다: Prism의 모든 운영 작업은 이제 최소 세 가지의 독립적인 접점(웹, API, CLI)을 통해 도달할 수 있으며, MCP와 SDK는 그 위에 계층화된 접근 패턴으로 존재합니다. 이 중 어느 것도 이등급이 아닙니다. 어느 것도 다른 접점이 가진 기능을 누락하고 있지 않습니다. 대시보드는 더 이상 표준 접점이 아닙니다 — API가 표준이며, 대시보드는 단지 네 가지 클라이언트 중 하나일 뿐입니다.

이러한 변화가 중요한 이유는 이것이 진지한 인프라 제품이 성장하는 방식이기 때문입니다. Cloudflare의 대시보드는 훌륭하지만, 대부분의 개발자가 실제로 사용하는 것은 그들의 CLI (wrangler)입니다. Stripe의 대시보드는 훌륭하지만, 실제 프로덕션이 실행되는 것은 그들의 SDK입니다. Prism은 이제 그러한 형태를 갖추었습니다. 대시보드에 기능이 먼저 출시되지만, 대시보드가 기능을 제한하지는 않습니다 — 클릭할 수 있는 모든 것은 스크립트로도 구현할 수 있습니다.

직접 시도해 보세요:

pip install ssimplifi-cli
prism configure
prism chat "what just shipped in v1.8?"