CI 뜻과 개인정보 처리 주의사항: CI·DI를 쓰는 서비스가 점검할 것
CI는 Connecting Information의 약자로, 우리말로는 연계정보라고 부릅니다. 온라인에서 본인확인을 하거나 서로 다른 서비스 사이에서 같은 이용자를 식별해야 할 때 등장하는 값입니다.
예전에는 “CI가 무엇인가요?”라는 질문이 주로 개념 설명에 가까웠습니다. 하지만 서비스를 운영하는 입장에서는 이제 질문이 조금 달라져야 합니다. 우리 서비스가 CI나 DI를 쓰고 있다면 개인정보 처리방침, 동의 문구, 보유기간, 수탁사 관계에 제대로 반영되어 있는가를 함께 봐야 합니다.
먼저 알아둘 핵심 요약
- CI는 Connecting Information의 약자로, 여러 서비스 사이에서 같은 이용자를 연계해 식별하는 값입니다.
- DI는 보통 특정 서비스나 사업자 영역 안에서 이용자를 구분하는 값으로 함께 언급됩니다.
- CI는 주민등록번호를 그대로 저장하는 것과는 다르지만, 다른 정보와 연결되면 특정 개인을 알아보는 데 쓰일 수 있습니다.
- 서비스에서 CI·DI를 사용한다면 처리 목적, 보관기간, 제3자 제공·위탁 여부, 파기 기준을 문서에 반영해야 합니다.
CI는 무엇인가요?
CI는 Connecting Information의 약자입니다. 이름 그대로 여러 정보나 서비스를 연결할 때 같은 이용자인지 확인하기 위해 쓰이는 연계정보입니다. 본인확인기관이 주민등록번호를 바탕으로 생성하는 식별값으로 설명되며, 온라인 서비스에서 동일인을 식별하는 데 활용되어 왔습니다.
중요한 점은 CI가 단순한 임의 문자열이 아니라는 것입니다. 이름이나 휴대전화번호처럼 사람이 바로 읽을 수 있는 정보는 아니지만, 특정 개인을 구분하거나 다른 정보와 연결하는 데 사용될 수 있습니다. 그래서 CI는 기술값이면서 동시에 개인정보보호 실무에서 관리해야 할 대상입니다.
CI가 등장한 배경
과거에는 온라인 본인확인에서 주민등록번호가 널리 사용되었습니다. 하지만 주민등록번호는 한 번 유출되면 바꾸기 어렵고, 다양한 서비스에서 같은 번호가 반복 사용되기 때문에 큰 위험을 만들었습니다.
이후 주민등록번호 수집 제한 정책이 강화되면서, 주민등록번호를 그대로 쓰지 않으면서도 본인확인과 이용자 식별을 할 수 있는 수단이 필요해졌습니다. 그 흐름에서 CI가 본인확인과 서비스 연계의 수단으로 활용되기 시작했습니다.
CI는 어떻게 만들어지고 활용되나요?
CI는 주민등록번호를 그대로 노출하지 않고, 본인확인기관을 통해 생성되는 연계정보로 설명됩니다. 기존 글에서 다뤘던 것처럼 CI는 온라인 서비스에서 동일인을 식별하거나 본인확인 결과를 연계하는 맥락에서 활용되어 왔습니다.
이러한 특성 때문에 포인트 제휴, 가맹점 할인, 내정보 확인 서비스 등 본인 확인이 필요한 서비스에 다양하게 활용되어 왔습니다. 다만 활용 범위가 넓어질수록 개인정보보호 관점의 점검도 함께 필요합니다.
CI는 암호화된 값이면 안전한가요?
CI는 주민등록번호를 그대로 저장하는 방식과는 다릅니다. 하지만 “복원이 어렵다”는 점만 보고 안전하다고 판단하면 부족합니다. 개인정보보호 실무에서는 복원 가능성뿐 아니라 어떤 목적에 쓰이는지, 어떤 정보와 연결되는지, 누가 접근할 수 있는지, 언제 삭제되는지를 함께 봐야 합니다.
예를 들어 한 서비스에서 CI를 회원 식별에 사용하고, 다른 시스템에서 상담 이력이나 결제 정보와 연결한다면, CI는 이용자 프로필을 연결하는 기준점이 될 수 있습니다. 이 경우 처리 목적과 보관 기준이 문서에 반영되어 있어야 합니다.
마이데이터와 본인확인 흐름에서 CI가 계속 언급되는 이유
공공정보 마이데이터, 금융 서비스, 본인확인 기반 서비스에서는 이용자를 정확히 식별하면서도 주민등록번호를 직접 쓰지 않는 구조가 중요합니다. 그래서 CI는 서비스 연계와 본인확인 논의에서 반복해서 등장합니다.
다만 기술 발전이나 정책 변화가 있더라도 실무자가 확인해야 할 질문은 크게 달라지지 않습니다. 우리 서비스가 어떤 값으로 이용자를 식별하는지, 그 값이 어떤 시스템과 연결되는지, 고객에게 어떤 문구로 안내되는지 설명할 수 있어야 합니다.
CI와 DI는 어떻게 다를까요?
CI와 DI는 함께 언급되는 경우가 많습니다. 간단히 정리하면, CI는 여러 서비스 사이에서 같은 이용자를 연계해 식별할 수 있는 값으로 이해할 수 있고, DI는 특정 서비스나 사업자 영역 안에서 이용자를 구분하는 값으로 이해하면 쉽습니다.
다만 실제 서비스 구조에서는 이 둘이 모두 이용자 식별과 연결됩니다. 따라서 CI와 DI를 “개발팀이 쓰는 내부 식별값”으로만 보지 말고, 개인정보 처리 현황과 문서 관리 범위에 포함해야 합니다.
서비스 운영자가 확인해야 할 5가지
- 처리 목적: CI·DI를 본인확인, 중복가입 방지, 회원관리, 제휴 연계 중 어떤 목적으로 쓰는지 구분합니다.
- 수집·생성 경로: 본인확인기관, 외부 API, 내부 시스템 중 어디에서 값이 들어오는지 확인합니다.
- 보관기간: 회원 탈퇴, 본인확인 완료, 계약 종료 후 언제까지 보관하는지 정합니다.
- 제공·위탁 관계: 본인확인기관, 운영 대행사, 분석 도구, 고객지원 도구와 연결되는지 확인합니다.
- 처리방침 반영: 개인정보 처리방침, 동의서, 내부 관리대장에 실제 처리 목적과 보관 기준이 일치하는지 봅니다.
처리방침에는 어떻게 반영해야 할까요?
CI나 DI를 처리한다면 개인정보 처리방침에서 수집 항목, 처리 목적, 보유기간, 제3자 제공 또는 위탁 여부를 확인해야 합니다. 특히 “회원관리”처럼 넓은 표현만 쓰면 실제 사용 맥락이 드러나지 않을 수 있습니다.
예를 들어 CI를 중복가입 방지에 쓰는지, 본인확인 결과 보관에 쓰는지, 서비스 간 계정 연계에 쓰는지에 따라 설명이 달라집니다. 같은 CI라도 처리 목적이 다르면 보관기간과 접근 권한도 달라질 수 있습니다.
함께 보면 좋은 글
- CI·DI를 쓰는 서비스라면 개인정보 처리방침에서 먼저 볼 5가지
- CI vs DI, 이게 뭔데 털리면 안된다는거예요?
- 개인정보 보유 기간은 언제까지일까?
- 위탁과 제3자 제공 알아보기
자주 묻는 질문
CI는 개인정보인가요?
CI는 다른 정보와 결합해 특정 개인을 알아볼 수 있는 맥락에서 개인정보로 다뤄질 수 있습니다. 따라서 단순한 기술값이 아니라 개인정보 처리 현황에 포함해 관리하는 편이 안전합니다.
CI를 쓰면 주민등록번호를 안 쓰는 것이니 문제가 없나요?
주민등록번호를 직접 쓰지 않는다는 점은 중요하지만, 그것만으로 충분하지는 않습니다. CI가 어떤 목적에 쓰이고 어떤 정보와 연결되는지, 언제 삭제되는지까지 확인해야 합니다.
DI도 처리방침에 적어야 하나요?
DI가 이용자 식별과 서비스 운영에 사용된다면 처리 항목과 목적을 검토해야 합니다. 실제 문구는 서비스 구조와 수집 경로에 따라 달라질 수 있습니다.
마치며
CI는 온라인 본인확인과 서비스 연계에서 중요한 역할을 해왔습니다. 하지만 서비스 운영자 입장에서는 “CI가 무엇인가”를 아는 것에서 끝나면 부족합니다. 우리 서비스가 CI·DI를 어떤 목적으로 쓰는지, 어디에 저장하는지, 누구에게 맡기는지, 언제 삭제하는지를 설명할 수 있어야 합니다.
CI·DI를 이미 사용하고 있다면 개인정보 처리방침과 동의서, 내부 관리대장부터 확인해 보세요. 검색 유입이 많은 개념 글을 실제 점검 행동으로 연결하려면, 이 지점이 가장 중요합니다.
