제품 작업과 반복되는 인프라를 분리하세요
제품을 유용하게 만드는 기능을 나열한 다음, 그것을 작동시키는 데 필요한 인프라를 나열하세요. 리서치 플로는 차별화될 수 있지만 세션 처리, 고객 소유 레코드, 구독 액세스는 보통 그렇지 않습니다. 이 인벤토리는 스타터의 홈페이지에서 기능 수를 세는 것보다 더 나은 평가 도구입니다.
두 번째 목록은 보기보다 깁니다. 대부분의 SaaS 제품은 같은 십여 개 조각을 다시 구현하고, 제품이 무엇이든 할 수 있으려면 각각이 나머지와 올바르게 통합되어야 합니다.
처음부터 구축하면 이러한 선택을 직접 제어할 수 있지만 통합하고 유지할 책임도 집니다. 스타터는 출발점을 바꿉니다. 여전히 그 코드를 이해하고 제품, 팀, 배포에 대해 내리는 가정을 검증해야 합니다.
- 신원: 로그인 방법, 세션, 계정 복구.
- 워크스페이스: 레코드 소유권, 초대, 멤버 역할.
- 결제: 체크아웃, 웹훅, 엔타이틀먼트, 해지.
- 백그라운드 작업: 큐, 재시도, 스케줄, 상태 추적.
- 전송: 트랜잭션 이메일, 파일 스토리지, 배포.
표시 가격이 아니라 총비용을 비교하세요
스타터의 가격은 보이지만 처음부터 만드는 비용은 여러 달에 분산됩니다. 정직하게 합산하세요: 인증, 결제, 작업, 배포를 조립하는 데 쓰는 주 수, 그 조립이 함께 출시하는 통합 버그, 그리고 이후 각 프로바이더 업데이트가 촉발하는 유지보수.
스타터의 비용은 당신이 쓰지 않은 코드를 배우고 적응시키는 것입니다: 관례를 읽고, 샘플 콘텐츠를 교체하고, 가끔 그것이 그린 경계를 휘는 것. 아래의 검사가 잘 진행되면 그 교환은 보통 같은 배관을 다시 만드는 것보다 쌉니다. 나쁘게 진행되면 무시해서는 안 되는 경고입니다 — 오늘 읽을 수 없는 경계는 내년의 프로덕션 사고입니다.
상속받을 코드를 평가하세요
설치 지침을 실행하고 레코드를 인터페이스에서 영속화까지 따라가세요. 인가가 서버 경계에 있는지, 구성이 검증되는지, 프로바이더 자격 증명이 클라이언트 번들 밖에 있는지 확인하세요. 데모 화면뿐 아니라 네거티브 테스트를 읽으세요.
샘플 제품이 인프라와 분리 불가능해진 부분을 찾으세요. 데모 기능을 제거하는 데 인증이나 결제 동작 변경이 필요하다면, 향후 제품 작업이 처음 설치가 시사하는 것보다 어려울 수 있습니다. supastack에서 소비 제품은 도메인 로직을 Starter Core 밖에 두고 구성과 계약을 통해 연결합니다 — 프로젝트 구조 가이드가 그 선이 어디 있는지 보여줍니다.
- 스스로 알아내야 했던 문서화되지 않은 모든 설정 단계.
- 인가가 어디서 강제되는지, 라우트별인지 체계적인지.
- 네거티브 테스트 — 워크스페이스 간 읽기, 재생된 웹훅 — 가 있는지, 그리고 그것이 무엇을 증명하는지.
- 시크릿이 어디 사는지, 어떤 것이라도 클라이언트 번들에 도달하는지.
- 데모 기능을 지우려 할 때 인프라에 어떤 일이 일어나는지.
결정하기 전에 실행하세요
커밋하기 전에 리포지토리 안에서 하루를 보내세요. supastack에서는 corepack pnpm install, 구성된 apps/web/.env.local, 그리고 로컬 참조 플로를 의미합니다: 로그인하고, 액세스를 검사하고, 작업을 제출하고, 결과를 읽으세요. 그런 다음 pnpm verify:local이 자격 증명 없이 fake 프로바이더로 골든 패스를 실행합니다 — 로컬 설정 가이드가 그 순서를 안내합니다.
그런 다음 일부러 무언가를 깨뜨려 보세요. 같은 작업을 두 번 제출하고, 잘못된 워크스페이스로 API 라우트를 호출하고, 웹훅을 재생하세요. 일반적인 실패를 우아하게 처리하는 스타터는 기능 목록이 더 긴 스타터보다 가치가 있습니다 — 당신의 머신에서 깔끔하게 실패시킬 수 없는 것은 결국 프로덕션에서 디버깅하게 되기 때문입니다.
트레이드오프를 명시적으로 만드세요
스타터의 기존 경계가 요구와 맞고 의존할 플로를 설명할 수 있으면 스타터를 선택하세요. 제품의 제약이 스타터의 가정에 반복적인 변경을 강요하면 맞춤 기반을 선택하세요. 두 선택 모두 합리적일 수 있습니다. 중요한 질문은 팀이 어떤 유지보수 부담을 짊어질 수 있는가입니다.
샘플 콘텐츠 교체, 통합 구성, 데이터 소유권 검토, 배포 테스트에 시간을 확보하세요. 컴파일되는 리포지토리는 프로덕션 수용의 출발점입니다. 출시 전에 고객이 사용할 환경에서 실제 로그인 경로, 결제 라이프사이클, 복구 동작을 검증하세요 — 출시 체크리스트가 그 목록을 열거합니다. 그리고 하부 스택도 미정이라면 SaaS 스택 고르기가 계층별 평가를 다룹니다. 두 결정은 서로를 밝혀줍니다.
| 처음부터 구축 | 스타터 키트 채택 | |
|---|---|---|
| 소유하는 것 | 모든 관례, 통합, 실패 모드 | 제품 코드; 배관은 유지보수된 채로 옵니다 |
| 초기 속도 | 느림 — 배관이 먼저 | 빠름 — 첫날부터 기능 시작 |
| 리스크가 있는 곳 | 아직 찾지 못한 접합부 | 아직 검사하지 않은 경계 |
| 옳은 선택인 경우 | 당신의 제약이 일반적인 가정을 깰 때 | 그 경계가 제품의 필요와 맞을 때 |
스타터 키트에 관한 흔한 질문
구매 대 구축 논쟁은 강한 의견을 낳습니다. 실제로 결정을 움직이는 질문은 이것들입니다.
- 진지한 제품에 스타터 키트를 쓰는 것은 위험한가요? — 많은 프로덕션 SaaS가 구매한 기반 위에서 돌아갑니다. 위험은 스타터가 아니라 검사하지 않은 코드를 상속하는 것입니다. 의존하기 전에 경계를 읽으세요.
- 보일러플레이트가 유지보수되는지 어떻게 알 수 있나요? — 최근 커밋, 문서화된 업데이트 경로, 실패 사례를 실행하는 테스트, 로드맵 약속 대신 구체적으로 답변된 이슈를 찾으세요.
- 스타터의 선택이 내 것과 다르면요? — 선호와 제약을 구분하세요. UI를 다시 꾸미는 것은 저렴하지만 세션 모델이나 테넌트 경계와 싸우는 것은 아닙니다. 구조적 불일치는 직접 만들 이유입니다.
- 나중에 스타터에서 벗어날 수 있나요? — 코드를 소유하므로 마이그레이션할 대상이 없습니다 — 진짜 질문은 수정하면서 그 배관이 자산으로 남는지이며, 그래서 분리 가능한 제품과 인프라 코드가 중요합니다.
- 스타터는 실제로 얼마나 시간을 절약하나요? — 대략 인증, 결제, 작업, 배포에 걸렸을 주 수에서, 상속받은 것을 배우고 적응시키는 데 필요한 날 수를 뺀 만큼입니다.