Gumroad 제품을 위한 셀프 호스팅 라이선스 키 관리자를 만들었습니다 (현재까지 판매량 0건)

그래서 저는 차라리 직접 만들었습니다. 이름은 KeyMint이며, 직접 호스팅할 수 있는 라이선스 키 관리자(license key manager)입니다.

데모 (빈 껍데기처럼 보이지 않도록 시드 데이터가 포함되어 있습니다): https://keymint.pages.dev

실제로 하는 일
제품을 생성하고, 키 배치를 생성하여 배포합니다. 그런 다음 사용자의 소프트웨어가 단 한 번의 요청으로 키를 확인합니다:

const res = await fetch("https://your-keymint.app/api/validate", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ key, productSlug: "subsaver", activate: true }), }); const { valid } = await res.json();

대부분의 통합(integration)에서 핵심은 바로 그 valid 불리언(boolean) 값입니다. 응답은 또한 키가 왜 실패했는지(취소됨, 만료됨, 활성화 제한 도달, 잘못된 제품)와 활성화 횟수가 얼마나 남았는지를 알려주므로, 직접 로직을 작성하지 않고도 좌석 제한(seat limits)이나 기기 제한(device limits)을 구현할 수 있습니다. activate: true를 전달하면 확인과 동시에 활성화 횟수가 하나 차감됩니다.

대시보드는 지루한 측면들을 처리합니다: 대량 키 생성, 취소, 만료 날짜, 그리고 모든 확인 시도와 그 결과 및 IP를 기록하는 활동 로그(activity log)가 있습니다. 30일 트렌드 차트를 추가한 이유는 주로 빈 대시보드는 우울해 보이지만, 데이터가 채워진 대시보드는 단 2초 만에 아이디어를 팔 수 있기 때문입니다.

기술 스택, 그리고 고전했던 부분
프론트엔드는 React 19와 Vite, 백엔드는 Express 5와 Drizzle, 그 아래에는 Postgres를 사용하며, 모두 pnpm 모노레포(monorepo)로 구성되어 있습니다. 특별할 것은 없습니다.

돈이 없는 사람으로서 이를 배포하는 과정이 흥미로운 부분이었습니다. 프론트엔드는 정적(static)이므로 Cloudflare Pages에 무료로 올렸습니다. API는 Railway에 올렸습니다. 그러다 두 번째 서비스를 추가하려고 했을 때 Railway의 무료 티어(free-tier) 제한에 걸렸고, 제 Supabase 무료 프로젝트들은 이전의 두 앱 때문에 이미 가득 차 있었습니다. 그래서 데이터베이스는 결국 Neon에 두게 되었는데, Neon은 만료되지 않는 무료 티어에서 실제 Postgres 인스턴스를 제공합니다. 세 개의 제공업체를 사용하면서 한 달에 0달러를 씁니다. 스키마(schema)와 시드 스크립트(seed script)가 레포지토리(repo)에 있으므로, 자신만의 복사본을 실행하는 것은 SQL 붙여넣기와 두 번의 배포면 충분합니다.

기록해 둘 만한 주의 사항(gotcha)이 하나 있습니다. API를 esbuild로 번들링(bundle)하는데, pg가 서버 패키지의 직접적인 의존성(direct dependency)으로 나열되어 있어야 합니다. 그렇지 않으면 배포된 번들(bundle)이 런타임(runtime)에 이를 찾을 수 없습니다. 로컬에서는 잘 빌드되었지만, 이 문제를 발견하기 전까지는 첫 부팅 시 계속 충돌이 발생했습니다. 정확히 한 시간을 허비하게 만드는 그런 종류의 문제입니다.

솔직한 상태
판매량 0건입니다. 제품은 오늘 출시되었습니다. 저는 이제 이 과정을 충분히 많이 경험해 보았기에(이번이 저의 네 번째 보일러플레이트(boilerplate)입니다), "Gumroad에 게시하는 것"과 "누군가 그것을 구매하는 것" 사이에는 매우 큰 간극이 있으며, 그 차이는 제품이 아니라 배포(distribution)에 있다는 것을 알고 있습니다. 이 글을 쓰는 것은 그 간극을 메우기 위한 과정의 일부이며, 이것이 다소 순환 논리적이라는 점도 인지하고 있습니다.

가격은 49달러이며, MIT 라이선스(MIT licensed)가 적용되고 전체 소스 코드를 제공합니다. 의도적으로 구현하지 않은 기능은 다음과 같습니다: 결제를 처리하지 않습니다(돈이 아니라 키(key)를 관리합니다). 그리고 관리자 대시보드(admin dashboard)는 프라이빗하게 실행되도록 설계되었기 때문에 기본적으로 인증(auth) 기능이 없습니다. README에는 만약 대시보드를 외부에 노출하고 싶을 경우 이를 제한하기 위한 약 10줄 정도의 코드가 안내되어 있습니다. 은행 연동도 없고, 호스팅 버전도 없으며, 월간 비용도 전혀 없습니다.

원하신다면 링크는 여기 있습니다: https://ibrh96.gumroad.com/l/nvkfg

다른 제품들
만약 여러분이 보일러플레이트(boilerplates)를 구매하는 유형이라면, 제가 출시한 다른 세 가지 제품도 있습니다. 동일한 스택(stack)을 사용하며, 설정의 번거로움을 건너뛰는 동일한 개념을 가지고 있습니다:

SubSaver, 구독 및 절약 추적기: https://ibrh96.gumroad.com/l/gytqdv
FreelanceFlow, 클라이언트, 프로젝트 및 인보이스(invoice) 추적기: https://ibrh96.gumroad.com/l/bcsufq
MetricMint, 인디 해커(indie hackers)를 위한 MRR 대시보드: https://ibrh96.gumroad.com/l/jwdmao

진지한 질문
제가 계속해서 고민하고 있는 두 가지가 있는데, 실제 의견을 듣고 싶습니다:

이런 도구의 경우, 기본적으로 관리자 측면의 인증(auth)을 없애두는 것이 미완성된 느낌을 줄까요, 아니면 "기본적으로 비공개이며, 직접 게이트를 설정하라"는 방식이 스타터 키트(starter kit)로서 올바른 결정일까요?

만약 디지털 제품을 판매하신다면, 현재 라이선싱(licensing)을 어떻게 처리하고 계신가요? 신경을 쓰시는 편인가요, 아니면 그냥 사람들을 믿고 맡기시나요? 제가 정말 유용한 것을 만든 것인지, 아니면 저만 겪고 있는 문제를 해결한 것인지 진심으로 판단이 서지 않습니다.