27일 만에 돈을 받는 서비스가 되다

PG 신청에서 실결제까지, 27일의 기록

4월 19일에 포트원을 통해 PG 심사를 신청했다. 사업자등록증, 서비스 URL, 결제 플로우 설명서 같은 서류를 모아서 제출하고 나면 할 수 있는 건 기다리는 것뿐이다. 카드사마다 심사 기준이 다르고, 심사 속도도 제각각이라 어디서 막힐지 알 수 없었다.

5월 16일, 메일이 왔다. 9개 카드사 전원 승인.

하나도 빠짐없이 통과된 건 솔직히 좀 의외였다. 사주 해석이라는 서비스 특성상 어디선가 걸릴 수 있다고 생각했는데, 결과적으로는 깔끔했다. 아마 서비스 페이지에 이용약관, 환불정책, 개인정보처리방침을 미리 잘 갖춰놓은 게 주효했던 것 같다.

포트원 실연동: ID 3종 혼동의 함정

카드사 승인이 떨어지자마자 바로 실연동 작업에 들어갔다. 테스트 환경에서 실제 결제 환경으로 전환하는 과정은 생각보다 단순하지 않았다.

해야 할 일의 목록은 명확했다:

• 포트원 콘솔에서 실연동 채널 등록
• Vercel 환경변수를 테스트 키에서 라이브 키로 교체
• 코드 변경 없이 환경변수만으로 테스트→실결제 전환

그런데 여기서 예상 못한 에러가 터졌다. 결제 요청을 날리면 storeId is not correct라는 메시지가 돌아온다. 포트원의 ID 체계는 세 종류가 있다:

1. 상점 ID (Store ID) — 포트원 콘솔의 상점 식별자
2. 채널 키 (Channel Key) — 각 PG 채널별 키
3. 가맹점 식별코드 — V1 API에서 쓰이는 레거시 코드

이 셋을 혼동하면 딱 저런 에러가 난다. 나는 V2 API를 쓰고 있는데, V1 시절의 가맹점 식별코드를 storeId에 넣고 있었다. 포트원 콘솔을 다시 들여다보고 올바른 Store ID를 찾아 환경변수를 교체했더니 깨끗하게 해결됐다.

환경변수 3개를 교체한 것이 전부였다. 코드 한 줄 안 고치고 테스트에서 라이브로 넘어간 건, 처음 설계할 때 키를 전부 환경변수로 분리해둔 덕분이다. 이게 얼마나 중요한 습관인지 매번 느낀다.

4,000원의 첫 결제

환경변수를 바꾸고 나서 본인 카드로 직접 결제를 해봤다. 화조당에서 제공하는 사주 해석 서비스, 4,000원짜리 기본 상품.

결제 위젯이 뜨고, 카드번호 입력하고, 결제 완료. 포트원 콘솔에 실결제 내역이 찍혔다. 내 카드에서 4,000원이 빠져나간 걸 확인한 순간, 묘한 감정이 올라왔다.

이 서비스가 "돈을 받을 수 있는 서비스"가 된 거다.

PG 신청이 4월 19일, 실결제 검증이 5월 16일. 정확히 27일. 사업자등록증 발급, 통신판매업 신고, PG 신청, 카드사 심사 대기, 실연동까지의 전체 여정을 생각하면 27일은 꽤 빠른 편이라고 생각한다. 물론 이 기간 동안 결제만 기다린 게 아니라 서비스 자체를 계속 개발하고 있었으니, 체감상으로는 자연스러운 흐름이었다.

다음 날, SEO 전면 구축

5월 17일. 정식 서비스를 열었으니 이제 사람들이 찾을 수 있게 해야 한다. 정식 개시 다음 날, 기술 SEO를 전면적으로 깔았다.

이 작업은 나중에 하면 할수록 귀찮아지는 종류다. 처음부터 구조를 잡아놓으면 이후 페이지가 추가될 때 자동으로 적용되니까, 가능한 한 빨리 하는 게 맞다.

구축한 것들:

• sitemap.xml — Next.js의 generateSitemap 함수로 동적 생성
• robots.txt — 크롤러 허용 범위 설정
• 메타데이터 — 각 페이지별 title, description 동적 생성
• OG 카드 — 소셜 공유 시 미리보기 이미지와 텍스트
• hreflang 태그 — 다국어 대응 (현재는 ko 단일이지만 구조는 준비)
• JSON-LD 구조화 데이터 — 검색엔진이 서비스 정보를 이해하도록

여기서 중요한 판단 하나가 있었다. 화조당은 사주 해석 결과 페이지가 사실상 콘텐츠의 대부분인데, 이 페이지들은 개인 정보가 담긴 비공개 콘텐츠다. 검색엔진에 노출되면 안 된다.

그래서 공개 5페이지만 색인 허용하고, 나머지는 전부 noindex로 처리했다:

1. 메인 페이지 (/)
2. 사주 입력 페이지
3. 서비스 소개
4. 이용약관
5. 개인정보처리방침

이렇게 하면 검색엔진에는 서비스의 존재와 공개 정보만 노출되고, 사용자 개인의 사주 해석 결과는 절대 색인되지 않는다. SEO와 프라이버시, 두 마리 토끼를 잡는 설계다.

SEO 유틸리티 3파일

SEO 관련 로직을 깔끔하게 분리하기 위해 유틸리티 파일 3개를 새로 만들었다:

• lib/seo/metadata.ts — 페이지별 메타데이터 생성 함수. title 템플릿, description 규칙, OG 이미지 경로 등을 중앙 관리
• lib/seo/jsonld.ts — JSON-LD 구조화 데이터 생성. WebSite, WebApplication, FAQPage 스키마 지원
• lib/seo/sitemap.ts — 동적 sitemap 생성 헬퍼. 공개 페이지 목록과 우선순위, 변경 빈도 설정

이 3파일 구조의 장점은, 새 공개 페이지가 추가될 때 sitemap.ts의 배열에 한 줄만 추가하면 sitemap, robots, 메타데이터가 자동으로 따라간다는 것이다. 한 곳에서 관리하니까 빠뜨릴 일이 없다.

사주 해석 8번째 섹션 잘림 버그

SEO 작업 중에 사주 해석 결과를 다시 확인하다가 버그를 발견했다. 8개 섹션으로 구성된 사주 해석 결과에서 8번째 섹션이 잘려서 표시되는 문제였다.

원인은 예상대로 max_tokens 설정이었다. AI가 8개 섹션 전체를 생성하기에 8,000 토큰으로는 부족했던 거다. 각 섹션이 평균 800~1,000 토큰 정도를 차지하니, 8개 섹션이면 최소 6,400~8,000 토큰이 필요하고, 여기에 JSON 구조나 마크다운 포맷팅 오버헤드까지 더하면 8,000 토큰은 아슬아슬한 수준이었다.

max_tokens를 8,000에서 16,000으로 두 배 올렸다. 넉넉하게 잡아야 뒷부분이 잘리는 일이 없다. 비용이 소폭 증가할 수 있지만, 사용자가 돈을 내고 받는 결과물이 잘려 나오는 것보다는 훨씬 나은 선택이다.

이틀의 의미

5월 16일과 17일, 이틀 동안 화조당은 두 가지 결정적 전환을 이뤘다:

1. 무료 데모 → 유료 서비스: 실제로 돈을 받고 서비스를 제공할 수 있게 됐다
2. 비공개 → 검색 가능: 검색엔진을 통해 사람들이 서비스를 발견할 수 있게 됐다

27일 만에 완성한 결제 시스템, 그리고 그 다음 날 바로 깐 SEO. 이 두 가지가 갖춰지면 서비스는 비로소 "런칭"이라고 부를 수 있는 상태가 된다.

기술적으로 복잡한 일은 아니었다. 환경변수 3개 교체, SEO 유틸리티 3파일 생성, max_tokens 하나 수정. 하지만 이 작은 변경들이 모여서 서비스의 성격 자체를 바꿨다. 실험에서 사업으로. 그 전환점이 이 이틀이었다.