결제 도입 일정·오픈 런북: 2·4·6주 일정표와 D-21→D-Day 체크리스트

핵심 요약

결제 일정이 밀리는 가장 큰 이유는 연동이 아니라 서비스 완성도가 부족한 상태에서 심사를 넣기 때문이에요. PG 보완이 나오면 기획자만 문구를 고치는 게 아니라 개발자가 화면, 상태 처리, 예외 케이스를 다시 손봐야 해요.
현실적인 결제 도입 일정은 2주 / 4주 / 6주로 나눠 판단해요. 단건·단순 판매는 2주, 대부분의 SaaS·예약·디지털 서비스는 4주, 구독·포인트·예약 규칙이 복잡하면 6주로 잡는 편이 안전해요.
오픈 직전 3주는 D-21 → D-Day 주차별 런북으로 관리해요. 기획자, 개발자, 운영 담당자분이 각자의 트랙에서 동시에 움직여야 해요.
오픈 당일은 직전 30분, 직후 1시간, 24시간 모니터링으로 나눠 점검해요. 런북 없이 오픈했다가 벌어지는 3대 삽질은 운영키 누락, 웹훅 유실, CS 취소 패닉이에요.

이런 상황이라면

대표님은 "결제 붙이는 건 금방 아니야?"라고 묻고, 개발자분은 "연동 자체는 며칠이면 됩니예요"라고 답해요. 그래서 팀은 2주 안에 오픈 가능하다고 생각해요.
그런데 실제로는 그 다음이 문제예요. 심사 단계에서 취소·환불 기준, 사이트 하단 정보, 상품 설명, 결제 후 제공 흐름, 상태 처리 기준을 다시 보게 돼요. 여기서 보완이 나오면 기획자만 수정하고 끝나는 게 아니라, 개발자도 실제 사이트를 다시 고쳐야 해요. 결제 완료 후 상태 표시, 취소 후 주문 처리, 실패 시 재시도 안내 같은 부분을 손봐야 하기 때문이에요.
오픈 일주일 전, 슬랙에는 질문만 난무해요. "PG 심사 나왔나요?", "취소는 누가 어떻게 하죠?", "오픈 버튼 누가 누르나요?"

결국 일정이 밀리는 건 단순히 심사 기간 때문만이 아니라, 보완 요청이 서비스 수정으로 이어지기 때문이에요. 이 글은 현실적인 일정 산정과 D-21→D-Day 주차별 런북을 한 문서에 정리했어요.

1결제 일정은 왜 항상 늦어지나

많은 팀이 결제 일정을 짧게 보는 이유는, SDK를 붙이는 시간만 계산하기 때문이에요. 하지만 실제 오픈 일정에는 아래가 같이 들어가요.

상품/가격 노출
사이트 하단 정보 정리
취소·환불 기준 정리
결제 후 제공 흐름 확인
실패/취소/환불/검증 지연 상태 처리
PG 심사와 보완 대응

즉, 결제 일정은 결제창 연동 일정이 아니라 서비스를 상거래 가능한 상태로 만드는 일정이에요.

보완이 나오면 왜 일정이 더 늦어지나

보완 요청은 보통 문구만 고치면 끝나는 일이 아니에요.

보완 항목	실제로 같이 손봐야 하는 것
취소·환불 기준 보완	약관, 주문 화면 문구, 고객 안내 문구
상품 설명 부족	상품 상세, 가격 노출, 결제 진입 화면
결제 후 제공 흐름 불명확	완료 화면, 주문 상태, 기능 오픈 시점
상태 처리 부족	실패 화면, 재시도, 취소 후 상태 복구, 웹훅 반영
사이트 하단 정보 부족	푸터, 사업자 정보, 정책 링크

보완이 한 번 나오면 보통 이렇게 돼요.

기획자가 보완 내용을 해석해요
개발자가 실제 사이트를 수정해요
다시 캡처를 떠요
다시 제출하고 기다려요

이 왕복이 일정 지연의 핵심이에요.

2현실적인 2주 / 4주 / 6주 일정표

2주 일정

대상: 단건 결제, 단순 상품 판매, 기본 결제 흐름
전제: 상품/가격/약관/사이트 하단 정보가 이미 준비돼 있음
조건: 심사 보완이 거의 없거나, 있어도 문구 수정 수준

기간	할 일
1주차	샌드박스 연동, 기본 결제 흐름 확인, 심사 제출 준비
2주차	PG 심사, 승인 후 운영 반영

서비스 완성도가 이미 높은 경우에만 가능해요.

4주 일정 (가장 현실적)

대상: 대부분의 SaaS, 예약, 디지털 서비스
전제: 기본 기능은 있지만 운영 문구와 상태 처리가 덜 정리된 상태
조건: 보완이 1회 정도 나와도 흡수 가능

기간	할 일
1주차	상품/가격/정책/사이트 하단 정보 정리
2주차	샌드박스 연동, 결제 상태별 화면 점검
3주차	PG 심사 신청, 보완 대응
4주차	수정 반영, 재제출, 승인 후 운영 전환

6주 일정

대상: 구독, 포인트/크레딧, 예약/취소 규칙이 복잡한 서비스
전제: 결제 상태에 따라 서비스 동작이 많이 달라짐
조건: 보완이 나오면 개발 반영 범위가 넓을 수 있음

기간	할 일
1주차	상품 구조, 취소·환불 기준, 운영 정책 정리
2주차	주문/결제 상태 설계, 예외 케이스 정의
3주차	샌드박스 연동, 완료/실패/취소 흐름 구현
4주차	PG 심사 신청, 보완 항목 확인
5주차	개발 반영, 화면/정책 수정, 캡처 재정리
6주차	재제출, 승인, 운영 반영

구독이나 포인트형 서비스는 보완 = 개발 수정이 되는 경우가 많아서 이 정도를 보는 편이 안전해요.

3일정 산정에서 반드시 넣어야 하는 결제 상태 케이스

결제는 성공만 구현한다고 끝나지 않아요. 심사나 운영에서 다시 보는 건 보통 아래 케이스예요.

결제 성공
결제 실패
결제 취소
환불 처리
결제 승인 후 검증 지연
결제창 이탈 후 복귀

이 케이스를 서비스에서 어떻게 보여주고, 주문 상태를 어떻게 맞출지 준비가 안 되어 있으면 보완이 길어져요.

케이스	같이 정해야 하는 것
결제 성공	언제 주문 완료로 볼지
결제 실패	어떤 메시지와 재시도 경로를 줄지
결제 취소	주문 상태를 어떻게 되돌릴지
환불 처리	고객에게 어떤 기준으로 안내할지
검증 지연	완료로 볼지, 확인 중으로 둘지

4D-21 → D-Day 주차별 런북

이 3주 런북은 이미 개발팀이 테스트 키로 결제 연동을 완료하고, PG 심사를 신청하려는 시점을 기준으로 해요. 테스트 키 연동이 먼저 완료되어야 심사 신청이 가능하다(병렬 진행 불가). 연동 방식(SDK, API)도 아직 정하지 않았다면 이 런북보다 2주는 더 확보해야 해요.

결제는 혼자 하는 게 아니에요. 기획자, 개발자, 운영 담당자가 각자의 트랙에서 동시에 움직여야 해요. 아래 테이블을 팀 공통 문서에 복사해두고 매주 체크하길 권해요.

구분	기획자 (PM)	개발자 (Dev)	운영 / CS
Week -3 (준비/신청)	PG 심사 서류 제출 및 보완, 이용약관/환불 정책 확정	테스트 키 연동 완료, 웹훅 수신 로직 검증	PG 관리자 계정 권한 할당, 취소/환불 시나리오 초안 작성
Week -2 (QA/검증)	결제 UX/UI QA (모바일/웹), 심사 현황 모니터링	상용 환경 인프라 세팅 (DB/Server), 에러 로그 모니터링 구축	CS 대응 스크립트 작성, 취소 권한자 지정
Week -1 (라이브 세팅)	PG 심사 승인 확인, 최종 서비스 점검 및 공지 준비	운영키(Production Key) 반영, 상용 환경 결제 테스트(테스트 모드)	PG 상점 관리자 매뉴얼 숙지, 정산 주기 확인
D-Day (오픈)	라이브 전환 승인, 첫 결제/취소 모니터링	라이브 스위치 온, 실결제 데이터 검증	CS 유입량 모니터링, 부정 결제 감시

5D-Day 체크리스트

오픈 당일, 정신없는 슬랙 채널에서 중심을 잡아줄 체크리스트예요. 그대로 복사해서 D-Day 아침에 팀 채널에 공유해요.

오픈 직전 30분 (Final Sync)

운영 키 확인: 설정 파일에 테스트 키가 아닌 실제 상용 키(API Key/Secret)가 들어있는가?
DB 연결: 상용 DB에 결제 관련 테이블이 정상적으로 생성되어 있는가?
웹훅(Webhook) URL: 상용 서버의 도메인이 정확히 입력되어 있는가? (localhost나 dev 서버 주소 금지)
도메인 허용: PG사 관리자 페이지에 실제 서비스 도메인이 허용 등록되었는가?

오픈 후 1시간 (Smoke Test)

실결제 테스트: 팀원 개인 카드로 1,000원 이상 결제를 진행해봐요
자동 취소 테스트: 결제 직후, 서비스 내 '결제 취소' 버튼이 정상 작동하며 PG사 전산에도 취소(reversal)가 반영되는가?
데이터 확인: DB의 결제 상태값이 정상 반영되는가? (PG 웹훅 수신하여 내부 상태를 '결제 완료'로 변경)
알림톡/메일: 결제 완료 후 사용자에게 발송되는 알림이 정상적으로 가는가?

오픈 후 24시간 (Monitoring)

결제 성공률: 결제 시도 대비 성공률이 비정상적으로 낮지 않은가? (특정 카드사 장애 등)
정기 배치: (구독형의 경우) 첫 정기 결제 예약 건들이 문제없이 생성되었는가?
CS 인입: '결제가 안 돼요' 문의가 특정 OS나 브라우저에서 집중되지 않는가?
정산 리포트: PG 관리자 페이지에서 전날 결제된 내역이 리포트로 잘 잡히는가?

6삽질 포인트: 런북 없이 오픈했다가 벌어지는 3가지

1) "결제했는데 왜 내역이 없죠?" (운영키 누락)

가장 흔한 사고예요. 테스트 환경에서 잘 되던 게 라이브에서 안 되는 이유는 99% 운영키 설정 오류예요. 개발자가 로컬 환경 설정을 상용 서버에 그대로 배포하거나, PG 관리자에서 발급받은 실제 키값을 설정 파일(env)에 반영하지 않았을 때 발생해요. '오픈 직전 30분' 체크가 필요한 이유예요.

2) 웹훅 URL이 유령 서버를 가리킴

결제는 성공했는데 서비스 내에서 상품 배송이나 예약 확정이 안 된다면 웹훅 문제일 확률이 높아요. PG사가 결제 결과를 서버로 쏴주려는데 그 주소가 테스트 서버(dev-api.example.com)로 되어 있으면 상용 서버는 결제 사실을 영영 몰라요. 반드시 상용 도메인으로 업데이트했는지 확인해요.

3) CS 담당자분의 "취소 패닉"

기획자와 개발자분은 결제 버튼을 만드는 데 집중하지만, 고객은 취소 버튼을 더 찾아요. 오픈 당일 고객이 "잘못 결제했어요, 취소해 주세요"라고 할 때, CS 담당자분이 PG 관리자 페이지 로그인 방법조차 모른다면 대참사가 발생해요. 운영 담당자분이 PG사 관리자에서 '취소(Cancel)' 버튼을 누를 줄 아는지 미리 리허설해요.

7최종 체크리스트

우리 서비스 일정이 2주 / 4주 / 6주 중 어디에 해당하는지 합의했어요
실제 판매 상품(서비스)을 최소 3개 이상 등록하고 가격을 표기했어요
상품, 가격, 사이트 하단 정보, 약관이 정리돼 있어요
샌드박스 모드에서 결제 흐름을 확인했어요
결제 성공 / 실패 / 취소 / 환불 / 검증 지연 케이스를 점검했어요
PG 보완이 나오면 개발 수정까지 필요할 수 있다는 점을 일정에 반영했어요
대표님과 팀에 "연동 기간"이 아니라 "보완 포함 일정"으로 공유했어요
D-21 → D-Day 주차별 런북을 팀 공통 문서에 공유했어요
D-Day 당일 30분/1시간/24시간 체크리스트 담당자가 정해져 있어요