MediBridge는 편의보다 안전을 우선합니다. 병원은 아무 포트도 열지 않고, 데이터는 연결 경로 어디에서도 평문으로 노출되지 않습니다.
병원 안의 Agent가 항상 먼저, 밖으로만 연결합니다. 밖에서 들어오는 문(인바운드 포트)은 하나도 열지 않습니다.
나가는 데이터는 받는 사람의 열쇠로만 열리는 봉투(종단간 암호화)에 담깁니다. 중간의 중계 서버는 뜯어볼 수도, 바꿔치기할 수도 없습니다.
병원이 허용 목록에 올린 요청과 항목만 처리됩니다. 목록에 없는 것은 전부 거절이 기본값이고, 반출 범위는 병원이 직접 정합니다.
여러 종류의 데이터베이스와 병원이 제공하는 API를 하나의 표준 흐름으로 연결합니다.
연결·암호화·연동·통제까지, 실제 운영에서 검증된 구성 요소로 이루어져 있습니다.
Agent가 mTLS로 게이트웨이에 아웃바운드 연결을 유지하고, 그 통로로만 명령과 응답이 오갑니다. 병원은 인바운드를 열지 않습니다.
응답은 수신자 공개키로 봉인(HPKE)되어 중계 서버도 내용을 볼 수 없고, 명령은 서명되어 위조를 차단합니다.
서로 다른 데이터베이스와 병원 제공 API를 하나의 커넥터 계층으로 연결해, 현장마다 다른 연동을 표준화합니다.
발급·자동 회전·폐기(CRL)까지 무중단으로 관리합니다.
연결 상태·토큰·감사 이벤트를 한 화면에서 관리합니다.
연동 주체별로 접근 가능한 범위를 분리합니다.
PACS 규모의 데이터도 암호문 상태로 중계합니다.
현장 시스템과 외부 서비스 사이를, 내용을 알 수 없는 중계 게이트웨이가 안전하게 잇습니다.
결제·수납 등 실제 데이터가 있는 병원 시스템과 MediBridge Agent.
명령을 라우팅하고 봉인된 응답을 전달하되, 내용은 볼 수 없는 중계 계층.
자기 키로 응답을 복호화해 데이터를 사용하는 외부 애플리케이션.
데이터를 연동한다고 하면 가장 먼저 나오는 걱정입니다. 백도어는 시스템 주인 몰래 숨겨 놓은 통로입니다. MediBridge는 반대입니다 — 병원이 직접 설치를 승인하고, 접근 범위를 정하고, 언제든 끌 수 있습니다. 열쇠가 전부 병원에 있습니다.
외부(운영사 포함)는 병원이 허용한 데이터만, 병원이 허용한 동안만 받을 수 있습니다.
Agent는 병원 또는 병원이 지정한 EMR 업체만 설치할 수 있습니다. 운영사도 병원 동의 없이는 설치·변경이 불가능하고, 병원은 언제든 Agent를 종료해 모든 연동을 즉시 끊을 수 있습니다.
병원 DB는 내부 통신만 허용하므로 외부에서 직접 닿을 방법 자체가 없습니다. Agent는 병원이 발급한 최소권한 계정으로, 병원이 등록한 저장 프로시저만 호출합니다. 임의 SQL은 실행되지 않습니다.
백도어의 본질은 '몰래'입니다. MediBridge의 모든 요청은 서명 검증을 거치고, 무엇이 언제 어떤 데이터를 조회했는지 위변조가 탐지되는 감사 로그로 병원이 전부 확인할 수 있습니다.
소유자 몰래 설치되고, 소유자가 모르는 경로로, 소유자의 통제 밖에서 동작하는 숨은 통로.
병원이 알고 승인해 설치하고, 병원이 정한 범위만 수행하며, 병원이 언제든 끌 수 있는 공개된 통로. — 백도어의 정의 세 가지 모두에 해당하지 않습니다.
기존 연동은 병원 안에 연동용 API 서버(프로그램)를 두고, 외부 서비스가 그 API에 접속할 수 있도록 방화벽 인바운드 포트를 열어 주는 방식이 일반적입니다. DB를 직접 여는 것은 아니지만, "밖에서 들어오는 문"이 생긴다는 사실은 같습니다. 그 방식과 팩트로 비교합니다.
밖으로 나간 연결을 이용한다는 점 때문에 ngrok·SSH 역터널 같은 '방화벽 우회 통로'로 오해받기도 합니다. 연결 방향이 아웃바운드인 것은 같지만, 결정적 차이는 그 통로로 무엇이 지나갈 수 있는가입니다.
Agent는 서버가 필요한 장비가 아니라 수납자 PC에 설치되는 가벼운 프로그램입니다. 수납 PC가 여러 대인 현장에서는 각 PC에 Agent를 함께 설치할 수 있고, 외부 통신은 그 PC들에서 밖으로만 나갑니다.
병원마다 앱마다 연동을 따로 만들면 조합 수만큼(N×M) 통로와 관리 부담이 늘어납니다. MediBridge는 병원과 앱이 각각 표준 하나로만 연결되므로(N+M), 연동이 늘어날수록 차이가 커집니다.
병원은 대부분 고정 IP를 사용합니다. 인바운드를 여는 구조에서는 변하지 않는 주소가 '언제든 다시 찾아올 수 있는 표적'이 되지만, 아웃바운드 전용 구조에서는 반대로 보안을 강화하는 근거가 됩니다.
MediBridge의 목적은 병원 데이터를 임의로 가져오는 것이 아닙니다. 병원·EMR의 승인 아래 보안 연결(핫라인) 하나를 만들어 두고, 그 위에 서비스를 쌓는 것입니다. 어떤 서비스든 중계 서버의 인증을 통과해야만 병원과 대화할 수 있습니다. 이 공통 기반 위에서 결제·보험청구·예약·처방 전달 같은 다양한 사업으로 확장합니다.
서비스가 아무리 늘어도 병원 연결은 이 핫라인 하나 — 모든 접근은 중계 서버의 인증을 통과해야만 병원에 닿습니다.
서비스(앱)는 중계 서버가 발급한 API 토큰(병원·기능 범위 제한)과 등록된 수신자 키가 있어야 하고, 모든 명령은 서명 검증을 통과해야 병원까지 전달됩니다. 범위 밖 요청은 거부되고 기록됩니다.
Agent 설치(병원·EMR 업체)와 명령 허용 목록(병원 정책) 승인 없이는 어떤 서비스도 데이터에 닿을 수 없습니다. '허락받은 만큼만'이 약속이 아니라 기술로 강제됩니다.
핫라인은 한 번 구축하면 유지되고, 새 서비스는 중계 서버의 인증 발급(필요 시 병원의 정책 승인 추가)만으로 붙습니다. 병원 쪽 재공사 없이 결제·청구·예약·처방 전달 같은 확장 서비스를 더해갈 수 있습니다.
병원은 민감정보를 쌓아두는 것이 부담스럽고, 우리도 통째로 보관하고 싶지 않습니다. 그래서 완전한 데이터는 어디에도 저장하지 않습니다. 찢어진 지도의 반쪽처럼 — 무작위로 나눈 두 조각을 병원과 중계서버가 하나씩 보관하고, 실제로 필요한 순간에만 병원 안 Agent에서 합칩니다. 이미 구현되어 있는 기능이며, 병원이 설정과 정책으로 직접 켜는 방식입니다.
완전한 민감정보는 저장 장소가 없습니다 — 존재하는 순간은 병원 안 Agent 메모리에서 쓰이는 그 잠깐뿐입니다.
비밀분산은 각 조각이 원본에 대한 어떤 정보도 갖지 않도록 무작위로 나누는 표준 암호 기법입니다 — 1979년 발표 이후 금융·키관리에서 쓰여 온 방식입니다.[8] 큰 데이터는 데이터를 암호화한 뒤 그 키를 반씩 나누는 '분할 지식' 방식이 키 관리 표준입니다.[9]
중계서버에서 합치면 중계가 원문을 보게 되고, 외부에서 합치면 조각이 모두 밖으로 나갑니다. 그래서 결합은 데이터의 주인인 병원 안 Agent에서 — 서명·정책 검증을 통과한 요청에만, 메모리에서 잠깐 이뤄지고 즉시 폐기되며 전 과정이 감사 기록에 남습니다.
보관 기간이 끝나면 어느 한쪽 조각만 파기해도 원본은 수학적으로 복원할 수 없게 됩니다(암호 파쇄). 병원도 중계서버도 완전한 민감정보를 보관하지 않으므로, 어느 한 곳의 사고가 곧 개인정보 유출로 이어지지 않습니다.
※ MediBridge 자체 동작에 대한 서술(여는 포트 0개, 병원이 등록한 프로시저만 실행, 명령 서명, 위변조 탐지 감사 로그 등)은 실제 구현과 공개 기술 문서(콘솔 '문서' 탭, OpenAPI 명세) 기준이며, 관리자 콘솔의 데모에서 직접 확인할 수 있습니다. 분산 보관(반쪽씩 보관)은 위 표준 기법(데이터는 AES-256-GCM 암호화, 키를 2-of-2 분할 보관)으로 Agent·게이트웨이에 구현되어 있으며, 병원의 명시적 옵트인(Agent 설정 + 정책 허용)과 Agent의 클라이언트 인증서 인증이 모두 갖춰져야 동작합니다.
도입 전 문제와 적용 후 개선 내용을 실제 사례 기준으로 정리합니다.
의료 현장에서 실제로 요구되는 연동 시나리오입니다. 공통 과제는 하나 — "병원 방화벽을 열지 않고, 개인정보를 최소로, 안전하게" — 이고, MediBridge가 그 기반을 제공합니다.
보험업법 개정으로 실손보험 청구 서류의 전자 전송이 제도화되어 2024년 10월 병원급부터 시행되었고, 2025년 10월 의원·약국까지 확대되었습니다. 병원 내부의 진료비 세부내역 등을 외부로 안전하게 내보내야 하는 법정 수요가 생긴 것입니다.
MediBridge는 병원 EMR·청구 시스템의 데이터를 인바운드 개방 없이, 허용된 항목만, 종단간 암호화로 반출하는 병원 구간 연동 기반을 제공합니다. 제도상 절차·전송기관 요건은 해당 제도를 따르며, 연동 구축의 기술 기반으로 활용됩니다.
병원 앱 결제, 무인 수납기(키오스크), 간편결제 연동이 보편화되면서 외부 결제 서비스가 병원 수납 시스템의 결제 대상·수납 상태를 실시간 조회해야 하는 수요가 큽니다.
MediBridge의 첫 실적용 분야입니다 — 결제 상태 조회 명령이 병원 Agent를 통해 수납 DB의 등록된 프로시저만 호출하고, 금액·상태 등 필요한 필드만 봉인되어 돌아옵니다. 구형 키오스크(32비트 Windows)까지 지원합니다.
모바일 접수 앱으로 병원에 가기 전 접수하고 순번을 확인하는 사용 방식이 소아과를 중심으로 일반화되었습니다. 이런 서비스는 병원 접수 시스템과의 실시간 양방향 연동이 필수인데, 병원마다 연동 방식이 제각각인 것이 진입 장벽입니다.
접수 현황 조회·접수 등록을 표준 명령으로 정의하고 병원별 차이는 프로시저 안에 숨기면, 앱은 병원이 늘어나도 같은 코드로 연동합니다 — 병원 추가 시 서버 배포가 필요 없는 구조입니다.
지금의 처방전은 종이로 출력해 환자가 들고 가는 방식이라 분실·재발급, 약국 도착 후에야 시작되는 조제 대기, 수기 입력 오류가 따라옵니다. 의료법은 전자처방전을 허용하고 있고(전자서명 등 요건 충족 시), 비대면 진료 흐름과 함께 병원→약국 전자 전달 수요가 계속 커지고 있습니다.
MediBridge 구조에서는 이 전달이 자연스럽게 구현됩니다:
① 환자가 약국 선택(병원 접수·앱에서) → ② 병원 Agent가 처방 데이터를 그 약국의 공개키로 봉인 → ③ 약국 프로그램이 수신·복호화 — 환자가 도착하기 전에 조제를 시작할 수 있습니다.
이 구조의 강점: 지정 약국만 열람(다른 약국·중계서버·해커 누구도 열 수 없음 — 종이보다 유출 위험이 낮음), 위변조 불가(서명 검증 — 종이 처방전 위조 문제 해소), 전달 이력 전체가 감사 기록으로 남음, 약국 측도 인바운드 개방 없이 아웃바운드 조회만으로 수신(약국에 Agent를 두면 조제 프로그램 자동 입력까지 연계 가능).
검진기관의 결과를 수검자 앱이나 기업(단체검진 계약사)으로 제공하는 서비스는 결과지의 민감정보를 최소 범위로만 내보내는 것이 관건입니다.
명령 단위의 반출 필드 제한(egressFields)으로 "종합 판정만", "특정 항목만" 같은 최소 반출을 강제할 수 있고, 모든 조회가 위변조 탐지 감사 로그에 남아 검진기관의 통제권이 유지됩니다.
진단서·통원확인서 등을 창구 방문 없이 온라인으로 발급받는 서비스가 확산 중입니다. 발급 요청 접수와 문서 데이터 전달 모두 병원 시스템과의 연동이 필요합니다.
발급 가능 여부 조회·발급 요청을 표준 명령으로, 문서 전달은 봉인 채널로 구현할 수 있습니다. 신청자 본인 확인 후 그 신청자의 키로만 봉인하면 전달 과정의 열람 위험이 원천 차단됩니다.
정부의 의료 마이데이터 사업(건강정보 고속도로)으로 의료기관이 본인 동의 기반의 진료기록 제공에 참여하는 흐름이 진행 중입니다. 참여하려는 중소 병의원에게는 내부 시스템과 제공 채널을 잇는 연동 구축이 부담입니다.
병원 내부에 Agent 하나를 설치하는 것만으로 인바운드 개방 없이 제공 데이터를 안전하게 내보내는 구간을 만들 수 있어, 참여 문턱을 낮추는 기반이 됩니다.
전원(轉院) 시 CD로 영상을 들고 가는 관행을 온라인 전송으로 바꾸는 진료정보교류가 확산 중입니다. 영상은 용량이 커서 대용량 전송과 무결성 보장이 기술 과제입니다.
MediBridge는 대용량 봉인 스트리밍(청크 단위 암호화·절단 탐지)을 갖추고 있어, 수신 병원만 열 수 있는 형태로 영상을 릴레이할 수 있습니다.
예방접종 시기, 정기검진 도래 안내 같은 리콜 서비스는 환자에게 유용하지만, 연락처·방문이력이 과잉 반출되기 쉬운 영역이라 병원이 꺼립니다.
"이번 달 검진 도래 대상의 연락처만" 같은 최소 필드 반출을 명령 정책으로 강제하고 모든 반출이 감사 기록에 남으므로, 병원이 통제권을 유지한 채 CRM 서비스와 협업할 수 있습니다.
여러 지점을 운영하는 네트워크 병원·프랜차이즈는 지점별 매출·수납·예약 현황을 본부에서 봐야 하지만, 지점마다 VPN을 깔고 유지하는 비용이 큽니다.
지점마다 Agent 하나씩 설치하면 VPN 없이 전 지점이 연결됩니다. 병원(지점) 단위 격리·토큰 범위 제한이 기본이라 지점 간 데이터가 섞이지 않으며, 수백 개 지점 규모를 전제로 설계되었습니다.
※ 제도 연계 서비스(실손 청구 전송, 마이데이터 등)는 각 제도의 절차와 참여 기관 요건을 따릅니다. MediBridge는 그 구축에 필요한 "병원 구간의 안전한 데이터 연동 기반"을 제공합니다.
병원→약국 처방 전달(활용 분야 04)을 약국 현장에서 완성하는 자매 제품입니다. 약국이 쓰던 관리 프로그램을 바꾸지 않는 것을 전제로 설계했습니다.
약국에 작은 에이전트 하나를 설치하면, 병원에서 전달된 처방이 약사가 늘 쓰던 업무 흐름 그대로 조제 프로그램에 반영됩니다. 프로그램 교체도, 약국 방화벽 개방도 없습니다.
※ MediRxAgent는 현재 개발·실증 단계의 제품입니다. 도입 시기·연동 가능한 약국 프로그램은 도입 문의를 통해 안내드립니다.
연동은 도입보다 운영이 중요합니다. MediBridge는 장애와 침해에 견디도록 설계되었습니다.
자동 재연결과 장애 격리로 연결이 끊겨도 스스로 복구합니다.
종단간 암호화와 최소권한 원칙으로 데이터를 보호합니다.
위변조가 탐지되는 감사 로그로 접근 이력을 기록합니다.
만료 전 인증서를 무중단으로 자동 갱신합니다.
병렬 처리와 백프레셔로 과부하에서도 현장 시스템을 보호합니다.
연결 상태·처리량·오류를 지표로 확인합니다.
병원 전산 담당자·보안팀·연동 개발자가 실제로 물어본 질문들입니다. 질문을 누르면 답이 펼쳐집니다.
방화벽이 막는 것은 정확히는 "외부에서 새로 들어오는 연결 시도"입니다. 일단 안에서 밖으로 시작된 연결은, 그 연결 위에서 양방향으로 데이터가 오가는 것을 허용합니다(스테이트풀 방화벽의 연결 추적). 전화와 같습니다 — 누가 걸었든 통화가 이어지면 양쪽 다 말할 수 있습니다.
병원 Agent가 서버로 아웃바운드 443(wss) 연결 하나를 걸고 끊지 않고 유지합니다. 서버는 병원으로 새 연결을 만드는 게 아니라, 병원이 걸어와 대기 중인 이 연결에 명령을 써넣을 뿐입니다. 그래서 인바운드 개방·포트포워딩·DDNS·VPN이 전혀 필요 없습니다. 카카오톡 수신, 원격지원 프로그램이 모두 같은 원리입니다.
Agent는 DB에 "밖에서" 접근하지 않습니다. Agent가 설치된 PC 자체가 병원 내부망의 구성원이므로, DB 입장에서 Agent의 접속은 원무과 청구 프로그램과 똑같은 내부망 클라이언트 접속입니다. DB 방화벽 규칙을 바꿀 필요가 없습니다.
즉 연결은 두 다리로 나뉩니다: ① Agent→DB (내부망, DB가 이미 허용하는 경로) ② Agent→중앙서버 (아웃바운드 443). 설치 PC의 조건은 "내부망으로 DB에 닿고, 인터넷 443이 나갈 것" 두 가지뿐입니다.
전부 불필요합니다. Agent가 아웃바운드로만 연결하므로 병원이 유동 IP·NAT·CGNAT 뒤에 있어도 되고, 요구사항은 아웃바운드 HTTPS(443) 허용 하나뿐입니다. 웹 브라우저가 되는 PC면 충족입니다. 프록시 강제망·폐쇄망·WebSocket 차단망도 대응 수단이 있습니다(상세는 관리자 콘솔 FAQ).
DB에 직접 접속하는 것은 맞지만, 임의 쿼리문은 절대 실행하지 않습니다. Agent는 사전 등록된 저장 프로시저만 호출하고, 파라미터는 바인딩 방식으로 전달합니다. 외부에서 오는 명령에는 SQL이 아예 담기지 않으므로(명령 이름+파라미터뿐) SQL 인젝션이 구조적으로 불가능하고, 중계서버가 해킹돼도 등록된 프로시저 외의 것을 시킬 수 없습니다.
병원 호스트가 맞습니다. 요청의 출발점(외부 앱)과 실행 주체(Agent)를 구분하면 됩니다: 외부 앱은 "결제상태 알려줘"라는 명령 이름만 보내고, 프로시저를 실제로 호출하는 것은 병원 내부망에서 실행 중인 Agent 프로세스입니다. DB 접속 정보는 병원 내부에만 있고 서버로 전송되지 않습니다 — 중계서버는 DB가 어디 있는지조차 모릅니다.
연결 방향은 역방향(아웃바운드)이 맞지만, ngrok·SSH -R 같은 범용 역터널과는 결정적으로 다릅니다. 일반 역터널은 임의의 바이트 스트림을 나르므로 내부 포트가 사실상 외부에 노출됩니다 — 중계지점이 뚫리면 내부 서비스(DB 포트 등)에 자유롭게 접속할 수 있어 보안팀이 우려하는 것이 정당합니다.
MediBridge 터널은 범용 통로가 아니라 서명 검증된 명령 메시지만 통과하는 채널입니다: ① 병원의 어떤 포트도 외부에서 도달 불가(TCP 수준 접속 자체가 존재하지 않음) ② 통과 가능한 것은 HSM 서명 + 병원 정책 화이트리스트를 통과한 명령뿐 ③ Agent가 병원 안에서 서명·정책을 독립 검증 ④ 돌아나가는 데이터는 지정 수신자만 열 수 있는 암호문. 분류하자면 ngrok보다 AWS IoT·클라우드 에이전트의 아웃바운드 명령 채널에 가깝습니다.
보안팀 설명 문구: "아웃바운드 443 연결 하나만 사용하며, 범용 터널이 아니라 서명 검증된 명령만 통과하는 채널입니다. 병원의 어떤 포트도 노출되지 않고, 중계서버가 침해되어도 명령 위조·데이터 열람이 암호학적으로 불가능합니다."
구조적으로 불가능하게 설계했습니다. 응답은 병원 Agent가 수신자 공개키로 봉인(E2E 암호화)한 뒤 서버를 통과하므로 서버는 암호문만 봅니다. 명령은 HSM 서명이 있어야 Agent가 실행하므로 서버가 위조할 수 없습니다. 서버가 완전히 장악돼도 공격자는 ① 데이터를 읽을 수 없고 ② 가짜 명령을 만들 수 없고 ③ DB에 접속할 경로 자체가 없습니다.
아니요. 중계서버는 암호문을 통과시킬 뿐이며, 평문 환자 데이터를 읽을 수도 저장할 수도 없습니다. 대용량(영상 등) 릴레이도 봉인된 암호문 상태로만 일시 보관 후 전달·삭제됩니다. 서버에 남는 것은 감사 로그의 메타데이터뿐입니다(명령ID·병원ID·결과코드·시각 — 환자 정보 없음).
이중 암호화입니다. ① 전송 구간: TLS 1.3 (+ 병원 Agent는 mTLS 클라이언트 인증서로 신원 증명) ② 데이터 자체: HPKE(X25519 + AES-256-GCM)로 종단간 봉인. TLS는 서버에 도착하면 벗겨지지만, 봉인은 최종 수신 앱까지 유지되므로 서버 내부에서도 데이터는 여전히 암호문입니다.
모든 명령은 서명 서버(Ed25519, HSM 보관)가 서명하고, 병원 Agent가 병원 안에서 독립적으로 검증합니다 — 서명키는 게이트웨이에 없으므로 게이트웨이 침해로도 위조가 불가능합니다. 각 명령에는 nonce(1회용 번호)와 만료시각이 들어 있어, 가로챈 명령을 다시 보내는 리플레이도 Agent가 거부합니다.
토큰만으로는 데이터를 열 수 없습니다 — 응답이 수신자 공개키로 봉인되므로, 복호화에는 별도의 수신자 개인키가 필요합니다. 토큰의 권한도 발급 시 지정한 병원·커넥터·수신자 범위로 제한되며 만료를 걸 수 있고, 즉시 폐기할 수 있습니다. 유출 시 피해는 "허용된 명령을 호출해 볼 수 있다"까지이고, 범위 밖 시도는 403으로 거부되면서 감사 로그와 권한 위반 알림으로 드러납니다.
정직하게 말하면 이 경우는 그 병원 범위 안의 위험이 존재합니다 — 공격자가 그 PC를 장악하면 Agent의 DB 계정으로 허용된 조회를 할 수 있게 됩니다. 그래서 피해 범위를 제한하는 장치를 겹겹이 둡니다: ① DB 계정은 조회 전용(변조·삭제 불가) ② 정책 파일로 조회 범위 제한 ③ 모든 활동이 감사 로그·알림에 기록 ④ 병원별 키·인증서가 분리되어 다른 병원이나 중앙 플랫폼으로 확산 불가. PC 자체의 보안(백신·OS 패치·물리 접근 통제)은 병원의 기본 수칙으로 유지되어야 합니다 — 이는 기존 병원 업무 PC와 동일한 요구사항입니다.
네. 모든 명령 제출·실행·오류·Agent 연결/끊김이 해시체인 감사 로그로 기록됩니다 — 각 기록이 이전 기록의 해시를 물고 있어 중간 수정·삭제가 체인 검증에서 즉시 탐지됩니다. 기록은 개인정보 없는 메타데이터(행위자·명령·병원·결과·시각)로만 구성됩니다.
※ 설치·운영·개발 관련 상세 FAQ는 관리자 콘솔(로그인 필요)에서 제공됩니다.
현재 사용 중인 시스템과 필요한 연동 방식을 알려주시면, 기존 환경을 최대한 유지하는 방안을 검토합니다.