MCP로 AI 어시스턴트를 SMM 패널 계정에 연결하는 방법
MCP란 무엇인지부터 OAuth 2.1 승인, 18개 도구, 조회 전용 권한, AI로 주문하기까지 Panel Follows 계정에 AI 어시스턴트를 연결하는 방법을 정리했습니다.
MCP(Model Context Protocol)는 AI 어시스턴트가 바깥의 시스템에 직접 연결되어 그 시스템의 기능을 도구처럼 쓰게 해 주는 개방형 프로토콜이며, 이 패널에서는 여러분의 계정 하나를 어시스턴트에게 열어 주는 통로를 뜻합니다. 연결이 끝나면 Claude나 ChatGPT 같은 어시스턴트에게 "인스타그램 팔로워 서비스 중에 리필 보장 있는 것만 가격순으로 보여 줘"라고 말할 수 있고, 어시스턴트는 패널 카탈로그를 직접 조회해서 대답합니다.
이 글은 그 연결이 실제로 어떻게 이루어지는지를 화면 순서와 프로토콜 동작 양쪽에서 정리한 문서입니다. 어떤 도구가 열리는지, 어시스턴트가 무엇을 할 수 있고 무엇을 할 수 없는지, 토큰은 얼마나 살아 있는지, 잘못되면 어떤 오류가 어디서 뜨는지를 코드에 실제로 들어 있는 값 그대로 적었습니다. 홍보 문구는 넣지 않았습니다.
먼저 한 가지를 분명히 해 두겠습니다. AI 어시스턴트를 연결한다는 것은 그 어시스턴트에게 여러분의 돈을 쓸 수 있는 창구를 하나 더 만들어 주는 일입니다. 주문 도구는 실제 잔액을 차감하고 되돌릴 수 없습니다. 그래서 패널 쪽 설계는 "모델이 알아서 잘하겠지"에 기대지 않는 방향으로 되어 있습니다. 승인은 패널 화면에서 받고, 조회 전용 연결에서는 주문 도구를 아예 목록에서 지우고, 모든 호출은 기록에 남깁니다. 이 글에서 그 장치들을 하나씩 확인하실 수 있습니다.
읽는 순서도 미리 안내해 두겠습니다. 앞부분은 개념과 연결 절차라서 어떤 클라이언트를 쓰든 필요한 내용이고, 중간부터는 실제로 주문을 맡길 때 알아야 할 규칙입니다. 뒷부분은 전송 방식이나 요청 한도처럼 직접 클라이언트를 만들거나 문제를 파고들 때 필요한 내용이므로, 그냥 연결해서 쓰실 분은 건너뛰셔도 됩니다.
패널 자체를 처음 쓰신다면 Panel Follows 사용 가이드를 먼저 읽고 오시는 편이 좋습니다. 주문 화면과 잔액 개념을 알고 있어야 어시스턴트가 무엇을 대신해 주는지 감이 잡힙니다.
MCP란 무엇이고 SMM 패널에서는 무슨 일을 합니까?
MCP란 AI 모델과 외부 도구 사이를 잇는 표준 규약입니다. 예전에는 어시스턴트마다 플러그인 형식이 달라서 서비스 제공자가 클라이언트 수만큼 연동을 따로 만들어야 했습니다. MCP는 그 지점을 표준화했습니다. 서버 쪽이 "내가 가진 도구는 이것들이고 각 도구는 이런 입력을 받는다"를 한 번 선언해 두면, 그 규약을 이해하는 모든 클라이언트가 같은 방식으로 그 도구를 씁니다.
이 규약에서 서버는 도구를 가진 쪽이고, 클라이언트는 어시스턴트가 들어 있는 앱입니다. 즉 MCP 서버는 여기 패널 쪽에 있고, 여러분이 쓰는 어시스턴트 앱이 클라이언트가 됩니다. 여러분이 직접 코드를 짤 필요는 없습니다. 클라이언트에 주소 하나를 등록하고 패널에서 승인만 누르면 됩니다.
패널에서 MCP가 실제로 하는 일은 세 가지입니다. 첫째, 카탈로그를 읽게 해 줍니다. 플랫폼과 카테고리 목록, 서비스 검색, 개별 서비스의 최소와 최대 수량, 리필과 취소 지원 여부까지 어시스턴트가 직접 조회합니다. 둘째, 금액을 계산하게 해 줍니다. 주문을 실제로 열지 않고 먼저 요금만 뽑아 보는 도구가 따로 있습니다. 셋째, 주문과 사후 처리를 맡깁니다. 주문 생성, 상태 조회, 취소, 리필 요청까지 대화 안에서 처리할 수 있습니다.
반대로 MCP가 하지 않는 일도 분명합니다. 이것은 새로운 결제 수단이 아니고, 자동 마케팅 도구도 아니며, 여러분 대신 무엇을 살지 결정해 주는 장치도 아닙니다. 패널이 원래 가지고 있던 기능을 대화라는 다른 입구로 여는 것뿐입니다. 그래서 패널에서 불가능한 일은 어시스턴트에서도 불가능합니다.
여기서 자주 나오는 질문 하나를 미리 정리하겠습니다. MCP 서버를 붙인다고 해서 어시스턴트가 여러분의 인스타그램 계정이나 틱톡 계정에 접근하는 것이 아닙니다. 어시스턴트가 보는 것은 이 패널의 계정 하나뿐입니다. 잔액, 주문 목록, 카탈로그가 전부입니다. 소셜 계정의 비밀번호는 애초에 패널이 가지고 있지 않으므로 어시스턴트도 볼 수 없습니다.
패널에 있는 두 개의 MCP 서버: 사용자용과 관리용
패널에는 성격이 완전히 다른 MCP 서버가 두 개 올라가 있습니다. 하나는 패널의 고객, 즉 여러분을 위한 서버이고, 다른 하나는 패널 소유자가 패널 전체를 운영하기 위한 서버입니다. 이 글의 대부분은 앞의 것을 다룹니다.
| 구분 | 사용자 서버 | 관리 서버 |
|---|---|---|
| 엔드포인트 | POST /api/mcp/user |
POST /api/mcp |
| 연결하는 사람 | 패널의 고객 | 패널 소유자 |
| 인증 방식 | OAuth 2.1 토큰 또는 계정의 API 키 | 단일 비밀 키(MCP_SECRET) |
| 권한 범위 | 자기 계정만, 도구 18개 | 패널 전체, 도구 57개 |
| 기록 방식 | aiAuditLog(사용자 식별자 있음) |
aiAuditLog(사용자 식별자 없음) |
두 서버는 같은 전송 계층 코드를 공유합니다. 즉 프로토콜 동작, 오류 처리 방식, 기록 방식이 동일하고 차이는 인증과 도구 목록에만 있습니다. 이 구조 덕분에 사용자 서버에서 확인한 동작은 관리 서버에서도 그대로 성립합니다.
여러분이 신경 쓸 주소는 하나입니다. 계정에 연결할 주소는 패널 주소 뒤에 /api/mcp/user를 붙인 것이고, 로그인 후 왼쪽 메뉴의 "AI 어시스턴트" 항목, 즉 AI 어시스턴트 페이지에서 "연결 주소" 상자에 그대로 표시됩니다. 복사 버튼도 붙어 있으니 직접 타이핑할 필요는 없습니다.
하위 패널(화이트라벨) 고객이라면 주소가 다릅니다. 여러분이 쓰는 패널의 도메인이 그대로 연결 주소가 되고, 메인 패널 주소는 화면 어디에도 나타나지 않습니다. 이 부분은 뒤에서 따로 설명하겠습니다.
어시스턴트가 쓸 수 있는 18개 도구는 무엇입니까?
사용자 서버가 공개하는 도구는 정확히 18개입니다. 이름은 영문 그대로이며, 어시스턴트가 호출할 때 쓰는 식별자이기도 합니다. 대화에서 여러분이 이 이름을 외울 필요는 없지만, 어떤 도구가 있는지 알면 무엇을 부탁할 수 있는지 판단이 빨라집니다.
| 영역 | 도구 |
|---|---|
| 계정 | get_account |
| 카탈로그 | list_platforms, list_categories, search_services, get_service |
| 주문 | preview_order, create_order, create_orders_bulk, list_orders, get_order, cancel_order, refill_order |
| 리필 | list_refills, get_refill |
| 자동화 | list_events, list_webhooks, create_webhook, delete_webhook |
이 중 12개는 조회만 하는 도구입니다. get_account, list_platforms, list_categories, search_services, get_service, preview_order, list_orders, get_order, list_refills, get_refill, list_events, list_webhooks가 여기 속합니다. 나머지 6개가 쓰기 도구입니다. create_order, create_orders_bulk, cancel_order, refill_order, create_webhook, delete_webhook입니다.
쓰기 도구 안에서도 등급이 나뉩니다. create_order, create_orders_bulk, cancel_order, delete_webhook은 되돌리기 어려운 작업으로 표시되어 있고, refill_order와 create_webhook은 쓰기이긴 하지만 그 표시가 붙지 않습니다. 리필 요청은 돈을 쓰지 않고 웹훅 추가는 지우면 되기 때문입니다. 이 표시는 도구 목록을 받아 갈 때 함께 전달되므로, 클라이언트가 "이 도구는 확인을 한 번 더 받자"는 식으로 쓸 수 있습니다.
도구 몇 개는 동작을 조금 더 알아 두면 유용합니다.
get_account는 계정 식별자, 이메일, 사용 가능한 잔액(USD), 요청 한도를 돌려줍니다. 주문 전에 잔액이 충분한지 확인하는 용도입니다.
search_services는 카탈로그 검색입니다. 걸 수 있는 조건은 search(이름에 들어가는 글자), platform, category, type, refill, cancel, dripfeed, min_rate, max_rate입니다. 한 번에 돌려주는 개수는 기본 20개이고 최대 50개입니다. 결과가 길면 커서로 다음 장을 요청합니다.
get_service는 서비스 하나의 전체 정보입니다. 가격, 최소와 최대 수량, 리필과 취소와 드립피드 지원 여부, 평균 소요 시간, 그리고 그 서비스가 요구하는 주문 입력란 목록(fields)이 들어 있습니다. 이 마지막 항목이 중요합니다. 어시스턴트가 어떤 칸을 채워야 하는지 추측하지 않고 여기서 읽습니다.
preview_order는 주문을 열지 않고 검증만 합니다. 응답에는 charge(청구될 금액), balance_after(주문 후 잔액), sufficient_balance(잔액이 충분한지)가 들어 있습니다.
create_order는 실제로 돈을 씁니다. 되돌릴 수 없습니다. create_orders_bulk는 한 번에 최대 50건까지 처리하며, 항목을 순서대로 처리하기 때문에 하나가 실패해도 나머지는 계속 열립니다. 각 항목이 자기 결과를 따로 돌려줍니다.
list_orders는 상태로 걸러 볼 수 있습니다. 쓸 수 있는 값은 pending, in_progress, completed, partial, canceled, refunded, failed입니다. 기본 20건, 최대 100건입니다.
cancel_order는 그 서비스가 취소를 지원하고 주문이 아직 완료되지 않았을 때만 동작합니다. 지원하지 않으면 cancel_not_supported가 돌아옵니다. refill_order는 완료된 주문이면서 리필이 보장된 서비스에서만 동작하고, 요금이 붙지 않으므로 잔액에 영향이 없습니다.
create_webhook은 응답에 서명용 비밀 키를 한 번만 보여 줍니다. 그 화면을 지나가면 다시 볼 수 없습니다. delete_webhook은 대기 중이던 전송 건까지 함께 버립니다.
목록을 돌려주는 도구들은 커서 방식으로 넘어갑니다. 요청에 starting_after를 넣고, 응답의 next_cursor 값을 다음 요청에 그대로 넘기면 됩니다. 페이지 크기를 일부러 작게 잡아 둔 이유가 있습니다. 도구가 돌려준 결과는 모델의 문맥에 글자 그대로 들어가기 때문에, 한 번에 수백 건을 내려보내면 비용이 커지고 모델의 주의도 흩어집니다. 그래서 기본값을 낮게 두고 필요할 때만 다음 장을 요청하는 방식을 씁니다.
여러분이 "서비스 전부 보여 줘"라고 요청하면 어시스턴트가 한 번에 다 받아 오지 못하는 이유가 여기 있습니다. 이럴 때는 조건을 좁혀서 묻는 편이 결과도 좋고 빠릅니다.
AI 어시스턴트를 패널에 연결하는 방법은 무엇입니까?
연결 자체는 세 단계입니다. 패널의 "AI 어시스턴트 연결" 화면에도 같은 순서가 그대로 적혀 있습니다.
- "연결 주소"를 복사해 AI 클라이언트에 MCP 서버로 추가합니다.
- 클라이언트가 브라우저로 승인 화면을 띄웁니다. 연결을 승인합니다. 원하면 조회 전용으로 승인할 수 있습니다.
- 이제 "인스타그램 팔로워 가격 보여 줘" 또는 "최근 주문 상태 알려 줘"라고 말하면 됩니다.
화면 안내 문구도 같은 이야기를 합니다. "이 주소를 AI 클라이언트에 추가하세요. 승인은 이 패널에서 이루어지며, 비밀번호는 클라이언트에 전달되지 않습니다."라고 적혀 있습니다. 이 문장이 핵심입니다. 클라이언트는 여러분의 로그인 정보를 절대 보지 못합니다.
클라이언트별 설정 예시는 패널 화면에 그대로 실려 있습니다. 명령줄 도구를 쓴다면 이렇게 등록합니다.
claude mcp add --transport http panel https://panelfollows.com/api/mcp/user
설정 파일에 직접 적는 편집기라면 아래 형태입니다.
{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }
헤더를 보낼 수 있는 클라이언트라면 API 키를 그대로 실어 보낼 수도 있습니다.
claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
--header "Authorization: Bearer pf_live_..."
연결이 되었는지 눈으로 확인만 하고 싶다면 명령 한 줄로 도구 목록을 받아 보면 됩니다.
curl -s https://panelfollows.com/api/mcp/user \
-H "Authorization: Bearer pf_live_..." \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
화면의 안내는 "OAuth 2.1을 지원하는 모든 MCP 클라이언트에서 작동합니다. 헤더를 보낼 수 있는 클라이언트는 API 키도 사용할 수 있습니다."입니다. 즉 특정 브랜드 전용 통합이 아닙니다. 규약을 지키는 클라이언트라면 종류를 가리지 않습니다.
주소 부분만 조심하시면 됩니다. 위 예시는 메인 패널 주소를 기준으로 적혀 있습니다. 하위 패널 고객이라면 그 패널의 도메인으로 바꿔서 등록해야 하고, 정확한 값은 언제나 여러분이 로그인한 패널의 "연결 주소" 상자에 적힌 것입니다.
OAuth 2.1 흐름은 뒤에서 정확히 무엇을 합니까?
주소만 등록했는데 어떻게 승인 화면이 뜨는지 궁금하실 수 있습니다. 클라이언트와 서버가 표준 절차를 따라 자동으로 협상하기 때문입니다. 순서는 이렇습니다.
- 클라이언트가 아무 인증 없이 서버에 요청을 보냅니다. 서버는
401을 돌려주면서 응답 헤더에WWW-Authenticate: Bearer error="...", resource_metadata=".../.well-known/oauth-protected-resource/api/mcp/user"를 함께 실어 보냅니다. 이것이 RFC 9728이 정한 방식입니다. - 클라이언트는 그 주소로 가서 보호 자원 정보를 읽고, 이어서
/.well-known/oauth-authorization-server에서 인증 서버 정보를 읽습니다. RFC 8414 규격입니다. - 클라이언트가 자기 자신을 등록합니다.
POST /api/mcp/oauth/register로 이루어지는 동적 클라이언트 등록이며 RFC 7591을 따릅니다. 비밀 키가 없는 공개 클라이언트로 등록되고, 신원 증명은 PKCE로 대신합니다. 이 등록은 IP당 시간당 10회로 제한됩니다. - 브라우저가 열립니다.
GET /api/mcp/oauth/authorize가 패널 자체의 승인 화면인/mcp/connect로 안내합니다. 로그인 세션이 없으면 먼저 로그인 화면으로 보내고, 로그인이 끝나면 같은 승인 화면으로 되돌아옵니다. - 여러분이 승인합니다. 이때 "조회 전용 권한만 부여(주문 불가)" 체크박스를 켤 수 있습니다.
- 클라이언트가
POST /api/mcp/oauth/token으로 인증 코드를 토큰으로 바꿉니다. 이 단계에서 PKCE는S256방식만 받습니다.plain은 거부됩니다. OAuth 2.1이 요구하는 조건입니다.
여기까지가 한 번만 거치는 절차입니다. 이후에는 클라이언트가 토큰을 들고 조용히 요청을 보냅니다.
서버가 공개하는 정보 문서에는 이런 값들이 들어 있습니다. response_types_supported는 ["code"], grant_types_supported는 ["authorization_code", "refresh_token"], token_endpoint_auth_methods_supported는 ["none"], code_challenge_methods_supported는 ["S256"]입니다. 여기에 발급자 확인용 매개변수를 지원한다는 표시(RFC 9207)와 자원 지시자를 지원한다는 표시(RFC 8707)도 함께 들어 있습니다.
되돌아가는 주소에도 규칙이 있습니다. 등록할 수 있는 redirect_uris는 https 주소, 루프백 http 주소(127.0.0.1 또는 localhost), 그리고 cursor://나 vscode:// 같은 전용 스킴입니다. 원격 주소에 평문 http를 쓰는 것은 거부됩니다. 그리고 실제 요청의 되돌아갈 주소는 등록한 목록과 일치해야 합니다. 유일한 예외는 루프백 주소의 포트 번호이며, 이는 RFC 8252가 허용하는 범위입니다.
한 가지 더 알아 두면 좋은 설계가 있습니다. 이 모든 주소는 요청이 들어온 도메인에서 생성됩니다. 그래서 하위 패널 고객이 자기 패널 도메인으로 연결하면 발급자 주소도 그 도메인이 되고, 메인 패널 주소는 고객에게 한 번도 노출되지 않습니다. PKCE 검증값의 길이는 43자에서 128자 사이여야 하며, 이것은 클라이언트가 알아서 맞추는 부분입니다.
API 키로 연결하는 편이 나은 경우는 언제입니까?
두 가지 연결 방식이 다 열려 있습니다. 어느 쪽이 나은지는 클라이언트의 성격에 달려 있습니다.
| 항목 | OAuth 2.1 연결 | API 키 연결 |
|---|---|---|
| 준비물 | 없음, 주소만 등록 | API 페이지에서 발급한 pf_live_ 키 |
| 승인 절차 | 브라우저에서 패널 승인 화면 | 없음, 헤더에 키를 실어 보냄 |
| 권한 제한 | "조회 전용" 선택 가능 | 항상 전체 권한 |
| 유효 기간 | 접근 토큰 8시간, 자동 갱신 | 재발급하거나 폐기할 때까지 |
| 끊는 방법 | 패널에서 "연결 해제" 한 번 | 키 재발급 또는 폐기 |
| 적합한 곳 | 대화형 어시스턴트 앱 | 서버, 봇, 스크립트, 자동화 파이프라인 |
서버가 받아 주는 Bearer 값은 세 가지입니다. pf_mcp_로 시작하는 OAuth 접근 토큰, pf_live_로 시작하는 API v3 키, 그리고 64자리 16진수로 된 예전 리셀러 키입니다. X-Api-Key 헤더로 보내도 됩니다. 서버는 앞머리 글자만 보고 어느 방식인지 판단합니다.
여기서 놓치기 쉬운 점이 하나 있습니다. 키로 연결한 세션은 언제나 전체 권한입니다. 조회 전용이라는 개념은 OAuth 쪽에만 있습니다. 그러니 "이 봇은 읽기만 하게 하고 싶다"면 키를 주는 대신 OAuth로 연결하고 조회 전용을 선택하셔야 합니다. 키를 주면서 읽기만 하기를 기대하는 것은 방법이 아닙니다.
키를 쓰기로 했다면 관리 방식도 같이 정해 두십시오. 키는 재발급하는 순간 이전 키가 무효가 되므로, 여러 자동화가 같은 키를 공유하고 있으면 한꺼번에 끊깁니다. API 자체의 쓰임새는 SMM 패널 API 페이지와 API 문서에 정리되어 있습니다.
패널에서 실시간 가격을 확인하세요
팔로워, 좋아요, 조회수, 참여 서비스의 단가가 목록에 실시간으로 표시됩니다. 가입은 무료이며 잔액을 충전하기 전에도 목록을 살펴볼 수 있습니다.
승인 화면에서는 무엇을 보고 무엇을 승인합니까?
승인 화면의 주소는 /mcp/connect입니다. 검색 엔진에는 노출되지 않으며, 클라이언트가 시작한 흐름 안에서만 의미가 있습니다. 즉 이 주소를 직접 열어 보아도 할 수 있는 일이 없습니다.
화면 맨 위에는 요청한 클라이언트의 이름이 들어간 제목이 뜹니다. 형식은 "{클라이언트 이름}이(가) 계정 연결을 요청합니다"입니다. 그 아래 설명은 "승인하면 이 앱이 회원님을 대신해 아래 작업을 할 수 있습니다."입니다. 그러니까 이 화면에서 확인해야 할 첫 번째 항목은 이름입니다. 여러분이 방금 연결을 시작한 그 앱이 맞는지 보십시오.
화면에는 네 가지 정보가 나옵니다. "계정"에는 연결될 계정의 이메일이 표시됩니다. "이동할 주소"에는 승인 후 되돌아갈 주소가 표시됩니다. 그 아래에는 부여될 권한 목록이 있고, 마지막으로 "조회 전용 권한만 부여(주문 불가)" 체크박스가 있습니다. 버튼은 "연결 승인"과 "거부" 두 개입니다.
"이동할 주소"를 한 번 보고 넘어가시길 권합니다. 정상적인 경우 이 값은 여러분이 방금 조작한 그 앱의 주소입니다. 로컬에서 도는 앱이면 127.0.0.1이나 localhost가 보이고, 편집기 확장이면 cursor://나 vscode:// 형태가 보입니다. 낯선 도메인이 보인다면 승인하지 마십시오.
승인 코드는 오래 살지 않습니다. 화면을 열어 둔 채로 시간이 지나면 "연결 요청이 유효하지 않거나 만료되었습니다. 클라이언트에서 다시 시도하세요."가 뜹니다. 이때는 브라우저 뒤로 가기를 눌러 봐야 소용이 없고, 클라이언트에서 연결을 다시 시작해야 합니다.
로그인이 되어 있지 않은 상태에서 클라이언트가 승인을 요청하면 먼저 로그인 화면이 뜹니다. 로그인이 끝나면 원래 승인 화면으로 자동으로 되돌아오므로, 처음부터 다시 시작할 필요는 없습니다. 계정이 아직 없다면 회원가입부터 하셔야 합니다.
"조회 전용" 권한은 정확히 무엇을 막습니까?
승인 화면의 "조회 전용 권한만 부여(주문 불가)" 체크박스는 이름 그대로 동작합니다. 이것을 켜면 그 연결은 읽기만 하는 연결이 되고, 주문을 여는 도구가 그 세션에서 사라집니다.
권한 이름은 두 가지뿐입니다. account:read와 account:write입니다. 클라이언트가 아무것도 요청하지 않으면 둘 다 부여됩니다. 조회 전용을 선택하면 토큰은 account:read만 받습니다. 클라이언트가 openid, profile, email 같은 다른 이름을 요청해도 서버가 알아보지 못하는 이름은 조용히 버립니다.
구현 방식이 중요합니다. 서버는 조회 전용 연결에 "쓰기 도구를 호출하지 마라"고 지시하는 대신, 도구 목록 자체를 걸러서 내보냅니다. 조회 전용 연결에서 도구 목록을 받아 보면 12개만 보이고 나머지 6개는 아예 존재하지 않습니다. 지시문에 의존하지 않는 이유는 단순합니다. 지시를 지킬지 말지는 모델의 판단에 달려 있고, 돈이 걸린 자리에서 그 판단에 기대는 것은 설계가 아니기 때문입니다.
여기에 더해 서버 지시문에도 한 줄이 추가됩니다. 이 연결은 조회 전용이며 주문 생성과 취소, 리필 도구가 이 세션에 없다는 안내, 그리고 사용자가 주문을 원하면 패널에서 조회 전용 설정을 풀고 다시 연결해야 한다는 안내입니다. 그래서 어시스턴트는 없는 도구를 억지로 부르다 실패하는 대신 처음부터 상황을 설명할 수 있습니다.
조회 전용이 어울리는 경우가 실제로 많습니다. 보고서를 만들거나 지출을 정리하는 용도라면 주문 도구가 있을 이유가 없습니다. 여러 사람이 같은 어시스턴트를 쓰는 팀 환경도 마찬가지입니다. 반대로 실제 주문까지 맡기고 싶다면 체크박스를 켜지 마십시오. 나중에 마음이 바뀌면 연결을 끊고 다시 승인하면 됩니다.
어시스턴트는 어떤 순서로 주문을 넣습니까?
서버는 모델에게 지켜야 할 순서를 명시적으로 지시합니다. 이 지시는 연결이 열릴 때 함께 전달되며, 내용은 다섯 단계입니다.
search_services로 조건에 맞는 서비스를 찾고 서비스 번호를 확보합니다.get_service로 그 서비스의 최소와 최대 수량, 리필과 취소 지원 여부, 평균 소요 시간, 그리고 반드시 채워야 하는 입력란 목록을 읽습니다.preview_order로 금액을 계산합니다. 응답의charge와sufficient_balance를 사용자에게 그대로 알립니다.- 사용자에게 명시적인 승인을 받습니다. 승인 없이
create_order를 부르지 않습니다. create_order로 주문을 열고 돌아온 주문 번호를 알립니다.
실제 대화는 대략 이런 모양이 됩니다. 예시로 든 값이며 실제 가격이나 서비스가 아닙니다.
여러분이 "인스타그램 팔로워 2,000명, 리필 보장 있는 걸로 찾아 줘"라고 말하면, 어시스턴트는 먼저 검색 도구를 리필 조건을 걸어 호출합니다. 그다음 후보 몇 개를 표로 보여 주면서 가격과 최소 최대 수량, 평균 소요 시간을 비교합니다. 여러분이 하나를 고르면 미리보기 도구로 정확한 청구 금액과 주문 후 잔액을 계산해 알려 줍니다. 여기서 여러분이 "그걸로 진행해"라고 답해야 비로소 주문이 열립니다. 마지막에 주문 번호가 돌아옵니다.
이 흐름에서 여러분이 확인해야 할 지점은 세 번째와 네 번째 사이입니다. 어시스턴트가 알려 주는 금액은 미리보기 도구가 계산한 값이고, 이 값은 주문 화면의 "합계" 줄과 같은 계산을 거칩니다. 그러니 금액이 예상과 다르면 그 자리에서 멈추십시오. 승인하기 전에는 아직 아무 일도 일어나지 않은 상태입니다.
한 가지 더 있습니다. 주문이 열린 뒤의 진행 상황은 실시간이 아닙니다. get_order로 시작 수량과 남은 수량을 읽거나 list_events로 상태 변화를 따라가야 합니다. 어시스턴트가 "지금 몇 퍼센트 진행되었어?"라는 질문에 답하려면 그때마다 도구를 다시 호출합니다.
어시스턴트에게 어떻게 말해야 원하는 답이 나옵니까?
도구가 아무리 잘 만들어져 있어도 요청이 모호하면 답도 모호해집니다. 몇 가지 습관만 들이면 대화가 훨씬 짧아집니다.
첫째, 조건을 숫자와 이름으로 주십시오. "괜찮은 팔로워 서비스 찾아 줘"보다 "인스타그램 팔로워, 리필 보장 있는 것, 1,000개 기준 단가 낮은 순으로 다섯 개"가 훨씬 낫습니다. 검색 도구가 받을 수 있는 조건이 플랫폼, 카테고리, 유형, 리필 여부, 취소 여부, 드립피드 여부, 최저 단가, 최고 단가이므로 이 축에 맞춰 말하면 그대로 걸립니다.
둘째, 금액은 미리보기 결과로 확인하십시오. "이거 2,000개면 얼마야?"라고 물으면 어시스턴트가 직접 계산해서 답할 수도 있습니다. 그보다 "미리보기 돌려서 청구 금액이랑 주문 후 잔액 알려 줘"라고 요청하는 편이 정확합니다. 그러면 어시스턴트가 서버가 계산한 값을 그대로 전달합니다.
셋째, 승인 문장을 명확하게 쓰십시오. "그럼 그걸로 하지 뭐" 같은 애매한 답보다 "3번 서비스로 2,000개 주문해 줘"처럼 대상을 다시 지정하는 편이 안전합니다. 어시스턴트가 잘못된 후보를 고를 여지를 없앱니다.
넷째, 목록을 요청할 때는 범위를 주십시오. 주문 목록 도구는 기본 20건, 최대 100건을 돌려주고 상태로 거를 수 있습니다. "이번 주에 넣은 것 중에 아직 진행 중인 것만" 같은 요청이 "내 주문 다 보여 줘"보다 훨씬 쓸모 있는 답을 냅니다.
다섯째, 어시스턴트가 요약한 내용과 실제 화면이 다르면 화면을 믿으십시오. 모델은 도구가 돌려준 데이터를 사람이 읽기 좋게 다시 쓰는 과정에서 표현을 바꿀 수 있습니다. 숫자가 걸린 판단이라면 AI 어시스턴트 페이지가 아니라 주문 화면에서 최종 확인하시는 편이 낫습니다.
마지막으로, 어시스턴트에게 자기가 무엇을 할 수 있는지 물어봐도 됩니다. 도구 목록과 서버 지시문이 연결 시점에 전달되므로 "너는 지금 이 계정에서 뭘 할 수 있어?"라는 질문에 스스로 답할 수 있습니다. 조회 전용으로 연결했다면 그 사실도 함께 알려 줍니다.
가격 읽기에서 가장 비싼 실수: per_1000과 per_order
패널에서 가장 비싼 오해는 단가 표기입니다. 이 문제는 화면에서도 발생하고 어시스턴트에서도 발생합니다.
서비스 응답에는 pricing.unit이라는 값이 있습니다. 이 값이 per_1000이면 표시된 가격은 1,000개 기준입니다. per_order이면 표시된 가격은 그 패키지 전체의 값입니다. 두 번째 경우에는 1,000으로 나누는 과정이 없습니다.
서버 지시문은 이 부분을 특히 강조합니다. 이 구분을 놓치면 금액을 1,000배 틀리게 계산하기 때문입니다. 예를 들어 22라는 숫자를 보고 "1,000개에 22달러"라고 읽었는데 실제로는 그 패키지 한 건이 22달러인 경우, 수량을 크게 잡으면 결제 금액이 예상의 수백 배가 됩니다.
금액이 문자열로 돌아온다는 점도 알아 두시면 좋습니다. 서버는 금액을 소수점이 있는 문자열로 내려보내고, 지시문은 모델에게 이 값을 부동소수점 숫자로 바꿔 반올림하지 말라고 요구합니다. 통화는 항상 USD입니다.
| 항목 | 값 | 무엇을 뜻합니까 |
|---|---|---|
pricing.unit |
per_1000 |
표시 가격은 1,000개 기준입니다 |
pricing.unit |
per_order |
표시 가격이 그 주문 전체의 값입니다 |
| 금액 형식 | 소수점 문자열 | 숫자로 변환해 반올림하지 않습니다 |
| 통화 | USD | 화면 표시 통화와 무관하게 계산 기준은 USD입니다 |
| 최종 확인 | preview_order의 charge |
실제 청구될 금액입니다 |
실전에서 지킬 규칙은 하나입니다. 어시스턴트가 계산해서 말해 준 숫자를 믿기보다 미리보기 도구의 charge 값을 그대로 확인하십시오. 그 값이 실제로 차감될 금액입니다. 어시스턴트에게 "미리보기 결과의 청구 금액을 그대로 알려 줘"라고 요청하면 계산 과정에서 생기는 오차가 끼어들 여지가 없습니다.
대량 주문과 특수 서비스 유형은 어시스턴트에서 어떻게 동작합니까?
패널에는 링크와 수량만 받는 표준 서비스 말고도 입력란이 더 필요한 유형이 많습니다. 어시스턴트도 같은 값을 채워야 합니다. 다행히 이름을 새로 외울 필요는 없습니다. 도구의 매개변수 이름이 API v3와 하나도 다르지 않기 때문입니다.
쓸 수 있는 이름은 service, link, quantity, runs, interval, comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords, media입니다. 어떤 서비스가 어떤 값을 요구하는지는 get_service 응답의 입력란 목록이 알려 줍니다. 어시스턴트는 이 목록을 읽고 필요한 것만 채웁니다.
댓글 계열 서비스에는 규칙이 하나 더 있습니다. 이런 서비스에는 수량을 보내지 않습니다. 댓글을 한 줄에 하나씩 적고, 줄 수가 곧 수량이 됩니다. 지시문에도 같은 내용이 들어 있으므로 어시스턴트가 수량 칸을 억지로 채우려 하지 않습니다.
드립피드는 runs와 interval로 표현합니다. runs는 몇 번에 나누어 보낼지이고 interval은 회차 사이의 분 단위 간격입니다. 이 값은 드립피드를 지원하는 서비스에서만 의미가 있습니다. 나누어 보내기가 실제로 무엇을 바꾸고 무엇을 바꾸지 않는지는 분할 전달과 자동 구독 서비스 글에 정리해 두었습니다.
한 번에 여러 건을 열어야 한다면 create_orders_bulk를 씁니다. 한 호출에 최대 50건까지 들어갑니다. 항목은 순서대로 처리되고, 중간에 하나가 실패해도 나머지는 계속 열립니다. 각 항목이 자기 결과를 따로 돌려주므로 어떤 줄이 실패했는지 바로 알 수 있습니다.
여기서 주의할 점이 있습니다. 대량 주문 도구는 전체 금액을 미리 알려 주지 않습니다. 총액을 먼저 알고 싶다면 항목을 하나씩 미리보기로 통과시켜야 합니다. 50건을 한꺼번에 여는 요청이라면 어시스턴트에게 "먼저 각 줄을 미리보기로 계산해서 합계를 알려 주고, 내가 승인하면 실행해"라고 명확히 말하는 편이 안전합니다.
리필과 취소를 어시스턴트에게 맡겨도 됩니까?
맡길 수 있습니다. 다만 두 기능 모두 조건이 붙어 있고, 그 조건은 어시스턴트가 만들어 낼 수 있는 것이 아닙니다.
취소는 그 서비스가 취소를 지원할 때만 됩니다. 지원 여부는 서비스 상세 정보의 기능 항목에 들어 있고, 어시스턴트는 주문을 취소하기 전에 그 값을 확인하도록 안내받습니다. 지원하지 않는 서비스에서 취소를 시도하면 cancel_not_supported가 돌아옵니다. 이 경우 남은 길은 고객지원 문의인데, 문의 작성 도구는 없으므로 화면에서 직접 남기셔야 합니다.
리필은 완료된 주문이면서 리필이 보장된 서비스에서만 됩니다. 요금이 붙지 않으므로 잔액에는 영향이 없습니다. 진행 중인 주문에 리필을 요청하는 것은 성립하지 않고, 보장이 없는 서비스에서 완료 후에 생긴 이탈은 보상 대상이 아닙니다. 이 규칙은 화면에서 리필 버튼이 나타나는 조건과 동일합니다.
| 요청 | 필요한 주문 상태 | 필요한 서비스 조건 | 잔액 영향 |
|---|---|---|---|
| 취소 | 아직 완료되지 않은 상태 | 서비스가 취소를 지원해야 합니다 | 취소가 확정되면 환불됩니다 |
| 리필 | 완료 | 서비스가 리필을 보장해야 합니다 | 없습니다 |
요청 상태를 따라가는 도구도 따로 있습니다. list_refills로 그동안 낸 리필 요청과 상태를 보고, get_refill로 특정 요청 하나의 현재 상태를 확인합니다. 후자는 공급업체 쪽에서 최신 상태를 다시 가져옵니다.
실무에서 유용한 조합은 이렇습니다. "완료된 주문 중에 리필 보장 있는 것만 뽑아서, 지금 리필 요청할 만한 게 있는지 정리해 줘"라고 요청하면 어시스턴트가 주문 목록과 서비스 정보를 함께 읽어 후보를 추려 줍니다. 다만 실제로 요청을 넣을지는 여러분이 판단하십시오. 이탈이 왜 생기고 리필이 무엇을 보장하는지는 팔로워 이탈과 리필 보장 글에 자세히 정리해 두었습니다.
어시스턴트가 할 수 없는 일은 무엇입니까?
경계선을 분명히 그어 두겠습니다. 패널 화면의 안내 문구와 서버 지시문이 같은 내용을 말하고 있습니다.
어시스턴트가 할 수 있는 일은 "서비스 검색, 가격 계산, 주문 및 잔액 조회"와 "주문 생성, 취소, 리필 요청"입니다. 그리고 주문을 넣기 전에는 반드시 확인을 요청하도록 되어 있습니다.
할 수 없는 일은 "잔액 충전, 출금, 비밀번호 확인, 다른 계정 접근"입니다. 여기에 몇 가지를 더 붙일 수 있습니다.
| 요청 | 가능 여부 | 이유 |
|---|---|---|
| 서비스 검색과 비교 | 가능 | 카탈로그 조회 도구가 있습니다 |
| 금액 계산 | 가능 | 미리보기 도구가 실제 청구액을 돌려줍니다 |
| 주문 생성과 취소 | 가능 | 취소는 서비스가 지원할 때만 됩니다 |
| 리필 요청 | 가능 | 완료된 주문이면서 리필 보장이 있을 때만 됩니다 |
| 잔액 충전 | 불가능 | 결제 도구가 없습니다 |
| 출금 | 불가능 | 해당 도구가 없습니다 |
| 가격 변경 | 불가능 | 사용자 서버에 관리 기능이 없습니다 |
| 고객지원 문의 작성 | 불가능 | 문의 도구가 없습니다 |
| 비밀번호 조회나 변경 | 불가능 | 계정 인증 정보에 접근하지 않습니다 |
| 다른 사람 계정 조회 | 불가능 | 연결은 한 계정에 고정되어 있습니다 |
마지막 항목을 조금 더 설명하겠습니다. 서버는 요청마다 하나의 계정에 묶여 동작합니다. 도구가 다른 사용자의 데이터를 볼 수 있는 경로 자체가 없고, 관리 기능도 이 서버에는 존재하지 않습니다. 그래서 "다른 계정 주문도 보여 줘" 같은 요청은 권한 오류로 끝나는 것이 아니라 애초에 그런 도구가 없어서 답할 수 없습니다.
도구가 오류를 돌려주는 경우도 정해진 방식이 있습니다. 오류 코드는 고정되어 있고(예를 들어 insufficient_balance, quantity_out_of_range), 메시지는 여러분의 언어로 돌아옵니다. 지시문은 모델에게 그 메시지를 그대로 전달하고 없는 해결책을 지어내지 말라고 요구합니다. 잔액 충전이나 문의 작성처럼 도구로 처리할 수 없는 일은 패널로 안내하도록 되어 있습니다.
게시물 하나로 먼저 검증해 보세요
위 내용을 확인하는 가장 저렴한 방법은 게시물 하나에 소액 주문을 넣고 결과를 본인의 인사이트 데이터와 비교하는 것입니다.
보안: 비밀번호, 토큰, 그리고 유효 기간
가장 중요한 사실부터 말씀드리면, 어시스턴트는 여러분의 비밀번호를 보지 못합니다. 승인은 패널의 로그인 세션 위에서 이루어지고, 클라이언트가 받는 것은 비밀번호가 아니라 토큰입니다.
발급되는 비밀 값들과 유효 기간은 아래와 같습니다.
| 비밀 값 | 앞머리 | 유효 기간 |
|---|---|---|
| 인증 코드 | pf_mca_ |
10분, 한 번만 사용 가능 |
| 접근 토큰 | pf_mcp_ |
8시간 |
| 갱신 토큰 | pf_mcr_ |
90일, 사용할 때마다 새 값으로 교체 |
| 클라이언트 식별자 | mcpc_ |
만료 없음 |
| API 키 | pf_live_ |
폐기하거나 재발급할 때까지 |
값은 모두 32바이트, 즉 256비트 난수를 base64url로 표현한 것입니다. 그리고 데이터베이스에는 평문이 저장되지 않습니다. HMAC-SHA256 해시만 보관하며, 해시 키는 서버의 비밀 설정값에서 파생됩니다. 그래서 데이터베이스만 들여다봐서는 실제 토큰 값을 복원할 수 없습니다.
토큰 재사용에 대한 방어 장치도 있습니다. 인증 코드는 한 번만 쓸 수 있고, 두 번째로 같은 코드가 들어오면 그 클라이언트가 이 계정에 대해 가진 모든 토큰이 폐기됩니다. 이미 폐기된 갱신 토큰이 들어오는 경우도 같습니다. 즉 토큰이 새어 나가 누군가 재사용을 시도하면, 그 시도 자체가 연결 전체를 끊어 버립니다. 이때는 정상 클라이언트도 함께 끊기므로 다시 승인해야 합니다. 불편해 보이지만 의도된 동작입니다.
접근 토큰의 8시간은 짧게 느껴질 수 있는데, 실제로는 신경 쓸 일이 거의 없습니다. 클라이언트가 갱신 토큰으로 알아서 새 토큰을 받아 오기 때문입니다. 갱신 토큰 자체도 쓸 때마다 새 값으로 바뀌므로, 예전 값이 어딘가 남아 있어도 다시 쓰이지 않습니다.
마지막으로 하나. 패널은 어떤 경우에도 소셜 계정의 비밀번호를 요구하지 않습니다. 어시스턴트를 통해서든 화면을 통해서든 마찬가지입니다. 필요한 것은 공개된 프로필 주소나 게시물 주소뿐입니다.
모든 호출은 기록에 남습니다
모든 도구 호출은 기록됩니다. 사용자 서버든 관리 서버든 같은 기록 테이블을 씁니다. 남는 항목은 호출한 클라이언트 정보(User-Agent), 계정 식별자, 도구 이름, 전달된 인자, 결과, 오류, 그리고 걸린 시간입니다.
몇 가지 규칙이 있습니다.
- 인자 중에 비밀로 보이는 이름(
apikey,api_key,secret,password,passphrase,token)이 있으면 값이***로 가려집니다. - 조회 도구의 결과는 기록하지 않습니다. 양이 많고 남겨 두는 이득이 적기 때문입니다.
- 쓰기 도구의 결과는 기록합니다. 무엇이 실제로 만들어졌는지 남겨야 하기 때문입니다.
- 인자와 결과의 JSON은 8,000자에서 잘립니다.
- 기록 실패가 본 작업을 막지는 않습니다. 로그를 쓰지 못해도 주문 자체는 정상 처리됩니다.
이 기록이 실제로 쓸모 있는 순간은 나중에 옵니다. 어떤 주문이 화면에서 들어온 것인지 어시스턴트를 통해 들어온 것인지 구분할 수 있고, 어느 클라이언트가 언제 무엇을 호출했는지 되짚을 수 있습니다. 자동화를 여러 개 붙여 두었다면 이 구분이 문제를 좁히는 첫 단서가 됩니다.
한 가지 덧붙이면, 사용자 서버와 관리 서버의 기록은 계정 식별자 유무로 구분됩니다. 사용자 쪽 호출에는 계정 식별자가 채워지고 관리 쪽 호출에는 비어 있습니다. 여러분이 직접 이 로그를 열어 보는 화면은 없지만, 문의를 남기면 이 기록을 근거로 상황을 확인할 수 있습니다.
연결된 어시스턴트는 어디서 확인하고 어떻게 끊습니까?
AI 어시스턴트 페이지의 맨 아래에 "연결된 어시스턴트" 영역이 있습니다. 여기에 지금 여러분 계정에 붙어 있는 클라이언트가 모두 나열됩니다. 아직 아무것도 연결하지 않았다면 "아직 연결된 AI 어시스턴트가 없습니다."만 보입니다.
각 줄에는 다음이 표시됩니다.
| 표시 항목 | 내용 |
|---|---|
| 클라이언트 이름 | 등록할 때 클라이언트가 알린 이름입니다 |
| 권한 배지 | "전체 권한" 또는 "조회 전용" |
| "연결됨" | 처음 승인한 날짜입니다 |
| "마지막 사용" | 마지막으로 도구를 호출한 시각이며, 없으면 "없음"으로 표시됩니다 |
| "연결 해제" 버튼 | 그 클라이언트의 접근을 끊습니다 |
"연결 해제"를 누르면 확인을 한 번 더 묻습니다. 문구는 "이 어시스턴트의 계정 접근 권한이 사라집니다. 계속할까요?"입니다. 확인하면 "연결이 해제되었습니다."가 뜨고 그 줄이 목록에서 사라집니다. 실패하면 "연결을 해제하지 못했습니다."가 뜹니다.
끊고 나면 그 클라이언트가 가지고 있던 토큰은 즉시 무효가 됩니다. 접근 토큰의 8시간이 남아 있어도 마찬가지입니다. 다시 쓰려면 처음부터 승인 절차를 다시 밟아야 합니다. 클라이언트 쪽에서 끊는 방법도 있는데, 규약상으로는 폐기 요청을 보내는 경로가 준비되어 있습니다. 다만 대부분의 경우 패널에서 버튼 하나 누르는 편이 빠릅니다.
이 목록은 정기적으로 한 번씩 확인해 보시길 권합니다. 여러 도구를 실험해 본 뒤에는 쓰지 않는 연결이 남아 있기 마련이고, "마지막 사용" 값이 오래된 줄은 대체로 지워도 되는 줄입니다. 권한 배지가 "전체 권한"인데 기억나지 않는 클라이언트가 있다면 먼저 끊고 나중에 필요하면 다시 연결하는 것이 안전합니다.
이벤트와 웹훅으로 자동화하려면 어떻게 합니까?
주문 상태가 바뀔 때마다 알아채고 싶다면 두 가지 길이 있습니다. 계정의 이벤트 목록을 주기적으로 읽는 방법과 웹훅으로 받아 보는 방법입니다. 어시스턴트는 둘 다 다룰 수 있습니다.
이벤트 종류는 여덟 가지이며 이름은 번역되지 않습니다.
| 이벤트 이름 | 언제 발생합니까 |
|---|---|
order.created |
주문이 만들어졌을 때 |
order.processing |
주문 처리가 시작되었을 때 |
order.completed |
주문이 완료되었을 때 |
order.partial |
일부만 전달되어 부분 완료로 마감되었을 때 |
order.canceled |
주문이 취소되었을 때 |
order.updated |
주문 정보가 갱신되었을 때 |
refill.created |
리필 요청이 만들어졌을 때 |
refill.updated |
리필 요청 상태가 바뀌었을 때 |
list_events는 오래된 것부터 새로운 것 순으로 읽으며 커서로 이어집니다. 마지막으로 읽은 위치를 기억해 두었다가 다음에 그 지점부터 읽으면 중간을 놓치지 않습니다. 이 방식은 웹훅을 걸 수 없는 환경에서 특히 유용합니다. 노트북에서 개발 중이거나 고정 주소가 없는 경우가 여기 해당합니다.
웹훅을 쓸 수 있다면 create_webhook으로 주소를 등록합니다. 받을 이벤트 종류를 지정할 수 있고, 비워 두면 전부 보냅니다. 등록하면 응답에 서명용 비밀 키가 들어 있는데 이 값은 한 번만 표시됩니다. 어시스턴트에게 등록을 시켰다면 그 자리에서 안전한 곳으로 옮겨 적으십시오. 지나가면 다시 볼 수 없고 새로 만드는 수밖에 없습니다.
등록된 목록은 list_webhooks로 확인합니다. 주소, 구독한 이벤트, 최근 전송 결과가 함께 나옵니다. 필요 없어지면 delete_webhook으로 지웁니다. 지우면 아직 전송을 기다리던 건들도 함께 버려집니다. 웹훅 규격과 서명 검증 방법은 API 문서에 정리되어 있으니, 실제로 수신 코드를 짜실 거라면 그쪽을 함께 보십시오.
미리 준비된 명령: order_status, find_service, reorder
서버는 도구 말고도 미리 만들어진 명령 세 개를 제공합니다. 클라이언트가 이 목록을 읽어 메뉴 형태로 보여 주기도 하고, 여러분이 직접 이름을 불러 쓸 수도 있습니다.
| 명령 | 하는 일 | 인자 |
|---|---|---|
order_status |
최근 주문을 요약하고 멈춰 있거나 덜 채워진 건을 짚어 줍니다 | count(기본 10) |
find_service |
요청 하나에 대해 서비스 3개에서 5개를 비교하고 가격을 뽑습니다. 주문은 열지 않습니다 | request(필수), quantity |
reorder |
지난 주문과 같은 내용을 승인을 받아 다시 엽니다 | order_id(필수) |
order_status는 주문 목록을 서비스 정보까지 포함해 불러온 뒤 번호, 서비스 이름, 상태, 수량, 남은 수량, 요금을 정리해 보여 줍니다. 그리고 완료되지 않았거나 공급업체 쪽 오류가 있는 건을 따로 강조하고, 각각에 대해 취소나 리필, 대기 중 무엇이 가능한지 알려 주도록 되어 있습니다.
find_service는 비교용입니다. 검색 결과에서 가장 그럴듯한 몇 개를 골라 가격, 최소와 최대, 리필 보장, 평균 소요 시간을 표로 정리합니다. 수량을 함께 주면 그중 가장 적절해 보이는 서비스에 대해 미리보기까지 돌려 금액을 계산합니다. 이 명령은 주문을 열지 않도록 명시적으로 지시받고 있습니다. 결정은 여러분이 합니다.
reorder는 지난 주문을 읽어서 같은 서비스, 같은 링크, 같은 수량으로 미리보기를 돌리고 현재 금액을 보여 준 다음 승인을 요청합니다. 승인이 없으면 아무것도 하지 않습니다. 그리고 같은 링크에 아직 진행 중인 주문이 있으면 먼저 경고하도록 되어 있습니다.
이 세 명령이 있다고 해서 다른 요청을 못 하는 것은 아닙니다. 그냥 자주 쓰는 흐름을 미리 묶어 둔 것입니다. 평소에는 자연어로 말하고, 정리된 형태의 답이 필요할 때 이 명령을 부르는 식으로 쓰시면 됩니다.
프로토콜 세부 사항: 전송 방식과 요청 한도
여기부터는 직접 클라이언트를 만들거나 문제를 파고들 때 필요한 내용입니다. 일반적인 사용에서는 몰라도 됩니다.
서버는 스트리밍 가능한 HTTP 위에서 JSON-RPC 2.0으로 동작하며 상태를 저장하지 않습니다. 세션 식별자를 유지하지 않는다는 뜻입니다. 요청 하나가 곧 완결된 단위입니다.
| 항목 | 값 |
|---|---|
| 프로토콜 | JSON-RPC 2.0, 상태 비저장 |
| 허용 메서드 | initialize, tools/list, tools/call, prompts/list, prompts/get, ping, resources/list, resources/templates/list |
| 기본 프로토콜 버전 | 2025-06-18 |
| 호환 버전 | 2025-03-26, 2024-11-05 |
| GET 요청 | HTTP 405, SSE 스트림은 제공하지 않습니다 |
| 배치 요청 | 배열 형태로 지원합니다 |
| 알림만 담긴 요청 | 본문 없이 HTTP 202 |
| 도구 출력 상한 | 100,000자에서 잘립니다 |
| 계정당 요청 한도 | 분당 600회, 초과 시 HTTP 429와 Retry-After: 60 |
자원 목록을 묻는 두 메서드는 규약을 만족시키기 위해 존재하며 빈 결과를 돌려줍니다. 이 서버가 제공하는 것은 도구와 명령이지 문서 자원이 아니기 때문입니다.
브라우저 주소창에 연결 주소를 그대로 입력하면 405가 나옵니다. 오류가 아니라 정상 동작입니다. 이 서버는 POST만 받고 서버 발신 이벤트 스트림을 열지 않습니다. 연결이 되었는지 확인하고 싶다면 앞에서 소개한 명령줄 예시처럼 POST로 도구 목록을 요청해 보십시오.
오류 처리 방식도 알아 둘 만합니다. 도구가 실패해도 프로토콜 수준의 오류로 취급하지 않습니다. 대신 오류 표시가 붙은 텍스트로 돌아옵니다. 이렇게 하는 이유는 모델이 그 내용을 읽고 스스로 고칠 수 있게 하기 위해서입니다. 수량이 범위를 벗어났다면 모델이 범위를 다시 읽고 값을 조정할 수 있습니다.
도구 목록을 받아 갈 때 각 도구에는 힌트가 함께 붙습니다. 읽기 전용인지, 되돌리기 어려운 작업인지를 알려 주는 표시입니다. 클라이언트는 이 표시를 보고 되돌리기 어려운 도구에 대해 사용자 확인을 한 번 더 받는 식으로 쓸 수 있습니다. 서버가 지시문으로만 부탁하지 않고 기계가 읽을 수 있는 형태로도 알려 주는 셈입니다.
출력 길이에도 상한이 있습니다. 도구가 돌려주는 텍스트는 100,000자에서 잘립니다. 정상적인 사용에서는 걸릴 일이 없지만, 조건 없이 큰 목록을 요청하면 뒷부분이 사라질 수 있습니다. 이것도 조건을 좁혀서 묻는 편이 나은 이유 중 하나입니다.
요청 한도는 API v3와 같은 천장을 씁니다. 같은 계정의 요청이 MCP로 들어오든 일반 HTTP로 들어오든 구분하지 않고 분당 600회로 셉니다. v3 계층에는 IP당 분당 900회 제한도 따로 있습니다. 손으로 대화하는 정도로는 걸릴 일이 없지만, 자동화를 촘촘하게 돌린다면 기억해 두십시오.
리셀러와 하위 패널 운영자에게는 무엇이 달라집니까?
리셀러 관점에서 MCP는 두 가지 의미를 가집니다. 하나는 여러분 자신의 운영이 편해지는 것이고, 다른 하나는 여러분 고객에게 제공할 수 있는 기능이 하나 늘어나는 것입니다.
첫 번째부터 보겠습니다. 여러 고객의 주문을 대신 넣는 일을 하고 있다면 반복 작업이 많습니다. 같은 서비스를 다른 링크로 계속 열고, 상태를 확인하고, 멈춘 건을 골라내는 일입니다. 이런 작업은 대화로 처리하기에 적합합니다. "오늘 들어온 주문 중에 아직 시작 안 된 게 있으면 정리해 줘" 같은 요청 하나로 목록과 판단 근거를 함께 받을 수 있습니다. 리셀러 운영 전반은 SMM 리셀러 사업 시작 가이드에 따로 정리해 두었습니다.
두 번째가 하위 패널 이야기입니다. 자기 도메인으로 패널을 운영하고 있다면, 그 패널의 고객도 같은 페이지에서 자기 어시스턴트를 연결할 수 있습니다. 화면 구성은 동일하고 주소만 여러분의 도메인으로 바뀝니다. 이것이 중요한 이유는 노출 때문입니다. 앞에서 설명했듯이 발급자 주소와 공개 정보 문서의 주소가 모두 요청이 들어온 도메인에서 만들어지므로, 고객의 클라이언트가 보는 모든 주소가 여러분의 도메인입니다. 메인 패널 주소는 어디에도 나타나지 않습니다.
| 상황 | 연결 주소 | 고객에게 보이는 이름 |
|---|---|---|
| 메인 패널 고객 | 메인 도메인 뒤에 /api/mcp/user |
메인 패널 |
| 하위 패널 고객 | 그 패널 도메인 뒤에 /api/mcp/user |
그 패널 |
계정 구분도 그대로 유지됩니다. 하위 패널에서 만든 계정은 그 패널의 도메인에서만 유효합니다. 어시스턴트 연결도 마찬가지여서, 계정을 만든 도메인이 아닌 곳에 연결하면 로그인이 되지 않습니다. 고객이 "연결이 안 된다"고 문의하면 도메인부터 확인해 보십시오.
하위 패널 자체의 조건과 비용 구조는 하위 패널 안내 페이지에 정리되어 있습니다. 에이전시 규모로 운영을 키우는 관점은 소셜미디어 에이전시 확장 가이드를 참고하시면 됩니다.
계정을 만들고 몇 분 안에 주문하세요
가입은 무료이며 두 단계면 끝납니다. 카드, 계좌이체, 암호화폐로 잔액을 충전하고 주문한 뒤 패널에서 진행 상황을 확인하세요.
처음 연결한 뒤에는 무엇부터 해 보면 좋습니까?
승인을 마쳤다면 곧바로 주문을 넣기보다 순서대로 몇 가지를 확인해 보시길 권합니다. 여기서 어긋나는 부분이 있으면 나중에 금액이 걸린 자리에서 문제가 됩니다.
- 계정 요약을 물어보십시오. "지금 내 잔액이랑 계정 정보 알려 줘"라고 하면 계정 식별자, 이메일, 사용 가능한 잔액이 돌아옵니다. 여기 나온 이메일이 여러분 계정이 맞는지 확인하십시오. 하위 패널 계정을 여러 개 쓰는 분이라면 특히 중요합니다.
- 플랫폼 목록을 받아 보십시오. 어떤 플랫폼에 서비스가 몇 개씩 있는지 나옵니다. 이 값이 서비스 목록 화면과 크게 다르지 않다면 카탈로그 조회가 정상입니다.
- 검색을 한 번 걸어 보십시오. 평소 쓰는 조건을 그대로 말해 보고 결과가 납득이 가는지 확인합니다.
- 미리보기를 한 번 돌려 보십시오. 실제로 주문을 넣지 않으므로 위험이 없습니다. 나온 금액을 주문 화면에서 같은 조건으로 계산한 값과 비교해 보십시오. 두 값이 같아야 합니다.
- 마지막으로 AI 어시스턴트 페이지의 "연결된 어시스턴트" 목록을 열어 방금 연결한 항목이 보이는지, 권한 배지가 의도한 값인지 확인하십시오.
여기까지 통과했다면 실제 주문을 맡겨도 됩니다. 처음 몇 번은 금액이 작은 주문으로 시작하시길 권합니다. 어시스턴트가 승인 절차를 지키는지, 주문 번호를 제대로 알려 주는지, 그 주문이 "내 주문" 화면에 그대로 나타나는지를 눈으로 확인하는 과정이라고 생각하시면 됩니다.
반대로 확인 과정에서 어긋나는 부분이 있으면 그 자리에서 멈추십시오. 잔액이 다르게 나오거나, 검색 결과에 엉뚱한 플랫폼이 섞여 나오거나, 미리보기 금액이 화면과 다르다면 연결 대상이 잘못되었을 가능성이 큽니다. 가장 흔한 원인은 주소를 잘못 등록한 경우와 다른 계정으로 승인한 경우입니다.
패널 소유자 쪽: 57개 도구의 관리 서버
고객용 서버와 별개로, 패널 소유자를 위한 관리 서버가 같은 방식으로 열려 있습니다. 주소는 POST /api/mcp이고 도구는 57개입니다. 이 서버는 패널 전체를 다룹니다. 전반 현황과 검색, 사용자, 주문, 주문 요청, 서비스, 카테고리, 공급업체, 결제, 고객지원 문의, 쿠폰, 설정이 도구 영역입니다.
인증은 단일 비밀 키로 이루어지며, 그 키가 설정되어 있지 않으면 엔드포인트 자체가 닫혀서 HTTP 503을 돌려줍니다. 키는 헤더나 쿼리 매개변수 어느 쪽으로도 보낼 수 있고 비교는 시간 차이가 드러나지 않는 방식으로 이루어집니다.
안전장치도 몇 가지 걸려 있습니다. 마지막으로 남은 관리자는 권한을 잃거나 차단될 수 없고, 금액을 다루는 작업은 트랜잭션과 행 잠금으로 원자적으로 처리되며, 모든 호출은 앞에서 설명한 기록에 남습니다.
이 내용을 여기 적어 두는 이유는 하나입니다. 패널 운영 자체가 같은 프로토콜로 이루어진다는 사실이 고객 쪽 서버의 신뢰도와 무관하지 않기 때문입니다. 고객용 서버는 급하게 붙인 부가 기능이 아니라 같은 뼈대 위에서 권한만 좁혀 놓은 구성입니다.
MCP, API, 패널 화면 중 무엇을 언제 써야 합니까?
세 가지 입구가 같은 기능을 향해 열려 있습니다. 어느 것을 쓸지는 상황에 따라 정하시면 됩니다.
| 기준 | 패널 화면 | MCP 어시스턴트 | REST API |
|---|---|---|---|
| 준비 시간 | 없음 | 승인 한 번 | 키 발급과 코드 작성 |
| 적합한 작업 | 한두 건 주문, 화면 확인 | 탐색과 비교, 반복 조회, 대화형 처리 | 정해진 흐름의 대량 자동화 |
| 판단이 필요한 일 | 사람이 직접 | 어시스턴트가 후보를 정리하고 사람이 결정 | 미리 짜 둔 규칙대로 |
| 예측 가능성 | 높음 | 중간, 모델이 개입합니다 | 높음 |
| 기록 | 주문 기록 | 주문 기록과 호출 기록 | 주문 기록 |
| 비용 | 주문 금액만 | 주문 금액만 | 주문 금액만 |
정리하면 이렇습니다. 무엇을 살지 아직 정하지 못했고 카탈로그를 훑어야 하는 단계라면 어시스턴트가 유용합니다. 조건을 걸어 검색하고 후보를 비교하고 금액을 뽑는 일을 몇 초 안에 끝냅니다. 반대로 매일 정해진 시각에 정해진 서비스를 정해진 수량으로 넣는 일이라면 REST API 쪽이 낫습니다. 모델이 개입할 이유가 없고, 결과가 항상 같아야 하기 때문입니다.
화면은 여전히 필요합니다. 잔액 충전, 문의 작성, 계정 설정, 하위 패널 관리는 화면에서만 됩니다. 그리고 무엇이 실제로 일어났는지 최종 확인하는 곳도 "내 주문" 화면입니다. 어시스턴트가 알려 준 내용과 화면이 다르다면 화면이 맞습니다.
카탈로그를 먼저 눈으로 보고 싶다면 로그인 없이도 열리는 서비스 목록이 있습니다. 어떤 지표를 기준으로 결과를 판단해야 하는지 감이 잡히지 않는다면 소셜미디어 지표와 참여율 계산이 참고가 됩니다.
문제가 생기면 어디를 봐야 합니까?
자주 나오는 증상과 그 원인을 정리했습니다. 대부분은 설정 문제이고 몇 가지는 정상 동작입니다.
| 증상 | 원인 | 해결 방법 |
|---|---|---|
401 invalid_token |
접근 토큰의 8시간이 지났습니다 | 클라이언트가 갱신 토큰으로 스스로 갱신합니다. 갱신되지 않으면 패널에서 다시 연결합니다 |
브라우저에서 405 |
GET으로 스트림을 열려고 했습니다 | 정상입니다. 이 서버는 POST만 받습니다 |
429 |
분당 600회 한도를 넘었습니다 | Retry-After에 적힌 시간만큼 기다립니다 |
| "연결 요청이 유효하지 않거나 만료되었습니다" | 인증 코드의 10분이 지났거나 클라이언트가 등록되어 있지 않습니다 | 클라이언트에서 연결을 다시 시작합니다 |
| 토큰 발급이 400으로 거절됨 | 클라이언트가 plain 방식 PKCE를 보냈습니다 |
S256만 허용됩니다. 클라이언트 설정을 확인합니다 |
| 되돌아갈 주소가 거절됨 | redirect_uri가 등록된 목록과 다릅니다 |
루프백 주소의 포트만 예외입니다 |
| 엔드포인트가 503 | 관리 서버의 비밀 키가 설정되어 있지 않습니다 | 패널 소유자만 해당됩니다 |
| 계정을 찾을 수 없음 | 하위 패널에서 만든 계정입니다 | 그 패널의 도메인으로 연결합니다 |
몇 가지를 조금 더 풀어 두겠습니다.
401은 대부분 그냥 지나갑니다. 정상적인 클라이언트라면 만료를 감지하고 갱신 토큰으로 새 접근 토큰을 받아 옵니다. 반복해서 같은 오류가 뜬다면 연결이 어딘가에서 끊긴 것이므로, 패널에서 그 연결을 해제하고 처음부터 다시 승인하는 편이 빠릅니다.
되돌아갈 주소 문제는 주로 직접 만든 클라이언트에서 생깁니다. 등록할 때 적은 주소와 실제 요청에 실은 주소가 글자 하나까지 같아야 합니다. 예외는 루프백 주소의 포트 번호뿐입니다. 매번 다른 포트를 여는 로컬 앱을 위해 열어 둔 예외입니다.
도구가 오류를 돌려줄 때는 코드를 먼저 보십시오. insufficient_balance는 잔액이 모자란 것이고, quantity_out_of_range는 수량이 서비스의 최소와 최대를 벗어난 것이며, cancel_not_supported는 그 서비스가 취소를 지원하지 않는 것입니다. 코드는 고정되어 있고 메시지는 여러분의 언어로 나옵니다. 리필과 이탈 자체의 원리는 팔로워 이탈과 리필 보장 글에 정리해 두었습니다.
자주 묻는 질문
MCP란 무엇입니까?
MCP(Model Context Protocol)는 AI 어시스턴트가 외부 시스템의 기능을 도구처럼 호출할 수 있게 해 주는 개방형 프로토콜입니다. 서버 쪽이 자기가 가진 도구와 각 도구의 입력 형식을 한 번 선언해 두면, 그 규약을 이해하는 모든 클라이언트가 같은 방식으로 그 도구를 씁니다. 이 패널에서는 계정 하나를 어시스턴트에게 열어 주는 통로로 쓰입니다.
어시스턴트에게 패널 비밀번호를 알려 줘야 합니까?
아닙니다. 승인은 패널 안에서 여러분의 로그인 세션 위에서 이루어지고, 클라이언트가 받는 것은 비밀번호가 아니라 토큰입니다. 화면 안내에도 "승인은 이 패널에서 이루어지며, 비밀번호는 클라이언트에 전달되지 않습니다."라고 적혀 있습니다. 소셜 계정의 비밀번호는 패널 자체가 가지고 있지 않으므로 더더욱 전달될 일이 없습니다.
어시스턴트가 제 승인 없이 주문을 넣을 수 있습니까?
서버는 모델에게 주문 전에 반드시 명시적 승인을 받도록 지시합니다. 다만 지시는 지시일 뿐이고 완전한 보장은 아닙니다. 확실하게 막고 싶다면 승인 화면에서 "조회 전용 권한만 부여(주문 불가)"를 선택하십시오. 그러면 주문 관련 도구가 그 연결의 도구 목록에서 아예 사라지므로 호출 자체가 불가능해집니다.
어떤 AI 클라이언트를 쓸 수 있습니까?
OAuth 2.1을 지원하는 MCP 클라이언트라면 종류를 가리지 않습니다. 패널 화면에는 명령줄 도구용 등록 명령, 편집기용 설정 파일 형식, 헤더로 API 키를 보내는 방식, 그리고 확인용 명령 예시가 함께 실려 있습니다. 헤더를 보낼 수 있는 클라이언트라면 OAuth 대신 API 키로도 연결할 수 있습니다.
연결을 끊으면 어떻게 됩니까?
AI 어시스턴트 페이지의 "연결된 어시스턴트" 목록에서 "연결 해제"를 누르면 그 클라이언트가 가진 토큰이 즉시 무효가 됩니다. 접근 토큰의 남은 시간과 관계없이 바로 끊깁니다. 확인 문구는 "이 어시스턴트의 계정 접근 권한이 사라집니다. 계속할까요?"이고, 완료되면 "연결이 해제되었습니다."가 표시됩니다. 다시 쓰려면 처음부터 승인 절차를 다시 밟아야 합니다.
접근 토큰은 얼마나 유효하며 매번 다시 연결해야 합니까?
접근 토큰은 8시간 동안 유효하고 갱신 토큰은 90일입니다. 갱신 토큰은 쓸 때마다 새 값으로 바뀝니다. 정상적인 클라이언트는 만료를 감지해 자동으로 새 접근 토큰을 받아 오므로 여러분이 손댈 일은 없습니다. 다시 승인 화면을 보게 되는 경우는 대체로 연결을 직접 끊었거나 토큰 재사용이 감지되어 연결 전체가 폐기된 경우입니다.
어시스턴트가 잔액을 충전해 줄 수 있습니까?
없습니다. 잔액 충전, 출금, 가격 변경, 고객지원 문의 작성은 이 도구들로 할 수 없습니다. 해당하는 도구 자체가 존재하지 않기 때문에 권한 문제가 아니라 기능이 없는 것입니다. 서버 지시문도 그런 요청이 오면 사용자를 패널로 안내하도록 되어 있습니다.
API 키와 OAuth 중 무엇으로 연결해야 합니까?
대화형 어시스턴트 앱이라면 OAuth 쪽이 편합니다. 키를 복사해 옮길 필요가 없고, 조회 전용으로 제한할 수 있으며, 패널에서 버튼 하나로 끊을 수 있습니다. 서버나 봇, 스크립트처럼 헤더를 직접 실어 보내는 환경이라면 API 키가 간단합니다. 다만 키로 연결한 세션은 언제나 전체 권한이라는 점을 기억하십시오. 읽기만 시키고 싶다면 키가 아니라 OAuth를 쓰셔야 합니다.
어시스턴트가 넣은 주문을 패널에서도 볼 수 있습니까?
볼 수 있습니다. 어시스턴트가 만든 주문은 화면에서 만든 주문과 완전히 같은 주문이며 "내 주문" 목록에 그대로 나타납니다. 상태 변화, 부분 완료 환불, 리필과 취소 규칙도 동일하게 적용됩니다. 여기에 더해 모든 도구 호출이 별도 기록에 남기 때문에, 어떤 주문이 어시스턴트를 통해 들어왔는지 나중에 구분할 수 있습니다.
하위 패널 고객도 자기 어시스턴트를 연결할 수 있습니까?
가능합니다. 같은 페이지가 그 패널의 도메인에서 그대로 동작하고, 연결 주소도 그 도메인으로 표시됩니다. 인증 관련 주소가 모두 요청이 들어온 도메인에서 만들어지므로 메인 패널 주소는 고객에게 노출되지 않습니다. 다만 계정은 만들어진 도메인에서만 유효하므로, 연결이 되지 않는다면 도메인이 맞는지부터 확인해 보십시오.
도구가 오류를 돌려주면 어떻게 됩니까?
프로토콜 오류로 처리되지 않고, 오류 표시가 붙은 텍스트로 어시스턴트에게 전달됩니다. 그래서 모델이 내용을 읽고 스스로 값을 고쳐 다시 시도할 수 있습니다. 오류 코드는 고정되어 있고 메시지는 여러분의 언어로 나옵니다. 서버 지시문은 모델에게 그 메시지를 그대로 전달하고 없는 해결책을 지어내지 말라고 요구합니다.
MCP를 쓰면 추가 요금이 붙습니까?
주문 자체의 금액 외에 별도로 붙는 요금은 없습니다. 어시스턴트를 통해 넣은 주문이든 화면에서 넣은 주문이든 계산 방식이 같습니다. 다만 여러분이 쓰는 AI 클라이언트 쪽에 자체 요금 정책이 있을 수 있으며, 그 부분은 패널과 무관합니다. 보장 범위와 이용 조건은 자주 묻는 질문과 이용약관 페이지에 정리되어 있습니다.