1. 플러스벳과 EMR
플러스벳은 동물병원에서 사용하는 Cloud EMR(전자 의무 기록)입니다. Cloud EMR이라고 하면 의료계에 계시는 분들은 대부분 뭔지 알지만 다른 분들은 잘 모르실텐데요. 종이 차트를 대신해 환자의 진료 기록, 예약, 접수, 수납, 검사, 처방 같은 병원 업무를 디지털로 관리하는 프로그램입니다. 그리고 저는 현재 벳칭이라는 회사에서 플러스벳이라는 동물병원용 EMR을 기획, 설계하고 있습니다.
병원 내 대부분의 업무가 [전자 의무 기록]이라는 하나의 프로그램 안에서 이루어집니다.
최근 플러스벳에 쓰레드라는 이름의 기능이 출시되었습니다. (메타의 Threads와 이름만 같고 전혀 다른 기능입니다.) 한 환자에 대한 기록을 하나의 대화창 안에서 확인하고 이어서 작성할 수 있도록 만든 기능입니다. 이 글에서는 쓰레드를 왜 만들게 되었는지, 어떤 문제를 해결하려고 했는지 이야기해보려 합니다.
2. 왜 환자 히스토리를 한눈에 보기 어려웠을까
플러스벳을 만들어오면서 반복적으로 들었던 요청 중 하나는 환자 히스토리를 더 쉽게 파악하고 싶다는 것이었습니다. 예약은 언제 잡혔고 언제 수정되었는지, 진료는 언제 이루어졌는지, 어떤 검사와 처치가 이어졌는지, 보호자에게는 언제 문자가 발송되었는지를 더 쉽게 보고 싶다는 요구였습니다.
EMR의 기능 배치 예시(플러스벳 기준) 다른 서비스들도 구성만 다를 뿐 대부분 비슷한 기능을 제공합니다.
이 요구는 EMR의 구조적인 특징에서 비롯된 불편에 가까웠습니다. EMR에는 예약, 접수, 진료, 검사, 수납, 문자 발송 등 병원 운영에 필요한 여러 정보가 계속 쌓입니다. 다만 이 정보들은 각 기능 화면에 나뉘어 기록되고 관리됩니다. 정보가 없는 것은 아니었습니다. 데이터는 각 공간에서 아주 많이 쌓이고 있었습니다. 다만 그것들이 한 환자의 시간 안에서 자연스럽게 이어져 보이지 않았습니다.
진료는 현재의 상태만 다루는 일이 아닙니다. 지금 눈앞의 상태를 판단하면서도, 바로 직전에 어떤 일이 있었는지, 이전 방문에서는 어떤 우려가 있었는지, 보호자와는 어디까지 이야기가 오갔는지를 함께 봐야 할 때가 많습니다. 그래서 의료진이 확인하고 싶은 것은 개별 데이터 하나하나보다, 그 데이터가 어떤 흐름 안에 놓여 있는지에 더 가깝습니다.
하지만 정보가 기능별로 나뉘어 있으면 그 흐름이 화면에서 바로 드러나지 않습니다. 예약은 예약 화면에, 진료 기록은 차트에, 메시지 발송 이력은 또 다른 기능 안에 남게 됩니다. 결국 사용자는 이 화면에서 보고, 저 화면으로 이동하고, 다시 다른 기능으로 넘어가며 환자에 대한 맥락을 스스로 조합해야 합니다.
3. EMR은 왜 업무 중심으로 설계될까
전자차트가 환자 중심으로 설계되지 않은 데에는 이유가 있습니다. 병원은 한 사람이 모든 일을 처음부터 끝까지 처리하는 공간이 아니라, 여러 사람이 각자의 위치에서 각자의 일을 맡아 움직이는 곳이기 때문입니다. 예약을 관리하는 사람, 접수를 보는 사람, 진료를 하는 수의사, 검사를 맡는 인력, 조제를 담당하는 인력이 서로 다른 화면과 기능을 중심으로 일하게 됩니다.
동물병원 구성원 별 주요 사용 기능
대부분의 의료 차트 시스템은 병원 안의 여러 업무가 각자의 자리를 가질 수 있도록 설계됩니다. 예약은 예약 화면에서, 환자 정보와 수납은 접수 화면에서, 진료 기록은 진료 화면에서, 검사와 조제는 또 각자의 기능 안에서 다루는 식입니다. 이런 구조는 각 사용자가 업무를 처리하는 데에는 분명 효율적입니다. 필요한 기능을 더 깊게 넣고, 각 화면을 해당 업무에 맞게 최적화할 수 있기 때문입니다.
문제는 이 구조가 잘못되었다는데 있지 않습니다. 오히려 병원의 현실을 충실하게 반영한 결과에 가깝습니다. 다만 이렇게 설계된 시스템에서는 한 환자의 흐름을 한눈에 따라가는 관점이 뒤로 밀려납니다. 업무 단위로는 잘 정리되어 있지만, 환자 단위로는 따로 다시 읽어야 하는 구조가 되기 때문입니다.
쓰레드는 바로 그 빈틈을 보완하기 위해 나온 기능이었습니다. 기존의 업무 화면을 없애거나 뒤집는 것이 아니라, 그 사이에서 상대적으로 약했던 환자 중심의 관점을 하나 더 세워보려는 시도였습니다.
4. 쓰레드는 어떤 기능인가
기존 차트 시스템과 쓰레드 비교
초기에 먼저 고민했던 방식은 환자에게 일어난 주요 이력과 알림을 시간순으로 쌓아 보여주는 타임라인형 구조였습니다. 예약 변경, 차트 생성, 검사 오더, 백신 접종 같은 이벤트를 하나의 흐름 안에서 볼 수 있게 하면, 기존 EMR보다 환자 히스토리를 훨씬 쉽게 파악할 수 있을 것이라고 생각했습니다.
이 방향은 분명 의미가 있었습니다. 흩어진 기록을 한곳에 모아 보여준다는 점만으로도 사용자는 환자에게 어떤 일이 있었는지를 더 빠르게 따라갈 수 있었기 때문입니다. 하지만 고민을 이어갈수록, 단순 알림과 이력을 시간순으로 쌓아 보여주는 것만으로는 부족하다는 생각이 들었습니다. 진료는 과거를 확인하는 데서 끝나지 않고, 그 다음 기록과 판단, 오더와 후속 조치로 바로 이어지기 때문입니다.
동물병원 방문 여정 흐름을 하나의 창에서 모두 확인 가능
그래서 쓰레드는 타임라인을 출발점으로 삼되, 기록을 읽는 일과 다음 행동이 한 흐름 안에서 이어지는 구조로 발전하게 되었습니다. 예약, 접수, 문진, 진료 기록, 검사 오더, 수납 대기, 메시지 발송 같은 정보가 환자 기준으로 시간순으로 쌓이고, 사용자는 그 흐름 안에서 과거 이력을 확인하는 동시에 필요한 기록도 이어서 작성할 수 있도록 하고 싶었습니다.
이 과정에서 쓰레드는 메신저의 형태를 베이스로 설계하게 되었습니다. 시간순으로 정보가 쌓인다고 했을 때, 일반적인 사용자들이 가장 익숙하게 읽는 UI가 바로 메신저라고 생각했기 때문입니다. 우리는 이미 일상적으로 메신저 안에서 대화가 어떻게 쌓이고, 어떤 메시지가 먼저 있었고, 그다음에 어떤 응답이 이어졌는지를 자연스럽게 읽고 있습니다. 환자에게 일어난 기록 역시 하나의 시간 흐름 안에서 읽혀야 한다면, 메신저와 비슷한 구조가 가장 직관적인 출발점이 될 수 있다고 봤습니다.
물론 쓰레드는 단순히 메신저처럼 보이게 만드는 것이 목표는 아니었습니다. 실제로는 대화 메시지뿐 아니라 예약 전환, 문진 생성, 차트 작성, 검사 오더, 수납 대기 같은 다양한 이벤트가 함께 쌓입니다. 그래서 메신저의 형식을 빌리되, 의료 기록과 업무 이벤트를 함께 담을 수 있는 구조로 바꾸는 작업이 필요했습니다. 쓰레드는 단순히 환자 히스토리를 보여주는 화면이 아니라, 진료 흐름을 따라가며 기록과 행동이 이어지는 작업 공간에 더 가깝습니다.
부서별 쓰레드 사용 예시
또 하나 중요하게 본 것은 알림의 방식이었습니다. 병원은 여러 부서가 함께 움직이는 공간이기 때문에, 모든 사람이 같은 알림을 똑같이 받아보는 방식은 오히려 비효율적일 수 있습니다. 그래서 쓰레드에서는 각 부서가 본인들의 업무에 맞는 알림만 받아볼 수 있도록 설정할 수 있게 했습니다. 예를 들어 원무 데스크, 검사실, 약국, 입원실처럼 각자의 역할에 따라 필요한 흐름만 골라서 확인할 수 있도록 한 것입니다.
쓰레드 핀 기능 예시
여기에 핀 기능도 함께 넣었습니다. 특정 동물을 핀으로 고정하면, 그 환자와 관련된 알림을 계속 받아보면서 집중적으로 관리할 수 있습니다. 입원 중이거나 경과 관찰이 중요하거나, 여러 부서가 함께 신경 써야 하는 환자라면 이런 방식이 특히 유용합니다. 결국 쓰레드는 환자별 기록을 모아 보여주는 기능인 동시에, 병원의 여러 구성원이 환자의 흐름을 중심으로 일할 수 있도록 만드는 기능이기도 합니다.
5. 쓰레드 이후의 확장
쓰레드를 중요하게 본 이유는 지금 더 편하게 보기 위한 기능에 그치지 않기 때문입니다. 환자별 기록이 시간순으로 정리되고, 어떤 행동이 어떤 맥락에서 이루어졌는지가 구조적으로 쌓이기 시작하면, 그다음부터는 AI가 개입할 수 있는 자리도 조금씩 생깁니다.
예를 들어 환자별 진료 과정을 일정한 구조로 읽을 수 있게 되면, 다음에 이어질 가능성이 높은 프로세스를 제안하거나, 자주 누락되는 기록과 처치를 찾아주거나, 현재까지의 흐름을 바탕으로 필요한 다음 액션을 안내하는 것도 가능해집니다. 중요한 것은 단순한 자동화가 아닙니다. 더 중요한 것은 진료 과정을 조금 더 구조적으로 이해하고, 그 안에서 누락과 편차를 줄이며, 시스템이 의료진의 판단을 더 잘 보조할 수 있게 만드는 것입니다. AI가 대신 생각하는 것이 아니라, 사람이 놓치기 쉬운 연결을 더 잘 드러내고 다음 흐름을 더 안정적으로 이어갈 수 있도록 돕는 쪽에 가깝습니다.
쓰레드 AI 활용 예시
그런 점에서 쓰레드는 현재의 화면 개선이면서 동시에 이후의 구조를 준비하는 기능이기도 합니다. 지금은 환자의 기록을 더 잘 보고 더 자연스럽게 이어서 쓰기 위한 기능이지만, 앞으로는 환자 중심의 의료 AI가 자랄 수 있는 기반이 될 수도 있다고 보고 있습니다.
쓰레드는 환자 히스토리를 한눈에 보고 싶다는 요청에서 시작됐습니다. 하지만 그 요청을 따라가다 보니 결국 보이게 된 것은, 의료의 기록이라는 것이 단순히 저장의 문제가 아니라 흐름의 문제이기도 하다는 점이었습니다. 저는 쓰레드를 만들면서 시스템이 해야 할 일은 정보를 많이 담는 것만이 아니라, 한 환자에게 일어난 시간을 더 잘 드러내는 일일 수도 있다고 생각하게 되었습니다. 흩어진 데이터를 한곳에 모으는 것에서 그치지 않고, 그 흐름 안에서 기록과 행동이 함께 이어지도록 만드는 것. 쓰레드는 그 방향을 향해 만든 하나의 시도였습니다.
이 글은 [❶작성자가 초안 작성 → ❷AI가 내용 보완 및 다듬기 → ❸작성자가 첨삭 후 마무리] 순서로 작성되었습니다.