최근 UK Biobank (UKB) 관련 보도를 보신 분이 계실까요? 영국의 대표적 바이오뱅크인 UKB는 50만 명 규모의 건강정보와 유전체, 영상, 검체를 보유한 대형 연구 인프라입니다. 그런데 최근 보도에 따르면, 승인된 연구자들이 분석 코드를 공유하는 과정에서 비식별 참가자 데이터 일부를 공개 저장소에 올렸고, 이런 일이 한두 번이 아니라 반복적으로 발생했습니다 (1). Guardian은 데이터가 수십 차례 온라인에 노출되었다고 보도했고, UKB는 이에 대해 해킹은 아니며 이름이나 주소 등 직접 식별정보는 포함되지 않았고, 참가자가 실제로 재식별된 증거는 없다고 설명했습니다 (1,2). 동시에 UKB는 2022년부터 이런 문제를 인지했고, 이후 데이터 보안 교육 의무화, 코드 점검 도구, 코드 저장소 자동 탐지 도구, 미준수 연구자 접근 중단 방침까지 도입했다고 밝혔습니다 (2,3).
이 사건이 중요한 이유는 단순히 “유명한 기관에서도 사고가 났다”는 데 있지 않습니다. 오히려 더 불편한 질문은 이것입니다. 우리는 아직도 데이터 유출을 해킹, 랜섬웨어, 외부 공격 같은 극적인 사건으로만 떠올리고 있지 않은가?
실제 연구 현장에서 더 흔한 위험은 훨씬 사소한 습관에서 시작됩니다. 코드와 데이터를 같은 폴더에 두고 작업하다가 실수로 함께 업로드하는 경우, 노트북 출력 셀에 샘플 데이터가 남아 있는 경우, 공동연구 편의를 위해 결과 파일을 메일이나 메신저로 주고받는 경우, 발표 준비를 위해 임시 추출한 파일이 개인 PC에 남아 있는 경우가 그렇습니다. 생성형 AI를 많이 쓰는 요즘에는 프롬프트 창에 일부 데이터를 그대로 붙여 넣는 일도 새로운 위험이 됩니다 (4,5). 이런 일들은 의도 없이도 충분히 일어날 수 있습니다. UKB 사건은 바로 이 지점을 드러냈습니다. 데이터 관리는 특별한 상황에서만 필요한 보안 업무가 아니라, 연구의 일상 그 자체라는 점입니다.
여기서 누군가는 “그래도 비식별 처리된 데이터 아닌가?”라고 물을 수 있습니다. 그러나 비식별 또는 가명처리는 위험을 줄여주는 조치이지, 데이터를 완전히 무해하게 만드는 마법은 아닙니다. 영국 ICO도 가명처리는 보안을 강화하는 방법일 뿐이며, 가명처리된 데이터는 여전히 개인정보로 간주된다고 설명합니다 (6). 실제로 Guardian 보도에서는 생년월, 성별, 특정 시기의 수술 이력 같은 제한된 정보만으로도 한 참가자의 기록을 높은 확률로 특정할 수 있음을 보여주었습니다 (1). 즉, 이름이 없어도 안전하다고 단정할 수는 없습니다. 데이터가 풍부해질수록, 그리고 온라인에 공개된 개인 정보와 교차 가능한 단서가 많아질수록 재식별 위험은 커집니다. AI가 발달할수록 이 위험은 더 작아지기보다 커질 가능성이 있습니다.
이 문제는 한국의 연구자들에게도 결코 남의 일이 아닙니다. 이미 많은 연구자들이 KoGES, 국민건강영양조사, HIRA, NHIS, 병원 EHR, 각종 바이오뱅크 자료를 활용해 연구하고 있습니다. 그리고 데이터 제공기관들은 생각보다 엄격한 통제 장치를 갖추고 있습니다. 예를 들어 KoGES는 원격분석시스템을 통해 가상 PC 환경에서 분석하도록 하고, 분석 데이터셋 자체는 반출 대상에서 제외하며 분석 결과표만 반출 신청이 가능하다고 안내합니다 (7). 보건의료 빅데이터 통합 플랫폼 역시 제3의 신뢰기관이 발급한 랜덤키를 활용해 자료를 연계하고, 분산연구네트워크에서는 원천 데이터 제공 없이 분석 결과 값만 연구자에게 제공합니다 (8). 최근 개정된 보건의료데이터 활용 가이드라인도 표준 심의 절차, 공용 DRB, 사망자 데이터 활용기준 명확화 등을 통해 연구 활용과 안전성 사이의 균형을 제도화하려 하고 있습니다 (9). 즉, 한국의 방향도 “마음껏 가져다 쓰라”가 아니라 “통제된 환경에서 안전하게 활용하라”에 가깝습니다.
그런데 제도와 별개로, 연구실의 실제 관행은 늘 그만큼 안전하지는 않습니다. 공용 서버에서 내려받은 파일을 개인 노트북으로 옮기고, 분석 편의를 위해 부분 데이터셋을 따로 저장하고, 공동연구자와 빠르게 소통하기 위해 메일에 파일을 첨부하는 일은 너무 쉽게 일어납니다. 한국에서도 병원 직원과 제약사 직원이 환자 정보를 촬영하거나 다운로드하고 불법적으로 시스템에 접근해 총 18만 5271명의 환자정보가 외부로 유출된 사례가 있었습니다 (10). 이 사건은 연구데이터 이용과 정확히 같은 맥락은 아니지만, 민감한 보건의료정보가 어떻게 일상적인 업무 흐름 속에서 빠져나갈 수 있는지를 잘 보여줍니다. 결국 위험은 규정이 없어서만이 아니라, 규정을 일상적 습관으로 만들지 못할 때 커집니다.
그렇다면 연구자는 무엇을 해야 할까요? 우선 raw data와 분석 코드는 처음부터 분리해 저장해야 합니다. 공개 저장소에 올릴 가능성이 있는 폴더에는 데이터 파일이 들어가지 않도록 구조를 설계해야 하고, 출력 셀과 캐시 파일도 점검해야 합니다. 둘째, 데이터 반출과 공유는 기관이 허용한 경로 안에서만 이뤄져야 합니다. 셋째, AI 도구를 쓸 때는 “이 문장을 붙여 넣는 순간 외부 처리 환경으로 전송될 수 있다”는 감각을 가져야 합니다. 개인정보보호위원회가 공개한 AI 프라이버시 리스크 관리 모델과 생성형 AI 개인정보 처리 안내서는 AI 생애주기 전반에서 프라이버시 리스크 식별, 학습데이터 출처·이력 관리, 가명·익명화, 입력·출력 필터링, 개인정보 영향평가, 거버넌스 구축 등을 강조하고 있습니다 (4,5). 기술을 쓰지 말자는 것이 아니라, 기술을 쓰는 방식에 규율이 필요하다는 뜻입니다.
기관의 역할도 중요합니다. UKB가 사후적으로 내놓은 대응은 오히려 많은 시사점을 줍니다. 의무 교육, 사전 점검 도구, 자동 탐지, 위반 시 접근 중단은 모두 “실수할 수 있는 인간”을 전제로 한 시스템 설계입니다. 데이터 보안을 연구자 개인의 윤리 의식에만 기대서는 안 됩니다. 안전한 저장소를 기본값으로 제공하고, 반출 전 점검 절차를 만들고, 로그를 감시하고, 사고가 나면 숨기지 않고 학습하는 구조가 있어야 합니다. 한국도 이미 원격분석, 결괏값 반출, 가명정보 활용 가이드라인 등 많은 제도를 갖추고 있습니다 (7-9). 이제 필요한 것은 이를 연구현장의 기본 문화로 만드는 일일 것입니다.
결국 이번 기사가 남긴 질문은 하나입니다. 우리는 데이터를 얼마나 많이 모으고 있는가가 아니라, 그 데이터를 끝까지 얼마나 신뢰 가능하게 관리하고 있는가를 묻고 있는가? 데이터 기반 연구는 더 커질 것이고, AI는 더 깊이 들어올 것입니다. 그렇다면 이제 연구자 혹은 데이터를 가진 국가의 경쟁력은 분석 기술만으로 결정되지 않을 것입니다. 데이터를 다루는 태도, 기록하는 습관, 공유를 설계하는 방식이 연구의 신뢰를 좌우하게 될 것입니다. 데이터 관리는 연구의 바깥에 있는 행정이 아니라, 연구의 안쪽에 있는 책임입니다.
레퍼런스
- Devlin H, Burgis T. Confidential health records from UK Biobank project exposed online. The Guardian. 2026 Mar 14.
- UK Biobank. A message to our participants: protecting your personal information. 2026 Mar 14.
- UK Biobank Community. Repository Management Best Practices for Sensitive Data. 2026 Feb 9.
- 개인정보보호위원회. 국민이 신뢰할 수 있는 인공지능 시대를 위한 AI 프라이버시 리스크 관리 모델 제시. 2024 Dec 19.
- 개인정보보호위원회. 생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서. 2025.
- Information Commissioner’s Office (ICO). Pseudonymisation.
- 국립보건연구원. KoGES 원격분석시스템 이용안내.
- 보건의료 빅데이터 통합 플랫폼. 플랫폼 소개 / 자료 연계방식.
- 보건복지부·개인정보보호위원회. 보건의료데이터 활용 연구 문턱 낮춘다. 2025 Dec 31.
- 개인정보보호위원회. 환자정보 유출 17개 종합병원 제재. 2023 Jul 27.
- 본문은 생성형 AI를 구성 아이디어 정리와 문장 표현 개선 등 작성 과정 전반에서 참고 자료로 활용했습니다. 그러나 최종 원고의 표현은 직접 검토 및 수정 후 완성했습니다.