Supabase Middleware 1.0 정식 공개, 서버의 인증·요청 처리 재사용

이번 소식

Supabase가 서버의 반복적인 요청 처리를 묶는 Supabase Middleware 1.0을 정식 공개했습니다. 미들웨어는 로그인 확인처럼 실제 서비스 기능이 실행되기 전후에 거치는 처리 단계입니다. 앱을 만드는 개발자가 이 단계를 여러 서버 환경에서 재사용하도록 돕는 도구입니다.

주요 변경

• 1.0 정식 버전: @supabase/middleware 1.0.0을 npm·JSR의 최신 버전으로 제공합니다. MIT 라이선스이며, 앞으로 기존 사용법을 깨는 변경은 새 주 버전에 넣는 버전 관리 정책을 적용합니다.
• 순서대로 조립하는 처리: defineMiddleware로 각 단계를 만들고 pipeline으로 연결합니다. 요청을 중간에 거절하거나, 다음 단계에 필요한 정보를 넘기거나, 반환할 응답을 조정할 수 있습니다.
• 조합 오류 확인: 파이프라인에서 같은 이름의 정보를 중복 등록하거나 필요한 선행 단계가 빠진 조합은 TypeScript의 코드 검사에서 확인하도록 설계했습니다. 기본 제공 기능은 다른 출처의 웹 요청 허용을 다루는 CORS와 기능 공개 여부를 제어하는 기능 플래그입니다.

알아둘 배경

이 엔진은 Supabase Edge Functions뿐 아니라 Vercel Functions, Cloudflare Workers, Deno·Bun·Node.js 22 이상을 대상으로 합니다. Hono·H3·Elysia·NestJS·TanStack Start에서는 공식 가이드의 연결 코드를 프로젝트에 넣어 사용합니다. 프레임워크별로 응답 처리 등 지원 범위가 다르므로 같은 동작을 모두 가정하면 안 됩니다.

영향 대상과 활용

서버 환경이나 프로젝트를 바꿀 때 로그인 확인과 요청 처리 코드를 매번 다시 옮겨 적는 부담을 줄이는 데 쓸 수 있습니다. 예를 들어 회원 전용 API 앞에 인증 확인을 두거나, 요청을 추적할 번호를 붙이는 단계를 공통 부품으로 관리할 수 있습니다. 이는 활용 예이며 이번에 직접 실행해 측정한 결과는 아닙니다. 일반 서비스 이용자가 켜는 새 메뉴는 없고, 개발팀이 앱의 서버 코드를 구성할 때 영향을 받는 변화입니다.

사용 전 확인할 점

Supabase 인증·데이터 연결 기능은 별도 @supabase/server와 조합합니다. 기존 프레임워크 연결 방식을 옮길 때 특히 인증 조건을 확인해야 합니다. 공식 문서에 따르면 withClaims는 인증 정보가 없는 요청도 통과시킬 수 있으므로, 로그인이 필수인 경로에는 withRequiredClaims 등 해당 요구를 유지하는 구성이 필요합니다. 적용 후에는 로그인하지 않은 요청이 실제로 거절되는지 확인하는 편이 좋습니다.

공식 출처·발표 시점

원문 발표일: 2026년 9월 30일. 공식 RSS 게시 시각은 2026년 9월 30일 09:00 KST입니다. 동작과 적용 조건은 공식 프레임워크 가이드와 미들웨어 작성 가이드를 함께 확인했습니다.

원문 출처 보기 →