Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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" 셋 중 하나.

| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

| Email/Password | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 |

| Social Login | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 | 있음 |

| Magic Link | 있음 | 있음 | 있음 | 핵심 | 플러그인 | 있음 | 있음 | 있음 | 부분 | 있음 |

| Passkey/WebAuthn | 있음 | 있음 | 있음 | 핵심 | 플러그인 | 있음 | 있음 | 베타 | 베타 | 베타 |

| TOTP MFA | 있음 | 있음 | 있음 | 있음 | 플러그인 | 있음 | 있음 | 있음 | 있음 | 부분 |

| SMS OTP | 있음 | 있음 | 있음 | 있음 | 플러그인 | 있음 | 있음 | 있음 | 있음 | 부분 |

| UI 컴포넌트 | 강함 | 강함(AuthKit) | 있음 | 있음 | 약함 | 있음 | 있음 | 있음 | 약함 | 없음 |

| B2B Organizations | 있음 | 강함 | 유료 | 있음 | 플러그인 | 있음 | 유료 | 부분 | 부분 | 부분 |

| SAML SSO | 유료 | 핵심 | 유료 | 있음 | 플러그인 | 유료 | 유료 | 유료 | 없음 | 직접 |

| SCIM Provisioning | 유료 | 핵심 | 유료 | 있음 | 없음 | 유료 | 유료 | 없음 | 없음 | 없음 |

| Audit Logs | 부분 | 핵심 | 유료 | 있음 | 플러그인 | 부분 | 부분 | 있음 | 부분 | 직접 |

| 자체 호스팅 | 불가 | 불가 | 사실상 불가 | 불가 | 핵심 | 불가 | 가능 | 가능 | 불가 | 가능 |

| Open Source | 비공개 | 비공개 | 비공개 | 비공개 | MIT | 비공개 | Apache 2.0 | Apache 2.0 | 비공개 | MIT |

| Fraud/Bot 탐지 | 부분 | 부분 | 유료 | 핵심 | 없음 | 부분 | 없음 | 없음 | 부분 | 없음 |

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

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

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

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

| 프로바이더 | 월 청구서 (추정) | 메모 |

| --- | --- | --- |

| Clerk | 약 $250 | Pro $25 + MAU 초과분 (10K 무료 후 MAU당 $0.02) |

| WorkOS AuthKit | $0 | 1M MAU 무료 (2026년 정책) |

| Auth0 B2C Pro | 약 $1,500-2,500 | 5,000 MAU 가격대만 해도 이미 $1,500 |

| Stytch | 약 $400-800 | Pro $249 + MAU 초과 |

| Better Auth | $0 + 호스팅비 | 라이브러리 무료, DB·서버 비용만 |

| Kinde | 약 $89-200 | Plus $89 + MAU 추가 |

| SuperTokens 자체 | $0 + 호스팅비 | OSS, 운영 인건비는 별도 |

| Supabase Auth | $25-100 | Supabase Pro 안에 포함 |

| Firebase Auth | $0 | 50,000 MAU 무료 한도 |

| Auth.js 자체 | $0 + 호스팅비 | OSS, DB·이메일 본인 |

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

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

| 프로바이더 | 월 청구서 (추정) | 메모 |

| --- | --- | --- |

| Clerk + Enhanced Auth | 약 $200-400 | Pro + Enhanced Authentication add-on($100/월 + SAML 사용량) |

| WorkOS | 약 $7,500-8,000 | SSO connection 60개 × $125 = $7,500 |

| Auth0 B2B | $5,000-15,000 | Enterprise Connections·Organizations는 견적제 |

| Stytch B2B | $499/월 + add-on | SAML·SCIM 포함된 B2B 티어 |

| Better Auth | $0 + 호스팅비 | 플러그인으로 SSO·SAML·SCIM 직접 구현 |

| Kinde Plus | $89/월 + 사용량 | SAML add-on 별도 |

| SuperTokens Pro | 약 $300-500 | 자체 호스팅 + 일부 유료 기능 |

| Supabase | 부적합 | B2B SSO·SCIM 약함 |

| Firebase | 부적합 | B2B SAML 없음 |

| Auth.js | $0 + 호스팅비 | SAML·SCIM은 사실상 직접 구현 |

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

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

| 프로바이더 | 월 청구서 (추정) |

| --- | --- |

| Clerk | $5,000-10,000+ |

| WorkOS AuthKit | 약 $0-수백 (1M MAU 무료 한도 내) |

| Auth0 B2C | $20,000-40,000+ |

| Stytch | $5,000-10,000 |

| Better Auth | 약 $200-2,000 (DB·서버 비용) |

| Firebase Auth | 약 $1,500-2,500 (MAU 단가) |

| Supabase | 약 $1,000+ (DB·트래픽) |

해석: 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 깊이:

| 프로바이더 | passkey 지원 |

| --- | --- |

| Stytch | 핵심 카테고리·최고 깊이 |

| Clerk | 안정적 일급 지원 |

| WorkOS AuthKit | 안정적 일급 지원 |

| Auth0 | 일급 지원 |

| Kinde | 일급 지원 |

| Better Auth | passkey 플러그인 (안정) |

| SuperTokens | 일급 지원 |

| Supabase | 베타 |

| Firebase | 베타·플랫폼별 차이 |

| Auth.js | 베타·어댑터 의존 |

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](https://clerk.com/pricing)

- [Clerk B2B SaaS Authentication Guide](https://clerk.com/blog/b2b-saas-authentication)

- [Clerk vs Auth0 — Comparison](https://clerk.com/compare/auth0)

- [WorkOS Pricing](https://workos.com/pricing)

- [WorkOS AuthKit — 1M MAU Free](https://workos.com/blog/authkit-free-up-to-1m-maus)

- [WorkOS vs Auth0 — Documentation](https://workos.com/blog/workos-vs-auth0)

- [Auth0 Pricing](https://auth0.com/pricing)

- [Auth0 by Okta — Official site](https://www.okta.com/products/auth0/)

- [Stytch Pricing](https://stytch.com/pricing)

- [Stytch Fraud Prevention](https://stytch.com/products/fraud-prevention)

- [Better Auth — Official site](https://www.better-auth.com/)

- [Better Auth GitHub](https://github.com/better-auth/better-auth)

- [Lucia Deprecation Announcement — pilcrowOnPaper](https://github.com/lucia-auth/lucia/discussions/1714)

- [Migrating off Lucia — Better Auth docs](https://www.better-auth.com/docs/guides/migrating-from-lucia)

- [Auth.js (NextAuth) v5 Docs](https://authjs.dev/)

- [SuperTokens — Open Source Authentication](https://supertokens.com/)

- [SuperTokens vs Auth0 — Comparison](https://supertokens.com/blog/supertokens-vs-auth0)

- [Kinde Pricing](https://kinde.com/pricing/)

- [Logto — Open Source Identity](https://logto.io/)

- [Supabase Auth Docs](https://supabase.com/docs/guides/auth)

- [Firebase Authentication Pricing](https://firebase.google.com/pricing)

- [WebAuthn / Passkeys — W3C Spec](https://www.w3.org/TR/webauthn-3/)

- [FIDO Alliance — Passkeys Overview](https://fidoalliance.org/passkeys/)

- [SCIM 2.0 RFC 7644](https://datatracker.ietf.org/doc/html/rfc7644)

- [SAML 2.0 Core Specification](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)