12. CIAM 아키텍처 구성요소
CIAM(Customer Identity and Access Management)을 단순한 로그인 시스템으로만 보면 설계 범위를 지나치게 좁게 잡게 됩니다. 실제 CIAM은 인증, 사용자 프로파일, 접근 정책, 동의, API 연동, 감사와 보안 모니터링이 결합된 고객 신원 플랫폼입니다.
특히 대규모 소비자 서비스에서는 이벤트·캠페인·신제품 출시 등으로 평소보다 훨씬 높은 트래픽이 발생할 수 있습니다. 다만 “트래픽이 반드시 10배 증가한다”거나 “모든 CIAM은 동일한 응답시간 기준을 가져야 한다”고 보는 것은 적절하지 않습니다. 실제 목표는 서비스의 MAU, 피크 로그인 비율, 지역 분포, 비즈니스 중요도, 규제·보안 요구에 따라 조직별 SLO(Service Level Objective)로 정의해야 합니다.
이 글의 성능·가용성·복구 목표는 보편적 업계 표준이 아니라 Digital Future & Strategy의 실무 설계 예시입니다. 실제 수치는 각 조직의 서비스 등급, 위험도, 비용, 사용자 규모, 벤더 계약조건을 기준으로 정해야 합니다.
1. CIAM 아키텍처 전체 구조
CIAM은 하나의 고정된 참조 아키텍처만 존재하는 시스템이 아닙니다. SaaS CIAM을 사용할 수도 있고, 일부 기능을 자체 구축할 수도 있으며, 기능별 서비스를 분리한 구조를 사용할 수도 있습니다. 중요한 것은 역할과 책임을 명확히 나누고, 장애·확장·보안 영향범위를 통제하는 것입니다.
| # | 레이어 | 핵심 역할 | 주요 설계 관심사 |
|---|---|---|---|
| 1 | 인증 서비스 | 로그인·MFA·패스워드리스·토큰·세션 | 피크 트래픽·보안·가용성 |
| 2 | 사용자 저장소 | 계정·프로파일·자격증명·연결 식별자 | 일관성·보안·확장성 |
| 3 | 정책 엔진 | 인가·위험기반 접근·조건부 정책 | 정책 일관성·변경 통제 |
| 4 | 동의 서비스 | 동의 수집·철회·버전·전파·증적 | 이력·법적 근거·연동 |
| 5 | API / Integration | 외부 IdP·CRM·마케팅·결제·고객센터 연동 | 보안·Rate Limit·재시도 |
| 6 | Audit / Observability | 인증·인가·동의·관리자 변경 이벤트 추적 | 감사·탐지·보존·검색 |
2. 레이어 1 — 인증 서비스 (Authentication Service)
인증 서비스는 CIAM의 핵심 진입점입니다. 로그인, MFA, 패스워드리스, 소셜 로그인, 토큰 발급과 세션 관리가 이 영역에 속합니다.
| 기능 | 설계 포인트 |
|---|---|
| 다중 인증 방식 | 비밀번호, 소셜 로그인, OTP, 패스키/FIDO 기반 인증 등 채널별 요구사항을 표준 프로토콜과 연계 |
| 토큰 관리 | Access/Refresh/ID Token의 역할을 분리하고 유효기간·재발급·폐기 정책을 서비스 위험도에 맞게 설정 |
| 위험기반 인증 | IP·기기·지역·행동 패턴 등 신호를 활용해 추가 인증, 차단, 모니터링 여부 판단 |
| 세션 관리 | 세션 만료, 강제 종료, 다중 기기, Single Logout 등을 서비스 구조에 맞게 설계 |
| Credential Stuffing / Brute Force 방어 | Rate Limit, 점진적 지연, CAPTCHA/Challenge, 위험기반 MFA 등을 조합하고 임계값은 실제 공격 패턴과 사용자 경험을 기준으로 조정 |
평소보다 수배 높은 로그인 요청이 발생하는 캠페인·출시 이벤트를 가정해 인증 서비스가 자동 확장되는지 검증할 수 있습니다. 필요한 최소 인스턴스 수나 Auto-Scaling 임계값은 “3개 인스턴스”, “CPU 70%”처럼 고정하기보다 조직의 장애 허용수준과 실제 부하 테스트 결과로 결정해야 합니다.
3. 레이어 2 — 사용자 저장소 (User Store)
사용자 저장소는 고객 계정과 프로파일을 관리하는 데이터 기반입니다. 데이터 유형에 따라 관계형 DB, NoSQL, 캐시, 디렉토리 등을 조합할 수 있습니다.
| 저장소 유형 | 적합한 데이터 | 설계 고려사항 |
|---|---|---|
| 관계형 DB | 계정 핵심정보·동의·거래성 메타데이터 | 정합성이 중요할 때 적합. 샤딩·복제는 규모와 장애요건에 따라 결정 |
| NoSQL | 확장 가능한 프로파일·이벤트성 데이터 | 유연한 스키마와 수평 확장에 유리. 쿼리·일관성 요구를 함께 검토 |
| 인메모리 / Cache | 세션·OTP·단기 캐시 | 고속 조회에 유리. 데이터 영속성·복제·장애 시 동작을 별도 설계 |
| Directory | B2B federation·기존 기업 계정 | 기존 IAM/디렉토리와 연결할 때 유용. 대규모 B2C의 주 저장소와는 요구가 다를 수 있음 |
- 비밀번호는 검증된 password hashing 알고리즘을 사용하고 알고리즘·cost parameter는 최신 보안 가이드에 따라 관리
- 계정별 고유 salt를 적용하고 평문 비밀번호를 저장하지 않음
- 민감정보는 데이터 분류에 따라 저장·전송 암호화와 키 관리 체계를 적용
- 직접 DB 접근 권한을 최소화하고 애플리케이션·관리자 접근을 별도로 통제
4. 레이어 3 — 정책 엔진 (Policy Engine)
정책 엔진은 “인증된 사용자가 현재 이 작업을 수행할 수 있는가”를 결정하는 영역입니다. 인증과 인가를 분리하고 정책을 중앙에서 관리하면 여러 채널에서 일관된 통제를 적용하기 쉬워집니다.
| 정책 유형 | 판단 기준 | 적용 예시 |
|---|---|---|
| RBAC | 사용자의 역할·등급 | 관리자·회원 등 역할별 기능 접근 분리 |
| ABAC | 역할 + 국가 + 기기 + 시간 + 리스크 등 | 조건에 따라 추가 인증 또는 접근 제한 |
| 동의 기반 정책 | 현재 동의·목적·채널 상태 | 마케팅 동의가 없는 사용자의 특정 데이터 활용 차단 |
| Risk-Based Policy | 실시간 위험 신호 | 조직이 정의한 위험 임계값에 따라 MFA·차단·모니터링 적용 |
| 연령·자격 정책 | 법적·서비스별 자격 기준 | 연령 또는 자격조건이 필요한 콘텐츠·기능 제한 |
설계 원칙: 정책을 애플리케이션마다 중복 하드코딩하기보다 중앙 정책 또는 Policy-as-Code를 활용하면 변경 관리와 감사가 쉬워집니다. 다만 모든 조직이 별도 정책 엔진을 구축해야 하는 것은 아니며, CIAM 벤더의 정책 기능이나 애플리케이션 게이트웨이 수준에서 구현할 수도 있습니다.
5. 레이어 4 — 동의 서비스 (Consent Service)
동의 서비스의 핵심은 동의 사실을 단순 저장하는 것이 아니라 누가, 언제, 어떤 문구와 목적에 동의 또는 철회했는지 증적을 남기고 이를 관련 시스템에 일관되게 전파하는 것입니다.
| 구성요소 | 아키텍처 설계 |
|---|---|
| 동의 저장소 | 동의·철회·약관 버전을 시간순으로 추적하고 변경이력을 훼손하기 어렵게 설계 |
| 동의 API | 수집·조회·철회·버전관리 API를 명확히 정의하고 목적·채널·지역 정책과 연계 |
| 이벤트 발행 | 동의 변경을 CRM·마케팅·분석 시스템에 이벤트 또는 API 방식으로 전파 |
| 캐시 | 고빈도 조회를 최적화하되 동의 변경과 캐시 정합성의 우선순위를 명확히 설정 |
6. 레이어 5 — API 게이트웨이 및 통합 레이어
API 게이트웨이와 통합 레이어는 CIAM과 외부 애플리케이션·IdP·CRM·마케팅·결제 시스템 사이의 연결을 담당합니다. 모든 요청이 반드시 하나의 게이트웨이를 경유해야 하는 것은 아니지만, 중앙 통제가 필요한 API에서는 중요한 역할을 합니다.
| 기능 | 설계 포인트 |
|---|---|
| 토큰·인가 검증 | 게이트웨이에서 공통 검증할 범위와 각 서비스가 자체 검증할 범위를 명확히 분리 |
| Rate Limiting | IP·계정·클라이언트·엔드포인트별로 위험도와 정상 트래픽 패턴에 맞는 제한 설정 |
| Bot / Abuse 방어 | 행동·기기·네트워크 신호와 Challenge를 조합해 자동화 공격 완화 |
| 외부 IdP 연동 | OIDC/OAuth/SAML 등 필요한 프로토콜을 표준 방식으로 연결 |
| 내부 시스템 연동 | 웹훅·이벤트·API 호출에 재시도, 타임아웃, Circuit Breaker, idempotency 설계 |
| 버전 관리 | 하위호환·deprecated API·지원 종료 정책을 운영 관점에서 관리 |
7. 레이어 6 — 감사 로그와 관측가능성
CIAM에서는 인증 성공·실패, MFA, 동의 변경, 계정 변경, 관리자 작업, 정책 변경 등의 이벤트를 추적할 수 있어야 합니다. 감사 로그는 보안사고 조사와 규제 대응뿐 아니라 서비스 품질 분석에도 사용됩니다.
- 비동기 처리: 핵심 인증 경로와 로그 적재를 필요에 따라 분리
- 독립 저장: 운영 데이터와 감사 데이터를 논리적 또는 물리적으로 분리
- 무결성: 로그 변조를 탐지하거나 제한할 수 있는 저장·접근정책 적용
- 실시간 탐지: SIEM·보안 분석과 연계해 이상행동 탐지
- 보존 기간: 법률·산업 규제·분쟁 대응·내부 정책에 따라 이벤트 유형별로 정의
8. 서비스 분리와 배포 아키텍처
마이크로서비스 아키텍처는 CIAM에 유용할 수 있지만 모든 환경의 필수 조건은 아닙니다. SaaS CIAM, 모듈러 모놀리스, 마이크로서비스 모두 가능하며 조직 역량과 서비스 규모에 따라 선택해야 합니다.
| 설계 선택 | CIAM 적용 시 검토사항 |
|---|---|
| 서비스 분리 | 인증·프로파일·동의·감사를 분리할 경우 독립 확장과 장애격리에 유리하지만 운영 복잡성이 증가 |
| 독립 배포 | 변경 영향도를 줄일 수 있지만 CI/CD·버전 호환·관측가능성이 필요 |
| 서비스별 저장소 | 업무 특성에 맞는 DB 선택이 가능하지만 데이터 일관성과 운영 복잡성을 함께 고려 |
| Container / Kubernetes | 자동확장·롤링배포에 유리하지만 소규모 서비스에서는 과도한 복잡성이 될 수 있음 |
| SaaS CIAM | 운영부담을 줄일 수 있으나 기능·데이터·지역·라이선스·exit 전략을 검토해야 함 |
9. 고가용성 설계와 조직별 RTO/RPO
CIAM 장애는 로그인·회원가입·토큰 갱신·계정 복구 등 핵심 고객 접점에 직접 영향을 줄 수 있으므로 고가용성 설계가 중요합니다. 다만 Active-Active, Active-Passive, 멀티리전 중 어떤 구조를 선택할지는 서비스 중요도와 비용의 균형으로 결정해야 합니다.
| 구성 방식 | 특징 | 적합한 상황 |
|---|---|---|
| Active-Active | 복수 노드 또는 리전이 동시에 트래픽 처리 | 중단 허용도가 낮고 무중단에 가까운 운영이 필요한 서비스 |
| Active-Passive | Primary 장애 시 Standby로 전환 | 구조 단순성과 비용을 중시하면서 일정 수준의 복구시간을 허용하는 서비스 |
| Multi-Region | 리전 장애 대응 가능 | 글로벌 서비스, 재해복구 요건, 지역별 데이터 요구가 있는 환경 |
예를 들어 결제·커머스 로그인처럼 중단 비용이 큰 서비스는 매우 짧은 RTO를 목표로 할 수 있고, 상대적으로 중요도가 낮은 서비스는 더 긴 복구시간을 허용할 수 있습니다. RPO 역시 계정·동의·보안 이벤트별 데이터 손실 허용도가 다르므로 하나의 보편적 수치로 고정하지 않는 것이 적절합니다.
10. CIAM SLO와 부하 테스트
CIAM 성능 기준은 외부 벤치마크 수치를 복사하기보다 실제 서비스의 트래픽 패턴과 사용자 경험 목표를 기반으로 SLO를 정의해야 합니다.
| 지표 | SLO 설정 방식 | 검증 방법 |
|---|---|---|
| 로그인 응답시간 | P95/P99 기준을 사용자 경험과 외부 IdP 지연을 고려해 정의 | 정상·피크·외부 IdP 지연 시나리오로 부하 테스트 |
| 토큰 처리량 | 예상 피크 TPS와 성장률에 따라 목표 설정 | Token issue/refresh/revoke 경로를 분리해 측정 |
| 가용성 | 비즈니스 중요도와 비용을 기준으로 서비스 등급별 목표 설정 | 업타임·오류율·Error Budget 추적 |
| 동시 세션 | MAU 비율이 아니라 실제 peak concurrent session 데이터를 기반으로 산정 | 세션 저장소 메모리·네트워크·복제 영향 검증 |
| 데이터 조회시간 | 인증 경로와 프로파일 조회 경로를 구분해 목표 설정 | P95/P99 latency와 cache hit ratio를 함께 측정 |
| 에러율 | 정상 실패와 시스템 오류를 구분해 목표 정의 | HTTP status, 인증 실패 사유, dependency 오류 분리 |
- Baseline: 평상시 대표 트래픽
- Peak: 마케팅 이벤트·신제품 출시 등 예상 피크
- Stress: 예상 피크를 넘는 수준에서 성능 저하 지점 확인
- Dependency Failure: 외부 IdP·SMS·메일·DB 일부 장애 상황
- Recovery: 인스턴스 또는 리전 장애 후 복구시간 검증
11. 정리
CIAM 아키텍처의 핵심은 특정 기술 스택이나 하나의 숫자를 정답으로 제시하는 것이 아닙니다. 인증, 프로파일, 정책, 동의, API, 감사의 책임을 분리하고, 각 레이어의 장애·확장·보안 영향을 이해한 뒤 조직의 서비스 수준에 맞는 SLO를 정의하는 것이 중요합니다.
트래픽 10배나 특정 P99 숫자를 목표로 하는 것이 아니라,
우리 서비스가 감당해야 할 실제 위험과 부하를
측정 가능한 SLO로 정의하는 것에서 시작합니다."
설계 검토 시에는 세 가지를 확인하면 됩니다. 첫째, 인증과 세션이 단일 장애 지점에 과도하게 의존하지 않는지 확인합니다. 둘째, 접근 정책과 동의 상태가 채널별로 불일치하지 않는지 검토합니다. 셋째, 정상·피크·장애 시나리오를 포함한 부하 테스트를 수행해 조직이 정의한 SLO를 충족하는지 검증합니다.
- NIST. Zero Trust Architecture (SP 800-207).
- IETF. The OAuth 2.0 Authorization Framework (RFC 6749).
- OpenID Foundation. OpenID Connect Core 1.0.
- OWASP Foundation. API Security Top 10.
※ 성능·보존·복구·보안 임계값은 조직별 정책과 최신 공식 가이드를 기준으로 별도 결정해야 합니다.
Reviewed: September 2026. 고정 성능 수치보다 조직별 SLO와 실제 트래픽 시나리오를 중심으로 재작성했습니다.
Comments
Post a Comment