AI가 체크아웃을 설계할 때 저지르는 실수 (그리고 해결 방법)

AI가 체크아웃을 설계할 때 저지르는 뻔한 실수가 있습니다. 바로 만 번째 거래가 아니라 데모 시연만을 위해 설계한다는 점입니다. AI 앱 빌더에게 체크아웃을 만들어 달라고 하면 몇 분 만에 그럴듯한 결과물이 나옵니다. 깔끔한 장바구니, 정돈된 버튼, 직관적인 결제 화면이 제공되죠. 하지만 진짜 문제는 스크린샷에 담기지 않는 영역에서 발생합니다. 환불, 분할 결제, 세금 규칙, 혹은 토요일 정오에 길게 늘어선 고객 대기 줄을 이 흐름이 어떻게 처리하는지 같은 부분입니다.

해결책은 더 나은 프롬프트를 작성하는 것이 아닙니다. 체크아웃의 어느 부분을 AI에게 맡기고, 어느 부분을 절대 AI가 임의로 처리하지 못하게 할지 결정하는 것입니다. AI가 생성한 체크아웃이 실제로 작동을 멈추는 지점과 이에 대한 대처법을 알아봅니다.

왜 AI가 설계한 체크아웃은 겉보기엔 멀쩡한데 실제 사용 시 실패할까요?

두 가지 이유가 있습니다. 첫째, AI는 기존 체크아웃을 학습하여 설계하는데, 기존 체크아웃의 수준이 그리 높지 않기 때문입니다. 베이마드 연구소(Baymard Institute)에 따르면 온라인 장바구니 이탈률은 평균 70.22%에 달하며¹, 미국 평균 체크아웃은 이상적인 흐름에 필요한 12~14개보다 훨씬 많은 23.48개의 입력 폼 요소를 포함하고 있다고 합니다¹. 평균적인 데이터로 학습된 모델은 그 실수까지 그대로 재현합니다.

둘째, 해피 패스(happy-path) 편향 때문입니다. 생성된 소프트웨어는 데모처럼 평가받습니다. 즉, '일반적인 상황에서 작동하는가?'를 봅니다. 반면 실제 체크아웃은 금전 등록기처럼 평가받아야 합니다. '고객이 지켜보는 가운데 매번 모든 예외 상황까지 완벽하게 처리하는가?'를 따져야 하죠. 이 둘의 기준은 완전히 다르며, 실제 돈이 오가기 전까지는 그 격차가 눈에 보이지 않습니다.

AI가 체크아웃에서 실제로 저지르는 실수는 무엇일까요?

다섯 가지 오류가 반복해서 나타납니다. (그 이면에 있는 더 깊은 인프라 격차에 대해서는 Lovable이나 Replit으로 POS를 구축할 수 있을까요?를 참고하세요. 여기서는 체크아웃 자체에 집중합니다.)

• 금액 계산 오류. 생성된 코드는 통상적으로 통화 연산을 부동 소수점(반올림이 불규칙하게 발생하는 소수점 연산)으로 처리하므로, 할인, 세금, 분할 결제 과정에서 미세한 금액 오차가 발생합니다. 이 문제는 마감 시점에 일일 마감 보고서와 실제 정산 금액이 일치하지 않는 현상으로 나타납니다.

• 세금 처리. AI는 단일 세율을 하드코딩하는 경향이 있습니다. 실제 판매세는 관할 구역, 품목 유형, 면세 여부, 날짜에 따라 달라지며 코드에 알리지 않고 수시로 변경됩니다. 세금을 대충 짐작해서 계산하는 체크아웃은 정상적인 시스템이 아니라, 겉만 번지르르한 법적 리스크일 뿐입니다.

• 예외 경로(Unhappy paths). 환불, 승인 취소, 부분 결제, 가격 임의 수정, 결제 도중 네트워크 끊김 현상 등입니다. 데모에서는 이런 상황을 테스트하지 않지만, 실제 매장 카운터에서는 매일 발생합니다. 대부분의 AI 생성 체크아웃에는 이러한 기능이 아예 누락되어 있습니다.

• 캐셔의 작업 속도. AI는 한 번만 결제하는 일반 소비자를 위해 설계된 이커머스 패턴을 그대로 복사합니다. 하지만 매장 직원은 한 교대 근무 동안 동일한 흐름을 수백 번 반복하므로, 불필요한 터치가 한 번 늘어날 때마다 대기 시간이 누적됩니다. 아주 작은 선택도 카운터의 흐름을 바꿉니다. 예컨대 팁 입력 창의 위치를 정하는 것조차 매우 중요한 결정입니다.

• 결제 처리. 결제 버튼이 있다고 해서 결제가 이루어지는 것은 아닙니다. 대면 카드 결제를 처리하려면 결제 대행사(PG), PCI 준수(카드 업계 데이터 보안 표준), 인증된 리더기 하드웨어가 필요합니다. 이 중 어느 것도 프롬프트만으로 생성할 수 없으며, 반드시 실재해야 합니다. 결제 인프라의 실제 구성 요소는 생각보다 훨씬 복잡합니다.

AI가 설계한 체크아웃을 어떻게 해결해야 할까요?

역할을 둘로 나누세요. AI는 레이아웃, 흐름 순서, 문구 작성, 매장의 실제 판매 방식에 맞춘 화면 구성 등 디자인 영역에 확실히 강점이 있습니다. 이 부분은 AI에게 맡기십시오. 반면 금액 계산, 세금, 결제 처리, 거래 기록과 같은 금융 영역은 프롬프트에 의해 매번 새로 생성되는 코드가 아니라, 항상 동일하고 정확한 결과를 보장하는 결정론적(deterministic) 커머스 인프라를 기반으로 작동해야 합니다.

"세금을 정확하게 처리하도록 프롬프트를 작성해 줘"라는 식으로는 해결되지 않습니다. 눈으로 보는 것만으로는 제대로 작동하는지 알 수 없기 때문입니다. 거래당 몇 센트씩 발생하는 미세한 오차는 몇 달 동안 아무도 눈치채지 못할 수 있습니다. 따라서 구조적인 해결책이 필요합니다.

• 프롬프트에 의존하는 대신 제약 조건을 두세요. 합계, 세금, 결제 수단이 기본으로 내장되어 있어 AI가 이를 새로 발명하는 것이 아니라 배치만 할 수 있는 플랫폼을 사용하십시오.

• 출시 전에 예외 경로를 테스트하세요. 환불, 승인 취소, 분할 결제, 결제 도중 취소를 직접 실행해 보십시오. 이 중 하나라도 누락되었다면 그것은 체크아웃이 아니라 단순한 데모일 뿐입니다.

• 첫날부터 정산해 보세요. 실제 판매 첫날이 지난 후 체크아웃 합계와 결제 대행사의 기록을 대조해 보십시오. 미세한 금액 오차는 즉시 나타나거나 아예 나타나지 않습니다.

• 임시방편을 감시하세요. 운영 첫 주에 직원이 정상적인 흐름을 우회하는 임시방편을 만들어 쓴다면 설계가 실패한 것입니다. 임시방편이 시스템으로 굳어지기 전에 수정하십시오.

요약하자면, AI가 체크아웃을 설계할 때 저지르는 실수는 무엇일까요?

겉모습은 제대로 그리지만 내부 배관을 엉망으로 만듭니다. 즉, 정상적인 흐름만 고려하고, 금액 계산을 임의로 처리하며, 세금을 짐작하고, 환불이나 분할 결제, 대면 카드 결제에 대한 대책이 없습니다. 이 중 어느 것도 더 나은 프롬프트로 해결되지 않으며, 이미 금융 처리를 담당하고 있는 인프라 위에 AI를 얹음으로써 해결할 수 있습니다. 경험 법칙: AI에게 흐름을 설계하게 하되, 돈 계산을 임의로 처리하게 두지 마십시오.

이러한 역할 분담이 바로 Final의 Build와 같은 프롬프트 기반 빌더의 핵심 개념입니다. 사용자는 원하는 체크아웃을 설명하기만 하면 되며, 그 이면의 합계, 세금, Final Pay 거래는 항상 정확하게 계산되는 시스템을 통해 처리됩니다. 실제로 확인해 보려면 약 10분 만에 첫 번째 흐름을 구축해 보거나, 비즈니스를 위한 AI: 할 수 있는 것과 할 수 없는 것을 통해 더 넓은 관점에서 살펴보세요.