1. 개인정보보호법과 법 체계

우리나라 법 체계에서 개인정보보호법은 개인정보 보호 분야의 일반법에 해당합니다.
즉, 개인정보 보호와 관련된 기본 원칙과 일반적인 처리 기준을 정하는 법입니다.

다만 모든 경우에 개인정보보호법만 적용되는 것은 아닙니다.
다른 법률에 개인정보 처리에 관한 특별한 규정이 있는 경우에는 해당 법률이 우선 적용됩니다.

예를 들어 의료, 감염병, 농축산, 금융, 이동통신, 암관리 등 특정 분야에서는 각 분야의 개별 법령이 가명정보 처리와 관련된 별도 기준을 둘 수 있습니다.

2. 개인정보보호법과 다른 법률의 관계

개인정보보호법은 사회 전반의 개인정보 보호를 규율하는 일반법입니다.
적용 대상은 공공기관, 사업자, 법인, 단체, 개인 등 매우 넓습니다.

하지만 다른 법률에 특별한 규정이 있으면 그 법률을 우선 적용합니다.

예시로는 다음과 같은 법률이 있습니다.

분야관련 법률 예시

즉, 가명정보 처리는 개인정보보호법을 기본으로 하되, 분야별 특수 법령을 함께 확인해야 합니다.

3. 의료법과 개인정보보호법의 관계

의료 분야에서는 의료법이 우선 적용되는 경우가 있습니다.

의료기관이 보유한 환자 관련 기록은 의료법상 보호 대상이기 때문에, 의료인이 환자에 관한 기록을 열람하거나 제공하는 경우에는 의료법 규정을 우선 확인해야 합니다.

그러나 의료법에서 명확하게 규정하지 않은 사항은 개인정보보호법을 적용할 수 있습니다.

예를 들어, 진료기록을 연구 목적으로 활용하려는 경우에도 단순히 개인정보보호법상 가명처리만으로 충분한 것이 아니라, 의료법상 환자 기록 제공 제한 규정을 함께 검토해야 합니다.

핵심은 다음과 같습니다.

의료정보는 민감성이 높기 때문에 개인정보보호법뿐 아니라 의료법, 생명윤리법 등 관련 법률을 함께 고려해야 한다.

4. 데이터3법 외 가명정보 처리 관련 법령

교안에서는 개인정보보호법 외에도 여러 법률에서 가명정보 처리 관련 규정을 두고 있음을 설명합니다.

대표적으로 다음과 같은 법령들이 제시됩니다.

4-1. 데이터기반행정 활성화에 관한 법률

공공기관은 데이터기반행정을 위해 데이터를 처리할 수 있습니다.
이때 필요한 경우 개인정보를 가명처리하여 활용할 수 있습니다.

주요 내용은 다음과 같습니다.

• 공공기관은 정책 수립, 행정 개선, 공공서비스 제공 등을 위해 데이터를 활용할 수 있음
• 개인정보가 포함된 경우 개인정보보호법에 따라 가명처리 가능
• 가명정보는 통계작성, 과학적 연구, 공익적 기록보존 등의 목적에 활용 가능

4-2. 감염병의 예방 및 관리에 관한 법률

감염병 분야에서는 질병관리청 등이 감염병 예방과 관리, 정보 분석 및 연구를 위해 정보를 처리할 수 있습니다.

감염병 정보에는 민감한 건강정보가 포함될 수 있으므로, 필요한 경우 개인정보를 가명처리하여 활용할 수 있습니다.

주요 활용 목적은 다음과 같습니다.

• 감염병 예방
• 감염병 관리
• 감염병 정보 분석
• 공중보건 연구
• 감염병 확산 방지

다만 감염병 정보는 개인의 건강상태와 직결되기 때문에 안전조치와 목적 제한이 매우 중요합니다.

4-3. 농수산물 유통 및 가격안정 관련 법령

농축산 분야에서도 가명정보 처리가 활용될 수 있습니다.

예를 들어 축산물 유통, 농가 정보, 생산 및 거래 정보 등을 분석할 때 개인정보가 포함될 수 있습니다.
이 경우 개인정보를 가명처리하여 통계나 연구 목적으로 활용할 수 있습니다.

주요 활용 목적은 다음과 같습니다.

• 농수산물 유통 분석
• 가격 안정 정책 수립
• 생산 및 공급 현황 파악
• 축산물 이력 관리
• 공익적 연구 및 통계작성

4-4. 디지털 기반 원격교육 활성화 기본법

원격교육 분야에서도 학생의 학습 데이터가 활용될 수 있습니다.

예를 들어 학습이력, 접속기록, 과제 수행, 평가 결과 등은 교육 개선과 학습 지원에 중요한 데이터입니다.

그러나 학생 정보는 개인정보에 해당할 수 있으므로, 교육 연구나 정책 개선을 위해 활용할 때는 가명처리가 필요할 수 있습니다.

주요 활용 목적은 다음과 같습니다.

• 원격교육 운영 개선
• 학습 성취도 분석
• 교육격차 분석
• 학습지원 정책 수립
• 교육 콘텐츠 품질 개선

4-5. 사회보장기본법

사회보장 분야에서는 복지 서비스 제공과 정책 분석을 위해 다양한 개인정보가 처리됩니다.

예를 들어 복지급여, 소득, 가구구성, 건강, 고용상태 등 민감한 정보가 포함될 수 있습니다.

이러한 정보는 사회보장 정책 수립과 서비스 개선을 위해 활용될 수 있지만, 개인정보 보호를 위해 가명처리가 필요합니다.

주요 활용 목적은 다음과 같습니다.

• 사회보장 정책 수립
• 복지 사각지대 분석
• 서비스 대상자 분석
• 복지급여 제공 현황 분석
• 사회보장제도 개선 연구

4-6. 이동통신 관련 법령

이동통신 분야에서는 위치정보, 통신 이용 정보, 서비스 이용 정보 등이 활용될 수 있습니다.

이러한 정보는 개인을 식별하거나 생활 패턴을 추정할 수 있기 때문에 보호 필요성이 높습니다.

따라서 연구나 통계 목적의 활용 시 가명처리 또는 익명처리가 필요합니다.

주요 활용 목적은 다음과 같습니다.

• 통신서비스 품질 개선
• 이용자 행태 분석
• 위치 기반 서비스 연구
• 재난 대응 및 공익 목적 분석
• 통신 인프라 개선

4-7. 암관리법

암관리법에서는 암 연구와 암 관리사업을 위해 관련 정보를 처리할 수 있습니다.

암 환자 정보는 매우 민감한 건강정보에 해당하므로, 연구 목적 활용 시 가명처리가 중요합니다.

주요 활용 목적은 다음과 같습니다.

• 암 발생 원인 연구
• 암 예방 정책 수립
• 암 환자 생존율 분석
• 암 치료 성과 분석
• 국가 암관리사업 개선

5. 분야별 가명처리 절차 설명

교안의 후반부는 분야별 가명처리 절차를 설명합니다.
특히 적합성 검토, 적정성 검토, 데이터심의위원회, 적정성평가위원회 등의 개념이 중요합니다.

5-1. 적합성 검토

적합성 검토는 가명처리 절차 중 사전 준비 단계에서 수행하는 업무입니다.

즉, 가명정보를 만들기 전에 해당 처리가 법적으로 가능한지, 목적이 정당한지, 신청 내용이 적절한지 확인하는 단계입니다.

검토 내용은 다음과 같습니다.

• 가명정보 신청의 적합성
• 활용 목적의 적정성
• 법령상 허용 가능성
• 제공 또는 결합 가능 여부
• 필요한 절차 준수 여부

“이 데이터를 가명처리해서 활용해도 되는가?”를 먼저 판단하는 절차입니다.

5-2. 적정성 검토

적정성 검토는 가명처리가 완료된 후 수행하는 절차입니다.

가명처리 결과가 안전한지, 재식별 위험이 낮은지, 활용 목적에 비해 과도한 정보가 포함되지 않았는지를 확인합니다.

주요 검토 내용은 다음과 같습니다.

• 가명처리 수준이 적절한지
• 재식별 가능성이 낮은지
• 목적 달성에 필요한 정보만 남아 있는지
• 안전조치가 충분한지
• 가명처리 결과를 제공해도 되는지

“가명처리 결과물이 안전하고 적절한가?”를 확인하는 절차입니다.

5-3. 데이터심의위원회

데이터심의위원회는 가명처리 과정에서 적합성 검토를 수행하는 조직입니다.

교안에서는 보건의료 분야의 경우, 데이터 심의위원회가 기관 내에서 구성되어 데이터 활용 신청의 적합성과 제공 여부 등을 심의하는 구조를 설명합니다.

주요 역할은 다음과 같습니다.

• 데이터 활용 신청 심의
• 가명처리 여부 결정
• 활용 목적의 적합성 판단
• 제공 가능 여부 판단
• 데이터 활용 범위 검토

위원회는 객관성과 전문성을 확보하기 위해 일정 기준을 충족하는 위원들로 구성됩니다.

5-4. 적정성평가위원회

적정성평가위원회는 가명처리 결과의 적정성을 평가하는 조직입니다.

즉, 가명처리된 정보가 안전한지, 재식별 위험이 관리 가능한 수준인지 검토합니다.

주요 역할은 다음과 같습니다.

• 가명정보 또는 익명정보 산출 적정성 평가
• 재식별 가능성 검토
• 가명처리 수준 평가
• 안전조치 여부 확인
• 활용 또는 제공 가능 여부 판단

정리하면, 데이터심의위원회가 처리 전 적합성을 본다면, 적정성평가위원회는 처리 후 결과의 안전성을 본다고 이해하면 됩니다.

6. 공공분야 가명처리 절차

공공분야의 가명처리 절차는 대체로 다음 순서로 진행됩니다.

1. 가명정보 제공 신청
2. 신청서 접수
3. 위험성 검토
4. 가명처리
5. 적정성 검토
6. 안전한 관리
7. 제공 결정 또는 제공 거부

이 절차에서 중요한 것은 신청 단계부터 최종 제공 단계까지 모든 과정에서 목적의 적합성, 법적 근거, 재식별 위험, 안전조치가 함께 검토된다는 점입니다.

7. 보건의료 분야 가명처리 절차

보건의료 분야는 민감정보를 다루기 때문에 절차가 특히 엄격합니다.

7-1. 내부 활용 절차

의료기관 내부에서 데이터를 활용하는 경우, 예를 들어 병원 내 연구나 내부 분석을 위해 데이터를 사용하는 경우에는 다음 절차를 거칩니다.

1. 데이터 활용 신청서 작성 및 제출
2. 심의위원회 심의
3. 가명처리 방법 및 활용 범위 결정
4. 가명처리 실시
5. 가명처리 적정성 검토
6. 데이터 분석 또는 연구 수행
7. 데이터 수정 또는 보완

내부 활용이라 하더라도 동일 목적 또는 동일 유형의 데이터라고 해서 무조건 자유롭게 활용할 수 있는 것은 아닙니다.
기존 처리 목적과의 관련성, 활용 목적의 적정성, 가명처리 수준 등을 검토해야 합니다.

7-2. 외부 결합 절차

A병원, B병원, C병원이 각각 보유한 정보를 결합하여 연구하려는 경우에는 외부 전문기관 또는 결합전문기관이 개입합니다.

절차는 다음과 같이 이해할 수 있습니다.

1. 각 병원 또는 기관이 데이터 활용 신청서 작성
2. 데이터 활용 연구 자료 검토
3. 심의위원회 심의
4. 결합전문기관에 신청서 제출
5. 데이터 제출
6. 결합 적정성 검토
7. 결합 수행
8. 반출 심의
9. 결합 데이터 활용

이 경우 여러 기관의 데이터가 결합되므로 재식별 위험이 커질 수 있습니다.
따라서 결합전문기관의 역할과 반출 심의가 중요합니다.

8. 금융 분야 가명처리 절차

금융 분야에서는 신용정보법과 관련하여 데이터 결합 및 가명처리 절차가 설명됩니다.

금융 데이터는 개인의 신용, 거래, 소비, 자산, 대출 정보 등 민감한 정보를 포함할 수 있으므로 엄격한 절차가 필요합니다.

8-1. 결합신청 기관과 데이터전문기관

금융 분야에서는 데이터 결합을 위해 결합신청 기관과 데이터전문기관이 등장합니다.

결합신청 기관은 데이터를 결합하려는 기관이고, 데이터전문기관은 결합 절차를 수행하거나 지원하는 기관입니다.

주요 절차는 다음과 같습니다.

1. 결합 신청
2. 가명처리
3. 결합신청서 제출
4. 결합키 생성
5. 결합키 전달
6. 정보집합물 전달
7. 데이터 설명회
8. 정보집합물 결합
9. 가명처리 또는 익명처리
10. 적정성 평가
11. 결합정보 전달
12. 관련 파일 완전 파기
13. 결합정보 활용 및 사후관리

8-2. 데이터 설명회

데이터 설명회는 데이터전문기관이 결합할 정보집합물의 구조와 특성을 이해하고, 가명처리 수준을 확인하기 위해 진행됩니다.

주요 목적은 다음과 같습니다.

• 데이터 구조 파악
• 가명처리 수준 확인
• 결합 데이터의 특성 이해
• 결합 과정에서 필요한 사항 확인
• 데이터 명세 확인

즉, 단순히 데이터를 결합하기 전에 데이터의 의미와 위험성을 충분히 이해하는 절차입니다.

8-3. 적정성 평가

금융 분야의 적정성 평가는 데이터전문기관이 결합 결과물을 제공하기 전에 수행하는 절차입니다.

평가 내용은 다음과 같습니다.

• 가명처리 또는 익명처리 수준
• 재식별 가능성
• 데이터 활용 목적
• 결합정보 이용기관의 재식별 의도 및 능력
• 개인정보 보호 수준
• 반출 가능 여부

즉, 결합된 데이터가 외부로 제공되거나 활용되기 전에 충분히 안전한지 검토하는 단계입니다.

9. 보건의료 분야와 금융 분야 절차 비교

구분보건의료 분야금융 분야

개인정보 저장.관리 개요

필요성)

개인정보처리자는 수집.이용을 위해 저장 중인 개인정보를 안전하게 관리해야 함

개인정보 유출 사고는 추가적 오남용으로 이어질 수 있음

법적 근거)

제3조(개인정보 보호 원칙)

제29조(안전조치의무)

안전 관리 주요 대상)

개인정보취급자: 임직원, 파견근로자, 시간제근로자 등 개인정보처리자의 지휘.감독을 받음

개인정보처리시스템: 개인정보 처리할 수 있도록 체계적으로 구성한 시스템

• 대부분 다크웹을 중심으로 개인정보의 유출 및 불법적인 거래가 이루어진 사례들을 확인할 수 있음

안전성 확보조치 주요내용

개인정보 내부관리계획)

전사 규정으로 마련 CEO 등 최고경영층 내부 결재 등 승인

접근 권한의 안전한 관리)

필요성: 대형 개인정보 유출사고의 시작은 관리자 권한의 획득에서 시작

-접근 권한의 안전한 관리가 매우 중요

접근권한의 안전한관리)

1. 차등 부여

2. 접근권한 변경 또는 말소

3. 기록 최소 3년보관

4. 공유금지

5. 인증수단 안전 적용

6. 인증 실패 시 접근 제한

접근 통제)

1. 방화벽 등 침입차단 탐지 시스템 구축 및 운영

2. 외부에서 시스템 접속 시 OTP 등 안전한 인증 수단 적용

3. 인터넷 홈페이지, P2P, 공유 설정 등을 통한 공개 및 유출 방지 조치

4. 일정시간 시스템 미접속 시 자동 접속 차단 등 조치

5. 업무용 모바일 기기.분실.도난 등으로 인한 유출 방지 위해 모바일기기 비밀번호 설정 등 조치

6. 인터넷망 차단(구 망분리) 적용

법적 주요 암호화 대상 및 절차)

-정보통신망을 통한 개인정보 송수신시 암호화

-비밀번호 일방향 암호화 저장

-이용자 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호, 신용카드번호, 계좌번호, 생체인식정보

-대규모 개인정보 처리 시 안전한 암호키 관리 절차 수립.시행

접속기록의 보관.점검)

접속기록: 식별자, 접속일시, 접속자 정보, 처리한 정보주체 정보, 수행업무 등을 전자적으로 기록

<법적 의무 사항>

1. 개인정보취급자의 개인정보처리시스템에 대한 접속기록을 2년 이상 보관.관리

2. 접속기록 등을 주기적으로 점검(특히 다운로드 사유 확인)

3. 접속기록 안전 보관 조치(별도 저장매체에 분리보관 등)

<개인정보취급자 유의사항>

접속 기록 소명 요청 대응

다운로드 최소화 및 필요시 사유 입력

개발자: 접속기록 생성 및 다운로드 시 사유 입력 기능 마련 등

악성프로그램)

<법적 의무 사항>

보안프로그램 설치 운영

물리적 안전조치)

필요성: 개인정보 저장하는 물리적 보관장소를 별도로 두고 있는 경우 비인가자의 출입 등으로 인한 개인정보의 유출 등을 방지

재해.재난 대비 안전조치)

적용 대상: 

-10만 명 이상의 개인정보를 처리하는 대기업.중견기업.공공기관

-100만 명 이상의 정보주체에 관하여 개인정보를 처리하는 중소기업.단체

출력.복사 시 안전조치)

1. 개인정보 출력 시 용도 특정하며, 용도에 따라 출력 항목을 최소화

2. 안전하게 관리

개인정보 파기)

<법적 의무 사항>

1. 개인정보 파기 방법

• 완전파괴(소각, 파쇄 등)
• 전용 소자장비를 이용하여 삭제
• 데이터가 복원되지 않도록 초기화 또는 덮어쓰기 수행

2. 개인정보 일부만을 파기

-전자적 파일: 개인정보를 삭제한 후 복구 및 재생되지 않도록 관리.감독

-기록물, 인쇄물, 서면, 그 밖의 기록매체인 경우: 해당 부분을 마스킹, 구멍 뚫기 등으로 삭제

3. 기술적 특성으로 파기가 현저히 곤란한 경우에는 법: 익명처리가능

개인정보취급자 실천수칙)

1. 개인정보 내부 관리계획 확인

2. 1인 1계정, 공유 금지

3. 불필요한 접근 권한 즉시 반납

4. 소명 요청 적극대응하기

5. 개인정보의 화면.문서 출력은 용도에 맞게 최소화하기

6. 잠금장치가 있는 안전한 곳에 보관하기

7. 불필요한 개인정보 파일 즉시 파기하기

8. 개인정보 저장 파일은 반드시 비밀번호 설정 혹은 암호화 저장하기

9. 개인정보 유출 사고 대응 훈련-적극 참여

10. 이상징후 발생시 즉시 개인정보보호 조직에 공유하기

1) 해당 페이지 범위의 제목, 소제목, 표/차트/키워드만 먼저 훑어보기

정보주체의 권리

• Right to erasure(삭제권/잊힐 권리), Right to be informed(정보를 받을 권리)
• 각 권리별 유사점과 차이점을 비교한 표
• 주요 키워드: Right to erasure, Right to be informed, Privacy Policy, Consent

2) 문단별로 빠르게 훑으며 주요 결론/차이점만 한국어로 적기

표 형식 부분은 GDPR/PIPA/Differences 열을 먼저 한국어로 요약

• 주요 결론: 두 법 모두 동의 철회나 수집 목적 달성 시 정보주체가 자신의 데이터를 삭제해달라고 요청할 수 있는 권리를 인정합니다.
• 주요 차이점:
  • 대응 기간: GDPR은 1개월 내에 대응해야 하나, PIPA는 훨씬 짧은 10일 이내에 대응해야 합니다.
  • 비용: GDPR은 원칙적으로 무료이나, PIPA는 실비 범위 내에서 수수료 및 우편 요금을 청구할 수 있습니다.
  • 공개된 데이터: GDPR은 컨트롤러가 공표한 데이터에 대한 삭제 조치 의무를 구체적으로 규정하지만, PIPA에는 관련 별도 규정이 없습니다.

• 주요 결론: 두 법 모두 개인정보 수집 시 처리 목적 등을 정보주체에게 알려야 할 의무를 부여합니다.
• 주요 차이점:
  • 권리의 성격: GDPR은 이를 독립적인 개별 권리로 명시하는 반면, PIPA는 동의 획득 과정 및 개인정보 처리방침 공개 의무를 통해 이를 실현합니다.
  • 고지 내용: PIPA는 특히 동의를 거부할 권리가 있다는 사실과 동의 거부 시의 불이익을 반드시 고지하도록 요구합니다.
  • 제3자 수집: GDPR은 제3자로부터 데이터를 수집한 경우 한 달 이내에 고지해야 하지만, PIPA는 일정 기준 이상의 데이터 처리자에게만 3개월 이내 고지 의무를 부여합니다.

[주요 차이점]

3) 핵심 문장 2~3개는 직접 영어로 요약해서 노트에 쓰기

• While both laws recognize the right to erasure, PIPA mandates a much stricter response timeline of 10 days, compared to the one-month period allowed under the GDPR.
• The GDPR treats the right to be informed as a standalone right, whereas PIPA ensures this right through mandatory disclosures during the consent process and in public privacy policies

4)

페이지에서 나온 중요한 법률 영어 단어 선택

간단하게 영어로 정의 작성, 한국어로 정의 작성

• Right to erasure
  • The right of a data subject to request the deletion of their personal data by the controller.
  • 정보주체가 컨트롤러에게 자신의 개인정보 삭제를 요청할 수 있는 권리 (삭제권/잊힐 권리).
• Privacy Policy
  • A formal document that explains how an organization collects, uses, and protects personal information.
  • 조직이 개인정보를 어떻게 수집, 이용, 보호하는지 설명하는 공식 문서 (개인정보 처리방침).
• Undue delay
  • Acting without any unnecessary or excessive postponement.
  • 불필요하거나 과도한 지연 없는 상태 (부당한 지체 없음).

5)

한글로 3문장 요약→영어로 3문장 요약 바꿔쓰기

스스로에게 공부한 내용 관련해서 1개의 질문을 영어로 해보기

그리고, 스스로 답변 작성

1. GDPR과 PIPA는 정보주체의 삭제권과 정보를 받을 권리를 공통적으로 보장하고 있습니다.
2. 하지만 삭제권 대응 기간에 있어 PIPA(10일)는 GDPR(1개월)보다 훨씬 신속한 처리를 요구하며, 수수료를 부과할 수 있다는 점에서도 차이가 있습니다.
3. 정보를 받을 권리의 경우, PIPA는 정보주체가 동의를 거부할 때 겪게 될 불이익을 명확히 알리도록 강제하는 특징이 있습니다.

1. Both the GDPR and PIPA guarantee individuals' right to erasure and the right to be informed.
2. However, PIPA requires a much faster response for erasure requests (10 days) than the GDPR (one month) and permits charging fees.
3. Regarding the right to be informed, PIPA specifically mandates disclosing the disadvantages a data subject might face for refusing consent.

• Question: According to the sources, how does the cost of exercising the "right to erasure" differ between the GDPR and PIPA?
• Answer: Under the GDPR, the right to erasure is generally exercised free of charge, whereas PIPA allows data handlers to charge a processing fee and postage to the data subject.

가이드 < 자료마당 < 금융보안원

내부업무망 SaaS 이용

정의: 금융회사 등이 내부업무망(망분리 환경)에서 인터넷 구간에 위치한 SaaS를 업무 목적으로 안전하게 연계.이용하는 것을 의미

주요 규제 개선 내용

제2조의3(망분리 적용 예외)

3. 이용자의 고유식별정보 또는 개인정보를 처리하지 않는 [클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률 시행령] 제3조제2호에 따른 "응용프로그램 등 소프트웨어를 제공하는 서비스" 이용 목적의 경우

-별표 7. 망분리 대체 정보보호통제를 적용

-망분리 대체 정보보호대체의 이행 여부를 반기에 1회 평가하고 정보보호위원회에 보고하여야 한다.

• 망분리 예외에 따른 보안성 확보를 위해 SaaS 특화 망분리 대체 정보보호통제 적용 및 정보보호위원회 승인 필요

내부업무망 SaaS 이용 시 발생 가능한 보안 위협

내부업무망 SaaS 이용 시 발생 가능한 보안 위협

• 내부업무망에서 SaaS 이용 시 SaaS 서비스 취약점, 인프라 장애.프로그램 오류, SaaS 이용자의 보안 설정 미흡 등으로 인해
• 내부업무망으로 침해위협 전파, 업무 중단. 서비스 장애, SaaS 중요정보 유출, 데이터 변조.유실, 규제준수 위험 등의 보안위협 예상

금융회사 등은 SaaS 이용에 따른 예상되는 보안 위협을 식별하고,

규정 및 내부 보안정책, 보안해설서, 가이드 등에 근거하여 안전한 SaaS 도입을 위한 보안 통제를 수립.적용해야 함

SaaS 제공자 보안 위협

침해위협 내부 전파: 취약점 악용, 계정 권한을 획득한 후 제공자 시스템을 통해 금융회사에 악성코드 유포

업무 중단.서비스 장애: SaaS 제공자의 클라우드 인프라 장애 또는 소프트웨어 업데이트 오류.결함으로 인한 서비스 지연.장애로 내부업무 영향

중요정보 유출.데이터 변조: 제공자의 관리자나 운영 인력이 권한을 오남용하여 금융회사 중요정보를 무단 열람하거나 변조

규제준수 위험: 국외 소재 제공자와 서비스 이용 계약 시 국내 규정 준수 및 의무 이행 협조 조항 누락

SaaS 이용자 보안 위협

침해위협 내부 전파: 단말.계정 관리가 미흡하여 관리자 권한이 탈취되거나 내부 시스템으로 악성코드 감염.전파

업무중단.서비스 장애: SaaS 운영.관리 미흡으로 데이터 유실 및 업무 지연이 발생할 수 있으며, SaaS 이용망과 대고객망을 혼용하는 경우 서비스 장애에 취약

중요정보 유출: 로그 수집.탐지 규칙 및 점검절차 부재, 과도한 공유.접근 권한 허용 등 보안통제가 미흡한 경우 위협이 식별되지 않거나 정보유출 등 피해 확산

데이터 변조.유실: 설정 변경 모니터링, 관리자 계정 인증, 전송 구간 암호화 등이 미흡한 경우 데이터 무결성 훼손, 중간자 공격으로 피해 확산

내부업무망 SaaS 이용 보안관리 방안

도입절차

1. SaaS 활용 범위 판단: 조직 내에서 활용 목적과 범위, 데이터 연계방식 등 판단

구체적인 업무 수행 범위는 금융회사에서 자율적으로 정의

업무 목적에 부합하는 SaaS를 선별하여 도입

2. 자체 위험성 평가: 사용과 관련된 위험을 식별하고 평가

자사의 업무 환경 고려. 자체 위험성 평가를 실시

-예상되는 보안 위협을 빠짐없이 식별하고 위협에 대한 위험성을 평가

3. 망분리 대체 통제 적용: 규정 및 시행세칙, 관련 메뉴얼을 참조하여 위협 모니터링 및 조치방안 수립

위험성 평가 결과를 토대로 규정.시행세칙, SaaS 메뉴얼을 참조. 자사환경에 적절한 보안 통제 방안 수립

-SaaS 보안 위협에 따른 모니터링 조치 방안을 수립, SaaS 특화 [망분리 대체 정보보호 통제]를 적용

-금융 회사 등은 자사의 업무 환경 등을 고려하여 필요시 추가 보호대책을 적용

4. 정보보호위원회 의결: 위험성 평가 결과와 보호대책의 적정성 심의 및 의결

망분리 예외에 따른 자체 위험성 평가 결과, 적용된 보호대책의 적정성 등에 대해 정보보호위원회 의결

-자체 위험성 평가를 통해 도출된 보안위험이 보안대책 적용 등을 통해 충분히 완화되었는지 검토

정보보호위원회 의결 이후 망분리 대체 정보보호통제의 이행여부를 반기에 1회 평가하고 정보보호위원회에 보고

-내부업무망 SaaS 이용에 대한 정기적인 위험성 평가 실시 권고

(*연 1회 보안점검 실시 등)

-내부업무망 추가 이용 및 대상.범위 변경, 주요기능의 추가.변경으로 인한 보호대책의 중대한 변경있는 경우 정보보호위원회의 심의.의결 재수행 필요

• 금융회사 등은 기존 클라우드 이용 절차 또한 준수해야 하며, 내부업무망 SaaS 이용을 포함한 클라우드 이용에 관한 보고의무 이행 필요([금융분야 클라우드컴퓨팅서비스 이용 가이드] 참조

내부업무망 SaaS 제공자 평가

1. 평가개요

-내부업무망 [망분리 대체 정보보호통제] 적용을 지원하기 위해 침해사고대응기관은 클라우드서비스 제공자에 대한 안전성 평가를 대표로 수행하고 결과 공유

(*침해사고대응기관의 평가결과 충족을 획득한 SaaS 이용)

2. 평가결과

SaaS 적용 필수 항목을 기준으로 하는 평가 결과 공유

3. 평가 결과 활용

SaaS 적용 필수 항목이 모두 충족인 경우 평가 결과를 내부업무망 SaaS 망분리 적용 예외에 따른 정보보호위원회 심의.의결 자료로 활용

또한, [전자금융감독규정] 클라우드 이용 보고 의무 이행 시 클라우드서비스 제공자 안전성 평가 결과의 일부로 활용 가능

클라우드서비스 제공자의 안전성이 저하되지 않도록 평가관련 서류를 최신 상태로 유지

내부업무망 SaaS 이용 보안대책

1. 단말 보호

• 비인가 SaaS 단말기 접속 통제
  • 단말 보안: 인가 체계 마련, 무단 사용 방지
  • 외부->내부 접근 제한: 인가된 단말기, IP, 계정으로만 접근이 가능하도록 보안 조치를 적용
  • 내부->외부 멀티 테넌트 제한: 내부 SaaS 이용 단말에서 외부 타 테넌트 및 개인 계정으로 접속이 되지 않도록 보안 조치 적용
• SaaS 이용 단말기 보안대책 적용
  • 악성코드 감염 예방
  • 중요정보 유출 방지
• 모바일 단말기 보안대책 적용: 내부 보안정책을 준수, 기술적.관리적 조치 적용(*[금융회사 재택근무 보안 안내서] 중 외부 모바일 기기 특화 보안 통제 권고 사항 참고])

2. 접근통제

• 단말기 네트워크 통제 적용: 외부 인터넷 및 다른 SaaS 로 접속이 되지 않도록 접근 통제 설정 적용
• 연계 및 제3자 제공 앱 통제: 비인가 앱.플러그인 설치, 외부 연동 모니터링, 승인 및 통제 절차를 마련

• 접속 단말기 및 사용자 등록.관리: 절차 마련
• 안전한 인증 수단 적용: 멀티팩터(MFA) 인증 적용
• 안전한 계정관리 정책 적용: 비밀번호 설정, 계정 잠금.해제 등
• 최소 권한(역할) 설정: 최소한의 범위로 제한, 최소한의 인원에 권한을 할당하도록 검토 수행
• 부적절한 공유 설정 점검 및 제거

3. 운영.관리

• 클라우드 서비스 보안 관리
  • 보안관리 대상 식별.관리: 담당자 및 책임자를 지정
• 이용.관리 등 보안 교육 실시: 서비스에 대한 보안관리 방안을 명확히 숙지하도록 정기 또는 수시 교육 실시
• 상시 관리 체계 확보: 관련 위협, 침해사고 등에 신속하게 대응할 수 있도록 SaaS 제공자, 관리자, 이용자 간 비상 연락 체계를 상시 유지, 담당자별 역할 정의와 대응 절차를 마련하여 상시 운영

4. 네트워크 보호

• 이용 및 대고객 서비스 네트워크 간 상호 영향 최소화
• 연계 구간 암호화 적용

5. 이상행위 모니터링

• 이용자.관리자 로그 기록 보존: 1년이상 보존하도록 설정
• 이상행위 및 주요 설정 변경 탐지: 이상행위를 정의, 탐지정책 적용에 따른 탐지.분석을 수행하며, 지속적인 개선 수행
• 모니터링 체계 구축
  • 탐지 알람 통지
  • 보안 조치 이행

6. SaaS 데이터 보호

• 중요정보 입력 및 저장 방지
  • 중요정보 입력 제한.필터링
  • 중요정보 입력 점검: 입력 제한 데이터가 저장.처리 되었는지 점검
  • 생성형 AI 학습 방지: 이용자 정보 활용 설정을 비활성화하고 피드백 기능 제한 등 데이터 보호 조치 적용
• 중요정보 식별: 데이터 생성.저장.처리시 중요정보를 식별하여 SaaS를 통해 중요정보가 오남용되지 않도록 관리
• 악성코드 감염 점검
• 중요정보 유출 방지 대책 적용
  • 중요정보 보호대책 적용
  • 탐지내역 점검

1. 가명처리 이해

1-1. 가명처리와 가명정보 처리의 차이

가명처리

• 개인정보 일부를 삭제하거나 대체하여 개인을 식별하기 어렵게 만드는 과정
• 예: 이름 일부 마스킹, 주민번호 일부 삭제

가명정보 처리

• 가명처리를 통해 생성된 가명정보를 이용·제공·활용하는 행위
• 단순 변환이 아니라 활용 단계까지 포함

1-2. 가명정보 처리 5단계 절차

가이드라인에서는 가명정보 처리 절차를 다음과 같이 설명한다.

1. 사전준비
2. 위험성 검토
3. 가명처리
4. 적정성 검토
5. 안전한 관리 및 활용

또한 역할을 분리하여 처리해야 한다.

• 가명처리 수행자
• 가명정보 결합자
• 적정성 검토자
• 가명정보 취급자

1-3. 역할 분리의 중요성

가명정보 처리에서는

• 안전조치 의무
• 처리 시 금지의무
• 재식별 금지

등을 반드시 준수해야 한다.

특히

• 가명처리 수행자
• 적정성 검토자
• 가명정보 취급자

사이에 권한을 분리하여 운영해야 한다.

1-4. 익명정보와 가명정보 비교

구분 익명정보 가명정보

즉,

• 익명정보는 재식별 가능성이 거의 없음
• 가명정보는 추가정보 없이는 개인 식별이 어렵지만 완전히 불가능한 것은 아님

2. 가명정보 처리 필요성

2-1. 개인정보 활용 부서 사례

자료에서는 기업 내부 여러 부서가 개인정보를 활용한다고 설명한다.

활용 예시

• 마케팅 부서 → 구매패턴 분석
• 회계 부서 → 결제 및 환불 관리
• 연구 부서 → 소비 성향 및 빅데이터 분석
• 지원 부서 → 회원관리 및 UX 개선
• 회원관리 부서 → 고객 관리 및 고객지원
• 재고·생산관리 부서 → 재고 분석 및 생산 공정 관리

2-2. 가명정보 활용 이유

수집한 개인정보를 그대로 사용하는 경우 개인정보 침해 위험이 높아진다.

따라서

• 개인정보를 가명처리하여 활용
• 데이터 분석 및 연구 목적 활용
• 개인정보 보호와 데이터 활용의 균형 추구

가 필요하다.

2-3. 다양한 산업 분야 활용

가명정보는 다음과 같은 분야에서 활용 가능하다.

• 금융
• 치안
• 통신
• 지역경제
• 라이프로그
• 교통
• 헬스케어
• 환경
• 소방안전
• 문화
• 유통
• 보건의료
• 감염병
• 농식품 등

특히 서로 다른 데이터를 결합하여 새로운 서비스를 만드는 데 활용된다.

3. 전통적 비식별 기술의 한계

3-1. Privacy-Utility Trade-off

자료에서는 개인정보 보호와 데이터 활용성 간의 상충 관계를 설명한다.

핵심 개념

• 개인정보 보호 수준이 높아질수록 데이터 활용성 감소
• 데이터 활용성을 높이면 개인정보 보호 수준 감소 가능

이를

• Privacy-Utility Trade-off
• Accuracy-Privacy Trade-off

라고 설명한다.

4. 가명처리 기술에 대한 이해

4-1. 개인정보 속성 분류 목적

가명처리를 위해서는

• 데이터 위험도 분석
• 속성별 식별 가능성 분석
• 적절한 가명처리 수준 결정

이 필요하다.

4-2. 개인정보 분류

자료에서는 개인정보를 다음과 같이 분류한다.

구분 특징

예시

• 고유식별자: 주민등록번호
• 준식별자: 성별, 나이, 주소
• 민감정보: 건강정보, 질병정보

4-3. 개인정보를 포함한 일반적 자료 형태

자료는 데이터를 다음과 같이 설명한다.

데이터 종류

• Raw Data
• Micro Data
• Macro Data
• Meta Data

특징

• 미시데이터는 개별 단위 데이터
• 거시데이터는 통계 집계 데이터
• 메타데이터는 데이터를 설명하는 데이터

5. 자료 형태별 데이터 분석 특징

5-1. 이산형 데이터

명목형 척도 (Nominal)

• 순서 없음
• 범주만 존재
• 예: 성별, 혈액형

순위형 척도 (Ordinal)

• 순서 존재
• 간격 의미 없음
• 예: 만족도 조사

5-2. 연속형 데이터

구간형 척도 (Interval)

• 간격 의미 존재
• 절대 0 불가능
• 예: 온도

비율형 척도 (Ratio)

• 절대 0 존재
• 비율 계산 가능
• 예: 키, 몸무게, 시간

6. 특정정보 관찰 방법

6-1. k-익명성

개념

• 동일 속성을 가진 사람이 최소 k명 이상 존재하도록 처리

목적

• 특정 개인 식별 방지

6-2. 이상치(Outlier) 탐지

3시그마 규칙

• 평균 ±3표준편차 범위를 벗어나면 이상치로 판단

사분위수 분석

• 박스플롯 기반 이상치 탐지
• IQR(Q3-Q1) 활용

6-3. 범주형 데이터 분석

범주별 빈도를 통해

• 희귀값 존재 여부
• 특정 집단 식별 가능성

등을 확인한다.

예:

• 특정 지역 + 특정 직업 조합
• 희귀 혈액형
• 드문 연령대 조합

핵심 정리

가명정보의 핵심 목적

• 개인정보 보호
• 데이터 활용 가능성 확보
• 분석·연구·산업 활용 지원

가명처리 시 핵심 고려사항

• 재식별 위험 최소화
• 역할 분리
• 안전조치 의무 준수
• 적정성 검토 수행

핵심 기술

• k-익명성
• 이상치 탐지
• 범주형 빈도 분석
• 속성 분류 기반 위험 분석

개인정보 제3자 제공 개요

개인정보처리자: 업무를 목적으로 개인정보파일을 운용하기 위하여 스스로 또는 다른 사람을 통하여 개인정보를 처리하는 공공기관, 법인, 단체 및 개인 등을 말함

• 개인정보처리자는 적법 근거가 있는 경우에만 최초 수집한 목적외로 개인정보를 이용하거나 제3자 제공 가능
• 업무를 목적으로 개인정보를 목적외로 이용하거나 제3자에게 제공하는 경우 개인정보 보호 조직의 사전 확인을 받을 필요

처벌 규정

• 위반 시 5년 이하 징역 또는 5천만원 이하의 벌금
• 전체 매출액의 100분의 3 이하 과징금

제3자 제공 개념: 개인정보를 최초 수집한 개인정보처리자(기관.단체.법인 등) 외의 다른 개인정보처리자에게 개인정보가 제공되는 것

• 개인정보가 저장된 저장매체, 개인정보가 인쇄된 출력물.책자, 개인정보를 기재한 수기문서 등을 물리적으로 이전
• 개인정보가 저장된 파일을 네트워크를 통해 전송
• 개인정보가 저장된 DB 등 시스템 접근 권한을 허용하여 개인정보 열람.복사 가능

위탁과 제3자 제공의 구분

유사 개념 비교

• 제3자 제공
  • 개인정보처리자 외의 제3자에게 개인정보의 지배 관리권이 이전되는 것
    • 제공받은 개인정보처리자의 업무 처리와 이익을 위해 개인정보가 이전
    • 제3자가 개인정보에 대한 법적인 관리 책임을 가짐
• 위탁
  • 개인정보처리자의 업무 처리 목적으로 외부의 수탁사에게 전달하는 것
    • 개인정보의 지배관리권은 여전히 최초의 개인정보처리자에게 있어 개인정보 제공 아님
• 영업 양도.합병
  • 개인정보 처리 형태가 변하는 것이 아니라 관리주체만 변경되는 것으로 제3자 제공과는 차이가 있음

개인정보취급자 금지 행위

• 위반 시 5년 이하의 징역 또는 5천만원 이하의 벌금

개인정보 제3자 제공 적법 근거

1. 정보주체 동의를 받은 경우
2. 다음의 경우에 따라 수집한 목적 범위 내에서 제공하는 경우
   1. 법률의 특별한 규정, 법령상 의무 준수를 위해 불가피한 경우
   2. 공공기관이 법령 등에서 정한 소관업무 수행을 위해 불가피
   3. 급박한 생명, 신체, 재산의 이익을 위해 필요
   4. 개인정보처리자의 정당한 이익 달성. 정보주체의 권리보다 우선하는 경우
   5. 공공의 안전과 안녕을 위하여 긴급히 필요

처벌 규정

• 전체 매출액의 100분의 3 이하의 과징금

수집한 목적 범위내에 개인정보 제공

• 법률에 제3자 제공에 관한 특별한 규정이 있는 경우 혹은 법령상 의무를 준수하기 위해 제3자 제공이 불가피한 경우
  • 법률에서 개인정보의 활용에 대하여 구체적으로 요구하거나 허용하여야 함
• 공공기관이 법령 등에서 정하는 소관 업무의 수행을 위하여 불가피한 경우로서 그 수집 목적 범위 내에서 개인정보를 제공하는 경우
• 공공의 안전과 안녕을 위하여 긴급히 필요한 경우

개인정보의 추가적 이용.제공

• 당초 수집 목적과 합리적으로 관련된 범위 내 정보주체 동의 없이 개인정보 이용.제공 가능

1. 당초 수집 목적과 관련성이 있는지 여부
2. 개인정보를 수집한 정황 또는 처리 관행에 비추어 볼 때 개인정보의 추가적인 이용 또는 제공에 대한 예측 가능성이 있는지 여부
3. 정보주체의 이익을 부당하게 침해하는지 여부
4. 가명처리 또는 암호화 등 안전성 확보에 필요한 조치를 하였는지 여부

개인정보 처리 위탁

위탁 시 조치사항

1. 위탁업무 수행목적 외 개인정보의 처리 금지
2. 개인정보의 기술적.관리적 보호조치
3. 위탁업무의 목적 및 범위
4. 재위탁 제한
5. 개인정보에 대한 접근 제한 등 안전성 확보 조치
6. 위탁업무와 관련하여 보유하고 있는 개인정보의 관리 현황 점검 등의 감독
7. 수탁자가 준수하여야 할 의무를 위반한 경우의 손해배상 등의 책임

개인정보 처리업무 공개 및 수탁사 관리 감독

• 위탁자는 정보주체가 언제든지 쉽게 확인할 수 있도록 위탁 업무 내용, 수탁자를 인터넷 홈페이지 등에 공개(재수탁사 포함)
• 홍보나 판매 권유 업무 위탁 시 업무 내용과 수탁자를 정보주체에게 통지
• 수탁자가 개인정보를 안전하게 관리할 수 있도록 수탁자 교육, 감독

⇒

수탁사에 대한 관리.감독 또는 교육을 소홀히 하여 수탁자가 이 법의 규정을 위반한 경우

전체 매출액의 100분의 3을 초과하지아니하는 범위에서 과징금을 부과

개인정보취급자 주의 사항

• 위수탁 계약종료 전후 개인정보보호 조직의 검토 및 확인
• 수탁사 선정
  • 위탁 업무 및 수탁사 선정
  • 위탁 문서 작성
• 위탁 계약 유지
  • 수탁사 교육 및 관리 감독
  • 재위탁 여부 확인
• 위탁 계약 종료
  • 개인정보 파기 확인

개인정보 위수탁 관련 처벌 사례

• A사는 B사의 서버.계정으로 회원정보를 공공 관리→A사 B사에게 개인정보처리 위탁
• 해커가 사전에 탈취한 관리자 계정으로 B사 서버에 침입하여 A사.B사 회원 8만 7,923명에게 스팸문자 발송

개인정보취급자 실천수칙

이용.제공 단계 개인정보 보호 수칙

1. 개인정보는 반드시 최초 수집한 목적 범위 내에서 이용.제공
2. 개인정보를 제3자에게 제공 전 적법 근거를 확인하기
3. 동의를 받아서 제3자에게 재공하는 경우에는 동의서 내 법적 고지 사항을 포함하기
4. 위탁 계약 시 개인정보 보호에 대한 사항을 계약서에 포함하기
5. 수탁자를 주기적으로 교육하고 점검하여 관리.감독을 철저히 하기
6. 위탁 계약 종료 후에 개인정보 파기 여부를 확인하기
7. 제3자 제공과 위탁 처리 전 반드시 개인정보 보호 담당자의 검토 받기

1)

해당 페이지 범위의 제목, 소제목, 표/차트/키워드만 먼저 훑어보기

• 제목 및 소제목:
  • 4.4. Data protection officer appointment (데이터 보호 책임자 임명)
  • 4.5. Data security and data breaches (데이터 보안 및 데이터 유출)
  • 4.6. Accountability (책임성)
• 표/차트(일관성 등급):
  • 세 섹션 모두 'Fairly consistent (매우 유사)' 등급
• 주요 키워드:
  • DPO, Privacy Officer (개인정보 보호책임자), Independence (독립성), Domestic representative (국내대리인), Technical/Managerial/Physical measures (기술적/관리적/물리적 조치), Data breach notification (유출 통지), Internal management plan (내부 관리 계획)

2)

문단별로 빠르게 훑으며 주요 결론/차이점만 한국어로 적기

표 형식 부분은 GDPR/PIPA/Differences 열을 먼저 한국어로 요약

• 4.4. DPO 임명: 양측 모두 전문가 임명을 요구하지만, GDPR은 공공기관이나 대규모 모니터링 시 필수인 반면, PIPA는 일정 기준(매출액, 고용 인원 등)에 따라 임명 여부가 결정됩니다. 특히 PIPA는 국내에 사업장이 없는 서비스 제공자에게 국내대리인 지정을 요구하는 특징이 있습니다.
• 4.5. 데이터 보안 및 유출: 기술적·관리적 보호 조치를 취해야 한다는 점은 같습니다. 하지만 유출 통지 기한에서 GDPR은 72시간 이내인 반면, PIPA는 5일 이내(정보통신서비스 제공자는 24시간 이내)입니다. 또한 PIPA는 1,000명 이상의 유출 시에만 정부 기관에 보고할 의무가 있습니다.
• 4.6. 책임성: GDPR은 '책임성(Accountability)'을 명시적인 법적 원칙으로 규정하고 입증 책임을 강조하지만, PIPA는 명시적인 용어 대신 처리자의 전반적인 의무 준수 노력을 강조하는 형태로 표현합니다.

[표 요약: GDPR/PIPA 차이점]

구분 GDPR PIPA 주요 차이점 (Differences)

3)

핵심 문장 2~3개는 직접 영어로 요약해서 노트에 쓰기

Both frameworks require the appointment of a data protection expert to ensure compliance, though PIPA specifically mandates a 'domestic representative' for foreign entities without a physical presence in Korea.

• While both laws mandate data breach notifications, PIPA sets a reporting threshold of 1,000 individuals and prescribes specific timelines, such as 24 hours for information and communications service providers.

4)

페이지에서 나온 중요한 법률 영어 단어 선택

간단하게 영어로 정의 작성, 한국어로 정의 작성

1. Domestic Representative
   • A person designated within South Korea by foreign service providers to manage data protection matters and respond to local authorities.
   • 국내에 사업장이 없는 외국 사업자가 정보주체 보호를 위해 국내에 지정해야 하는 국내대리인.
2. Internal Management Plan
   • A set of administrative guidelines established by a data handler to ensure the secure processing of personal information.
   • 개인정보의 안전한 처리를 위해 수립하고 시행해야 하는 내부 관리 계획.
3. Independence (of DPO/Privacy Officer)
   • The requirement that data protection officers should not receive instructions regarding the exercise of their tasks to prevent conflicts of interest.
   • 책임자가 업무 수행 시 누구의 지시도 받지 않고 독자적으로 판단할 수 있는 독립성.
4. Integrity and Confidentiality
   • Fundamental principles ensuring that personal data is processed securely to prevent unauthorized access or loss.
   • 개인정보가 안전하게 보호되어야 한다는 무결성 및 기밀성 원칙.
5. Corrective Power
   • The authority of a supervisory body to issue warnings, order erasures, or impose fines in response to violations.
   • 법 위반 시 감독 기구가 행사할 수 있는 시정 명령 및 제재 권한인 시정권

5)

한글로 3문장 요약→영어로 3문장 요약 바꿔쓰기

스스로에게 공부한 내용 관련해서 1개의 질문을 영어로 해보기

그리고, 스스로 답변 작성

1. GDPR과 PIPA는 데이터 보호 책임자(DPO)의 임명과 그 독립성 보장을 공통적으로 요구하지만, PIPA는 그룹 단위의 단일 책임자 지정을 허용하지 않습니다.
2. 보안 측면에서 두 법 모두 기술적·관리적 조치를 강조하며, PIPA는 1,000명 이상 유출 시에만 기관 보고 의무가 발생하는 구체적 기준을 두고 있습니다.
3. 책임성(Accountability)에 대해 GDPR은 이를 명시적 기본 원칙으로 삼는 반면, PIPA는 데이터 처리자의 전반적인 법적 의무 준수 노력을 통해 이를 실현합니다.

1. Both the GDPR and PIPA mandate the appointment of data protection experts and ensure their independence, but PIPA requires each individual entity to appoint its own officer.
2. In terms of security, both laws emphasize technical and managerial measures, with PIPA establishing a clear threshold of 1,000 affected subjects for mandatory reporting to regulators.
3. While the GDPR explicitly codifies accountability as a core legal principle, PIPA approaches it through the general duty of handlers to demonstrate compliance with their statutory responsibilities.

• Q: What is a key difference between the GDPR and PIPA regarding the reporting of a data breach to the supervisory authority?
• A: Under the GDPR, a breach must be notified to the authority within 72 hours unless it is unlikely to result in a risk, whereas under PIPA, a report is only mandatory if the breach involves 1,000 or more individuals, typically within 5 days

잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정 - tech.kakao.com

상상해본다. 친구가 당신에게 편지를 보냈다.

보냈다는 친구의 말도 맞고, 우체국의 발송 기록도 존재한다. 

집 앞에는 집배원이 다녀간 흔적까지 남아있다.

그런데 정작 우편함 안에는 편지가 없다.

지난달, KIMS(Kakao Integrated Messaging Service)에서 비슷한 일이 실제로 발생했다.

카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정

KIMS는 카카오 내부 서비스에서 사용되는 SMS 전송 플랫폼.

하루 약 100만 건의 메시지를 처리

다수의 IDC 환경에 분산된 MSA 기반 시스템으로 운영되고 있음.

• IDC(Internet Data Center): 기업의 서버, 네트워크, 데이터 저장 장치 등을 안전하게 모아서 관리하는 물리적인 데이터 센터(서버실)을 의미
• 분산됨: 여러 지역의 IDC나 여러 대의 서버 장비에 나누어져서(분산되어) 시스템이 설치되어 있다는 의미
• 이유: 특정 서버나 한 지역의 IDC에 화재나 지진 같은 재해가 발생하더라도, 다른 지역의 서버가 살아있어 서비스가 24시간 중단 없이 안정적으로 운영(고가용성) 되도록 하기 위함이다.

• MSA(Microservice Architecture): 시스템을 기능별로 작게 쪼개서 개발하고 운영하는 설계 방식
• 쪼개진 각각의 서비스들은 서로 독립된 프로그램이며, 자기만의 데이터베이스(DB)를 따로 가진다. 이 작은 서비스들이 서로 API(통신)을 주고받으며 하나의 거대한 쇼핑몰처럼 작동하게 된다.
• 이유
  • 빠른 업데이트: 배송 기능에 버그가 있어서 수정할 때, 전체 쇼핑몰을 껐다 켤 필요 없이 '배송 서비스'만 고쳐서 새로 배포하면 된다.
  • 유연한 확장: 블랙프라이데이터 같은 이벤트로 인해 '주문/결제'에 트래픽이 폭주하면, 전체 시스템을 늘릴 필요 없이 '주문/결제 서비스'용 서버만 집중적으로 늘려주면 된다.
• 결론: 대형 데이터 센터(IDC)들이 여러 서버에 시스템을 나누어 배치(분산)해 두었고, 그 시스템은 기능별로 쪼개진 작은 서비스들(MSA)이 서로 협력하며 돌아가는 구조로 만들어져 있다.

또한, 메시지의 안정적인 전송을 위해 다수의 외부 SMS 벤더사와 연동되어 있다.

1. 외부 SMS 벤더사

• 벤더사는 공급업체, 즉 서비스를 제공하는 기업을 의미함.
• 외부 SMS 벤더사는 우리가 흔히 아는 대량 문자 발송 전문 업체를 의미. 통신사(SKT, KT, LGU+)와 직접 연결되어 대량으로 문자를 보내주는 통로 역할을 하는 회사들 의미

2. 다수의 벤더사와 연동되어 있다.

• 문자 발송 시스템을 구축할 때 한 회사하고만 계약해서 쓰는 것이 아니라, A사, B사, C사 등 여러 업체와 시스템을 동시에 연결(연동)해 두었다는 의미

3. 메시지의 안정적인 전송을 위해

• 안정성(백업 구조) 때문
• 장애 대비(Failover): 만약 A사 시스템에 갑자기 화재가 나거나 서버 오류가 발생해서 문자가 안 보내진다면? 시스템이 즉시 B사나 C사로 경로를 틀어서(우회해서) 문자를 보낸다. 사용자는 서비스에 장애가 발생한지도 모르고 인증 번호 또는 알림 문자를 정상적으로 받게 된다.
• 부하 분산(Traffic Load Balancing): 대량의 공지 문자나 광고 문자를 한 번에 보낼 때, 한 업체에만 밀어 넣으면 처리가 늦어질 수 있음. 이때 여러 벤더사로 문자를 나누어 보내면 훨씬 빠르고 안정적으로 전송가능.
• 비용 절감 및 효율성: 벤더사마다 통신사별 또는 문자 종류별(단문 SMS/ 장문 LMS/ 이미지 MMS)로 가격이나 전송 성공률이 조금씩 다를 수 있다. 상황에 따라 가장 유리한 곳을 골라서 보낼 수 있는 기반이 된다.

메시지 전송 요청이 들어오면, 내부적으로 여러 단계를 거쳐 메시지를 처리하게 된다.

카카오 및 카카오 공동체의 다양한 서비스로부터 메시지 전송 요청이 들어오면,

1. API Server는 실시간 품질 지표를 기준으로, 여러 벤더사 중 가장 적합한 곳으로 메시지 전송 요청을 라우팅한다.

2. 벤더사 호출 이후, 메시지를 SENT 상태로 DB에 기록한다.

3. 메시지는 실제 단말 사용자에게 전달된다.

4. 이후 벤더사는 어떤 메시지가 언제, 어떤 결과로 전달되었는지에 대한 전송 결과 리포트를 우리에게 보내준다.

5. 리포트를 수신하면, 메시지의 상태를 REPORTED 상태로 DB에 업데이트한다.

KIMS의 메시지 처리 흐름은

1. 전송요청

2. 벤더 호출

3. 리포트 수신

4. 상태 확정

단계를 거치며, 각 단계는 비동기적으로(독립적으로) 분리된 컴포넌트에서 수행됨.

이 구조는, 모든 단계가 우리가 기대한 순서대로 동작한다면, 문제없이 잘 동작한다.

리포트가 어디갔지?

일부 메시지의 상태가 REPORTED로 갱신되지 않은 채, SENT 상태로 그대로 머물러 있었다.

처음에는 벤더사로부터 리포트를 받지 못했을 가능성을 의심했지만, Report Server 로그를 확인한 결과, 리포트 수신 로그는 남아 있었다.

즉, 벤더사로부터 리포트는 정상적으로 수신되었지만, 그 결과를 회사의 DB에 반영되지 못한 채, 메시지 상태가 SENT 상태로 멈춰 있던 상황이었다.

실종된 리포트의 특징?

동시성(Concurrency) 문제의 원인을 규명하는 일은 본질적으로 어렵다.

특히 문제 발생 빈도가 낮고, 특정 조건에서만 간헐적으로 드러나는 경우라면 분석 난이도는 더욱 높아진다.

이러한 동시성 버그는 실행 순서와 타이밍에 강하게 의존한다.

그래서 단위 테스트나 로컬 환경에서는 재현되기 어렵고, 운영 환경에서 여러 조건이 우연히 맞아떨어질 때에만 관측되는 경우가 많다.

다행히 분석이 가능할 정도의 누락 건이 충분히 축적되어 있었고, 누락 건들 사이에 몇 가지 공통 패턴이 있었다.

문제 1. 리포트 누락 건은 특정 벤더사로 전송된 메세지에 한정되어 관측됨.

문제 2. 메시지 유형 중에서는 무료 메시지가 아닌, 과금 대상 유료 메시지에서 주로 발생함.

리포트 누락은 전체의 극히 일부인 약 0.02% 에서만 발생했음.

전체가 아닌, 제한된 조건에서, 극히 일부에서만 이슈가 발생하고 있다는 점이 원인 분석과 디버깅을 더욱 어렵게 만듦

왜 특정 조건에서만, 이렇게 선택적으로 리포트 누락이 발생했을까?

로그의 단서 찾기

문제 1: 리포트 누락 건은 특정 벤더사로 전송된 메시지에 한정되어 관측되었음.

애플리케이션 로그를 분석해본다.

아래는 리포트 누락이 발생한 시점의 로그를 시간 순으로 정리한 것이다.

// (API Server) 벤더 API 호출 성공, 토큰 수신 완료 (아직 DB에 영속화되지 않음)

2025-11-21T15:43:21.362+09:00 INFO API Server : [VENDOR_RESPONSE] SMS sent successfully, token acquired (token=aaaa, persistence=PENDING)

// (API Server) 과금 단계: Kafka 이벤트 발행 완료 (여전히 DB 미영속 상태)

2025-11-21T15:43:21.370+09:00 INFO API Server : [POST_PROCESS] Kafka event published for SENT message (token=aaaa, persistence=PENDING)

// ✅ 21.370초 이후의 어느 시점에 레코드 영속화가 이루어짐

// (Report Server) 벤더사 Report 진입 시점 (API Server 후처리와 동일 타임스탬프)

2025-11-21T15:43:21.370+09:00 INFO Report Server : [ENTRY] DeliveryReportController invoked (token=aaaa)

// (Report Server) 메시지 조회 실패, 저장 실패

2025-11-21T15:43:21.372+09:00 WARN Report Server : [LOOKUP_FAIL] Delivery report received but message not found (vendor=B, token=aaaa)

일반적으로 다른 벤더사들은 메시지 처리를 마치고 리포트를 전달하기까지 평균 1초 이상이 걸리는 반면,

문제가 생긴 벤더사는 평균 약 20ms 로 리포트 전달 시점이 상대적으로 매우 빠른 편이었다.

특히 리포트 누락이 발생한 사례들만 모아보면, 리포트 유입까지의 평균 지연 시간은 약 8ms로, 전체 평균보다도 훨씬 짧았다.

그 결과, 메시지에 대한 후처리와 DB 영속화를 완료되기도 이전에, 리포트가 먼저 시스템에 도착하는 상황이 발생함.

이로 인해 메시지의 Write 경로와 Read 경로가 동일한 시점에 교차하게 되었고, 극단적으로 짧은 타이밍에서 경쟁 조건이 발생하게 되었던 것이다.

문제 2: 메시지 유형 중에서는 무료 메시지가 아닌, 과금 대상 유료 메시지에서 주로 발생했다.

과금 대상인 유료 메시지의 경우, 과금 이벤트 발행을 위한 추가 후처리 로직이 존재했다.

벤더 호출부터 해당 후처리 단계까지의 전 과정이 하나의 @Transactional 범위로 묶여 단일 트랜잭션 내에서 실행되고 있었다.

그 결과 무료 메시지에 비해 트랜잭션 수행 시간이 길어졌고, DB Commit 시점도 자연스럽게 지연되고 있었다.

이로 인해 유료 메시지에서는 메시지가 DB에 영속화되기 전에 전송 결과 리포트가 먼저 도착할 가능성이 더 커지고 있었다.

아이러니하게도, 과금을 정확히 처리하기 위해 추가한 로직이 오히려 과금 대상 메시지에서 문제를 유발하고 있었다.

1. API Server: 실시간 품질 지표를 기준으로, 여러 벤더사 중 가장 적합한 곳으로 메시지 전송 요청을 라우팅한다.

2. 여기서 과금을 위한 후처리 작업이 수행

3과 4 메시지에는 실제 단말 사용자에게 전달되고, 벤더사는 전송 결과 리포트를 우리에게 보내준다.

5. 리포트를 수신한 Report server는 메시지 상태를 REPORTED 로 업데이트하려고 시도한다.

-그러나 이 시점에는 아직 메시지 레코드가 DB에 존재하지 않아, 해당 리포트는 유효하지 않은 리포트로 판단되어 Drop 된다.

6. API Server는 과금 이벤트 발행을 마친 뒤에 비로소 메시지 레코드를 DB에 영속화한다.

그렇다면 이제 이 구조적인 경쟁 조건을 어떻게 제거 ?

첫번째 조치: 트랜잭션을 다이어트해보자.

트랜잭션을 가볍게 만드는 것.

기존 구조에서는 Kafka 이벤트 발행과 같은 비즈니스 로직이 트랜잭션 내부에서 함께 실행되며 Long-lived Transaction을 유발했고, 그 결과 DB 영속화 시점이 불필요하게 지연되고 있었다. 이를 개선하기 위해, 트랜잭션 내에서 반드시 필요하지 않은 로직을 분리한다.

이 변경으로 트랜잭션의 책임 범위는 상태변경과 DB 영속화(커밋)으로 한정되어, 보다 가벼워질 수 있었다.

부수적인 효과로, 이벤트 발행 실패 시 트랜잭션 자체가 롤백되는 Dual-write 문제 역시 함께 해소되었다.

개념상 롤백될 수 없는 외부 이벤트 발행을 트랜잭션 내부에 두고 있었던 이 구조 자체도 부적절했던 것이다.

우리는 정말 트랜잭션이 필요?

문제를 해결하는 과정에서 한걸음 물러나, 트랜잭션 자체가 우리의 비즈니스 요구사항에 적절한 선택이었는지를 처음부터 검토해보았다.

트랜잭션은 물론 강력한 도구이지만, 모든 상황에서 항상 필요하지는 않으며, 때로는 오히려 성능 저하와 복잡성 증가를 초래하기에, 트랜잭션인 보장을 완화하거나 아예 사용하지 않는 것이 이득일 수 있다.

본 회사에서 시스템은 MySQL 의 기본 격리 수준인 REPEATEABLE READ 를 사용하고 있었고, 일반적으로 해당 격리 수준에서 트랜잭션을 도입하는 이유는 3가지로 정리 가능.

1. 원자성: 작업 도중 문제가 발생했을 때, 전체 변경을 롤백할 수 있는 보장이다.

2. 읽기 격리: 다른 트랜잭션의 중간 상태를 읽지 않도록 보호한다.

3. 쓰기 격리: 커밋되기 전까지는 다른 트랜잭션에서 해당 변경사항을 볼 수 없도록 한다.

이제 하나씩 질문을 던져본다.

<원자성>

Abortability가 필요한 상황인가?

여기서 말하는 원자성은, 여러 개의 쓰기 작업 중 일부만 수행된 상태에서 장애가 발생했을 때 전체 변경을 abort 하고, 지금까지 실행한 쓰기를 취소할 수 있는 것을 의미한다.

하지만 시스템의 특성을 다시 살펴보면, 이 트랜잭션 안에서 수행되던 쓰기 연산은 단 하나였다.

여러 테이블에 걸친 동기 쓰기나, 크로스 레코드 원자성을 보장해야 하는 구조는 아니었다. 즉, 부분 성공을 허용하지 않기 위해 반드시 트랜잭션이 필요한 시나리오는 아니었다.

<읽기 격리>

일관된 읽기가 필요한 상황인가?

해당 트랜잭션에서는 상태 변경에 앞서, 몇 개의 메타데이터 테이블을 조회하고 있었다.

예를 들어 현재 라우팅 대상 벤더의 정보나, 벤더별 실시간 품질 지표 같은 값들이었다.

다만 이 데이터들의 특성을 살펴보니, 강한 시점 일관성(strict freshness)이 요구되는 정보는 아니었다.

벤더 품질 지표는 분 단위로 갱신되고 있었고, 최악의 경우 1분 전 스냅샷이 사용되더라도 비즈니스적으로 문제가 없는 수준이었다.

또한 조회 대상 테이블들 간에도 강한 결합 관계가 없었다.

즉, 서로 독립적인 메타데이터를 읽는 구조였기 때문에, 동일한 스냅샷에서 일관되게 격리하여 읽어야 할 필요성이 크지 않았다.

우리의 상황에서 읽기 격리를 위해 트랜잭션을 유지해야 할 명확한 이유를 찾기 어려웠다.

<쓰기 격리>

이 변경이 정말 다른 트랜잭션에게 숨겨야 할 변경이었을까?

트랜잭션이 커밋되기 전까지 변경 사항을 다른 트랜잭션에서 관측하지 못하도록 하는 특성.

본 회사 시스템에서는 Hibernate 기반의 JPA를 사용하고 있었고, @Transactional 아래에서는 Dirty Checking 메커니즘을 따라, 변경 사항이 Persistence Context(1st-level Cache)에만 반영된 채, 트랜잭션 종료 시점까지 실제 DB Write가 지연되고 있었다.

리포트 누락은 Report Server가 리포트를 빠르게 수신한 상황에서, API Server에서 수행된 상태 변경(초기 상태->SENT)이 아직 DB에 커밋되지 않았을 때 발생했다.

@Transactional 으로 보호된 API Server의 상태 변경은 Dirty Checking에 의해 트랜잭션 종료 시점까지 DB에 반영되지 않았고, 이로 인해 리포트 수신 시점과 메시지 레코드 커밋 시점 사이의 간극이 더욱 벌어졌다.

그 결과, Report Server는 리포트를 정상적으로 수신했음에도 불구하고, 해당 시점에는 메시지 레코드가 아직 DB에 존재하지 않아 조회에 실패하게 되었다.

이 경로에서의 트랜잭션 경계와 커밋 지연은 리포트 수신 타이밍과 맞물리며, Write 경로와 Read 경로 간의 타이밍 충돌을 증폭시키는 요인으로 작용하고 있었다.

이 3가지 측면을 종합한 결과, 해당 경로의 트랜잭션 유지가 불필요하다고 결론지었다.

두번째 조치: 트랜잭션을 풀다

발생 가능성이 낮은 시나리오를 대비해 시스템을 과도하게 복잡하게 만들 경우, 그에 따른 비용과 제약은 빠르게 증가하는 반면 실제로 얻는 이점은 적을 수 있다.

결론적으로, 성공적으로 상태 값 영속화 시점을 앞당길 수 있었고, 그 결과 리포트 누락 건수가 약 40% 까지 감소했다.

한계는 존재했다.

트랜잭션을 아무리 가볍게 만들지라도 DB 영속화까지 소요되는 시간 자체를 0으로 만들 수는 없었고, 이 구조가 유지되는 한 Write 경로와 Read 경로가 경쟁하는 상황은 언제든지 다시 발생할 수 있다.

Race Condition의 발생 확률을 늦출 뿐, 문제를 구조적으로 제거하는 해결책으로 보기 어렵다.

이제는 확률을 낮추는 접근이 아닌, 경쟁 자체가 발생하지 않는 구조를 만들자.

세번째 조치: Transactional Outbox Pattern 도입하기

경쟁 자체가 발생하지 않는 구조 만들기가 목표이다.

결론은 아웃박스(Outbox) 이다.

Report Server는 리포트를 받는 즉시 모두 Outbox 테이블에 먼저 기록하고, 이후 잃어버린 리포트는 별도의 워커가 Outbox를 기반으로, 리포트 적용을 재시하도록 구성하는 것이었다.

이를 통해, 온라인 처리 경로에서 일시적인 실패가 발생하더라도, 오프라인 경로에서 리포트가 재처리되어 누락되지 않도록 하는 것이다.

목적은 Outbox 기반 재처리 구조가 리포트 유실(DB 누락)을 구조적으로 제거할 수 있는지를 확인하는 것이었다.

결과는, 구조 적용 이후 DB 기준 리포트 누락은 0%로 줄었지만, 과금 이벤트 누락은 오히려 이전보다 더 눈에 띄게 증가하기 시작했다.

멱등성 가드와의 충돌

벤더사는 네트워크 지연이나 장애 상황에서 동일한 리포트를 여러번 전송하는 경우가 종종 있다.

그러나 동일한 리포트를 본 회사에서 2번 수신했다고 해서, 사용자에게 과금이 2번 발생해서는 안된다.

이를 방지하기 위해 Report Server에는 과금 이벤트를 최대 한 번만 발행하도록 보장하는, 원자적 Compare-and-set 연산 기반의 멱등성 가드가 구현되어 있었다.

문제는 Outbox 도입 이후, Report Server와 Report Replayer라는 2개의 처리 경로가 동시에 같은 데이터를 바라보며 상태 전이를 시도하게 되었다는 점이다.

분산 환경에서는 '누가 먼저 실행될지'를 가정할 수 없다.

앞선 사례에서는 이 가정을 벤더사가 깨뜨렸다면, 이번에는 시스템 내부의 요소가 그 가정을 깨뜨렸다.

우리는 배치 처리를 '안전망'으로 추가했지만, 결과적으로 2개의 Writer(At-most-once 시맨틱을 지키기 위한 멱등성 가드와 리포트 복구를 위한 배치 처리 경로)가 정면으로 충돌하는 구조를 만들고 말았다.

이처럼 실시간 처리와 과거 데이터 재처리가 동일한 데이터를 수정하는 구조에서는, 두 경로가 서로 간섭하지 않도록 보장하는 메커니즘이 필수적이다.

네번째 조치: Single Writer Principle

"같은 데이터에 대해 쓰기를 수행하는 주체는 하나만 두자."

우리가 포기한 것과 얻은 것

동시성 문제는 코드의 미세한 조정만으로 해결될 수 없으며, 경쟁 자체가 발생하지 않는 아키텍처로 전환할 때만 근본적으로 제거할 수 있다는 점을 깨닫게 되었다.

아키텍처는 언제나 트레이트오프의 연속이며, 트랜잭션 또한 만능 해법은 아니다.

무엇을 얻기 위해 무엇을 포기할 수 있는지를 명확히 인식하며 설계하자!!

1. 가명정보 활용 유형

가명정보는 개인정보를 직접 식별할 수 없도록 처리한 정보

통계작성, 과학적 연구, 공익적 기록보존 등의 목적에서 활용 가능

1. 연구자료 또는 통계 자료 확보

기관이나 기업은 연구 목적이나 통계자료 확보를 위해 가명정보 활용 가능

특정 현상에 대한 분석, 이용자 행동 패턴 분석, 사회적 문제 해결을 위한 기초자료 확보 등에 사용됨.

2. 현황 및 실태조사

신기술 서비스 개발이나 현황 파악, 특정 집단의 실태 분석을 위해 가명정보 활용 가능.

원본 개인정보는 그대로 활용하지 않고 가명처리함으로써 개인정보 침해 위험을 낮추면서도 데이터 분석 가능

3. 상품.서비스 개발 및 개선

필요한 데이터를 확보하고, 알고리즘 학습이나 품질 개선을 위해 가명정보 활용 가능.

이용자 패턴을 분석해 맞춤형 서비스나 추천 시스템을 개선하는 데 활용 가능

4. 정책 개발 및 개선

기존 정책에 대한 효과 검증 또는 새로운 정책 개발을 위해 가명정보가 활용될 수 있음.

정책 대상자의 특성, 이용 현황, 정책 효과 등을 분석하여 더 나은 정책 설계에 활용하는 방식이다.

2. 가명정보 활용 사례

1) 서울시 1인 가구 정책 실효성 분석

서울시는 1인 가구의 행복하고 안전한 사회기반 조성을 위해 다양한 정책을 운영하고 있다. 이때 가명데이터를 활용하면 1인 가구의 고충, 생활 특성, 정책 수요를 분석하여 정책의 실효성을 높일 수 있다.

즉, 단순히 “1인 가구를 위한 정책이 필요하다”는 수준을 넘어, 실제 데이터 분석을 통해 어떤 정책이 필요한지, 어떤 집단에게 우선 지원이 필요한지 판단할 수 있다.

2) 친환경차 충전 인프라 수요 예측

친환경차 이용이 증가하면서 충전소 위치 선정과 수요 예측이 중요해지고 있다. 가명정보를 활용하면 차량 이용 패턴, 이동 경로, 지역별 수요 등을 분석하여 충전소 설치 위치를 더 합리적으로 선정할 수 있다.

이는 단순히 사람들이 많이 사는 지역에 충전소를 설치하는 것이 아니라, 실제 이동량과 충전 수요를 기반으로 인프라를 배치할 수 있다는 점에서 의미가 있다.

3) 지역가입자 주택금융 부채 공제를 위한 신용정보 결합

건강보험료 부과와 관련하여 지역가입자의 주택금융 부채 정보를 반영하기 위해 신용정보를 결합하는 사례가 제시된다. 건강보험공단의 정보와 금융 관련 정보를 결합하면 보다 정확한 보험료 산정이나 정책 지원이 가능해진다.

이 사례는 서로 다른 기관이 보유한 데이터를 결합해 정책의 정확성과 형평성을 높이는 데 가명정보가 활용될 수 있음을 보여준다.

가명정보는 개인정보를 직접 식별하기 어렵게 처리한 정보이지만, 다른 정보와 결합하면 개인을 알아볼 가능성이 있기 때문에 여전히 개인정보에 해당한다. 가명정보는 통계작성, 과학적 연구, 공익적 기록보존 등의 목적에서 활용될 수 있으며, 정책 개발, 서비스 개선, 연구자료 확보, 현황 분석 등에 유용하게 쓰인다.

다만 가명정보를 활용할 때에는 목적의 적법성, 재식별 가능성, 안전조치, 결합 절차, 위탁 여부 등을 반드시 검토해야 한다. 특히 민감정보, 고유식별정보, 영상정보처럼 식별 가능성이 크거나 정보주체에게 미치는 영향이 큰 정보는 더 신중하게 다루어야 한다.

개인정보 수집의 개념

개인정보 수집:

정보주체로부터 직접수집+모든 형태의 개인정보 수집 행위

개인정보 수집 경로

정보주체로부터 직접 수집:

-온라인

-오프라인

제3자로부터 직접 수집

-온라인 플랫폼으로부터 제공받은 구매자 주문내역

-카드사로부터 제공받은 구매자 가명정보

공개된 자료에서 수집

-SNS 전체 공개된 정보

-검색 사이트를 통해 검색되는 정보

-인명부, 전화번호부, 잡지, 신문기사 등

업무 처리 과정에서 생성

-고객 센터 문의 사항 대응

-시스템 로그 및 접속 기록 등

-직원의 인사평가.근태 기록

수집 단계 개인정보 보호원칙

개인정보 처리 목적을 명확하게!

목적 내에서 적법하고 정당하게!

꼭 필요한 최소한의 개인정보 수집!

개인정보 수집의 적법 근거

적용 대상: 

개인정보 처리자

-업무를 목적

-개인정보파일 운용

-스스로 또는 다른 사람을 통하여 개인정보를 처리하는 공공기관, 법인, 단체 및 개인

업무를 목적으로 개인정보 수집 시 적법 수집 근거에 대해 개인정보 보호 조직의 사전 확인을 받을 필요!!

처벌 규정: 전체 매출액의 100분의 3 이하의 과징금

적법 수집 근거

개인정보처리자의 모든 개인정보 수집 행위에는 개인정보 수집의 법적 근거가 있어야 함

1. 정보주체 동의 받은 경우

2. 법률의 특별한 규정, 법령상 의무 준수-불가피

3. 공공기관이 법령 등에서 정한 소관업무-불가피

4. 체결한 계약 이행, 계약 체결 과정에서 정보주체의 요청에 따른 조치를 이행하기 위하여 필요한 경우

5. 명백히 정보주체 등의 급박한 생명, 신체, 재산의 이익을 위해 필요한 경우

6. 개인정보처리자의 정당한 이익 달성을 위해 필요한 경우로서, 명백하게 정보주체의 권리보다 우선하는 경우

7. 공중위생 등 공공의 안전과 안녕을 위하여 긴급히 필요한 경우

1. 정보주체 동의

'동의'는 개인정보처리자가 개인정보를 수집.이용하는 것에 대한 정보주체의 자발적인 승낙의 의사표시

적법한 동의 의미: 자유로운 의사

<법정고지사항>

-개인정보 수집.이용 목적

-수집하고자 하는 개인정보 항목

-개인정보의 보유 및 이용기간

-동의 거부 권리 및 동의거부 시 불이익 내용

<2023년 개인정보 보호 관련 법률 개정>

필수 동의 원칙: 온라인을 중심으로 개인정보 수집.이용 시 동의 의무화

6. 개인정보처리자의 정당한 이익 달성

*고려사항

(1) 목적의 정당성: 개인정보처리자의 정당한 이익

(2) 처리의 필요성

(3) 정보주체의 권리와 이익 형량

온라인에 공개된 게시물 수집.이용

홈페이지의 성격, 게시물 내용 등에 비추어 사회통념상 동의의사가 있었다고 인정되는 경우

개인정보 최소 수집

-필요 최소한의 개인정보 수집

-최소한의 개인정보 수집이라는 입증책임은 개인정보처리자가 부담

-필요 최소한의 정보 외의 개인정보 수집에는 동의 거부가능

-최소한의 개인정보 이외의 개인정보 수집에 동의하지 않는다는 이유로 재화 등 제공 거부 금지

=> 위반 시 3천만원 이하의 과태료

특별 보호 개인정보

일반 정보주체 외 취약 계층 보호

정보주체에게 미치는 영향이 많아 별도 동의를 받거나 법적 근거에 의해서만 처리 가능

1. 아동의 개인정보 보호-법정 대리인 동의

2. 민감정보 처리 제한-법령 근거 혹은 별도 동의 획득

3. 고유식별정보 처리 제한-법령 근거 혹은 별도 동의 획득

4. 주민등록번호 처리 제한-법령 근거

수집.동의 단계 개인정보 보호 원칙

1. 개인정보 수집 목적을 명확히 하기

2. 개인정보 수집할 때 반드시 적법 근거 확인

3. 개인정보는 목적 범위 내에서 최소한으로 수집하기

4. 개인정보 수집에 동의를 받을 때는 정보주체의 선택권을 보장

5. 14세 미만 아동의 개인정보 수집 시에는 법정대리인의 동의를 받기

6. 민감정보. 고유식별정보. 주민등록번호 수집의 법적 근거는 한번 더 확인하기

7. 개인정보 수집 전에 반드시 개인정보보호 담당자의 검토 받기