Polar 결제 연동 라이브 전환 완료
목차
결제 연동이 LIVE 상태로 전환됐다. 문서 두 곳에 상태를 기록하고, 공식적으로 go-live를 선언한 날.
배경: 왜 상태 문서가 중요한가
개발하다 보면 코드 자체보다 "이게 지금 어느 단계냐"를 추적하는 게 더 어려울 때가 있다. 특히 외부 결제 제공자(Payment Provider)와 연동하는 과정은 단계가 꽤 많다. 개발 환경 테스트 → 샌드박스 검증 → 제공자 측 심사(approval) → 프로덕션 go-live. 어느 한 단계라도 빠지면 실사용자가 결제를 못하거나, 반대로 아직 검증 안 된 코드가 실계정에 붙어버리는 사고가 난다.
이번 커밋은 코드 변경이 아니다. CLAUDE.md와 docs/STATUS.md 두 파일에 Polar가 승인했고, go-live를 실행했다는 사실을 기록한 것. 변경 통계가 미지정이지만, 파일 두 개에 상태 레이블 몇 줄 바꾼 핀포인트 수정이었을 것이다. 그런데 이 "몇 줄"이 실제로는 꽤 묵직하다.
LIVE 전환, 실제로 무슨 의미인가
| 상태 | 의미 |
|---|---|
IN_PROGRESS / PENDING |
개발 진행 중 or 제공자 심사 대기 |
APPROVED |
제공자(Polar) 측 승인 완료 |
LIVE |
실사용자 트래픽에 실제 결제 흐름 활성화 |
Polar 같은 결제 인프라 제공자는 단순히 API 키 발급으로 끝나지 않는다. 비즈니스 정보, 계좌 연결, 결제 정책 검토 등 제공자 측 심사를 통과해야 실계정이 활성화된다. 이 심사 통과 시점이 APPROVED고, 그걸 실제 서비스 코드와 연결해서 트래픽을 붙인 게 LIVE 전환이다.
이 두 단계를 문서에 명확히 분리해두는 게 중요하다. "승인됐으니까 됐지"로 넘어갔다가 실제 go-live 실행을 깜빡하는 케이스도 있고, 반대로 승인 전에 프로덕션 엔드포인트를 미리 붙여놨다가 에러 로그 쌓이는 경우도 봤다. 상태를 명시적으로 추적하면 이런 실수가 줄어든다.
팀 관점에서 본 "상태 문서" 운영
혼자 짜는 사이드 프로젝트라도 이런 상태 문서를 두는 게 나는 습관이 됐다. 이유가 몇 가지 있다.
- 재현 가능한 맥락: 한 달 뒤에 "이 결제 연동 언제부터 살았더라?" 하고 커밋 로그 뒤지는 것보다,
STATUS.md한 파일이 훨씬 빠르다 - 온보딩 비용 절감: 나중에 누군가 합류했을 때, 각 기능/연동의 현재 상태를 바로 파악할 수 있다
- 의사결정 추적: "왜 이 시점에 LIVE로 전환했는가"가 커밋 메시지와 문서에 남으면, 이후 트러블슈팅에서 타임라인 재구성이 쉬워진다
CLAUDE.md에도 함께 기록한 건 아마 AI 컨텍스트 파일로 관리하는 구조인 것 같다. 요즘 LLM 보조 개발 환경에서는 프로젝트 상태를 CLAUDE.md 같은 파일에 정리해두고, 어시스턴트에게 "현재 어디까지 됐는지"를 빠르게 전달하는 패턴이 늘고 있다. 이것도 일종의 문서화 레이어인 셈이다.
회고
사실 go-live 당일은 코드보다 이런 문서 업데이트가 더 실감난다. 결제가 실제로 돌아가기 시작했다는 걸 공식적으로 선언하는 행위라서. Polar 심사가 통과되고 go-live를 실행하기까지, 연동 코드를 짜고 테스트하고 기다리던 과정이 이 커밋 한 줄로 닫혔다.
작은 커밋이지만, 이게 쌓이면 프로젝트 히스토리가 된다. 다음에 이 프로젝트를 다시 열었을 때, 또는 다른 결제 제공자를 추가 연동할 때, 이 STATUS.md가 기준점이 될 것이다.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.