OpenMRS: 무료 오픈소스 전자의무기록 플랫폼

병원 소프트웨어는 보통 영업 전화 뒤에서 결정되는 구매 건이고, 가격과 라이선스 조건은 벤더가 정합니다. OpenMRS는 이 모델 자체를 정면으로 거스르는 프로젝트입니다 — 코드, 라이선스, 커밋 히스토리가 벤더의 서버가 아니라 GitHub에 공개되어 있는, 무료 오픈소스 전자의무기록(EMR) 플랫폼입니다.

이건 그냥 믿고 넘어가기보다 직접 확인해볼 가치가 있는 지점입니다 — "소외된 의료 시스템을 위해 만들었다"는 프로젝트 중 상당수는 사실 피치덱(pitch deck) 수준에 머물러 있기 때문입니다. OpenMRS 자체 저장소들이 바로 그 확인이 이뤄지는 곳입니다 — 라이선스 문구, 릴리스 노트, 그리고 이 글을 쓰기 하루 전까지도 움직이고 있던 커밋 그래프입니다.

이 오픈소스 전자의무기록 플랫폼의 정체 — 프로젝트가 직접 밝힌 말로

OpenMRS의 GitHub 조직 소개글은 프로젝트를 한 줄로 설명합니다 — "Open source Medical Records by and for the entire planet, starting with the developing world."(개발도상국부터 시작해, 전 지구를 위한, 전 지구에 의한 오픈소스 의료 기록.) 대표 저장소인 openmrs-core README는 같은 목표를 더 실무적으로 풀어내며, 프로젝트가 존재하는 이유를 "to improve health care delivery in resource-constrained environments"(자원이 제한된 환경에서 의료 전달 체계를 개선하기 위해)라고 밝힙니다.

같은 README에는 digitalpublicgoods.net/r/openmrs로 연결되는 "Verified-DPG" 배지도 붙어 있습니다 — 유엔과 연계된 이니셔티브인 Digital Public Goods Alliance가 공개된 기준에 따라 오픈소스 소프트웨어를 심사해 운영하는 레지스트리입니다. 이 글은 이번 세션에서 해당 레지스트리 페이지를 독립적으로 열어볼 수 없었고(도메인 자체가 접속되지 않았습니다), 그래서 이 주장은 레지스트리를 통해 확인된 사실이 아니라 — 프로젝트가 자체 README에 내걸고 있는 배지 그대로 — 있는 그대로만 보고합니다.

라이선스에는 전용 Healthcare Disclaimer(의료 면책 조항)가 있습니다

OpenMRS는 수정된 Mozilla Public License 2.0 아래 배포되며, 저장소 자체 메타데이터에는 "MPL 2.0 w/ HD"로 태그되어 있습니다. 여기서 "HD"는 실제로 추가된 조항인 Healthcare Disclaimer(의료 면책 조항)를 가리키는데, 표준 MPL 조건 위에 "additional disclaimer of warranty and limitation of liability are hereby incorporated"(추가적인 보증 부인 및 책임 제한 조항이 여기 포함된다)는 내용을 명시합니다.

실질적인 효과는 형식적인 문구가 아니라 구체적입니다. 라이선스는 "use of the covered code is not a substitute for a health care providers standard practice or professional judgment"(이 코드의 사용이 의료 제공자의 표준 진료 행위나 전문적 판단을 대체하지 않는다)라고 명시하고, 기여자와 배포자는 임상적 실패나 개인정보 유출에 따른 간접적 피해에 대해 책임을 지지 않는다고 못 박습니다. 실제 환자 차트 안에 들어가게 될 소프트웨어라는 점을 생각하면, 이건 일반적인 MIT나 Apache 라이선스가 하지 않는 일을 라이선스가 직접 하는 셈입니다 — 임상적 책임을 소프트웨어를 작성한 오픈소스 메인테이너가 아니라, 그 소프트웨어를 사용하는 의료 제공자 쪽으로 명시적으로 돌려놓는 것입니다.

하나의 앱이 아니라, 저장소들이 쌓인 스택

OpenMRS는 다운로드해서 쓰는 단일 프로그램이 아닙니다. 조직이 고정해 둔(pinned) 저장소들은 제품을 여러 레이어로 나눕니다. openmrs-core는 Java API와 웹 애플리케이션 엔진입니다(스타 2k개, 포크 4.5k개). openmrs-distro-referenceapplication은 "the reference distribution of the OpenMRS EMR application"(OpenMRS EMR 애플리케이션의 레퍼런스 배포판)으로, 수동 서버 설치가 아니라 Docker Compose로 실행하도록 만들어졌습니다. openmrs-esm-patient-chart는 더 최신의 "O3" 프런트엔드로, 자체 README는 이를 "microfrontends that constitute widgets in a patient dashboard"(환자 대시보드의 위젯을 구성하는 마이크로프런트엔드들의 집합)라고 설명합니다. 그리고 openmrs-module-fhir2는 표준 모듈로, README는 "intended to be a replacement for the current OpenMRS FHIR module, initially using FHIR R4"(현재의 OpenMRS FHIR 모듈을 대체하기 위한 것으로, 초기에는 FHIR R4를 사용한다)라고 밝힙니다 — FHIR는 OpenMRS 인스턴스가 독자적인 데이터 섬이 되는 대신 다른 의료 시스템과 레코드를 주고받을 수 있게 해주는 상호운용성 표준입니다.

이 저장소들 전체에서 하나의 패턴이 드러납니다 — 포크 수가 스타 수를 앞서고, 그 차이가 꽤 큰 경우가 많다는 것입니다. 레퍼런스 애플리케이션 배포판은 스타 122개에 포크 650개입니다. REST 웹서비스 모듈은 스타 109개에 포크 597개입니다. 대표 저장소인 core조차 스타(2k)보다 포크(4.5k)가 더 많습니다. 대부분의 GitHub 프로젝트에서는 이 비율이 반대로 나타납니다 — 사람들은 북마크하듯 스타를 누르고, 실제로 실행하거나 수정하려고 포크하는 건 그중 일부에 불과합니다. 스타보다 포크가 다섯 배 많은 레퍼런스 EMR 배포판은 멀리서 감탄만 하는 도구보다는, 실제로 가져다가 자신만의 인스턴스를 세우는 도구에 가깝게 읽힙니다 — 다만 이 포크들 중 몇 개가 실제 운영 중인 병원 배포이고 몇 개가 중단된 실험인지는 이 글이 말할 수 없습니다. GitHub의 포크 수는 둘을 구분해주지 않기 때문입니다.

실제 배포 사례가 그 위에서 돌아갑니다

OpenMRS가 단순히 보여주기용으로 포크되는 게 아니라 실제로 배포된다는 가장 분명한 증거는, 다른 오픈소스 프로젝트들이 그 위에 직접 지어지고 있다는 사실입니다. 별도의 GitHub 조직인 Bahmni는 자신을 "Open Source Hospital Management System & EMR built on top of OpenMRS, OpenELIS and Odoo"(OpenMRS, OpenELIS, Odoo 위에 구축된 오픈소스 병원 관리 시스템 & EMR)라고 소개합니다. Bahmni의 저장소는 "Clinics and Small Hospitals"(진료소와 소규모 병원)를 명시적으로 겨냥한 clinic-config 배포판과, 더 큰 시설을 위한 더 무거운 standard-config로 나뉘어 있고 둘 다 Docker로 배포되며, 이 조직의 GitHub 토픽 태그에는 hospital-management-system, emr, social-impact가 포함되어 있습니다.

Bahmni는 OpenMRS 조직 자체의 일부가 아닙니다 — 의료 기록 엔진을 처음부터 새로 작성하는 대신 OpenMRS의 core 위에 자신들의 병원 소프트웨어를 짓기로 선택한, 독립적인 다운스트림 프로젝트입니다. 이건 OpenMRS가 자사 홈페이지에 올릴 수 있는 어떤 통계보다 더 강력한 실제 사용 신호입니다 — 바로 OpenMRS의 사용률을 부풀릴 이유가 전혀 없는 별도의 팀에서 나온 것이기 때문입니다.

여전히 출시 중입니다, 박물관 전시품이 아닙니다

오픈소스 전자의무기록 플랫폼은 실제로 유지보수되고 있을 때에만 가치가 있으므로, 커밋 히스토리를 직접 확인해볼 가치가 있습니다. 이번 확인 시점을 기준으로 master 브랜치에는 2026년 10월 29일 — 이 글을 쓰기 하루 전 — 날짜의 커밋이 있었고, 여기에는 "TRUNK-6859: Make domain object collection setters update Hibernate-managed collections in place" 같은 티켓이 포함되어 있었으며, 그 이전 한 주 동안에도 날짜가 찍힌 커밋들이 계속 이어졌습니다.

티켓 번호 접두사(TRUNK-####)는 GitHub 기능이 아니라, 외부 JIRA 트래커를 가리키는 참조입니다. 이는 저장소 자체의 Issues 탭이 열린 이슈 0개를 보여주는 이유도 설명해줍니다 — OpenMRS는 버그 트리아지를 GitHub에서 전혀 하지 않습니다. CONTRIBUTING.md는 기여자들에게 먼저 JIRA에서 "Ready for Work" 이슈를 선점한 다음, 그에 대응하는 GitHub 풀 리퀘스트를 여는 과정을 안내합니다 — 그래서 같은 Issues 탭에 열린 이슈 0개 대비 열린 풀 리퀘스트 346개가 나타나는 것이고, 버그 트래커가 완전히 다른 곳에 있다는 걸 알기 전에는 이 조합이 이상하게 보일 수 있습니다.

릴리스 페이지를 보면 프로젝트가 두 개의 버전 라인을 동시에 유지하고 있다는 걸 알 수 있습니다. 2.8.10(10월 6일)과 2.7.6(9월 12일)이 같은 달 안에 함께 출시됐고, 그 전에는 2.8.0(8월 15일)과 2.7.4(5월 21일)이 있었습니다. 현재 브랜치와 레거시 호환 브랜치를 나란히 운영하는 건, 배포된 모든 병원에 메인테이너의 일정대로 업그레이드를 강제할 수 없는 소프트웨어에서 흔히 나타나는 모습입니다 — 이런 제약은 취미 프로젝트가 아니라 사람들이 실제로 의존하는 인프라에서 주로 나타납니다.

솔직하게 밝혀야 할 한계

이 글이 검증할 수 있는 건 정확히 GitHub가 보여주는 것까지이고, 그 이상은 아닙니다. OpenMRS 자체 마케팅 사이트인 openmrs.org와 거기서 링크하는 Digital Public Goods 레지스트리 페이지는 둘 다 이번 세션의 사실 확인 과정에서 접속되지 않았습니다. 그래서 이 글 어디에도 국가 수, 환자 기록 총량, 배포 건수 같은 숫자는 등장하지 않습니다 — 그런 숫자들은 OpenMRS 자체 사이트에 존재하지만, 이 글은 직접 열어서 확인하지 못한 숫자를 그대로 가져다 쓰지 않습니다.

확인 가능한 것들도 양면을 다 보여줍니다. 매일 커밋이 병합되고 있는 프로젝트에 열린 풀 리퀘스트 346개가 쌓여 있다는 건 죽은 적체가 아니라 살아있는 적체라는 뜻이지만, 그래도 적체는 적체입니다 — 이 정도 규모라면 기여자의 PR이 몇 달째 리뷰도 받지 못한 채 방치되는 일도 충분히 있을 법합니다. 그리고 포크가 스타를 앞서는 것은 실제 배포에 대한 합리적인 신호일 뿐, 증거는 아닙니다. GitHub는 어떤 포크가 실제로 운영 중인 병원 시스템이고 어떤 포크가 주말 실험 후 버려졌는지를 알려주지 않습니다.

이것이 일반화되는 지점

여기서 유용한 습관은 의료 기록에만 해당하는 게 아닙니다. 어떤 소프트웨어가 "자원이 부족한" 또는 "개발도상국" 사용자를 위한다고 주장할 때는, 그 주장이 반증 가능한 형태로 어딘가에 드러나는지 확인하세요 — 임상적 책임을 침묵하지 않고 명시적으로 배분해 둔 라이선스, 여전히 활발한 커밋 로그, 그리고 이상적으로는 벤더 자신의 사례 연구 페이지가 아니라 독립적인 다운스트림 프로젝트가 그 위에 뭔가를 짓기로 선택했는지 같은 것들입니다. 이건 접근성 도구가 실제로 아직 유지보수되고 있는지 확인하는 것이나 기부 플랫폼의 투명성 약속이 실제로 읽을 수 있는 공개 장부로 뒷받침되는지 확인하는 것과 같은 원칙이며, 간격 반복 알고리즘의 소스 코드를 직접 읽는 것이 기능 목록을 그냥 믿는 것보다 나은 이유도 같은 본능에서 나옵니다. 소프트웨어가 자신을 실망시켰을 때 그걸 감당할 여력이 가장 적은 사람들을 위해 만들어진 플랫폼이야말로, 홍보 문구를 곧이곧대로 받아들이기보다 직접 확인해볼 가치가 있는 플랫폼입니다.