AI 에이전트와 폐쇄형 API: Dodo Pizza 사례

AI 에이전트가 상용 API를 재정의하는 방법: 오픈 인터페이스 없이 도도 피자와 통합한 사례 연구

AI 에이전트는 더 이상 단순한 개념이 아닙니다. 이미 프로덕션 환경에서 장바구니에 상품 추가, 보너스 잔액 조회, 결제 확인, 주문 접수 등 거래 관련 작업을 처리하고 있습니다. 핵심 기술적 과제는 공개 API를 제공하지 않는 서비스와의 상호작용입니다. 이번 도도 피자 사례는 개발자가 폐쇄형 RESTful 인터페이스 위에 완전히 기능하는 에이전트 스킬을 구축하고, 헤드리스 브라우저를 활용해 WAF 및 안티봇 방어를 우회하면서도 엄격한 데이터 프라이버시와 이용약관 준수를 유지한 사례를 보여줍니다.

에이전트 아키텍처: CLI에서 컨텍스트 기반 스킬로

이 시스템은 클라우드 코드, 키미클로, 오픈클로 등 에이전트 프레임워크용 확장 가능한 스킬로 설계되었으며, 외부 도구를 지원하는 모든 인터페이스와 호환됩니다. 음성 어시스턴트가 정보 조회에 국한되는 반면, 이 에이전트는 상태를 유지하는 작업을 수행합니다: 장바구니 관리, 픽업 지점 선택, 저장된 쿠키를 통한 이중 인증, 그리고 자금이 차감되기 전 결제 확인까지 말이죠.

핵심 원칙은 책임 분담입니다:

• 에이전트 인터페이스 — 깔끔한 자연어 인터페이스: “소시지 피자와 레모네이드 주문해”, “최근 세 번의 주문 내역 보여줘”;
• 실행 로직 — 에이전트 러너에 의해 트리거되는 Node.js 스크립트(dodo.mjs);
• 네트워크 상호작용 — 오직 헤드리스 크롬(퍼펫리어)을 통해 실제 사용자 행동을 모방합니다.

에이전트는 HTML을 파싱하지 않습니다. 대신 클라이언트 측 검사를 모두 통과한 후 로드된 페이지 컨텍스트 내에서 사이트의 내부 API로 fetch() 요청을 보냅니다. 서버 입장에서는 일반 사용자 트래픽처럼 보입니다: 동일한 User-Agent, 동일한 쿠키, 동일한 navigator.webdriver === false, 동일한 리소스 로딩 순서.

폐쇄형 API 역공학 및 탐지 방지

30개 이상의 엔드포인트 문서는 Chrome DevTools Protocol을 통해 네트워크 트래픽을 스니핑하여 확보했습니다. 스크립트는 메뉴 탐색부터 최종 주문 완료까지의 전체 사용자 시나리오 동안 /api/가 포함된 모든 fetch 및 XHR 요청을 가로챕니다. 이를 통해 GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses 등 엔드포인트의 완전한 맵을 얻었습니다.

주요 기술적 난관과 그 해결책:

• Webdriver 탐지: ServicePipe가 navigator.webdriver를 확인합니다. 해결책: 퍼펫리어 실행 옵션에 한 줄 추가 — --disable-blink-features=AutomationControlled — 그리고 런타임 중 수동 속성 교체.
• JS-챌린지: 사이트는 page.goto() 직후 바로 캡차 작업을 표시합니다. 에이전트는 <title>에 “delivery”라는 단어가 나타날 때까지 기다립니다 — SPA 로딩 성공의 지표입니다.
• 로그인 시 reCAPTCHA v3: 소프트웨어적 해결책은 없습니다. GUI가 활성화된 기기에서 한 번 수동으로 인증을 진행한 후 쿠키를 파일에 저장하고 서버로 전송합니다. 유효기간: 30일; 자동 로테이션은 구현되지 않았습니다.
• Canvas/WebGL 지문 식별: 아직 활성화되지는 않았지만, 아키텍처상 향후 puppeteer-extra-plugin-stealth와의 통합이 가능합니다.

이 모든 조치 덕분에 4개월간 실패나 차단 없이 안정적으로 운영되었습니다.

스킬에서 에이전트 경제로: 안전한 인증과 서비스 간 오케스트레이션

현재 에이전트는 ‘한 사용자—한 계정—한 서비스’ 모델로 운영됩니다. 그러나 확장 가능한 모델을 위해서는 표준화된 에이전트 식별이 필요합니다. 통신사 ID를 신원 제공자로 활용하는 방안이 제안됩니다: MTS ID, Sber ID 또는 Tinkoff ID는 여권과 SIM 카드를 통해 이미 신원을 확인합니다. OAuth와 유사한 에이전트 토큰 체계:

• 사용자는 통신사 ID를 통해 한 번 인증합니다;
• 통신사는 명시된 범위의 JWT를 발급합니다: orders:dodo:read, orders:dodo:write, limit:2000rub/day;
• 도도는 토큰 서명을 검증하고 범위를 확인한 후 작업을 실행합니다;
• 액세스 취소는 통신사 모바일 앱을 통해 즉시 이루어집니다.

이렇게 하면 쿠키 저장과 수동 인증이 필요 없어져 기업이 권한과 분석을 직접 관리할 수 있게 됩니다.

더욱 유망한 것은 마스터 에이전트 모델입니다. 여러 스킬을 동시에 조율합니다:

마스터 에이전트:
├── 도도 스킬 → 스파이시 소시지 25cm — 369₽ (15분 픽업)
├── 마그니트 스킬 → 굿 콜라 1.5L — 89₽ (30분 배송)
└── 결론: “도도에서 피자를 픽업하고, 마그니트에서 콜라를 주문하세요.
   66₽ 절약하고, 콜라 양은 세 배로 늘리세요. 괜찮아요?”

이런 에이전트는 A2A(Agent-to-Agent) 프로토콜을 사용합니다: 각 서비스는 자신의 기능을 기계가 읽을 수 있는 형식으로 공개합니다(예: OpenAPI 3.1 포맷에 x-agent-capabilities 확장). 에이전트들은 수동 통합 없이 동적으로 서로를 발견합니다.

무엇이 중요한가

• 에이전트는 이미 프로덕션 환경에서 사용되고 있습니다: 주문 작성자는 2025년 12월부터 이를 주요 주문 방식으로 사용해 왔습니다 — 이것은 PoC가 아니라 작동하는 솔루션입니다.
• 폐쇄형 API는 실제 사용자 행동을 모방하고 이용약관을 위반하지 않는다면 헤드리스 브라우저를 통해 합법적으로 사용할 수 있습니다(자신의 계정에서 자신의 행동을 자동화하는 경우).
• 기업이 에이전트 트래픽을 무시하면 통제력과 분석 능력을 잃게 됩니다: 현재 통합은 지표상 스크래퍼와 구분이 불가능합니다.
• 전용 에이전트 준비 API는 선택이 아니라 경쟁 우위입니다: CAC를 제로로 낮추고, 마켓플레이스 수수료를 없애며, 맞춤형 프로모션을 위한 채널을 열어줍니다.
• 개인화는 클라이언트 측에 있어야 합니다: 에이전트는 주문 내역, 예산, 선호를 알고 있으므로 기업은 깔끔하고 문서화된 API만 제공하면 됩니다.

구현: JavaScript 380줄, 의존성 하나(puppeteer-core), 단일 명령으로 설치. 윤리적 이유로 코드는 오픈소스로 공개되지 않습니다: 특정 서비스의 안티봇 조치를 우회하려면 API 소유자와 협의가 필요합니다. 이 글의 목적은 우회 방법을 알려주는 것이 아니라 에이전트 인터페이스 표준화에 대한 대화를 촉진하는 것입니다.

— Editorial Team