TL;DR
본인인증 시스템에서 ID·DI·CI는 각각 ‘사용자 이름’, ‘서비스 단위의 고유 식별자’, ‘전역 고유 식별자’를 의미한다.
스폰지밥 에피소드를 통해 식별자 체계의 범위와 역할을 쉽게 정리해보려 한다.
이름이 아니라 ‘본체’를 식별하는 법
인턴 생활 중 사용자 식별과 관련된 기능을 다뤘다.
단순히 아이디(ID)로만 구분하는 게 아니라, 사용자의 고유한 연결 정보(CI, Connecting Information) 를 기준으로 이전 이용 이력이나 데이터 중복 여부를 판단하는 구조였다.
CI는 단순히 인증용 값이 아니라, 서비스 전반에서 동일 인물을 일관되게 인식하게 만드는 본체 식별자라는 걸 처음 알게되었다.
이전 글 [Python hash() 함수가 내 캐싱을 망쳤어] 에서 다뤘던 “입력에 대한 결정적 결과”와 마찬가지로, 이번엔 “사람의 정체성도 결정적으로 식별되어야 한다”는 이야기를 풀어보겠다.
뚱이가 누구냐면
스폰지밥이 사는 비키니시티에는 한 주민이 있습니다.
이름은 뚱이(Patrick Star).
에피소드마다 주소나 생일이 조금씩 다르긴 하지만,
오늘은 그냥 ‘뚱이’로 통일할게요.
그가 들고 있는 건 비키니시티 운전면허증이에요.
시민으로서의 정체성을 증명하는 공식 문서죠.
이건 단순한 이름표가 아닙니다.
그가 누구인지, 어디에 속한 사람인지를 증명하는
일종의 본체 정보라고 할 수 있어요.
1. 이름(ID)만 바꿔봤습니다
게살버거 가게에서 “신규 고객 버거 1개 무료!” 이벤트가 열렸습니다.
뚱이는 어제 이미 공짜 버거를 먹었지만… 오늘 또 먹고 싶었죠.
그래서 안경을 쓰고 이름을 바꿉니다.
“안녕하신가! 제 이름은 뚱이가 아닌데요!”
처음엔 그럴듯했지만,
집게사장은 곧 말합니다.
“그 분홍색 얼굴, 어제 봤던 그놈이잖아!”
이유는 가게 내부 시스템이 뚱이의 DI(서비스 단위 식별자) 를 기억하고 있었기 때문이에요.
참고로 ID는 사용자가 직접 입력하는 값으로, 언제든 바꿀 수 있는 비결정적 식별자(Non-deterministic Identifier)이다.
이메일 주소나 닉네임처럼 외부 입력에 의존하기 때문에, 오타·중복·변경이 모두 발생할 수 있다.
그래서 대부분의 시스템은 ID 자체를 신뢰하지 않고, ID를 내부 식별자(DI) 또는 전역 식별자(CI)와 매핑해 관리한다. 즉, ID는 껍데기일 뿐, 본체가 아니다.
2. DI는 그 가게가 기억하는 나
DI는 쉽게 말해 서비스 내부 고객 번호(Local Deterministic ID)이다.
대부분의 시스템에서 DI는 다음과 같이 생성된다.
DI_service = HMAC(K_service, CI || service_id)
K_service: 서비스 고유의 비밀키
CI: 전역 식별자
service_id: 해당 서비스의 네임스페이스이 구조는 보안을 위한 중요한 속성을 가진다. 같은 사용자가 여러 서비스에 가입해도 각 서비스의 DI는 서로 다르다. (비결정적 연결성, Non-linkability)
서로 다른 키(K_service)와 네임스페이스를 사용하기 때문에 서로의 데이터베이스를 병합하더라도 동일 인물임을 추정할 수 없다.
이건 실무적으로 언링커빌리티(Unlinkability) 라는 중요한 프라이버시 속성으로, 한 서비스의 DI가 외부로 유출되더라도 다른 서비스의 DI나 CI를 역으로 유추할 수 없다.
결국 DI는 서비스가 기억하는 ‘내 얼굴’이지만, 그 얼굴은 그 가게 안에서만 통하는 별명 같은 존재입니다. DI는 쉽게 말해 서비스 내부 고객 번호이다.
게살버거 가게 입장에서는 “이 사람이 어제도 왔었는지, 포인트를 얼마나 썼는지, 불만을 접수한 적이 있는지” 같은 모든 정보를 DI 기준으로 저장한다.
이름(ID)은 매번 다를 수 있지만, 그 가게가 기억하는 “분홍색 덩어리”는 DI 하나로 묶여 있다.
실제 사용 예시
- 온라인 쇼핑몰에서 이메일(ID)은 달라도, 카드 정보나 디바이스로 이전 주문 내역이 남는 경우
- 앱에서 닉네임을 바꿔도 여전히 같은 계정으로 인식되는 경우
- 회사 시스템에서 사번이 바뀌어도, 주민등록번호나 CI가 같다면 같은 사람으로 처리되는 경우
3. CI는 모든 가게가 공유하는 시민증
게살버거 가게에서 쫓겨난 뚱이는 옆집 플랑크톤의 미끼 가게로 향합니다.
“여긴 처음 오니까 이번엔 괜찮겠지?”
하지만 계산대 앞 등록 절차에서 플랑크톤이 말합니다.
“신분증 좀 보여주겠어?”
뚱이는 당당하게 비키니시티 시민증, 즉 CI를 내밉니다.
플랑크톤이 스캔하자마자 삑—
화면에 뜬 문구는 이렇습니다.
“경고! 집게리아 블랙리스트 동일인(CI 일치)”
여기서 CI는 단순한 인증 코드가 아니다.
실제 본인인증 체계에서는 주민등록번호 등 개인식별정보(PII)를 비밀키로 HMAC 처리하거나, SHA-256 같은 비가역적(irreversible) 해시 함수로 변환해 생성한다.
즉, CI는 복호화할 수 있는 값이 아니라 같은 입력에 대해 항상 동일한 출력을 내는 결정적이고 비가역적인 해시 토큰이다. 그래서 해커가 CI를 탈취하더라도 원본 주민번호나 전화번호를 복원하는 것은 수학적으로 불가능하다.
이 덕분에 여러 금융사나 통신사, 공공기관은 서로 다른 DI를 사용하더라도 CI를 통해 사용자의 정체성 일관성(Identity Consistency) 을 유지한다.
한마디로, CI는 “복호화할 수 없는 본체의 그림자”인 셈이다.
정리하자면
[사용자 입력값(ID)] → [서비스 내부 매핑(DI)] → [공통 인증망 매핑(CI)]
| 구분 | 의미 | 비유 | 특징 |
|---|---|---|---|
| ID | 로그인 시 사용하는 이름 | 뚱이가 바꾼 가짜 이름 | 언제든 변경 가능 |
| DI | 서비스 내부에서의 식별자 | 집게사장이 기억하는 분홍색 얼굴 | 서비스 단위 기억 |
| CI | 모든 서비스가 공유하는 본체 식별자 | 비키니시티 시민증 | 전역·불변 |
처음엔 단순히 하나의 필드, 하나의 데이터 포인트로만 봤던 CI가 지금은 시스템이 ‘사람’을 기억하는 방식 전체를 바꾸는 핵심 개념으로 다가온다.
시스템이든 사람의 식별이든, 결국 핵심은 ‘결정성(Determinism)’이라는 걸 다시 한번 느꼈다. 입력은 같았는데 출력이 다르다면, 그건 이미 시스템이 ‘결정성’을 잃었다는 신호이다. 사용자 식별도 마찬가지로 이름(ID)은 언제든 바꿀 수 있고, DI는 서비스마다 달라질 수 있지만, CI라는 본체 식별자가 일관성을 보장한다.
이 경험은 단순히 본인인증 로직을 이해하는 데서 그치지 않다.
결국 코드를 짜는 일도, 사람을 식별하는 일도 일관성과 신뢰를 어떻게 유지할 것인가에 대한 고민이며 혼란을 줄이고 신뢰를 쌓는 방식이라는 걸 몸으로 배웠다.
📸 Image & Reference
ScreenRant – Why Patrick Star’s Name Changes on SpongeBob
ScreenRant – What Patrick Star Actually Does for Work
The Parenting Patch – SpongeBob SquarePants: Chum Bucket Supreme (Season 6, Episode 46)