개인정보위, 우리은행 고객 1만7천명 개인정보 유출 사고 현장조사 착수…CI값 9개월 공개 방치

핵심 요약

개인정보보호위원회(개보위)가 우리은행의 고객 개인정보 유출 사고와 관련해 현장조사에 착수했다. 이번 사고는 우리은행이 NFT 플랫폼 구축을 위해 외부 업체에 업무를 위탁하는 과정에서 고객 1만7,551명의 개인정보가 외부에 공개된 사건으로, 유출된 정보에는 온라인상 주민등록번호로 불리는 CI(연계정보)값이 포함돼 있어 파장이 커지고 있다.

사고 경위

우리은행은 NFT 플랫폼 구축을 목적으로 외부 개발업체에 업무를 위탁했으나, 해당 사업은 2025년 2월 이미 종료됐다. 문제는 사업 종료 이후 수탁업체 직원이 업무용 메신저인 슬랙(Slack)에 남아 있던 고객 정보를 코드 저장소 깃허브(GitHub)에 백업하면서 외부에 공개됐다는 점이다.

특히 이 사실을 우리은행 스스로 발견하지 못했다는 점에서 내부 통제 부실 논란이 불거지고 있다. 한국인터넷진흥원(KISA)이 먼저 이를 발견해 금융보안원에 제보했고, 그제야 우리은행이 인지한 것으로 확인됐다. 깃허브에 파일이 업로드된 시점은 2025년 9월 5일이었으나, 발견된 것은 2026년 6월 30일로, 약 9개월간 공개 상태로 방치된 셈이다.

쟁점 ① 위탁 종료 후 파기 확인 절차의 실효성

우리은행 측은 사업 종료 후 상암 전산센터 현장에 나가 데이터 파기를 확인했다고 밝혔다. 그러나 수탁업체가 업무 과정에서 사용하던 슬랙 내 데이터는 파기 확인 범위에 포함되지 않았던 것으로 드러났다. 개인정보 보호법은 위탁자가 수탁자를 교육하고 개인정보 처리 현황을 주기적으로 점검·감독할 의무를 명시하고 있다. 파기 확인서에 서명을 받는 형식적 절차만으로 해당 법적 의무를 다했다고 볼 수 있는지가 이번 조사의 핵심 쟁점 중 하나다.

쟁점 ② 실제 CI값 사용의 필요성

수탁업체 측은 "마이그레이션 최종 단계에서 실제 CI값이 필요했다"고 설명했다. 그러나 개인정보보호법은 익명 또는 가명 처리만으로 목적을 달성할 수 있다면 그렇게 처리해야 한다고 규정하고 있다. 더미 데이터나 대체키 활용 가능성에 대한 내부 검토 및 승인 절차가 이루어졌는지, 실제 CI값 사용 시 접근자 최소화 조치와 저장 환경 통제가 적절히 이루어졌는지도 조사 대상이다.

쟁점 ③ 슬랙 데이터의 추가 유출 여부

현재까지 해당 깃허브 URL에 접속한 것으로 확인된 인원은 최초 제보자, KISA, 금융보안원, 정보보호 부서 관계자에 한정된 것으로 알려졌다. 그러나 슬랙에 남아 있던 데이터가 깃허브 이외의 경로로 유출되거나 복제되었을 가능성에 대한 철저한 검증이 필요하다는 지적이 나온다.

---

전문가 분석

이번 사고는 개인정보 위탁 관리의 사각지대를 다시 한번 드러냈다는 평가다. 개보위에 따르면 현재 위탁자가 수탁자의 파기 확인 시 준수해야 할 구체적인 가이드라인이나 표준 체크리스트가 마련되어 있지 않다. "슬랙까지 확인해야 한다는 걸 몰랐다"는 해명이 단순한 관리 안일함의 문제가 아니라, 제도적 공백에서 비롯된 구조적 문제일 수 있다는 것이다.

개인정보 보호 전문가들은 ▲파기 확인 절차의 구체적 기준 마련 ▲개발·테스트 환경에서의 실제 개인정보 사용 제한 ▲외부 코드 저장소(GitHub 등)에 대한 개인정보 업로드 금지 조치 등이 ISMS, ISMS-P 등 정부 인증 체계에 명시적으로 반영되어야 예방이 가능하다고 강조한다. 매 사고에서 반복적으로 드러나는 허점들이 인증 기준에 적시에 반영되지 않는 한, 유사 사고는 계속될 수밖에 없다는 지적이다.

아울러 금융권의 개인정보 유출 사고가 AXA손해보험, SGI서울보증, KB라이프생명, 하나카드 등에 이어 잇따르고 있다는 점에서, 금융감독원과 금융보안원 등 관계 기관의 예방 점검 체계 전반에 대한 재검토 필요성도 제기되고 있다. 국민은 서비스 이용 과정에서 사실상 개인정보 제공 동의를 강요받는 구조 속에 있는 만큼, 정보주체의 권리보호 관점에서 기업과 기관 모두의 책임 강화가 시급하다는 목소리가 높다.

---

실무 연계 포인트

• 수탁자 감독 의무(개인정보보호법 제26조): 위탁자는 수탁자의 개인정보 처리 현황을 주기적으로 점검해야 하며, 파기 확인은 서면 수령에 그치지 않고 실질적 이행 여부까지 포함해야 한다.
• 최소 수집 원칙: 개발·테스트 단계에서 실제 개인정보 대신 가명처리 또는 더미 데이터 활용 여부를 사전에 검토하고 내부 승인 절차를 갖춰야 한다.
• 외부 저장소 통제: 슬랙, 깃허브 등 외부 협업 도구 및 코드 저장소에 개인정보가 포함된 파일이 업로드되지 않도록 기술적·관리적 통제 수단을 마련해야 한다.
• 위탁 종료 시 데이터 흐름 전체 파악: 위탁 업무 종료 시 수탁자가 사용한 모든 업무 환경(메신저, 클라우드, 개발도구 등)에 대한 개인정보 잔존 여부를 포함해 파기를 확인해야 한다.