MVP 만들고 끝? 결제 붙이는 순간 진짜 개발이 시작된다

한줄 요약

코드 완성보다 결제 연동이 더 어렵다 — MVP 이후 수익화까지의 실제 거리.

MVP(최소 기능 제품)를 빠르게 만드는 건 이제 어렵지 않다. 문제는 그 다음이다. 사용자에게 돈을 받는 순간, 개발의 난이도가 아니라 개발의 성격 자체가 바뀐다.

외주 개발사 입장에서 수십 개의 서비스 런칭을 지켜보면, 매번 같은 패턴이 반복된다. 클라이언트가 "기능은 다 됐으니까 결제만 붙이면 끝"이라고 생각하는 순간, 예상보다 두 배는 긴 일정이 시작된다. 이 글은 그 이유를 현장 관점에서 설명한다.

결제 연동은 기능이 아니라 인프라다

결제창을 화면에 띄우는 코드 자체는 어렵지 않다. PG사(결제대행사)가 제공하는 SDK를 붙이고, 콜백을 처리하면 겉으로는 동작한다.

진짜 문제는 그 아래에 있다. PG사 심사를 통과하려면 사업자등록증, 통신판매업 신고증, 개인정보 처리방침 게시, 환불 정책 명시가 기본으로 요구된다. 코드는 하루 만에 짤 수 있어도, 서류 심사는 영업일 기준으로 2주를 잡아야 한다. 카드사 심사가 따로 또 붙는 경우엔 일정이 더 늘어난다.

스타트업이나 1인 창업자가 이 지점을 가장 많이 놓친다. "개발은 끝났는데 왜 오픈이 안 되냐"는 질문의 대부분은 여기서 나온다.

무료일 때와 유료일 때, 버그의 무게가 다르다

무료 서비스에서 오류가 나면 불편하다. 유료 서비스에서 오류가 나면 사고다.

결제가 붙는 순간부터 에러 처리 방식이 완전히 달라져야 한다. 결제는 완료됐는데 서비스가 정상 제공되지 않는 케이스, 타임아웃으로 인한 중복 결제, 환불 처리 자동화 여부 — 이 세 가지를 사전에 설계하지 않으면 운영 초기에 반드시 터진다.

외주 개발 프로젝트에서도 마찬가지다. 클라이언트가 "결제만 추가해 달라"고 요청할 때, 단순히 PG 연동 공수만 산정하면 후반에 재작업이 생긴다. 에러 복구 로직, 결제 상태 로깅, 어드민에서 수동 처리할 수 있는 백오피스까지 세트로 설계해야 비로소 완성이다.

개인정보는 나중이 아니라 처음부터 설계해야 한다

사용자 데이터를 다루는 서비스라면, 개인정보 처리방침은 런칭 전에 반드시 완성돼 있어야 한다. 법적 의무이기도 하지만, 더 중요한 건 데이터 구조 자체가 개인정보 설계의 결과물이어야 한다는 점이다.

"안 보겠습니다"를 약속으로 남기는 것과, 구조적으로 볼 수 없게 만드는 것은 다르다. 민감한 사용자 데이터를 처리하는 서비스라면 후자가 맞다. 원본 데이터는 처리 후 즉시 삭제하고, 서버에 남기는 건 처리된 결과 요약뿐이어야 한다. 이 구조를 처음부터 설계하지 않으면 나중에 뜯어고치는 비용이 훨씬 크다.

외주 개발을 의뢰할 때도 마찬가지다. 개인정보 처리 흐름을 요구사항 단계에서 명확히 정의해야 한다. 개발이 끝난 뒤에 "이 데이터 어떻게 저장돼요?"라는 질문이 나오면, 이미 재설계 비용이 발생한 상태다.