에이전틱 커머스, DoorDash가 보여준 앱 밖 주문의 다음 단계

앱을 열지 않고 AI가 주문한다: DoorDash가 보여준 에이전틱 커머스의 다음 단계

2026년 7월 24일
전략 분석

핵심 요약

에이전틱 커머스의 핵심은 AI가 상품을 “답변”하는 데 있지 않다. 사용자의 의도를 이해하고, 정해진 권한 안에서 검색·비교·장바구니·주문 같은 실제 업무를 연결하는 데 있다.
DoorDash의 대화형 어시스턴트와 AI 에이전트용 주문 도구는 앱 안의 기능 개선이면서 동시에, AI 인터페이스를 통해 주문이 시작되는 사례가 늘어날 가능성을 보여주는 초기 형태다.
이 변화에서 플랫폼의 경쟁력은 화면 설계만으로 결정되지 않는다. 가격·재고·배송 가능 여부·정책·결제 상태를 AI가 오해 없이 읽고 실행할 수 있게 제공하는 운영 데이터가 중요해진다.
광고와 검색의 중심도 클릭을 얻는 경쟁에서, 에이전트의 비교·추천·실행 과정에 신뢰할 만한 선택지로 들어가는 경쟁으로 일부 이동할 수 있다.
자동화의 목표는 사람을 빼는 것이 아니라, 승인·한도·취소·감사 기록을 갖춘 검증 가능한 실행을 만드는 일이다.

우리는 배달 앱을 여는 일을 너무 자연스럽게 받아들인다. 검색창에 음식 이름을 넣고, 식당을 비교하고, 옵션을 고르고, 결제 버튼을 누른다. 이 일련의 화면 이동은 오랫동안 플랫폼이 고객을 붙잡는 방식이었다. 앱을 열게 만들고, 더 오래 둘러보게 만들고, 그 안에서 추천과 광고와 멤버십을 작동시키는 구조다.

그런데 “오늘 저녁, 지난번처럼 맵지 않은 태국 음식으로 4만원 안에서 주문해줘. 7시 전에 도착해야 해”라고 말한 뒤, AI가 필요한 질문만 하고 후보를 좁혀 최종 승인 직전까지 일을 끝낸다면 무엇이 달라질까. 고객은 여전히 DoorDash나 배달 플랫폼의 공급망을 이용한다. 다만 일부 구매 과정에서는 그 플랫폼의 첫 화면을 직접 열지 않고도 거래가 시작되는 경험이 늘어날 가능성이 있다. 이 변화가 바로 에이전틱 커머스가 던지는 질문이다.

DoorDash 사례가 제품 뉴스보다 중요한 이유

이번 글에서 다루는 최신 발표의 핵심은 ‘dd-cli’다. DoorDash가 2026년 7월 공개한 개발자 베타(Developer Beta) 도구로, 개발자와 AI 에이전트가 별도의 앱 화면 없이 명령줄에서 곧바로 식당을 검색하고 장바구니를 구성하고 결제까지 마칠 수 있게 한다. 공개 시연에서는 Anthropic의 Claude가 dd-cli를 이용해 사람의 개입 없이 식당을 고르고 장바구니에 담아 결제를 완료하는 과정을 보여줬다. AI 에이전트가 이런 명령줄 도구를 실행하려면 결국 어딘가에서 셸을 띄우고 명령을 실행할 컴퓨팅 환경이 필요한데, AWS WorkSpaces처럼 에이전트 전용 업무 환경을 제공하려는 움직임도 같은 맥락에서 나온다. 현재는 미국·캐나다의 macOS 개발자를 대상으로 대기자 명단을 받는 초기 단계이며, DoorDash 공식 블로그나 뉴스룸의 정식 발표문보다는 앤디 팡(Andy Fang) 공동창업자 겸 CTO의 소셜 미디어 공지와 이를 다룬 언론 보도로 먼저 알려졌다는 점도 함께 밝혀 둔다. 출처: TechCrunch, Yes, you can now order DoorDash from the command line, DoorDash, dd-cli 공식 저장소(GitHub)

이 글에서는 dd-cli와 함께, 앞서 공개된 대화형 어시스턴트 ‘Ask DoorDash’, 그리고 훨씬 이전부터 존재해 온 물리적 실행 플랫폼 ‘DoorDash Tasks’를 함께 다룬다. 세 가지는 발표 시점도 성격도 다르다. dd-cli는 이번에 새로 공개된 개발자용 명령줄 도구이고, Ask DoorDash는 그보다 앞서 나온 소비자용 대화형 주문 기능이며, DoorDash Tasks는 이미 공개돼 있던, 에이전트가 사람(Dasher)에게 현실 세계의 작업을 맡기는 별도의 플랫폼이다. 셋을 하나의 발표로 뭉뚱그리지 않고, 에이전틱 커머스가 어떤 방향으로 확장되고 있는지를 보여주는 서로 다른 사례로 나눠 읽는 편이 정확하다.

DoorDash가 앞서 공개한 ‘Ask DoorDash’는 자연어 대화로 식당을 발견하고, 식사를 계획하고, 장보기 장바구니를 구성하도록 설계된 대화형 어시스턴트다. 알려진 구조의 요지는 언어 모델 하나가 모든 답을 만들어 내는 방식이 아니라, 전문화된 에이전트와 공용 도구 계층을 통해 카탈로그 검색, 추천, 장바구니, 결제, 주문 이력, 소비자 기억 같은 기존 사업 기능을 호출하는 데 있다. 즉 AI는 거래 시스템을 대체하는 새 백엔드가 아니라, 이미 존재하는 거래 시스템을 사용자의 의도에 맞춰 조합하는 실행 인터페이스에 가깝다. 출처: DoorDash 공식 엔지니어링 블로그, Building DoorDash Assistant: An Engineering Overview, InfoQ, DoorDash의 AI 쇼핑 어시스턴트 구축 전략 보도

이 차이는 실무적으로 크다. 전통적인 챗봇은 “근처에서 평점이 좋은 피자집을 알려줘”라는 질문에 목록을 보여주면 임무가 끝난다. 에이전트는 그 뒤에 남은 일을 다룬다. 위치를 확인하고, 영업 중인 매장을 찾고, 특정 메뉴의 품절 여부와 배달 예상 시간을 확인하고, 알레르기·예산·과거 선호를 반영하고, 장바구니를 구성하고, 사용자가 허용한 조건에서 주문을 생성한다. 마지막 결제나 변경 가능성이 큰 선택은 다시 사람에게 보여준다.

DoorDash의 사례를 “AI가 주문도 해주는 기능”으로만 읽으면, 중요한 산업적 함의를 놓치기 쉽다. 여기서 AI는 배달 플랫폼의 부가 기능인 동시에 소비자와 플랫폼 사이에 놓이는 새로운 조정 계층이다. 이 계층이 커질수록 사용자는 매번 수십 개의 식당·상품·요금제를 화면으로 비교하지 않아도 된다. 반대로 플랫폼은 사람에게 보기 좋은 목록뿐 아니라 AI가 정확히 비교하고 안전하게 실행할 수 있는 거래 능력을 제공해야 한다.

현재 사례가 곧바로 모든 주문 경로를 대체한다는 뜻은 아니다. 식당을 고르는 즐거움, 새 상품을 발견하는 과정, 쿠폰을 직접 비교하는 행동은 계속 남는다. 그러나 반복 구매, 시간 제약이 큰 구매, 조건이 복잡한 구매에서는 ‘탐색’보다 ‘완료’가 더 큰 가치를 가질 수 있다. 에이전틱 커머스는 이 두 경험이 상당 기간 공존하는 가운데, 실행이 필요한 순간의 비중을 넓혀 갈 가능성이 있는 변화다.

DoorDash Tasks: AI가 아니라 사람이 현실을 실행한다

dd-cli와 Ask DoorDash가 모두 ‘주문’이라는 디지털 거래를 다룬다면, DoorDash Tasks는 이보다 앞서 공개된 전혀 다른 층위의 플랫폼이다. DoorDash 개발자 문서는 이를 “현실 세계에서 행동을 실행하는” API 호출 한 번으로 미국 어디서든 Dasher를 투입할 수 있는 서비스로 소개한다. 폭풍 피해 사진 촬영, 시공 전후 상태 기록, 정해진 절차에 따른 현장 점검처럼 사람이 직접 가서 확인해야 하는 일을 에이전트가 API로 요청하면, 실제로 그 일을 수행하는 것은 800만 명이 넘는 Dasher다. 출처: DoorDash Developers, DoorDash Tasks — Digitize the Physical World

여기서 정확히 짚어야 할 것은 역할 구분이다. AI가 현실 세계의 일을 직접 수행하는 것이 아니라, AI가 사람과 플랫폼을 연결해 현실 세계의 작업을 실행한다. 에이전트는 요청을 해석하고, 주소를 확정하고, 적합한 작업을 선택해 API를 호출하는 조정자 역할을 맡는다. 실제로 문을 두드리고 사진을 찍고 물건을 옮기는 것은 여전히 사람이다. dd-cli가 “사람 없이도 디지털 주문을 끝낼 수 있는가”를 보여준다면, DoorDash Tasks는 “AI가 사람의 실행을 얼마나 정확하게 호출할 수 있는가”를 보여준다는 점에서 서로 다른 질문에 답하는 사례로 봐야 한다. 에이전트가 이런 도구를 골라 호출하는 기반 기술은 이미 여러 형태로 자리 잡고 있다. 기업 내부에서는 AI Gateway가 여러 도구·모델 호출을 한곳에서 통제하고, 에이전트끼리 작업을 넘기는 상황에서는 Agent2Agent 같은 연결 계층이, 외부 서비스와의 표준화된 도구 호출에는 MCP가 쓰인다. DoorDash Tasks의 API 호출도 이런 ‘에이전트가 실제 행동하기 위해 필요한 기반 기술’ 위에서 작동한다.

챗봇과 에이전트의 경계는 ‘말’이 아니라 ‘실행’에 있다

에이전틱 AI를 어렵게 볼 필요는 없다. 핵심은 AI가 대화를 이해하는 방식과, 외부 시스템에서 실제 업무를 수행하는 도구 호출을 결합하는 것이다. ‘툴 호출’은 AI가 주문 정보를 상상해 내는 대신, 정해진 형식의 요청으로 검색 API, 재고 API, 장바구니 API, 주문 API 같은 도구를 부르는 방식이다. 도구가 반환한 결과는 다시 AI의 판단 재료가 되고, AI는 필요한 다음 행동을 선택한다.

예를 들어 “채식 메뉴로 3명 저녁을 주문해줘”라는 요청은 단일 명령이 아니다. 누가 먹는지, 배달지는 어디인지, 예산은 얼마인지, 유제품도 피하는지, 언제 필요한지에 따라 결과가 달라진다. 좋은 에이전트는 불확실한 정보는 질문으로 되돌리고, 확실한 정보는 이미 허용된 컨텍스트에서 가져온다. 그리고 ‘가능한 메뉴를 소개’하는 데 멈추지 않고, 실제 운영 시스템이 확인한 가격과 재고를 바탕으로 후보를 제시한다.

사용자 의도
  → 조건 해석: 인원·예산·시간·식단·위치
  → 정보 조회: 카탈로그·재고·가격·배송 가능 여부
  → 비교와 제안: 조건 충족 후보·대안·예외 질문
  → 장바구니 생성: 옵션·수량·쿠폰·배송지 검증
  → 사용자 승인: 금액·가게·대체 규칙 확인
  → 실행: 주문·결제 요청
  → 결과 검증: 접수·결제·배차·배송 상태 확인 및 오류 복구

이 흐름을 에이전틱 워크플로우라고 부를 수 있다. 여기서 가장 중요한 설계 원칙은 ‘생성’과 ‘결정’을 분리하는 일이다. AI는 사용자의 표현을 이해하고 후보를 설명하는 데 강하다. 반면 최종 가격, 재고, 영업 상태, 결제 가능 여부처럼 틀리면 거래 사고로 이어지는 사실은 권위 있는 운영 시스템에서 조회해야 한다. 주문 생성 뒤에도 “API가 성공 응답을 보냈다”만으로 충분하지 않다. 주문 접수 번호, 결제 상태, 매장 승인, 배달 상태 같은 결과를 다시 확인해야 한다.

DoorDash가 비즈니스 로직을 프롬프트에 넣기보다 기존 서비스가 뒷받침하는 재사용 가능한 도구로 노출하고, 오케스트레이션과 도메인 기능을 구분한 것은 이 관점에서 읽을 만하다. 언어 모델의 표현 능력은 바뀔 수 있어도, 카탈로그·장바구니·결제·주문이라는 거래 핵심 기능은 안정적인 계약으로 남아야 하기 때문이다. 출처: DoorDash 공식 엔지니어링 블로그, Building Ask DoorDash(Part 2): Intelligence

컨텍스트가 추천 품질이 아니라 거래 품질을 좌우한다

“피자를 주문해줘”는 사람끼리도 불완전한 요청이다. 에이전트가 실용적이려면 현재 위치, 배달 가능 시간, 예산, 동행 인원, 알레르기, 선호 브랜드, 최근 주문, 멤버십 혜택, 기피 메뉴 같은 맥락을 다뤄야 한다. 이 정보가 없으면 AI는 말은 그럴듯해도 사용자가 다시 화면을 열어 수정해야 하는 추천을 내놓기 쉽다.

DoorDash가 장기 선호, 대화 중 맥락, 사용자가 명시한 사실을 구분해 소비자 기억을 다룬다는 설명은 그래서 주목할 만하다. 장기 기억은 자주 주문한 음식이나 식단 선호를 반영할 수 있고, 세션 기억은 “이번에는 아이도 먹는다” 같은 현재 대화를 유지하며, 명시 기억은 사용자가 직접 밝힌 제약을 보존하는 역할을 할 수 있다. 이 정보들은 모두 같은 신뢰도로 자동 적용돼서는 안 된다. 오래된 주소나 과거의 일시적 취향이 현재 주문에 강하게 반영되면 오히려 오류가 된다. 출처: DoorDash 공식 엔지니어링 블로그, Building Ask DoorDash(Part 2): Intelligence

서비스 기획자에게 이는 개인화 기능 추가의 문제가 아니다. 컨텍스트를 세 가지로 나눠 설계해야 한다. 첫째, 사용자가 수정·삭제·열람할 수 있는 선호 정보다. 둘째, 주문마다 다시 확인해야 하는 상황 정보다. 셋째, 결제나 배송처럼 시스템이 사실의 원천이 되는 거래 정보다. 이 경계를 흐리면 에이전트는 편리한 비서가 아니라, 오래된 기억을 근거로 실수하는 자동화가 된다.

컨텍스트의 최소 단위도 다시 정의할 필요가 있다. 기존 추천 시스템은 클릭·구매 이력 중심으로 개인화를 해왔다. 에이전트는 왜 그 추천을 지금 실행해도 되는지를 알아야 한다. 예산 상한, 허용 가능한 대체품, 특정 브랜드 제외, ‘늦으면 취소’ 같은 실행 정책이 컨텍스트가 된다. 개인화의 목표가 더 많이 보여주는 데서, 더 적게 되묻고 더 정확히 완료하는 데로 옮겨가는 셈이다.

앱의 첫 화면이 아니라 ‘에이전트가 읽는 거래 표면’이 경쟁력이 된다

전통적 플랫폼은 사람의 시선을 붙잡는 UI에 최적화돼 왔다. 상세 페이지의 사진, 배너, 검색 결과 순서, 리뷰, 결제 전환 화면이 핵심 자산이었다. 이 자산은 앞으로도 중요하다. 다만 에이전트가 거래에 관여하면 또 하나의 고객 접점이 생긴다. 사람은 ‘가장 눈에 띄는’ 상품을 찾지만, 에이전트는 ‘조건을 충족하고, 현재 구매 가능하며, 정책상 실행 가능한’ 상품을 찾는다.

이 변화를 한 문장으로 요약하면, AI가 새로운 고객이 된다는 것이다. 지금까지 플랫폼의 경쟁력은 사람이 보기 편한 화면, 즉 사람 중심 UX 경쟁이었다. 앞으로는 여기에 AI가 이해하기 쉬운 데이터 경쟁이 더해질 수 있다. 구조화된 상품 정보, 정확한 가격, 실시간에 가까운 재고 정보, 안정적인 API 품질, 세밀한 권한 관리가 새로운 경쟁력의 축이 될 수 있다는 뜻이다. 아무리 매력적인 상세 페이지를 만들어도, 에이전트가 가격·재고·배송 조건을 오독하거나 API 응답이 불안정하면 그 상품은 애초에 에이전트의 후보 목록에도 오르지 못한다. 맥킨지가 에이전틱 커머스를 “검색·비교·구매로 나뉘어 있던 단계가 하나의 의도 중심 흐름으로 통합되는 지각 변동”으로 설명하며, AI 에이전트가 판단할 수 있으려면 구조화되고 일관되며 실시간에 가까운 데이터가 필수 인프라라고 짚은 것도 같은 문제의식이다. 출처: McKinsey, The automation curve in agentic commerce

따라서 플랫폼은 AI가 읽을 수 있는 거래 표면을 갖춰야 한다. 이름과 설명만 정리하는 수준이 아니다. 상품 속성, 옵션 관계, 알레르기·규제 정보, 실시간 가격, 재고, 판매 가능 지역, 배송 약속, 취소·환불 규정, 대체 허용 범위, 결제 수단, 수수료가 일관된 데이터 모델로 연결돼야 한다. 같은 상품이 앱·웹·제휴 채널·AI 인터페이스에서 서로 다른 가격이나 재고로 보이면 에이전트의 신뢰는 즉시 무너진다.

이것은 ‘API를 열면 된다’는 말보다 넓다. API는 문을 열어 주지만, 에이전트가 안정적으로 일하려면 호출 결과의 의미, 오류 코드, 재시도 가능성, 데이터 갱신 시점, 권한 범위, 취소의 원자성까지 예측 가능해야 한다. 예를 들어 장바구니 생성은 성공했는데 할인 적용은 실패한 경우, 에이전트는 주문을 진행하면 안 된다. 부분 성공을 어떤 상태로 돌려주고 어떻게 복구하는지가 경험의 일부가 된다.

Salesforce가 말하는 통합 커머스의 방향도 같은 맥락에서 볼 수 있다. 온라인 장바구니 정보와 매장 접점, 인근 재고와 배송을 연결하는 것은 사람에게 일관된 경험을 주기 위한 작업이지만, 동시에 AI가 전체 재고와 이행 가능성을 이해할 수 있는 기반이 된다. 채널을 나눠 운영하는 데이터 구조에서는 에이전트가 고객 대신 정확한 결정을 내리기 어렵다. 출처: Unified Commerce Loop: 지능형 리테일 시장의 미래와 자사몰의 로드맵

검색·추천·광고의 질문이 달라진다

검색 중심 커머스에서는 “어떤 키워드에서 상단에 노출될 것인가”가 중요한 질문이었다. 추천 중심 커머스에서는 “어떤 사용자에게 어떤 상품을 더 보여줄 것인가”가 핵심이었다. 에이전틱 커머스에서는 질문이 한 단계 더 실행 지향적으로 바뀐다. “사용자의 제약을 만족하는 선택지 중, 에이전트가 어떤 상품을 추천하고 실제로 주문할 수 있는가”가 된다.

이 변화가 광고를 없애는 것은 아니다. 다만 클릭을 유도하는 광고 상품만으로 충분하지 않을 수 있다. 광고주와 판매자는 에이전트가 비교할 수 있는 정확한 상품 정보, 명확한 혜택 조건, 실제 이행 가능한 재고를 제공해야 한다. 후원 노출도 가능하겠지만, 에이전트가 비용·품질·배송·사용자 선호를 어떻게 함께 고려하는지 설명할 수 있어야 신뢰를 해치지 않는다. 추천 이유와 후원 여부가 사용자에게 분명히 표시되지 않으면, 편리함은 곧 불투명한 판매 압력으로 해석될 수 있다.

브랜드의 과제도 달라진다. 브랜드는 소비자에게 기억되기 위해 감성적 서사와 시각적 경험을 계속 만들어야 한다. 그러나 반복 구매나 조건 기반 구매에서는 브랜드가 ‘에이전트가 선택 가능한 후보’로 남는 일이 별도 과제가 된다. 정확한 속성 데이터, 일관된 리뷰·정책, 신뢰할 수 있는 배송 약속, 명확한 대체품 규칙이 브랜드 발견성의 일부가 될 수 있다. BCG가 에이전틱 커머스를 고객 의도부터 거래 완료까지 AI가 능동적 참여자로 들어오는 모델로 설명하며, 인간과 AI 인터페이스라는 두 의사결정자를 함께 고려해야 한다고 짚은 것도 이 지점과 맞닿아 있다. 출처: BCG, Agentic AI Is Redefining Marketing Growth

국내에서는 네이버가 대화 맥락을 이해해 구매를 제안하는 쇼핑 AI 에이전트를 정식 출시했다는 보도가 나왔다. 이 사례가 곧 주문과 결제의 전면 자동화를 뜻하지는 않는다. 다만 검색 결과를 목록으로 보여 주는 것에서, 사용 목적·조건을 대화로 수집해 구매 후보를 좁히는 방향이 실제 서비스 경쟁으로 들어오고 있음을 시사한다. 출처: 네이버 쇼핑 ‘AI 에이전트’ 정식 출시…대화하며 구매까지 제안

결제는 마지막 버튼이 아니라 권한과 책임의 설계 문제다

에이전틱 커머스에서 가장 민감한 지점은 결제다. 사람이 앱에서 결제 버튼을 누를 때는 의도와 실행이 한 화면에 결합된다. 에이전트가 중간에 들어오면 그 연결을 시스템적으로 다시 만들어야 한다. “이 AI가 누구를 위해, 어떤 수단으로, 얼마까지, 어떤 조건에서 결제할 수 있는가”가 명시돼야 한다.

가장 현실적인 방식은 권한을 세분화하는 것이다. 사용자는 음식 배달에는 월별 또는 건별 한도를 두고, 특정 주소와 기존 결제수단만 쓰게 하며, 새 판매자·새 배송지·고액 주문·대체품 변경은 반드시 재승인하게 만들 수 있다. 반복 구매는 미리 정한 품목과 가격 범위 안에서 빠르게 처리하되, 평소와 다른 주문은 멈춰 세우는 식이다. 중요한 것은 사용자가 자동화를 켜거나 끄는 선택권, 권한의 범위, 각 실행의 이유와 결과를 이해할 수 있어야 한다는 점이다.

이때 Human-in-the-loop, 즉 사람의 최종 확인은 자동화 실패를 의미하지 않는다. 위험이 큰 지점에 사람을 정확히 배치하는 설계다. 에이전트는 비교·입력·검증 같은 반복 작업을 줄이고, 사람은 의도가 바뀌거나 비용과 책임이 커지는 순간 결정을 내린다. 좋은 경험은 승인 창을 무조건 줄이는 것이 아니라, 사용자가 확인해야 할 순간에만 짧고 충분한 정보를 보여 주는 데 있다.

결제 사업자와 플랫폼에는 인증·위임·취소·분쟁 처리의 재설계가 과제다. 주문을 생성한 에이전트, 결제를 승인한 사용자, 거래를 이행한 판매자, 결제 정보를 보관한 사업자의 역할을 추적할 수 있어야 한다. 실행 전 정책 검사, 실행 후 영수증과 상태 기록, 실패 시 중복 청구 방지, 취소 가능 구간의 명확화가 모두 필요하다. AI 에이전트 결제의 상호운용성 표준 논의에 결제 인프라 사업자가 참여하는 배경도 여기에 있다. 출처: NHN KCP, AI 에이전트 결제 표준 만든다…글로벌 AAIF 합류

신뢰성은 ‘환각 방지’보다 넓은 운영 문제다

생성형 AI의 위험을 말할 때 흔히 환각을 떠올린다. 커머스 에이전트에서는 더 넓은 실패 지도를 봐야 한다. AI가 존재하지 않는 메뉴를 말하는 오류도 문제지만, 더 흔한 운영 리스크는 오래된 재고, 적용되지 않는 쿠폰, 주소 해석 오류, 동시 주문으로 인한 품절, 일시적 결제 실패, 매장 거절, 중복 주문, 배송 지연이다. 답변 품질이 좋아도 실행 결과가 틀리면 고객은 서비스를 신뢰하지 않는다.

그래서 에이전트의 평가는 대화가 자연스러운가에만 머물면 안 된다. 조건에 맞는 상품을 골랐는가, 필요한 질문을 했는가, 금지된 결제를 막았는가, 주문이 실제로 완료됐는가, 실패를 복구했는가, 사용자가 이유를 이해했는가를 함께 측정해야 한다. DoorDash가 상태를 가진 고객 대화와 도구 응답을 이용한 자동 평가, 운영 환경과 유사한 검증 체계를 강조한 이유도 답변형 AI와 실행형 AI의 품질 기준이 다르기 때문이다. 출처: DoorDash 공식 엔지니어링 블로그, Building Ask DoorDash(Part 3): Evaluation

PM과 운영 조직은 특히 세 가지 기록을 분리해 보관할 필요가 있다. 사용자가 무엇을 원했는지에 대한 의도 기록, AI가 어떤 데이터와 규칙을 바탕으로 무엇을 제안했는지에 대한 결정 기록, 실제 어떤 API 호출과 상태 전이가 일어났는지에 대한 실행 기록이다. 이 세 기록이 있어야 고객 문의를 해결하고, 잘못된 추천이나 결제 사고를 재현하며, 정책을 개선할 수 있다. ‘AI가 그렇게 판단했다’는 설명은 운영 체계가 아니다.

예외 처리도 제품 기능으로 다뤄야 한다. 예를 들어 주문 직전 품절이 나면, 에이전트가 임의로 대체품을 결제할 수 있는지, 가격 차이는 어디까지 허용되는지, 사용자에게 다시 물을지, 주문 전체를 멈출지를 정책화해야 한다. 배송이 늦어지면 취소·환불·보상은 누가 판단하는지 정해야 한다. 에이전트는 예외를 없애지 않는다. 예외를 더 빠르고 일관되게 처리할 기회를 만들 뿐이다.

여행·숙박·쇼핑·금융으로 넓어질 때의 공통 구조

배달은 에이전틱 커머스의 시험장으로 적합하다. 빈도가 높고, 상품·시간·위치·재고·배송이 한 거래에 함께 들어가며, 결과를 비교적 빠르게 확인할 수 있기 때문이다. 하지만 구조는 다른 산업에도 적용될 수 있다.

여행·숙박 산업은 이 구조가 특히 자연스럽게 옮겨갈 수 있는 영역이다. “다음 달 셋째 주말, 예산 150만원 안에서 항공권과 숙소를 같이 알아봐 줘”라는 요청을 받은 에이전트는 일정과 예산을 기준으로 여러 항공사·숙박 플랫폼의 운임과 객실 조건을 비교하고, 취소 규정과 좌석·객실 재고를 확인한 뒤 후보를 좁힐 수 있다. 사용자가 최종 승인만 하면 결제와 예약까지 에이전트가 이어서 처리하는 방식이다. 항공권은 배달 주문보다 단가가 높고 환불·변경 규정이 복잡하지만, 조건이 명확한 반복 출장이나 정형화된 패키지 여행처럼 실패 비용이 낮은 영역부터 이런 흐름이 자리 잡을 가능성이 있다. DoorDash의 사례가 음식 배달에만 해당하는 이야기가 아니라, 검색·비교·예약·결제가 함께 얽힌 모든 산업으로 에이전틱 커머스가 확산되는 흐름의 한 예로 봐야 하는 이유가 여기에 있다.

산업	사용자가 맡기고 싶은 일	에이전트가 연결할 운영 데이터	반드시 남겨야 할 사람의 판단
여행	조건에 맞는 항공·숙소 조합 찾기	좌석·객실 재고, 운임 규칙, 수하물·환불 조건	총액, 환불 불가 조건, 일정 확정
숙박	출장 정책 안에서 호텔 예약	법인 요금, 위치, 체크인, 취소 기한	객실·일정·보증 조건 승인
쇼핑	반복 구매와 대체품 선택	상품 속성, 재고, 가격, 호환성, 배송	고가 품목·브랜드 변경·결제 승인
금융	지출 요약과 이체 준비	계좌 상태, 수수료, 수취인 검증, 한도	송금·투자·대출 등 법적·금전적 결정

공통점은 ‘추천’만으로 끝나지 않는다는 것이다. 각 산업은 공식 데이터 원천, 정책 규칙, 사용자 권한, 실행 상태 검증을 함께 갖춰야 한다. 여행에서 AI가 매력적인 일정안을 만드는 것은 비교적 쉬운 일일 수 있다. 하지만 실제 예약에는 운임 변경, 객실 정책, 여권·이름 정보, 취소 조건이 얽힌다. 금융은 더 엄격하다. 대화형 안내와 거래 실행 사이의 경계를 훨씬 보수적으로 설계해야 한다.

따라서 산업 확장은 같은 속도로 일어나지 않을 가능성이 높다. 빈도가 높고 거래가 단순하며 실패 비용이 낮은 반복 구매부터 적용이 늘어날 수 있다. 반대로 규제가 강하고 되돌리기 어려운 거래는 제한된 추천과 사용자 승인 중심으로 오래 남을 가능성이 있다. 이것은 기술 성숙도만이 아니라 책임 구조와 소비자 신뢰의 문제다.

플랫폼과 PM이 지금 점검할 다섯 가지

첫째, 자신의 서비스가 제공하는 ‘실행 가능한 사실’을 목록화해야 한다. 상품명과 설명만이 아니라 가격, 재고, 옵션, 배송 가능 여부, 정책, 수수료, 상태 변경을 어떤 시스템이 최종적으로 보증하는지 찾아야 한다. 이 원천이 불명확하면 AI 인터페이스를 붙여도 결국 부정확한 설명 도구에 머문다.

둘째, 사람용 화면과 기계용 계약을 함께 제품으로 관리해야 한다. 사람이 이해하는 상세 페이지와 에이전트가 호출하는 데이터·도구는 서로 다른 표현이지만 같은 거래를 가리켜야 한다. 조직적으로는 카탈로그, 주문, 결제, 고객 지원, 데이터 팀이 각자 가진 정의를 조정하는 일이 선행돼야 한다.

셋째, 자동화의 범위를 시나리오별로 제한해야 한다. ‘주문 자동화’라는 한 단어 대신, 검색 보조, 후보 비교, 장바구니 작성, 주문 초안 생성, 승인 후 결제, 반복 구매 자동 실행을 분리한다. 각 단계에 필요한 데이터, 실패 비용, 승인 주체, 되돌리는 방법을 정의하면 과도한 약속을 피할 수 있다.

넷째, 지표를 전환율 하나로 축소하지 말아야 한다. 에이전트가 질문 횟수를 줄였는지, 사용자가 수정한 비율은 어떤지, 주문 실패·중복 주문·취소·고객센터 문의가 늘었는지, 승인을 건너뛴 위험 행동은 없는지를 함께 본다. 단기 전환율이 좋아도 잘못된 자동화가 환불과 이탈을 키우면 장기 가치는 훼손된다.

다섯째, 광고·제휴·브랜드 노출의 원칙을 지금부터 정해야 한다. 후원 결과가 추천에 어떻게 작용하는지, 에이전트가 어떤 이유로 특정 판매자를 골랐는지, 사용자 선호와 상충할 때 무엇을 우선하는지 설명할 수 있어야 한다. AI가 고객 접점이 될수록 추천의 투명성은 브랜드 신뢰와 규제 리스크 모두에 직접 연결된다.

앱이 사라지는 것이 아니라, 앱의 역할이 재배치된다

에이전틱 커머스가 확산한다고 해서 앱이 사라진다고 보기는 이르다. 사용자는 여전히 신상품을 둘러보고, 이미지와 리뷰를 보고, 브랜드를 경험하고, 중요한 결정을 직접 내리고 싶어 한다. 앱과 웹은 발견·신뢰 형성·복잡한 비교·문제 해결의 공간으로 남을 것이다.

달라질 수 있는 것은 앱이 모든 거래의 유일한 입구라는 전제다. 반복적이고 조건이 분명한 구매에서는 AI가 앱 바깥의 대화 창, 운영체제 보조 기능, 업무 도구, 자동차 인터페이스 같은 곳에서 의도를 받아 플랫폼의 실행 능력을 호출할 수 있다. 플랫폼은 소비자에게 사랑받는 UI를 계속 만들면서도, AI 에이전트가 신뢰하고 호출할 수 있는 거래 환경을 제공해야 할 가능성이 커진다.

DoorDash의 사례는 그 전환이 이미 제품과 시스템 설계의 문제로 내려왔음을 보여 준다. 중요한 것은 ‘AI가 주문한다’는 표면적 장면이 아니다. 자연어 이해, 정확한 컨텍스트, 재사용 가능한 도구, 권한 관리, 사람의 승인, 실행 결과 검증이 한 흐름으로 묶일 때 비로소 에이전트가 거래를 도울 수 있다는 점이다.

앞으로 플랫폼의 경쟁력은 소비자가 사용하기 쉬운 앱을 만드는 것에서, AI 에이전트가 신뢰하고 실행할 수 있는 플랫폼을 만드는 것으로 확장될 가능성이 있다. 이 변화는 단기간에 기존 이커머스를 대체한다는 예언이 아니다. 다만 지금의 데이터 품질, 권한 모델, 결제·주문 운영, 추천 투명성이 미래의 고객 접점에서 어떤 선택지를 갖게 할지를 결정할 수 있다는 뜻이다.

참고 출처

함께 읽기: AI 호출 인터페이스