지금까지 퍼널 최적화는 “버튼 위치·카피·단계 수”를 줄이는 게임이었습니다. 그런데 MCP(Model Context Protocol)가 들어오면 게임판이 바뀝니다. 자연어 지시가 곧바로 외부 시스템 실행(메일 발송, 인보이스 생성, 결제 요청)로 이어지면서, 사용자가 ‘앱 안에서’ 클릭해야만 전진하던 퍼널이 ‘대화/에이전트 호출’로 새로 열립니다.
dev.to의 통합 다이제스트(2026년 3월)는 이 변화를 두 축으로 보여줍니다. 하나는 Stripe가 정리한 에이전트 커머스 운영 교훈—상품 카탈로그 정규화, ms 단위 재고/가용성 체크, Scoped/Shared Payment Token 같은 결제 토큰화, 네트워크 단위 사기 신호 등—으로 “에이전트가 거래를 망치지 않게 만드는 인프라 표준”이 빠르게 정리되고 있다는 점입니다. 다른 하나는 Machine Payments Protocol(MPP)처럼, 에이전트가 pay-per-call·마이크로 트랜잭션을 ‘기계 친화적으로’ 주고받는 길이 열린다는 신호입니다. 즉, 구매 퍼널의 입구가 웹/앱 UI가 아니라 프로토콜 레이어로 내려갑니다.
여기에 dev.to의 SendLayer 사례는 ‘실행’의 임계점을 더 낮춥니다. Codex 같은 에이전트 환경에서 MCP 서버를 붙이면, 개발자는 코드로 이메일 API를 엮지 않아도 “이메일 보내줘” 같은 자연어 명령으로 트랜잭션 메일을 즉시 실행합니다(설정도 bearer token env로 끝). 이건 단순 편의가 아니라 성장 레버입니다. 온보딩 메일/결제 리마인드/휴면 깨우기 같은 리텐션 루프를 “마케터 티켓 → 개발 구현 → 릴리즈”가 아니라 “가설 → 실행 → 이벤트 로그로 검증”의 짧은 사이클로 돌릴 수 있기 때문입니다.
핵심 맥락은 한 가지입니다. MCP는 ‘API를 더 쉽게 호출’하는 게 아니라, 에이전트가 워크플로우 단위로 실행하도록 인터페이스를 재조립합니다. 55개 툴로 ERP를 MCP 위에 올린 사례(dev.to의 Frihet 글)가 말하듯, 도메인/워크플로우 중심 툴 카탈로그(예: create_invoice, overdue_followup)가 준비되면 에이전트는 여러 엔드포인트를 체인으로 묶어 “행동”을 만듭니다. 이때 퍼널의 병목은 UI가 아니라 (1) 어떤 툴이 준비됐는지, (2) 어떤 권한/확인 단계가 있는지, (3) 어떤 구조화 출력으로 실패를 줄이는지가 됩니다.
시사점은 명확합니다. 첫째, 전환율은 ‘클릭 수’가 아니라 ‘실행 성공률’의 함수가 됩니다. 이메일/결제/인보이스/환불 같은 고가치 액션이 에이전트 경로로 들어오면, 실패·재시도·권한 오류가 곧바로 매출 누수입니다. 따라서 툴 입력/출력 스키마(구조화), 오류 분류(재시도 가능/불가), 관찰성(이벤트·트레이싱)을 성장 지표로 삼아야 합니다.
둘째, 온보딩과 리인게이지먼트가 ‘콘텐츠’에서 ‘거래’로 이동합니다. 예전엔 “환영 메일을 예쁘게”가 목표였다면, 이제는 “환영 → 설정 완료 → 첫 결제/첫 행동”까지를 에이전트가 끝내게 만드는 게 목표가 됩니다. 예: 사용자에게 긴 폼을 던지는 대신, “업종/규모/목표만 말하면” 에이전트가 플랜 추천→결제 링크 발급→세팅 체크리스트 메일 발송까지 실행. 이 흐름에서 D1/D7 리텐션은 UX 카피보다 ‘첫 가치 실현 시간(Time-to-Value)’이 얼마나 줄었는지로 갈립니다.
셋째, 머신 페이먼트 표준은 새로운 유저 세그먼트를 엽니다. 사람(카드 소유자)을 설득해 결제시키는 퍼널만이 전부가 아닙니다. 에이전트가 API 호출 단위로 비용을 지불하는 pay-per-call, 혹은 반복적인 소액 결제를 자동 집행하는 구조가 자리 잡으면, “개별 사용자의 결제 의사결정”이 아니라 “워크플로우의 실행 비용”이 수익화 단위가 됩니다. 이는 프리미엄 기능 판매가 막히던 B2B SaaS에도 새로운 ARPU/LTV 실험 공간을 만듭니다.
전망: 2026년은 MCP가 ‘연결’에서 ‘표준 운영’으로 넘어가는 해가 될 가능성이 큽니다. Stripe의 에이전트 커머스/MPP, Envoy를 기반으로 한 에이전트 네트워킹, MCP 프로덕션 플레이북(세션·SLO·OTel)까지 등장한 흐름은 “대충 붙여보는 자동화”가 아니라 “대규모 트래픽과 돈이 흐르는 자동화”를 전제합니다(dev.to 다이제스트).
성장 관점에서 다음 액션은 단순합니다. MCP를 ‘챗봇 기능’으로 두지 말고, 퍼널의 핵심 액션(메일·결제·구독·리마인드)을 툴로 쪼개고, 성공/실패 이벤트를 계측한 뒤, 에이전트 경로로 유입되는 코호트를 분리해 전환율·리텐션·CS 티켓 변화를 비교하세요. 퍼널은 이제 화면이 아니라 프로토콜에서 자동화되고, 그 자동화는 실험 가능한 성장 레버가 됩니다.