CI & DI에 대해 알아보기 🔑

안녕하세요. 그린입니다 🍏

이번 포스팅에서는 CI & DI에 대해 알아보려합니다 🙋🏻

 

일단 개발에서 한번쯤 들어보셨을 친숙한 지속적 통합/배포를 나타내는 CI/CD가 아닙니다!

헷갈리시면 안됩니다 🙅🏻

 

그럼 CI & DI라는건 어쩌다 알아보려고 한거야~?

---

CI & DI를 알아보게된 배경

일단 가장 대표적으로 다들 앱을 개발하다보면 회원가입 / 로그인 기능은 거의 구현해보는 기능일거에요.

 

근데 이런 고민 안해보셨나요?

소셜 로그인으로 카카오 로그인과 네이버 로그인, 애플 로그인을 구현해놨다고 가정해볼께요.

 

그럼 카카오 로그인으로 연동된 카카오 계정에서 이메일 및 닉네임을 받아와서 서버를 통해 DB에 값을 저장하겠죠?

그 다음 만약 로그아웃을 하고 네이버 로그인으로 연동된 네이버 계정에서 동일하게 이메일 및 정보를 받아와서 로그인을 시킨다면

 

이 두 유저가 같은 유저인지 어떻게 판단할 수 있을까요?

 

 

카카오와 네이버 로그인에서 얻어올 수 있는 정보는 이메일과 닉네임뿐이라고 가정해볼께요.

 

그렇다면 사실 두 계정 모두 이메일은 다를것이고 또한 닉네임은 중복될 경우도 있기에 고유하지 않습니다.

 

즉, 이 두 로그인으로는 서버 유저 테이블에 저장될 때 두 로그인한 계정이 하나의 사용자인지 판단하기가 불가능하죠.

 

그렇다고 소셜 로그인 시 해당 디바이스 모델 정보들을 받아와 그걸 고유값으로 비교할 수도 있겠지만, 만약 스마트폰을 바꾸거나 다른 장비에서 로그인 한다면..?

 

마찬가지로 같은 사용자인지 판단할 수 없을겁니다. 🥲

 

그래서 많이 하는 방법으로 조금 간단하게 소셜 로그인 시 다음 스텝으로 휴대폰 번호를 입력하여 인증받게하여 이 휴대폰 번호를 가진 같은 사용자라는것을 판단하게도 하죠.

 

그런데 여기도 맹점이 있습니다 🥹

 

휴대폰 번호가 바뀐다면...?

그럼 기존 유저는 고객센터에 연락하여야 되는 불가피한 상황도 발생할거고 기존 해당 유저가 사용하던 휴대폰 번호를 다른 사용자가 그 번호를 이제 사용하게 되었다면 같은 서비스에 들어갈때 마찬가지로 오류가 나는 상황이 생길거에요.

 

왜냐면, 서버 유저 DB에 해당 휴대폰 번호와 카카오/네이버 로그인 시 이메일 등의 정보들을 가지고 판단하게된 환경이니까요!

 

그래서 이러한것을 해결하는 방법들이 몇가지 있겠지만 고민을 하다보니 CI & DI라는것에 대해 알게 되었고 한번 라이트하게 학습해보려고 오늘의 포스팅으로 CI & DI 알아보기로 주제를 가져와봤습니다!

 

자 그럼 스포하나 하자면, 앱에서 소셜 로그인이든 회원가입이든 거칠때 NICE를 통해 휴대폰 번호를 가지고 인증하거나 PASS 앱을 통해 본인 인증을 하는 경우 아주 많으셨죠?

 

이 경우가 바로 오늘 알아볼 CI & DI라는 개념입니다.

 

그럼 한번 CI & DI 본격적으로 알아볼까요?

---

CI (Connection Information)

우선 CI부터 알아볼께요!

CI는 Connection Information의 약자로 본인인증 기관에서 개인별로 고유하게 부여하는 개인 식별 정보입니다.

연계 정보라고도 부릅니다.

 

즉, 핵심은 개인 식별 정보로 온라인 주민등록번호라고 통칭합니다!

 

NICE 평가정보 요런곳이 본인인증 기관이라고 보시면 됩니다.

총 88 Byte로 구성된 개인간 절대 겹칠일이 없고 한명당 무조건 하나만 발급받게 되어 고유한 정보입니다.

 

원래 예전에는 본인인증을 확인할때 휴대폰 인증이 아닌 주민등록번호로 인증을 받는 시대가 있었습니다.

불과 그렇게 오래되진 않았어요! (제가 기억하는거 보니까..?)

 

그런데 이 주민등록번호로 수집을 하게 되니 많은 악용과 문제가 발생하였고 주민등록번호 수집 제한 정책이 시행되게 됩니다.

그러면서 대체제로 나온것이 주민등록번호를 사용하지 않고 온라인에서 고유한 본인을 식별할 수 있는 방법으로 CI가 나왔습니다.

 

CI 자체는 주민등록번호를 내부적으로 일방향 암호화하여 생성해줍니다.

개개인은 모두 주민등록번호가 다르잖아요?

이것을 암호화하여 88 Byte로 처리한 값을 만듭니다.

 

 

위와 같은 방식으로 생성이 됩니다.

 

CI의 특징으로는 본인 인증 기관이 달라도 이 CI 값은 고유하기에 공유하고 있다는것입니다.

즉, 이 키 자체가 개인별로 고유하기에 한번 생성된 값을 서로 공유해서 사용할 수 있는것이죠.

당연하게도 본인의 CI 값은 수정을 할 수 없기에 만약 유출된다면 아주 큰 문제가 될 수 있습니다.

 

 

결국 정리하여 요약해보면 CI 값은 온라인 주민등록번호와 같은 개념으로 본인확인기관에서 발급을 하며 각 기관이 달라도 이 CI 값은 고유하게 공유하여 사용할 수 있기에 카카오나 네이버 등 다른 사이트에서도 연계가 가능합니다.

 

CI에 대해 왜 생겨났고 어떻게 사용되는지 알 수 있겠죠?

 

그럼 이제 DI에 대해 한번 알아볼께요!

---

DI (Duplication Information)

DI는 Duplication Information의 약자로 중복 확인 정보라는 의미로 사용됩니다.

즉, 본인인증을 하는 인증 업체별로 같은 사람이라도 요청한 서비스에 따라 다르게 DI를 발급합니다.

DI도 마찬가지로 개개인을 식별하는 키입니다.

 

CI와 다른점은 같은 사람이라도 DI는 공유되지 않고 따로 발급되기에 다른 서비스끼리 이 값을 공유할 수가 없습니다.

 

 

즉, 위 그림처럼 DI는 서로 다른 사이트끼리 연계를 할 수 없죠.

그렇기에 CI처럼 해당 키 값으로 같은 사용자인지 판단할 수 없습니다.

 

DI는 66 Byte의 키 값으로 이뤄져있으며 용도는 고유한 개인 식별 정보보다는 중복을 확인하는 키 값으로 해당 사용자가 이 서비스에서 가입한적이 있는지를 중복 체크해주는 키 값입니다.

 

즉, 네이버에서 로그인을 첫 시도하여 DI를 부여 받았을때 다시 이 네이버에서 다른 DI를 같은 사람이 부여받을 수 없도록 하기 위함입니다.

여러 계정 생성을 방지한다고 볼 수 있습니다.

 

CI 값과 마찬가지로 DI 또한 개인이 수정할 수 없죠!

 

이렇게 DI도 알아봤는데 어떠셨나요?

CI와 DI에 대해 어떤 용도로 만들어졌고 사용되는 키 값들인지 알 수 있을거에요!

---

그럼 앱에서 어떻게 사용해?

결국 앱에서는 소셜 로그인 후 휴대폰번호 인증이나 PASS 인증 등을 붙여 이 CI와 DI를 가지고 고유한 개인 식별 정보를 가질 수 있습니다.

그렇기에 각 다른 소셜 로그인으로 로그인을 해도 CI 값은 공유가 되니 같은 사용자라는것을 확인하고 동일 유저로 처리할 수 있을거에요!

 

---

마무리

자 이렇게 CI & DI에 대해서 한번 알아봤습니다.

뭔가 개발적으로 생각해보다가 왜 나왔는지 알아보게 되었어요!

물론 CI & DI에 대해서도 제기되고 있는 문제가 많지만 정책상 사용하고 있기에 알아두면 좋을것 같습니다.

빠삭하게 딥하게는 저도 아직 이해가 안가지면 전체적인 맥락은 파악되었어요ㅎㅎ

 

---

레퍼런스

‘CI’(Connecting Information) 알아보기 | 캐치시큐

 

CI(Connection Information), DI(Duplication Information) 란?