Lovable이나 Replit으로 POS를 만들 수 있을까? UI 너머에 빠진 것들

어느 정도는 가능합니다. POS의 정의가 화면에서 끝난다면 Lovable이나 Replit으로도 POS를 만들 수 있습니다. 두 도구 모두 반나절 만에 결제 인터페이스, 상품 그리드, 장바구니를 만들어내며, 이는 가맹점들이 돈을 지불하고 사용하는 많은 소프트웨어보다 더 보기 좋을 것입니다. 하지만 UI 너머, 즉 눈에 보이지 않는 영역인 재고, 보고, 세금, 그리고 매번 완벽하게 정확해야 하는 결제 기능에서 간극이 발생합니다.

시작하기 전에 한 가지 유의할 점은, Lovable과 Replit은 끊임없이 업데이트를 배포하므로 아래의 세부 사항은 발행일 기준의 정보로 이해해 주시기 바랍니다.

Lovable과 Replit은 실제로 무엇을 제공하나요?

회의론자들의 생각보다 훨씬 많은 것을 제공합니다. Lovable은 데이터베이스, 인증, 파일 저장소가 포함된 호스팅 백엔드와 연결된 React 프론트엔드 웹 앱을 생성하며, 온라인 결제를 위한 결제 연동도 지원합니다. Replit은 서버 측에서 더 나아가, 에이전트가 자체 데이터베이스, 호스팅, 인증이 내장된 앱을 빌드하고 호스팅하므로 서드파티 서비스를 짜깁기하지 않고도 백엔드 로직을 실행할 수 있습니다.

내부 도구, 예약 페이지, 대시보드 같은 대다수의 소프트웨어 클래스에서는 이것이 작업의 전부이며, 이 플랫폼들이 빠르게 성장하는 이유이기도 합니다. 하지만 POS는 이 클래스에 속하지 않습니다. 웹 앱을 한 번에 만들어내는 프론티어 모델이 작동하는 POS 앞에서는 멈춰 서는 이유와 같은 이유입니다. 어려운 부분은 인터페이스가 아니었기 때문입니다.

UI 너머에 빠진 것은 무엇인가요?

바로 커머스 레이어(Commerce layer)입니다. POS는 앱이 얹어져 있는 기록 시스템(돈과 재고의 단일 원천)입니다. 두 플랫폼 모두 커머스 기본 요소를 제공하지 않으므로, 생성된 코드는 이를 처음부터 새로 발명해야 합니다.

• 동시성 제어 하의 재고 관리 (두 대의 포스기에서 동시에 판매가 일어나는 경우). 재고 컬럼의 숫자를 단순히 차감하는 방식은 데모에서는 작동하지만, 토요일 바쁜 시간에 두 단말기에서 마지막 남은 수량을 동시에 판매하는 순간 실패합니다.

• 주문 라이프사이클. 부분 환불, 교환, 취소, 할인은 각각 재고, 보고, 결제 기록을 동시에 업데이트해야 하는 상태 변화입니다. 하나라도 놓치면 숫자가 어긋납니다.

• 일치하는 보고서 (정산 대금과 일 센트 단위까지 일치하는 합계). 단순히 "대략 맞는" 보고서는 세금 신고 기간에 발견하게 될 회계 문제입니다.

• 실제 관할 구역의 규칙을 따르고 모든 영수증, 환불, 보고서에 정확히 반영되는 세금 로직.

AI 에이전트는 이 네 가지 모두에 대해 '그럴듯한' 버전을 생성해 줍니다. 하지만 '그럴듯함'이 바로 함정입니다. 망가진 버튼은 누르는 즉시 눈에 보이지만, 정산 버그는 몇 달 후 회계사가 발견하기 전까지 보이지 않기 때문입니다.

생성된 앱으로 실제 결제를 받을 수 있나요?

온라인 결제는 가능합니다. 두 플랫폼 모두 웹 결제를 위한 결제 연동을 충분히 지원합니다. 하지만 오프라인 대면 결제는 다른 영역입니다. 대면 결제는 인증된 단말기 하드웨어와 PCI DSS 준수(카드 데이터를 다루는 모든 것에 적용되는 카드 업계 보안 규정)가 필요합니다. 생성된 코드베이스 자체만으로는 이를 충족할 수 없습니다. 인증은 앱이 아니라 결제 제공업체의 하드웨어와 플랫폼에 존재하기 때문입니다. 분쟁 처리, 기존 카드로의 부분 환불, 팁 조정 등도 모두 이 인증된 레이어를 통해 실행됩니다.

이것이 어떤 도구를 사용하든 모든 DIY 방식이 결국 마주하게 되는 벽입니다. 우리는 AI 모델이 MCP를 통해 빌드할 수 있는 것과 없는 것을 테스트하면서 동일한 결론을 얻었습니다.

실제 운영 환경에서 가장 먼저 깨지는 것은 무엇인가요?

이런 반론이 있을 수 있습니다. "좋습니다, 생성된 앱을 호스팅된 데이터베이스와 결제 연동에 직접 연결하겠습니다." 그렇게 하실 수 있고, 많은 분들이 시도해 볼 가치가 있습니다. 한계가 어디인지 배우는 가장 빠른 방법이니까요. 하지만 여러분이 감수해야 할 역할을 이해하셔야 합니다. 여러분은 이제 소규모 금융 시스템의 유일한 유지보수자가 되는 것입니다. 결제 도중에 네트워크가 끊길 때, 영수증 프린터에 브라우저가 지원하지 않는 드라이버가 필요할 때, 결제 연동을 통해 환불은 처리되었는데 보고서에는 반영되지 않을 때 전화를 걸 수 있는 벤더가 없습니다. 구축은 저렴한 부분이었지만, 운영은 비용이 많이 드는 부분이며 이는 첫 실제 결제를 받는 날부터 시작됩니다.

그렇다면, Lovable이나 Replit으로 POS를 만들 수 있을까요?

전면부(Front)는 만들 수 있습니다. 실제 인터페이스와 로직을 빠르게 배포할 수 있습니다. 하지만 후면부(Back)는 생성할 수 없습니다. 부하 상황에서의 재고 관리, 정산, 세금, 인증된 대면 결제는 에이전트가 발명해 낼 수 있는 코드가 아니라 이미 존재해야 하는 인프라이기 때문입니다. 결국 두 가지 정직한 선택지만 남습니다. 그 인프라를 직접 재구축하고 평생 유지보수하거나, 이미 작동 중인 커머스 인프라 위에 결제 화면을 생성하는 것입니다. 후자가 바로 Final의 접근 방식이며, 프롬프트나 자체 AI 도구를 사용하여 작동하는 커머스 백엔드 위에 POS를 구축할 수 있습니다.

어떤 방식이든 AI에게 구축을 맡기기 전에 기억해야 할 한 가지 규칙이 있습니다. 버그로 인해 픽셀이 아니라 돈이 손실된다면, 여러분은 UI가 아니라 인프라를 구축하고 있는 것입니다. 커머스 레이어가 기본 포함된 결제 화면 아래에 무엇이 자리 잡고 있는지 확인하고 싶다면, 실제 작동 방식을 참고해 보세요.