처음 서비스를 팔기 전 확인할 목록
코드는 끝났는데 파는 준비가 안 되어 출시가 밀리는 경우가 많습니다. 미리 목록으로 만들어 두면 며칠이 줄어듭니다.
서비스를 팔기 전에 가장 먼저 확인할 것은 무엇인가요?
결제입니다. Stripe가 한국에서 정산되지 않는다는 사실을 개발이 끝난 뒤에 알면 구조를 다시 짜야 합니다. 결제는 가격 정책·환불·구독 갱신이 전부 얽혀 있어 나중에 바꾸기가 가장 어렵습니다.
결제
- 결제 수단 결정(MoR / PG)
- 가격 페이지
- 세금 서식 제출
- 정산 계좌 등록
- 환불 처리 절차
정책·법
- 이용약관
- 개인정보 처리방침
- 환불정책
- 사업자 정보 표기(국내 판매 시)
- 통신판매업 신고(해당 시)
보안
- HTTPS 적용
- 비밀번호 저장 방식 점검
- API 키 노출 여부 확인
- 관리자 페이지 접근 제한
- 백업
저장소에
.env나 키 파일을 올리지 않았는지 반드시 확인하세요. 공개 저장소를 스캔하는 봇이 상시 돌고 있습니다.운영
- 문의 받을 창구
- 장애 시 알림
- 결제 실패 처리
- 이용자 데이터 내보내기
- 서비스 종료 시 절차
출시 후 첫 주에 볼 것
| 지표 | 왜 |
|---|---|
| 가입 → 첫 사용 전환 | 온보딩이 막히는지 |
| 결제 시도 → 성공률 | 결제 오류가 없는지 |
| 오류 로그 | 특정 브라우저에서만 깨지는지 |
| 문의 내용 | 설명이 부족한 지점 |
출시 전 마지막 일주일에 할 일
D-2의 지인 테스트가 가장 많은 문제를 잡아냅니다. 만든 사람은 막히는 지점을 무의식적으로 피해 가기 때문입니다.
| 일자 | 할 일 |
|---|---|
| D-7 | 결제 전 과정 테스트 (결제·환불·실패) |
| D-5 | 정책 페이지 최종 확인, 사업자 정보 대조 |
| D-4 | 다른 브라우저·모바일에서 전체 흐름 확인 |
| D-3 | 에러 알림·백업 동작 확인 |
| D-2 | 지인 3명에게 실제로 써보게 하기 |
| D-1 | 메타 태그·사이트맵·robots.txt 확인 |
| D-Day | 공개 후 첫 24시간 로그 지켜보기 |
결제 관련 테스트 항목
- 정상 결제 — 성공 화면과 안내 메일이 나가는가
- 결제 실패 — 카드 거절 시 안내가 명확한가
- 중복 결제 — 새로고침이나 뒤로가기로 두 번 결제되지 않는가
- 환불 — 실제로 환불이 되고 권한이 회수되는가
- 구독 갱신 — 다음 결제가 정상 발생하는가
- 해지 — 해지 후 언제까지 쓸 수 있는가
중복 결제는 실제로 자주 발생하고 신뢰를 크게 해칩니다. 주문 식별자를 서버에서 생성하고 같은 주문은 한 번만 승인되게 막아야 합니다.
출시 직후 24시간
첫날은 개발하지 말고 지켜보는 데 쓰는 편이 낫습니다. 예상하지 못한 사용 패턴이 반드시 나옵니다.
- 에러 로그를 실시간으로 봅니다
- 가입한 사람이 어디서 멈추는지 확인합니다
- 결제 시도 대비 성공률을 봅니다
- 문의가 오면 즉시 답합니다 — 초기 사용자는 특히 중요합니다
빠뜨리기 쉬운 것들
| 항목 | 빠뜨리면 |
|---|---|
| 안내 메일 발신 설정 | 스팸함으로 가서 아무도 못 봄 |
| 비밀번호 재설정 | 로그인 못 하는 사람이 이탈 |
| 모바일 결제 화면 | 절반 이상이 모바일입니다 |
| 세금계산서·영수증 | 사업자 고객이 요구합니다 |
| 이용약관 동의 기록 | 분쟁 시 근거가 없습니다 |
| 데이터 내보내기 | 해지 시 분쟁 소지 |
출시는 끝이 아니라 시작입니다
출시하면 사람이 올 것 같지만, 대부분 아무 일도 일어나지 않습니다. 이건 실패가 아니라 정상입니다.
출시 이후가 진짜 일입니다. 첫 사용자를 직접 찾고, 쓰는 걸 보고, 막히는 곳을 고치는 과정이 몇 달 이어집니다.
체크 상태를 저장하면서 보시려면
이 글의 항목을 제품·결제·세금·법무·유입·운영 여섯 갈래로 나눠 체크박스로 만들어 두었습니다. 브라우저에 저장되어 다음에 열어도 남아 있습니다.
해외 SaaS 출시 체크리스트 →자주 묻는 질문
완벽하게 만든 뒤 내야 하나요?
결제와 정책, 보안만 갖춰지면 나머지는 쓰면서 고치는 편이 낫습니다. 다만 이 세 가지는 미루면 안 됩니다.
베타로 먼저 내는 게 나을까요?
“베타”라는 표시가 버그를 용인해 주지는 않습니다. 다만 기대치를 낮추는 효과는 있습니다. 결제를 받는다면 베타든 아니든 동일한 책임이 따릅니다.
언제 출시해야 하나요?
한 사람이 실제로 문제를 해결할 수 있으면 충분합니다. 기능을 더 넣는 것보다 실제 사용을 보는 편이 배움이 큽니다.
같이 보면 좋은 글
서비스에 반드시 있어야 하는 정책 페이지결제 심사에서 가장 많이 걸리는 부분. 무엇을 어떻게 써야 하는지. 정책 페이지가 없으면 결제 심사에서 막힙니다. 그리고 분쟁…혼자 만든 서비스의 가격을 정하는 법원가 기준으로 정하면 대부분 너무 싸집니다. 가격을 정하는 실질적인 기준. 가격을 원가 + 마진으로 정하면 거의 항상 너무 쌉…한국에서 Stripe를 못 쓸 때 무엇으로 결제를 받나한국 법인·개인은 Stripe 정산을 받을 수 없습니다. 실제로 쓸 수 있는 대안과 각각의 수수료 구조. 만드는 건 며칠이면 …MoR과 일반 PG는 무엇이 다른가수수료만 비교하면 잘못된 선택을 합니다. 세금 책임이 누구에게 있는지가 핵심입니다. MoR은 수수료가 비싸 보입니다. 그런데 …Paddle을 한국 사업자로 설정할 때 막히는 지점가입은 되는데 심사에서 막히거나 세금 정보에서 헤맵니다. 준비할 것과 순서. Paddle은 심사가 있습니다. 서비스가 실제로 …국내에 디지털 상품을 팔 때 필요한 것통신판매업 신고, 청약철회 제한, 표기 의무. 국내 판매 특유의 요건. 해외 판매와 국내 판매는 요구되는 것이 다릅니다. 국내…