우리은행 고객 개인정보 1만7551건이 외부 개발업체 직원의 과실로 유출됐습니다. 수치만 보면 "이 정도야 괜찮겠지" 싶을 수 있는데, 저는 그 판단이 틀렸다고 봅니다. 어떤 정보가 빠져나갔는지, 그리고 어떻게 관리됐는지를 따져보면 이야기가 달라집니다.
유출된 CI, 왜 단순하게 볼 수 없는가
이번에 유출된 정보는 고객의 닉네임과 CI입니다. 여기서 CI(연계정보, Connecting Information)란 주민등록번호를 암호화해 만든 고유 식별값으로, 온라인 서비스 간에 동일 인물임을 확인하는 용도로 쓰입니다. 주민등록번호를 직접 수집하지 못하도록 하면서 그 대체재로 도입된 전자 식별체계라고 보면 됩니다.
CI 자체만으로는 계좌에 로그인하거나 금융 자산을 빼낼 수 없습니다. 우리은행도 이 점을 사과문에서 명시했습니다. 그런데 제가 직접 이 사안을 들여다보면서 걸린 부분은 바로 이 지점입니다. CI는 평생 바뀌지 않습니다. 주민등록번호를 기반으로 생성되기 때문에 주민번호를 바꾸지 않는 한 동일한 값이 유지됩니다. 다른 경로로 유출된 개인정보와 결합되면 타깃형 보이스피싱이나 명의도용에 쓰일 수 있다는 뜻입니다.
개인정보보호위원회 역시 CI를 "다른 정보와 쉽게 결합해 특정 개인을 식별할 수 있는 정보"로 보고 개인정보보호법상 개인정보에 해당한다는 입장을 유지하고 있습니다(출처: 개인정보보호위원회). 법적으로도 단순 데이터가 아니라는 겁니다. "CI라서 피해 가능성 낮다"는 말이 완전한 안심의 근거가 될 수 없는 이유입니다.
외주업체 관리, 어디서 무너졌나
사고 경위를 보면 문제가 더 선명해집니다. NFT 플랫폼 구축 프로젝트를 맡은 외부 개발업체가 고객 개인정보가 담긴 파일 링크를 외부에 유출했고, 우리은행이 이 사실을 인지한 건 수개월이 지난 후였습니다. 제 경험상 이런 구조는 금융권만의 문제가 아닙니다. 외주 개발 환경에서는 테스트 데이터로 실제 고객 정보를 쓰는 관행이 여전히 남아 있는 경우가 있습니다.
이번 사고가 특히 불편하게 느껴진 이유가 여기 있습니다. 유출된 정보의 위험도보다, 그 정보가 어떻게 외부에 그냥 나돌 수 있었는지가 더 큰 문제입니다.
금융권에서 외부로 고객정보가 대규모 유출된 사례를 돌아보면, 2013년 한국SC은행과 한국씨티은행 사건이 있습니다. 당시 외주업체 직원이 10만 건에 달하는 고객 정보를 대출모집인에게 넘겼고, 씨티은행에서는 내부 직원이 수만 건을 출력해 외부로 전달했습니다. 성명, 주민등록번호, 연체정보, 직장 및 소득 정보까지 포함돼 있어 금융자산 탈취로 직결될 수 있는 사고였습니다. 이번 우리은행 사고는 그보다 피해 범위가 좁지만, 외주업체 관리 허점이라는 구조적 원인은 13년 전과 놀랍도록 닮아 있습니다.
이런 사고가 반복되는 배경을 짚어보면 다음과 같습니다.
- 외주 개발업체가 프로젝트 종료 후에도 개인정보를 임의로 보관하는 관행
- 테스트 환경과 실제 운영 환경의 데이터 분리가 미흡한 개발 프로세스
- 외주 직원의 접근 권한 및 파일 반출에 대한 사후 모니터링 부재
- 계약 종료 후 보유 데이터 파기 여부를 확인하는 절차 미비
우리은행은 이번 사태 이후 개발업체의 개인정보 관리 현황을 전수 조사하겠다고 밝혔습니다. 그런데 솔직히 이건 예상 밖이었습니다. 전수 조사가 사고 이전이 아닌 이후에 이뤄진다는 사실 자체가, 그동안 외주 관리 체계가 얼마나 허술했는지를 역설적으로 보여주기 때문입니다.
개인정보 생애주기 관리, 금융사가 놓치고 있는 것
제가 이번 사고에서 가장 주목한 개념은 개인정보 생애주기 관리(Personal Data Lifecycle Management)입니다. 여기서 개인정보 생애주기란 개인정보가 수집되는 순간부터 이용, 보관, 파기에 이르기까지 전 과정을 체계적으로 통제하는 것을 의미합니다. 단순히 "해킹당하지 않는 것"을 목표로 하는 보안과는 결이 다릅니다.
이번 사고는 해킹이 아니었습니다. 외주업체 직원의 과실로 파일 링크가 외부에 노출됐습니다. 시스템을 뚫은 게 아니라 데이터가 있어선 안 될 곳에 있었고, 그게 새어 나간 겁니다. 개인정보보호법은 수집 목적 달성 후 즉시 파기를 원칙으로 규정하고 있는데, 이번 사고는 그 원칙이 외주 개발 환경에서 제대로 작동하지 않았음을 보여줍니다(출처: 개인정보보호위원회).
제 경험상 이건 좀 다릅니다. 금융사가 직접 운영하는 시스템의 보안은 상당히 강화돼 있지만, 외주 프로젝트 단위에서 생성되고 이동하는 데이터까지 통제하는 체계는 아직 많은 곳에서 허점이 있습니다. 프로젝트 기간 동안 테스트용으로 쓰인 실제 고객 데이터가 프로젝트 종료 후에도 어딘가에 남아 있는 상황은 생각보다 흔합니다.
고객 입장에서는 당장 계좌가 위험하다기보다 앞으로 본인 이름과 CI가 다른 유출 데이터와 결합돼 타깃형 피싱 연락이 들어올 가능성을 경계해야 합니다. 평소보다 더 정교하게 개인 정보를 언급하는 문자나 전화가 온다면, 이번 사고와 무관하지 않을 수 있습니다.
결국 이번 우리은행 사고는 규모보다 구조를 봐야 합니다. 1만7551건이라는 숫자가 작아 보일 수 있지만, 외주 관리 허점이 방치되는 한 다음 사고는 더 많은 정보를 포함할 수 있습니다. 금융사가 직접 운영하는 시스템뿐 아니라 외주 개발업체, 프로젝트 산출물, 테스트 데이터 전반을 개인정보 생애주기 관점에서 통제하는 체계를 만드는 것이 이번 사고가 남긴 숙제라고 봅니다. 소비자로서는 금융 앱에서 이상 로그인 알림을 설정해두고, 출처 불명의 연락에 평소보다 더 민감하게 반응하는 것이 현실적인 대응입니다.
이 글은 개인적인 경험과 의견을 공유한 것이며, 전문적인 법률 또는 금융 조언이 아닙니다.