‘페퍼로니 피자 한 판을 빨리 보내 줘’라는 문장을 AI가 주문으로 바꿨다고 배송까지 끝난 것은 아니다. 메뉴·가격·알레르기 선택을 확인하고 매장 재고와 조리시간을 예약한 뒤, Wing service zone·payload·날씨와 customer drop point가 모두 맞아야 비행 임무가 만들어진다.
2026년 5월 시작된 Charlotte 초기 pilot는 curated Oven Toasted Sandwich를 Wing 앱에서 주문하는 구조다. Papa Johns 자사 앱과 Google Cloud 기반 Lou AI가 Wing network에 직접 연결되는 것은 두 회사가 제시한 ‘soon’의 향후 vision이다. 현재 workflow와 미래 agentic workflow를 한 화면처럼 설명하면 책임 경계가 사라진다.
에이전트의 문제는 말귀가 아니라 거래 상태다
agentic commerce는 자연어를 menu item으로 바꾸는 기능만이 아니다. customer identity·location, item option·allergen, price·promotion, payment authorization, stock, kitchen capacity, delivery eligibility와 consent를 검증하고 각 system에 transaction state를 남기는 orchestration 문제다.
Wing–Papa Johns 공식 발표는 Charlotte Indian Trail 인근에서 pilot가 시작됐고, 초기 주문은 Wing 앱의 제한 메뉴로 이루어진다고 밝혔다. 직접 app·Lou AI integration은 계획이다. 현재 가능한 주문경로와 목표 architecture를 API status register로 나눈다.
한 agent가 모든 결정을 소유하게 만들지 않는다. Lou AI는 대화와 주문 후보를, Papa Johns commerce는 catalog·price·payment·store order를, kitchen은 준비상태를, Wing은 flight eligibility·dispatch·delivery를 authoritative source로 갖는다. agent는 각 source의 확인을 받아 다음 상태로 이동한다.
기존 방식은 사람과 앱이 경계를 확인했다
현재 pilot에서 고객은 Wing 앱이 보여 주는 eligible address와 curated menu를 고른다. 이 제한은 불편해 보여도 payload, packaging, store workflow와 flight availability를 앞단에서 맞춘다. store가 준비한 sandwich를 인계하고 Wing system이 비행·배송 상태를 고객에게 전달한다.
전통적인 restaurant delivery는 POS가 주문을 받고 직원이 품절·조리 지연을 조정하며 driver platform이 배차와 handoff를 맡는다. 실패하면 사람이 전화·취소·refund를 연결한다. agentic flow는 이 handoff를 API로 줄이지만 예외 판단과 금전 책임까지 자동으로 사라지지 않는다.
Papa Johns의 partnership 설명은 Wing과 함께 packaging·loading 등 operational design을 개발한다고 전한다. 이는 주문 assistant만 바꾸는 project가 아니라 음식의 크기·온도·aerodynamics와 매장 작업을 함께 바꾸는 통합임을 보여 준다.
새 방식은 확인 가능한 상태기계여야 한다
미래 flow는 intent_received, cart_confirmed, payment_authorized, store_accepted, cooking, load_ready, flight_reserved, picked_up, delivered와 closed 같은 상태를 가진다. 각 transition에는 owner, timeout, idempotency key와 compensation action이 필요하다. agent가 같은 요청을 두 번 보내도 중복 결제·중복 비행이 생기지 않아야 한다.
주소를 자연어로 받으면 rooftop·yard·apartment와 delivery obstacle을 구분하고 Wing eligibility service의 답을 받아야 한다. 음식 준비시간과 aircraft arrival을 맞추지 못하면 뜨거운 음식이 식거나 drone이 기다린다. kitchen ETA와 flight slot을 양방향 예약하되 어느 한쪽이 지연되면 재계획한다.
고객에게는 확정과 제안을 구분해 보여 준다. ‘약 10분 예상’은 promise가 아니고, payment·store·flight가 모두 hold된 뒤에야 confirmed ETA가 된다. AI가 추정한 가격·allergen·delivery availability를 authoritative response보다 먼저 확정 문장으로 말하지 않는다.
공유해야 할 것은 대화가 아니라 최소 이벤트다
Lou AI와 Wing이 raw conversation 전체를 공유할 필요는 없다. order ID, store, item mass·dimensions, readiness window, destination token, eligibility, flight status와 exception code처럼 목적에 필요한 event만 교환한다. payment·health·voice data는 역할에 맞게 격리한다.
Papa Johns의 Lou AI 소개는 자연어 주문과 personalisation 방향을 설명한다. company product vision이며 Wing direct integration의 production evidence가 아니다. model output에는 catalog version과 confirmation step을 두고, 불명확한 요청은 human or structured UI로 넘긴다.
관측성도 shared component다. customer session, commerce order, kitchen ticket와 Wing mission을 correlation ID로 잇는다. 어느 system에서 timeout이 났는지, 최종 상태와 refund가 일치하는지 확인해야 agent가 보낸 매끄러운 문장 뒤의 실패를 찾을 수 있다.
품절·비·주소 오류는 서로 다른 복구를 요구한다
품절은 item substitution과 가격·allergen 재동의가 필요하다. 조리 지연은 flight slot을 재예약하거나 ground delivery로 바꿀 수 있다. bad weather는 이미 조리가 시작됐더라도 Wing이 flight를 취소해야 한다. 주소·drop zone 오류는 customer verification을 받아야 하며 agent가 임의 위치를 만들면 안 된다.
고객 미수령은 delivery proof와 food safety를 확인한다. payload가 내려졌다면 회수·redelivery 가능성과 책임이 달라지고, 아직 aircraft에 있으면 return route와 product disposition을 따른다. refund를 commerce system이, mission cancel을 Wing이 처리하더라도 final state는 두 system에서 일치해야 한다.
AI 오류도 구분한다. 존재하지 않는 메뉴·promotion을 말한 hallucination, 잘못된 option mapping, 고객 의도 오해, API stale data와 unauthorized action은 서로 다른 방지책을 가진다. conversation quality 점수로 금전·안전 incident를 가리지 않는다.
선택 경계는 자동화율이 아니라 책임을 닫는 능력이다
단순 menu와 넓은 service availability, 안정된 kitchen에서는 agentic integration이 주문 단계를 줄일 수 있다. 복잡한 allergen·customization, 재고 변동과 날씨가 잦으면 structured confirmation과 human handoff가 더 안전하다. 모든 주문을 대화형 agent로 강제할 이유는 없다.
- 현재 Wing-app pilot와 미래 Papa Johns app·Lou AI direct integration을 구분한다.
- catalog·price·allergen·payment·stock·flight eligibility의 authoritative owner를 지정한다.
- order–kitchen–mission 상태와 compensation action을 correlation ID로 연결한다.
- 품절·지연·기상·주소·미수령별 cancel·substitute·refund owner를 계약한다.
- raw conversation 대신 delivery에 필요한 최소 event와 consent만 공유한다.
- duplicate action, stale API와 partial failure를 replay test로 검증한다.
- confirmed ETA·가격·delivery 상태만 고객에게 확정 문장으로 표시한다.
이 경계를 통과하면 agentic commerce는 멋진 대화 demo가 아니라 실제 물류의 transaction coordinator가 된다. 통과하지 못하면 Wing 앱의 제한 메뉴처럼 단순하고 검증된 경로를 유지하는 편이 낫다. 자동화 범위를 좁히는 것은 실패가 아니라 exception rate에 맞춘 설계다.
현장에서 다시 확인할 질문
Lou AI가 주문하면 지금 바로 Wing 드론이 자동 출동하나요?
2026년 8월 26일 확인 범위에서는 아니다. 초기 Charlotte pilot는 Wing 앱의 curated menu로 운영된다. Papa Johns app과 Lou AI의 직접 Wing 연동은 향후 계획이다. 통합 뒤에도 재고·결제·조리·날씨·주소 eligibility의 authoritative system이 승인해야 실제 mission이 만들어져야 한다.
자료 마지막 확인: 2026년 8월 26일