병원 AI, 왜 '데이터를 줄이는 것'부터 시작해야 할까

"전자의무기록, 영상 판독 보고서, 최신 논문을 모조리 대형 언어모델에 집어넣으면 당장 'AI 진료'가 가능해질 것"이라고 믿는 병원이 적지 않다. 임원 회의에서도 심심찮게 들리는 말이다. 인프라만 붙이면 우리 병원도 곧 스마트 병원이라고.

그런데 막상 문서를 한꺼번에 들이부으면 정반대 현상이 일어난다. 넣는 문서가 많을수록 모델의 답은 엉뚱한 곳으로 새어나간다. 정리가 안 된 방대한 문서는 검색을 느리게 하고, 정답을 틀리게 하며, 심지어 환자 프라이버시를 모델 바깥으로 흘려보내는 통로가 되기도 한다. 의료 현장에서 AI를 쓰는 첫걸음은 데이터를 '더 넣는 것'이 아니라, 앞서 '빼는 법'을 아는 것이다. 문서를 작게 압축하고, 민감 정보를 가리고, 병원 내부망에 private RAG 토대를 세우는 것. 순서가 틀리면 아무리 큰 모델을 올려도 헛수고다.

UglyPear Data가 만드는 것은 바로 이 흐름이다. 고성능 문서 압축에 RAG 데이터 엔지니어링 기반을 결합해, 전체를 private로 배포한다. 데이터는 내부망을 한 발자국도 벗어나지 않는다. 병원, 제약사, 연구 기관처럼 "데이터는 한 걸음도 벽 밖으로 나가선 안 되는" 고객에게 이 조합은 자료를 퍼블릭 클라우드로 옮기는 것보다 훨씬 현실적인 선택지다. 여기서 말하는 '빼기'는 정보를 버리는 게 아니다. 모델이 읽어야 할 핵심만 남기고, 읽을 필요 없는 무게와 노출될 위험을 덜어내는 작업이다.

병원이 특히 이 고민에 부딪히는 까닭은, 다른 업종보다 문서의 무게와 민감도가 한층 무겁기 때문이다. 한 번 쌓인 진료 기록은 평생 보관해야 하는 경우가 많고, 그 안에는 언제 터질지 모르는 민감 필드가 촘촘하다. 규모가 클수록 문제는 덩치를 부풀린다. 그래서 의료 쪽일수록 '더 넣기'보다 '잘 다스리기'가 앞선다.

엉뚱한 통념 하나부터 깨보자

Komprise가 기업 NAS 저장소를 조사한 적이 있다. 그 결과 60%에서 70%에 이르는 데이터가 90일 넘게 아무도 건드리지 않으면서도, 비용이 큰 주저장소를 점유하고 있었다. 관리자가 외면한 채 값비싼 공간을 차지하고 있는 셈이다. 이걸 병원에 대입하면 PACS 영상 아카이빙이다. 필름을 디지털화한 뒤 수많은 DICOM 영상이 잠들어 있고, 평소엔 거의 들여다보지 않지만 저장 예산은 해가 거듭돼도 줄지 않는다.

이런 '콜드 데이터'를 그대로 대형 언어모델 파이프라인에 던져넣으면, 검색만 느려질 뿐 아니라 연산 자원을 헛되이 태운다. 더 들여다보면, 많은 진료과가 부족한 건 저장 공간 그 자체가 아니라 "지워야 할 걸 지우지 않고,归档해야 할 걸归档하지 않은" 구조라는 점이다. 용량이 차면 장비를 더 사면 그만이라는 식의 대응은, 애초에 쌓일 필요도 없는 무게를 계속 짊어리는 꼴이다. 병원은 본업인 진료가 아닌, 자료 보관 비용을 계속 지불하는 셈이다.

찾는 데 드는 숨은 비용

자료를 정리하는 일의 대가를 수치로 본 적이 있다. 지식 관리 프로젝트가 없는 기업은 직원이 주당 평균 8.5시간을 자료 찾는 데 썼다. 시스템을 도입한 곳은 4.6시간으로 줄어, 매주 3.9시간을 아꼈다. 이를 환산하면 직원 1,000명당 약 98명 분의 정규 인력을 되찾는 셈이다. 눈에 보이지 않는 낭비가 생각보다 크다. 이 숫자는 단순한 편의 문제가 아니라, 조직 전체의 생산성과 직결된다.

병원에서는 진료 지침, 투약 기준, 진료 기록 양식, 협진 기록이 여러 시스템과 개인 폴더에 흩어져 있다. 의사가 "최신판" 진료 경로 하나를 찾는 일이 외래 진료보다 버거울 때가 많다. 문서를 못 찾으면 누군가 새로 하나 만드니 버전은 계속 늘고, 정작 써야 할 파일은 맨 밑바닥에 묻힌다. 모델에게 이 혼잡을 그대로 먹이면, 답이 어디 출처에서 왔는지조차 알 수 없게 된다. 사람이 못 찾는 자료를 기계가 잘 찾아주리란 기대는, 정돈되지 않은 바탕 위에서는 쉽게 깨진다.

더 널리 퍼진 혼돈

Kaspersky가 실시한 설문에서는 응답자의 57%가 중요한 파일을 찾기 어렵다고 답했고, 30%만이 정기적으로 정리한다고 했으며, 26%는 처리하지 못한 자료를 쌓아두는 '쓰레기 폴더'를 따로 운영한다고 밝혔다. 의료 진료과의 공유 드라이브는 이 상태가 증폭된 모습인 경우가 많다. 이름은 제멋대로, 버전은 하늘에 널렸고, 누가 뭘 고쳤는지 아는 사람은 없다.

"이게 대형 언어모델을 올리는 것과 무슨 상관이냐"고 묻는다면, 상관이 크다. 모델이 먹는 건 바로 이 어지러운 파일들이기 때문이다. 쓰레기를 넣으면 쓰레기가 나온다. 입력이 통제되지 않으면 출력도 통제할 수 없다. 아무리 정교한 모델이라도, 밑바탕이 엉망이면 엉망인 답을 낼 뿐이다.

그럼 왜 그냥 클라우드로 가지 않을까

데이터를 다스려야 한다면 클라우드로 넘기는 게 편할 텐데, 의료 데이터는 그럴 수 없다. 환자 프라이버시(PHI), 연구 데이터, 공개되지 않은 임상 시험은 보안 규제와 데이터 반출 관련 규정의 적용을 받아, 한 걸음도 내부망을 벗어나선 안 된다. 규정 위반은 단순한 기술 이슈를 넘어 기관의 존립과 직결된다.

더 까다로운 건 원본 문서에 이름, 신분증 번호, 진료 기록 번호, 가족력 같은 민감 필드가 섞여 있다는 점이다. 그걸 그대로 모델에 주는 건 프라이버시를 활짝 열어 보이는 것과 같다. UglyPear Data의 구성에는 13개 범주의 AI 민감 정보 탐지가 내장돼, 입고 전에 자동으로 식별하고 가릴 수 있다. 거칠게 말해, 의료 AI에서 컴플라이언스는 가산점이 아니라 입장권이다. 이 입장권이 없으면, 아무리 성능이 좋아도 도입 자체가 불가능해진다. 병원이 클라우드 업체와 상담할 때 흔히 빠뜨리는 질문이 있다. "우리 민감 필드는 누가, 어디서, 어떻게 가리는가." 이 질문에 명확한 답이 없다면, 그쪽 길은 신중히 다시 보는 게 좋다.

구체적으로 어떻게 할까

실제 배포는 세 갈래가 동시에 돌아간다. 한 갈래만으로 끝난다고 기대하면 중간에 멈추기 십상이다. 압축과 정리, 그리고 그 위에 올라가는 검색 토대가 따로 노는 순간, 병원은 다시 원점으로 돌아간다.

압축부터

SmartSlim은 자체 개발한 Rust 엔진으로 PDF, 이미지, 영상, 오디오, Office, OFD, 스캔 문서 등 8종류 형식을 압축한다. 부피 감소폭은 60%에서 80% 사이이며, 모든 과정이 본인 환경에서 끝나 파일은 밖으로 나가지 않는다. 실측 사례가 있다. 443쪽짜리 OFD 문서를 끝에서 끝까지 124초 만에 처리했고, 이미지는 GPT-4o 기준으로 환산했을 때 토큰 비용을 85.9% 아꼈다.

문서가 많고 민감한 병원이라면, 우선 부피부터 줄여야 검색과 추론 비용이 따라 내려간다. 겉보기엔 압축이 그저 "작아지는 것" 같지만, 곰곰이 생각해 보면 압축이 실제로 해결하는 건 "모델이 읽을 수 있고, 또 읽을 돈도 드는" 문제다. 이 과정에서 compress-mcp 같은 MCP 기반 인터페이스가 압축 단계를 다른 도구와 연결하는 다리가 된다. 압축은 단순히 용량을 줄이는 기술이 아니라, 모델이 다룰 수 있는 범위 안으로 문서를 끌어들이는 첫 관문이 된다.

RAG 데이터 엔지니어링 기반

UglyPear Data는 이를 여섯 가지 공정과 여덟 가지 능력으로 나누어, 문서 정제·슬라이싱·탈감·벡터화·검색에 이르는 연결 고리를 망라한다. 핵심은 흩어진 문서를 "모델이 읽을 수 있고, 또 믿을 수 있는" 지식으로 바꾸는 일이다. private 배포이므로 전체 흐름이 별도의 서버에서 돌고, 데이터는 내부망을 벗어나지 않는다. 의료에서는 특히 이 점이 중요하다. 지식은 병원 안에 남고, 감사 추적도 병원 안에 남는다.

여섯 공정의 거버넌스는 규정 준수를 위한 형식이 아니다. 의료에서 잘못된 버전의 진료 지침을 인용한 답은 실제 피해로 이어질 수 있으므로, 파이프라인은 벡터 저장소에 담기기 전에 중복 제거, 필드 단위 마스킹, 출처 추적에 힘을 쏟는다. 정제된 출처가 추적되는 인덱스에서 답하는 모델은, 날것 PDF 더미에서 건지는 모델과는 차원이 다르다.

파일 정리가 취약한 공유 드라이브에는 MagiFiler 같은 정리 도구를 곁들여, 쌓인 문서를 우선 정돈한 뒤 파이프라인에 넣는 흐름도 가능하다. 정리와 압축과 검색이 한 줄기로 이어지면, 병원은 "데이터가 너무 많아"라는 고민에서 "데이터를 어떻게 쓰느냐"라는 문제로 넘어갈 수 있다. 무엇을 남기고 무엇을 가릴지 결정하는 주권이 병원 안에 머문다는 점도 놓치기 어려운 이점이다.

배포 방식 그 자체

전체 private 배포 서비스는 시스템을 병원 내부망에 둔다. 국산화 환경 적응도 갖춰, Kirin이나 UOS 같은 국산 운영체제에서도 돌아간다. 이미 국산화 노선을 걷는 병원이라면 "시스템이 안 맞는" 걱정을 한층 덜 수 있다. 기존 인프라를 버리지 않고 그 위에 올릴 수 있다는 점이 의료 쪽에선 적지 않은 무게를 갖는다. 도입 비용과 거부감을 함께 낮추는 길이기도 하다.

의료 문서 AI화의 길, 사실 세 가지뿐

차이는 생각보다 크다. 아래는 세 가지 배포 경로를 데이터 반출·마스킹·비용·정확도·기간·규모로 나눈 비교다. 같은 '의료 AI 도입'이라 표현해도, 선택한 길에 따라 남는 risk와 비용은 판이하게 갈린다.

표에서는 "비교적 안정적", "비교적 통제됨"처럼 상대적인 표현을 썼다. 선택할 때 진짜로 던져야 할 질문은 하나다. "너의 데이터가 그 벽을 넘어가도 되는가." 이 질문에 답이 '아니오'라면, 나머지 항목은 자연스레 좁혀진다. 기술적인 우위보다는, 내 규정과 내 인프라에 얼마나 잘 맞는지를 보는 편이 병원에는 훨씬 안전하다.

많은 병원이 막히는 건 데이터가 없어서가 아니라, 데이터가 너무 많고 너무 엉망이며 너무 민감해서다. 문서를 우선 작게 만들고, 프라이버시를 떼어내고, 지식을 정리해야 대형 언어모델이 비로소 쓸모를 낸다. 이 순서를 지키지 않으면, 아무리 거대한 모델을 올려도 결국 벽에 부딪힌다. 기술보다 앞서 필요한 건, 데이터를 다스릴 수 있다는 확신이다.

첫발을 어디에 떼야 할지 막막하다면, 굳이 큰 그림부터 그릴 필요는 없다. 상대적으로 덜 민감한 진료 지침 하나를 골라 압축부터 해보는 것만으로도, 병원 안에서 모델을 다루는 감각이 잡힌다. 작은 성공이 쌓이면, 그제야 '우리 데이터를 모델에 줄 수 있다'는 판단이 선다.

지금 사용해 보기

병원 내부망에서 실제로 어떻게 돌아가는지 보고 싶다면, UglyPear Data가 제공하는 RAG 데이터 엔지니어링 기반을 아래에서 확인해 보세요.

• 공식 사이트: https://www.uglypear.com/ko/
• 제품별 압축·정리 능력(SmartSlim, MagiFiler, compress-mcp): https://www.uglypear.com/ko/products/
• 엔지니어링 사례와 기술 글: https://www.uglypear.com/ko/blog/

자주 묻는 질문

Q. 의료 데이터는 무조건 private 배포여야 하나요?
A. 꼭 그렇지는 않습니다. 다만 환자 프라이버시를 다루거나 보안 규제·데이터 반출 제약을 받는 자료라면 private 쪽이 한결 안정적인 선택입니다. 데이터가 내부망을 벗어나지 않으면 컴플라이언스 부담도 줄어듭니다.

Q. 문서 압축하면 진료 기록이 안 보이게 되진 않나요?
A. 압축은 부피를 줄이는 것이지 내용의 가독성을 없애는 게 아닙니다. 실측으로 443쪽 OFD 문서를 끝까지 124초에 처리했고, 글자와 날인은 그대로 보존됩니다. 고르실 때는 압축이 "판독에 지장을 줄 만큼 손실형인가"를 보시면 됩니다.

Q. RAG와 문서를 그대로 모델에 주는 건 무엇이 다른가요?
A. 그대로 주면 길이 초과·문맥 유실·딴소리 답변이 생깁니다. RAG는 문서를 우선 슬라이싱·탈감·색인한 뒤 필요할 때 검색하므로 답이 추적 가능해집니다.

Q. 기술팀이 없는 소규모 병원도 올릴 수 있나요?
A. private 배포는 국산 환경에 적응하고 납품 지원을 받을 수 있습니다. 인력이 빠듯하다면 압축과 파일 정리 같은 가벼운 고리부터 시작하는 게 더 현실적입니다.

Q. 민감정보 마스킹이 일반 내용까지 잘못 건드리진 않나요?
A. 13개 범주 탐지는 규칙으로 이름·신분증 번호·진료 기록 번호 등을 식별합니다. 마스킹은 복원 가능 방식과 비가역 마스크 두 가지로 처리하며, 구체적 전략은 배포 시 요구에 맞춰 정할 수 있습니다.