본문 바로가기
일반IT/IT보안

주민번호가 사라진 자리에 생긴 것 — CI(연계정보)의 정체 🔐

by gasbugs 2026. 4. 7.
반응형

"당신의 주민번호는 사라졌지만, 그 그림자는 여전히 인터넷을 떠돌고 있다."

🎯 이 글에서 다루는 것

  • CI(Connecting Information)가 무엇인지, 왜 만들어졌는지
  • CI가 88바이트인 이유 — 해시 알고리즘의 비밀
  • CI 생성 과정 (주민번호 → HMAC → Base64)
  • CI vs DI, 차이점과 각각의 용도
  • CI를 둘러싼 개인정보 보호 논란

📌 도입 / 배경 — 주민번호를 없애려다 생긴 것

2014년, 대한민국은 민간 기업의 주민등록번호 수집을 원칙적으로 금지했습니다. 수년간 반복된 대규모 개인정보 유출 사고가 그 배경이었습니다. 카드사, 통신사, 쇼핑몰 — 어디에나 주민번호가 쌓여 있었고, 털릴 때마다 수천만 건씩 쏟아졌습니다.

 

그런데 문제가 생겼습니다. 주민번호를 못 쓰면, 온라인에서 "이 사람이 저 사람과 같은 사람인지"를 어떻게 확인하느냐는 것입니다. 예를 들어 A 쇼핑몰과 B 포인트 앱이 제휴 서비스를 연동할 때, 두 서비스에 가입한 "홍길동"이 동일 인물인지 확인하는 수단이 필요했습니다.

그래서 탄생한 것이 바로 CI(Connecting Information), 연계정보입니다.

 

CI는 온라인에서 서로 다른 인터넷 업체 간 동일인을 식별하기 위해 사용하며, 본인확인기관이 주민등록번호를 암호화하여 생성한 88바이트의 정보입니다.


🔍 CI란 정확히 무엇인가?

CI의 정의

CI(Connecting Information)는 특정 개인의 식별을 위한 고유한 범용 Key값입니다. 주민번호 기반으로 생성되기 때문에 유일성이 보장되고, 일방향 암호화를 이용하기 때문에 복호화가 불가능합니다.

쉽게 말하면, 주민번호를 해시로 갈아버린 뒤 Base64로 인코딩한 88자짜리 문자열입니다.

실제 CI 값 예시는 아래와 같이 생겼습니다:

wEi9oYSuekQGxT9MV4rKHG4CO+Zrp+onhLIIuembI8jx/0PLF5Ne3oMBxvUFlN4UmsgjeNErZfmpCVUFH..

 

영어 대소문자 + 숫자 + 특수문자(+, /, =)가 섞인 88자입니다. 어디서 많이 보셨죠? 맞습니다. Base64 인코딩 특유의 형태입니다.

왜 88바이트인가?

여기서 앞서 질문의 답이 나옵니다. 88바이트는 SHA-512 해시 결과를 Base64 인코딩했을 때 나오는 크기입니다.

해시 알고리즘으로는 SHA-512 암호화 알고리즘이 사용됩니다.

단계 설명  크기
SHA-512 해시 출력 512비트 = 64바이트 (바이너리) 64바이트
Base64 인코딩 3바이트 → 4문자 변환 64 × 4/3 ≈ 88자

 

즉 SHA-256이 아니라 SHA-512 + Base64 조합이기 때문에 88바이트가 나오는 것입니다. ✅


🔧 CI 생성 과정 — 단계별 분해

첫 단계로 주민번호(RN)와 비밀번호(SA, SK)를 조합합니다. 여기서 비밀번호는 본인확인기관과 KISA가 공유하는 64바이트의 비밀정보입니다. 두 번째로 주민번호와 비밀번호가 조합된 값을 일방향 암호화 알고리즘인 해시 함수로 암호화합니다.

정리하면 다음과 같습니다:

주민번호 + KISA 공유 비밀키(64바이트)
        ↓
   HMAC-SHA-512 (일방향 해시)
        ↓
    64바이트 바이너리
        ↓
   Base64 인코딩
        ↓
    CI (88바이트 문자열)

여기서 핵심은 단순 해시가 아니라 HMAC(Hash-based Message Authentication Code)를 사용한다는 점입니다. HMAC은 비밀키를 함께 섞어서 해시를 생성하므로, KISA와 본인확인기관만이 동일한 CI를 재현할 수 있습니다.

Python 유사 코드 예시

import hmac
import hashlib
import base64

# 주민번호 + KISA 공유 비밀키
resident_number = "9001011234567"
secret_key = b"KISA_SHARED_SECRET_64BYTES_..."  # 실제 비밀키는 비공개

# HMAC-SHA512로 해시 생성
hmac_result = hmac.new(
    secret_key,
    resident_number.encode("utf-8"),
    hashlib.sha512
).digest()  # 64바이트 바이너리

# Base64 인코딩 → 88자 CI 생성
ci = base64.b64encode(hmac_result).decode("utf-8")
print(f"CI 길이: {len(ci)}")  # 88
print(f"CI: {ci}")

⚠️ 실제 KISA 비밀키는 절대 공개되지 않습니다. 위 코드는 개념 이해용 유사 코드입니다.


🆚 CI vs DI — 무엇이 다른가?

DI는 Duplication Information의 약자로 64바이트로 된 정보입니다. 서비스 내의 중복 가입 회원 정보이며, DI는 한 서비스에 단 하나의 DI만이 존재합니다. 각 서비스마다의 DI는 서로 다르기 때문에 각 서비스를 서로 연계하려면 CI 정보를 사용해야 합니다.

항목 CI(연계정보) DI(중복가입확인정보)
약자 Connecting Information Duplication Information
크기 88바이트 64바이트
유일성 전국 모든 서비스에서 동일 같은 서비스 내에서만 동일
용도 서비스 간 동일인 연결 특정 서비스 내 중복 가입 방지
주민번호 매칭 1:1 매칭 사이트별로 다름

 

쉬운 비유: CI는 주민번호처럼 어디서나 쓰이는 전국구 ID, DI는 특정 사이트에서만 통하는 멤버십 번호입니다.


⚠️ 주의사항 / CI를 둘러싼 논란

1. "제2의 주민번호" 문제

연계정보는 주민등록번호를 해시함수를 이용해 변환하되 '본인확인기관간 공유 비밀정보'를 추가해 생성하고, 한 번 부여되면 주민등록번호를 변경하지 않는 한 변경할 수 없어 가히 제2의 주민등록번호라고 할 수 있습니다.

2. 유출 시 대응 불가

주민등록번호를 없애고자 도입한 CI인데 주민번호와 1:1 매칭됨으로써 CI로 개인 식별이 가능하게 되었습니다. 유출이 되어도 본인은 수정 권한이 없기 때문에 대응 방법이 없습니다.

3. 개인정보보호법상 암호화 의무

개인정보처리자는 주민등록번호가 분실·도난·유출·위조·변조 또는 훼손되지 않도록 암호화 조치를 통하여 안전하게 보관해야 합니다. 이를 위반하여 암호화 조치를 하지 않은 경우에는 3천만 원 이하의 과태료가 부과됩니다.

CI 역시 개인정보에 해당하므로, 서비스 사업자가 DB에 CI를 저장할 때는 AES-256 등 안전한 알고리즘으로 암호화 보관해야 합니다.

일반적으로 AES-256, SHA-256 이상을 쓰면 논란의 여지가 없습니다.


✅ 정리 / 마무리

항목 내용
CI 정의 주민번호 기반 일방향 해시 연계정보
해시 알고리즘 HMAC-SHA-512
크기 64바이트(바이너리) → Base64 → 88바이트
복호화 가능 여부 ❌ 불가 (일방향)
생성 주체 본인확인기관 (NICE, KCB, 이통사 등)
법적 규제 개인정보보호법 암호화 의무 대상

 

CI는 주민번호의 대안으로 태어났지만, 사실상 주민번호와 1:1 대응되는 영구 식별자입니다. 개인정보 보호 측면에서 여전히 논란이 있으며, 한국 고유의 독특한 본인확인 체계를 이해하는 데 핵심 개념입니다.

 

심화 학습을 원하신다면 KISA 본인확인 지원포털개인정보의 안전성 확보조치 기준 안내서(2024년 10월판)를 참고하시길 권장합니다.

반응형