이 글은 웹셀러(디.패밀리)가 한 의료기관 고객사를 위해 만든 의사용 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가 진단을 내리거나 처방을 결정하지 않으며, 진료 정보를 빠르게 구조화하고 참고할 추천을 정리해줄 뿐이다. 최종 판단은 의사가 한다.