✍️ 필사 모드: 인증 프로바이더 정면 비교 2026 — Clerk · WorkOS · Auth0 · Stytch · Better Auth · Kinde · SuperTokens 그리고 NextAuth·Lucia 사후 정리

• 프롤로그 — 인증을 사는 시대
• 1장 · 비교 축 — 무엇을 보고 골라야 하는가
• 2장 · 10개 옵션 — 한 줄 정체성과 한 줄 위험
• 3장 · 기능 매트릭스 — 한 표로 정리
• 4장 · 가격 매트릭스 — 실제 청구서 시뮬레이션
  • 시나리오 A · B2C 소비자 앱 (50,000 MAU, MFA·passkey·소셜만)
  • 시나리오 B · B2B SaaS (200 고객사, 평균 50 시트, SAML 30%·SCIM 10%)
  • 시나리오 C · 글로벌 소비자 앱 (500,000 MAU)
• 5장 · 의사결정 트리 — 어떤 걸 골라야 하는가
• 6장 · 자체 호스팅 TCO — 진짜 싼가
• 7장 · Clerk vs WorkOS — 가장 자주 묻는 비교
• 8장 · 패스워드리스·passkey·magic link — 2026년의 디폴트
• 9장 · Lucia 마이그레이션 — 무엇을 어디로
• 10장 · NextAuth(Auth.js) vs Better Auth — Next.js 라이브러리 선택
• 11장 · 안티패턴 — 자주 보는 실수 10가지
• 에필로그 — 결정 체크리스트와 다음 글 예고
  • 결정 체크리스트
  • 안티패턴 요약
  • 다음 글 예고
• 참고 / References

프롤로그 — 인증을 사는 시대

2026년 5월의 인증 시장은 5년 전과 완전히 다르다. 2021년에는 "Auth0를 쓸까, Cognito를 쓸까, 직접 만들까"가 전부였다. 지금은 같은 질문에 적어도 열 개의 답이 있고, 각 답이 서로 다른 가격·운영 부담·기능 집합을 가진다.

이 시장은 두 갈래로 찢어졌다.

• B2C·개발자 경험 진영. Clerk가 깃발을 들었다. UI 컴포넌트, 호스팅 인증, 잘 만든 React/Next.js 통합, 그리고 "10분 안에 로그인 동작"이라는 약속. Stytch가 패스워드리스·passkey·Fraud SDK로 옆에 섰고, Kinde가 "더 단순한 대안"으로 따라왔다.
• B2B·엔터프라이즈 진영. WorkOS가 만든 카테고리다. SAML·SCIM·디렉토리 동기화·감사 로그 — 엔터프라이즈가 사달라고 비명을 지르는 모든 기능을 API 한 줄로 파는 회사. Auth0는 여기 있었지만, Okta 인수 후 가격 인상과 정체로 점유율을 잃었다.

그리고 자체 호스팅·OSS 진영에서 2025년 한 해 동안 두 가지 큰 사건이 벌어졌다. Lucia가 죽었다. 메인테이너 pilcrowOnPaper가 2025년 3월에 deprecation을 공식 발표했고, 라이브러리는 2025년 말부터 학습용 리소스로 전환됐다. 그리고 그 자리를 Better Auth가 가져갔다. TypeScript 네이티브·프레임워크 불문·플러그인 아키텍처·자체 호스팅 가능 — 2025년 인디 해커들이 일제히 갈아탔다.

이 글은 이 모든 옵션을 같은 축으로 정면 비교한다. 이론(OIDC·SAML 같은 프로토콜 자체)은 별도 글에 있고, Keycloak 자체 호스팅 핸즈온도 별도 글에 있다. 이 글은 **"무엇을 살까"**에 대한 의사결정 가이드다.

가격은 빠르게 바뀐다. 이 글의 모든 숫자는 2026년 5월 기준이며, 정확한 수치보다 구조에 집중한다. 6개월 뒤 가격이 바뀌어도 결정 프레임은 유효해야 한다.

흐름은 이렇다: 비교 축 → 10개 프로바이더를 한 줄씩 → 기능 매트릭스 → 가격 매트릭스 → 시나리오별 결정 트리 → 자체 호스팅 TCO → Lucia 마이그레이션 → 에필로그.

1장 · 비교 축 — 무엇을 보고 골라야 하는가

같은 축으로 보지 않으면 "Clerk가 더 좋다 vs WorkOS가 더 좋다" 같은 무의미한 싸움이 된다. 다음 8개 축을 모든 프로바이더에 적용한다.

축 1 · 타겟 시장(B2C vs B2B) 누가 사용자인가. 개인 사용자가 가입하는 앱(B2C)인가, 회사가 시트를 사는 SaaS(B2B)인가. 답이 다르면 필요한 기능이 다르다. B2C는 소셜 로그인·패스워드리스·passkey가 중심. B2B는 SSO(SAML/OIDC)·SCIM(자동 프로비저닝)·조직·역할·감사 로그가 중심. 둘 다 잘하는 척하는 프로바이더가 많지만, 실제로는 한쪽에 강하다.

축 2 · 호스팅 모델 완전 SaaS인가, 자체 호스팅 가능인가, 둘 다인가. SaaS는 운영 부담이 없지만 의존성·가격·데이터 주권을 양보한다. 자체 호스팅은 그 반대다. "둘 다 가능"이라는 옵션은 마케팅 문구일 때가 많다 — 실제로 자체 호스팅을 진지하게 지원하는 OSS 회사는 소수다.

축 3 · 가격 모델 MAU(Monthly Active User) 기반인가, 시트 기반인가, 기능 게이트인가. MAU 모델은 B2C에 잔인하다 — 사용자가 늘면 비용이 선형으로 늘어난다. 시트(조직 멤버) 모델은 B2B에 합리적이다. 그리고 "엔터프라이즈 기능"(SAML·SCIM·SSO)을 별도 SKU로 묶어 가격을 5배로 뛰게 하는 패턴은 거의 모든 SaaS 프로바이더의 표준이다.

축 4 · 기능 폭(passkey·MFA·org·SAML·SCIM·passwordless·magic link) 필수: 비밀번호·소셜·세션. 보너스: passkey(WebAuthn)·TOTP·SMS OTP·magic link·passwordless·SAML SSO·SCIM provisioning·B2B 조직·역할/권한·감사 로그·디바이스 관리. 같은 가격대에서 어디까지 들어오는지 확인.

축 5 · DX(개발자 경험) SDK 품질, 문서, 예제, UI 컴포넌트, 프레임워크 통합. Clerk의 강점이 여기. 잘 만든 <SignIn /> 컴포넌트가 30초 안에 동작하는가, 아니면 OIDC 핸드셰이크를 직접 코딩해야 하는가.

축 6 · 통합 깊이(프레임워크·BaaS·이메일·결제) Next.js·Remix·SvelteKit 같은 메타프레임워크에서 first-class인가. Stripe·Resend·Supabase·Vercel과 어떻게 엮이는가. 통합이 좋으면 부수 코드가 줄고, 통합이 없으면 어댑터 레이어를 직접 만든다.

축 7 · 데이터 주권 & 컴플라이언스 사용자 데이터가 어디 저장되는가. EU/일본/한국 리전 옵션이 있는가. SOC2·ISO 27001·HIPAA·GDPR DPA·일본 APPI 대응. 자체 호스팅이면 이게 답이지만, SaaS에서는 회사 본사 위치와 리전 옵션이 결정한다.

축 8 · 이탈 비용(lock-in) 사용자 데이터를 어떻게 export할 수 있는가. 비밀번호 해시는 가져올 수 있는가(SCRAM·bcrypt·argon2 형식이 호환되는가). MAU 비례 가격이 임계점을 넘었을 때 마이그레이션 비용은 얼마인가. 이게 가장 무시되는 축이다. 처음에 작을 때 좋아 보이는 프로바이더가 50만 MAU에서 매년 30만 달러를 내라고 청구서를 보낼 때, "그냥 옮기면 되지"가 사실인지 확인해야 한다.

2장 · 10개 옵션 — 한 줄 정체성과 한 줄 위험

본격 비교 전에 각 프로바이더를 짧게 정리한다.

Clerk — 개발자 경험 1위의 B2C 인증. UI 컴포넌트(<SignIn />, <UserButton />)·B2B Organizations·Backend API. 가격은 Pro $25/월 부터 시작하고 MAU 10,000까지 무료. SAML·SCIM은 비싼 Enhanced Authentication add-on($100/월부터). 한 줄 위험: B2C에서 출발해 B2B 기능을 추가하는 중이라, B2B 깊이는 WorkOS에 못 미친다.

WorkOS — "Enterprise OAuth" 카테고리를 만든 회사. SSO·SAML·SCIM·디렉토리 동기화·감사 로그를 API 한 줄로. 가격은 SSO·DSync 각 connection당 $125/월 (월 1,000,000 unit까지 무료 한도). 2026년 AuthKit이 무료 1M MAU까지 풀이며 모든 인증 빌딩블록을 묶었다. 한 줄 위험: B2C 인증(소셜·패스워드)도 되지만, 진짜 가치는 엔터프라이즈 readiness이지 일반 인증이 아니다.

Auth0 (Okta) — 인증 SaaS의 원조이자 거인. 2021년 Okta에 65억 달러로 인수됐다. 모든 기능이 있고, 모든 통합이 있다. 그리고 모든 것에 돈을 낸다. 2026년 가격: B2C Essentials $35/월부터 (1,000 MAU 포함), Pro$240/월 (1,000 MAU), 5,000 MAU에서 약 $1,500/월. B2B 가격은 별도 — Auth0 Organizations·Enterprise Connections는 비싸다. 한 줄 위험: M&A 정체. 신기능 출시가 느려졌고, 가격 인상은 연례 행사다. 새 프로젝트가 Auth0로 시작하는 비율은 2023년부터 떨어지는 추세.

Stytch — Passwordless·passkey·magic link를 가장 잘 만드는 회사. 2024년부터 "Fraud Prevention" SDK를 추가해 봇·계정 탈취·합성 ID 탐지를 ML로. 가격은 B2C $0 (10,000 MAU까지)·$249/월 (Pro)·B2B는 별도. 한 줄 위험: 카테고리가 좁다. Stytch만으로 모든 인증을 처리할 수도 있지만, 일반 SaaS 인증 시장에서는 Clerk·WorkOS에 비해 인지도가 낮다.

Better Auth — 2025년 인디 시장을 가져간 OSS TypeScript 인증 라이브러리. 프레임워크 불문(Next.js·Nuxt·SvelteKit·Solid·Astro·Hono·Express…), 데이터베이스 어댑터(Drizzle·Prisma·Kysely·MongoDB), 플러그인 아키텍처(passkey·magic link·organization·admin·OIDC provider). MIT 라이선스·자체 호스팅. 한 줄 위험: 라이브러리이지 서비스가 아니다. DB·이메일·세션 저장·운영을 다 직접 한다. Clerk가 주는 30초 onboarding은 여기 없다.

Kinde — "Auth0보다 단순하고 더 싼" 포지셔닝. 호주에서 시작했고 2024-25년 빠르게 성장. UI·B2B 조직·MFA·소셜이 다 있고, 가격이 Auth0의 절반 이하. Pro $25/월 (10,500 MAU), Plus$89/월 (10,500 MAU + 더 많은 기능). 한 줄 위험: Auth0·Clerk·WorkOS만큼의 생태계·통합·문서 깊이는 아직 부족.

SuperTokens — OSS 자체 호스팅을 진지하게 지원하는 회사. Apache 2.0, Docker로 띄우고 React SDK·Node SDK가 잘 만들어져 있다. 매니지드 SaaS 옵션도 있지만 핵심 정체성은 자체 호스팅. 한 줄 위험: 생태계가 좁다. 일본·한국 커뮤니티는 거의 없고, B2B Organizations·SAML·SCIM 같은 엔터프라이즈 기능은 유료 SaaS 티어에서만.

Supabase Auth — Supabase BaaS와 묶인 인증. Postgres에 사용자 테이블이 살고, RLS(Row Level Security)와 직결된다. Supabase를 이미 쓰는 팀에게는 거의 무료에 가깝다. 가격은 Supabase 가격에 묶여 있다 — Pro $25/월부터. 한 줄 위험: Supabase 안에서만 가치. 별도 백엔드가 있고 Supabase가 아닌 다른 DB를 쓰면 어색하다.

Firebase Auth (Google Identity Platform) — 모바일 앱의 디폴트. Firebase를 쓰는 모든 팀이 그냥 쓴다. 가격은 50,000 MAU까지 무료, 그 위는 MAU당 $0.0055-0.0025. 한 줄 위험: Vendor lock-in이 강하다. Google Cloud 안에서만 진짜로 매끄럽고, 다른 백엔드에서는 Admin SDK로 빈약하게 연동.

Auth.js (NextAuth) — Next.js의 사실상 표준 인증 라이브러리. v5에서 이름이 바뀌고 프레임워크 중립으로 확장. OSS·자체 호스팅·DB는 본인이 준비. 한 줄 위험: 라이브러리이지 서비스가 아니다(Better Auth와 같은 카테고리). 깊이는 있지만 학습곡선이 있고, 세션·DB 어댑터·콜백을 직접 이해해야 한다. 2025-26년 Better Auth로의 이탈이 가시화됐다.

Logto — OSS 자체 호스팅 정체성 플랫폼. MIT 라이선스, OIDC·OAuth2·SAML 지원, Console UI 제공. Cloud 옵션도 있다. 한 줄 위험: 후발주자라 생태계·통합 깊이는 Keycloak·SuperTokens에 비해 얕다.

Lucia (deprecated) — TypeScript 네이티브 세션 라이브러리로 사랑받았지만, 메인테이너가 2025년 3월에 deprecation을 공식 발표. 새 프로젝트에서는 사용 금지. 기존 프로젝트는 Better Auth·Auth.js·Arctic(같은 메인테이너의 후속작)으로 마이그레이션 필요.

3장 · 기능 매트릭스 — 한 표로 정리

각 프로바이더가 무엇을 무료/기본 티어에서 제공하는지. "있다·없다·유료 add-on" 셋 중 하나.

읽는 법: 매트릭스만 보고 결정하지 마라. "기능 있음"이 "프로덕션 품질"을 보장하지 않는다. Clerk의 SAML과 WorkOS의 SAML은 같은 단어이지만 깊이가 다르다. WorkOS는 카테고리를 정의한 회사고, Clerk는 add-on으로 붙였다.

4장 · 가격 매트릭스 — 실제 청구서 시뮬레이션

추상적인 가격표는 의미 없다. 세 가지 실제 시나리오에서 월 청구서가 얼마인지 시뮬레이션.

시나리오 A · B2C 소비자 앱 (50,000 MAU, MFA·passkey·소셜만)

해석: B2C 50K MAU만 보면 WorkOS AuthKit·Firebase·Supabase가 압도적으로 싸다. 라이브러리(Better Auth·Auth.js)는 라이선스 비용 0이지만 운영비를 잊으면 안 된다(다음 장).

시나리오 B · B2B SaaS (200 고객사, 평균 50 시트, SAML 30%·SCIM 10%)

해석: B2B SAML이 많아지면 WorkOS의 connection 가격이 무섭게 늘어난다. 그래도 "한 SAML 연결을 직접 구현하는 인건비"보다는 싸다(IdP별 호환성 디버깅에 보통 1-2주). Clerk의 Enhanced Authentication이 절대 가격에서는 가장 싸 보이지만, 깊이·디렉토리 동기화 품질에서 WorkOS와 차이가 있다.

시나리오 C · 글로벌 소비자 앱 (500,000 MAU)

해석: 50만 MAU 구간이 거의 모든 MAU 기반 SaaS의 임계점이다. Clerk·Auth0·Stytch에서 청구서가 무서워진다. 이 구간에서는 자체 호스팅(Better Auth + Postgres) 또는 WorkOS AuthKit(현재 정책 한도 내) 또는 Firebase가 합리적이다.

가격은 2026년 5월 공식 가격 페이지·릴리즈 정보를 토대로 한 추정이며, 실제 청구서는 add-on·support·overage에 따라 ±50% 변동 가능. 정확한 견적은 본인 워크로드로 직접 받아야 한다.

5장 · 의사결정 트리 — 어떤 걸 골라야 하는가

8개 축·10개 옵션·3개 가격 시나리오를 보고도 결정이 안 된다면, 정직한 트리는 이렇다.

[질문 1] B2C인가 B2B인가 둘 다인가?
   ├── 순수 B2C → 질문 2
   ├── 순수 B2B → 질문 4
   └── 둘 다 → 질문 3

[질문 2] B2C: 예상 1년 후 MAU는?
   ├── 1만 미만 → Clerk Pro 또는 Better Auth·Auth.js (취향)
   ├── 1만-10만 → Clerk·Stytch·Kinde 중 DX 취향 / Better Auth 자체 호스팅
   └── 10만+ → WorkOS AuthKit · Firebase · Better Auth 자체 호스팅 (Clerk·Auth0는 비쌈)

[질문 3] 하이브리드: 진짜로 B2B를 신경 쓰는가?
   ├── B2B는 "있으면 좋음" → Clerk + Enhanced Auth 또는 Kinde
   └── B2B가 매출의 50%+ → WorkOS (B2C는 AuthKit으로 같이 해결)

[질문 4] B2B: 엔터프라이즈 고객 비중은?
   ├── SMB·미드마켓 위주 → Clerk·Kinde·Auth0 Pro
   └── 엔터프라이즈·SAML·SCIM 필수 → WorkOS (압도적) 또는 Auth0 B2B (예산 있으면)

[질문 5] 자체 호스팅 요건이 있는가?
   ├── 데이터 주권·온프레미스 의무 → Keycloak (별도 글) 또는 SuperTokens·Logto
   ├── 풀스택 TS 팀이고 작게 시작 → Better Auth
   └── Next.js + DB 자유롭게 다룸 → Better Auth (Auth.js v5보다 우세)

핵심 결정 휴리스틱 6가지:

1. B2B 엔터프라이즈가 매출의 50%+ → WorkOS가 1지망. 다른 답은 거의 없다. SAML·SCIM·디렉토리 동기화의 깊이가 다른 카테고리다.
2. 개인 개발자·인디·작은 팀 + Next.js → Clerk 또는 Better Auth. 둘 중 하나로 좁히고, Clerk는 "관리하기 싫음", Better Auth는 "OSS·자체 호스팅·DB 자유".
3. 이미 Supabase·Firebase를 쓰면 → 같은 BaaS의 Auth를 쓴다. 별도 인증을 끼우면 RLS·세션이 어색해진다.
4. 새 프로젝트가 Auth0로 시작할 이유는 거의 없다. 같은 가격대에서 Clerk·Stytch·WorkOS가 거의 모든 면에서 낫다.
5. MAU가 50만이 넘어갈 가능성이 높으면 → Clerk·Auth0·Stytch의 청구서를 미리 시뮬레이션해야 한다. 청구서가 무서워졌을 때 옮기는 비용이 더 무섭다.
6. Lucia를 쓰고 있다면 → 지금 마이그레이션 계획을 세워라. 9장 참고.

6장 · 자체 호스팅 TCO — 진짜 싼가

"우리 인증을 직접 만들자" 또는 "Keycloak·SuperTokens·Better Auth를 자체 호스팅하자"는 결정은 거의 항상 첫 해의 청구서를 보고 나온다. SaaS Auth0가 월 5,000달러를 보냈는데, Keycloak은 EC2 인스턴스 한 대 100달러면 되니까. 정말 그런가.

5년 TCO를 분해해보자.

SaaS 측 비용 (Clerk·Auth0 B2C 등):

• 라이선스: MAU별 청구서. 10만 MAU 기준 연 2만-10만 달러.
• 인건비: 거의 0. 통합 첫 주에 한 명이 일주일.
• 운영 부담: 0. 다운타임은 그쪽 SLA.
• 마이그레이션 비용: lock-in. 옮기려면 비밀번호 해시·소셜 연결·세션을 어떻게 export하는지 확인 필요.

자체 호스팅 측 비용 (Keycloak·SuperTokens·Better Auth):

• 라이선스: 0.
• 인프라: 인스턴스·DB·로드밸런서·백업. 진지하게 HA·다중 리전이면 월 500-2,000달러.
• 인건비: 초기 셋업 + 운영. 이게 거대하다. SRE 한 명의 시간 0.1-0.3 FTE. 패치·업그레이드·이슈 트러블슈팅·SAML 디버깅. 연간 인건비로 2-6만 달러.
• 보안 부담: 본인이 진다. CVE 대응·패치·취약점 점검. 0-day가 터지면 그날 밤이 사라진다.
• 컴플라이언스: SOC2·ISO27001 감사를 받을 때 인증 시스템도 함께 받는다. 별도 노력.

5년 누적, 10만 MAU 기준 B2C 앱의 매우 단순화한 시뮬레이션:

Clerk Pro + MAU 추가:
  연 평균 4만 달러 × 5년 = 20만 달러
  인건비 (운영) = 5K (통합 작업) + 거의 0 (운영) = 5K
  합계: 약 20.5만 달러

Better Auth 자체 호스팅:
  라이선스: 0
  인프라: 월 800달러 × 60개월 = 4.8만 달러
  인건비: 0.2 FTE × 5년 × 15만 달러/년 = 15만 달러
  합계: 약 20만 달러

놀라운 결과: 5년 TCO가 비슷하게 나온다. 자체 호스팅이 "공짜"가 아니다. 인건비를 정직하게 계산하면 SaaS와 거의 같다. SaaS가 이길 때: 인증이 핵심 비즈니스가 아니고, 작은 팀이고, 운영 시간을 다른 데 쓰고 싶을 때. 자체 호스팅이 이길 때: 데이터 주권 요건, 1M MAU+ 구간, 인증을 깊이 커스터마이즈해야 할 때, 이미 인증을 잘 운영할 SRE가 있을 때.

7장 · Clerk vs WorkOS — 가장 자주 묻는 비교

가장 자주 받는 질문이다. 둘 다 잘 만든 회사이고, 카테고리가 다르다.

Clerk가 이기는 경우:

• 풀스택·B2C·Next.js 우선.
• <SignIn />·<UserButton /> 같은 UI 컴포넌트로 30초 만에 화면을 만들고 싶다.
• 조직 기능은 "있으면 좋음" 수준.
• 작은 팀·인디·스타트업 초기.

WorkOS가 이기는 경우:

• B2B SaaS이고 엔터프라이즈 고객이 매출의 큰 비중.
• SAML·SCIM이 사실상 필수 (Okta·Azure AD·OneLogin·Google Workspace 연결).
• 자체 회원가입 UI는 이미 있고, 엔터프라이즈 readiness만 추가하고 싶음.
• 또는 새 프로젝트인데 처음부터 AuthKit(WorkOS의 hosted 로그인)을 쓰면 1M MAU까지 무료라서 매력적.

둘 다 쓰는 경우도 있다. 일부 회사는 B2C 부분에 Clerk를, 엔터프라이즈 connection에 WorkOS를 같이 쓴다. 깔끔하진 않지만 가능하다.

2026년 변화: WorkOS AuthKit이 SAML·SCIM 외에도 소셜·패스워드리스·passkey를 다 포함하는 hosted UI로 진화하면서 Clerk의 영역과 겹치기 시작했다. 1M MAU 무료 정책으로 인디·스타트업도 끌어들이는 중. Clerk는 반대 방향으로 B2B Organizations·Enhanced Authentication을 키워 WorkOS 쪽으로 침투. 카테고리 경계가 흐려지고 있다.

8장 · 패스워드리스·passkey·magic link — 2026년의 디폴트

2026년 새 프로젝트는 "비밀번호 로그인"이 디폴트가 아니다. 디폴트는 셋 중 하나.

• passkey(WebAuthn). 디바이스 또는 1Password·Bitwarden 같은 패스워드 매니저에 저장되는 공개키. iCloud Keychain·Google Password Manager가 디바이스 간 동기화. 사용자가 "비밀번호를 기억"할 필요가 없다. UX 최강·보안 최강.
• Magic link. 이메일로 일회용 링크를 보내고 클릭하면 로그인. UX는 매우 단순하지만, 이메일 전달 지연·이메일 인증 자체에 대한 회의가 있다.
• OTP(이메일 또는 SMS). 6자리 코드. SMS는 SIM swap 위험과 통신 비용 때문에 권장도가 떨어지는 추세.

2026년 추세는 passkey 우선·magic link 백업·SMS 폐지다. Apple·Google·Microsoft가 모두 passkey를 OS 레벨에서 지원하면서 디바이스 채택률이 80% 이상에 도달했고, 사용자 학습곡선도 사라지는 중이다.

각 프로바이더의 passkey 깊이:

magic link는 거의 모든 프로바이더에 있다. 차이는 이메일 전달성·템플릿 커스터마이즈·재전송 로직·attempt rate limiting 같은 디테일에서 갈린다.

9장 · Lucia 마이그레이션 — 무엇을 어디로

Lucia의 메인테이너 pilcrowOnPaper가 2025년 3월에 다음 메시지를 공식 발표했다.

• Lucia는 "라이브러리"로서의 유지보수가 끝난다.
• 그가 작성한 인증 학습 가이드는 GitHub에서 무료 학습 리소스로 유지된다.
• 그가 작성한 OAuth 클라이언트 라이브러리 Arctic은 계속 유지·활성 개발 중.
• 새 프로젝트는 다른 라이브러리(또는 직접 구현)를 권장.

마이그레이션 옵션:

옵션 1 · Better Auth로 — Lucia의 정신적 후계자. TypeScript 네이티브·세션 기반·DB 어댑터·플러그인. 사용자 테이블·세션 테이블 스키마가 비슷하고 (id·user_id·expires_at), 이메일+패스워드 흐름도 비슷. 2025-26년의 가장 인기 있는 이주 경로.

옵션 2 · Auth.js v5로 — Next.js 중심이라면. 어댑터 API가 다르고, 콜백 모델·세션 처리도 달라서 변환이 좀 더 크다.

옵션 3 · Arctic + 본인 세션 관리 — Lucia에서 OAuth 부분만 분리. 세션은 본인 DB·쿠키로 직접 관리. "Lucia 가이드 정신"을 그대로 유지하는 경로. 학습 코스트는 가장 낮지만 코드 베이스에 흩어진 세션 관리 코드를 인정해야 한다.

옵션 4 · Clerk·WorkOS 같은 SaaS로 — Lucia의 직접 관리 비용이 부담이라면. 비밀번호 해시 형식 호환성 확인 필수. argon2·bcrypt 형식의 import는 대부분 지원되지만, SCRAM·이전 Lucia의 SHA-256 같은 변형은 직접 마이그레이션 스크립트가 필요할 수 있다.

마이그레이션 체크리스트:

• 사용자 테이블 export → 새 스키마로 import.
• 비밀번호 해시 형식 호환성 검증.
• 세션 토큰·쿠키 이름 변경·과거 세션 무효화 정책.
• 이메일 인증·재설정 토큰 처리.
• 소셜 연결 (OAuth provider별 user_id 매핑) 보존.
• 점진 이주 (dual-write) vs 빅뱅 컷오버 선택.

10장 · NextAuth(Auth.js) vs Better Auth — Next.js 라이브러리 선택

자체 호스팅 라이브러리를 선택하면 둘 중 하나로 좁혀진다.

Auth.js (구 NextAuth) — 오래된 안정성·큰 사용자 베이스·많은 통합. v5에서 auth() 헬퍼·App Router 친화·@auth/core로 프레임워크 중립화. 단점: 콜백 API가 복잡(signIn·session·jwt)하고, DB 어댑터 별로 동작이 미묘하게 다름. 깊이 들어가면 학습곡선이 가파르다.

Better Auth — 2024년 등장·2025-26년 폭발적 성장. API가 더 직관적이고, 플러그인 시스템이 깔끔하며, DB 스키마 자동 생성·CLI 도구 제공. TypeScript 타입 추론이 더 강력. Drizzle·Prisma·Kysely·MongoDB 어댑터. Next.js·Nuxt·SvelteKit·Solid·Astro·Hono·Express·Tanstack Start 모두 일급.

선택 기준:

• 이미 Auth.js를 쓰고 있고 동작이 만족스럽다면 → 굳이 옮길 이유 없음.
• 새 프로젝트라면 → Better Auth가 우세. DX·플러그인 시스템·문서가 더 좋다.
• 멀티 프레임워크(Next.js 외에도 SvelteKit·Hono 등)에서 같은 인증을 써야 한다면 → Better Auth.

2026년 현재 npm 트렌드: Auth.js는 안정적 사용 유지, Better Auth는 폭발적으로 성장 중. Auth.js 메인테이너도 Better Auth의 일부 디자인 결정을 차용하는 움직임이 있다.

11장 · 안티패턴 — 자주 보는 실수 10가지

지난 1년 코드리뷰·기술 컨설팅에서 본 실제 실수들.

1. JWT를 세션 대신 쓰면서 revoke가 없다. Access token TTL 24시간 + revoke 없음 = 해고된 직원이 하루 종일 API를 호출할 수 있다. 짧은 TTL + refresh + revoke 리스트 또는 세션 기반으로.
2. Auth0를 쓰면서 모든 기능을 직접 구현. 가입 폼·이메일 전송·MFA를 다 직접 만들면 Auth0를 산 이유가 없다. Universal Login 또는 SDK 위젯을 쓰라.
3. Clerk·Stytch에서 마이그레이션 비용을 0으로 가정. "MAU 늘면 다른 데로 옮기지" — 정말로 비밀번호 해시·소셜 연결·세션을 export할 수 있는지 사전 확인.
4. WorkOS를 SAML 없는데 비싸게 사기. WorkOS의 1순위 가치는 엔터프라이즈 SSO. SAML·SCIM이 없으면 WorkOS의 가치 절반을 안 쓰는 셈.
5. Supabase Auth + 별도 Postgres. Supabase Auth는 Supabase Postgres에 사용자 테이블이 살아야 RLS·트리거가 자연스럽다. 다른 DB에 가입 정보를 옮기면 어색해진다.
6. passkey를 추가했지만 백업 fallback이 없다. 디바이스를 잃은 사용자는 잠긴다. magic link 또는 복구 코드 백업 흐름이 반드시 필요.
7. SAML 디버깅을 자체 구현으로 시도. Okta·Azure AD·OneLogin·Google Workspace 각자의 quirk가 있고, IdP-initiated vs SP-initiated 흐름이 다르다. 2주 동안 진흙탕에 들어가게 된다. WorkOS가 비싼 이유.
8. MAU 가격을 회사 자체 MAU 정의와 일치시키지 않음. 프로바이더의 MAU 정의(예: 월에 한 번이라도 로그인한 사용자, 또는 세션이 만료되지 않은 사용자)와 내 비즈니스의 MAU가 다를 수 있다. 가입자 100만이지만 실제 활성 5만이면 청구서가 다르다.
9. passkey를 "추가했다"고만 하고 측정하지 않음. 실제 사용률은 가입 흐름·UI 카피·iOS/Android 비율에 크게 좌우된다. 측정·실험 없이 "있음" 체크박스만 채우면 ROI가 의심.
10. Lucia를 쓰면서 마이그레이션 계획이 없다. 1년 안에 의무가 된다. 미루지 말 것.

에필로그 — 결정 체크리스트와 다음 글 예고

결정 체크리스트

• 타겟 시장 명확화: B2C·B2B·하이브리드 중 어디?
• 1년·3년 예상 MAU 시뮬레이션.
• 엔터프라이즈 고객 비중·SAML·SCIM 의무 여부.
• 자체 호스팅 vs SaaS 의사결정 (TCO 5년 비교).
• passkey·magic link·MFA 정책.
• 마이그레이션 비용 사전 평가 (lock-in 축).
• 데이터 주권·리전 요건 (특히 EU·한국·일본).
• 컴플라이언스 요구 (SOC2·ISO27001·HIPAA·GDPR·APPI).
• 운영 부담 vs 인건비 솔직한 평가.
• 그리고 가장 중요한 것: "제일 안 좋아 보이는 옵션은 직접 만드는 것이다" — 2년 후 후회한다.

안티패턴 요약

• 인증을 직접 만든다.
• MAU 가격을 처음에만 계산하고 1년 후를 안 본다.
• Auth0를 디폴트로 선택한다(2026년에는 더 이상 디폴트가 아니다).
• 자체 호스팅을 "공짜"라고 가정한다.
• passkey를 추가하지만 측정·fallback 없음.

다음 글 예고

• "WorkOS AuthKit 핸즈온 — Next.js에 1M MAU 무료 인증 30분 셋업"
• "Better Auth 풀스택 셋업 — Drizzle·Postgres·Resend·passkey 플러그인 가이드"
• "엔터프라이즈 SAML 디버깅 — Okta·Azure AD·OneLogin·Google Workspace 호환성 매트릭스"
• "인증 마이그레이션 — 비밀번호 해시 호환성과 점진 컷오버 패턴"

다음 프로젝트의 인증을 결정해야 한다면, 이 글의 8개 축·10개 옵션·결정 트리를 이용해 30분 안에 후보를 두세 개로 좁혀라. 그리고 그 두세 개의 가격 페이지를 직접 펼쳐 본인 워크로드로 실제 견적을 받아라. 추측으로 인증을 결정하지 말 것.

참고 / References

• Clerk Pricing
• Clerk B2B SaaS Authentication Guide
• Clerk vs Auth0 — Comparison
• WorkOS Pricing
• WorkOS AuthKit — 1M MAU Free
• WorkOS vs Auth0 — Documentation
• Auth0 Pricing
• Auth0 by Okta — Official site
• Stytch Pricing
• Stytch Fraud Prevention
• Better Auth — Official site
• Better Auth GitHub
• Lucia Deprecation Announcement — pilcrowOnPaper
• Migrating off Lucia — Better Auth docs
• Auth.js (NextAuth) v5 Docs
• SuperTokens — Open Source Authentication
• SuperTokens vs Auth0 — Comparison
• Kinde Pricing
• Logto — Open Source Identity
• Supabase Auth Docs
• Firebase Authentication Pricing
• WebAuthn / Passkeys — W3C Spec
• FIDO Alliance — Passkeys Overview
• SCIM 2.0 RFC 7644
• SAML 2.0 Core Specification