실무 가이드

CI·DI를 쓰는 서비스라면 주목! 개인정보 처리방침에서 꼭 확인해야 할 5가지 체크리스트

CI DI를 쓰는 서비스의 개인정보 처리방침 점검 항목 썸네일

CI·DI를 쓰는 서비스라면 개인정보 처리방침에서 꼭 확인해야할 5가지

안녕하세요, 서비스 기획자와 개발자, 그리고 개인정보 보호 담당자 여러분!

여러분의 개인정보보호 전담 부서, 캐치시큐입니다.

개발 문서나 기획서에서 CI(연계정보), DI(중복가입확인정보)라는 단어, 정말 자주 보시죠? 사실 이 개념이 무엇인지 설명하는 글은 많아요. >> CI vs DI, 이게 뭔데 털리면 안된다는거예요?

하지만 실무자에게 진짜 중요한 건 이론이 아니죠. “개념은 알겠는데, 그래서 우리 서비스 개인정보 처리방침이랑 동의서에 이게 제대로 반영되어 있는 거야?”라는 질문입니다.

회원가입, 본인인증, 중복가입 방지, 이벤트 중복 참여 제한, 고객 DB 관리까지… 본인확인값이 조금이라도 발을 걸치고 있는 서비스라면 처리방침, 동의서, 보유기간, 접근권한이 톱니바퀴처럼 딱딱 맞물려 돌아가야 합니다. 단순히 문서 한 줄 고친다고 끝날 일이 아니라는 뜻이죠.

오늘은  실제 시스템 데이터와 고객 안내 문구의 싱크율을 100%로 맞추기 위해 실무자가 지금 당장 확인해야 할 5가지 핵심 포인트를 짚어보겠습니다.

💡 한눈에 보는 핵심 요약

  • 수집 항목: 텍스트로만 적힌 항목(이름, 번호) 외에 실제 DB에 쌓이는 CI·DI가 누락되지 않았는지 확인하세요.

  • 이용 목적: “서비스 제공”이라는 만능 치트키 뒤에 숨지 말고, ‘중복가입 방지’, ‘부정 이용 방지’ 등 진짜 목적을 쪼개어 적어야 합니다.

  • 보유 및 파기: “회원 탈퇴 시 즉시 파기”라고 써두고, 별도 테이블에 본인확인값을 그대로 남겨두는 실수를 잡아야 합니다.

  • 외부 협력사 관계: 본인확인기관, CRM 툴 등 데이터가 흘러가는 길목에 있는 업체들이 ‘위탁’인지 ‘제3자 제공’인지 명확히 하세요.

  • 접근 권한: 고객 눈에 안 보인다고 방치하면 안 됩니다. 내부 관리자 중 “누가, 왜 볼 수 있는지” 통제하고 기록해야 합니다.

1. 우리 수집 항목에 CI·DI가 투명하게 드러나 있나요?

휴대폰 본인인증, 패스(PASS), 카카오·네이버 간편인증, 아이핀 등을 도입한 서비스라면 백엔드에서는 이미 CI나 DI 같은 값이 열심히 생성되어 돌아다니고 있을 확률이 높습니다.

가장 흔하게 하는 실수 🚨

“우리가 직접 주민등록번호를 수집하는 건 아니니까, 처리방침에는 그냥 ‘이름, 휴대전화번호, 이메일’만 적으면 되겠지?”

실무 점검에서 가장 먼저 걸리는 지점이 바로 여기입니다. 시스템 안에서는 엄연히 식별값(CI·DI)이 쓰이고 있는데, 문서에는 쏙 빠져 있는 경우죠.

인증 모듈, 회원 DB, CRM, 이벤트 신청 폼이 유기적으로 연결되어 있다면 어느 단계에서 이 값이 저장되는지 전수조사해야 합니다. 값을 저장하지 않고 1회성 검증으로만 끝내는지, 아니면 내부 회원 일련번호(User Key)와 매핑해 계속 보관하는지에 따라 처리방침 문구와 보유기간 기준이 완전히 달라집니다.

2. 이용 목적을 그냥 “본인확인”으로 적어놓고 있진 않나요?

CI·DI는 보통 본인확인, 중복가입 방지, 계정 복구, 부정 이용 방지 등의 목적으로 사용됩니다. 그런데 많은 서비스가 귀찮거나 잘 모른다는 이유로 처리방침이나 동의서에 ‘서비스 제공 및 운영’이라는 너무 넓은 표현으로 뭉뚱그려 놓곤 합니다.

목적을 너무 넓게 잡으면, 나중에 꼼꼼한 사용자가 “왜 내 식별값까지 가져간 건가요?”라고 문의했을 때 명쾌하게 대응하기 어려워집니다.

  • 본인확인용인가요?

  • 이벤트 중복 응모를 막기 위함인가요?

  • 악성 유저의 재가입(부정 이용)을 막기 위함인가요?

특히 마케팅·이벤트 목적과 본인확인 목적을 한 문장에 섞어 쓰는 것은 금물입니다. 본인확인은 필수 절차일 수 있지만, 마케팅 활용은 엄연히 고객의 ‘선택 동의’를 받아야 하는 영역이니까요. UX 화면 안에서 깔끔하게 목적을 분리해 설계해 주세요.

3. 회원 DB가 지워질 때, 식별값도 같이 파기되나요?

개인정보 처리방침에는 “회원 탈퇴 시 즉시 파기”라고 아주 모범적으로 적어두는 경우가 많습니다. 하지만 엔지니어링 단을 뜯어보면 다른 세상 이야기일 때가 많죠.

  • 회원 정보 테이블은 날아갔는데, 본인확인값과 회원키가 매핑된 별도 테이블은 그대로 남아 있다면?

  • 마케팅 이벤트 폼은 마감 후 삭제했는데, 중복 응모 방지용 식별값 엑셀 파일이 마케팅팀 PC에 따로 보관되어 있다면?

이러면 모두 방침 위반입니다. 보유기간과 파기는 문장 한 줄로 끝나지 않습니다. 실제 DB, 관리자 화면에서 다운로드한 파일, 외부 수탁사 데이터, 백업 서버, 로그 기록까지 모두 동일한 파기 사이클을 공유해야 합니다.

참고 : 보유 기간 기준을 정리할 때 개인정보 보유 기간은 언제까지일까?에서 다룬 기본 원칙도 함께 확인하면 좋습니다.👍

4. 데이터가 흐르는 길목, 위탁과 제3자 제공을 구분했나요?

본인인증을 하려면 외부 본인확인기관(통신사, KCB 등), 인증 서비스 사업자, 알림톡/문자 발송사, 클라우드, CRM 툴, 고객센터 시스템 등 수많은 외부 파트너를 거치게 됩니다.

이때 실무자는 단순히 처리방침 맨 아래에 협력사 이름 몇 개 추가하는 것으로 만족해서는 안 됩니다. “우리 서비스에서 생성된 CI·DI를 누가 만들고, 누가 전달받고, 최종적으로 누가 저장하는가?”라는 데이터 흐름도(Data Flow)를 그릴 줄 알아야 합니다.

단순히 우리 업무를 대행하는 ‘수탁사’인지, 독립적인 목적으로 데이터를 가져가는 ‘제3자’인지 계약 구조를 명확히 하고, 그에 맞는 법적 의무 사항(재위탁 제한, 파기 확인 등)을 처리방침에 녹여내야 안전합니다.

5. “누가 볼 수 있지?” 접근 권한과 조회 이력 관리

CI·DI는 고객이 마이페이지에서 직접 확인할 수 있는 정보가 아닙니다. 암호화된 텍스트 형태로 시스템 내부에 숨어있죠. 눈에 보이지 않기 때문에 내부 통제가 더욱 중요합니다.

고객센터 관리자 페이지나 CRM 대시보드에서 회원 식별값이나 본인확인 결과 조회가 가능하다면, 담당자의 권한을 엄격하게 제한해야 합니다.

  • 퇴사자나 부서 이동자의 권한은 즉시 회수되고 있는가?

  • 관리자 화면에서 해당 데이터의 대량 다운로드를 제한하고 있는가?

  • 누군가 이 정보를 조회, 변경, 삭제했을 때 “누가, 언제, 왜” 했는지 로그(이력)가 남는가?

CI·DI 리스크의 관리 명제는 하나입니다. “무슨 값인가”보다 “누가 어떤 목적으로 볼 수 있는가”.

CI DI를 쓰는 서비스가 확인할 개인정보 처리방침 체크리스트 이미지

🛠️ 실무자용 “싱크율 100%” 자가 진단 체크리스트

내 컴퓨터에 메모장 하나를 켜고, 우리 서비스 화면을 직접 눌러보며 아래 항목에 체크해 보세요.

✅ 회원가입 / 로그인 / 본인인증 / 이벤트 신청 흐름에서 CI·DI(본인확인 결과값)가 실제로 쓰이고 있나요?

✅ 개인정보 처리방침의 ‘수집 항목’에 이 값이 명시되어 있나요?

✅ 이용 목적이 본인확인, 중복가입 방지, 부정 이용 방지 등으로 구체적으로 쪼개져 있나요?

✅ 마케팅/프로모션 동의 문구와 본인확인 동의 문구가 뒤섞여 있지 않나요?

✅ 회원이 탈퇴하거나 이벤트가 끝나면, DB와 엑셀 파일에 남은 식별값 매핑 데이터가 함께 지워지나요?

✅ 본인확인기관, 문자 발송사 등 외부 업체와의 계약 관계(위탁/제공)가 처리방침과 일치하나요?

✅ 내부 관리자 화면에서 식별값을 볼 수 있는 직원의 권한이 제한되어 있나요?

✅ 관리자가 해당 정보를 조회하거나 다운로드할 때 감사 로그(Audit Log)가 남나요?

(※ 본 체크리스트는 법적 판단을 대신하지 않습니다.)

🤝 복잡한 개인정보 관리, 혼자 앓지 마세요

고객에게는 낯설고, 실무자에게는 복잡한 CI·DI와 개인정보 규제. “우리 서비스 문서와 실제 시스템이 일치하는지” 확신이 서지 않는다면 개인정보보호 전문 솔루션의 도움을 받는 것도 방법입니다.

캐치시큐는 복잡한 수집 항목, 보유기간, 수탁사 관리, 동의 문구부터 파기 기준까지 기업이 꼭 챙겨야 할 개인정보 관리 항목을 체계적으로 정리해 드립니다.

특히 이벤트, 상담 신청, 설문조사 등 수많은 페이지로 개인정보가 흩어져 들어오는 구조라면 캐치폼을 통해 용도별 동의 문구와 파기 시점을 일관되게 컨트롤할 수 있습니다.

우리 서비스의 처리방침과 동의서, 제대로 가고 있는지 점검이 필요하다면 아래 상담 링크를 통해 전문가의 진단을 받아보세요!

캐치시큐 개인정보보호 무료 상담 CTA 배너
Hera Kim 에디터 프로필

Editor

Hera Kim

개인정보보호가 당연한 세상을 위해, 실무자가 이해하고 바로 적용할 수 있는 콘텐츠를 씁니다.

참고: 이 글은 CI·DI를 활용하는 서비스의 개인정보 처리방침, 동의서, 보유기간, 위탁·제3자 제공, 접근권한 기준을 점검하기 위한 실무 콘텐츠입니다. 개별 조직의 법적 판단은 실제 서비스 구조, 처리 항목, 계약 관계, 보관 방식에 따라 달라질 수 있습니다.

# 실무 가이드

관련 최신글

CI DI를 쓰는 서비스의 개인정보 처리방침 점검 항목 썸네일

CI·DI를 쓰는 서비스라면 개인정보 처리방침에서 꼭 확인해야할 5가지

안녕하세요, 서비스 기획자와 개발자, 그리고 개인정보 보호 담당자 여러분!

여러분의 개인정보보호 전담 부서, 캐치시큐입니다.

개발 문서나 기획서에서 CI(연계정보), DI(중복가입확인정보)라는 단어, 정말 자주 보시죠? 사실 이 개념이 무엇인지 설명하는 글은 많아요. >> CI vs DI, 이게 뭔데 털리면 안된다는거예요?

하지만 실무자에게 진짜 중요한 건 이론이 아니죠. “개념은 알겠는데, 그래서 우리 서비스 개인정보 처리방침이랑 동의서에 이게 제대로 반영되어 있는 거야?”라는 질문입니다.

회원가입, 본인인증, 중복가입 방지, 이벤트 중복 참여 제한, 고객 DB 관리까지… 본인확인값이 조금이라도 발을 걸치고 있는 서비스라면 처리방침, 동의서, 보유기간, 접근권한이 톱니바퀴처럼 딱딱 맞물려 돌아가야 합니다. 단순히 문서 한 줄 고친다고 끝날 일이 아니라는 뜻이죠.

오늘은  실제 시스템 데이터와 고객 안내 문구의 싱크율을 100%로 맞추기 위해 실무자가 지금 당장 확인해야 할 5가지 핵심 포인트를 짚어보겠습니다.

💡 한눈에 보는 핵심 요약

  • 수집 항목: 텍스트로만 적힌 항목(이름, 번호) 외에 실제 DB에 쌓이는 CI·DI가 누락되지 않았는지 확인하세요.

  • 이용 목적: “서비스 제공”이라는 만능 치트키 뒤에 숨지 말고, ‘중복가입 방지’, ‘부정 이용 방지’ 등 진짜 목적을 쪼개어 적어야 합니다.

  • 보유 및 파기: “회원 탈퇴 시 즉시 파기”라고 써두고, 별도 테이블에 본인확인값을 그대로 남겨두는 실수를 잡아야 합니다.

  • 외부 협력사 관계: 본인확인기관, CRM 툴 등 데이터가 흘러가는 길목에 있는 업체들이 ‘위탁’인지 ‘제3자 제공’인지 명확히 하세요.

  • 접근 권한: 고객 눈에 안 보인다고 방치하면 안 됩니다. 내부 관리자 중 “누가, 왜 볼 수 있는지” 통제하고 기록해야 합니다.

1. 우리 수집 항목에 CI·DI가 투명하게 드러나 있나요?

휴대폰 본인인증, 패스(PASS), 카카오·네이버 간편인증, 아이핀 등을 도입한 서비스라면 백엔드에서는 이미 CI나 DI 같은 값이 열심히 생성되어 돌아다니고 있을 확률이 높습니다.

가장 흔하게 하는 실수 🚨

“우리가 직접 주민등록번호를 수집하는 건 아니니까, 처리방침에는 그냥 ‘이름, 휴대전화번호, 이메일’만 적으면 되겠지?”

실무 점검에서 가장 먼저 걸리는 지점이 바로 여기입니다. 시스템 안에서는 엄연히 식별값(CI·DI)이 쓰이고 있는데, 문서에는 쏙 빠져 있는 경우죠.

인증 모듈, 회원 DB, CRM, 이벤트 신청 폼이 유기적으로 연결되어 있다면 어느 단계에서 이 값이 저장되는지 전수조사해야 합니다. 값을 저장하지 않고 1회성 검증으로만 끝내는지, 아니면 내부 회원 일련번호(User Key)와 매핑해 계속 보관하는지에 따라 처리방침 문구와 보유기간 기준이 완전히 달라집니다.

2. 이용 목적을 그냥 “본인확인”으로 적어놓고 있진 않나요?

CI·DI는 보통 본인확인, 중복가입 방지, 계정 복구, 부정 이용 방지 등의 목적으로 사용됩니다. 그런데 많은 서비스가 귀찮거나 잘 모른다는 이유로 처리방침이나 동의서에 ‘서비스 제공 및 운영’이라는 너무 넓은 표현으로 뭉뚱그려 놓곤 합니다.

목적을 너무 넓게 잡으면, 나중에 꼼꼼한 사용자가 “왜 내 식별값까지 가져간 건가요?”라고 문의했을 때 명쾌하게 대응하기 어려워집니다.

  • 본인확인용인가요?

  • 이벤트 중복 응모를 막기 위함인가요?

  • 악성 유저의 재가입(부정 이용)을 막기 위함인가요?

특히 마케팅·이벤트 목적과 본인확인 목적을 한 문장에 섞어 쓰는 것은 금물입니다. 본인확인은 필수 절차일 수 있지만, 마케팅 활용은 엄연히 고객의 ‘선택 동의’를 받아야 하는 영역이니까요. UX 화면 안에서 깔끔하게 목적을 분리해 설계해 주세요.

3. 회원 DB가 지워질 때, 식별값도 같이 파기되나요?

개인정보 처리방침에는 “회원 탈퇴 시 즉시 파기”라고 아주 모범적으로 적어두는 경우가 많습니다. 하지만 엔지니어링 단을 뜯어보면 다른 세상 이야기일 때가 많죠.

  • 회원 정보 테이블은 날아갔는데, 본인확인값과 회원키가 매핑된 별도 테이블은 그대로 남아 있다면?

  • 마케팅 이벤트 폼은 마감 후 삭제했는데, 중복 응모 방지용 식별값 엑셀 파일이 마케팅팀 PC에 따로 보관되어 있다면?

이러면 모두 방침 위반입니다. 보유기간과 파기는 문장 한 줄로 끝나지 않습니다. 실제 DB, 관리자 화면에서 다운로드한 파일, 외부 수탁사 데이터, 백업 서버, 로그 기록까지 모두 동일한 파기 사이클을 공유해야 합니다.

참고 : 보유 기간 기준을 정리할 때 개인정보 보유 기간은 언제까지일까?에서 다룬 기본 원칙도 함께 확인하면 좋습니다.👍

4. 데이터가 흐르는 길목, 위탁과 제3자 제공을 구분했나요?

본인인증을 하려면 외부 본인확인기관(통신사, KCB 등), 인증 서비스 사업자, 알림톡/문자 발송사, 클라우드, CRM 툴, 고객센터 시스템 등 수많은 외부 파트너를 거치게 됩니다.

이때 실무자는 단순히 처리방침 맨 아래에 협력사 이름 몇 개 추가하는 것으로 만족해서는 안 됩니다. “우리 서비스에서 생성된 CI·DI를 누가 만들고, 누가 전달받고, 최종적으로 누가 저장하는가?”라는 데이터 흐름도(Data Flow)를 그릴 줄 알아야 합니다.

단순히 우리 업무를 대행하는 ‘수탁사’인지, 독립적인 목적으로 데이터를 가져가는 ‘제3자’인지 계약 구조를 명확히 하고, 그에 맞는 법적 의무 사항(재위탁 제한, 파기 확인 등)을 처리방침에 녹여내야 안전합니다.

5. “누가 볼 수 있지?” 접근 권한과 조회 이력 관리

CI·DI는 고객이 마이페이지에서 직접 확인할 수 있는 정보가 아닙니다. 암호화된 텍스트 형태로 시스템 내부에 숨어있죠. 눈에 보이지 않기 때문에 내부 통제가 더욱 중요합니다.

고객센터 관리자 페이지나 CRM 대시보드에서 회원 식별값이나 본인확인 결과 조회가 가능하다면, 담당자의 권한을 엄격하게 제한해야 합니다.

  • 퇴사자나 부서 이동자의 권한은 즉시 회수되고 있는가?

  • 관리자 화면에서 해당 데이터의 대량 다운로드를 제한하고 있는가?

  • 누군가 이 정보를 조회, 변경, 삭제했을 때 “누가, 언제, 왜” 했는지 로그(이력)가 남는가?

CI·DI 리스크의 관리 명제는 하나입니다. “무슨 값인가”보다 “누가 어떤 목적으로 볼 수 있는가”.

CI DI를 쓰는 서비스가 확인할 개인정보 처리방침 체크리스트 이미지

🛠️ 실무자용 “싱크율 100%” 자가 진단 체크리스트

내 컴퓨터에 메모장 하나를 켜고, 우리 서비스 화면을 직접 눌러보며 아래 항목에 체크해 보세요.

✅ 회원가입 / 로그인 / 본인인증 / 이벤트 신청 흐름에서 CI·DI(본인확인 결과값)가 실제로 쓰이고 있나요?

✅ 개인정보 처리방침의 ‘수집 항목’에 이 값이 명시되어 있나요?

✅ 이용 목적이 본인확인, 중복가입 방지, 부정 이용 방지 등으로 구체적으로 쪼개져 있나요?

✅ 마케팅/프로모션 동의 문구와 본인확인 동의 문구가 뒤섞여 있지 않나요?

✅ 회원이 탈퇴하거나 이벤트가 끝나면, DB와 엑셀 파일에 남은 식별값 매핑 데이터가 함께 지워지나요?

✅ 본인확인기관, 문자 발송사 등 외부 업체와의 계약 관계(위탁/제공)가 처리방침과 일치하나요?

✅ 내부 관리자 화면에서 식별값을 볼 수 있는 직원의 권한이 제한되어 있나요?

✅ 관리자가 해당 정보를 조회하거나 다운로드할 때 감사 로그(Audit Log)가 남나요?

(※ 본 체크리스트는 법적 판단을 대신하지 않습니다.)

🤝 복잡한 개인정보 관리, 혼자 앓지 마세요

고객에게는 낯설고, 실무자에게는 복잡한 CI·DI와 개인정보 규제. “우리 서비스 문서와 실제 시스템이 일치하는지” 확신이 서지 않는다면 개인정보보호 전문 솔루션의 도움을 받는 것도 방법입니다.

캐치시큐는 복잡한 수집 항목, 보유기간, 수탁사 관리, 동의 문구부터 파기 기준까지 기업이 꼭 챙겨야 할 개인정보 관리 항목을 체계적으로 정리해 드립니다.

특히 이벤트, 상담 신청, 설문조사 등 수많은 페이지로 개인정보가 흩어져 들어오는 구조라면 캐치폼을 통해 용도별 동의 문구와 파기 시점을 일관되게 컨트롤할 수 있습니다.

우리 서비스의 처리방침과 동의서, 제대로 가고 있는지 점검이 필요하다면 아래 상담 링크를 통해 전문가의 진단을 받아보세요!

캐치시큐 개인정보보호 무료 상담 CTA 배너
Hera Kim 에디터 프로필

Editor

Hera Kim

개인정보보호가 당연한 세상을 위해, 실무자가 이해하고 바로 적용할 수 있는 콘텐츠를 씁니다.

참고: 이 글은 CI·DI를 활용하는 서비스의 개인정보 처리방침, 동의서, 보유기간, 위탁·제3자 제공, 접근권한 기준을 점검하기 위한 실무 콘텐츠입니다. 개별 조직의 법적 판단은 실제 서비스 구조, 처리 항목, 계약 관계, 보관 방식에 따라 달라질 수 있습니다.

# 실무 가이드
관련 최신글
인기글
CI vs DI, 이게 뭔데 털리면 안된다는거예요? 티빙과 쿠팡 사례로 알아보는 개인정보 유출

개인정보관리는 캐치시큐

지금 바로 시작하세요!

개인정보보호에 고민이 있으신가요? 언제든지 문의주세요!
개인정보관리는 캐치시큐

지금 바로 시작하세요!

개인정보보호에 고민이 있으신 가요? 언제든지 문의주세요!
메뉴
X
error: 컨덴츠는 보호됩니다.