핵심 요약
- AI 덕분에 랜딩 페이지, 상품 상세, 마이페이지 같은 쇼핑몰 화면은 예전보다 훨씬 쉽게 만들 수 있어요.
- 하지만 상품·고객·주문·결제·취소·구독 같은 커머스 로직은 화면처럼 쉽게 만들기 어려워요. 돈과 운영이 걸려 있어서 안정성이 필요해요.
- Supabase가 인증·DB·스토리지를 직접 구축하지 않게 해주는 BaaS라면, 부트페이 커머스는 독립몰에 필요한 주문·상품·결제 흐름을 직접 처음부터 짜지 않게 해주는 커머스 BaaS에 가까워요.
- 독립몰, MVP 쇼핑몰, 소규모 브랜드몰을 빠르게 열어야 한다면 결제 API부터 따로 붙이기보다 부트페이 커머스 API 도입을 먼저 검토하는 편이 나아요.
이런 상황이라면
자체 브랜드 쇼핑몰을 만들려고 외주 견적을 검토하는 팀이 있어요. 랜딩 페이지와 상품 상세 화면 정도는 금방 만들 수 있을 것 같은데, 막상 견적을 받으려니 범위가 잘 안 잡혀요.
누구는 "쇼핑몰이면 최소 5천만 원은 불러야 해요"라고 말하고, 누구는 "요즘은 AI로 금방 만들 수 있어요"라고 말해요. 그런데 들여다볼수록 상품 등록, 옵션, 재고, 주문 번호, 결제 연결, 부분 취소, 관리자 화면, 고객 문의 대응까지 챙길 게 계속 늘어나요.
단순한 화면은 AI로 빠르게 만들 수 있을 것 같아요. 하지만 돈이 오가고 주문이 쌓이는 서비스를 안정적으로 운영할 수준까지 AI와 외주 개발만으로 만들 수 있을지 감이 안 와요.
이때 필요한 건 또 하나의 쇼핑몰 솔루션이 아니라, 우리 서비스에 붙일 수 있는 검증된 커머스 BaaS예요.
1독립몰도 AI로 쉽게 딸깍
예전에는 쇼핑몰을 만들려면 쇼핑몰 솔루션을 고르는 일이 먼저였어요. 정해진 템플릿 안에서 상품을 올리고, 프론트 레이아웃을 편집하고, 관리자 화면을 쓰는 방식이에요. 빠르게 시작하기엔 좋지만, 화면과 흐름을 우리 서비스답게 바꾸는 데 한계가 있었어요.
지금은 상황이 달라졌어요. AI 코딩 도구와 프론트 템플릿이 좋아지면서 화면을 만드는 비용은 크게 내려갔어요. 브랜드몰, 예약형 커머스, 콘텐츠 판매, B2B 주문 페이지처럼 기존 쇼핑몰 솔루션에 딱 맞지 않는 독립몰을 직접 만들려는 팀이 늘어날 수밖에 없어요.
문제는 화면 다음이에요. 프론트는 AI로 빨리 만들 수 있어도, 커머스 로직은 쉽게 대체되지 않아요.
- 상품과 옵션은 어디에 저장할 것인가?
- 고객과 주문은 어떤 기준으로 연결할 것인가?
- 결제 성공과 주문 완료는 어떻게 맞출 것인가?
- 부분 취소가 들어오면 주문 상태와 금액은 어떻게 바꿀 것인가?
- 운영 담당자분은 어디서 주문과 고객을 확인할 것인가?
이 영역을 직접 만들면 쇼핑몰 백엔드를 새로 개발하는 일이 돼요. 오픈소스를 가져와도 운영 책임은 남아요. 일반 BaaS를 써도 DB와 인증은 줄어들지만, 주문·취소·결제 연결 같은 커머스 도메인 로직은 직접 설계해야 해요.
그래서 필요한 선택지가 커머스 BaaS예요. 화면은 우리 서비스가 만들고, 반복되는 커머스 로직은 검증된 API에 맡기는 방식이에요. 부트페이 커머스는 이 역할을 해요.
2프론트는 이쁘게 개발하세요. 복잡한 백엔드는 우리가 할게요.
Firebase나 Supabase라는 제품을 쓰면 로그인과 DB를 처음부터 만들지 않아도 돼요. 그렇다고 제품이 자동으로 만들어지는 것은 아니에요. 제품 화면과 사용자 경험은 여전히 우리 팀이 만들어요. 대신 반복되는 백엔드 기반을 빌려 쓰는 거예요.
부트페이 커머스도 비슷해요. 쇼핑몰을 자동으로 만들어주는 빌더가 아니에요. 대신 독립몰에 필요한 상품, 고객, 주문, 결제, 구독 흐름을 API로 제공해요. 개발자는 이 레이어를 붙이고, 우리 서비스의 프론트와 운영 흐름을 만들어요.
쉽게 말하면 이래요.
| 필요한 기반 | 일반 BaaS | 부트페이 커머스 |
|---|---|---|
| 로그인·DB·스토리지 | Supabase 같은 BaaS | 직접 담당 영역 아님 |
| 상품·고객·주문 | 직접 테이블 설계 | API와 관리자 기준 제공 |
| 결제 연결 | 결제 API 별도 조합 | 주문 흐름 안에서 결제 연결 |
| 취소·상태 관리 | 직접 로직 설계 | 주문 상태와 웹훅 기준 제공 |
| 구독 운영 | 스케줄러와 실패 처리 직접 설계 | 구독 흐름 제공 |
그래서 부트페이 커머스를 “쇼핑몰 솔루션”으로 보면 조금 어긋나요. 더 정확히는 우리 프론트에 붙이는 커머스 백엔드예요. 쇼핑몰 오픈소스를 통째로 운영하는 대신, 필요한 커머스 기능을 API로 가져와 쓰는 방식이에요.
3부트페이 커머스가 맡는 것
부트페이 커머스는 쇼핑몰 운영에 필요한 기본 단위를 제공해요.
| 기능 | 쉽게 말하면 | 언제 쓰나 |
|---|---|---|
| 상품 | 팔 물건을 등록하는 기준 | 상품명, 가격, 옵션, 판매 상태를 관리할 때 |
| 고객 | 누가 샀는지 남기는 기준 | 회원 주문, 비회원 주문, 고객 그룹이 필요할 때 |
| 주문 | 구매 건을 남기는 기준 | 주문 번호, 결제 상태, 취소 상태를 관리할 때 |
| 체크아웃 | 고객이 결제하는 주문서 | 우리 프론트에서 주문서 결제를 열 때 |
| 링크페이 | 링크로 보내는 결제 | 개발 없이 SMS·카카오·이메일로 결제 링크를 보낼 때 |
| 구독 | 반복 결제 상품 | 멤버십, 정기 배송, SaaS 요금제를 운영할 때 |
| 마켓플레이스 | 여러 판매자로 확장되는 구조 | 나중에 판매자, 정산, 수수료가 붙을 가능성이 있을 때 |
핵심은 결제도 주문 안에 들어간다는 점이에요. 쇼핑몰에서는 고객이 결제만 하는 게 아니라 상품을 주문하고 결제해요. 운영팀도 결제 건만 보는 게 아니라 주문 건을 봐요. 그래서 독립몰을 만들 때는 결제 API보다 커머스 API가 먼저예요.
커머스 API로 안 되는 특수한 결제 UI나 결제 제어가 있을 때만 결제 API를 부분적으로 보면 돼요.
4외주 견적에서 줄어드는 범위
외주 견적이 커지는 이유는 화면 때문만이 아니에요. 상품 DB, 주문 DB, 고객 DB, 결제 매핑, 취소 처리, 관리자 화면까지 모두 범위에 들어가기 때문이에요.
부트페이 커머스를 쓰면 견적의 기준을 바꿀 수 있어요.
| 직접 개발 범위 | 커머스 BaaS를 쓸 때 |
|---|---|
| 쇼핑몰 백엔드 전체 설계 | 부트페이 커머스 API 연동 |
| 상품·주문·고객 테이블 설계 | 제공되는 상품·주문·고객 기준 활용 |
| 결제 결과와 주문 상태 매핑 | 주문 흐름 안에서 결제 연결 |
| 취소·상태 변경 로직 구현 | 제공되는 주문 상태와 웹훅에 맞춰 동기화 |
| 관리자 화면 직접 구축 | 필요한 운영 화면만 최소 구현 |
이렇게 나누면 개발자분이 해야 할 일도 명확해져요. “쇼핑몰을 전부 만들어달라”가 아니라 “부트페이 커머스에 상품·주문·결제를 맡기고, 우리 서비스 화면과 필요한 연결만 구현해요”가 돼요.
5언제 쓰면 좋은가
아래에 2개 이상 해당하면 커머스 API부터 검토해요.
- 독립몰이나 브랜드몰을 직접 열고 싶어요.
- AI로 프론트는 만들 수 있지만 쇼핑몰 백엔드가 부담스러워요.
- 상품이 여러 개이고 가격이나 판매 상태가 바뀔 수 있어요.
- 고객이 주문 내역을 봐야 해요.
- 결제 완료 이후 주문 상태를 관리해야 해요.
- 취소나 부분 취소가 생길 수 있어요.
- 운영 담당자분이 주문을 확인해야 해요.
- 구독 상품이나 반복 결제 가능성이 있어요.
- 나중에 마켓플레이스나 정산 구조로 확장될 수 있어요.
반대로 후원금, 단건 결제, 단일 권한 부여처럼 “돈만 받으면 끝”인 서비스라면 결제 API만으로도 충분해요.
다음 단계
쇼핑몰을 만들기로 했다면 개발 범위를 이렇게 나눠요.
- 프론트는 우리가, 백엔드는 부트페이 API로 개발해요.
- 상품·고객·주문·결제 로직은 부트페이 커머스에 맡겨요.
- 쇼핑몰 페이지, 상품상세, 마이페이지 등 우리 서비스에 맞는 브랜드, 디자인은 직접 개발해요.
- 커머스 기본 흐름으로 안 되는 결제 예외만 결제 API로 보완해요.