Builder Notes

Supabase, Stripe, R2, Cloudflare를 활용한 보호된 다운로드

ImgKit이 로그인, 결제, 제품 액세스, 비공개 파일, 서명된 다운로드 URL을 어떻게 연결하는지 실용적으로 설명합니다.

유료 디지털 제품에는 지루하지만 중요한 기반이 필요합니다. 구매자는 결제를 하고, 로그인하여, 공개된 ZIP 링크를 노출하지 않고도 올바른 파일을 다운로드할 수 있어야 합니다.

ImgKit은 간단한 보호된 다운로드 패턴을 사용합니다.

  1. Supabase가 로그인을 처리합니다.
  2. Stripe가 결제(checkout)를 처리합니다.
  3. 애플리케이션이 제품 액세스를 기록합니다.
  4. R2가 비공개 파일을 저장합니다.
  5. Cloudflare Functions가 수명이 짧은 서명 URL을 반환합니다.

보호된 다운로드가 중요한 이유

유료 ZIP 파일이 공개 폴더에 있으면 URL을 아는 사람은 누구나 공유할 수 있습니다. 무료 샘플이라면 받아들일 수 있지만, 유료 제품에는 약한 조치입니다.

보호된 다운로드는 서버 측 확인을 추가합니다.

  • 사용자는 누구인가?
  • 이 사용자가 제품을 구매했는가?
  • 다운로드 자산이 활성화되어 있는가?
  • 서버가 임시 URL을 생성할 수 있는가?

사용자는 여전히 일반적인 브라우저 다운로드를 받지만, 영구 스토리지 경로는 공개되지 않습니다.

Supabase 로그인

Supabase는 ImgKit에 계정 신원을 제공합니다. 구매자는 이메일로 로그인하며, 그 계정에 결제와 다운로드를 연결할 수 있습니다.

초기 제품의 경우 이메일 로그인만으로 충분합니다. 보호된 파일을 다운로드하기 위해 구매자에게 복잡한 대시보드가 필요하지 않습니다.

Stripe 결제

Stripe는 결제 세션을 처리합니다. 구매자는 사이트에서 결제를 시작하고, 결제한 뒤 ImgKit으로 돌아옵니다.

그런 다음 서버는 완료된 세션을 제품 액세스와 연결해야 합니다. 웹훅과 결제 동기화 엔드포인트를 통해 이루어지면 구매자는 결제 직후 액세스를 확인할 수 있습니다.

제품 액세스

제품 액세스는 일반적인 멤버십 라벨과 분리되어야 합니다. 구매자는 한 제품을 소유하면서 다른 제품은 소유하지 않을 수 있습니다.

ImgKit의 경우, 종료된 Builder Case Study는 자체 제품 권한(entitlement)을 사용했습니다. 이 모델은 모든 구매자를 광범위한 구독 회원으로 만들지 않고도 향후 제품이 존재할 수 있게 합니다.

R2 비공개 스토리지

R2는 실제 ZIP 패키지를 공개된 웹사이트 번들 외부에 저장합니다. 사이트는 R2 객체에 직접 링크하지 않습니다.

대신 다운로드 엔드포인트가 액세스를 확인하고 스토리지에 임시 URL을 요청합니다.

서명 URL

서명 URL은 비공개 파일에 대한 임시 액세스를 제공합니다. URL이 짧은 기간 후 만료되면 영구적으로 공유하기 어려워집니다.

이는 무거운 DRM이 아닙니다. MVP를 위한 실용적인 유료 배포 경계선입니다.

ImgKit이 배운 점

보관된 ImgKit Builder Case Study 페이지에는 주변 구현 결정이 남아 있습니다. 유료 소프트웨어 판매가 왜 중단되었는지, 보호된 다운로드가 어떻게 형성되었는지, 소스 코드 패키지가 첫 유료 오퍼로 어떻게 테스트되었는지 등입니다.

이 맥락은 중요합니다. 기술적 흐름은 제품의 절반에 불과하기 때문입니다. 나머지 절반은 무엇을 먼저 팔지 결정하는 것입니다.

자주 묻는 질문

유료 ZIP 파일을 공개 폴더에 두지 않는 이유는 무엇인가요?

공개 파일은 바로 공유될 수 있습니다. 보호된 배포는 서버가 계정 액세스 권한을 확인하고 수명이 짧은 다운로드 URL을 반환하도록 합니다.

Stripe가 파일을 저장하나요?

아니요. Stripe는 결제를 처리합니다. 제품 액세스와 다운로드 배포는 애플리케이션과 비공개 스토리지가 담당합니다.

왜 서명된 URL을 사용하나요?

서명된 URL을 사용하면 영구적인 스토리지 액세스를 노출하지 않고도 비공개 파일을 제한된 시간 동안 다운로드할 수 있습니다.

관련 가이드

다음 읽을 거리