기능이 먼저 같지만, 실제로는 상태가 먼저입니다
의료 AI 프로젝트를 시작할 때 가장 자주 나오는 요청은 대개 비슷합니다. 자동으로 초안을 써달라, 추천을 해달라, 누락을 잡아달라, 승인 흐름을 줄여달라 같은 이야기입니다. 겉으로 보면 모두 기능 요청처럼 보입니다. 그래서 프로젝트 초반에는 화면 목록과 기능 목록부터 빠르게 적기 쉽습니다. 하지만 실제로 병원 현장에 들어가 보면 기능보다 먼저 정리되지 않으면 안 되는 것이 있습니다. 바로 운영 상태입니다.
누가 초안을 만들 수 있는지, 누가 검토하는지, 어디까지가 임시 상태이고 어디서부터 법적 기록인지, 수정 이력은 어떻게 남는지, 외부 시스템으로 전송됐을 때 어떤 응답을 성공으로 볼 것인지가 먼저 정리되어야 합니다. 이 기준이 없는 상태에서 기능을 먼저 붙이면, 데모는 되지만 운영은 불안정해집니다. 의료 AI는 답변을 만드는 기술이기도 하지만, 그 답변이 어떤 상태를 거쳐 확정되는지를 다루는 시스템이기도 합니다.
초안이 만들어졌다는 것과 기록이 확정됐다는 것은 다릅니다
의료 현장에서는 같은 문서라도 상태가 다르면 의미가 완전히 달라집니다. 초안은 초안이고, 검토 완료는 검토 완료이며, 승인된 기록은 또 다릅니다. 여기에 서명이나 외부 EMR 반영까지 붙으면 그 문서는 단순 텍스트가 아니라 운영 행위의 결과가 됩니다. 그런데 많은 프로젝트가 이 차이를 너무 늦게 다룹니다.
예를 들어 AI가 문장을 잘 생성하는 것만 확인하고 나면, 그 다음 단계는 자연스럽게 이어질 것처럼 생각하기 쉽습니다. 하지만 실제로는 검토자가 누구인지, 반려되면 어디로 돌아가는지, 승인 후 수정은 addendum으로 볼지 재작성으로 볼지, 전송 후 ACK를 받지 못했을 때 어떤 상태로 남길지가 모두 달라집니다. 이 상태 정의가 먼저 없으면, 뒤에 붙는 모든 기능은 결국 예외 처리와 책임 소재 문제로 다시 흔들립니다.
병원 프로젝트에서 운영 상태는 결국 책임의 언어입니다
운영 상태를 먼저 정리해야 하는 이유는 단지 개발 편의를 위해서가 아닙니다. 병원 프로젝트에서는 상태 정의가 곧 책임 분리이기 때문입니다. 누가 작성했고, 누가 검토했고, 누가 승인했고, 어느 시점에 외부 시스템에 전송했는지가 분명해야 나중에 문제가 생겼을 때 다시 따라갈 수 있습니다. 의료 AI에서 감사 이력과 상태 전이가 중요한 이유도 여기에 있습니다.
특히 AI가 개입하는 순간에는 더 그렇습니다. 사람이 처음부터 끝까지 직접 작성한 문서와, AI 초안을 기반으로 사람이 보완한 문서는 운영상 다르게 봐야 할 때가 많습니다. 무엇을 근거로 생성했는지, 어떤 필드를 바탕으로 추천했는지, 어떤 사용자 행위 이후에 최종 문서가 확정됐는지가 남아 있어야 합니다. 이것이 없으면 AI는 빠른 도구가 아니라 불명확한 위험 요인이 됩니다.
저장, 검색, 복원은 편의 기능이 아니라 운영 기능입니다
프로젝트 중간쯤 가면 팀은 종종 이런 질문을 받습니다. 최근 작업 이력을 다시 보고 싶다, 자주 보는 필터를 저장하고 싶다, 특정 케이스를 나중에 다시 열고 싶다, 이전 상태와 충돌 나면 어떻게 되는지 보고 싶다 같은 요청들입니다. 겉으로 보면 UI 편의 기능처럼 들리지만, 실제로는 운영 상태를 다루는 기능입니다.
병원 업무는 항상 한 번에 끝나지 않습니다. 같은 환자, 같은 문서, 같은 부서 기준이 시간 차를 두고 다시 이어지는 경우가 많습니다. 그래서 저장된 보기나 히스토리 복원 같은 기능은 보기 좋게 만드는 장식이 아니라, 업무 맥락을 이어붙이는 도구에 가깝습니다. 의료 AI 프로젝트에서 이런 기능이 늦게 붙을수록 현장은 시스템을 믿기보다 다시 수기 기록이나 메신저 메모에 의존하게 됩니다.
외부 연동은 성공 여부보다 상태 해석이 더 중요합니다
EMR이나 병원 내부 시스템과 연결되는 순간, 프로젝트는 또 다른 단계를 맞습니다. 많은 팀이 전송 성공과 실패만 구분하면 된다고 생각하지만 실제 운영에서는 그 사이가 더 중요합니다. queued인지 accepted인지, rejected인지, 외부 문서 번호가 생성됐는지, 승인 시각이 돌아왔는지 같은 응답 해석이 필요합니다. 연동의 핵심은 단순 전송이 아니라 결과 상태를 다시 내부 운영 상태로 번역하는 일입니다.
그래서 의료 AI 프로젝트에서는 기능 구현보다 응답 상태 정규화가 더 중요해질 때가 많습니다. ACK 하나를 어떤 상태로 볼지, 재시도를 언제 허용할지, 실패 기록을 사용자에게 어디까지 보여줄지 정해두지 않으면 시스템은 연결되어 있어도 운영은 연결되지 않습니다. 기술적으로 붙었다는 사실보다, 운영적으로 해석 가능하다는 사실이 더 중요합니다.
메디움스가 먼저 보는 것은 기능 목록이 아니라 상태 지도입니다
메디움스가 의료 AI 프로젝트를 볼 때 먼저 확인하는 것은 어떤 모델을 쓸지보다 상태 지도가 있는지입니다. 초안, 검토, 승인, 서명, 전송, 반영 완료, 재수정, addendum 같은 단계가 어떻게 이어지는지, 각 단계에서 누가 책임을 가지는지, 기록은 어디에 남는지를 먼저 봅니다. 이 구조가 있어야 그 다음에야 기능 우선순위도 올바르게 정할 수 있습니다.
이 접근은 처음에는 조금 느려 보일 수 있습니다. 하지만 실제 프로젝트 후반으로 갈수록 차이가 분명해집니다. 상태가 먼저 정리된 프로젝트는 기능을 추가해도 흔들림이 적고, 예외 상황이 와도 어디서 멈췄는지 확인하기 쉽습니다. 반대로 기능부터 급하게 붙인 프로젝트는 시연은 빨라도 운영 전환 단계에서 훨씬 큰 비용을 치르게 됩니다.
결론
의료 AI 프로젝트는 기능을 얼마나 많이 붙였는지가 아니라, 그 기능이 어떤 운영 상태 위에서 움직이는지가 더 중요합니다. 초안과 승인, 서명과 전송, ACK와 감사 이력, 저장된 보기와 복원 흐름이 먼저 정리되어야 기능도 안정적으로 쌓입니다. 결국 의료 AI는 문장을 잘 만드는 시스템이 아니라, 의료 기록이 안전하게 상태를 바꾸며 이동하도록 만드는 시스템에 더 가깝습니다.
메디움스는 의료 Vertical AI와 의료IT 프로젝트를 설계할 때 이 점을 먼저 봅니다. 좋은 기능은 중요하지만, 더 중요한 것은 그 기능이 운영 가능한 상태 구조 안에 들어가 있는지입니다. 프로젝트가 길어질수록 기능 목록보다 상태 지도가 더 큰 차이를 만듭니다.