supabase-node

supabase-node 스킬 개요

supabase-node는 무엇을 위한 스킬인가

supabase-node 스킬은 Supabase와 Drizzle ORM을 사용해 Node.js 백엔드를 만드는 빌드 가이드입니다. 스택에 Supabase Auth와 storage를 포함하고 싶지만, 타입이 보장되는 데이터베이스 쿼리는 Drizzle로 처리하고, API 계층은 Express나 Hono로 유지하고 싶은 팀에 가장 잘 맞습니다.

누가 설치하면 좋은가

새 백엔드를 시작하든, 기존 Node 서비스에 인증을 추가하든, Supabase 기반 앱 전반의 route, middleware, database 패턴을 표준화하든 supabase-node 스킬을 사용하세요. 특히 auth, data access, request validation을 명확하게 분리해야 하는 백엔드 개발 작업에서 유용합니다.

무엇이 다른가

핵심 설계는 단순합니다. Drizzle이 query를 처리하고, Supabase가 auth와 storage를 맡고, middleware가 validation을 담당합니다. 이런 분리는 즉흥적인 프롬프트 출력을 줄이고 database access 패턴과 auth 로직이 뒤섞이는 일을 막는 데 도움이 됩니다. 이 스킬은 한 번 쓰고 끝나는 프롬프트보다, 반복 가능한 프로젝트 구조가 필요할 때 더 큰 가치를 발휘합니다.

supabase-node 스킬 사용 방법

설치하고 컨텍스트에 올려두기

skill manager에서 supabase-node install 흐름으로 설치한 뒤, 백엔드 작업을 하는 동안 스킬을 활성화해 두세요. 프롬프트를 보낼 때는 모델이 스킬 지침과 함께 목표에 맞는 repo 파일을 볼 수 있어야 합니다. 특히 src/routes/, src/middleware/, src/db/, supabase/ 아래의 파일이 중요합니다.

스킬에 맞는 작업 형태로 요청하기

supabase-node usage는 API 계층, auth 요구사항, data shape를 요청에 명확히 적을 때 가장 잘 작동합니다. 예를 들어 “posts API를 만들어줘”라고 하기보다 “Supabase JWT auth를 사용하는 보호된 POST /posts route를 추가하고, Drizzle insert와 title/body 필드에 대한 request validation까지 포함해줘”처럼 요청하세요. 그래야 스킬이 적절한 파일과 경계를 선택할 만큼 충분한 구조를 얻습니다.

먼저 읽어야 할 파일

먼저 SKILL.md로 패턴을 확인한 뒤, src/index.ts, src/routes/index.ts, src/middleware/auth.ts, src/middleware/validate.ts, src/db/schema.ts, src/lib/supabase.ts를 살펴보세요. repository에 migration이 있다면, 새 table이나 auth 관련 로직을 쓰기 전에 supabase/migrations/도 확인해야 합니다.

더 나은 결과를 만드는 워크플로

세 단계 루프로 진행하세요. 먼저 route나 feature를 정하고, 그다음 auth와 DB 경로를 확인한 뒤, 기존 구조에 맞는 가장 작은 변경만 구현합니다. supabase-node guide는 한 번에 하나의 워크플로를 요청할 때 가장 강합니다. 예를 들어 “session 기반 auth middleware를 만들어줘”, “users용 Drizzle query layer를 추가해줘”, “Hono route를 Supabase 기반 profile lookup에 연결해줘”처럼 요청하세요.

supabase-node 스킬 FAQ

supabase-node는 새 프로젝트에만 필요한가

아닙니다. greenfield 앱에 유용하지만, 더 깔끔한 Supabase 통합이 필요한 기존 Node backend에도 잘 맞습니다. 다만 프로젝트가 이미 Express나 Hono, 그리고 TypeScript 스타일의 backend 구조에 익숙해야 한다는 점이 주요 제약입니다.

일반 프롬프트와 어떻게 다른가

일반 프롬프트도 동작하는 코드를 만들 수는 있지만, supabase-node 스킬은 auth가 어디에 있고, query가 어디에 있으며, validation이 어디에 있어야 하는지 더 안정적인 architecture를 제시합니다. 빠른 prototype이 아니라 유지보수 가능한 supabase-node for Backend Development를 원할 때 이 차이가 중요합니다.

스킬의 모든 부분을 다 써야 하나

아닙니다. 앱이 auth verification과 몇 개의 query만 필요로 한다면, 모든 route나 folder convention을 채택하지 않아도 핵심 패턴만 적용할 수 있습니다. stack과 맞지 않는 부분은 건너뛰되, Supabase 관련 책임과 Drizzle 관련 책임의 경계는 유지하세요.

언제 쓰지 않는 게 좋은가

backend가 Node 기반이 아니거나, Supabase Auth나 storage를 사용할 계획이 없거나, Express/Hono layer가 없는 완전 serverless-first stack을 원한다면 이 스킬은 맞지 않습니다. 또한 data layer가 relational이 아니거나, typed SQL 스타일의 query handling을 원하지 않는 경우에도 적합성이 떨어집니다.

supabase-node 스킬 개선 방법

“만들어줘”보다 더 구체적으로 입력하기

가장 좋은 결과는 endpoint, auth 상태, table 이름, response shape를 명시할 때 나옵니다. 강한 프롬프트의 예시는 이렇습니다. “Supabase JWT에서 인증된 user를 읽고, Drizzle로 users에서 profile을 조회한 뒤, validation과 error handling을 포함해 { user, profile }을 반환하는 GET /me route를 만들어줘.”

흔한 실패 모드를 점검하기

가장 흔한 실수는 Supabase client 사용과 direct DB access를 섞거나, middleware를 건너뛰거나, 실제 프로젝트 구조를 확인하지 않고 가정해버리는 것입니다. 첫 결과가 너무 일반적으로 느껴진다면, src/routes/, src/db/, src/middleware/에 맞춰 구현을 명시적으로 매핑해 달라고 요청하세요.

schema에서 바깥으로 확장하며 반복하기

더 나은 supabase-node usage를 원한다면, route 코드를 요청하기 전에 schema와 auth 가정부터 먼저 정리하세요. 기능을 바꿔야 한다면 table 구조, validation 규칙, middleware 요구사항을 먼저 업데이트한 뒤, 그에 맞춰 route와 query 코드를 다시 생성하는 방식이 좋습니다.