풀스택 개발에서 가장 흔한 함정이 바로 회원가입·로그인을 직접 만드는 것입니다. 튜토리얼 몇 개 보고 bcrypt 한 줄 넣어 비밀번호를 저장하고 세션 쿠키를 발급하면 끝이라고 생각하기 쉽습니다. 그런데 실제 운영에서 이게 가장 위험한 영역이고, 사고가 터지면 회사가 사라질 수도 있는 비대칭 리스크 구간입니다.
2024년 한국에서만 개인정보 유출 신고가 307건, 그중 56%가 해킹이었고, 가장 흔한 공격 벡터가 인증·세션 관리 취약점입니다. 결혼정보회사 듀오정보는 회원 약 42만 명 개인정보 유출로 과징금 약 12억 원을 맞았고, 2025년 개정 개인정보보호법은 반복적·중대한 위반 시 매출의 최대 3%까지 과징금(국회 개정안에서는 10%까지 상향 논의)을 부과합니다. 인디 개발자가 한 번 사고 터지면 회복이 불가능한 수준입니다.
이 문서는 인증을 직접 만들면 안 되는 이유를 보안·법률·운영 측면에서 빠짐없이 정리합니다. OWASP Top 10에서 매년 상위권을 차지하는 Broken Authentication, 실제 CVE 사례, 한국 개인정보보호법 과징금 사례, 그리고 그 대안으로 Clerk·WorkOS·Supabase Auth·Firebase Auth·Auth0 같은 전문 서비스가 무엇을 대신 책임져 주는지까지 다룹니다.
결론부터 말하면 인증·개인정보는 절대 직접 만들지 말고 전문 SaaS에 위탁해야 합니다. 돈을 아끼는 게 아니라 책임을 분담하는 일이고, 사고가 터졌을 때 법적 방어선이 되는 일입니다.
1. 비밀번호 저장에서 터지는 위험
비밀번호를 안전하게 저장하는 일은 생각보다 훨씬 어렵습니다. 단순히 해싱 함수 하나 부르는 게 아니라 알고리즘 선택·파라미터 설정·솔트·페퍼·키 회전까지 모두 정확해야 합니다.
1.1. 잘못된 해싱 알고리즘 선택
- MD5는 2004년부터 깨진 알고리즘입니다. 충돌이 잘 일어나고 GPU 한 대로 초당 수십억 개의 해시를 역산할 수 있습니다. 그런데 아직도 레거시 시스템에 남아있는 경우가 많습니다.
- SHA1·SHA256·SHA512는 빠른 해시 함수라 비밀번호용으로 부적절합니다. 빠르다는 건 공격자도 빠르게 무차별 대입할 수 있다는 뜻입니다.
- 비밀번호 저장에는 반드시 bcrypt·scrypt·Argon2·PBKDF2 같은 KDF(Key Derivation Function)를 써야 합니다. 의도적으로 느리게 설계된 함수입니다.
- bcrypt를 쓰더라도 work factor(cost)를 너무 낮게 설정하면 무의미합니다. 2026년 기준 최소 12 이상 권장이고 서버 성능에 따라 더 높여야 합니다.
- Argon2id가 현재 OWASP 권장 1순위 알고리즘이지만 메모리·시간 파라미터를 잘못 설정하면 똑같이 뚫립니다.
1.2. 솔트와 페퍼 잘못 다루기
같은 비밀번호도 사용자마다 다른 해시가 되도록 사용자별 랜덤 솔트가 필수입니다. 자체 구현에서 흔한 실수는 다음과 같습니다.
- 솔트를 아예 쓰지 않거나 모든 사용자에게 같은 솔트 사용
- 솔트를 너무 짧게(16바이트 미만) 생성
- 암호학적으로 안전하지 않은 난수 생성기(rand·Math.random) 사용
- 페퍼(서버 측 비밀값)를 코드에 하드코딩하거나 깃허브에 커밋
- 해시 알고리즘 업그레이드 시 기존 해시를 마이그레이션할 전략 부재
1.3. 실제 비밀번호 유출 통계
Have I Been Pwned 데이터베이스에는 2025년 기준 140억 개 이상의 유출된 자격증명이 등록돼 있고, 2025년 한 해에만 1억 8,300만 개의 새 이메일이 추가됐습니다. 이 중 상당수가 약한 해싱 알고리즘(MD5·SHA1)으로 저장됐다가 평문으로 복원된 비밀번호입니다.
핵심 포인트: 비밀번호 해시 DB가 한 번 유출되면 사용자 통지·당국 신고·집단소송까지 갑니다. 한국에서는 1,000명 이상 유출 시 개인정보보호위원회 의무 신고이고, 통지·고지 절차를 안 지키면 별도 과태료까지 부과됩니다.
2. 세션과 토큰 관리에서 터지는 위험
인증이 성공해도 끝이 아닙니다. 로그인 후 발급되는 세션·토큰을 어떻게 관리하느냐가 더 중요합니다. OWASP는 Broken Authentication을 매년 Top 10 상위권에 올리고 있고, 그 핵심이 세션 관리 실패입니다.
2.1. 세션 하이재킹 공격
- HTTPS를 안 쓰면 네트워크 도청으로 세션 쿠키가 그대로 탈취됩니다. HTTP 시대의 Firesheep 사건이 대표적입니다.
- 쿠키에 Secure·HttpOnly·SameSite 플래그를 안 걸면 XSS·CSRF로 탈취당합니다.
- 세션 ID를 URL에 노출하면 Referer 헤더·로그·북마크·공유링크로 새어 나갑니다.
- 세션 ID를 예측 가능한 패턴(증가하는 정수, 타임스탬프 기반)으로 생성하면 무차별 추측이 가능합니다.
- 로그아웃 시 서버 측 세션을 폐기하지 않으면 탈취된 세션이 계속 유효합니다.
2.2. 세션 고정 공격
공격자가 미리 만든 세션 ID를 피해자에게 사용하게 만들어, 피해자가 로그인하면 그 세션을 그대로 가로채는 공격입니다. 로그인 직후 세션 ID를 재발급하지 않으면 자동으로 취약합니다. 자체 구현에서 이걸 빼먹는 경우가 정말 많습니다.
2.3. JWT를 잘못 쓰는 패턴
JWT는 직접 다루기 정말 어려운 기술입니다. 부적절한 JWT 구현 사고의 대부분이 토큰 저장·전송 방식 취약점입니다.
- 시크릿 키를 약하게 설정:
secret,password123같은 키는 무차별 대입 1초면 깨집니다. - 시크릿 키를 깃허브 퍼블릭 레포에 커밋하는 사고가 매주 일어납니다. GitGuardian 보고서에 따르면 매년 수백만 개의 시크릿이 노출됩니다.
alg: none취약점: 토큰 헤더의 알고리즘을 none으로 바꿔 서명 검증을 우회하는 고전적 공격. 라이브러리 잘못 쓰면 아직도 발생.- RS256 토큰을 HS256으로 바꿔 공개키를 시크릿으로 사용해 위조하는 알고리즘 혼동 공격.
- JWT를 localStorage에 저장하면 XSS 한 방에 통째로 탈취됩니다. HttpOnly 쿠키여야 합니다.
- JWT는 기본적으로 취소(revoke) 불가능합니다. 로그아웃·계정 정지 시 토큰이 만료 전까지 계속 유효해서 별도 블랙리스트 DB가 필요합니다.
2.4. 실제 CVE 사례
2025년 3월 공개된 CVE-2025-29927 (Next.js 미들웨어 인증 우회)는 심각도 9.1점의 치명적 취약점이었습니다. x-middleware-subrequest 헤더 하나로 모든 인증 미들웨어를 우회할 수 있었습니다. 2023년 CVE-2023-48309 (NextAuth.js)는 중단된 OAuth 흐름의 JWT를 가지고 빈 사용자 객체를 만들어 인증을 우회하는 취약점이었습니다.
전문 인증 라이브러리도 이렇게 자주 취약점이 나오는데 개인이 직접 만들면 발견조차 못한 채 운영되는 게 현실입니다.
3. OAuth와 소셜 로그인의 함정
구글 로그인만 쓰면 안전할 거라 생각하기 쉬운데, OAuth 흐름을 직접 구현하면 함정이 더 많습니다.
3.1. state 파라미터 누락으로 인한 CSRF
OAuth 2.0 인증 요청에 state 파라미터가 없거나 검증하지 않으면 CSRF 공격이 가능합니다. 공격자가 자신의 OAuth 코드로 피해자의 계정을 자기 소셜 계정과 연결시키는 "계정 바인딩 공격"이 가능해집니다. 실제로 페이스북·구글·마이크로소프트 OAuth에서 이 방식으로 계정 탈취가 보고된 사례가 다수 있습니다.
3.2. PKCE 미구현
모바일 앱이나 SPA는 클라이언트 시크릿을 안전하게 보관할 수 없습니다. 그래서 OAuth 2.1부터는 PKCE(Proof Key for Code Exchange) 가 사실상 의무입니다. PKCE 없이 Authorization Code Grant를 쓰면 인증 코드 가로채기 공격에 취약합니다. 자체 구현 OAuth 클라이언트의 대부분이 PKCE를 빼먹습니다.
3.3. Redirect URI 검증 실패
- Redirect URI 화이트리스트 미설정 또는 와일드카드 허용
- 부분 문자열 매칭으로
evil.com/yourapp같은 변형 허용 - 오픈 리다이렉트와 결합한 토큰 탈취
- 콜백 URL을 동적으로 사용자 입력에서 받아 처리하는 경우 즉시 취약
3.4. Authorization Code 재사용
Authorization Code는 단 1회만 사용 가능해야 하는데 이걸 검증하지 않으면 가로챈 코드로 여러 번 토큰을 발급받을 수 있습니다.
3.5. 카카오·네이버 OAuth의 추가 함정
카카오·네이버는 OAuth 2.0은 따르지만 OIDC 표준을 완전히 준수하지 않습니다. 카카오는 id_token 발급이 비표준이고 네이버는 userinfo 응답 필드가 다릅니다. 직접 구현 시 이메일 검증 누락으로 동명이인 사용자가 다른 사람 계정에 로그인되는 사고가 흔합니다.
4. 무차별 대입과 자동화 공격
비밀번호와 토큰 자체가 안전해도 운영 단계에서 자동화 공격을 막지 못하면 의미가 없습니다.
4.1. 크리덴셜 스터핑
다른 사이트에서 유출된 이메일·비밀번호 조합을 너희 서비스에 그대로 시도하는 공격입니다. 사용자의 65%가 여러 사이트에서 같은 비밀번호를 재사용하기 때문에 성공률이 의외로 높습니다.
2024년 큰 피해 사례를 보면 한국고용정보원·한국장학재단 크리덴셜 스터핑 공격, 스노우플레이크 고객사 다수가 2024년 6월 크리덴셜 스터핑으로 수억 건 데이터 탈취(AT&T, Ticketmaster 등), 옥타가 2024년 4월 크리덴셜 스터핑 공격 급증 경고문 발표 등이 있습니다.
자체 구현으로 이걸 막으려면 IP·디바이스·행동 패턴 분석, 봇 탐지, 누출 비밀번호 DB 대조까지 다 만들어야 하는데 사실상 불가능합니다.
4.2. 무차별 대입
- rate limiting 미적용: 분당 수천 번 로그인 시도 가능
- 계정 잠금 미구현: 무한 시도 허용
- CAPTCHA 미적용: 봇이 사람처럼 시도
- 로그 모니터링 부재: 공격당하고 있는지도 모름
- 점진적 지연(progressive delay) 미적용: 실패해도 비용이 없음
4.3. SQL 인젝션을 통한 인증 우회
2024년 7월 한국 웹 공격 중 SQL 인젝션이 42.23%로 가장 큰 비중을 차지했습니다. 로그인 폼에 ' OR '1'='1 같은 입력 한 줄로 인증을 우회하는 고전적 공격이 아직도 통합니다. ORM을 안 쓰거나 prepared statement를 빼먹은 자체 구현이 가장 잘 당합니다.
5. MFA·패스키 직접 구현의 불가능성
다중 인증과 패스키는 이제 보안 기본기인데 직접 구현은 사실상 불가능에 가깝습니다.
5.1. TOTP
구글 Authenticator 같은 앱과 연동하는 6자리 코드. RFC 6238 표준을 정확히 구현해야 하고 시계 동기화 오차·재사용 방지·백업 코드 관리까지 필요합니다.
5.2. SMS OTP
SMS 발송 자체에 통신사 계약·문자 게이트웨이·국제 발송·비용 관리가 필요합니다. 그리고 SMS는 SIM 스와핑·SS7 공격에 취약해서 단독으로는 권장되지 않는 인증 수단입니다.
5.3. WebAuthn / 패스키
생체인증·하드웨어 키 기반 인증. FIDO2·CTAP·WebAuthn 표준을 모두 정확히 구현해야 하고 디바이스별 호환성, 동기화된 패스키(Apple iCloud·Google Password Manager)와 디바이스 바운드 패스키의 구분 처리 등 신경 쓸 게 산더미입니다. 자체 구현 사례를 거의 찾아볼 수 없는 이유가 여기 있습니다.
6. 한국 개인정보보호법상 책임
기술적 취약점보다 더 무서운 게 법적 책임입니다.
6.1. 과징금 수준
2023년 개정 개인정보보호법은 위반 행위 관련 매출의 최대 3%까지 과징금을 부과할 수 있습니다. 2025년 국회에서는 이를 최대 10%까지 상향하는 개정안이 논의 중입니다. 매출 기준이라 적자 회사도 과징금을 피할 수 없습니다.
6.2. 실제 부과 사례
| 사업자 | 사유 | 처분 |
|---|---|---|
| 듀오정보 | 약 42만 명 회원정보 유출 | 과징금 약 12억 원 |
| LG U+ | 약 30만 명 정보 유출 | 과징금 68억 원 |
| 카카오 | 6만여 명 정보 유출 | 과징금 151억 원 |
| 골프존 | 221만 명 정보 유출 | 과징금 약 75억 원 |
인디 개발자나 1인 사업자도 동일한 법 적용 대상입니다. 매출이 적으면 과징금 절대액은 적지만 형사처벌(5년 이하 징역)·민사 손해배상·신용 회복 비용은 매출과 무관하게 발생합니다.
6.3. 통지·신고 의무
- 정보주체 통지: 유출 인지 후 72시간 이내
- 개인정보보호위원회 신고: 1,000명 이상 유출 시 의무
- 언론 공표: 사회적 파장 큰 경우
- 통지·신고 지연 시 별도 과태료 3,000만 원 이하
6.4. 14세 미만 처리 제한
만 14세 미만 아동의 개인정보는 법정대리인 동의 없이 처리하면 즉시 위법입니다. 자체 회원가입 폼에서 연령 검증·법정대리인 동의 절차를 제대로 구현하는 건 매우 어렵습니다.
6.5. 국외이전
외국 서비스에 데이터를 보내려면 정보주체 동의 또는 적정성 결정 등 법적 근거가 필요합니다. 자체 운영이라도 AWS·Cloudflare·Sentry 같은 외국 인프라를 쓰면 다 해당됩니다.
7. 운영 비용과 인력 부담
보안과 법률을 다 해결해도 운영 단계에서 무너지는 경우가 많습니다.
7.1. 24시간 모니터링
인증 시스템은 새벽 3시에 공격이 들어옵니다. 1인 개발자가 24시간 모니터링·즉시 대응을 할 수 있을까요? 전문 SaaS는 SRE 팀이 24/7 대응합니다.
7.2. CVE 패치 속도
인증 관련 라이브러리에 CVE가 공개되면 수 시간 안에 공격 코드가 풀립니다. 휴가 갔다 와서 패치하면 이미 늦습니다. 매니지드 서비스는 자동으로 패치되고 사용자는 알 필요도 없습니다.
7.3. 사고 대응 절차
사고가 터지면 포렌식·통지·신고·언론 대응·집단소송 방어를 동시에 진행해야 합니다. 이걸 혼자 감당할 수 있을까요? 전문 서비스를 쓰면 위탁 업체의 보안 보고서·SOC 2 인증·DPA가 법적 방어선이 됩니다.
7.4. 비용 비교
| 항목 | 자체 구현 | 매니지드 서비스 |
|---|---|---|
| 초기 개발 | 1~3개월 풀타임 | 5분 |
| 보안 컨설팅 | 연 1,000만 원~ | 포함 |
| SOC 2 인증 | 자체 취득 시 5천만 원~ | 포함 |
| 침투 테스트 | 회당 500만 원~ | 포함 |
| 24시간 모니터링 | 불가능 | 포함 |
| 월 운영비 | 인건비 | $0~25 |
8. 30가지 위험 요약
위에서 다룬 내용을 30개 항목으로 압축하면 다음과 같습니다.
- MD5·SHA1·SHA256 등 부적합 해시 사용
- bcrypt work factor 12 미만 설정
- 사용자별 솔트 없이 해싱
- 페퍼를 코드에 하드코딩
- 비밀번호 평문 로그 기록
- 시크릿 키를 깃허브에 커밋
- JWT alg:none 우회 미차단
- RS256↔HS256 알고리즘 혼동 공격
- JWT를 localStorage에 저장
- JWT 취소 불가능 구조
- 세션 ID URL 노출
- Secure·HttpOnly·SameSite 플래그 누락
- 로그인 후 세션 ID 재발급 누락(세션 고정)
- OAuth state 파라미터 누락(CSRF)
- PKCE 미구현
- Redirect URI 화이트리스트 부재
- Authorization Code 재사용 허용
- SQL 인젝션 인증 우회
- rate limiting·계정 잠금 미구현
- CAPTCHA·봇 차단 부재
- 누출 비밀번호 DB 미대조
- 이메일 검증·비밀번호 재설정 토큰 만료 미적용
- MFA·패스키 직접 구현 실패
- HTTPS 강제 미적용
- 로그 모니터링·이상 탐지 부재
- CVE 패치 지연
- 14세 미만 동의 절차 부재
- 국외이전 동의 누락
- 유출 통지·신고 절차 미숙지
- 24시간 사고 대응 불가능
9. 대안 인증 서비스 비교
위 위험을 모두 떠넘길 수 있는 매니지드 서비스를 정리합니다.
| 서비스 | 무료 한도 | 강점 | 한국 소셜 |
|---|---|---|---|
| Clerk | 50,000 MRU | 임베디드 UI, Astro·Next.js 5분 통합 | Custom OAuth 가능 |
| WorkOS AuthKit | 1,000,000 MAU | MFA·패스키 무료, OpenAI·Anthropic 채택 | 사실상 불가 |
| Supabase Auth | 50,000 MAU | 카카오·네이버 공식 지원, DB 통합 | 공식 지원 |
| Firebase Auth | 무제한(이메일) | 구글 생태계, 무료 폭 넓음 | Custom 필요 |
| Auth0 | 7,500 MAU | 엔터프라이즈 표준, 기능 다양 | Custom 필요 |
| Logto | 5,000 MAU | 오픈소스 옵션, 카카오 지원 | 공식 지원 |
9.1. 어떤 상황에 어느 쪽
- 한국 인디 서비스 + 카카오 로그인 필수: Supabase Auth 또는 Logto
- Astro·Remix·Expo 스택: Clerk(공식 SDK 유일)
- B2B SaaS, 100만 사용자 이상: WorkOS AuthKit
- 구글 생태계, 모바일 앱: Firebase Auth
- 엔터프라이즈 고객, 예산 충분: Auth0
핵심 포인트: 인증을 직접 만들지 마라. 전문 SaaS에 위탁하면 SOC 2·GDPR·ISO 27001 인증, 24/7 모니터링, CVE 자동 패치, 사고 시 법적 방어선까지 월 0~25달러에 빌리는 셈입니다. 압도적 가성비입니다.
10. 마무리
위에서 살펴본 자체 인증 구현 위험성의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 비밀번호 해싱부터 잘못하기 쉽다. MD5·SHA1·SHA256은 부적합, bcrypt·Argon2id 정확한 파라미터 필수
- 세션·JWT 관리에서 가장 많은 사고가 터진다. localStorage 저장, 시크릿 노출, 알고리즘 혼동 공격
- OAuth는 state·PKCE·Redirect URI 검증 중 하나만 빼도 즉시 취약
- 크리덴셜 스터핑·SQL 인젝션·무차별 대입 자동화 공격은 자체 구현으로 막기 거의 불가능
- MFA·패스키는 표준이 너무 복잡해 직접 구현이 사실상 불가능
- 한국 개인정보보호법은 매출 3%(개정 시 10%) 과징금, 14세 미만 동의·국외이전 동의·유출 통지 의무 모두 위반 시 형사처벌까지
- 매니지드 서비스(Clerk·WorkOS·Supabase Auth·Firebase Auth·Auth0)는 월 0~25달러로 위 위험을 전부 떠넘길 수 있다
신규 프로젝트를 시작한다면 첫날부터 매니지드 인증 서비스에 위탁하세요. 한국 소셜 로그인이 필요하면 Supabase Auth, Astro·Next.js 스택이면 Clerk, 대규모 글로벌·B2B면 WorkOS가 현실적 선택입니다. 본업 기능에 집중하고 인증은 전문가에게 맡기는 것이 인디 개발자가 살아남는 유일한 길입니다.
자주 묻는 질문
- 그냥 NextAuth(Auth.js) 같은 오픈소스 라이브러리 쓰면 안 되나요?
라이브러리는 도구일 뿐이고 운영 책임은 본인에게 그대로 남습니다. NextAuth는 2023년 CVE-2023-48309(JWT 인증 우회), 2025년 CVE-2025-29927(Next.js 미들웨어 인증 우회) 등 심각한 취약점이 여러 번 공개됐고, 그때마다 직접 패치하고 토큰을 회수해야 했습니다. 또한 DB 설계·세션 저장소·시크릿 키 관리·MFA·패스키·봇 차단·로그 모니터링은 라이브러리가 책임지지 않습니다. 매니지드 서비스는 이런 CVE가 나와도 자동 패치되고 사용자는 알 필요도 없습니다.
- 매출이 거의 없는 1인 인디 서비스도 개인정보보호법 적용 대상인가요?
예, 매출과 무관하게 개인정보를 처리하면 전부 적용 대상입니다. 매출이 0이어도 형사처벌(5년 이하 징역, 5천만 원 이하 벌금)과 민사 손해배상 책임은 그대로 부과됩니다. 과징금은 매출의 최대 3%(개정안 통과 시 10%)라 절대액은 작을 수 있지만, 1,000명 이상 유출 시 개인정보보호위원회 신고 의무, 정보주체 통지 의무, 14세 미만 처리 시 법정대리인 동의 의무는 동일하게 적용됩니다. 신용카드·실명·주민번호를 다루면 정보통신망법·신용정보법까지 추가됩니다.
- 비밀번호를 bcrypt로 해싱하면 안전한 거 아닌가요?
bcrypt 자체는 좋은 선택이지만 work factor(cost)를 너무 낮게 설정하면 무의미합니다. 2026년 기준 최소 12 이상이 권장이고, 서버 성능에 따라 13~14까지 올려야 합니다. 또한 사용자별 랜덤 솔트가 있어야 하고, 페퍼(서버 측 비밀값)를 코드에 하드코딩하지 않아야 합니다. bcrypt는 72바이트 입력 제한이 있어서 긴 비밀번호가 잘리는 문제도 있습니다. OWASP는 현재 Argon2id를 1순위로 권장합니다. 이런 디테일을 직접 관리하는 것보다 전문 서비스에 맡기는 게 안전합니다.
- JWT를 localStorage에 저장하면 안 되는 이유가 뭔가요?
localStorage는 자바스크립트로 자유롭게 읽을 수 있어서 XSS 취약점이 하나만 있어도 모든 토큰이 통째로 탈취됩니다. 광고 스크립트·외부 위젯·서드파티 라이브러리에 XSS가 들어오면 즉시 끝입니다. 안전한 방식은 HttpOnly·Secure·SameSite=Strict 플래그를 단 쿠키에 저장하는 것입니다. HttpOnly 쿠키는 자바스크립트로 읽을 수 없어서 XSS로 탈취가 불가능합니다. 다만 CSRF 방어를 위해 SameSite 또는 별도 CSRF 토큰이 필요합니다. 자체 구현 시 이 모든 플래그를 정확히 설정하는 게 의외로 어렵습니다.
- 한국 서비스에서 카카오·네이버 로그인이 꼭 필요한데 어떻게 하나요?
한국 소셜 로그인을 공식 지원하는 서비스는 Supabase Auth와 Logto 정도입니다. 두 서비스 모두 카카오·네이버 커넥터를 기본 제공하고 한국어 문서도 있습니다. Clerk·WorkOS·Firebase·Auth0는 Custom OAuth/OIDC로 직접 연결해야 하는데, 그중 Clerk이 한국 개발자 커뮤니티 자료가 가장 많아 현실적입니다. 카카오는 OIDC id_token이 비표준이고 네이버는 userinfo 응답 필드가 달라서 글로벌 서비스들이 공식 지원하지 않습니다. 한국 소셜이 필수면 Supabase Auth로 시작하는 것이 가장 빠릅니다.
- MFA(다중 인증)를 직접 구현하는 게 정말 어렵나요?
RFC 6238(TOTP) 자체는 30줄 정도로 구현할 수 있어 보이지만, 실제 운영에서는 시계 동기화 오차 처리, 백업 코드 발급·검증, 코드 재사용 방지, 시도 횟수 제한, 디바이스 등록·해제, 분실 시 복구 절차까지 모두 필요합니다. SMS OTP는 통신사 계약·문자 게이트웨이·비용 관리가 필요하고 SIM 스와핑 공격에 취약합니다. WebAuthn 패스키는 FIDO2·CTAP·WebAuthn 세 가지 표준을 정확히 구현해야 하고, 동기화 패스키와 디바이스 바운드 패스키 구분 처리까지 필요합니다. WorkOS AuthKit은 이걸 전부 무료로 제공합니다.
- 외부 인증 서비스를 쓰면 한국 개인정보보호법상 문제가 없나요?
오히려 권장되는 구조입니다. SOC 2·ISO 27001·GDPR 인증을 가진 전문 인증 서비스에 위탁하면, 사고 발생 시 "법적으로 적절한 보호 조치를 했다"는 방어선이 됩니다. 다만 미국 본사 서비스(Clerk·WorkOS·Auth0·Firebase)는 개인정보처리방침에 "○○ Inc.(미국)에 인증 업무 위탁"을 명시하고, 회원가입 시 국외이전 동의를 받아야 합니다. EU 사용자가 있다면 EU 리전 옵션을 활용하고 DPA(Data Processing Agreement)를 체결하면 됩니다. Supabase는 한국 리전 선택지가 있어 국외이전 이슈가 줄어듭니다.
- Clerk과 WorkOS 중 인디 개발자에게는 어느 쪽을 추천하나요?
사용자 5만 명 미만이면 Clerk이 더 적합합니다. Astro·Next.js·Remix·Expo 등 다양한 프레임워크 공식 SDK를 제공하고, 임베디드 UI 컴포넌트라 통합이 5분이면 끝납니다. 한국 소셜 로그인을 Custom OAuth로 붙이는 자료도 WorkOS보다 많습니다. 다만 MFA·패스키가 필요하면 Pro 플랜($20/월)부터 가능합니다. 사용자 100만 명 이상 글로벌 SaaS나 B2B 엔터프라이즈를 노린다면 WorkOS가 비용·기능 모두 우위입니다. WorkOS는 100만 MAU까지 무료에 MFA·패스키도 무료 포함입니다.