1인 창업가의 기본 기술 스택 선택

좋은 스택은 오래 버틸 수 있는 선택이다

1인 창업가에게 좋은 기술 스택은 최신 기술을 가장 많이 넣은 조합이 아니다. 혼자 만들고, 혼자 고치고, 혼자 비용을 감당할 수 있는 조합이다.

우리가 만들 서비스의 첫 흐름은 단순하다.

1. 사장님이 가입한다.

2. 매장 정보를 입력한다.

3. 리뷰 파일이나 텍스트를 업로드한다.

4. AI가 리뷰를 분석한다.

5. 반복 불만, 칭찬 포인트, 개선 액션, 답글 초안, 홍보 문구가 담긴 리포트를 보여준다.

6. 사장님이 리포트 링크를 저장하거나 공유한다.

이 흐름을 만들기 위해 처음부터 별도 백엔드 서버, 자체 인증 시스템, 쿠버네티스, 벡터 데이터베이스, 관리자용 대시보드를 모두 만들 필요는 없다. 첫 버전의 목표는 기술적으로 멋진 구조가 아니라 고객이 리포트를 받아보고 돈을 낼 만한지 확인하는 것이다.

따라서 기본 스택은 이렇게 정한다.

핵심은 한 가지다. 직접 만들지 않아도 되는 것은 관리형 서비스에 맡긴다.

다만 이 장에서 언급하는 무료 한도와 수수료는 고정된 약속이 아니라, 서비스를 고를 때 확인해야 할 기준선으로 봐야 한다. 클라우드와 결제 서비스의 가격 정책은 바뀔 수 있다. 실제로 가입하고 배포하기 전에는 반드시 공식 가격 페이지와 약관을 한 번 더 확인하자.

AI 생성 이미지

MVP 아키텍처를 한 장으로 그리기

우리 서비스의 최소 구조는 다음과 같다.

사용자 브라우저
  ↓
Next.js 앱 on Vercel
  ├─ 화면: 랜딩, 로그인, 업로드, 분석 결과, 공유 리포트
  ├─ 서버 로직: 업로드 처리, AI API 호출, 결제 웹훅 처리
  ↓
Supabase
  ├─ Auth: 사용자 로그인
  ├─ Postgres: 매장, 리뷰, 분석 작업, 리포트 저장
  ├─ Storage: CSV, 엑셀, 텍스트 파일 저장
  └─ RLS: 사용자별 데이터 접근 제한
  ↓
AI API
  └─ 리뷰 분석, 답글 초안, 마케팅 문구 생성

GitHub에 코드를 올리면 Vercel이 자동으로 배포한다. 사용자가 화면에서 리뷰 파일을 올리면 Supabase Storage에 파일이 저장되고, Next.js의 서버 로직이 파일 내용을 읽어 AI API에 분석을 요청한다. 분석 결과는 다시 Supabase Postgres에 저장한다. 리포트 화면은 저장된 결과를 불러와 보여준다.

여기서 중요한 보안 원칙이 있다. AI API 키, Supabase 서비스 키, 결제 시크릿 키는 브라우저에 노출하면 안 된다. 사용자가 보는 화면이 아니라 서버에서만 사용해야 한다. Next.js를 쓰는 이유 중 하나가 여기에 있다. 같은 프로젝트 안에서 화면과 서버 로직을 함께 다룰 수 있기 때문이다.

Next.js를 중심에 두는 이유

Next.js는 단순히 화면을 만드는 도구가 아니다. 초기 SaaS에서는 프론트엔드와 가벼운 백엔드 역할을 한 프로젝트 안에서 처리할 수 있다.

우리 서비스에서 Next.js가 맡을 일은 다음과 같다.

• 랜딩페이지와 회원가입 화면

• 리뷰 업로드 화면

• 분석 진행 상태 화면

• 리포트 상세 페이지

• 공유 가능한 공개 리포트 페이지

• AI API를 호출하는 서버 라우트

• 결제 성공·실패·웹훅을 받는 서버 라우트

별도의 백엔드 프레임워크를 붙이면 구조는 더 정교해질 수 있다. 하지만 1인 창업가에게는 계정, 배포, 로그, 환경변수, 장애 지점이 하나 더 늘어난다. 첫 버전에서는 그것이 장점보다 부담이 될 가능성이 크다.

단, Next.js 안에 모든 일을 무리하게 넣으면 안 된다. 예를 들어 수만 개 리뷰를 장시간 분석하거나, 여러 작업을 큐에 쌓아 순차 처리해야 하거나, 백그라운드 작업이 오래 돌아가야 한다면 별도 작업 큐나 서버가 필요해질 수 있다. 하지만 지금은 리뷰 30~300개 정도를 업로드해 리포트 하나를 만드는 수준에서 시작한다. 이 범위에서는 Next.js와 관리형 백엔드 조합이 충분하다.

Supabase를 백엔드로 쓰는 이유

Supabase는 PostgreSQL 데이터베이스를 중심으로 인증, 파일 저장, 권한 관리 기능을 함께 제공한다. PostgreSQL은 오래 쓰인 관계형 데이터베이스다. 사용자, 매장, 리뷰, 결제, 리포트처럼 서로 관계가 있는 데이터를 다루기에 적합하다.

첫 버전에서 Supabase에 만들 핵심 테이블은 많지 않다.

Supabase를 선택하는 가장 큰 이유는 인증과 데이터 권한을 함께 다룰 수 있다는 점이다. SaaS에서는 A사장님의 리뷰가 B사장님에게 보이면 안 된다. 이런 문제를 애플리케이션 코드만으로 막으려 하면 실수하기 쉽다. Supabase의 Row Level Security, 즉 행 단위 보안은 데이터베이스 차원에서 사용자별 접근을 제한하는 장치다.

또 하나의 이유는 비용이다. Supabase 무료 플랜은 프로젝트당 데이터베이스 500MB, 스토리지 1GB, 월간 활성 사용자 50,000명, Edge Functions 500,000회 호출 등의 한도를 제공한다.¹ 이 숫자가 크다는 뜻은 아니다. 오히려 첫 병목이 어디에서 올지 미리 보여준다. 리뷰 파일을 많이 저장하면 스토리지가 먼저 찰 수 있고, 리포트 공유가 많아지면 전송량이 먼저 문제가 될 수 있다.

Vercel과 GitHub는 배포 시간을 줄인다

Vercel은 Next.js 앱을 배포하기에 편한 선택지다. GitHub 저장소를 연결하면 main 브랜치에 코드를 올릴 때 자동으로 배포된다. 기능 브랜치나 Pull Request마다 프리뷰 URL도 만들 수 있다. 혼자 개발하더라도 이 프리뷰 URL은 유용하다. 결제 화면, 업로드 화면, 리포트 화면을 실제 주소에서 확인할 수 있기 때문이다.

Vercel 가격 페이지에는 Fast Data Transfer, Functions 호출, Web Analytics 같은 항목별 포함 사용량이 안내되어 있다. 예를 들어 Functions 호출 100만 회, Fast Data Transfer 100GB 같은 포함량은 초기 검증 단계에서는 충분할 가능성이 높다.² 하지만 무료 또는 저가 플랜의 한도는 사업 모델이 아니다. 사용량이 늘면 비용도 늘고, 서버리스 함수 실행 시간이나 로그 보관 기간 같은 제한도 체감하게 된다.

여기서 한 가지를 더 조심해야 한다. Vercel의 무료 Hobby 플랜은 개인적이고 비상업적인 프로젝트를 전제로 한다. 결제 기능을 붙여 돈을 받거나, 유료 서비스를 홍보하거나, 고객용 SaaS로 운영하려면 무료 한도만 보고 판단하면 안 된다. 실제 유료 실험을 시작할 때는 Pro 플랜 이상의 비용을 예산에 넣고, 상업적 사용이 약관에 맞는지 확인해야 한다.

GitHub는 코드 백업 이상의 역할을 한다. 기능을 고치다 문제가 생기면 이전 커밋으로 돌아갈 수 있다. 어떤 변경 때문에 오류가 생겼는지도 추적할 수 있다. 1인 창업가에게 버전 관리는 협업 도구가 아니라 생존 도구다.

AI API는 직접 학습보다 호출로 시작한다

리뷰 분석 서비스를 만든다고 해서 자체 AI 모델을 학습할 필요는 없다. 첫 버전에서는 OpenAI, Anthropic, Google 등 외부 AI API를 호출하는 방식이 현실적이다.

우리가 AI에 맡길 일은 명확하다.

• 리뷰를 긍정, 부정, 중립으로 분류하기

• 반복되는 불만 주제 찾기

• 자주 칭찬받는 강점 찾기

• 사장님이 실행할 수 있는 개선 액션 만들기

• 리뷰 답글 초안 작성하기

• 배달앱, 인스타그램, 문자에 쓸 홍보 문구 제안하기

여기서 비용을 결정하는 것은 대체로 토큰이다. 토큰은 AI가 읽고 쓰는 글자 조각이라고 이해하면 된다. 리뷰 원문이 길수록, 한 번에 많은 리뷰를 넣을수록, 결과물을 길게 받을수록 비용이 늘어난다.

그래서 처음부터 모든 리뷰를 한 번에 넣지 않는다. 리뷰를 일정 단위로 나누어 요약하고, 요약된 결과를 다시 합쳐 최종 리포트를 만드는 방식이 더 안전하다. 모델도 하나만 쓰지 않아도 된다. 단순 분류와 요약은 저렴한 모델로, 최종 액션 제안은 더 성능이 좋은 모델로 처리할 수 있다.

비용과 병목을 기준으로 보는 선택표

기술 선택은 취향이 아니라 병목 예측이다. 아래 표는 첫 버전에서 확인해야 할 기준이다.

특히 AI 비용은 초기에 반드시 계산해야 한다. 예를 들어 리포트 1건을 39,000원에 판매한다면, AI 분석 비용과 결제 수수료, 서버 비용을 뺀 뒤에도 충분한 마진이 남아야 한다. 처음에는 정확한 예측보다 상한선을 정하는 것이 중요하다. 리포트 1건당 AI 비용이 3,000원을 넘으면 경고, 5,000원을 넘으면 프롬프트와 처리 방식을 바꾸는 식으로 기준을 잡는다.

한국 독자를 위한 결제 선택

결제는 기술 문제가 아니라 사업 형태의 문제다. 같은 SaaS라도 고객이 한국 소상공인인지, 해외 사용자인지, 사업자가 한국에 있는지, 디지털 상품을 전 세계에 팔 것인지에 따라 선택이 달라진다.

TossPayments의 기본 흐름은 요청, 인증, 승인으로 나뉜다. 클라이언트가 결제창을 열고, 인증이 끝나면 paymentKey, orderId, amount가 돌아온다. 서버는 결제 요청 전에 저장해 둔 주문 금액과 돌아온 금액이 같은지 확인한 뒤 승인 API를 호출해야 한다.³ 이 검증을 생략하면 사용자가 결제 금액을 조작하는 상황을 막기 어렵다.

Lemon Squeezy는 디지털 상품 판매에 초점을 둔 결제 도구다. 공식 가격 페이지 기준으로 전자상거래 수수료는 거래당 5% + 50센트이며, Merchant of Record로서 판매세와 VAT의 계산, 징수, 신고를 대신 처리한다고 설명한다.⁴ 글로벌 판매를 빨리 테스트하는 1인 창업가에게는 운영 부담을 줄여주는 선택지가 될 수 있다. 다만 일부 결제에는 추가 수수료가 붙을 수 있으므로, 실제 상품 가격을 정할 때는 정산 금액을 직접 계산해 봐야 한다.

Stripe는 결제 처리와 구독 과금 기능이 강한 선택지다. 다만 Merchant of Record가 아니라면 세금, 환불, 분쟁, 정산 책임이 창업자에게 더 많이 남는다. 반대로 복잡한 구독, 사용량 기반 과금, 기업 고객 청구처럼 통제력이 중요한 SaaS에는 Stripe가 더 잘 맞을 수 있다.⁵

우리 예제 서비스는 한국 음식점·카페 사장님을 1차 고객으로 잡았다. 따라서 첫 유료 실험은 TossPayments를 우선 후보로 둔다. 다만 12장에서 결제를 붙이기 전까지는 payments 테이블을 특정 PG에 종속되지 않게 설계한다. provider, provider_payment_id, status, amount, currency 같은 필드를 두면 나중에 TossPayments에서 Lemon Squeezy나 Stripe로 확장할 여지가 생긴다.

지금은 만들지 않을 것들

기술 스택을 정할 때는 선택한 것보다 제외한 것이 더 중요하다. 첫 버전에서는 다음을 만들지 않는다.

• 자체 로그인 시스템

• 별도 백엔드 서버

• 쿠버네티스나 복잡한 클라우드 인프라

• 자체 AI 모델 학습

• 전용 벡터 데이터베이스

• 팀 계정과 권한 관리

• 자동 리뷰 답글 게시 기능

• 복잡한 관리자 대시보드

이 목록은 포기가 아니다. 순서의 문제다. 고객이 리포트에 돈을 내고, 반복 사용 의사가 확인되고, 데이터가 쌓이면 그때 필요한 구조로 확장한다.

이번 프로젝트의 최종 선택

이 책의 예제 서비스는 다음 조합으로 시작한다.

Next.js + TypeScript
Supabase Auth + Postgres + Storage + RLS
Vercel 배포
GitHub 저장소
AI API 서버 호출
결제는 한국 우선 TossPayments, 글로벌 실험은 Lemon Squeezy 검토

이 조합은 모든 상황에 맞는 정답이 아니다. 하지만 1인 창업가가 리뷰 업로드, AI 분석, 리포트 생성, 공유 링크까지 빠르게 만들고 운영하기에는 균형이 좋다. 직접 구축해야 할 부분을 줄이고, 제품의 핵심 가치인 실행 가능한 리뷰 리포트에 시간을 쓰게 해준다.

다음 단계부터는 이 선택을 실제 개발 환경으로 옮긴다. 저장소를 만들고, 로컬 개발 환경을 세팅하고, AI 코딩 파트너와 함께 첫 화면을 띄울 준비를 한다.

참고

¹Supabase 가격 페이지

²Vercel 가격 페이지

³토스페이먼츠 결제 흐름 이해하기

⁴Lemon Squeezy 가격 페이지

⁵Stripe와 Lemon Squeezy 비교 자료