Agents that can pay: building Restock with Stripe's Link and Managed Deep Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Restock은 Slack의 Managed Deep Agents에서 상품 검색부터 실제 주문까지 수행하며, Stripe의 Link와 Machine Payments Protocol(MPP), 사용자 승인 및 코드로 통제되는 지출 한도를 결합한 결제 에이전트 예제다.

📌 핵심 요약

• Restock은 사무용품 구매용 샘플 에이전트로, Managed Deep Agents(MDA)가 Slack 연동·사용자 검토·자격 증명·상태 저장을 담당하고 Zinc가 상품 검색과 소매업체 주문을 처리한다. Link는 사용자의 결제 수단을 보관하며, MPP는 HTTP의 402 Payment Required 응답과 결제 자격 증명을 통한 재요청으로 결제를 진행한다.
• 예시 요청은 총 $25 미만의 파란색 잉크 펜 12개 묶음 구매다. 사용자가 선결제액 $23을 선택하면 Zinc의 기본 수수료 $1을 제외한 $22가 상품·세금·배송비의 한도가 된다. 소매업체 주문액은 $21.18이고 수수료 포함 최종 지출은 $22.18이며, 나머지 $0.82는 환불된다. 이 가격들은 설명용 예시다.
• 사용자는 Slack에서 장바구니·사무실 표시·수수료·선결제액을 검토하고, 이어 Link 웹사이트에서 결제를 별도로 승인한다. 모델은 카드 번호나 결제 비밀정보를 다루지 않으며, 지출 한도와 승인 통제는 모델이 변경할 수 없는 코드에 둔다. 결제 도구는 승인된 주문과 실제 주문의 일치 여부 및 승인 유효성도 확인한다.
• MPP 지원 API를 이용하면 브라우저 결제의 페이지 변경·자동화 차단 문제를 피할 수 있지만, 구매 가능한 범위는 MPP 지원 API로 제한된다. Restock은 Zinc가 order_placed를 보고해야 주문을 확정하며, 글의 설명용 가격과 별개로 실제 호스팅 배포에서 주문 완료와 예상 환불을 확인했다.
• 코드는 langchain-samples/restock-agent에 공개되어 있으며, RESTOCK_MODE로 rehearsal, link-test, live를 순서대로 시도할 수 있다. rehearsal은 가상 상품과 모의 승인, link-test는 실제 Zinc 검색과 실제 Link 승인만 수행하며 구매하지 않고, live는 실제 결제와 주문을 수행한다. 샘플은 미국 배송·USD만 지원하고 배포당 사무실 하나와 요청자 본인 지갑으로 제한된다.

🧩 주요 포인트

1. MPP의 명시적인 결제 교환 → 브라우저 화면에 의존하는 결제를 줄이지만, 도입 가능 범위는 MPP 지원 API의 상품·서비스 범위에 좌우된다.
2. Slack 구매 검토와 Link 결제 승인, 코드의 지출 한도 및 주문 일치·승인 유효성 확인 → 에이전트의 상품 선택 권한과 실제 자금 집행 권한을 분리한다.
3. rehearsal → link-test → live의 단계적 실행과 order_placed 기반 확정 → 모의 실행, 지갑 승인, 실제 주문을 구분해 검증할 수 있으나 미국 배송·USD·배포당 사무실 하나·요청자 본인 지갑이라는 적용 제약이 있다.

🧠 상세 정리

1. 상품 탐색에서 실제 결제로 넘어갈 때의 문제

글은 에이전트가 구매할 물건을 찾는 데는 이미 능숙하지만, 결제는 실제 돈을 이동시키고 모델에 노출해서는 안 되는 자격 증명을 요구하며 되돌리기 어렵다는 문제에서 출발한다. 이를 보여 주기 위해 만든 Restock은 Slack에서 Managed Deep Agents로 실행되는 사무용품 구매 샘플로, 실제 상품을 검색하고 장바구니를 만든 뒤 Stripe의 소비자 지갑인 Link로 결제한다. 사례의 요청은 사무실용 파란색 잉크 펜 12개 묶음을 총 $25 미만으로 구매하는 것이며, 글은 최초 요청부터 주문 확정까지의 과정을 따라간다. Restock의 수수료 포함 최종 지출은 $22.18로 제시되지만, 글에 나온 가격은 모두 설명을 위한 예시라는 점을 명시한다.

2. MPP 결제 방식과 네 구성요소의 역할

에이전트가 브라우저에서 소매업체의 결제 화면을 조작하는 방식은 페이지 변경, 자동 결제 차단, 결제정보를 모델에 노출하지 않고 입력해야 하는 문제 때문에 취약하다고 설명한다. MPP 지원 API는 결제할 금액을 명시하고 직접 결제를 받지만, 에이전트가 구매할 수 있는 범위가 해당 API를 지원하는 곳으로 제한되는 절충이 있다. 글은 지원 범위가 확대되고 있다며 도구 집계 서비스인 Apify와 Mercator, 소매 분야의 Zinc를 언급하고, Restock이 Zinc를 사용하더라도 전체 패턴이 Zinc에 종속되지는 않는다고 설명한다. 구성요소는 결제 수단 보관과 승인을 맡는 Link, HTTP 결제 교환을 정의하는 MPP, 상품 검색과 소매업체 주문을 맡는 Zinc, 실행 환경과 Slack·사용자 검토·자격 증명·저장 상태를 관리하는 Managed Deep Agents다. MPP에서는 판매자가 402 Payment Required와 결제 지침을 반환하고, 클라이언트가 결제 자격 증명을 포함해 요청을 다시 보낸다.

3. 상품 검색, 장바구니 저장과 선결제액 산정

Restock은 Zinc 검색, 장바구니, 결제를 위한 사용자 정의 도구와 대화·도구 사용 지침을 갖추며, MDA가 대화와 주문을 저장해 며칠 뒤에도 같은 펜 주문을 문의할 수 있도록 한다. 상품 검색에는 Zinc API 키와 잔액이 충전된 검색 계정이 필요하고, 검색 비용은 Link로 결제하지 않으며, 사용자가 12개 묶음을 선택하면 결제액이 없는 상태로 장바구니를 저장한다. Restock은 $25 예산을 청구액이 아닌 상한으로 취급하는데, 상품 목록만으로는 세금과 배송비를 알 수 없고 최종 합계는 소매업체 주문이 들어간 뒤 확정되기 때문이다. 사용자가 상한 이내에서 선결제액 $23을 선택하면 Zinc가 주문 접수 시 이를 받아 소매업체에 지급하고 잔액을 환불하며, 기본 수수료 $1을 제외한 $22가 상품·세금·배송비에 쓰일 수 있다. 이메일 주문 알림 같은 선택 수수료는 이 한도를 더 줄일 수 있으므로, Restock은 사용자 검토 전에 결제 없이 주문 요청을 보내 Zinc의 402 Payment Required 응답에서 실제 수수료를 읽는다.

4. 자격 증명 격리와 Slack의 구매 검토

주문에 사용되는 결제 비밀정보는 모델이 다루지 않으며, Link 세션은 사용자 소유의 MDA Connection에 저장되어 각 사용자의 지갑이 본인에게 귀속되도록 한다. 배송 주소, 알림 이메일, Zinc API 키는 에이전트 소유 Connection에 보관하고, Link CLI는 MDA의 관리형 샌드박스 안에서 로그인을 수행한다. 작은 보조 프로그램이 저장된 세션을 사용자 Connection에 유지하다가 명령 실행 중에만 샌드박스에 배치하며, Link 연결 자체는 구매 승인이 아니고 이후 대화에서도 같은 세션을 재사용한다. 결제 전 사용자는 Slack에서 장바구니, 사무실 표시, 수수료와 선결제액을 검토하지만 배송 주소는 비공개로 유지된다. Restock은 interrupt를 발생시켜 사용자가 Slack에서 Approve 또는 Reject를 누를 때까지 실행을 멈추며, 모델이 도구 호출에 어떤 내용을 작성하더라도 이 승인을 대신할 수 없다.

5. Link 승인과 결제 도구의 추가 검증

Slack의 구매 검토 다음에는 Zinc의 결제 요청에 제시된 정확한 금액인 $23에 대한 Link 승인 링크를 같은 Slack 대화에 게시한다. 사용자는 Link 웹사이트에서 이를 승인하며, 이는 Slack의 구매 검토와 별개인 지갑 자체의 결제 동의다. 승인이 완료되면 Restock은 Link의 shared payment token을 자격 증명으로 포함해 Zinc에 결제된 요청을 보내고, Zinc는 Stripe를 통해 결제를 처리하며 pympp가 MPP 형식을 담당한다. 결제 도구는 비공개 샌드박스 파일에서 토큰을 읽어 사용 후 삭제하고 모델에는 공개 가능한 요약만 반환한다. 토큰 자체가 장바구니의 세부 내용을 강제하지는 않으므로, 도구는 실제 주문이 사용자가 검토한 주문과 일치하는지와 승인이 여전히 유효한지도 확인한다.

6. 최종 비용, 환불과 판매자 기준 주문 확정

예시의 소매업체 주문액은 펜 가격 $14.99, 세금 $1.20, 배송비 $4.99를 합한 $21.18로, Zinc 기본 수수료를 제외한 $22 한도 안에 들어간다. 여기에 Zinc 수수료 $1을 더하면 사용자의 최종 지출은 $22.18이 되고, 선결제한 $23 가운데 남은 $0.82는 Zinc가 환불한다. 따라서 $25 예산, Link에서 승인한 $23, 수수료 포함 최종 지출 $22.18은 서로 다른 단계의 금액이다. Restock은 Zinc가 order_placed를 보고한 뒤에만 Slack에서 주문을 확정하고, 소매업체가 배송하면 추적 정보를 공유한다. 글은 가격 예시와 별도로 호스팅 배포에서 전체 흐름을 실제 실행했으며, 실제 주문이 order_placed에 도달하고 예상 환불도 이루어졌다고 보고한다.

7. 실행 모드, 샘플의 제약과 일반화 가능한 원칙

샘플 코드는 langchain-samples/restock-agent에 있으며 README가 설정과 배포를 단계별로 설명하고, MDA의 Slack 설정 가이드는 Slack 앱 연결을 안내한다. Restock은 미국 배송과 USD만 지원하며, 배포당 사무실 하나와 요청자 본인 지갑의 결제로 제한된다. RESTOCK_MODE의 rehearsal은 가상 상품과 모의 승인을 사용하며 OpenAI API 키와 Managed Deep Agents 접근 권한이 있는 LangSmith 워크스페이스가 필요하다. link-test는 실제 Zinc 검색과 실제 Link 승인을 수행하되 구매하지 않으며, Link 지갑·Zinc API 키·잔액이 충전된 Zinc 검색 계정·배송 정보가 추가로 필요하고, live는 실제 결제와 소매업체 주문을 수행한다. 글은 이 세 모드를 순서대로 시도하도록 제안하면서, 돈을 쓰는 다른 에이전트에도 상품 탐색과 장바구니 구성은 맡기되 지출 한도와 승인은 모델이 건드릴 수 없는 코드에 두고 판매자의 확인이 있어야 주문 완료로 판단하는 원칙을 제시한다.

🧾 핵심 주장 / 시사점

• 결제 안전성은 Link가 결제정보를 보관하는 것만으로 완성되지 않는다. Slack의 구매 검토, Link의 결제 동의, 도구의 주문 일치 및 승인 유효성 검증이 함께 작동해야 한다.
• 예산 상한, 선결제액, 최종 지출을 구분해야 세금·배송비가 나중에 확정되는 주문을 설명할 수 있다. Restock의 예시는 $25 상한 안에서 $23을 승인받고 $22.18을 지출한 뒤 $0.82를 환불하는 흐름이다.
• MPP는 결제 절차를 명시적으로 만들지만 지원 API의 범위가 구매 가능성을 결정한다. 또한 결제 승인만으로 주문 성공을 판단하지 않고 Zinc의 order_placed를 확인하는 것이 이 구현의 핵심 원칙이다.

✅ 액션 아이템

• Restock 적용 시 Slack 구매 검토, Link 결제 승인, 코드의 지출 한도 및 주문 일치·승인 유효성 확인을 함께 점검한다.
• RESTOCK_MODE를 rehearsal → link-test → live 순서로 실행하며 모의 승인, 실제 Link 승인, 실제 결제·주문을 단계별로 검증한다.
• 도입 대상이 MPP 지원 API로 구매 가능한지와 미국 배송·USD·배포당 사무실 하나·요청자 본인 지갑 제약에 부합하는지 확인한다.

❓ 열린 질문

• 도입하려는 상품과 서비스의 구매 범위를 MPP 지원 API가 충분히 제공하는가?
• Restock의 미국 배송·USD·배포당 사무실 하나·요청자 본인 지갑 제약이 실제 사용 환경에 부합하는가?
• Slack 구매 검토와 Link 결제 승인 이후에도 코드의 지출 한도, 주문 일치·승인 유효성 확인, order_placed 기반 확정이 일관되게 작동하는가?