한국어
어떤 IdP(인증 제공자)를 선택할 것인가: 엔지니어링 팀의 평가 프레임워크
실제 엔터프라이즈 요구사항에서 도출한 실전 IdP 평가 프레임워크. 프로토콜 심층성, 마이그레이션, 다중 임차(멀티테넌시), AI-준비성 및 대부분의 체크리스트가 놓치는 기준까지 포괄적으로 다룹니다.
Yijun
Developer
Developer
실제 엔터프라이즈 요구사항에서 도출한 실전 IdP 평가 프레임워크. 프로토콜 심층성, 마이그레이션, 다중 임차(멀티테넌시), AI-준비성 및 대부분의 체크리스트가 놓치는 기준까지 포괄적으로 다룹니다.
대부분의 인증 제공자(Identity Provider) 비교 글은 IdP 회사가 직접 작성합니다. 충격적이지요? 자신들의 제품에 있는 기능을 나열하고, 없는 건 빼고, "객관적인 가이드"라고 부릅니다.
이 글은 다릅니다.
우리는 실제로 엔터프라이즈에서 벤더에게 보내는 평가 요청서와 스프레드시트, RFP 문서를 수십 건 검토했습니다. 패턴은 명확합니다: 엔지니어링 팀은 정말 중요한 기준을 과소평가하고, 덜 중요한 기준을 과대평가하는 경우가 반복됩니다.
결과는? 팀은 데모 보고 IdP를 결정했다가, 6개월 뒤 마이그레이션이 악몽임을 깨닫고 평가를 다시 시작합니다.
아래는 우리가 예전에 받았으면 했던 평가 프레임워크입니다. B2B SaaS 회사의 엔지니어링 조직을 위한, 즉 사내 직원용 SSO가 아닌 제품에 인증을 넣는 팀을 위한 가이드입니다.
바쁜 사람을 위해 핵심만 요약합니다:
이 가이드의 나머지 부분에서는 각 평가 항목별로 구체적인 질문과 레드플래그(경고 신호)를 제시합니다.
이런 경우에 해당되면 읽으세요:
이런 경우에는 읽지 않아도 됩니다:
시장에서 만나는 모든 IdP는 "OAuth2와 OIDC 지원"을 외칩니다. 당연한 기본입니다. 진짜 중요한 건 깊이(심층성)입니다.
필수:
점점 더 중요해지는 기능:
많은 팀이 빠뜨리는 질문: 이 IdP를 OIDC 제공자로 사용할 수 있나? (단순 소비자 아닌)
이유: SaaS가 성장하면 파트너와 고객이 당신의 IdP로 타 시스템에 로그인하길 원할 수 있습니다. 토큰 발행, 동의 관리, 3자 앱 등록 필요. 단순히 외부 IdP만 소비할 수 있고 제공자는 안 되면, 앞으로 확장 못합니다.
질문 예시:
토큰은 IdP와 서비스 사이의 계약입니다. 커스터마이즈 불가할 경우, 모든 하위 서비스가 유저의 권한 확인을 위해 추가 API 호출을 해야 합니다.
질문:
{ "org_id": "org_123", "role": "admin", "auth_level": 2 }와 같은 토큰이면 미들웨어 한 줄로 권한 판별이 끝나지만, { "sub": "user_456" }만 있으면 모든 서비스가 IdP/api에 추가 조회해야 합니다. 대규모에선 2ms 대 200ms 수준의 차이입니다.
모든 IdP가 이메일/비밀번호, 소셜 로그인을 지원합니다. 그래서 후보군은 아직도 모두입니다.
차별점은 대부분 데모로 안 나오는 디테일에 있습니다.
데모는 이 부분을 거의 건너뜁니다. 세션/토큰 관리는 문제 생기기 전엔 '지루해' 보이지만, 한번 터지면 전체 유저 로그아웃 대란입니다.
화려함은 없지만 치명적으로 중요합니다.
유저는 수 주, 수개월간 로그인 유지 원합니다. 180일 세션은 30분 세션과 보안 측면이 전혀 다릅니다.
질문:
RBAC(역할 기반 접근 제어)은 최소 기준입니다. RBAC도 없는 IdP는 평가할 의미가 없습니다. 하지만 B2B SaaS 환경에선 RBAC만으로 부족합니다.
유저는 "조직"에 소속되고, 조직별 권한이 플랫폼/글로벌 수준과 다릅니다.
예: 한 유저가 조직A에선 관리자, B에선 뷰어. 같은 유저라도 역할 맥락 다름. 이런 모델이 내장되지 않으면, 결국 별도의 권한 시스템을 직접 구축해야 하고, '두 개의 소스 오브 트루스'가 탄생합니다.
질문:
금융/헬스케어 등 민감 서비스는 모든 인증 세션이 같은 수준이 아닙니다.
대시보드 열람엔 세션 쿠키만으로 충분. 송금 등 고위험 작업은 MFA 등 별도 재인증 필요.
즉 auth_level(인증 레벨)을 토큰에서 1급 시민으로 지원해야 합니다.
질문:
IdP가 이걸 지원하지 않으면, 구현을 직접 해야 하고, 그게 IdP를 사는 이유를 무색하게 만듭니다.
이상적 모델: API 미들웨어가 토큰만 읽어서 조직/역할/auth_level까지 즉시 판별.
여러 IdP는: 토큰엔 유저만 식별되고, 권한은 별도 API를 조회해야 알 수 있음.
별도 호출은 지연, 의존성, 실패 위험까지 낳습니다. 초당 1,000회 요청이면 네트워크 핫스팟이 됩니다.
아무도 말하지 않는 통계: IdP 평가가 실패하는 주 원인은, 새 IdP가 '좋지 않아서'가 아니라, 기존 유저 마이그레이션 방법을 못 찾아서입니다.
10만명 이상 유저가 있으면, 마이그레이션이 프로젝트 전부입니다.
1. 기존 해시 비밀번호 대량 이관
기존 bcrypt, argon2 등으로 해싱된 비밀번호를 IdP에 직접 이관, 검증 가능?
YES: 유저는 변화 인식 없이 로그인. 베스트 케이스.
NO: 전체 유저 비밀번호 재설정 메일 발송. 이 과정에서 30~50% 유저 이탈. 실제 있었던 일입니다.
2. 점진적(게으른) 이관
모두 한 번에 옮기는 대신, 로그인 시마다 1명씩 이전. 최초 로그인은 구시스템서 비밀번호 검증/신규 IdP에 계정 생성, 그 후부턴 새 IdP 이용.
이런 방식은:
3. 듀얼라이트(병렬 운용)
구시스템/신시스템 동시 운용. 쓰기는 양쪽, 읽기는 점진적 이전. 롤백 가능하지만 운영 복잡성 추가.
명쾌히 답하지 못하면, 실제 경험이 없는 벤더입니다. 넘기세요.
B2B SaaS는 기본이 멀티테넌시. 고객(조직)별 유저 다수, 역할/정책 다수. IdP가 이를 네이티브로 이해해야 합니다.
조직 모델이 없는 IdP는 user.app_metadata.org_id 과 같은 형식의 커스텀 메타데이터를 쓰게 합니다.
이런 방식은 대규모에서 무너집니다:
"우리 메타데이터로 조직 관리 하세요"는 데이터베이스에서 관계형 테이블을 JSON 컬럼에 저장하라는 말과 같습니다. 잘 될 때까지만 됩니다.
12개월 전만 해도 "AI 에이전트 인증"은 평가 항목에 없었습니다. 오늘날, AI 기능(코파일럿/AI 워크플로우/에이전트) 도입을 계획한다면, IdP가 새로운 타입의 신원: 에이전트(비인간 주체)를 다룰 수 있어야 합니다.
전통적 인증은 유저/애플리케이션 2자 구도(OAuth2 설계 근간).
AI 에이전트는 3번째 주체: 비인간, 특정 유저 대리, 제한된 권한, 별도 감사추적 필요.
Token Exchange(RFC 8693): 에이전트가 자체 자격+유저 동의 제시, 제한 범위 토큰을 발급. 토큰 구조: 누구(유저), 누구(에이전트), 범위/만료 등.
에이전트별 client type: 에이전트를 별도 OAuth2 클라이언트(client_id)로 모델링. (API 키/유저 토큰 꼼수X)
위임 범위 관리: 유저가 에이전트에 select한 권한만 임시로 부여가능(읽기전용 등).
감사 구분: "유저 직접 vs. 에이전트 대리" 로그 구분 불가하면, SOC2 등 감사를 통과할 수 없습니다.
MCP는 AI 에이전트가 외부 도구/서비스와 상호작용하는 표준으로 자리잡는 중입니다. IdP가 OAuth 기반 MCP 인증 서버를 지원하면, 에이전트가 API 키/비밀키 없이 표준 인증 경로로 통합 가능.
벤더에게 이 질문이 낯설다면, 2020년 사고방식을 고수하고 있는 벤더입니다. 당신은 2026년을 준비하는 중입니다.
기능만 팔게 되어있지만, 운영이 재계약/교체의 진짜 결정자입니다.
모든 기준에서 평가 후, 비교표가 필요합니다. 우선순위는 다음과 같습니다:
| Criteria | P1인 이유 |
|---|---|
| 비밀번호 해시 가져오기 또는 점진적 마이그레이션 | 이거 안되면 아무 쓸모 없음 |
| Authorization Code + PKCE 지원 | 기본 보안 요구 |
| 네이티브 조직 모델 | B2B SaaS 필수 |
| SOC2 Type II(또는 확실한 계획) | 엔터프라이즈 필수 요구 |
| 99.9%+ 가동률 SLA | Auth 장애 = 제품 전체 장애 |
| Criteria | 이유 |
|---|---|
| 커스텀 JWT 클레임 | 권한 확인시 매번 외부 조회 방지 |
| 조직별 인증 정책 | 엔터프라이즈 온보딩 지원 |
| 조직단위 역할/토큰 | 멀티테넌트 권한관리 필수 |
| 리프레시 토큰 회전/회수 | 보안 우수관행 |
| 호스팅 UI/커스텀 UI 선택 | 다양한 케이스 대처 |
| Criteria | 이유 |
|---|---|
| Token Exchange (RFC 8693) | AI 에이전트 인증 |
| OIDC 제공자 역할 | 파트너 연동 |
| 단계별 인증 / auth_level | 금융 등 고위험 작업 구분 |
| SCIM 프로비저닝 | 엔터프라이즈 디렉터리 동기화 |
| 패스키/WebAuthn | 패스워드리스 미래 준비 |
| Criteria | 이유 |
|---|---|
| 내장형 분석(Analytics) 대시보드 | 로그로 대체 가능 |
| 화이트라벨 이메일 템플릿 | 편의성 |
| 시각적 플로우 빌더 | 편의성 |
| SNS 커넥터(상위 5개 외) | 롱테일 대응 |
활용법: P1 먼저 필터링(탈락시 바로 제외), 그 다음 P2, P3 점수별로 비교. P2+P3 합산 점수 최대 벤더가 답입니다.
실제 팀이 반복적으로 저지르는 실수와 대처법입니다:
비교표는 "존재"만 보여줍니다. 실제 구현 방식은 말해주지 못합니다. IdP가 "조직 지원"이라면서 org_id를 유저 메타데이터에 박아두는 식입니다. 체크리스트엔 통과지만 실전 운영 문제로 이어집니다.
해결: 모든 기능에 "어떻게 구현되어 있나?"를 반드시 추가 질문하세요.
"최고" IdP 고른 뒤 실제로 사용하려다, 유저 비번 재설정 없이는 이관 안됨을 뒤늦게 깨달음. 이제 최악 이관이냐, 평가 재시작이냐만 남음.
해결: 마이그레이션 가능성부터 1차 필터로 사용하세요.
모든 벤더 데모는 완벽하게 준비된 전용 데이터, 엣지 케이스 없는 환경만 보여줍니다. 실제 운영 중엔 병합계정, 프로필 이상 유니코드, 세션 꼬임 등 다양한 데이터가 존재합니다.
해결: 실제 데이터를 1,000명 이상 가져다 PoC(실증) 요청하세요.
플랫폼 팀 단독 평가 시 기술적으로 깔끔한 것, 제품팀 단독 시 통합 쉬운 것, 보안팀 단독시 컴플라이언스 체크 많은 것을 선택. 각기 다른 P1/P2 기준.
해결: 평가팀은 플랫폼, 제품, 보안 동시 참여해야 함.
벤더 락인은 현실. SDK/API/토큰 포맷 독점일수록 이후 이관이 힘들어집니다.
해결: OIDC/OAuth2/SCIM 등 표준 사용 IdP를 우선 고려. 미래를 위해서도.
PoC(실증)까지 포함시 48주 걸립니다. 성급히 진행하면 특히 마이그레이션 누락 등 실수를 하게 됩니다. 요구사항 정리 2주, 벤더 평가/PoC 23주, 이해관계자 정합 1~2주 예상하세요.
10,000명 미만/엔터프라이즈 없음 등 초기엔 경량 인증 라이브러리도 충분. 그러나 SSO, 멀티테넌시, MFA, 컴플라이언스 문서 필요해지는 순간, 자체 인증 시스템 유지비가 IdP 구독료를 넘어섭니다. 실제로 풀타임 인력 2~3명 유지 필요, 연간 수억 원 기회 비용.
CIAM은 고객이 실제 사용하는 회원가입/로그인/프로필 관리, 워크포스 IAM은 사내 직원들의 내부 도구 접근(예: Okta, 구글 워크스페이스 접근). 평가 기준과 구매 결정 모두 다릅니다. 본 가이드는 CIAM에 한정.
오픈소스는 코드 투명성, 셀프호스트, 커뮤니티 수정/기여 등 장점. 상용은 대체로 UI, 관리편의성 등 강점. 중요한 건 열려있냐/닫혀있냐가 아니라, "필요시 떠날 수 있나"입니다. 오픈소스가 보통 마이그레이션이 쉽습니다. (데이터/API 명세 공개)
이미 AI가 유저 데이터에 접근한다면(P1), 6~12개월내 도입 예정이라면 P3으로 가중 적용. 아예 계획 없으면 P4로 두고 6개월 후 재검토하세요.
대다수 IdP는 MAU(월간 활성 유저) 기준. 정의는 다양 — 로그인건수, 유니크유저, M2M토큰 별도 등. "우리 시나리오(X명 유저, Y 조직, Z건 머신간연동, 인증 요청량 포함)" 그대로 견적 요청/비교하면 됩니다. 단순 단가 말고 총 비용 비중으로 비교하세요.
인증 제공자 선택은 기능 체크가 아니라 인프라 결정입니다. 모든 유저 첫 진입/모든 API의 권한체크/모든 감사로그가 통과하는 시스템을 고르는 것.
위의 평가 프레임워크는 실전에서 실제 중요한 지점(마케팅 불릿 X)만 다루었습니다. P1 먼저 후보 걸러내고, P2/P3는 실제 데이터/Poc로 최종 결정을 하세요.
이 부분을 제대로 처리하는 팀은 공통적으로, 인증을 '배포하고 잊는 기능'이 아닌 '핵심 인프라'로 받아들입니다.