LabHub

블로그

API & 웹앱 인증 라이브러리 2026 완벽 가이드 - Auth.js v5 · Lucia v3 · better-auth · Clerk · Stytch · WorkOS · Kinde · SuperTokens · Frontegg 심층 분석

2026-05-16 · 37 분 읽기 · #auth-libraries#auth-js#lucia#better-auth#clerk#stytch#workos#kinde#supertokens#frontegg#oauth2#passkeys#webauthn#deep-dive

한국어English日本語

프롤로그 — 2026년에 "인증을 직접 만드는 게 맞나?"

2010년대에 "로그인 화면 정도는 직접 만든다"가 기본값이었다. 2020년대 초반에 Auth0와 Firebase Auth가 등장하면서 "인증은 SaaS에 외주 주는 게 맞다"가 주류가 됐다. 그리고 2026년, 우리는 다시 한 번 갈림길에 섰다.

이 글은 그 지형 전체를 본다. 라이브러리·SaaS 옵션을 하나씩 보고, OAuth 흐름과 패스키 같은 프로토콜 레이어를 풀고, B2B 요구사항(SSO/SCIM/감사로그)을 정리하고, 한국·일본 로컬 인증 제공자까지 다룬다. 마지막에 "누가 무엇을 골라야 하는지" 권고한다.

1장 · 2026년 웹앱 인증 지형도 — Library vs Managed vs OSS-SaaS

크게 세 가지 진영이 있다.

┌──────────────────────────────────────────────────────────────────────┐
│                  2026년 웹앱 인증 옵션 3 카테고리                      │
│                                                                      │
│  ┌────────────────┐   ┌────────────────┐   ┌────────────────────┐   │
│  │  Library       │   │  Managed SaaS  │   │  OSS-SaaS / Hybrid │   │
│  │  (DIY)         │   │  (Buy)         │   │  (Self-host OK)    │   │
│  │                │   │                │   │                    │   │
│  │ - Auth.js v5   │   │ - Clerk        │   │ - SuperTokens      │   │
│  │ - Lucia v3     │   │ - Stytch       │   │ - Logto            │   │
│  │ - better-auth  │   │ - WorkOS       │   │ - Ory Network      │   │
│  │ - iron-session │   │ - Kinde        │   │ - Keycloak Cloud   │   │
│  │ - Passport.js  │   │ - Frontegg     │   │ - Hanko Cloud      │   │
│  │ - JOSE/jose    │   │ - Auth0        │   │                    │   │
│  └────────────────┘   └────────────────┘   └────────────────────┘   │
│       ↑                     ↑                       ↑                │
│   당신의 DB             그들의 DB                 둘 다 가능          │
│   당신의 도메인         그들의 위젯               대부분 둘 다        │
│   $0/MAU              $25~$2000+/M             $0~수백/M            │
└──────────────────────────────────────────────────────────────────────┘

각 진영의 강점과 약점.

카테고리강점약점잘 맞는 팀
Library풀 코드 제어, 비용 0, 데이터 소유보안 책임 100%, 시간 소모, 패스키/SSO 직접 구현시니어 풀스택 1~2명, MAU 10만 미만, 컴플라이언스 자가 책임
Managed빠른 출시, MFA/SSO/SCIM 박스 안, SOC2 상속비용 폭증(MAU 기반), 락인, 도메인 종속시드~시리즈 B 스타트업, MAU 폭증 예상
OSS-SaaS셀프호스트 옵션, 코드 가시성운영 복잡, 매니지드는 결국 매니지드 비용엔터프라이즈, 데이터 주권 요구, EU/한국 규제 산업

2026년의 큰 흐름: 하이브리드가 늘었다. "Clerk으로 시작하고 MAU 5만 넘으면 better-auth로 이주"가 흔한 시나리오다. 이주 비용이 만만찮으니 초기 선택이 여전히 중요하다.

2장 · Auth.js v5 (구 NextAuth.js) — Node/Next.js 사실상 표준

Auth.js v5는 NextAuth.js의 후속이다. 2024년 v5로 메이저 리브랜드를 하면서 Next.js 외에 SvelteKit, SolidStart, Express, Hono 등으로 어댑터를 확장했다.

핵심 모델

// auth.ts (Next.js App Router)
import NextAuth from 'next-auth'
import Google from 'next-auth/providers/google'
import { PrismaAdapter } from '@auth/prisma-adapter'
import { prisma } from '@/lib/prisma'

export const { auth, handlers, signIn, signOut } = NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [Google],
  session: { strategy: 'database' },
  callbacks: {
    async session({ session, user }) {
      session.user.id = user.id
      return session
    },
  },
})

v5의 변경점 (v4 → v5)

강점 / 약점

3장 · Lucia v3 → better-auth로의 흐름

Lucia v3 (저자: pilcrowOnPaper)는 2023~2024년에 "프레임워크에 종속되지 않은 미니멀 세션 라이브러리"로 인기를 끌었다. 핵심은 Lucia 객체 + 어댑터 + 직접 작성하는 라우트. 매직이 거의 없어서 보안에 민감한 팀이 선호했다.

그러나 2025년 3월, 저자는 Lucia의 메인티넌스 모드 진입을 선언했다. 이유: "라이브러리보다는 학습 자료(Copy & Paste)로 가는 게 맞다." 그 자리를 빠르게 채운 게 better-auth다.

better-auth — TypeScript-first, 플러그인 아키텍처

better-auth (저자: bekacru)는 2024년 등장해 2025년 폭발적으로 성장했다. 디자인은 다음과 같다.

// auth.ts
import { betterAuth } from 'better-auth'
import { prismaAdapter } from 'better-auth/adapters/prisma'
import { passkey, twoFactor, organization } from 'better-auth/plugins'

export const auth = betterAuth({
  database: prismaAdapter(prisma, { provider: 'postgresql' }),
  emailAndPassword: { enabled: true },
  socialProviders: {
    google: { clientId: process.env.GOOGLE_CLIENT_ID!, clientSecret: process.env.GOOGLE_CLIENT_SECRET! },
  },
  plugins: [passkey(), twoFactor(), organization()],
})

Auth.js vs better-auth

측면Auth.js v5better-auth
출시2018(NextAuth) → 2024(v5)2024
프레임워크Next.js 중심, 다수 지원Next.js, SvelteKit, Nuxt 등 동등 지원
패스키베타 어댑터정식 플러그인
2FA / MFA직접 구현플러그인
조직 / 멀티테넌시직접 구현플러그인
타입 추론OK더 강함
성숙도높음빠르게 따라오는 중

2026년 시점에서 신규 Next.js 프로젝트라면 better-auth를 진지하게 검토할 가치가 있다. Auth.js는 안정성과 생태계, better-auth는 기능 풍부함과 타입 안전성으로 갈린다.

4장 · Clerk — 매니지드 UX의 황금 표준

Clerk(2021 창업, YC W21)은 2024~2026년 매니지드 인증 SaaS의 사실상 표준이 됐다. 강점은 명확하다.

가격 (2026년 1분기 기준)

코드 샘플

// app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({ children }) {
  return (
    <ClerkProvider>
      <html><body>{children}</body></html>
    </ClerkProvider>
  )
}

// app/sign-in/page.tsx
import { SignIn } from '@clerk/nextjs'
export default function Page() {
  return <SignIn />
}

Clerk의 함정

5장 · Stytch — 패스워드리스 중심, B2C/B2B 분리

Stytch(2020 창업, 시리즈 B $$로 평가)는 패스워드리스 인증에 가장 일찍 집중했다.

B2B SaaS 시나리오에서 강점

Stytch B2B는 조직 단위로 인증이 설계됐다.

import { StytchClient } from 'stytch'

const stytch = new StytchClient({
  project_id: process.env.STYTCH_PROJECT_ID!,
  secret: process.env.STYTCH_SECRET!,
})

// 매직 링크 발송
await stytch.magicLinks.email.loginOrCreate({
  email: 'user@acme.com',
  login_magic_link_url: 'https://app.example.com/auth/callback',
})

가격

6장 · WorkOS — 엔터프라이즈 SSO/SCIM에 특화

WorkOS는 "B2B SaaS가 엔터프라이즈로 올라갈 때 막히는 SSO/SCIM/감사로그를 한 박스로 푼다"가 포지셔닝이다.

핵심 가격 모델

WorkOS의 가격은 다른 곳과 다르다.

즉 B2B 한 고객(엔터프라이즈)이 SSO로 $99/월이면 그게 곧 매출인 셈이다. "엔터프라이즈 한 명 = 평균 LTV 수만 달러"라는 SaaS 비즈니스에 잘 맞춘 가격.

코드 샘플 — SSO 흐름

import { WorkOS } from '@workos-inc/node'

const workos = new WorkOS(process.env.WORKOS_API_KEY!)

// 1) 로그인 URL 생성
const authUrl = workos.sso.getAuthorizationUrl({
  connection: 'conn_01EHWNCE74X7JSDV0X3SZ3KJNY',
  redirectUri: 'https://app.example.com/callback',
  clientId: process.env.WORKOS_CLIENT_ID!,
})

// 2) 콜백에서 프로필 가져오기
const { profile, accessToken } = await workos.sso.getProfileAndToken({
  code: searchParams.code,
  clientId: process.env.WORKOS_CLIENT_ID!,
})

7장 · Kinde — 풀스택 매니지드, "Auth0보다 싸고 단순"

Kinde(2022 호주 창업)는 "Auth0의 복잡함과 가격을 줄인다"가 목표였다. 결과적으로 다음을 박스 안에 넣는다.

가격

특이점: Free 플랜이 가장 넉넉. 1만 MAU 무료가 2026년 시점에서 가장 후하다.

8장 · SuperTokens — 오픈소스 SaaS, 셀프호스트 가능

SuperTokens (2020 창업, YC W21)는 오픈소스 + 매니지드의 양다리 모델이다.

가격

코드 샘플

import SuperTokens from 'supertokens-node'
import Session from 'supertokens-node/recipe/session'
import ThirdPartyEmailPassword from 'supertokens-node/recipe/thirdpartyemailpassword'

SuperTokens.init({
  framework: 'express',
  supertokens: {
    connectionURI: 'http://localhost:3567', // 또는 managed core URL
  },
  appInfo: {
    appName: 'My App',
    apiDomain: 'https://api.example.com',
    websiteDomain: 'https://example.com',
  },
  recipeList: [
    ThirdPartyEmailPassword.init({ /* providers */ }),
    Session.init(),
  ],
})

SuperTokens의 한 줄 평: "오픈소스 충성도가 높지만 매니지드도 받고 싶을 때."

9장 · Frontegg — B2B 매니지드 고객 인증

Frontegg(2019 이스라엘 창업)는 B2B SaaS의 고객 인증을 풀스택으로 풀겠다는 포지셔닝이다.

WorkOS와 포지셔닝이 겹치지만 차이가 있다.

10장 · Hanko — 패스키-퍼스트 OSS

Hanko는 독일발 OSS 프로젝트로 "패스워드를 죽이자"가 슬로건. 패스키, WebAuthn, 패스코드(OTP) 중심.

<script type="module" src="https://esm.sh/@teamhanko/hanko-elements/dist/elements.js"></script>
<hanko-auth api="https://your-hanko-api.example.com"></hanko-auth>

패스키만 빠르게 깔고 싶다면 Hanko가 가장 단순하다. 다만 OAuth 소셜 로그인 지원이 다른 라이브러리보다 얇다.

11장 · Passport.js / iron-session / jose — Node 레거시 + 미니멀

세 가지 클래식.

// jose로 JWT 발급 / 검증
import { SignJWT, jwtVerify } from 'jose'

const secret = new TextEncoder().encode(process.env.JWT_SECRET!)

const token = await new SignJWT({ sub: 'user-42' })
  .setProtectedHeader({ alg: 'HS256' })
  .setExpirationTime('15m')
  .sign(secret)

const { payload } = await jwtVerify(token, secret)

세 라이브러리는 위의 큰 SaaS/라이브러리들의 "내부 부품"이다. 직접 조립하는 팀이 줄었지만, API 게이트웨이나 마이크로서비스 인증에서는 여전히 1선 도구.

12장 · OAuth 흐름 — Authorization Code with PKCE가 정답

2026년에 OAuth 흐름은 다음과 같이 정리됐다.

┌─────────────────────────────────────────────────────────────────┐
│                  2026년 OAuth 흐름별 권고                       │
│                                                                 │
│  Authorization Code + PKCE      → 웹앱, 모바일, SPA ✓ (표준)   │
│  Client Credentials              → 서버 간 (M2M) ✓             │
│  Device Authorization            → TV/CLI/IoT ✓                │
│  Refresh Token Rotation          → 모든 흐름과 결합 ✓          │
│  Resource Owner Password         → 금지 (레거시 호환만)         │
│  Implicit Flow                   → 폐지 (PKCE로 대체)           │
└─────────────────────────────────────────────────────────────────┘

OAuth 2.1 (드래프트 → 2024~2025년 RFC 진행)에서 Implicit과 ROPC는 공식 제거됐다. 새 코드에서 절대 쓰지 말 것.

PKCE — SPA/모바일의 필수

PKCE(Proof Key for Code Exchange, RFC 7636)는 SPA와 모바일에서 client_secret을 보관할 수 없는 문제를 푼다.

  1. 클라이언트가 code_verifier(랜덤 문자열) 생성.
  2. SHA256 해시를 code_challenge로 IdP에 전송.
  3. IdP가 authorization_code 발급.
  4. 토큰 교환 시 클라이언트가 원래 code_verifier를 보냄.
  5. IdP가 해시 비교 후 액세스 토큰 발급.

이 흐름으로 중간자가 authorization_code를 가로채도 토큰 교환을 못한다. 2026년 모든 모던 IdP/라이브러리가 기본 활성화한다.

13장 · 패스키 / WebAuthn — 2026년 사실상 표준

2026년 시점에서 패스키 채택은 임계점을 넘었다.

패스키의 작동 원리 요약

  1. 등록 시: 디바이스가 공개키/비공개키 쌍 생성. 비공개키는 디바이스(Secure Enclave/TPM)에 머무름.
  2. 서버는 공개키만 받음.
  3. 로그인 시: 서버가 챌린지(랜덤 nonce) 발급. 디바이스가 비공개키로 서명. 서버가 공개키로 검증.
  4. iCloud Keychain / Google Password Manager로 디바이스 간 동기화 가능.

라이브러리/SaaS별 패스키 지원 (2026Q1)

솔루션패스키 지원비고
Clerk정식UI/UX 가장 매끄러움
Stytch정식헤드리스 SDK
Hanko정식 (퍼스트)패스키 중심 설계
better-auth플러그인1~2줄로 활성화
SuperTokens정식셀프호스트 시 가장 자유
Auth.js v5베타 어댑터일부 한계
WorkOS AuthKit정식엔터프라이즈 친화

SimpleWebAuthn — 직접 구현할 때

직접 WebAuthn을 다룬다면 SimpleWebAuthn이 2026년 사실상 표준 라이브러리다. 백엔드(@simplewebauthn/server)와 브라우저(@simplewebauthn/browser) 양쪽 제공.

14장 · 매직 링크 / OTP / TOTP — 패스워드리스의 세 축

매직 링크, OTP(SMS/이메일), TOTP(인증 앱)는 패스워드의 대안이자 MFA의 두 번째 요소로 쓰인다.

방식보안UX비용잘 맞는 곳
패스키최상 (피싱 저항)최상무료모든 신규
TOTP상 (오프라인)중무료MFA
이메일 OTP중 (이메일 보안 의존)중낮음가입, 복구
매직 링크중 (URL 도용 위험)좋음낮음패스워드리스 1차
SMS OTP하 (SIM 스왑)좋음높음마지막 보루

매직 링크 구현 핵심

매직 링크는 단일 사용, 짧은 만료, IP/디바이스 바인딩이 핵심이다.

// 매직 링크 토큰 발급
const token = crypto.randomBytes(32).toString('base64url')
const hash = createHash('sha256').update(token).digest('hex')

await db.magicLink.create({
  data: {
    userId: user.id,
    tokenHash: hash, // 원본 저장 금지
    expiresAt: new Date(Date.now() + 15 * 60 * 1000), // 15분
    ip: request.ip,
  },
})

const url = `https://example.com/auth/verify?token=${token}`
await sendEmail({ to: user.email, magicLinkUrl: url })

Twilio Verify — SMS OTP의 사실상 표준

SMS OTP는 직접 구현하지 말고 Twilio Verify, Vonage, AWS SNS 같은 매니지드를 쓰는 게 일반적이다. 이유:

2026년 시점에서 SMS 비용 자체가 1통 0.01 0.01~0.10. 트라피킹(traffic pumping) 공격으로 한 달 수천 달러 손해 사례가 늘었다. 반드시 rate limiting + reCAPTCHA/Turnstile를 결합.

15장 · 세션 vs JWT — 2026년의 올바른 답

영원한 토론. 2026년의 답은 명확하다: 세션 > JWT, 단 액세스 토큰은 단명 JWT.

비교표

측면서버 세션 (DB/Redis)JWT (스테이트리스)
즉시 만료가능 (행 삭제)불가능 (만료까지 유효)
검증 비용DB/Redis 라운드트립서명 검증만
확장성Redis 클러스터 필요무한 (전제: 비밀키 안전)
데이터 노출쿠키만 (불투명)페이로드 base64 노출
복구키 회전 가능키 회전 후 재로그인
권장 사용사용자 세션M2M, 짧은 액세스 토큰

2026년 권장 패턴 — 하이브리드

┌─────────────────────────────────────────────────────────┐
│                  하이브리드 권장 흐름                    │
│                                                         │
│  1) 로그인 후 서버가 발급:                              │
│     - access_token (JWT, 5~15분, 페이로드에 권한)       │
│     - refresh_token (불투명, DB 저장, 7~30일)           │
│                                                         │
│  2) API 호출 시 access_token으로 인증                   │
│     - 서명 검증만, DB 안 봄                             │
│                                                         │
│  3) access 만료 시 refresh로 갱신                       │
│     - DB의 refresh 행 확인 후 새 access 발급            │
│     - refresh도 회전(rotation) — 사용된 건 무효화       │
│                                                         │
│  4) 즉시 로그아웃 시 refresh 행 삭제                    │
│     - access는 자연 만료까지 유효                       │
│     - 더 빠른 차단이 필요하면 access도 짧게             │
└─────────────────────────────────────────────────────────┘

이 패턴은 OAuth 2.0의 refresh token rotation과 동일하다. 2026년 모던 IdP/라이브러리 디폴트.

16장 · 토큰 저장 — HttpOnly 쿠키가 정답

브라우저에서 토큰을 어디 저장하는가가 끊임없는 논쟁이다.

저장소XSS 안전CSRF 안전새로고침 유지권고
HttpOnly + Secure + SameSite=Lax 쿠키안전거의 안전유지사용자 세션
localStorage위험 (JS 접근)안전 (자동전송 없음)유지비추
sessionStorage위험안전탭 닫으면 손실비추
메모리 변수안전안전새로고침 손실액세스 토큰만

권장 조합

CSRF 방어: SameSite=Lax/Strict + state 토큰 또는 double-submit cookie. SameSite만으로 CSRF가 완전 방어되지는 않는다(같은 사이트 sub-domain 공격, GET state-changing 등).

17장 · OWASP A07 — 인증 실패 Top 5 함정

OWASP Top 10 2021의 A07: Identification and Authentication Failures. 2026년에도 살아있는 함정.

1) 무차별 대입 보호 부재

2) 계정 열거(Account Enumeration)

3) 약한 비밀번호 정책

4) 세션 고정(Session Fixation)

5) 비밀번호 저장 실패

18장 · B2B 인증 요구사항 — SSO / SCIM / 감사 / IP / MFA 강제

B2B SaaS가 엔터프라이즈 고객을 잡으려면 다음 다섯이 거의 필수다.

  1. SSO (SAML 2.0 + OIDC) — Okta, Microsoft Entra, Google Workspace 등 IdP 연동.
  2. SCIM (System for Cross-domain Identity Management) — 고객 IdP에서 사용자 생성/비활성화가 자동 반영.
  3. 감사 로그 — 누가 언제 무엇을 했는지. SOC2, ISO 27001, HIPAA 요건.
  4. IP 허용목록 / 거부목록 — 특정 IP 대역에서만 로그인.
  5. MFA 강제 — 조직 단위로 "MFA 필수" 정책.

"엔터프라이즈 인증 세금"

B2B SaaS 업계에는 "엔터프라이즈 SSO 요구하면 가격이 10배"라는 농담이 있다. 이유:

라이브러리로 만들 때는 boxyhq/saml-jackson이나 SuperTokens의 멀티테넌트 모드를 검토할 가치가 있다.

19장 · 한국 인증 — NAVER · Kakao · PASS · 카카오 인증서

한국 시장에 특화된 인증 흐름.

Auth.js에서 NAVER 추가

// auth.ts
import Naver from 'next-auth/providers/naver'

export const { auth } = NextAuth({
  providers: [
    Naver({
      clientId: process.env.NAVER_CLIENT_ID!,
      clientSecret: process.env.NAVER_CLIENT_SECRET!,
    }),
  ],
})

Kakao도 동일한 패턴. 한국 사용자가 주 타겟이면 둘 다 거의 필수.

20장 · 일본 인증 — LINE · Yahoo!Japan · Mercari · d ACCOUNT

일본 시장 특화.

LINE Login 추가

Auth.js에 LINE 프로바이더가 있다. 일본 사용자 비중이 큰 서비스(특히 이커머스, 음식 배달, 게임)는 LINE을 1차 옵션으로 두는 게 표준.

21장 · 봇 방어 — Turnstile · hCaptcha · reCAPTCHA Enterprise · Arkose

CAPTCHA는 2026년에 거의 보이지 않는 방향으로 진화했다.

Cloudflare Turnstile 사이드 by 사이드

<form action="/login" method="POST">
  <div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>
  <button type="submit">Sign in</button>
</form>
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

서버 검증.

const response = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
  method: 'POST',
  body: new URLSearchParams({
    secret: process.env.TURNSTILE_SECRET!,
    response: token,
    remoteip: clientIp,
  }),
})

2026년 신규 프로젝트라면 Turnstile부터 검토. 무료이고 UX가 가장 매끄럽다.

22장 · AI 시대의 봇 방어 — 패시브 신호 + 행동 분석

LLM 시대에 자동화 공격이 폭증했다. 2026년의 봇 방어는 다음이 결합된다.

Castle, Sift, Stytch Fraud & Risk, Arkose Bot Manager 같은 매니지드가 이 영역을 채운다. 직접 구현은 매우 어렵다.

23장 · 마이그레이션 시나리오 — Clerk → Auth.js, Auth0 → Stytch

매니지드에서 라이브러리로(또는 다른 매니지드로) 이주하는 시나리오가 흔하다.

Clerk → Auth.js + Postgres

  1. Clerk Admin Dashboard에서 사용자 export(JSON).
  2. Postgres에 users, accounts, sessions 테이블 만들고 import.
  3. 비밀번호 해시 이관 불가 — Clerk는 자기 해시를 안 준다. 두 가지 옵션:
    • 옵션 A: 모든 사용자에게 "비밀번호 재설정" 이메일 발송.
    • 옵션 B: 패스워드 없이 매직 링크/OAuth만 허용.
  4. OAuth 계정은 accounts 테이블의 providerAccountId로 다시 매핑.
  5. 활성 세션은 무효화 → 모두 재로그인.

Auth0 → Stytch

Auth0 패스워드 해시는 export 시 받을 수 있다(bcrypt). Stytch가 bcrypt 해시 import를 받기 때문에 비밀번호 그대로 이관 가능.

Stytch Migration Docs 참조.

키 회전과 점진적 이주

대규모 서비스는 이중 발행 기간을 둔다.

24장 · 누가 무엇을 골라야 하나

지형을 다 봤으니 결정 트리.

START
  │
  ├─ MVP / 사이드 프로젝트 / MAU < 10,000인가?
  │     YES → Auth.js v5 또는 Clerk Free
  │            (Next.js → better-auth 검토)
  │
  ├─ B2C 대규모 (MAU 10만+) + 매니지드 가능?
  │     YES → Clerk 또는 Stytch
  │     (가격 시뮬레이션 필수)
  │
  ├─ B2B SaaS 엔터프라이즈 SSO 필요?
  │     YES → WorkOS (SSO/SCIM)
  │           + 자체 인증 (Auth.js / better-auth)
  │           또는 Stytch B2B / Frontegg 통합
  │
  ├─ 데이터 주권 / 셀프호스트 필수?
  │     YES → SuperTokens (셀프호스트)
  │           또는 Logto, Ory Network (별도 글)
  │
  ├─ 패스키-퍼스트로 패스워드 없애기?
  │     YES → Hanko 또는 Clerk
  │
  ├─ 미니멀 / 코드 가시성 / 의존성 최소?
  │     YES → iron-session + jose 조립
  │
  └─ 한국 / 일본 사용자 비중 큼?
        YES → 위 선택 + NAVER/Kakao(KR) 또는 LINE/Yahoo!JP(JP) 프로바이더
              직접 추가

에필로그 — 2026년 인증의 다음 결정 지점

세 가지 큰 흐름을 정리한다.

  1. 패스키는 더 이상 옵션이 아니다. 2026년 신규 프로젝트가 패스키 없이 출시되는 건 보안 부채의 시작이다. Clerk, Stytch, Hanko, better-auth 중 어느 걸 쓰든 패스키를 켜라.
  2. MAU 가격 모델을 시뮬레이션하라. Clerk/Stytch/Auth0의 $25~99/월은 출발 단가일 뿐이다. MAU 10만에서의 청구서를 모델링하고, 5만 시점에 이주 계획을 세워두는 게 안전하다.
  3. B2B로 가면 WorkOS 같은 SSO 레이어를 일찍 검토하라. 엔터프라이즈 고객이 SSO를 요구할 때 직접 구현하면 2~4주가 SSO 디버깅에 녹는다. 미리 깔아두는 게 싸다.

"인증 라이브러리/SaaS 선택은 6개월의 빠른 출시와 5년의 운영 비용을 동시에 결정한다. 빠른 시작만 보지 말고 마이그레이션 비용을 함께 보라."

같은 매니지드라도 데이터 포터빌리티(특히 비밀번호 해시 export 가능 여부)가 5년 후의 자유도를 결정한다. 인증을 인프라 결정으로 다룰 것 — 데이터베이스 선택만큼 무겁게.

참고 / References

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다