프롬프트에서 결제까지: 일상적인 언어로 POS 설명하기

일상적인 언어로 POS를 설명하는 것은 유효하지만, 소프트웨어가 아닌 비즈니스 자체를 설명할 때만 효과가 있습니다. 가장 훌륭한 설명은 신입 사원의 첫 근무날 교육하는 내용과 비슷합니다. 우리가 판매하는 품목, 결제 방식, 영수증에 표시될 내용을 알려주는 것이죠. 프롬프트 기반 빌더는 이러한 설명을 실제 판매가 가능한 결제 시스템으로 바꿔줄 수 있습니다. 실제 작동하는 계산대를 얻을지, 그저 보기 좋은 데모를 얻을지는 다섯 가지 세부사항에 달려 있으며, 이 중 기술적인 내용은 하나도 없습니다.

일상적인 언어로 작성한 POS 설명은 어떤 모습일까요?

평범한 화요일에 누군가에게 카운터를 안내하는 여러분의 목소리와 같습니다.

"저는 계산대 1대를 갖춘 베이커리를 운영합니다. 빵, 페이스트리, 드립 커피를 판매하죠. 페이스트리는 1개 또는 6개 세트(하프 다스) 단위로 나갑니다. 커피는 2가지 크기이며 우유 옵션이 있습니다. 대부분 카드를 단말기에 대서 결제하지만 현금도 받습니다. 통식빵은 면세 대상이고, 나머지는 모두 판매세가 부과됩니다. 손님들은 보통 영수증을 이메일로 받고 싶어 합니다."

기능 명칭도, 화면 설명도 없습니다. 카탈로그, 옵션, 결제 수단, 세금 규정, 영수증 등 매장 전면 업무 전체를 담아낸 단 7개의 문장일 뿐입니다. 빌더는 이런 설명을 바탕으로 작동할 수 있습니다. 하지만 "베이커리용 최신 POS를 만들어 줘" 같은 프롬프트는 비즈니스가 아닌 분위기만 설명할 뿐이므로 빌더가 처리할 수 없습니다.

결제 시스템의 작동 여부를 결정하는 5가지 세부사항은 무엇인가요?

신입 사원이 점심시간 전까지 물어볼 법한 내용들입니다. 각 항목을 여러분만의 언어로 설명해 보세요.

• 판매 품목 및 분류 방식. 모든 상품을 하나하나 나열할 필요 없이 카테고리, 크기나 추가 옵션 여부 등 카탈로그의 전체적인 구조만 설명하면 됩니다. POS에서는 이러한 옵션을 모디파이어(Modifier)라고 부르며, 이를 누락하는 것이 첫 번째 빌드 후 계산대에서 어색함을 느끼게 되는 가장 흔한 원인입니다.

• 결제 방식. 카드, 현금 또는 둘 다 사용하는지 여부와 팁 기능이 필요한지 여부를 포함합니다.

• 실제 적용하는 세금 규정. 법률 조항이 아니라 매장의 실제 운영 상황을 적어주세요. 과세 대상과 면세 대상, 세금이 진열대 가격에 포함되어 있는지 계산대에서 추가되는지 등을 명시합니다.

• 영수증에 포함되어야 할 내용. 이메일, 출력 또는 둘 다 제공할지 여부와 함께 사업자 등록번호나 환불 정책처럼 필수적으로 들어가야 하는 사항을 적습니다.

• 예외 상황. 공병 보증금, 무게 단위 청과물, 직원 할인, 월말에 한꺼번에 결제하는 단골 손님 등의 예외 상황을 각각 한 문장 정도로 적어주면 충분합니다. 일반적인 판매는 처리하지만 이러한 특이한 상황을 처리하지 못하는 결제 시스템은 일주일도 안 되어 외면받게 되므로, 예외 상황이야말로 전체 설명에서 가장 가치 있는 문장입니다.

일상적인 언어로 할 수 없는 것은 무엇인가요?

설명은 동작 방식을 결정할 뿐, 그 이면에 있는 시스템 백엔드까지 올바르게 구축해 주지는 못합니다. 동일한 상품에 대해 동시에 두 건의 결제가 발생해도 정확하게 유지되는 재고 관리, 실제 이동한 금액과 일치하는 마감 보고서, 첫 번째 결제부터 천 번째 결제까지 동일하게 적용되는 세금 계산, 카드 업계 보안 표준(PCI 규정)을 준수하는 카드 결제 등은 문장 하나로 해결할 수 있는 영역이 아닙니다. 여러분의 설명이 전달되는 플랫폼이 이러한 기능을 이미 지원하거나, 혹은 지원하지 않거나 둘 중 하나입니다.

바로 이 지점에서 직접 구축하려는 시도가 난관에 부딪힙니다. AI 코드 생성기는 동일한 7개 문장만으로 그럴듯한 결제 화면을 만들어내지만, 실제 돈과 실제 재고가 오가는 순간 한계가 드러납니다. 저희는 POS 바이브 코딩하기 문서와 최고 수준의 코딩 모델조차 제대로 작동하는 POS를 단독으로 출시하지 못하는 이유에 관한 글에서 이러한 한계점을 분석한 바 있습니다. 일상적인 언어는 눈에 보이는 POS 부분에 대한 완벽한 명세서 역할을 합니다. 하지만 눈에 보이지 않는 백엔드 부분은 여전히 누군가가 미리 구축해 두어야 합니다.

초안은 어떻게 다듬어야 할까요?

신입 사원을 가르칠 때처럼 한 번에 하나씩 구체적으로 지적해 주면 됩니다. 미리보기가 준비되는 대로 가장 흔한 주문부터 가장 특이한 주문까지 테스트 결제를 진행해 보세요. 문제가 있다면 매장 전체를 다시 설명하는 대신 평범한 문장("6개 세트 주문 시 6가지 페이스트리 종류를 선택하도록 물어봐야 함")으로 수정하세요. 화면 레이아웃 자체를 수정해야 한다면 뛰어난 POS 레이아웃을 생성하는 프롬프트 패턴을 참고해 보세요. 화면 모양이 아닌 거래 과정을 설명하는 것만으로도 대부분 해결됩니다.

Final에서는 이 작업이 채팅 형태로 진행됩니다. 설명, 미리보기, 수정, 배포의 과정이 이루어지며, 모든 변경 사항은 롤백이 가능한 체크포인트로 저장됩니다. 단계별 가이드는 첫 번째 플로우 구축하는 방법에서 확인할 수 있습니다. 이미 사용 중인 AI 도구를 계속 활용하고 싶다면 MCP를 통해 자체 AI 연결하기(AI 도구를 다른 소프트웨어에 연결하는 표준 방식)를 통해 동일한 실시간 미리보기를 바탕으로 구축할 수 있습니다. 개발 과정에 대해 더 궁금하시다면 프롬프트가 비주얼 빌더를 대체한 이유에서 상세한 이야기를 확인해 보세요.

그렇다면, 일상적인 언어로 정말 프롬프트에서 결제까지 구현할 수 있을까요?

그렇습니다. 카탈로그, 결제 수단, 세금 규정, 영수증, 예외 상황을 아우르는 설명은 매장 전면 업무를 위한 완벽한 명세서이며, 프롬프트 기반 빌더는 이를 당일에 작동하는 결제 시스템으로 변환할 수 있습니다. 단, 어떤 설명도 이면에 있는 커머스 인프라까지 만들어 줄 수는 없으므로 이러한 인프라가 이미 갖춰진 플랫폼을 향해 설명 프롬프트를 작성해야 합니다. 기본 원칙은 다음과 같습니다. 신입 사원을 교육하듯 카운터 업무를 설명하고, 신입 사원의 눈에 보이지 않는 모든 백엔드 작업은 플랫폼에 맡기세요.

작성한 설명이 실제 작동하는 계산대로 변하는 과정을 확인하고 싶다면 5분 만에 살피는 Build 시작하기 가이드를 참고해 보세요.