헬스케어 AI가 현실 세계에서 실패하는 이유

서론

2018년, 한 임상 정보학자(clinical informaticist)가 의사들이 타이핑하는 시간을 줄이고 진료에 더 집중할 수 있도록 접수 양식과 임상 기록을 처리하는 도구를 출시했습니다. 18명의 의대생을 대상으로 한 소규모 연구에 따르면, Cydoc 스마트 접수 양식은 기록의 품질을 유지하면서도 기록 작성 시간을 실질적으로 단축할 수 있는 것으로 나타났으나, 실제 임상 의사들을 대상으로 한 더 광범위한 검증은 여전히 필요한 상태였습니다. 2025년 8월까지, 이 회사는 사라졌습니다.

해당 사후 분석(postmortem)은 주요 원인을 다음과 같이 밝히고 있습니다: Cydoc이 EHR(전자 건강 기록) 외부에서 작동했다는 점입니다. 의사들은 Cydoc 인터페이스에서 기록을 복사하여 EHR에 붙여넣어야 했으며, 이는 두 개의 창을 띄워놓고 작업해야 함을 의미했고, 일상적인 임상 문서화 과정에 추가적인 워크플로우(workflow) 단계를 더하게 되었습니다. 창업자는 나중에 EHR 통합의 부재를 치명적인 도입 실수라고 설명했습니다.

Cydoc은 예외적인 사례가 아닙니다. 강력한 모델을 갖추고 있더라도, 헬스케어 AI 프로젝트는 이미 복잡한 임상 워크플로우(clinical workflows)에 마찰을 가할 때 실패할 수 있습니다. 2025년 말에 실시된 인프라 및 운영 리더 대상 Gartner 설문조사에 따르면, AI 활용 사례 중 단 28%만이 완전히 성공하여 ROI(투자 대비 수익) 기대치를 충족했으며, 20%는 완전히 실패했습니다. 보고된 장벽 중에는 낮은 데이터 품질, 제한된 데이터 가용성, 그리고 취약한 워크플로우 통합 등이 포함되었습니다. 제품 구축 전 단계부터 파일럿 및 확장 단계에 이르기까지 동일한 실수들이 반복되지만, 다행인 점은 이러한 실수들이 필연적인 것은 아니라는 사실입니다.

구축 전 단계: 실패를 위한 설정

구축 전(Pre-build) 단계의 실패는 디버깅(debug)할 대상이 아직 없고 되돌릴(roll back) 라이브 서비스도 없기 때문에 놓치기 가장 쉽습니다. 그 결과가 나타날 때쯤이면, 이를 수정하는 비용은 제품 설계, 데이터 액세스 계획, 그리고 워크플로우 발견(workflow discovery) 단계에서 예방하는 비용보다 훨씬 더 비싸질 수 있습니다.

Cydoc는 처음부터 EHR (Electronic Health Record, 전자 건강 기록) 통합이 중요하다는 것을 알고 있었습니다. 창업자는 자신의 임상 수련 과정에서 망가진 EHR 워크플로우(workflow)를 직접 경험했기 때문입니다. 하지만 회사는 이를 구축할 여력이 없었고, 결국 통합 기능 없이 제품을 출시하며 문제를 뒤로 미뤘습니다. EHR 통합은 끝내 이루어지지 않았고, Cydoc는 임상가들의 워크플로우에 맞춰지는 대신 임상가들에게 워크플로우를 변경하도록 요구하는 도구를 판매하기 위해 수년을 허비했습니다.

잘못된 문제 해결하기

가장 흔한 구축 전 실패 사례는, 누군가가 모델이 잘 수행할 수 있는 무언가를 발견한 뒤에야 그것을 연결할 임상적 문제를 찾기 시작할 때 발생합니다.

도구는 만들어지고, 점수(score)는 좋아 보이지만, 아무도 사용하지 않습니다. 의사가 이미 의심하고 있는 내용을 확인해주기만 하거나, 그 순간에 조치를 취할 수 없는 위험을 지적하는 알림은 그것이 얼마나 정확한지와 상관없이 무시됩니다.

무엇인가를 구축하기 전에, 당신이 목표로 하는 문제를 다루는 임상가를 한 명 찾아 다음과 같이 물어보십시오. 그 문제가 근무 교대 시간 중 정확히 언제 발생하는지, 현재는 어떻게 대처하고 있는지, 그리고 당신의 도구와 같은 것이 실제로 업무를 쉽게 만들어 줄 것인지 아니면 그저 마찰(friction)만 더할 뿐인지 말입니다. 헬스케어 AI에 있어 "사용자 발견(user discovery)"은 마케팅 활동이 아니라, 임상적 안전, 채택(adoption), 그리고 구현(implementation)을 위한 필수 요구사항입니다. 때로는 그 답이 AI와는 완전히 무관한 방향을 가리킬 수도 있으며, 시작 단계에서 이를 받아들이는 것이 수개월의 작업 시간과 수천 달러의 비용을 아껴줍니다.

존재하지 않는 데이터에 의존하기

흔히 하는 실수는 데이터가 라벨링된(labeled) 연구용 데이터셋과 비슷할 것이라고 생각하는 것입니다. 실제 EHR 데이터는 혼돈 그 자체입니다. 임상적으로 의미 있는 정보의 상당 부분은 비정형 노트(unstructured notes), 보고서, 서술형 기록에 존재하며, 그중 많은 부분이 구조화된 필드(structured fields)에 반영되어 있지 않습니다. 깨끗하고 분석 준비가 된 데이터에 의존하는 모든 프로젝트는 이 벽에 부딪히게 될 것입니다.

180만 개의 환자 기록을 대상으로 한 2025년 연구에 따르면, 자유 형식 텍스트(free text) 내 임상적으로 유의미한 개념 중 구조화된 필드(structured fields)에 대응하는 개념은 단 13%에 불과했습니다. 임상의가 특정 진료 내용을 기록하는 방문(visit) 수준에서는 이 비율이 7%까지 떨어졌습니다.

게다가 동일한 진단명이라도 부서마다 다르게 코딩되기도 하며, 결측치(missing values)는 환자의 실제 상태보다는 문서화 문화(documentation culture)를 반영하는 패턴을 따릅니다. 이러한 데이터로 학습된 모델은 이러한 인위적인 흔적(artifacts)을 임상적 신호(clinical signals)로 오인할 수 있습니다.

SciForce는 내부 헬스케어 AI 도구를 구축하는 과정에서 이러한 의미론적 표준화(semantic standardization) 문제에 직면했습니다. 소스 시스템의 용어들이 표준 어휘집(standard vocabularies)에 매핑되지 않거나, 변환 과정에서 임상적 세부 사항이 손실되고, 전문 인력들이 일관된 결과도 얻지 못한 채 몇 주 동안 수작업에 투입되는 상황이 발생했습니다. 이것이 바로 Jackalope가 탄생하게 된 계기입니다. Jackalope는 OMOP CDM 및 SNOMED CT 전반에 걸쳐 의료 데이터 표준화를 자동화하는 머신러닝(ML) 기반 도구입니다. 헬스케어 AI를 구축하는 팀에게 이는 단순한 부수적인 데이터 정제 작업이 아닙니다. 이는 모델이 여러 기관에서 학습, 검증, 설명 및 재사용될 수 있는지를 결정짓는 핵심 계층(layer)입니다.

데이터 접근을 단순한 세부 사항으로 취급하는 문제

서류 작업과 환자 데이터 접근 권한 확보는 흔히 프로젝트가 무너지는 지점입니다. 윤리 위원회(ethics board)의 승인을 받아야 하고, 비식별 데이터(de-identified data) 사용 허가를 얻어야 하며, IT 보안 점검을 통과해야 하고, 종종 데이터 사용 계약(data use agreements)도 체결해야 합니다. 많은 기관에서 이러한 프로세스는 순차적으로 진행되거나 부분적으로만 병렬로 이루어지는데, 이로 인해 데이터 접근은 단순한 행정적 세부 사항이 아니라 프로젝트의 성패를 가르는 결정적인 의존성(dependency)이 되어버립니다.

277개의 프로토콜을 대상으로 한 연구에 따르면, 10개의 VA 기관생명윤리위원회 (Institutional Review Boards, IRB)에서 윤리 심사(ethics review)에 평균 112일이 소요되는 것으로 나타났습니다. 이제 소규모 스타트업에 필요한 시간을 상상해 보십시오. 2025년 다기관 연구에서는 데이터 사용 계약 (data use agreements)을 체결하는 데 26개월이 걸리고, 실제 데이터 추출 (data extraction)에 추가로 14~22개월이 소요된다는 점을 기록했습니다. 이러한 규모에서는 모델을 훈련하는 두 달의 시간이 승인을 기다리는 수년의 시간으로 쉽게 변질될 수 있습니다.

현실적인 대응책은 모델 아키텍처 (model architecture)를 설계하기도 전인 첫날부터 서류 작업을 시작하는 것입니다. 그동안에는 PhysioNet의 MIMIC-III/IV나 eICU Collaborative Research Database와 같이 공개적으로 사용 가능한 데이터셋을 사용하여 모델을 훈련하십시오. 합성 데이터 (Synthetic data)는 파이프라인 (pipelines), 인터페이스 (interfaces), 개인정보 보호 워크플로 (privacy-preserving workflows), 그리고 일부 모델 개발 가설을 테스트하는 데 유용할 수 있지만, 대표성 있는 실제 임상 데이터 (real-world clinical data)를 통한 검증 (validation)을 대체하는 수단으로 취급해서는 안 됩니다.

파일럿: 워크플로의 저항

모든 파일럿 (pilot)은 동일한 방식으로 시작됩니다. 데모는 잘 진행되고, 누군가는 "이것이 정말 많은 것을 바꿀 수 있겠군요"라고 말하지만, 두 달 뒤에는 아무도 그 제품을 사용하지 않습니다.

Cydoc의 경우, 유료 고객이 있었음에도 불구하고 제품을 사용하지 않았는데, 그 이유는 제품을 사용하는 것이 이미 충분히 잘 작동하고 있는 워크플로 (workflow)를 변경해야 함을 의미했기 때문입니다. 도구는 기술적으로 견고하고 임상적으로 유의미할 수 있지만, 모델과는 전혀 상관없는 이유로 결국 사용되지 않을 수 있습니다.

임상적 가치 없는 정확도 (Accuracy Without Clinical Value)

내부 검증 (Internal validation) 단계에서 높은 점수를 얻는 것은 성공적이지만, 그것만으로는 모델을 배포하기에 충분한 이유가 되지 않습니다.

2025 JAMA Network Open 연구는 문헌에 나타난 동일 입원 (same-admission) AI 모델들을 검토하였으며, 그중 40.2%가 사망률 (mortality)을 예측하기 위한 입력 데이터로 ICD 코드 (ICD codes)를 사용하여 학습되었다는 사실을 발견했습니다. 그러나 ICD 코드는 환자가 퇴원한 후 청구 담당자에 의해 할당되며, 치료 시작 시점에 알고 있었던 정보가 아닌 최종 진단을 설명합니다. 저자들의 사망률 예측 실험에서 ICD 코드를 사용한 모델들은 매우 높은 AUROC 값을 달성했는데, 이는 임상적으로 사용 가능한 전향적 예측 (prospective prediction)이라기보다는 레이블 누수 (label leakage)를 보여주는 사례였습니다. 이와 유사한 상황을 피하려면, 임상의가 모델을 사용해야 하는 시점에 사용 가능한 모든 입력값을 감사 (audit)해야 합니다. 규모가 작은 제2기관 검증 코호트 (second-institution validation cohort)만으로도 내부 테스트에서 놓친 부분을 잡아낼 수 있습니다.

너무 많은 알림, 너무 적은 조치 (Too Many Alerts, Too Little Action)

임상의가 구체적으로 조치를 취할 수 없는 잘못된 알림 (false alerts)이 반복되면, 그들은 이러한 방해가 가치가 없다는 것을 학습하게 됩니다.

Epic 패혈증 (sepsis) 예측 모델에 대한 외부 검증 (External validations) 결과는 성능이 사이트, 임계값 (threshold), 환자군, 그리고 구현 맥락 (implementation context)에 따라 달라질 수 있음을 반복적으로 보여주었습니다. (출판 전, 이 정확한 "14%" 수치는 인용된 논문을 통해 확인되어야 합니다.) 또한, 알림이 정확하게 발생하더라도 패혈증이 이미 다른 수단에 의해 식별된 이후에 도착하는 경우가 많았습니다. 알림 시스템의 경우, 알림은 정확할 뿐만 아니라 적시에 도착해야 하며, 임상의가 그 알림으로 인해 평소와 다르게 행동할 수 있도록 충분한 정보를 제공해야 합니다.

또 다른 질문은 알림 시스템(alert system) 자체가 적절한 인터페이스인가 하는 점입니다. 헬스케어 기술 제공업체를 위해, SciForce는 의사가 특정 환자에 대해 질문할 수 있는 LLM 기반 시맨틱 검색 (LLM-powered semantic search)을 구축했습니다. 의사는 일상적인 언어로, 행동할 준비가 된 시점에 질문을 던지고 환자의 기록에서 추출된 관련 답변을 얻을 수 있습니다. 이는 설계 철학 자체가 다릅니다. 과부하된 워크플로 (workflow)에 또 다른 알림을 밀어넣는 대신, 시스템이 의사결정 시점에 임상의가 주도하는 검색 (clinician-initiated retrieval)을 지원하는 방식입니다.

아무도 원하지 않았던 또 하나의 대시보드

파일럿 프로젝트 실패를 예측할 수 있는 신뢰할 만한 지표는 임상의가 이미 사용 중인 시스템을 떠나야만 하는 도구입니다. Cydoc은 EHR (전자 건강 기록) 외부에서 작동했기에, 의료진은 두 번째 인터페이스를 관리해야 했습니다. 이는 매 교대 근무마다 환자 한 명당 한 단계의 추가 작업이 발생함을 의미했습니다.

Duke University 또한 Sepsis Watch를 통해 이와 유사한 워크플로 통합 (workflow-integration) 문제를 겪었습니다. 패혈증 예측 도구가 별도의 iPad에 배포되었기 때문에, 간호사들은 iPad를 모니터링하고 환자 차트를 대조하며, 알림을 담당 의사에게 수동으로 전달해야 했습니다. 병원은 AI와 임상 워크플로를 연결하기 위해 완전히 새로운 간호 역할을 만들어야만 했습니다. 이것이 해당 시스템이 임상적으로 실패했다는 의미는 아닙니다. Duke는 이후 Sepsis Watch의 확장을 보고했습니다. 하지만 이는 성공적인 AI 배포를 위해서는 단순히 모델과 인터페이스뿐만 아니라, 새로운 노동력, 새로운 역할, 그리고 능동적인 워크플로 수선 (workflow repair)이 필요할 수 있음을 보여줍니다.

Johns Hopkins는 동일한 문제를 다르게 해결했습니다. 그들은 유사한 패혈증 (sepsis) 모델을 별도의 시스템이나 로그인 없이 기존 EHR (전자 건강 기록) 인터페이스 내에 클릭 가능한 아이콘으로 직접 삽입했습니다. 5개 병원에 걸쳐 89%의 알림이 평가되었으며, 알림이 3시간 이내에 확인된 환자들은 사망률이 18.7% 감소하는 결과를 보였습니다. 여기서 얻을 수 있는 교훈은 특정 인터페이스 패턴이 항상 승리한다는 것이 아니라, 도입 여부는 해당 도구가 임상 의사결정 경로 (clinical decision pathway), 책임 구조 (accountability structure), 그리고 진료 타이밍 (timing of care)에 부합하는지에 달려 있다는 것입니다.

규모 (Scale): 여기서는 작동하지만, 저기서는 실패한다

성공적인 파일럿 (pilot)은 해당 모델이 하나의 기관에서는 작동했음을 의미합니다. 이를 널리 채택되고 상업적으로 성공적인 제품으로 전환하려면, 새로운 사이트에서의 일관된 성능, 규제 승인 (regulatory clearance), 그리고 처음부터 다시 구축할 필요 없이 확장 가능한 아키텍처 (architecture)가 필요합니다.