세상에는 수많은 동명이인이 존재합니다. 대한민국에 김태완이라는 사람이 약 500명 정도는 있을 것 같습니다. 상단 이미지는 구글링으로 확인한 대한민국의 김태완입니다. 지난 몇 년간 고객사에서 제 이름 때문에 생겼던 웃지 못할 경험을 했고, 이 에피소드는 현재도 진행 중입니다. 이 에피소드는 2018년 1월 24일 페이스북에 올려 100명의 페친으로 부터 공감을 얻은 사건이 있었습니다.

이유를 알 수 없는 고객사로부터 퇴출

2013년 3월 고객사에서 빅데이터 PoC를 준비할 때였습니다. 고객사로 부터 사업장에서 떠날 것을 통보받았습니다. 내가 고객사의 보안 정책을 위반했기 때문에 고객사 사업장에 출입할 수 있다는 통보였습니다. 내가 고객사의 어떤 보안 정책을 위반했는지 알아보았으나 누구도 그 이유를 말해 주지 않았습니다.

저는 소프트웨어 기술 지원하는 역할을 하고 있기 때문에, 고객사 출입이 많은 편입니다. 특히 저에게 퇴출 명령을 내린 그 고객사는 우리 회사의 가장 큰 고객사이기 때문에, 회사 업무에 상당한 영향을 미쳤습니다. 회사에서도 당황스럽기는 마찬가지였습니다. 고객사 출입이 제한되기 때문에 난처한 일이 많았습니다.

보안 위반 통보를 받은 후, 아래 그림과 같이 보안 위반자로서의 주홍 글씨가 찐하게 써졌습니다. 이 당시 고객사 문의 결과 이유를 파악할 수 없지만, 고객사 사업장에 영구 출입 정지 대상자라는 통보를 받았습니다. 회사에서 무슨 일을 저지른 거냐는 비난을 받아야 했습니다.

그리고 5년 후 밝혀진 허무한 진실: 생년월일이 같은 동명이인

그리고 5년이 흘렀습니다. 5년간 해당 고객사에 들어가야 할 경우, VIP로 출입하거나 여러 가지 편법을 써가며 생 난리를 치며 출입을 했습니다. 그러다가 고객사의 내부 시스템이 통합된 어느 날 보안 담당자에게서 이런 말을 들었습니다.

2011년 8월에 XX 사업장에서 하드디스크를 불법 반출하다 걸리셨네요. 이 정도 보안 위반이면 영구 출입 정지입니다. 출입 불가합니다.

저는 그런 사실이 없기에 다시 확인했습니다.

197X년 XX월 XX일 생 김태완: 보안 위반 대상자로 등록되어 있습니다. XX 컴퓨터 소속으로 되어 있는데요?

저는 2011년에 소속이 현재 회사였고, XX 컴퓨터에는 근무한 적이 없습니다. 동명이인의 덫에 걸린 겁니다.

2013년에 개인 정보 보호법이 강화되면서 데이터베이스에 주민등록번호를 사용할 수 없게 되었습니다. 이 법규 때문에 주민등록번호로 PK(Primary Key)로 사용하는 많은 테이블이 수정되었습니다. 절 출입 금지한 고객사는 BlackList 테이블을 기존에 주민등록번호로 관리해 왔던 것 같습니다. 2013년 개인 정보 보호법이 강화되면서 BlackList의 PK를 이름+생년월일로 변경한 것 같습니다.

이렇게 BlackList 테이블이 수정되면서, 저와 이름+생년월일이 같은 다른 사람의 보안 위반 기록이 어느 순간 저를 지목하는 문제가 발생한 것입니다.

생년 월일이 같은 사람이 동명이인일 확률: 11.7%

신용평가사 NICE신용평가정보는 2012년 9월 17일 성명·주민등록번호 정보 4천266만 2천467개를 분석한 결과 주민등록상 생년월일이 동일한 사람 중 동명이인이 있을 확률은 11.7%라고 밝혔습니다. 그리고 가장 흔한 성씨는 김-이-박-정-최이라고 합니다. 막연하게 굉장히 확률이 작을 것만 같은 생년월일+이름 조합은 결코 키가 될 수 없는 조합입니다. 데이터 충돌이 너무 많이 발생하는 조합입니다.

풀린 족쇄, 그리고 테이블 디자인에 대한 고민

2017년 8월에 경력증명서를 고객사에 제출한 후 고객사 출입이 약간 자유로워졌습니다. 출입은 가능해졌지만, 약간의 부가적인 절차는 필요했습니다. 보안위반자 관리 시스템을 새로 개발해야 했기에 완전 해결은 어려웠습니다. 저 하나 때문에 고객님께서 새로 예산을 확보해서 시스템을 개발해 주실 일은 없겠죠. ^^

제 에피소드의 고객사는 다음과 같은 원칙으로 보안 위반자 관리를 관리해 왔습니다.

• 보안 위반자는 지정된 기간 고객사 출입 불가함
• 보안 위반자가 소속 회사를 변경하더라도 당사자의 출입 제한 기간은 유지되어야 함

이러한 요건으로 데이터베이스 테이블을 설계할 경우 PK를 어떻게 잡아야 할까요? 주민등록번호 사용이 제한됨에 따라서 이런 로직을 데이터베이스에 디자인하는 것이 정말 어려운 문제입니다. 개인적으로 지난 5년 동안의 에피소드가 짜증 나기는 하지만, 이런 요구사항을 테이블 디자인에 반영할 적당한 key가 없다는 사실도 공감이 갑니다.

기존에 주민등록번호는 정말 대단한 Feature였습니다. 대한민국 국민에게 부여되는 유일한 값이고, 번호 안에 생년월일, 성별, 출생지역, 출생신고 접수순서 및 검증 필드를 포함하는 정말 잘 디자인된 Feature였습니다. 개인 정보 보호법이 강화되면서 이런 값을 사용하지 못하면서 많은 부수적인 문제가 발생하고 있습니다.

이런 문제를 해결하기 위해서 Key를 어떻게 정의해야 할까요? 부가적으로 추가해야 할 정보는 무엇일까요? LinkedIn 계정과 같은 부가적인 정보가 필요한 상황인 것 같습니다. 지속해서 자신의 경력을 관리하는 SNS 계정과 출입 계정 생성 시 사진을 추가하여 보안 문제 발생 시 검증 필드로 활용하는 방안을 고려해야 할 것 같습니다.

최근에 다시 시작된 에피소드와 고객사 관계자의 당당함

얼마 전에 다른 고객사로부터 또다시 출입 제지를 받았습니다. 제가 보안 위반자라 출입 등록할 수 없다는 연락을 받았습니다. 저와 생일과 이름이 다른 그분께서 또 다른 고객사에서도 하드디스크를 반출하다가 적발되어 영구 출입 정지를 당하셨다고 합니다. 저로서는 정말 악연입니다.

정말 악연인 그분에게 화가 나는 상황에서 황당한 요구를 받았습니다. 저를 보안관리 대상자로 지목한 고객사로 부터 제가 그 사람이 아니라는 것을 증빙을 위해서 건강보험 납부 증명서 원본을 제출하라는 요구를 당당히 받았습니다. 재직 증명서는 위조 가능성이 있으니 건강보험 납부 증명서 원본을 제출하라는 당당한 요구였습니다.

피해자는 난데 갑님이라고 너무 당당한 것 아닙니까? 내? 그리고 우리 회사에서 발행한 재직 증명서를 위조 가능한 문서라고 말하는것은 너무 무례한 것 아닙니까?

꼭 전달하고 싶은 말

• 고객사 보안 시스템 개발 담당자
  • PK 좀 잘 디자인해 주세요
  • 생년월일과 이름은 PK 될 수 없습니다.
  • 어려운 일이란 것 알지만 그래도, 당신이 선택한 생년월일과 이름 조합은 충돌이 발생할 확률이 매우 높은 조합입니다.
• 고객사 보안 담당자
  • 고객사 보안이 중요한 만큼, 내 개인 정보도 중요합니다.
  • 개인 소득 및 가족 사항 등 많은 정보가 공유되는 개인 정보 함부로 요구하지 맙시다.
  • 그리고 파트너사의 도덕성을 무시하지 맙시다. 위조 가능한 문서라뇨…
• 생년월일이 같은 또 다른 김태완님
  • 누군지 모르지만 제발 적법하게 일합시다. 쫌..

그나저나 데이터베이스 PK 디자인은 정말 어려운 분야인 것 같습니다. 이번에 정말 정말 정말……. 현실을 세계를 반영한 데이터베이스 디자인은 정말 어려운 것임을알게 되었습니다.