10. CIAM에서 동의 관리가 중요한 이유와 설계 방법
CIAM(Customer Identity and Access Management)에서 동의 관리는 중요하지만, 한 가지 전제가 먼저 필요합니다. 모든 개인정보 처리가 동의를 필요로 하는 것은 아닙니다. 동의는 여러 법적 처리근거 중 하나이며, 서비스 계약 이행에 필요한 정보까지 관행적으로 “필수 동의”로 묶는 설계는 2026년 현재의 개인정보보호 제도 방향과 맞지 않을 수 있습니다.
따라서 현대적인 CIAM은 “동의를 얼마나 많이 받는가”보다 각 개인정보 처리 목적의 법적 근거를 먼저 구분하고, 동의가 필요한 경우에만 명확하게 수집·증명·철회·전파할 수 있는가를 중심으로 설계해야 합니다.
- 한국 개인정보보호법은 계약 체결·이행에 필요한 개인정보를 동의 없이 처리할 수 있는 법적 근거를 두고 있습니다.
- 동의가 필요한 경우에는 목적별로 구분하고, 선택 동의를 거부했다는 이유로 서비스 제공을 거절해서는 안 되는 경우가 있습니다.
- GDPR에서도 동의는 여러 lawful basis 중 하나이며, 유효한 동의는 freely given, specific, informed, unambiguous해야 하고 철회도 쉽게 할 수 있어야 합니다.
- 동의 시스템의 핵심은 체크박스가 아니라 Legal Basis Mapping → Evidence → Versioning → Withdrawal → Propagation → Audit입니다.
이 글은 CIAM 아키텍처를 위한 일반적 실무 가이드입니다. 특정 기업의 법적 의무는 처리 목적, 데이터 종류, 사업자 지위, 산업별 법률, 이용자 국가에 따라 달라질 수 있으므로 실제 서비스 적용 시 최신 법령과 전문 검토가 필요합니다.
1. 동의 관리의 출발점 — 동의가 항상 필요한 것은 아니다
기존 CIAM 설계에서 흔히 나타나는 문제는 개인정보를 수집할 때마다 “필수 동의” 체크박스를 추가하는 것입니다. 그러나 법적으로 중요한 것은 체크박스의 수가 아니라 왜 이 개인정보를 처리하는가입니다.
| 처리 상황 | 가능한 법적 근거 | CIAM 설계 의미 |
|---|---|---|
| 회원 서비스 제공에 필요한 기본 정보 | 계약 체결·이행에 필요한 처리 | 요건을 충족한다면 불필요한 “필수 동의”를 받지 않고 법적 근거를 투명하게 고지 |
| 선택적 마케팅 | 동의 또는 적용 법령상 허용되는 다른 근거 | 서비스 제공과 분리하고 명확한 선택권 제공 |
| 민감정보·고유식별정보 | 별도 법적 근거 필요 | 일반 계약 이행 근거만으로 충분하다고 단정하지 말고 해당 조문을 별도 확인 |
| 제3자 제공 | 제공에 관한 별도 법적 근거 필요 | 수집·이용과 제3자 제공을 같은 체크박스로 단순 결합하지 않음 |
Consent Management를 Legal Basis Management의 일부로 보는 것이 적절합니다. 먼저 목적별 처리근거를 정한 뒤, 동의가 법적 근거인 처리에 대해서만 동의 증적과 철회 흐름을 적용합니다.
2. 한국 개인정보보호법: 2026년 기준 핵심 포인트
2-1. 계약 이행에 필요한 정보는 동의 없이 처리할 수 있습니다
개인정보보호법 제15조제1항은 개인정보의 수집·이용에 여러 법적 근거를 두고 있습니다. 그중 하나가 정보주체와 체결한 계약을 이행하거나 계약 체결 과정에서 정보주체의 요청에 따른 조치를 이행하기 위해 필요한 경우입니다.
개인정보보호위원회도 2024년 동의제도 개편 이후, 회원서비스 운영이나 판매상품 A/S처럼 계약 체결·이행에 필요한 개인정보를 반드시 동의에 의존할 필요가 없다는 방향을 안내하고 있습니다. 2026년 현재 개인정보위는 개인정보 처리방침 작성지침(2026.4. 개정)을 현행 안내서로 제공하고 있습니다.
2-2. 동의를 받을 때는 각각 구분해야 합니다
법 제22조는 동의를 받을 때 각각의 동의 사항을 구분하고 정보주체가 명확하게 인지할 수 있도록 알릴 것을 요구합니다. 특히 수집·이용, 제3자 제공, 민감정보, 고유식별정보, 홍보·판매 권유 목적 등은 관련 조문에 따라 구분해 확인해야 합니다.
또한 선택적으로 동의할 수 있는 사항이나 일정한 홍보·판매 권유 동의를 하지 않았다는 이유만으로 서비스 제공을 거부해서는 안 되는 경우가 있습니다.
2-3. 동의 철회는 정보주체의 권리입니다
법 제37조에 따라 정보주체는 개인정보 처리에 대한 동의를 철회할 수 있고, 개인정보처리자는 법령상 예외가 없는 한 이에 필요한 조치를 해야 합니다. 따라서 CIAM에는 동의 수집 화면뿐 아니라 철회 경로와 후속 처리 흐름이 함께 설계되어야 합니다.
2-4. 만 14세 미만 아동
법 제22조의2에 따라 만 14세 미만 아동의 개인정보를 처리하기 위해 법상 동의를 받아야 하는 경우에는 법정대리인의 동의를 받고 그 동의 여부를 확인해야 합니다. 또한 아동에게 개인정보 처리 관련 사항을 알릴 때에는 이해하기 쉬운 양식과 언어를 사용해야 합니다.
2-5. 자동화된 결정 권리는 모든 RBA에 자동 적용되는 것이 아닙니다
법 제37조의2는 완전히 자동화된 시스템이 개인정보를 처리해 내린 결정이 정보주체의 권리 또는 의무에 중대한 영향을 미치는 경우, 일정한 조건 아래 거부권과 설명 요구권 등을 규정합니다.
따라서 로그인 위험점수나 MFA 요청 같은 모든 RBA(Risk-Based Authentication)를 곧바로 “자동화된 결정 거부권 대상”으로 단정해서는 안 됩니다. 실제 결정의 자동화 정도와 정보주체에게 미치는 법적·경제적 영향 등을 함께 검토해야 합니다.
2-6. 개인정보 전송요구권도 모든 CIAM에 동일하게 적용되지 않습니다
개인정보 전송요구권은 법 제35조의2와 관련 제도에 따라 적용되며, 모든 개인정보처리자에게 단순히 “JSON/CSV 다운로드 기능을 반드시 제공하라”는 구조가 아닙니다. 적용 대상 사업자와 데이터 범위, 전송 요건을 확인해야 합니다. 개인정보위는 2026년 6월 전 분야 마이데이터 개인정보 전송요구권 제도 안내서를 현행 안내서로 제공하고 있습니다.
개인정보보호법은 일정한 위반에 대해 전체 매출액의 3%를 초과하지 않는 범위의 과징금을 규정합니다. 다만 실제 산정에서는 시행령에 따라 위반행위와 관련 없는 매출액의 제외 등 세부 기준이 적용되므로, “동의 위반 = 곧바로 전체 매출 3%”처럼 단정해서는 안 됩니다.
3. GDPR: 동의의 유효요건과 철회
GDPR에서도 동의는 개인정보 처리의 유일한 법적 근거가 아닙니다. Article 6는 동의 외에도 계약 이행, 법적 의무, 생명·신체의 중대한 이익, 공익, 정당한 이익 등 여러 lawful basis를 규정합니다.
동의를 법적 근거로 사용할 경우에는 Article 4(11)과 Article 7의 요건을 충족해야 합니다.
| 요건 | 실무 의미 |
|---|---|
| Freely given | 거부하거나 철회해도 부당한 불이익이 없어야 함 |
| Specific | 서로 다른 처리 목적을 지나치게 포괄적으로 묶지 않음 |
| Informed | 무슨 데이터를 어떤 목적으로 처리하는지 이해할 수 있어야 함 |
| Unambiguous | 명확한 affirmative action이 필요하며 사전 체크나 침묵에 의존하지 않음 |
| Withdrawal | 동의 철회는 동의하기만큼 쉽게 할 수 있어야 함 |
| Accountability | 사업자가 유효한 동의를 받았음을 증명할 수 있어야 함 |
GDPR의 아동 관련 동의는 정보사회서비스를 아동에게 직접 제공하는 경우 Article 8이 적용되며 기본 연령은 16세입니다. 다만 회원국은 이를 13세까지 낮출 수 있으므로 실제 서비스 국가별 기준을 확인해야 합니다.
GDPR은 강한 개인정보 보호 체계를 갖고 있지만, 각 국가의 동의 연령, 전자광고 규칙, 민감정보, 국외이전, 제3자 제공 요건은 다를 수 있습니다. 글로벌 CIAM은 공통 통제기준을 만들고 국가별 gap analysis를 별도로 수행하는 것이 적절합니다.
GDPR의 기본원칙·동의조건·정보주체 권리 등을 위반한 일정한 사안은 Article 83에 따라 최대 2천만 유로 또는 전 세계 연간 매출액의 4% 중 더 높은 금액까지 행정벌의 상한이 규정되어 있습니다. 실제 제재 수준은 위반의 성격·기간·고의성 등 개별 사정에 따라 결정됩니다.
4. CIAM 동의 라이프사이클 재설계
기존의 “수집 → 저장 → 관리 → 철회” 4단계보다 한 단계 앞에 법적 근거 판단을 추가하는 것이 중요합니다.
| 단계 | 핵심 질문 | 실무 설계 |
|---|---|---|
| 1. Legal Basis | 왜 처리하는가 | 목적별로 동의·계약·법적 의무 등 처리근거를 매핑 |
| 2. Collection | 동의가 필요한가 | 필요한 경우에만 목적별·항목별로 명확한 동의 수집 |
| 3. Evidence | 무엇에 동의했는가 | 동의문 버전, 시점, 채널, 이용자 식별자와 당시 고지 내용을 재현 가능하게 저장 |
| 4. Change | 목적·항목·수신자 변경이 있는가 | 변경 내용이 기존 법적 근거를 벗어나는지 평가 |
| 5. Withdrawal | 철회 요청을 어떻게 처리할 것인가 | 동의 기반 처리 중단, 관련 시스템에 상태 전파, 예외 법적 근거가 있다면 별도 관리 |
| 6. Audit | 나중에 입증 가능한가 | 동의·철회·정책변경·시스템 반영 이력을 감사 가능하게 관리 |
5. 동의 유형보다 먼저 해야 할 Legal Basis Mapping
기존의 “서비스 필수 동의 / 선택 동의”만으로 분류하면 계약 이행에 필요한 정보까지 동의에 의존하는 문제가 생길 수 있습니다. 다음처럼 처리근거 중심으로 나누는 편이 정확합니다.
| 처리 유형 | 예시 | 설계 포인트 |
|---|---|---|
| 계약 이행 기반 처리 | 계정 생성, 주문 배송, A/S 접수 | 필요성 범위를 입증하고 처리방침에 법적 근거를 구분 표시 |
| 선택적 마케팅 동의 | 광고 이메일·SMS·푸시 | 서비스 이용과 분리하고 채널·목적을 명확히 관리 |
| 제3자 제공 관련 동의 | 제휴사에 개인정보 제공 | 제공받는 자·목적·항목·보유기간 등 법정 고지사항 확인 |
| 민감정보·고유식별정보 | 건강정보, 생체정보 등 | 일반 개인정보보다 엄격한 별도 법적 근거와 안전조치 확인 |
| 아동 동의 | 만 14세 미만 국내 이용자 | 동의가 필요한 처리라면 법정대리인 동의와 확인 절차 적용 |
6. 동의 저장소와 중앙화 아키텍처
중앙화된 Consent Service는 매우 유용한 패턴이지만 법이 특정 기술구조를 강제하는 것은 아닙니다. 중요한 것은 동의 상태에 대한 일관된 Source of Truth와 증적 가능성입니다.
- Legal Basis Registry: 처리 목적별 법적 근거, 데이터 항목, 국가·서비스 범위
- Consent Store: 동의·철회·버전 이력을 추적 가능한 형태로 저장
- Consent / Preference API: 조회·수집·철회·환경설정 변경 기능
- Event Publisher: 동의 변경을 CRM·마케팅·분석 시스템에 전파
- Preference Center: 이용자가 동의와 환경설정을 직접 확인·변경
- Audit View: 특정 시점의 동의 상태와 당시 고지 내용을 재현
저장 방식도 “INSERT만 가능하고 UPDATE/DELETE는 절대 금지”라는 하나의 구조만 정답은 아닙니다. Append-only event log, versioned record, tamper-evident audit log 등 여러 방식이 가능하며, 삭제의무와 증적보존 의무 사이의 관계도 데이터 종류별로 설계해야 합니다.
7. 약관·처리방침 변경과 재동의
약관이나 개인정보 처리방침이 변경됐다고 해서 항상 기존 이용자 전체에게 재동의를 받아야 하는 것은 아닙니다.
| 변경 상황 | 검토 방향 |
|---|---|
| 표현·오탈자 수정 | 통상 재동의보다 버전·변경이력 관리 중심 |
| 기존 법적 근거 내 설명 변경 | 통지·공개 의무를 검토하되 자동으로 재동의 대상으로 단정하지 않음 |
| 새로운 처리 목적 추가 | 기존 법적 근거로 가능한지 평가하고, 동의가 필요하다면 별도 동의 수집 |
| 제3자 제공 대상·목적 변경 | 제17조 등 해당 법적 근거와 고지·동의 요건을 재검토 |
| 민감정보 등 신규 처리 | 별도 법적 근거와 추가 보호조치 검토 |
핵심: “개인정보처리방침 버전이 바뀌었다 = 모두 재동의”가 아니라, 실제 처리 목적·범위·법적 근거가 바뀌었는지를 먼저 판단해야 합니다.
8. 동의 철회와 연동 시스템 전파
동의 철회는 단순히 Consent DB의 값을 바꾸는 것으로 끝나지 않습니다. 동의를 법적 근거로 사용하던 처리활동이 실제로 중단되도록 관련 시스템에 상태가 전달되어야 합니다.
- 이용자가 Preference Center 또는 동일 수준의 쉬운 채널에서 동의 철회
- CIAM이 철회 시점과 대상 목적을 기록
- 관련 시스템에 철회 이벤트 또는 API 업데이트 전파
- 마케팅·개인화 등 동의에 의존하던 처리를 중단
- 전파 실패 시스템은 재처리 큐와 운영 알림으로 관리
- 감사 로그에서 시스템별 반영 상태 확인
한국 개인정보보호법은 동의 철회에 따른 조치를 지체 없이 수행하는 구조를 두고 있고, GDPR은 동의 철회를 언제든 할 수 있으며 철회가 동의만큼 쉬워야 한다고 규정합니다. “수 초”, “24시간” 같은 하나의 법정 공통 기준은 아니므로, CIAM은 시스템 중요도에 따라 조직별 Propagation SLO를 정의하는 편이 적절합니다.
| 시스템 유형 | SLO 설계 예시 |
|---|---|
| 광고·메시징 시스템 | 다음 발송 대상 생성 전 철회가 반영되도록 짧은 전파 SLO 설정 |
| CRM | 상담·캠페인 실행 전에 최신 동의 상태를 확인하도록 설계 |
| 분석 플랫폼 | 동의 철회 이후 허용되지 않는 신규 처리가 발생하지 않도록 배치·스트리밍 주기에 맞춘 통제 |
9. 동의 UX와 Dark Pattern
법적으로 유효한 동의는 이용자가 충분히 이해하고 실제 선택할 수 있어야 합니다. GDPR에서 사전 체크된 박스, 침묵, 단순 inactivity는 명확한 동의로 보기 어렵습니다.
| UX 원칙 | 피해야 할 설계 | 권장 설계 |
|---|---|---|
| 명확한 선택 | 선택사항을 기본 체크 | 동의가 필요한 선택사항은 명확한 affirmative action으로 수집 |
| Granularity | 서로 다른 목적을 하나의 동의로 묶음 | 법적으로 구분이 필요한 목적을 분리 |
| 철회 용이성 | 가입은 앱에서 가능하지만 철회는 전화만 가능 | 동의를 받은 것과 유사한 수준의 쉬운 경로 제공 |
| 선택 동의 보호 | 마케팅 동의 거부를 이유로 핵심 서비스 차단 | 법상 선택 동의라면 불필요한 서비스 불이익을 주지 않음 |
| Plain Language | 법률용어만 나열 | 핵심 목적과 영향을 이해하기 쉬운 표현으로 설명 |
10. 감사·규제 대응 체크리스트
- ☐ 각 개인정보 처리 목적의 법적 근거가 기록되어 있는가
- ☐ 동의 없이 처리하는 개인정보와 동의 기반 개인정보가 구분되어 있는가
- ☐ 동의가 필요한 경우 당시 동의문 버전·목적·항목·시점·채널을 재현할 수 있는가
- ☐ 선택 동의를 거부한 이용자에게 부당한 서비스 제한이 발생하지 않는가
- ☐ 동의 철회 후 관련 시스템의 처리 중단 상태를 확인할 수 있는가
- ☐ 만 14세 미만 아동의 동의가 필요한 경우 법정대리인 동의·확인 절차가 있는가
- ☐ 자동화된 결정이 정보주체 권리에 중대한 영향을 미치는 경우 제37조의2 적용 여부를 검토했는가
- ☐ 개인정보 전송요구권 적용 대상 사업자·데이터인지 별도 판단했는가
- ☐ 개인정보 처리방침과 실제 시스템의 법적 근거·데이터 흐름이 일치하는가
- ☐ 국가별 GDPR·한국법·기타 지역 규제 gap analysis를 운영하고 있는가
정리
CIAM의 동의 관리는 “동의 체크박스를 더 많이 추가하는 것”이 아닙니다. 가장 먼저 각 개인정보 처리활동의 법적 근거를 분류하고, 동의가 필요한 경우에만 유효한 동의를 받고, 그 동의를 증명하고, 이용자가 쉽게 철회할 수 있게 하며, 철회가 실제 연결 시스템에 반영되도록 만드는 것이 핵심입니다.
모든 처리에 동의를 받는 시스템이 아니라,
언제 동의가 필요한지 정확히 구분하고
그 선택을 끝까지 존중할 수 있는 시스템입니다."
- 국가법령정보센터 — 개인정보 보호법
- 개인정보보호위원회 — 현행 개인정보 안내서 목록
- 개인정보보호위원회 — 개인정보 필수동의 관행 개선
- EUR-Lex — Regulation (EU) 2016/679 (GDPR)
- EDPB — Guidelines 05/2020 on consent
※ 2026년 9월 검토. 법령·가이드라인은 개정될 수 있으므로 실제 적용 전 최신 버전을 다시 확인하십시오.
Reviewed: September 2026. 개인정보 처리의 법적 근거와 동의 요건을 구분하고, 한국 개인정보보호법·GDPR 공식 자료 중심으로 재작성했습니다.
Comments
Post a Comment