이 글은 웹셀러(디.패밀리)가 한 의료기관 고객사를 위해 만든 의사용 AI OCR 화면캡처 데스크톱 앱 제작 사례입니다. 의사가 진료 화면의 특정 영역을 마우스로 잡으면, AI OCR이 그 안의 진료 정보를 읽어내고, 환자 개인정보를 가린 뒤, 진료에 참고할 추천을 정리해 보여주는 윈도우 설치형 도구입니다. 의료 AI 프로그램 제작을 고민하는 병원·의원 의사결정자에게 어떤 기술 판단이 필요한지, 실제로 만들며 부딪힌 지점을 정리했습니다. 시점은 2026년 5월 기준입니다.

이 앱은 무엇을 하는 도구인가

먼저 정체성을 분명히 해두는 게 좋겠습니다. 이건 흔히 말하는 사무용 자동화 툴이 아닙니다. 의사가 진료 현장에서 직접 쓰는 의료 버티컬 데스크톱 앱입니다. 핵심 시나리오는 한 줄로 요약됩니다. 의사가 진료 화면을 캡처하면, AI OCR이 진료 정보를 읽고, 환자 개인정보를 가린 뒤, 진료에 참고할 추천을 정리해 보여줍니다.

여기서 AI OCR은 화면 속 글자를 인식해 구조화된 데이터로 바꾸는 기능을 말합니다. 전통적인 OCR 엔진이 글자 모양을 패턴 매칭하던 방식과 달리, 이 앱은 멀티모달 비전 모델로 화면 이미지를 읽습니다. 진료 화면에는 한국어와 영어, 질병코드, 처방 정보가 뒤섞여 있는데, 비전 모델은 이런 혼합 텍스트의 맥락까지 함께 읽어내기 때문에 표 형태나 줄바꿈이 불규칙한 화면에서도 인식 품질이 더 안정적인 편입니다. 여기에 질병코드 형식 검증, 한글 명칭 대조 같은 후처리를 얹어 오인식을 줄였습니다.

한 가지 분명히 짚을 게 있습니다. 이 도구는 의사의 판단을 돕는 보조 도구입니다. AI가 진단을 내리거나 처방을 결정하지 않습니다. 화면 속 진료 정보를 빠르게 구조화하고, 그 정보에 맞는 참고 항목을 정리해줄 뿐이고, 최종 판단은 언제나 의사 몫입니다.

왜 웹앱이 아니라 네이티브 데스크톱으로 만들었나

의료 AI 프로그램 제작에서 가장 먼저 갈리는 분기점이 이겁니다. 결론부터 말하면 브라우저로는 풀 수 없는 요구가 있었습니다.

핵심은 "다른 진료 프로그램의 화면을 그대로 읽어와야 한다"는 점입니다. 의사가 보고 있는 화면은 이 앱이 아니라 별도의 진료 프로그램입니다. 브라우저 탭은 자기 탭 밖의 OS 화면을 캡처할 수 없습니다. 외부 화면 영역을 잡으려면 OS와 통합된 네이티브 앱이어야 합니다. 진료실 PC라는 환경 특성상 오프라인에서도 멈추지 않고 돌아가야 한다는 요구도 있었습니다. 그래서 설치형 데스크톱을 택했습니다.

스택은 Python + PyQt6로 잡았습니다. 데스크톱 GUI를 빠르게 다듬으면서 화면 캡처·이미지 처리·네트워크를 한 언어로 묶기에 합리적인 선택이었습니다. 웹 기반 로그인 화면을 앱 안에 띄우기 위해 PyQt6-WebEngine(QtWebEngine)을 함께 썼습니다. 화면 영역 캡처는 mss, 이미지 처리는 Pillow로 처리했고, 캡처할 때 자기 앱 창이 같이 찍히지 않도록 윈도우 캡처 제외 API를 적용해 화면을 깔끔하게 잡았습니다.

환자 개인정보는 어떻게 지키나 — 마스킹 이중 가드

의료 데이터를 다루는 이상 이 부분이 설계의 중심이었습니다. 원칙은 하나로 정리됩니다. 환자 개인정보는 외부 AI 모델에 원문 그대로 보내지 않습니다.

흐름은 이렇게 짰습니다. OCR로 진료 텍스트를 뽑은 직후, 정규식으로 환자 식별정보(이름·주민번호·전화번호·차트번호 같은 것)를 1차 마스킹합니다. 그다음 사용자(의사 또는 직원)가 마스킹 결과를 직접 검수하는 화면을 거칩니다. 자동 처리만 믿지 않고 사람이 한 번 눈으로 확인하는 단계를 끼워 넣은 것입니다. 마지막으로 AI에 전송하기 직전에 한 번 더 마스킹을 겁니다. 1차 자동, 2차 사람 검수, 3차 전송 직전 재마스킹으로 이어지는 이중 가드 구조입니다.

이 설계가 중요한 이유는, 진료 정보 추천을 받으려면 외부 LLM에 텍스트를 보내야 하는데 그 텍스트에 환자 개인정보가 섞여 있을 위험이 늘 따라붙기 때문입니다. 식별정보를 가린 데이터만 모델에 보내도록 동선 자체를 막아두면, 추천 기능을 살리면서도 개인정보 노출 위험을 낮추기 좋은 구조가 됩니다. 의료기관 맞춤 솔루션에서 신뢰 자산은 결국 여기서 나온다고 봅니다.

AI 백엔드는 왜 둘을 붙였나

AI 호출은 LangChain 위에 서로 다른 사업자의 경량 모델 두 개를 연결했습니다. 한쪽이 실패하면 다른 쪽으로 넘어가는 이중 백엔드(폴백) 구조입니다. 진료 현장에서 쓰는 도구라 한 사업자의 일시적 장애나 응답 지연이 곧 업무 중단으로 이어지면 곤란합니다. 백엔드를 둘로 두면 한쪽이 흔들려도 흐름이 끊기지 않을 가능성이 높아집니다.

오프라인 대응도 함께 설계했습니다. SQLite 로컬 캐시에 더해 오프라인 큐를 뒀습니다. 네트워크가 끊기면 요청을 로컬에 쌓아두고, 연결이 복구되면 재전송합니다. 질병코드 명칭 같은 기준 데이터는 서버에서 동기화해 최신 상태를 유지합니다. 네트워크가 불안정한 순간에도 의사의 작업 자체는 멈추지 않게 하려는 의도였습니다.

인증은 임베디드 브라우저로 로그인 페이지를 띄우고, 성공하면 로컬호스트로 토큰을 콜백받는 OAuth Authorization Code 유사 흐름으로 처리했습니다. 데스크톱 앱에 자격증명을 직접 들고 있지 않고 표준 인증 흐름에 얹는 방식입니다. 백엔드 포털과의 통신은 httpx로 처리했습니다.

윈도우 배포에서 부딪힌 실무 포인트

이런 병원 데스크톱 프로그램은 실제 진료실 PC에 깔려야 의미가 있습니다. 그래서 배포 단계의 삽질이 적지 않았습니다. 직접 겪은 몇 가지를 남겨둡니다.

• QtWebEngine 초기화 순서 — QApplication을 만들기 전에 OpenGL 컨텍스트 공유 속성(AA_ShareOpenGLContexts)을 켜두지 않으면 웹뷰 생성 시 조용히 죽거나 검은 화면이 떴습니다. PyQt 공식 문서에서 짚는 전형적인 함정이라 순서를 고정해 해결했습니다.
• 작업표시줄 그룹화 — 윈도우 작업표시줄에서 아이콘이 제대로 묶이도록 AppUserModelID를 명시했습니다.
• PyInstaller hidden import — PyInstaller가 LangChain과 WebEngine의 지연 임포트를 자동으로 못 잡았습니다. 그래서 collect_submodules로 필요한 서브모듈을 직접 수집해 누락을 막았습니다.
• 캡처 제외 — 화면을 캡처할 때 앱 자기 창이 함께 찍히지 않도록 윈도우 캡처 제외 API를 적용했습니다.

최종 배포는 PyInstaller(onedir 방식 .exe)로 묶고 Inno Setup으로 한국어 인스톨러를 만들었습니다. 의료기관 직원이 IT 전문가가 아니어도 설치 마법사 몇 번으로 끝나게 하는 게 목표였습니다.

의료 AI 프로그램 제작에서 우리가 본 것

이번 사례를 한 문장으로 정리하면, 의료 버티컬의 데스크톱 앱은 "AI OCR 화면 인식"이라는 심장과 "환자 개인정보 마스킹"이라는 방패가 동시에 단단해야 한다는 것입니다. 둘 중 하나만 잘해서는 진료 현장에 들어가기 어렵습니다. 웹셀러는 PyQt6 기반 네이티브 앱 설계부터 비전 모델 OCR, 개인정보 보호 동선, 윈도우 배포까지 의료기관 맞춤 솔루션을 한 흐름으로 만들었습니다.

병원·의원 현장에 맞는 데스크톱 프로그램이나 진료 보조 도구를 검토 중이라면 맞춤형 솔루션·플랫폼 제작과 어플리케이션 제작 페이지가 출발점이 될 수 있습니다. 요구가 어느 정도 윤곽이 잡혀 있다면 무료 상담으로 현장 조건부터 같이 정리해보길 권합니다. 대략의 규모감도 같은 상담에서 안내드립니다.

자주 묻는 질문

의사가 진료 중에 이 앱을 어떻게 쓰나

의사가 진료 화면에서 필요한 영역을 마우스로 드래그해 캡처하면 됩니다. 그러면 AI OCR이 그 영역의 진료 정보를 읽어 텍스트로 구조화하고, 환자 개인정보를 가린 뒤 진료에 참고할 추천 항목을 정리해 보여줍니다. 별도 입력 작업 없이 화면을 잡는 동작 하나로 흐름이 시작되도록 설계했습니다.

환자 개인정보는 안전하게 처리되나

외부 AI 모델에 환자 식별정보 원문을 그대로 보내지 않는 것을 설계 원칙으로 삼았습니다. OCR 직후 정규식으로 이름·주민번호·전화번호·차트번호 같은 정보를 자동 마스킹하고, 사용자가 그 결과를 검수한 다음, AI 전송 직전 한 번 더 마스킹하는 이중 가드를 뒀습니다. 자동 처리와 사람 검수를 함께 거치게 해 개인정보 노출 위험을 낮추기 좋은 구조로 만들었습니다.

왜 웹이 아니라 설치형 프로그램인가

의사가 쓰는 별도의 진료 프로그램 화면을 그대로 읽어와야 하기 때문입니다. 브라우저 탭은 자기 탭 밖의 OS 화면을 캡처할 수 없어서 외부 화면 인식이 불가능합니다. 진료실 PC의 OS 통합과 오프라인 동작이 필요하다는 점도 네이티브 데스크톱을 택한 이유입니다.

기존 진료 프로그램과 직접 연동되나

이 앱은 별도 시스템 연동 없이도 화면 캡처와 AI OCR만으로 동작하도록 설계됐습니다. 기존 진료 프로그램의 화면을 그대로 읽어 정보를 구조화하는 방식이라, 내부 시스템에 손을 대지 않고도 도입할 수 있는 여지가 큽니다. 다만 고객사 환경과 요구에 따라 후속 처리 연계 범위는 달라질 수 있습니다.

이 앱이 진단이나 처방을 대신하나

아닙니다. 이 도구는 의사의 판단을 돕는 참고 정보 정리 도구입니다. AI가 진단을 내리거나 처방을 결정하지 않으며, 진료 정보를 빠르게 구조화하고 참고할 추천을 정리해줄 뿐입니다. 최종 판단은 의사가 합니다.