Stripe 결제·사용량 추적·랜딩 페이지를 한 주에 완성한 과정

Week 5에 Stripe 결제 연동, 사용량 추적, 그리고 랜딩 페이지 마무리 작업 세 가지를 한 커밋에 묶었다. 커밋 메시지에 billing+usage+copy를 슬래시로 구분해 나열한 게 이미 이 주의 밀도를 말해준다.

왜 이 세 가지를 한 주에 묶었나

원래 계획상 Stripe 연동은 Week 4 후반에 마무리됐어야 했다. 근데 체크아웃 플로우 쪽에서 웹훅 이벤트 처리 순서 문제가 생겨서 하루 이틀 밀렸고, 그게 도미노처럼 usage 트래킹 작업에도 영향을 줬다. 결국 Week 5에 세 작업이 동시에 착지하게 된 것.

팀 입장에서는 이런 상황이 생기면 우선순위 결정이 중요하다. 내가 판단한 순서는 이랬다:

• Stripe wiring 먼저 — 결제가 안 되면 나머지 UI 작업이 의미 없음
• Usage tracking 둘째 — 과금 기준이 되는 데이터 파이프라인이 결제 직후 붙어야 함
• Landing polish 마지막 — 가장 사용자가 많이 보는 화면이지만, 앞 두 개가 안 되면 전환 자체가 무의미

실제로 이 순서는 바꾸기 어렵다. 결제 연동 없이 랜딩만 예쁘게 해봤자 전환 후 구멍이 생기고, 사용량 추적 없이 결제를 열면 과금 정합성이 무너진다.

변경 파일별로 뭘 한 건지

checkout-button.tsx가 핵심이었다. Stripe의 createCheckoutSession을 서버 액션으로 호출하고, 반환된 url로 리다이렉트하는 구조인데, 클라이언트에서 직접 Stripe 키를 노출하지 않는 게 기본이라 이 부분을 서버 사이드로 분리하는 게 중요했다.

// checkout-button.tsx 패턴 (개념)
async function handleCheckout(priceId: string) {
  const { url } = await createCheckoutSession({ priceId });
  if (url) window.location.href = url;
}

클라이언트 버튼에서 price ID만 넘기고, 실제 세션 생성 로직은 서버에서 처리하는 방식. 이렇게 하면 Stripe secret key가 브라우저에 절대 노출되지 않는다. 팀원들한테 코드리뷰 때 항상 강조하는 부분이다 — "Stripe publishable key랑 secret key는 다른 거다, 절대 혼용하지 마라."

Usage Tracking을 대시보드에 연결하면서

usage/page.tsx는 사용자가 현재 플랜에서 얼마나 썼는지 보여주는 화면이다. 이걸 제대로 만들려면 단순히 숫자 표시가 아니라 어디서 데이터를 가져오냐가 관건이다.

Stripe에는 UsageRecord라는 개념이 있어서 종량제 과금 모델에서는 이걸 활용한다. 하지만 이 프로젝트에서는 자체 사용량 집계를 DB에서 직접 조회하고, Stripe 구독 상태는 별도로 확인하는 구조로 갔다. 이유는 Stripe API 호출 비용과 레이턴시 문제 — 대시보드를 열 때마다 외부 API를 치는 건 UX 측면에서 좋지 않다.

이런 구조를 선택할 때 트레이드오프는 명확하다:

• Stripe 직접 조회: 항상 정확하지만 느리고 API 비용 발생
• 자체 DB 집계: 빠르고 비용 없지만, 동기화 타이밍에 따라 약간의 지연 발생 가능

Week 5 기준에서는 자체 DB 집계를 선택했다. 실시간 정합성이 결정적으로 중요한 구간(예: 한도 초과 차단)에서만 Stripe 상태를 한 번 더 확인하는 식으로 보완할 예정.

랜딩 polish 작업 회고

features/page.tsx와 루트 page.tsx의 카피 작업은 사실 개발자가 직접 하기엔 경계가 애매한 영역이다. 이번엔 디자이너나 마케터 없이 내가 직접 카피 방향을 잡고 섹션을 재배치했는데, 항상 느끼는 거지만 "어떤 정보를 먼저 보여줄 것인가"는 순수하게 기술 문제가 아니다.

피처 페이지에서 섹션 재배치를 결정할 때 내가 기준으로 삼은 건 "사용자가 가장 먼저 궁금해할 것"의 순서다. 상세 스펙보다 "이게 나한테 어떤 도움이 되냐"가 먼저 나와야 한다는 원칙. 이걸 팀원들이랑 공유하고 싶어서 PR 설명에 섹션 순서 변경 이유를 따로 적어뒀다.

Week 5가 밀도 높았던 건 맞는데, 이 세 축이 한 주에 맞물려 완성된 덕분에 Week 6부터는 실제 사용자 피드백을 받을 수 있는 상태가 됐다. 그게 이번 주 작업의 가장 큰 의미다.

끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.