CI와 DI 차이 완벽 정리: 휴대폰 본인인증을 하면 따라오는 CI·DI는 도대체 뭘까?

휴대폰으로 회원가입을 하다 보면 익숙한 화면이 등장합니다.

“본인인증을 진행해주세요.”

PASS 앱을 열고, 이름과 휴대폰 번호를 확인하고, 인증을 마치면 서비스는 “본인인증 성공”이라는 결과를 받습니다. 여기까지는 이해하기 쉽습니다.

그런데 개발 문서나 개인정보처리방침을 조금 깊게 들여다보면 갑자기 CI, DI라는 정체불명의 영문 약자가 등장합니다.

“CI? 혹시 개발할 때 쓰는 CI/CD의 CI인가?”

아닙니다. 전혀 다른 친구입니다.

본인확인에서 말하는 CI는 연계정보(Connecting Information), DI는 중복가입확인정보(Duplication Information)를 뜻합니다. 둘 다 온라인에서 “이 사람이 누구인지 구분하는 데 사용하는 식별정보”이지만, 결정적인 차이는 사용 범위입니다. KISA는 CI를 서로 다른 기관 사이에서 동일인을 식별하기 위한 정보, DI를 특정 사이트 안에서 동일인을 식별하기 위한 정보로 설명하고 있습니다. 

CI란 무엇일까? 쉽게 말하면 서비스 사이에서 통하는 공통 식별표
CI는 Connecting Information의 약자로 우리말로는 연계정보라고 부릅니다.

가장 쉽게 설명하면 “온라인 서비스들이 같은 사람인지 확인할 수 있게 해주는 공통 식별값”에 가깝습니다.

예를 들어 홍길동이라는 사람이 A쇼핑몰, B보험사, C멤버십 서비스에서 각각 휴대폰 본인확인을 했다고 가정해 보겠습니다.

A서비스에서는 아이디가 hong123이고 B서비스에서는 이메일로 로그인하고 C서비스에서는 카카오 로그인을 사용한다고 해도, 본인확인 체계에서는 이 세 계정이 동일인 홍길동에게 속한다는 사실을 연결할 필요가 있을 수 있습니다.

이때 사용할 수 있는 것이 CI입니다.

KISA는 CI에 대해 주민등록번호처럼 한 사람에게 하나씩 부여되는 고유한 식별정보이며, 서로 다른 기관 간 동일인을 식별하기 위해 사용한다고 설명합니다. 기술적으로는 본인확인기관이 주민등록번호와 본인확인기관 간 공유비밀정보를 이용해 생성합니다. 

즉 개념적으로 보면 이런 느낌입니다.

CI/DI 설명 예시

서비스마다 로그인 아이디는 전혀 달라도 본인확인 결과로 제공되는 원본 CI는 동일인을 연결할 수 있도록 설계되어 있습니다. 다만 실제 서비스 DB에서는 CI를 암호화하거나 별도의 내부 식별자로 변환해 저장할 수 있기 때문에 DB에서 보이는 문자열까지 항상 똑같아야 한다는 의미는 아닙니다. 

여기서 한 가지 주의할 점이 있습니다.

CI를 흔히 “주민등록번호를 암호화한 값”이라고 표현하기도 하는데, 그렇게 단순하게 이해하는 것은 정확하지 않습니다. CI는 본인확인기관이 주민등록번호와 공유비밀정보 등을 이용해 생성하는 별도의 연계정보이며, 금융위원회 역시 CI를 주민등록번호와 일대일 대응해 생성하되 CI에서 주민등록번호를 복원할 수 없는 값으로 설명한 바 있습니다. 

DI란 무엇일까? 이번에는 사이트 전용 식별표다
DI는 Duplication Information, 우리말로 중복가입확인정보입니다.

CI와 비슷해 보이지만 중요한 차이가 하나 있습니다.

CI가 서비스 사이에서도 같은 사람을 연결하기 위한 값이라면, DI는 기본적으로 특정 웹사이트 범위 안에서 같은 사람인지 확인하기 위한 값입니다.

예를 들어 어떤 사이트가 “1인당 계정은 최대 3개까지만 만들 수 있습니다”라는 정책을 운영한다고 해보겠습니다.

홍길동이 이메일 주소를 계속 바꿔가며 가입하면 이메일만으로는 동일인 여부를 알기 어렵습니다.

하지만 본인확인을 하고 DI를 확인하면 사이트 입장에서는 이렇게 판단할 수 있습니다.

“어라? 이메일은 다른데 DI는 같네. 같은 사람이구나.”

KISA와 관련 고시는 DI를 이용자의 주민등록번호, 웹사이트 식별정보, 본인확인기관 간 공유비밀정보를 이용해 생성하는 정보로 정의하고 있습니다. 따라서 CI와 달리 웹사이트 식별정보가 생성 과정에 들어갑니다. 

조금 과장해서 비유하면 이렇습니다.

CI는 “전국적으로 통하는 사람 번호”에 가깝고,

DI는 “이 건물 안에서 사용하는 사물함 번호”에 가깝습니다.

다른 건물로 가면 사물함 번호가 달라질 수 있지만, 그 사람이 홍길동이라는 사실 자체는 달라지지 않는 식입니다.

정확히 말하면 DI의 범위는 단순히 인터넷 도메인 이름 자체가 아니라 본인확인기관이 부여하는 웹사이트 식별정보를 기준으로 결정됩니다. 그래서 “도메인이 다르면 무조건 DI도 다르다”라고 단정하기보다는 “서로 다른 웹사이트 식별정보라면 DI가 달라진다”고 이해하는 것이 정확합니다. 

CI와 DI 차이를 표 하나로 끝내보자
복잡한 이야기를 모두 내려놓고 핵심만 비교하면 다음과 같습니다.

CI/DI 비교

KISA도 CI와 DI 모두 본인확인 결과로 얻을 수 있는 중요한 개인 식별정보이므로 철저한 관리가 필요하다고 안내하고 있습니다. 

여기서 가장 중요한 문장은 사실 표의 아래쪽에 있습니다.

“CI와 DI는 비밀번호가 아니다.”

이 사실을 놓치면 보안 설계가 아주 이상한 방향으로 달려가기 시작합니다.

CI는 왜 유출되면 문제가 될까? 실제 티빙 사례로 보는 위험성
CI가 최근 보안 업계에서 더 주목받는 이유도 바로 이 “서비스 간 동일인 연결 가능성” 때문입니다.

2026년 9월 과학기술정보통신부 민관합동조사 결과를 인용한 언론 보도에 따르면 티빙 침해사고에서는 활성·휴면·탈퇴·테스트 계정을 포함해 중복 기준 약 3,954만 개의 계정 정보가 유출된 것으로 조사됐습니다. 유출 정보에는 이름, 생년월일, 연락처 등 여러 개인정보와 함께 CI 약 1,320만 건도 포함된 것으로 발표됐습니다. 동일인이 여러 계정을 보유할 수 있어 계정 수가 실제 피해자 수와 동일하다는 의미는 아닙니다. 

회사명을 직접 언급한 이유는 이 사례가 단순한 인터넷 소문이나 익명 커뮤니티 주장이 아니라 2026년 9월 3일 정부 민관합동조사 결과를 토대로 공개 보도된 사건이기 때문입니다. 

그렇다면 CI가 유출됐다고 해서 공격자가 곧바로 내 계정에 로그인할 수 있을까요?

정상적인 서비스라면 그렇지 않아야 합니다.

CI는 “이 사람이 누구인가를 연결하기 위한 식별값”이지 “지금 접속한 사람이 정말 그 사람임을 증명하는 비밀정보”가 아니기 때문입니다.

비유를 하나 들어보겠습니다.

내 주민등록번호를 안다고 해서 은행이 그 사람에게 곧바로 통장을 넘겨주면 큰일입니다.

마찬가지로 어떤 사람이 내 CI를 알고 있다는 이유만으로 서비스를 이용할 권한을 주면 안 됩니다.

문제는 일부 시스템이 CI를 단순한 식별자가 아니라 사실상의 인증수단처럼 취급했을 때 생깁니다. 예를 들어 클라이언트가 보내는 ci 파라미터만 보고 회원을 찾아 개인정보를 반환하거나 로그인 세션을 발급한다면, 다른 경로에서 확보된 실제 CI를 재사용하는 문제가 발생할 수 있습니다.

정부 역시 CI의 중요성을 고려해 안전조치를 강화하는 방향으로 제도를 정비하고 있습니다. KISA는 2025년 연계정보 처리 및 안전조치 안내서를 발간했고, 2026년에는 연계정보 이용기관을 대상으로 안전조치 실태점검 자료와 FAQ를 제공하고 있습니다. 

가장 중요한 보안 개념: 식별과 인증은 다르다
CI를 이해할 때 반드시 구분해야 하는 단어가 세 가지 있습니다.

식별, 인증, 인가입니다.

식별은 “누구인가?”입니다.

인증은 “정말 그 사람인가?”입니다.

인가는 “그 사람이 이 행동을 해도 되는가?”입니다.

KISA 역시 식별을 이름·생년월일·주민번호 등으로 이용자를 고유하게 확인하는 과정으로 설명하고, 인증은 약속된 증명방법을 통해 인가된 사람임을 증명하는 과정으로 구분합니다. 

CI의 핵심 역할은 첫 번째인 식별에 가깝습니다.

예를 들어 정상적인 휴대폰 본인확인 로그인은 대략 다음 흐름으로 구현할 수 있습니다.

text
복사
사용자
   ↓
본인확인 요청
   ↓
PASS / 휴대폰 본인확인기관
   ↓
본인확인 성공
   ↓
서비스 서버가 인증 결과 검증
   ↓
검증된 결과에서 CI 확인
   ↓
CI와 연결된 내부 회원번호 조회
   ↓
로그인 세션 발급
반대로 아래와 같은 구조라면 매우 위험합니다.

text
복사
사용자 → ci=ABCDE12345... 전송

서버:
"우리 DB에 이 CI가 있네?"

→ 해당 회원 개인정보 반환
이 구조에서는 “CI를 제출한 사람”과 “CI의 실제 주인”이 같은 사람인지 검증하지 않았습니다.

즉 CI가 아무리 길고 복잡해 보여도 그것은 접근권한 검사를 대신해주지 않습니다.

OWASP 역시 API 요청에 포함된 정수, UUID, 일반 문자열 등의 식별자를 사용해 객체를 조회하는 경우 서버가 현재 사용자가 해당 객체에 접근할 권한을 가지고 있는지 반드시 검증해야 한다고 설명합니다. 복잡하고 추측하기 어려운 식별자를 사용하더라도 권한 검사는 여전히 필요합니다. 이를 제대로 확인하지 않으면 IDOR 또는 BOLA라고 부르는 객체 수준 접근제어 취약점이 발생할 수 있습니다. 

개발자 입장에서 더 좋은 방법은 사용자가 자신의 CI를 매 요청마다 직접 보내게 하는 구조 자체를 피하는 것입니다.

예를 들어 /api/my-profile?ci=... 대신 이미 인증된 세션에서 현재 사용자를 찾도록 만드는 편이 안전합니다.

text
복사
로그인된 세션
   ↓
내부 user_id 확인
   ↓
해당 user_id가 접근 가능한 데이터 조회
OWASP도 가능한 경우 클라이언트가 전달하는 식별자보다 인증된 세션에서 현재 사용자를 결정하고, 그 사용자에게 허용된 데이터 범위 안에서 객체를 조회하도록 권고합니다. 

즉 “CI를 암호화하면 안전하겠지?”만으로는 부족합니다.

암호화된 CI 문자열 자체를 다시 인증수단처럼 사용한다면 결국 “그 문자열을 가진 사람 = 본인”이라는 잘못된 가정이 남기 때문입니다.

결국 CI와 DI는 이렇게 기억하면 된다
CI와 DI라는 이름 때문에 거창해 보이지만 개념은 생각보다 단순합니다.

CI는 “여러 서비스가 같은 사람인지 연결할 수 있도록 만든 식별값”이고, DI는 “특정 사이트 범위에서 같은 사람이 다시 나타났는지 확인하기 위한 식별값”입니다. KISA도 CI를 서로 다른 기관 간 동일인을 식별하는 정보, DI를 해당 사이트 내 동일인을 식별하는 정보로 설명합니다. 

그리고 보안 관점에서 정말 중요한 결론은 따로 있습니다.

CI가 유출됐다고 해서 곧바로 모든 서비스에 로그인할 수 있어서는 안 됩니다.

만약 어떤 서비스가 “CI 값이 맞으니 본인 맞음”이라고 처리한다면 문제는 CI라는 제도 자체보다 그 서비스를 구현한 인증·인가 구조에 있습니다.

CI는 신분을 연결하는 번호이지 비밀번호가 아닙니다.

DI 역시 마찬가지입니다.

쉽게 표현하면 CI는 “이름표”, 본인확인은 “신분증 검사”, 로그인 세션은 “입장권”, 권한 검사는 “이 입장권으로 VIP룸까지 들어가도 되는지 확인하는 직원” 정도라고 생각하면 됩니다.

이름표 하나 들고 왔다고 VIP룸 문을 열어주면 안 되는 것과 똑같습니다.

최근 실제 대규모 침해사고에서 CI 유출이 확인되고 정부가 CI 이용기관의 안전조치 기준과 실태점검을 강화하고 있다는 점을 고려하면, 사용자에게도 개발자에게도 CI와 DI의 정확한 역할을 이해하는 것이 점점 중요해지고 있습니다.