일기 slecs

Polar 결제 연동 라이브 전환 완료

목차

결제 연동이 LIVE 상태로 전환됐다. 문서 두 곳에 상태를 기록하고, 공식적으로 go-live를 선언한 날.


배경: 왜 상태 문서가 중요한가

개발하다 보면 코드 자체보다 "이게 지금 어느 단계냐"를 추적하는 게 더 어려울 때가 있다. 특히 외부 결제 제공자(Payment Provider)와 연동하는 과정은 단계가 꽤 많다. 개발 환경 테스트 → 샌드박스 검증 → 제공자 측 심사(approval) → 프로덕션 go-live. 어느 한 단계라도 빠지면 실사용자가 결제를 못하거나, 반대로 아직 검증 안 된 코드가 실계정에 붙어버리는 사고가 난다.

이번 커밋은 코드 변경이 아니다. CLAUDE.mddocs/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

첫 댓글 달아줘.