계속 출시할 수 있는 SaaS 스택 고르기

제품의 제약을 중심으로 선택하세요

프레임워크 이름을 비교하기 전에 제품이 필요로 하는 것을 적으세요. 웹 대시보드, 오프라인 모바일 도구, 긴 리서치 플로는 서로 다른 제약을 가집니다. 어떤 클라이언트가 필요한지, 어떤 데이터가 각 고객에 속하는지, 브라우저 탭이 닫힌 후에도 계속되어야 할 작업은 무엇인지 결정하세요.

기능 목록과 함께 팀의 경험을 저울질하세요. 명확한 경계를 가진 익숙한 스택이 인증, 배포, 영속화 규칙을 동시에 배워야 하는 더 새로운 조합보다 유지하기 쉬울 수 있습니다. 첫 설치뿐 아니라 업그레이드와 디버깅의 지속적인 작업을 세세요.

• 첫날 필요한 클라이언트 표면 — 웹만인지, 모바일과 데스크톱도인지.
• 어떤 데이터가 각 고객에 속하는지, 팀이 워크스페이스를 공유하는지.
• 브라우저 탭보다 오래 살아야 하는 작업: 큐에 넣는 작업, 예약 작업, 장기 실행 작업.
• 무엇에 요금을 청구할지 — 구독, 시트, 사용량 — 그리고 누가 지불하는지.
• 팀이 현실적으로 운영할 수 있는 운영 표면: 데이터베이스, 큐, 프로바이더.

프레임워크 아래 계층을 평가하세요

프레임워크 이름은 표면을 설명합니다. 그 아래 계층이 제품이 함께 유지되는지를 결정합니다. 하나씩 살펴보며 각각에 같은 질문을 하세요: 누가 이 결정을 소유하고, 어디서 강제되는가?

스택이 비워 두는 계층은 당신이 떠맡는 작업으로 취급하세요. “자체 인증을 가져오세요”는 정당한 설계입니다 — 다만 세션 의미, 프로바이더 통합, 그에 따른 모든 실패 사례를 소유한다는 뜻입니다. 빈 계층은 선택이지만 보이지 않는 계층은 부채입니다. 킷의 모듈 문서는 소유된 계층이 실제로 어떤 모습인지에 대한 유용한 참고자료입니다.

도구 간 접합부를 검사하세요

스택은 통합 결정의 집합입니다. 누가 세션을 소유하는지, 레코드가 어떻게 범위가 지정되는지, 결제 이벤트가 어디서 권한이 되는지, UI가 백그라운드 작업의 결과를 어떻게 가져오는지 파악하세요. 이러한 연결이 요청이 실패하거나 중복 도착할 때 해피 패스가 올바르게 유지되는지를 결정합니다.

supastack은 웹 화면에 Next.js, 모바일에 Expo, 그 아래에 공유 TypeScript 패키지를 사용합니다. Better Auth가 신원을 소유하고, Postgres와 Drizzle이 레코드를 영속화하며, Trigger.dev가 명시적 워크플로 의미를 소유합니다. 이것은 리포지토리의 선택이지 모든 제품이 같은 도구를 써야 한다는 주장이 아닙니다 — 기술 스택 가이드는 각 선택과 그 이유를 기록하며, 다른 도구를 골라도 질문은 그대로 적용됩니다.

도구가 무엇이든 테스트는 같습니다: 레코드 하나를 골라 인터페이스에서 서버 경계를 거쳐 영속화까지, 그리고 다시 따라가세요. 어느 한 구간이 강제된 규칙이 아니라 관례라면, 미래의 기여자가 언젠가 그것을 깨뜨립니다.

계속 실행하는 비용을 세세요

스택 결정은 운영 결정이기도 합니다. Postgres에는 백업과 마이그레이션 규율이 필요합니다. 작업 실행기에는 누군가 실제로 여는 대시보드가 필요합니다. 모든 프로바이더 키에는 로테이션과 클라이언트 번들 밖의 보관 장소가 필요합니다. 기능 체크리스트에 설득되기 전에 이 항목들을 비교에 추가하세요.

선택지가 있을 때 업그레이드 경로를 확인하세요. 고정된 의존성과 문서화된 업데이트 절차를 갖춘 모노레포 — 킷은 바로 이를 위한 업데이트 가이드를 유지합니다 — 가 각각 다른 세계관을 가정하는 튜토리얼로 조립된 스택보다 잘 늙습니다.

• 의존성 및 보안 업데이트: 얼마나 자주 오는지, 누가 적용하는지.
• 프로바이더 자격 증명: 어디에 있는지, 누가 로테이션할 수 있는지.
• 데이터: 백업 일정, 복원 훈련, 보관 정책.
• 옵저버빌리티: 무엇이 시끄럽게 깨지는지, 고객이 신고할 때까지 무엇이 조용히 실패하는지.

작은 수직 슬라이스를 구축하세요

스택에 커밋하기 전에, 사용자를 로그인시키고 소유된 레코드를 쓰고 작업을 시작하고 결과를 가져오는 슬라이스를 실행하세요. 그런 다음 의도적으로 잘못된 워크스페이스, 만료된 세션, 실패한 작업을 시도하세요. 이러한 일반적인 조건이 얼마나 많은 커스텀 글루를 요구하는지 평가하세요.

짧은 결정 기록을 남기세요: 스택이 지원하는 것, 미루기로 선택한 것, 재검토를 유발할 것. 네이티브 구매, 실제 프로바이더 수용, 배포 운영은 성공한 로컬 빌드 뒤에 숨겨진 가정이 아니라 명시적 항목이어야 합니다. 올바른 스택은 팀이 제품 작업에 충분한 주의력을 남깁니다.

슬라이스가 스타터의 리포지토리 안에서 잘 진행된다면, 다음 질문은 그것을 채택할지입니다 — 스타터 키트 vs 처음부터가 그 결정을 안내합니다.

• 로그인한 뒤 새로고침 후 세션을 복원하세요.
• 하나의 워크스페이스로 범위 지정된 레코드를 쓰고 다시 읽으세요.
• 백그라운드 작업을 시작하고 나중에 결과를 가져오세요.
• 잘못된 워크스페이스와 만료된 세션으로 같은 호출을 반복하세요.

스택 선택에 관한 흔한 질문

스택 결정에는 확신에 찬 조언이 많이 붙습니다. 대신 자신의 제품에 대해 답할 가치가 있는 질문은 이것들입니다.

• 이미 아는 스택을 골라야 하나요? — 제품의 제약을 표현할 수 있다면 보통 그렇습니다. 명확한 경계를 가진 익숙한 스택이 몇 달을 배워야 할 유행하는 스택보다 낫습니다 — 제품이 네이티브 모바일처럼 정말 없는 것을 요구하지 않는 한.
• 프런트엔드 프레임워크가 가장 중요한가요? — 주변 계층보다는 덜합니다. 프레임워크는 UI를 만들고, 신원, 범위 지정, 결제, 백그라운드 작업이 제품의 정확함을 결정합니다.
• 스택 평가는 얼마나 걸려야 하나요? — 몇 주가 아니라 며칠: 제약을 적고, 접합부를 검사하고, 수직 슬라이스 하나를 실행하세요. 일반적인 실패에 커스텀 글루가 필요하면 계속 찾으세요.
• 나중에 스택을 바꾸는 것이 언제 정당화되나요? — 핵심 제약이 바뀔 때 — 필요한 플랫폼, 규모 임계값 — 이며, 더 새로운 릴리스가 더 좋아 보일 때가 아닙니다. 전환 비용은 컴포넌트가 아니라 인증과 데이터에 있습니다.