13. CIAM 아키텍처 구성요소
CIAM을 "로그인 시스템"으로 이해하면 설계가 처음부터 잘못됩니다. 실제 CIAM 아키텍처는 수백만 고객의 신원을 실시간으로 확인하고, 수십 개 시스템과 데이터를 주고받으며, 트래픽이 10배 폭증해도 병목 없이 작동해야 하는 복잡한 분산 시스템입니다.
이 글에서는 CIAM을 구성하는 핵심 레이어—인증 서비스, 사용자 저장소, 정책 엔진, 동의 서비스, API 게이트웨이, 감사 시스템—를 각각 설계 포인트와 함께 상세히 정리하고, MSA 기반 고가용성 구성과 성능 기준까지 실무 관점에서 완전히 안내합니다.
1. CIAM 아키텍처 전체 구조
현대 CIAM 아키텍처는 단일 서버 구조가 아닌 기능별로 분리된 마이크로서비스 레이어로 구성됩니다. 각 레이어는 독립적으로 배포·확장이 가능하며, 특정 레이어 장애가 전체 시스템 마비로 이어지지 않도록 설계됩니다.
| # | 레이어 | 핵심 역할 | 확장 우선도 |
|---|---|---|---|
| 1 | 인증 서비스 | 로그인·MFA·RBA·토큰 발급 | 🔴 최고 (트래픽 집중) |
| 2 | 사용자 저장소 | 프로파일·자격증명 저장 | 🔴 최고 (읽기 집중) |
| 3 | 정책 엔진 | 인가·접근 제어·RBA 판단 | 🟡 중간 |
| 4 | 동의 서비스 | 동의 수집·저장·철회·전파 | 🟡 중간 |
| 5 | API 게이트웨이 | 외부 연동·트래픽 제어·보안 | 🔴 최고 (모든 요청 경유) |
| 6 | 감사 로그 시스템 | 이벤트 기록·보안 분석·규제 대응 | 🟢 낮음 (비동기 처리) |
2. 레이어 1 — 인증 서비스 (Authentication Service)
인증 서비스는 CIAM의 심장입니다. 고객이 로그인 버튼을 누르는 순간, 이 레이어가 작동합니다.
| 기능 | 설계 포인트 |
|---|---|
| 다중 인증 방식 지원 | 비밀번호·소셜 로그인·OTP·패스워드리스·FIDO2를 단일 인증 엔진으로 처리. 각 방식의 결과를 표준화된 토큰(JWT)으로 변환 |
| 토큰 발급 및 관리 | Access Token (짧은 유효기간, 15분~1시간), Refresh Token (긴 유효기간, 7~30일), ID Token (사용자 정보 포함) 분리 발급. 토큰 저장소(Redis 등)에서 실시간 무효화 지원 |
| RBA 위험 점수 계산 | IP·기기·시간·행동 패턴·유출 정보 DB 연계로 실시간 위험 점수 산출. 임계값 초과 시 정책 엔진에 추가 인증 요청 |
| 세션 관리 | 분산 세션 저장소(Redis Cluster) 활용. 세션 만료·강제 종료·기기별 독립 세션 지원. Single Logout(SLO) 연계 |
| 브루트포스 방어 | 로그인 실패 횟수 기반 점진적 잠금(5회→15분, 10회→1시간). CAPTCHA 연동. IP 기반 Rate Limiting |
인증 서비스를 단일 서버로 운영하면 블랙 프라이데이, 신제품 출시, 바이럴 이벤트처럼 트래픽이 순간 폭증할 때 인증 서버가 병목이 됩니다. 인증 서비스는 최소 3개 이상의 인스턴스를 로드밸런서 뒤에 배치하고, Auto-Scaling 정책을 반드시 설정해야 합니다.
3. 레이어 2 — 사용자 저장소 (User Store)
사용자 저장소는 고객의 프로파일과 자격 증명을 보관하는 CIAM의 데이터 기반입니다. 성능과 보안이 동시에 요구되는 가장 까다로운 레이어입니다.
| 저장소 유형 | 적합한 데이터 | 설계 고려사항 |
|---|---|---|
| 관계형 DB (PostgreSQL, MySQL) |
계정 기본 정보, 동의 이력, 감사 로그 | 트랜잭션 정합성 강점. 수억 건 이상 시 샤딩 필요. 읽기 복제본(Read Replica) 필수 |
| NoSQL (MongoDB, DynamoDB) |
고객 프로파일, 세션 데이터, 행동 이력 | 유연한 스키마로 Progressive Profiling에 적합. 수평 확장 용이. 조인 불가 단점 |
| 인메모리 DB (Redis) |
세션·토큰·OTP·캐시 | 밀리초 단위 응답. 휘발성 주의. 클러스터 구성으로 가용성 확보. 토큰 블랙리스트 관리 |
| 디렉토리 서비스 (LDAP) |
기업 B2B 환경의 계정 정보 | 기존 기업 인프라 연동에 강점. 계층적 구조 관리. B2C 대규모 환경에는 부적합 |
- 비밀번호 해싱: bcrypt (cost factor 12 이상) 또는 Argon2id 사용. MD5·SHA-1 절대 사용 금지
- 솔팅(Salting): 계정별 고유 랜덤 솔트 적용. Rainbow Table 공격 방어
- 암호화: 민감 정보(CI, 생체정보 등)는 AES-256 암호화 후 저장. 암호화 키는 HSM(하드웨어 보안 모듈) 또는 KMS 관리
- 접근 최소화: 사용자 저장소에 직접 접근하는 서비스를 인증 서비스로 제한
4. 레이어 3 — 정책 엔진 (Policy Engine)
정책 엔진은 "인증된 이 고객이 지금 이 요청을 할 수 있는가"를 결정합니다. 인증(Authentication)과 인가(Authorization)가 분리되어야 하는 이유가 바로 이 레이어에 있습니다.
| 정책 유형 | 판단 기준 | 적용 예시 |
|---|---|---|
| RBAC 정책 (역할 기반) |
사용자 역할 (일반/프리미엄/관리자) | 프리미엄 회원만 콘텐츠 전체 접근 허용 |
| ABAC 정책 (속성 기반) |
역할 + 국가 + 기기 + 시간대 복합 조건 | 해외 IP에서 고액 결제 시도 시 추가 인증 |
| 동의 기반 정책 | 고객의 현재 동의 상태 | 마케팅 동의 철회 고객에게 광고 API 호출 차단 |
| RBA 정책 | 실시간 위험 점수 | 위험 점수 70 이상 시 MFA 강제 요구 |
| 연령 기반 정책 | CI 기반 확인된 연령 | 만 19세 미만 고객 성인 콘텐츠 접근 차단 |
핵심 설계 원칙: 정책은 애플리케이션 코드에 하드코딩하지 않습니다. 정책 엔진을 중앙화하여 모든 애플리케이션이 공통으로 참조하도록 설계해야, 정책 변경 시 전체 서비스에 즉시 일관되게 반영됩니다. OPA(Open Policy Agent)처럼 정책을 코드로 관리하는(Policy as Code) 접근이 권장됩니다.
5. 레이어 4 — 동의 서비스 (Consent Service)
동의 서비스는 포스트 #11에서 상세히 다뤘지만, 아키텍처 관점에서의 핵심 설계 포인트를 정리합니다.
| 구성요소 | 아키텍처 설계 |
|---|---|
| 동의 저장소 | 불변 로그(Immutable Log) 구조. INSERT만 허용, UPDATE/DELETE 불가. 시간순 이력 보관. 약관 전문을 버전별로 함께 저장 |
| 동의 API | GET(조회)·POST(수집)·PUT(철회) 엔드포인트. 정책 엔진과 연동하여 동의 상태 기반 접근 제어 |
| 이벤트 발행 | 동의 변경 시 메시지 큐(Kafka/RabbitMQ)에 이벤트 발행. CRM·마케팅·분석 시스템이 구독하여 자동 동기화 |
| 캐시 전략 | 빈번히 조회되는 동의 상태를 Redis에 캐싱. 동의 변경 즉시 캐시 무효화. API 게이트웨이에서 인라인 조회 |
6. 레이어 5 — API 게이트웨이 및 통합 레이어
API 게이트웨이는 CIAM과 외부 세계 사이의 관문입니다. 모든 인바운드·아웃바운드 요청이 이 레이어를 경유합니다.
| 기능 | 설계 포인트 |
|---|---|
| 인증·인가 검증 | 모든 API 요청의 토큰 검증을 게이트웨이에서 일괄 처리. 각 서비스가 개별 검증하지 않도록 중앙화 |
| Rate Limiting | IP별·계정별·엔드포인트별 요청 횟수 제한. 슬라이딩 윈도우 방식 권장. 초과 시 429 응답 + 재시도 헤더 제공 |
| Bot 탐지 | User-Agent 분석, 요청 패턴 분석, CAPTCHA 연동. 의심 트래픽 자동 차단 또는 챌린지 요청 |
| 외부 IdP 연동 | Google·Apple·카카오 등 소셜 플랫폼과의 OAuth 콜백 처리. 프로토콜 변환(SAML↔OIDC) 브릿지 레이어 |
| 내부 시스템 연동 | CRM·마케팅·결제·고객센터 시스템과의 웹훅·이벤트 발행 처리. 재시도 로직·서킷 브레이커 패턴 적용 |
| API 버전 관리 | 하위 호환성 유지를 위한 버전별 엔드포인트(/v1, /v2). 구버전 지원 기간 정책 명확히 수립 |
7. 레이어 6 — 감사 로그 시스템
감사 로그 시스템은 모든 인증·인가·동의 이벤트를 불변 형태로 기록하는 CIAM의 블랙박스입니다.
- 비동기 처리: 인증 요청 처리와 로그 기록을 분리. 로그 기록 지연이 로그인 속도에 영향을 주지 않도록
- 별도 저장소: 운영 DB와 분리된 전용 로그 저장소. Elasticsearch 또는 전용 SIEM 시스템 연동
- 불변성 보장: 로그 수정·삭제 불가 구조. WORM(Write Once Read Many) 스토리지 활용 검토
- 실시간 분석: 이상 징후(단시간 다수 실패, 비정상 IP 등) 감지 시 즉시 알림. SIEM 연동
- 보존 기간: 인증 이벤트 최소 1년, 동의 이력은 계약 기간 + 5년 이상 보관 권장
8. MSA 기반 CIAM 아키텍처 설계 원칙
현대 CIAM은 마이크로서비스 아키텍처(MSA)를 기반으로 구성됩니다. 각 레이어를 독립 서비스로 분리하면 개별 확장과 장애 격리가 가능합니다.
| MSA 원칙 | CIAM 적용 방법 |
|---|---|
| 서비스 분리 | 인증·프로파일·동의·감사를 각각 독립 서비스로 분리. 서비스 간 통신은 REST API 또는 gRPC |
| 독립 배포 | MFA 로직 변경 시 전체 CIAM을 재배포하지 않고 인증 서비스만 롤링 업데이트 |
| 서비스별 DB | 인증 서비스는 Redis, 프로파일 서비스는 MongoDB, 동의 서비스는 PostgreSQL처럼 특성에 맞는 DB 선택 |
| 서킷 브레이커 | 외부 IdP(Google·카카오) 장애 시 해당 소셜 로그인만 차단하고 다른 인증 방식은 정상 운영 |
| 헬스체크 | 각 서비스의 /health 엔드포인트로 로드밸런서가 상태 감지. 비정상 인스턴스 자동 제외 |
CIAM 서비스를 Kubernetes 클러스터에 배포하면 트래픽에 따른 자동 확장(HPA), 롤링 업데이트, 셀프 힐링이 가능합니다. 인증 서비스의 경우 최소 3개 Pod를 기본으로 하되, CPU 사용률 70% 초과 시 자동으로 Pod를 추가하는 Auto-Scaling 정책을 설정합니다.
9. 고가용성(HA) 설계 — Active-Active vs Active-Passive
CIAM 인증 서비스가 다운되면 전체 서비스 로그인이 불가능해집니다. 고가용성 설계는 선택이 아닌 필수입니다.
| 구성 방식 | 특징 | CIAM 적용 권장 |
|---|---|---|
| Active-Active | 모든 노드가 동시에 트래픽 처리. 한 노드 장애 시 나머지가 즉시 흡수. 최고 가용성 | 인증 서비스, API 게이트웨이에 권장. 다중 리전 배포 시 지역별 Active 노드 운영 |
| Active-Passive | Primary 노드 처리, Standby 노드 대기. Failover에 수십 초 소요. 구성 단순 | 사용자 저장소 Primary DB에 적용. 쓰기 작업 정합성 유지 목적 |
| 멀티 리전 | 지역별 독립 클러스터. 리전 장애 시 다른 리전으로 트래픽 전환 | 글로벌 서비스 필수. 데이터 주권 규제(GDPR 데이터 국외 이전) 준수 설계 필요 |
- RTO (복구 목표 시간): 인증 서비스 장애 시 30초 이내 자동 복구를 목표로 설계
- RPO (복구 목표 시점): 사용자 저장소 데이터 손실 허용 범위는 1분 이내. 실시간 동기화 복제 구성
10. CIAM 성능 기준 및 부하 테스트
CIAM 아키텍처 설계 완료 후 반드시 성능 기준을 수립하고 부하 테스트로 검증해야 합니다.
| 지표 | 권장 목표 기준 | 측정 방법 |
|---|---|---|
| 로그인 응답 시간 | P99 기준 500ms 이내 | k6, JMeter로 동시 사용자 시뮬레이션 |
| 토큰 발급 TPS | 최대 부하 시 1,000 TPS 이상 | 피크 트래픽 예측 후 1.5~2배 여유 설계 |
| 가용성 | 99.9% 이상 (월 다운타임 44분 이하) | 월별 업타임 모니터링 (Datadog, New Relic 등) |
| 동시 세션 수 | 최대 예상 MAU × 0.1 이상 처리 | Redis 클러스터 메모리 사전 계산 |
| DB 쿼리 시간 | 사용자 조회 P99 기준 10ms 이내 | 인덱스 설계 최적화 + 캐시 적중률 모니터링 |
11. 정리
CIAM 아키텍처는 레이어 하나하나가 독립적으로 설계되고, 동시에 유기적으로 연결되어야 합니다. 인증 서비스가 토큰을 발급하고, 정책 엔진이 접근을 결정하고, 동의 서비스가 합법성을 보증하고, API 게이트웨이가 모든 것을 중개하며, 감사 로그가 전체 이력을 기록합니다.
가장 잘 만들어진 레이어가 아니라
가장 취약한 레이어가 결정합니다."
설계 단계에서 확인할 세 가지입니다. 첫째, 인증 서비스가 단일 장애 지점(SPOF)이 되지 않도록 이중화 구성이 되어 있는지 확인하십시오. 둘째, 정책이 각 애플리케이션 코드에 분산되어 있지 않고 중앙 정책 엔진에서 관리되는지 검토하십시오. 셋째, 부하 테스트로 피크 트래픽 시 P99 응답 시간이 목표 기준을 충족하는지 반드시 검증하십시오.
- NIST. (2020). Zero Trust Architecture (SP 800-207). NIST.
- Gartner. (2024). Magic Quadrant for Customer Identity and Access Management. Gartner, Inc.
- IETF. (2012). The OAuth 2.0 Authorization Framework (RFC 6749). IETF.
- OpenID Foundation. (2023). OpenID Connect Core 1.0. OpenID Foundation.
- OWASP. (2023). API Security Top 10. OWASP Foundation.
- Microsoft. (2024). Microsoft Entra External ID Architecture Guide. Microsoft Learn.
댓글
댓글 쓰기