Poppy란 무엇이며, 언제 API가 고객 에이전트를 지원해야 할까요?

Poppy는 Personal Agent Protocol의 약어입니다. 이 프로토콜은 개인 에이전트와 기업이 함께 작동하는 방법에 대한 개방형 프로토콜로 정의합니다. Sierra와 Meta가 업계 파트너들과 개발하고 있으며(https://sierra.ai/blog/introducing-personal-agent-protocol), 사양은 2026년 10월 9일 업데이트된 draft 0.1입니다(https://personalagentprotocol.org/docs/spec). 2026년 10월 12일 기준으로 볼 때, 대부분의 소비자 대상 API 플랫폼에게 가장 적절한 접근 방식은 고객 에이전트 채널이 필요로 하는 구성 요소를 구축하는 동안 진행할 수 있는 작고 일회성 실험이며, 프로덕션 배포는 아닙니다.

Sierra 계정에 따르면, 대부분의 개인 에이전트는 이미 사람들이 하는 방식대로 회사 웹사이트와 앱을 사용합니다. 즉, 페이지를 로드하고 양식을 클릭하며 진행하며, 이것만으로는 작업을 완료할 수 없을 때 지원 전화나 웹 채팅을 열어봅니다. 이 프로토콜 개요는 이를 '전부 아니면 전무(all or nothing)'라고 부릅니다. 에이전트가

• Poppy는 고객의 개인 에이전트와 회사 사이에 존재하는 동의 및 세션 계층입니다. 이는 회사의 API, MCP 서버, 웹사이트 또는 회사 에이전트를 채널로 재사용합니다.
• 2026년 10월 12일 기준으로, 이 사양은 브레이킹 체인지가 허용된 draft 0.1이며, 공식적인 레퍼런스 구현체는 공개되지 않았고, 현재까지 상업적 도입에 대한 공개 증거를 찾지 못했습니다.
• OAuth API와 MCP 서버만으로도 이미 범위가 지정된 위임 권한 부여(scoped delegated authorization)가 제공됩니다. draft 0.1은 로그아웃 세션(signed-out Sessions), 허용 및 차단 목록을 갖춘 사용자별 에이전트 속성(per-User agent attribution), 키 바운드 토큰(key-bound tokens), 인간 핸드오프(human handoff), 그리고 로그아웃 시 취소(revocation back to signed out) 기능을 추가합니다.

고객의 에이전트가 플랫폼으로부터 필요로 하는 것들

사양에서 말하는 고객의 에이전트는 개인 에이전트(personal agent)입니다. 이는 새로운 종류의 클라이언트이며, 다음 여섯 가지가 필요합니다: 디스커버리(discovery)(채널 위치 및 로그인 방법), 권한 부여(authorization)(고객이 허용한 범위), 하나의 에이전트와 하나의 고객에 연결된 범위 지정 세션(scoped Sessions), 인간에게 전달할 경로(a route to a human), 로그아웃하지 않은 고객을 위한 개인 정보 보호(privacy for a customer who has not signed in), 그리고 동작할 장소입니다. 현재의 방식은 이 중 마지막 것만 다룹니다. 고객의 비밀번호를 가진 브라우저 에이전트는 당신에게 고객처럼 보입니다. MCP의 권한 부여 사양은 도구에 대한 범위 지정 OAuth를 제공하지만, 로그아웃 세션, 개인 데이터를 갖지 않은 회사별 사용자 ID(per-company User ID), 인간 핸드오프, 그리고 채널 전반에 걸쳐 공유되는 세션을 정의하지 않습니다. Poppy는 이 여섯 가지 모두를 하나의 문서화된 인터페이스 뒤에 배치합니다.

Poppy 요청이 종단 간(end to end)으로 흐르는 방식

draft 사양은 한 에이전트가 디스커버리부터 로그아웃까지 다음 순서로 이동하는 과정을 설명합니다 (draft 0.1이므로 모든 단계는 변경될 수 있습니다):

Diagram: a Poppy session in six steps from personal agent to company. Start with poppy.json, signed out; sign in with poppy:read or poppy:write; key-bound token that lasts hours; act through an API, MCP server, website, or company agent; hand off to a person; revoke, which returns to signed out.

draft 0.1 세션 수명 주기, 요약.

1. 발견(Discover). "회사는 HTTPS를 통해 https://{domain}/.well-known/poppy.json에 자신의 poppy.json 문서를 게시해야 합니다." 이 문서에는 로그인 옵션(auth)과 채널(agent, apis, web)이 나열됩니다.
2. 에이전트 식별(Identify the agent). "개인 에이전트의 client_id는 메타데이터 문서를 반환하는 HTTPS URL이어야 합니다." 사전에 등록을 요구하거나 client_id를 이용해 허용 목록 또는 차단 목록을 유지할 수 있습니다.
3. 로그아웃 상태로 시작(Start signed out). 에이전트는 자신의 이름(iss)과 사용자(sub)를 명시하여 서명된 단언(JWT bearer grant)을 귀하의 token_endpoint로 전송합니다. "세션은 로그아웃 상태로 시작됩니다": 시간이 지나도 동일한 사용자를 인식할 수 있지만, 그 사용자가 누구인지는 알 수 없습니다. 사용자 ID는 "이메일 주소, 전화번호 또는 이름과 같은 개인 정보로부터 포함되거나 파생되어서는 안 됩니다."
4. 로그인 및 범위 부여(Sign in and grant scope). 로그인은 직접적(

에이전트는 귀하의 revocation_endpoint에서 계정 토큰(Account Token)을 취소하며, 해당 토큰으로 로그인된 모든 세션(Session)에서 로그아웃됩니다: “보통 이러한 세션들은 계속 로그아웃 상태를 유지하여 장바구니나 진행 중인 대화가 이어집니다.” 실패 시에는 invalid_token (401), sign_in_required (403), insufficient_scope (403), invalid_session (400), 또는 account_mismatch (400)이 반환됩니다.

Poppy 대 MCP 대 A2A

마지막 열은 오늘날의 브라우저 에이전트를 나타냅니다. 버전: Poppy draft 0.1, MCP 스키마 2026-07-28, 그리고 A2A 1.0.0이며, 기준일은 2026년 10월 12일입니다.

레이어는 다음과 같이 쌓입니다: Poppy가 어떤 에이전트가 요청하고 고객이 무엇을 허용했는지 결정하며, MCP 서버는 그 에이전트가 라우팅할 수 있는 하나의 채널입니다.

A2A와 Poppy의 관계는 불분명합니다. Poppy 사양(spec)이나 Sierra의 게시물 어디에도 A2A에 대한 언급이 없기 때문에 이를 정의하는 주요 출처가 없습니다. 독립적인 트래커인 poppy.md는 이 둘을 "대부분 상호 보완적이며, 주의 깊게 살펴볼 한 가지 중복 지점: '회사 에이전트(company agent)' 경로"라고 설명합니다(https://poppy.md/compare). A2A 기반의 설계는 2026년 10월 6일에 공개된 Decagon의 PACT (Personal Agent Consent & Trust Protocol)입니다. 이 날은 Sierra가 Personal Agent Protocol을 발표한 날과 같은 날이며, PACT는 "Agent2Agent 프로토콜 및 OAuth 2.0을 기반으로 구축되었습니다."라고 설명합니다. Decagon에 따르면 PACT는 "Meta의 Muse 팀이 발표한 Personal Agent Protocol 워킹 그룹에 합류"한다고 하지만, Poppy 사양 텍스트에는 PACT에 대한 언급이 없습니다. A2A 자체의 실제 구현상의 격차(production gaps)에 대해서는 A2A 생산 준비 상태: 프로토콜 지원을 넘어 필요한 것들을 읽어보세요.

2026년 10월 12일 기준 Poppy의 현황

성숙도(Maturity), 구현체(implementations), 채택(adoption)은 별개의 주장입니다.

초안 성숙도. 사양의 상태 표시줄은 Draft 0.1이며, 2026년 10월 9일에 업데이트되었습니다. 이 사양은 Apache License 2.0 하에 있으며, "안정 버전 이전에는 어떤 부분이든 변경될 수 있으며, 이는 하위 호환되지 않는 방식으로 이루어질 수도 있습니다."라고 경고합니다. 사양, 개요 또는 홈페이지 어디에도 편집자, 거버넌스 기구 또는 표준화 기관의 이름이 보이지 않습니다.

구현 사례(Implementations). 10월 9일, Sierra는 "다음 달에 디자인 워크숍을 개최하고 개발자들이 시작하는 데 도움이 되는 레퍼런스 구현체를 공개할 예정입니다."라고 작성했습니다. 10월 12일 기준으로 독립 트래커 poppy.md는 공식 레퍼런스 구현체에 대해 "아직 공개된 것이 없다"고 명시하고 있습니다. 이 목록에는 Cloudflare Workers 데모, X 비디오에서만 보이는 Meta의 Muse 데모, 그리고 'draft 0.1 (2026-10-09)'를 구현한 독립적인 Datalayer SDK와 같은 커뮤니티 및 파트너 데모 작업만 나열되어 있습니다.

상용 채택(Production adoption). 이에 대한 공개 증거는 찾을 수 없었습니다. 10월 9일, orka 프로젝트는 출시 파트너를 포함하여 약 40개 사이트를 확인한 후 "PAP 파일이 게시된 회사는 없다"고 보고했습니다. Sierra의 10월 9일 게시물은 OpenAI, Visa, Mastercard, PayPal, Okta, Bank of America 등 35개의 디자인 파트너를 Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe, Walmart와 같은 출시 파트너에 추가했습니다. 디자인 파트너 상태는 구현체가 아니며, poppy.md는 10월 12일 기준으로 데모 외의 디자인 파트너 구현체는 나열하고 있지 않습니다. fillthemat 프로젝트의 GitHub 이슈에서 OpenAI가 디자인 파트너로 등재된 것에 대해 "이는 ChatGPT 지원이나 가맹점 트래픽을 확립하지 못합니다."라고 언급했습니다.

API 팀이 구축해야 할 것들

최소한의 요구 사항은 작습니다. 회사가 '에이전트(agent)', 'API', 또는 '웹' 중 하나를 구현하고, 로그인(sign-in)은 선택 사항입니다: "아무것도 없다면, 로그아웃된 세션만 제공합니다."

OAuth API와 MCP 서버가 이미 다음을 포함합니다:

• 스코프 위임 인증 (Scoped delegated authorization): MCP의 인증 사양(authorization spec)에 따라 보호된 서버는 'OAuth 2.1 리소스 서버' 역할을 수행하고, 클라이언트에게 어떻게 인증할지 알려주는 RFC 9728 메타데이터를 게시하며, insufficient_scope 발생 시 스코프를 상향 조정할 수 있습니다.
• 직접 로그인 및 기기(Device) 로그인: OAuth 서버가 PKCE와 기기 승인(device grant)을 실행하는 경우입니다. OpenAgents 팀은 다음과 같은 중복점을 발견했습니다: '이미 RFC 8414/9728 메타데이터, PKCE, 기기 흐름(coder login) 및 MCP 리소스 서버를 가지고 있습니다.'
• API 채널: apis에 나열된 MCP 서버는 Bearer 토큰을 사용하는 유효한 Poppy 채널입니다.
• URL 기반 에이전트 식별자 (Agent identity by URL): MCP의 인증 사양은 인증 서버와 MCP 클라이언트가 'OAuth Client ID 메타데이터 문서'를 지원해야 한다고 명시하며, 이 경우 클라이언트는 HTTPS URL을 client_id로 사용합니다.

Draft 0.1에는 다음 내용이 추가됩니다:

• 기존 엔드포인트를 가리키는 poppy.json 디스커버리 파일.
• 모든 토큰에 대한 에이전트 및 사용자 기여도(attribution), 그리고 client_id별 허용 목록 및 차단 목록.
• 사용자 ID가 개인 데이터에서 파생되지 않는, 에이전트의 서명된 증명서(signed assertion)로 시작하는 로그아웃 세션.
• 에이전트의 키를 보유하고 있음을 증명하는 DPoP (RFC 9449)를 사용하여 OpenAPI 호출 시 확인되는, 몇 시간 동안 지속되는 키 바인딩 세션 토큰.
• 브라우저 로그인 및 로그아웃 후 쿠키가 따라다니는 browser_session_endpoint를 포함하여 채널 전반에 걸친 단일 세션(One Session).
• 회사 에이전트를 제공하는 경우, 인력이 배치된 대기열(staffed queue)로 연결되는 핸드오프 및 종료 엔드포인트.
• 계정 토큰(Account Token)에 연결된 모든 세션을 로그아웃시키는 revocation_endpoint.
• 사용자가 설계하는 감사 기록(Audit records). 사양은 기여도(