어떤 IdP(인증 제공자)를 선택할 것인가: 엔지니어링 팀의 평가 프레임워크

대부분의 인증 제공자(Identity Provider) 비교 글은 IdP 회사가 직접 작성합니다. 충격적이지요? 자신들의 제품에 있는 기능을 나열하고, 없는 건 빼고, "객관적인 가이드"라고 부릅니다.

이 글은 다릅니다.

우리는 실제로 엔터프라이즈에서 벤더에게 보내는 평가 요청서와 스프레드시트, RFP 문서를 수십 건 검토했습니다. 패턴은 명확합니다: 엔지니어링 팀은 정말 중요한 기준을 과소평가하고, 덜 중요한 기준을 과대평가하는 경우가 반복됩니다.

결과는? 팀은 데모 보고 IdP를 결정했다가, 6개월 뒤 마이그레이션이 악몽임을 깨닫고 평가를 다시 시작합니다.

아래는 우리가 예전에 받았으면 했던 평가 프레임워크입니다. B2B SaaS 회사의 엔지니어링 조직을 위한, 즉 사내 직원용 SSO가 아닌 제품에 인증을 넣는 팀을 위한 가이드입니다.

빠른 답: IdP 선택을 좌우하는 결정적 요소#

바쁜 사람을 위해 핵심만 요약합니다:

1. 프로토콜 심층성(Protocol depth)은 기능 갯수보다 중요합니다. "OAuth2 지원"만으로는 의미 없습니다. 어떤 grant type을 지원하는가? 토큰 클레임을 커스터마이즈할 수 있는가? OIDC 제공자가 될 수 있는가?
2. 마이그레이션 가능성은 가장 과소평가된 기준입니다. 기존 유저를 비밀번호 재설정 없이 옮길 수 없다면, 아무리 모든 게 좋아도 사용할 수 없습니다.
3. 멀티테넌시는 네이티브(내장형)여야 합니다. 조직 모델과 테넌트별 설정에 우회가 필요하면, 평생 시스템과 싸우게 됩니다.
4. AI-준비성은 미래 얘기가 아니라 12개월 내에 필요한 자격입니다. 토큰 익스체인지, 에이전트 아이덴티티, 위임된 scope 등. IdP가 이걸 지원하지 않으면 내년에 다시 평가하게 됩니다.

이 가이드의 나머지 부분에서는 각 평가 항목별로 구체적인 질문과 레드플래그(경고 신호)를 제시합니다.

이 가이드의 대상자(그리고 대상이 아닌 사람)#

이런 경우에 해당되면 읽으세요:

• 당신이 50~300명 규모의 B2B SaaS 회사 CTO, 엔지니어링 VP, 혹은 플랫폼 아키텍트라면
• 이미 10만 명 이상의 유저가 있고, 무리한 이관(마이그레이션)이 치명적이라면
• 엔터프라이즈 고객 수용을 위해 SSO, 조직 모델, 감사 로그가 필요한 상황이라면
• 벤더가 제공한 프레임워크가 아닌, 기술적인 평가 보고서를 직접 작성해야 한다면

이런 경우에는 읽지 않아도 됩니다:

• 사내 직원용 SSO(워크포스 IAM)가 필요하다면 — 완전히 다른 구매 결정입니다
• 500명 남짓 사용자만 있고 엔터프라이즈 고객이 없다면 — SDK 좋은 걸 써서 빨리 진행하세요
• 신원 인증(KYC/KYB)이 필요하다면 — 완전히 별개의 영역입니다

항목 1: 프로토콜 기능 — 단순 "OAuth2 지원"을 넘어서#

시장에서 만나는 모든 IdP는 "OAuth2와 OIDC 지원"을 외칩니다. 당연한 기본입니다. 진짜 중요한 건 깊이(심층성)입니다.

그랜트 타입(Grant types): 무엇을 지원하는가#

필수:

• Authorization Code + PKCE — 브라우저와 모바일 앱에서 유일하게 써야 할 흐름입니다. Implicit flow 추천하는 벤더는 탈락. PKCE는 선택이 아니라 보안 필수입니다.
• Client Credentials — 서비스-대-서비스 인증에 필요합니다. 백엔드끼리 유저 없이 통신 가능합니다.
• Refresh Token — 당연하지만 실제 구현은 천차만별. 회전/만료/부분 회수 등 커스터마이즈가 되는가?

점점 더 중요해지는 기능:

• Token Exchange (RFC 8693) — AI 에이전트 인증, 사용자 가장, 위임 등에 필수입니다. 없으면 로드맵이라도 있는지, 없다면 레드플래그.

OIDC 제공자(Provider) 기능#

많은 팀이 빠뜨리는 질문: 이 IdP를 OIDC 제공자로 사용할 수 있나? (단순 소비자 아닌)

이유: SaaS가 성장하면 파트너와 고객이 당신의 IdP로 타 시스템에 로그인하길 원할 수 있습니다. 토큰 발행, 동의 관리, 3자 앱 등록 필요. 단순히 외부 IdP만 소비할 수 있고 제공자는 안 되면, 앞으로 확장 못합니다.

질문 예시:

• 화이트라벨 가능한 OpenID Discovery 엔드포인트 제공합니까?
• 신뢰수준별로 1자, 3자 앱을 각각 등록할 수 있나요?
• 1자 앱은 동의 스킵, 3자 앱만 동의 화면 강제 가능한가요?

JWT 커스터마이즈#

토큰은 IdP와 서비스 사이의 계약입니다. 커스터마이즈 불가할 경우, 모든 하위 서비스가 유저의 권한 확인을 위해 추가 API 호출을 해야 합니다.

질문:

• 엑세스 토큰/ID 토큰에 커스텀 클레임 추가 가능합니까?
• 토큰에 어떤 테넌트(조직)인지 바로 포함시킬 수 있습니까?
• 앱의 퍼미션 모델에 맞춰 커스텀 scope 정의 가능한가요?
• 클레임이 토큰 발급 시 계산되는가, 아니면 웹훅이나 스크립트로 동적으로 반영 가능한가요?

{ "org_id": "org_123", "role": "admin", "auth_level": 2 }와 같은 토큰이면 미들웨어 한 줄로 권한 판별이 끝나지만, { "sub": "user_456" }만 있으면 모든 서비스가 IdP/api에 추가 조회해야 합니다. 대규모에선 2ms 대 200ms 수준의 차이입니다.

항목 2: 인증 플로우 — 사소해 보여도 치명적인 디테일#

모든 IdP가 이메일/비밀번호, 소셜 로그인을 지원합니다. 그래서 후보군은 아직도 모두입니다.

차별점은 대부분 데모로 안 나오는 디테일에 있습니다.

가입(회원가입) 플로우#

• 가입 직후 자동 로그인: 가입하고 바로 로그인 되나요? 아니면 다시 로그인 창이 나옵니까? 재로그인 강제는 전환율 저하의 주범. 생각보다 많은 IdP가 이걸 놓칩니다.
• 커스텀 가입 필드: 가입 단계에서 역할, 회사명, 용도 등을 받게 할 수 있나요? 아니면 완료 후 따로 온보딩 플로우 필요합니까?
• 점진적 프로파일링: 모든 정보 즉시 요구 대신, 여러 번에 걸쳐 순차 수집 가능한가요?

로그인 플로우#

• login_hint 지원: 마케팅 이메일 링크 클릭 시, 이메일 주소 자동입력 지원? 사소해 보여도 전환율 40% vs 60% 차이입니다.
• 조직별 인증 정책: 조직A는 SAML SSO, 조직B는 이메일/비밀번호, 엔터프라이즈만 MFA 강제 등. 테넌트별 auth policy가 코드수정 없이 설정만으로 바뀌나요? 그렇지 않다면, 고객 온보딩 때마다 개발 리소스 낭비됩니다.
• 브랜딩 커스터마이즈: 테넌트별 로그인 경험 커스터마이즈 지원? 단순 로고/색상 말고 CSS 전체, 커스텀 도메인, 화이트라벨 메일까지. "호스팅 UI vs. 커스텀 UI"는 선택이어야 합니다.

체크리스트에 잘 안 나오는 것들#

• 사일런트 인증: 토큰 만료 시, 앱이 유저 리다이렉트 없이 자동 갱신(사일런트 로그인) 가능한가요? 리프레시 토큰도 만료면 fallback(sliding session, iframe 등)이 있나요?
• 계정 연결(Account linking): 구글로 가입 후 이메일로 로그인 시, 한 계정인가요? 두 개인가요? IdP의 계정 병합(merge) 정책이 명확한가요? 이 부분이 엉키면 유령 중복계정은 무한히 생깁니다.
• 패스워드리스 옵션: 매직 링크, 패스키, WebAuthn 등. 지금 필요하지 않아 보여도, 6개월 내 기업고객이 반드시 요구합니다.

항목 3: 세션/토큰 관리 — 수면 아래의 심연#

데모는 이 부분을 거의 건너뜁니다. 세션/토큰 관리는 문제 생기기 전엔 '지루해' 보이지만, 한번 터지면 전체 유저 로그아웃 대란입니다.

쿠키 보안#

화려함은 없지만 치명적으로 중요합니다.

• HttpOnly, Secure, SameSite 모두 올바로 설정되어야 합니다. 세션 쿠키에 HttpOnly 미설정이면 실전 투입 불가입니다.
• 서브도메인 간 세션: 예를 들어 app.yourproduct.com과 api.yourproduct.com에서 쿠키 공유 가능한가요? 구현 방식은?
• 서드파티 쿠키 종식: 크롬 등에서 지원 중단 중. IdP가 서드파티 쿠키 없이 교차 도메인 인증 지원합니까? "준비 중"이면 불충분합니다.

장기 로그인(현재 유지)#

유저는 수 주, 수개월간 로그인 유지 원합니다. 180일 세션은 30분 세션과 보안 측면이 전혀 다릅니다.

질문:

• 세션 유효기간과 토큰 유효기간을 별개로 설정 가능합니까?
• "로그인 유지"(remember me) 옵션 등, 세션 연장과 토큰 짧은 유효기간을 동시에 실현 가능한가요?
• 민감 작업만 MFA 등 재인증 강제 가능(동시 세션 유지)한가요?

리프레시 토큰 보안#

• 토큰 회전: 리프레시 토큰 사용 시마다 자동 갱신되나요? (필수)
• 암호화 저장: 리프레시 토큰 저장소 암호화 되어 있나요?
• 부분 세션 종료: 단일 기기만 세션 종료(토큰 회수) 가능합니까?
• 유효기간 개별설정: 앱별로 리프레시 토큰 유효기간 각각 설정 가능한가요, 전역 세팅인가요?

항목 4: 권한 모델 — RBAC 그 이상#

RBAC(역할 기반 접근 제어)은 최소 기준입니다. RBAC도 없는 IdP는 평가할 의미가 없습니다. 하지만 B2B SaaS 환경에선 RBAC만으로 부족합니다.

조직 단위 권한#

유저는 "조직"에 소속되고, 조직별 권한이 플랫폼/글로벌 수준과 다릅니다.

예: 한 유저가 조직A에선 관리자, B에선 뷰어. 같은 유저라도 역할 맥락 다름. 이런 모델이 내장되지 않으면, 결국 별도의 권한 시스템을 직접 구축해야 하고, '두 개의 소스 오브 트루스'가 탄생합니다.

질문:

• 조직 레벨에서 역할 부여 가능한가?
• 한 명 유저가 여러 조직에서 다른 역할 가능?
• 현 조직 컨텍스트가 토큰에 직접 담겨서 API가 판별 가능합니까?

다단계 권한(auth_level)#

금융/헬스케어 등 민감 서비스는 모든 인증 세션이 같은 수준이 아닙니다.

대시보드 열람엔 세션 쿠키만으로 충분. 송금 등 고위험 작업은 MFA 등 별도 재인증 필요.

즉 auth_level(인증 레벨)을 토큰에서 1급 시민으로 지원해야 합니다.

질문:

• 토큰에 auth_level 클레임 추가 가능한가요?
• 전체 재로그인 없이 앱에서 step-up 인증 트리거 가능?
• auth_level의 만료는 세션 지속과 분리관리 가능?

IdP가 이걸 지원하지 않으면, 구현을 직접 해야 하고, 그게 IdP를 사는 이유를 무색하게 만듭니다.

토큰 기반 권한 판별#

이상적 모델: API 미들웨어가 토큰만 읽어서 조직/역할/auth_level까지 즉시 판별.

여러 IdP는: 토큰엔 유저만 식별되고, 권한은 별도 API를 조회해야 알 수 있음.

별도 호출은 지연, 의존성, 실패 위험까지 낳습니다. 초당 1,000회 요청이면 네트워크 핫스팟이 됩니다.

항목 5: 마이그레이션 — 모든 걸 결정하는 기준#

아무도 말하지 않는 통계: IdP 평가가 실패하는 주 원인은, 새 IdP가 '좋지 않아서'가 아니라, 기존 유저 마이그레이션 방법을 못 찾아서입니다.

10만명 이상 유저가 있으면, 마이그레이션이 프로젝트 전부입니다.

3가지 마이그레이션 전략(IdP 필수 지원)#

1. 기존 해시 비밀번호 대량 이관

기존 bcrypt, argon2 등으로 해싱된 비밀번호를 IdP에 직접 이관, 검증 가능?

YES: 유저는 변화 인식 없이 로그인. 베스트 케이스.

NO: 전체 유저 비밀번호 재설정 메일 발송. 이 과정에서 30~50% 유저 이탈. 실제 있었던 일입니다.

2. 점진적(게으른) 이관

모두 한 번에 옮기는 대신, 로그인 시마다 1명씩 이전. 최초 로그인은 구시스템서 비밀번호 검증/신규 IdP에 계정 생성, 그 후부턴 새 IdP 이용.

이런 방식은:

• 레거시 시스템과 연동되는 커스텀 인증 훅
• 로그인 시 실시간 유저 생성 지원
• 이관된 유저와 미이관별로 구분 추적 가능해야 함

3. 듀얼라이트(병렬 운용)

구시스템/신시스템 동시 운용. 쓰기는 양쪽, 읽기는 점진적 이전. 롤백 가능하지만 운영 복잡성 추가.

마이그레이션 경고 신호#

• "CSV 가져오기 지원" — 유저 프로필만 대량 등록이지 비밀번호는 아님. 비밀번호 재설정 필요
• "마이그레이션 가이드 있음" — "모든 유저가 새 비밀번호 설정 필요"라면 30~50% 이탈 시나리오. 꼼꼼히 확인하세요
• 비밀번호 해시 호환성 언급 없음 — 벤더가 해시 이관 얘기조차 안 했다면, 대규모 마이그레이션 경험 없는 업체임

중요한 체크 포인트#

• 어떤 비밀번호 해시 알고리즘(bcrypt, argon2, scrypt, PBKDF2, custom) 지원?
• 점진적 이관(최초 로그인 시 계정 이동) 가능?
• 이관 진행률 추적 — 몇 퍼센트 이관됐는지 집계 가능?
• 마이그레이션 실패 시 롤백 방법은?
• 이관 중 세션 유지 지원? (유저 강제 로그아웃 방지)

명쾌히 답하지 못하면, 실제 경험이 없는 벤더입니다. 넘기세요.

항목 6: 멀티테넌시 — 네이티브 vs. 붙이기식#

B2B SaaS는 기본이 멀티테넌시. 고객(조직)별 유저 다수, 역할/정책 다수. IdP가 이를 네이티브로 이해해야 합니다.

"네이티브 멀티테넌시"란#

• 조직이 1급 데이터 모델: 단순 유저 프로필의 커스텀 필드가 아니라, 독립적인 조직 ID/설정/회원 목록까지.
• 테넌트별 인증 정책: 조직A는 자사 IdP로 SAML SSO, 조직B는 이메일/비밀번호+MFA, C는 Google Workspace 연동. 코딩 아닌 UI 혹은 API로 설정 가능해야 함.
• 조직 초대/멤버 관리: 각 조직 관리자가 유저 초대/역할 부여/삭제를 UI로 제어. 초대 메일, 이메일 인증, 역할 지정까지 IdP에서 제공.
• 조직 컨텍스트 내장된 토큰: 조직 선택 시, 토큰에 org 정보 내장. API가 정확히 어떤 조직 작업인지 곧장 알 수 있음.

"커스텀 메타데이터" 우회책#

조직 모델이 없는 IdP는 user.app_metadata.org_id 과 같은 형식의 커스텀 메타데이터를 쓰게 합니다.

이런 방식은 대규모에서 무너집니다:

• 다중 조직 소속 유저 = 복잡한 배열/구조체 메타데이터 처리
• 초대/멤버십 관리 플로우 내장 불가
• 조직별 인증 정책 미지원
• 조직 컨텍스트가 토큰에 내장 안 됨 — 우회 신호 필요
• 감사 로그도 조직 몰라서 무의미

"우리 메타데이터로 조직 관리 하세요"는 데이터베이스에서 관계형 테이블을 JSON 컬럼에 저장하라는 말과 같습니다. 잘 될 때까지만 됩니다.

질문 가이드#

• 조직 모델이 네이티브입니까, 그냥 프로필 필드에 얹은 겁니까?
• 한 유저가 여러 조직 동시 소속 가능합니까?
• 조직별 인증 요건 개별 설정 가능합니까?
• 조직단위 역할/권한 모델이 네이티브로 지원됩니까?
• 조직 관리자가 셀프 서비스 UI로 멤버 관리 가능합니까?
• 토큰에 조직 정보 포함됩니까?

항목 7: AI-준비성 — 아직 아무도 안 묻는 기준#

12개월 전만 해도 "AI 에이전트 인증"은 평가 항목에 없었습니다. 오늘날, AI 기능(코파일럿/AI 워크플로우/에이전트) 도입을 계획한다면, IdP가 새로운 타입의 신원: 에이전트(비인간 주체)를 다룰 수 있어야 합니다.

에이전트가 기존 모델을 깨는 이유#

전통적 인증은 유저/애플리케이션 2자 구도(OAuth2 설계 근간).

AI 에이전트는 3번째 주체: 비인간, 특정 유저 대리, 제한된 권한, 별도 감사추적 필요.

• 에이전트는 유저가 아님 — 비번/세션 없음
• 기계-기계 서비스도 아님 — 특정 유저의 대리
• 제한적, 시간제한된 권한 필요 — 완전 대리X

IdP 지원 필요 기능#

Token Exchange(RFC 8693): 에이전트가 자체 자격+유저 동의 제시, 제한 범위 토큰을 발급. 토큰 구조: 누구(유저), 누구(에이전트), 범위/만료 등.

에이전트별 client type: 에이전트를 별도 OAuth2 클라이언트(client_id)로 모델링. (API 키/유저 토큰 꼼수X)

위임 범위 관리: 유저가 에이전트에 select한 권한만 임시로 부여가능(읽기전용 등).

감사 구분: "유저 직접 vs. 에이전트 대리" 로그 구분 불가하면, SOC2 등 감사를 통과할 수 없습니다.

MCP(Model Context Protocol) 호환성#

MCP는 AI 에이전트가 외부 도구/서비스와 상호작용하는 표준으로 자리잡는 중입니다. IdP가 OAuth 기반 MCP 인증 서버를 지원하면, 에이전트가 API 키/비밀키 없이 표준 인증 경로로 통합 가능.

핵심 질문#

• OAuth2 Token Exchange 지원합니까?
• 에이전트 별도 client type모델링 가능?
• 토큰에 위임 정보(누가 유임했는지, 범위)는 실릴수 있습니까?
• 감사 로그에서 에이전트/사람 구분됩니까?
• MCP서버/agent-to-tool OAuth 연동 지원합니까?

벤더에게 이 질문이 낯설다면, 2020년 사고방식을 고수하고 있는 벤더입니다. 당신은 2026년을 준비하는 중입니다.

항목 8: 비기능 요구사항 — 밤잠 설치게 하는 요소#

기능만 팔게 되어있지만, 운영이 재계약/교체의 진짜 결정자입니다.

성능#

• 인증 처리량: 피크 시 초당 100+ 인증요청, 1,000+ 도 가능합니까?
• 토큰 검증 지연: JWT를 로컬 검증한다면 1ms 미만. 반드시 introspection 호출 요구될 경우 P99 지연 조회 필요.
• 확장 한계: MAU 최대치는? 실제 운영 사례/트랙레코드 있는가?

컴플라이언스#

• SOC2 Type II: I는 한 시점, II는 일정 기간 모니터링 통과. Type I만 있다면 II 획득 시점 확인 필요.
• 감사 로그: 모든 인증/권한변경/관리자 작업 내역 저장. SIEM 내보내기, 불변 저장 가능?
• 데이터 레지던시: 유저 데이터 저장 리전을 고를 수 있나요?(EU 등 필수)

신뢰성#

• 가동률 SLA: 99.9%는 연간 8.7시간 다운, 99.99%는 52분. 인증 게이트웨이인 만큼 차이가 큽니다.
• 장애 대비: IdP 장애 시 fallback/다중리전 대책 있나요?
• 과거 장애 이력: 약속이 아니라 실제 상태 페이지 기록을 보세요.

데이터 이식성#

• 유저 데이터 내보내기: 메타데이터/조직 소속/역할 데이터까지 내보내기 지원? 포맷은?
• 표준 준수: OIDC, SCIM 등 표준 사용 — 타 IdP 마이그레이션 용이?
• 락인 신호 점검: 독점 API, 특수 프로토콜, 비표준 토큰 형식 등이 많을수록 떠나기 어려움.

평가 매트릭스: 실전 점수화 프레임워크#

모든 기준에서 평가 후, 비교표가 필요합니다. 우선순위는 다음과 같습니다:

P1 — 계약 성사/실패를 가르는 기준 (불합격 시 바로 탈락)#

P2 — 강력 선호 (없으면 엔지니어링 부담 문제)#

P3 — 중요 (12개월 내 필요할 항목)#

P4 — 있으면 좋은 (의사결정에 영향 적음)#

활용법: P1 먼저 필터링(탈락시 바로 제외), 그 다음 P2, P3 점수별로 비교. P2+P3 합산 점수 최대 벤더가 답입니다.

평가시 자주 하는 실수#

실제 팀이 반복적으로 저지르는 실수와 대처법입니다:

실수 1: 기능 vs. 구조(아키텍처) 구분 안 함#

비교표는 "존재"만 보여줍니다. 실제 구현 방식은 말해주지 못합니다. IdP가 "조직 지원"이라면서 org_id를 유저 메타데이터에 박아두는 식입니다. 체크리스트엔 통과지만 실전 운영 문제로 이어집니다.

해결: 모든 기능에 "어떻게 구현되어 있나?"를 반드시 추가 질문하세요.

실수 2: 마이그레이션을 평가 마지막에 두기#

"최고" IdP 고른 뒤 실제로 사용하려다, 유저 비번 재설정 없이는 이관 안됨을 뒤늦게 깨달음. 이제 최악 이관이냐, 평가 재시작이냐만 남음.

해결: 마이그레이션 가능성부터 1차 필터로 사용하세요.

실수 3: 데모에 과도하게 의존#

모든 벤더 데모는 완벽하게 준비된 전용 데이터, 엣지 케이스 없는 환경만 보여줍니다. 실제 운영 중엔 병합계정, 프로필 이상 유니코드, 세션 꼬임 등 다양한 데이터가 존재합니다.

해결: 실제 데이터를 1,000명 이상 가져다 PoC(실증) 요청하세요.

실수 4: 평가팀에 이해관계자 미포함#

플랫폼 팀 단독 평가 시 기술적으로 깔끔한 것, 제품팀 단독 시 통합 쉬운 것, 보안팀 단독시 컴플라이언스 체크 많은 것을 선택. 각기 다른 P1/P2 기준.

해결: 평가팀은 플랫폼, 제품, 보안 동시 참여해야 함.

실수 5: 언젠가 떠나야 한다는 사실 간과#

벤더 락인은 현실. SDK/API/토큰 포맷 독점일수록 이후 이관이 힘들어집니다.

해결: OIDC/OAuth2/SCIM 등 표준 사용 IdP를 우선 고려. 미래를 위해서도.

FAQ#

IdP 평가엔 보통 얼마나 걸립니까?#

PoC(실증)까지 포함시 48주 걸립니다. 성급히 진행하면 특히 마이그레이션 누락 등 실수를 하게 됩니다. 요구사항 정리 2주, 벤더 평가/PoC 23주, 이해관계자 정합 1~2주 예상하세요.

인증 시스템 직접 개발하는 게 나을 때도 있나요?#

10,000명 미만/엔터프라이즈 없음 등 초기엔 경량 인증 라이브러리도 충분. 그러나 SSO, 멀티테넌시, MFA, 컴플라이언스 문서 필요해지는 순간, 자체 인증 시스템 유지비가 IdP 구독료를 넘어섭니다. 실제로 풀타임 인력 2~3명 유지 필요, 연간 수억 원 기회 비용.

CIAM과 워크포스 IAM의 차이는?#

CIAM은 고객이 실제 사용하는 회원가입/로그인/프로필 관리, 워크포스 IAM은 사내 직원들의 내부 도구 접근(예: Okta, 구글 워크스페이스 접근). 평가 기준과 구매 결정 모두 다릅니다. 본 가이드는 CIAM에 한정.

오픈소스와 상용의 중요성은?#

오픈소스는 코드 투명성, 셀프호스트, 커뮤니티 수정/기여 등 장점. 상용은 대체로 UI, 관리편의성 등 강점. 중요한 건 열려있냐/닫혀있냐가 아니라, "필요시 떠날 수 있나"입니다. 오픈소스가 보통 마이그레이션이 쉽습니다. (데이터/API 명세 공개)

AI 에이전트 인증이 P1이 되는 상황은?#

이미 AI가 유저 데이터에 접근한다면(P1), 6~12개월내 도입 예정이라면 P3으로 가중 적용. 아예 계획 없으면 P4로 두고 6개월 후 재검토하세요.

각 벤더의 가격 체계가 달라 비교가 어렵다면?#

대다수 IdP는 MAU(월간 활성 유저) 기준. 정의는 다양 — 로그인건수, 유니크유저, M2M토큰 별도 등. "우리 시나리오(X명 유저, Y 조직, Z건 머신간연동, 인증 요청량 포함)" 그대로 견적 요청/비교하면 됩니다. 단순 단가 말고 총 비용 비중으로 비교하세요.

결론#

인증 제공자 선택은 기능 체크가 아니라 인프라 결정입니다. 모든 유저 첫 진입/모든 API의 권한체크/모든 감사로그가 통과하는 시스템을 고르는 것.

위의 평가 프레임워크는 실전에서 실제 중요한 지점(마케팅 불릿 X)만 다루었습니다. P1 먼저 후보 걸러내고, P2/P3는 실제 데이터/Poc로 최종 결정을 하세요.

이 부분을 제대로 처리하는 팀은 공통적으로, 인증을 '배포하고 잊는 기능'이 아닌 '핵심 인프라'로 받아들입니다.