by
Apr 14. 2024
이젠 병원에 UX개발 프로세스가 필요하다.
병원이라는 거대한 R&D센터
✅ 병원은 거대한 R&D 센터
병원은 우리가 평소에 보기 어려운 의료기기, 용어, 경험, 사람들로 가득찬 어찌보면 이색적인 공간으로 느껴진다. 특히 병원에서 사용하는 수많은 기기와 시스템을 보면 UX디자이너로서 많은 궁금증들이 생긴다.
키오스크, 카카오 알림톡, 외래대기 현황판, 전자설문 등등 수많은 IT 솔루션들을 보면 병원은 개발조직이 아닌데 어떻게 자체적으로 이 많은 솔루션들을 개발했을까? 과연 이런 프로젝트들은 누가 담당하고 있는걸까?'라는 점이었다. 다른 IT대기업에서는 앱 하나 서비스 하나를 만들고 유지하기 위해 수십명의 기획자, 디자이너, 개발자가 필요한데,이런 솔루션 개발을 위해 얼마나 많은 사람이 병원에서 근무하고 있는지, 그리고 그 사람들은 어디에 소속되어 어떻게 일을 하고 있는지도 궁금했다.
병원마다 공통적으로 의료정보실이라는 곳이 있다. 이곳은 보통 임상현장에서 새로운 IT시스템이 필요하거나, 사용하던 시스템이 고장나면 가장먼저 연락하게 되는 IT 부서이다. 처음에는 이 의료정보실이 IT 솔루션개발을 담당하고 있다고 생각했었다. 여느 기업의 IT개발 부서들과 마찬가지로 병원의 IT개발을 총괄하면서 수많은 개발자들이 밤새 코딩하는 곳이라고 생각했다. 물론 병원 전사적으로 사용할 전자의무기록(EMR) 시스템이나 사내메신저, 간호정보, 물류시스템처럼 전사적 시스템의 총괄 PM을 맡아서 추진하는곳이 맞기는 하지만 의료정보실은 직접 솔루션을 개발을 하기보다는 임상 현장에서 의뢰하는 IT 프로젝트의 PM(Project Manager) 역할과, 개발 외주용역을 통해 만들어진 결과물을 유지, 보수, 관리하는것이 주된 역할이라는 것을 뒤늦게 알게 되었다.
<이미지:Unsplash>그럼 예를들어 병동간호팀에서 신규 입원환자들에게 영상 교육자료를 전달할 채널이 필요하다거나, 낙상환자가 발생했을때 이를 자동으로 알려주는 시스템, 즉 기존에 없거나 특정 진료과에서만 활용되는 IT 솔루션을 완전히 새로 개발해야 한다면 이런 솔루션은 의료정보실이 아니라면 누구를 통해서 어떻게 개발해야 하는걸까? 물론 병원마다 사정은 다르겠지만, 일반적으로 의사는 개인이 직접 연구과제 형태로 관련업체를 직접 컨택해서 개발하는 경우도 있고, 간호사는 팀단위 또는 간호행정부서에서 임상현장의 니즈를 바탕으로 관련 솔루션을 구매하거나 관련 IT업체를 찾아서 용역을 주기도 하며. 원무팀 같은 행정부서에서 새로운 키오스크 개발이 필요하다면, 기존에 거래하던 키오스크 업체에 연락해서 요구사항을 얘기하고 원한다면 수요만 확보 된다면 맞춤형으로 새로운 용도의 키오스크를 주문 생산 하기도 한다.
이렇게 병원 곳곳에서는 의료업무 효율을 높이거나, 환자안전을 담보하기 위해 끊임없이 IT 술루션을 찾거나, 새롭게 개발하려는 수요가 지금도 이어지고 있다. 하지만 병원에는 이런 수요를 막상 받아줄 마땅한 IT전문인력이나 시스템이 부족한것이 현실이다. 또한 의료솔루션은 전문영역이라서 의료진이 직접 개발에 참여하지 않을수도 없다. 이런 이유들로 인해 결국 의사, 간호사들이 직접 아름아름 업체를 찾아서 구매하고, 개발하고 있는 상황이라고 할 수 있다.
그래서 현재 IT솔루션을 개발하려는 임상현장의 많은 의료진들이 직접 솔루션의 기능을 정의하고, 화면을 그려서 개발자에게 설명하고, 개발 과정에서 중간 결과물들을 보면서 피드백을 하고 있다. 즉, 병원의 UX디자이너 역할을 의료진들이 하고 있는것이다. 실제로 병동에서 일하던 간호사가 IT프로젝트에 착출되어서 여러 진료과, 관련부서들을 모아놓고 필요한 기능들을 협의하고, 이를 정리해서 개발자에게 전달하고, 개발 전 과정에서 PM역할을 하는 모습을 실제 목격하기도 했다.
✅ 병원이 IT솔루션을 직접 개발하는 이유
<이미지:Unsplash>그런데 여기에서 한가지 궁금한점이 생긴다. 왜 이걸 직접 개발할까? 기존 제품을 구매하면 훨씬 편할텐데 굳이 왜 직접 PM을 자처하면서 개발하는걸까? 본인이 병원에 와서 알게된 그 이유는 크게 세가지로 정리해볼 수 있을것 같다.
1. 구매처가 없어서
현장에서 당장 필요한데, 구매를 하고 싶어도 구할수 없는 경우가 많다. 열심히 리서치 해서 만약 구했다고 해도, 워낙 복잡한 병원규정 때문에 병원내에 설치하느니 신규개발이 차라리 쉬울 경우도 생긴다. 병원내 보안규정, 인프라 호환성 규정, 등등 병원별로 특성에 맞추기 쉽지 않다. 그래서 있는 솔루션을 찾느니 차라리 직접 개발을 택하는 경우가 많다.
2. 높은 비용
구매비용이 턱없이 비싸기 때문이다. 병원 솔루션은 병원내에서만 한정되어 사용되기 때문에 시장 자체가 매우 작다. 그래서 아무리 사소하고 작은 기능의 제품이라고 할지라도 어이없을 정도로 가격이 높아서 구매가 어려운 상황이 발생하기도 한다.
3. 개발 제약
있는 제품을 구매하면 여러가지 마음에 안드는 점이 많아서 현장에 맞게 수정하거나 추가하고 싶은 기능이 생기게 된다. 하지만 직접 만들게 되면 본인이 원하는 기능을 최대한 반영해서 원하는대로 만들 수 있으며, 고비용의 개발인력과 시스템 없이도 솔루션을 개발할 수 있다는 장점이 분명 존재한다. 또한 임상현장에서 바쁜 의료진이 개발에 크게 신경쓰지 않고 원하는것만 말하면 알아서 업체가 개발해서 보여주고, 중간중간 미팅해서 크리틱만 하면 되니 개발하기 편하다는 장점도 있다.
✅ 직접 개발의 장단점 (UX관점)
하지만 직접 개발하는것이 장점만 있는것은 아니다. 일단 새로 개발하는 제품은 아직 사용해보지 않은 베타버전이라고 할 수 있다. 그래서 처음부터 개발 안정성이 확보되기가 어렵다. 즉, 언제든 고장날 수 있다는 이야기다. 그래서 개발 퀄리티가 높지 않다. 시제품을 마치 상용제품처럼 쓰는 느낌이다.
또한 각자가 알아서 개발하다보니 마치 모두 다른 병원에서 개발한것처럼 UX가 일관성 없이 파편화 되는 현상이 생긴다는 문제도 발생한다. 뿐만 아니라 제품이든 서비스든 개발할때는 사용자를 중심으로 니즈를 파악해서 최적의 사용성으로 개발해야, 나중에 실컷 만들어놓고 솔루션의 사용성이 안좋아서 사용하기 어렵거나, 솔루션을 실제로 활용하는 사람이 제한적이거나, 유용성이 낮아서 사용빈도가 낮아지는 살례를 피할 수 있다. 하지만 병원에서 UX디자인 교육을 받은사람은 거의 없기때문에 솔루션들의 기본적인 사용성이나 고객가치가 고려되지 않은 상태로 개발될 확률, 즉 UX 퀄리티가 담보되지 않은 상태로 결과물이 나올 확률이 높을 수 있다는 단점이 생긴다. 이렇게 되면 결국 사용자에게 외면당한채 잊혀지는 솔루션이 될 확률이 높아질 것이다. 즉, 개발 과정에서 UX가 고려되지 않으면 다시 개발해야 하는 상황이 벌어질 수도 있다.
병원 주변을 한번 둘러보자. 많은 환자들이 사용하다가 실패해서 옆에 도우미가 항상 서 있어야하는 키오스크, 수많은 팝업창을 닫아야 처방할 수 있는 EMR, 무겁고 사용하기 번거로워서 책상위에 두고 다니는 의사용 태블릿, 제약이 많고 차별화된 기능이 없어서 결국 카카오톡과 병행해서 사용하게 되는 사내 메신저, 하루 외래만 1.5만명이지만 앱 다운로드 수를 10만명을 넘지 못하는 환자용 병원앱 등등 사용자 배려가 부족한 솔루션들로 인해 환자와 의료진이 고통받고 있는 상황은 병원내 여러곳에서 찾아볼 수 있다.
✅ 병원의 UX퀄리티 확보 방법
일반 IT기업들은 누가 더 빠르게 고객에게 필요하고, 기존에 없던 경쟁사와 차별화된 서비스/제품을 제공하는지를 두고 치열하게 경쟁한다. 그리고 그 서비스/제품이 고객에게 선택받지 못하면 빠르게 접고 다음 서비스를 개발한다. 이 산업에서의 경쟁 공식은 속도이다. 서비스를 개발하는 속도가 느리면 경쟁에서 생존하기가 어렵다. 하지만 병원의 IT환경은 완전히 다르다. 우선 병원은 독점산업이기 때문에 IT개발을 두고 치열하게 경쟁할 필요가 없다. 또한 속도가 느리다고 병원의 생존이 위협받지는 않는다.
위에서 언급한것 처럼 병원이 어쩔 수 없이 자체개발 해야 하는 상황이라면 개발 퀄리티를 확보할 수 있는 방법을 찾는것이 최선이라고 생각된다. 개발 자체의 완성도는 (논점에서 벗어나지 않기위해) 일단 논외로 하고, 우선 병원에서 일정수준의 UX 퀄리티를 확보할수 있는 방법을 이야기해보자.
1. 병원만의 Design System을 관리하기
토스의 디자인리소스 <이미지: 토스 Tossfeed> .병원 IT개발에서 가장 중요한건 안정성이다. 병원의 기존 인프라와 연계는 잘 되는지, 병원데이터 보안체계에는 잘 맞는지, 내구성 문제로 중간에 자주 고장나지는 않는지에 대한 개발 안정성은 이미 병원에서 완벽하게 관리하고 있다. 여기에서 이야기하고자 하는건 UX의 사용성 관점에서의 안정성을 말한다. 즉, 기본적인 UX의 퀄리티와 일관성에 대한 이야기다.
카카오는 카카오톡이든,뱅크든,택시든 카카오처럼 느껴진다. 그리고 쾌적한 사용성과 경험은 어느서비스를 이용하든지 동일하다. 이런 일관된 경험은 애플제품, 구글제품, 삼성제품에서도 동일하게 느낄수있다. 모든 제품이 일관되게 나이스하다.
이런 경험이 가능한 이유는 하나의 디자인 철학을 바탕으로 만들어진 일관된 디자인 언어와 디자인규칙, 디자인 시스템을 모든 디자이너가 공유하기 때문이다. 대표적인 예로 애플의 Human Interface Guideline, 구글의 Material Design, MS의 Fluent Design, 삼성의 One UI등을 들 수 있다. 반대로 이야기하면 일관된 디자인 퀄리티와 경험을 담보하기 위해서는 전사적인 디자인시스템 관리와 적용이 중요하다고 할 수 있다
구글 Material Design Asset <출처: 구글>임상현장에서 필요할때마다 외주업체를 불러서 각자의 방향에 따라 개발하게되면, 솔루션의 퀄리티 컨트롤이 안된다. UX에도 기본적으로 담보되어야 하는 퀄리티가 있다. 또한 고객 접점에 사용되는 솔루션은 병원의 브랜딩과도 연결 되어있기 때문에 디자인 뿐 아니라 사용경험을 일관되게 관리해야 한다. 그래서 병원만의 브랜딩 절학이 담긴 UX디자인 Asset과 Guideline 개발이 필요하다. 그리고 누구든 병원에서 무언가 새로운 솔루션을 개발하고자 한다면 반드시 해당 가이드라인을 활용해서 개발하도록 제도화 해야한다. 그래야 병원 UX의 파편화 현상을 막고 기본사용성의 일정 퀄리티를 유지할 수 있다. 여기에 병원의 신뢰도를 높일 수 있는 브랜딩 효과까지 얻을 수 있다.
2. 병원만의 UX개발 프로세스를 운영하기
구글의 Design Sprint <이미지 : Medium-Antoine Craske>각 기업에서는 각각의 도메인과 기업의 특성에 따라 조금씩 다르게 각자의 프로세스를 정의하고 운영하고 있다. 이 프로세스를 통해 누가 개발을 하든지 일정 수준의 퀄리티의 결과물을 만들어 낼수 있기 때문이다. 병원이 만약 다양한 사람이 직접 솔루션을 개발해야 하는 상황이라면, 병원도 병원만의 솔루션개발 프로세스를 가지고 있어야 한다. 그래야 개발한 솔루션의 퀄리티를 컨트롤할 수 있다. (아직 병원 내에서 신규 솔루션 개발 프로세스를 운영하고 있는 경우는 못들어본것 같다.)
그럼 병원에게 적합한 UX 개발프로세스는 무엇일까? 병원의 이용고객은 일반 제품과 서비스의 이용고객과 다르게 병원서비스에 대한 니즈가 시시각각 변하지 않는다. 즉, 빠르고 민첩하게 개발할 이유가 딱히 없을 수 있다는 이야기다. 그렇다면 병원에게 맞는 방법론은 무엇일까? 빠르게 개발할 필요가 없으니 수년에 걸쳐서 치밀하게 기획하고 완성도 있게 개발하는 Waterfall 방식이 정답일까?
Waterfall은 또다른 함정이 있다. 한번의 정교한 조준으로 성공을 해야 한다는점이다. 만약 그 정교한 조준이 고객의 니즈가 다르게 설정되었다면? 그동안의 수많은 노력을 통해 만든 제품은 고객에게 외면당하고 버려지게 된다. 이와 반면에 고객의 니즈에 대한 가설을 세우고 이를 시제품으로 빠르게 구현하여 테스트하면서 가설과 검증의 반복을 통해 고객의 니즈에 점진적으로 튜닝하는, 즉 여러번의 작은 시도를 통해 고객의 니즈에 Fit을 맞추는 디자인씽킹 방식은 속도와 별개로 고객의 니즈에 부합할 확률이 더 높을수밖에 없다. 결국 상품기획은 Waterfall보다는 디자인씽킹 방식이 성공 확률이 더 높다고 할 수 있다.
그 다음 실제 제품을 양산하기위한 개발과정에서는 어떨까? 위에서 언급한것처럼 디자인씽킹을 통해 기획 했으니 당연히 작게, 빠르게, 여러번 개발하면서 진화하는 애자일 방법론을 적용하면 될까? 여기에서 한가지 고려해야하는 병원의 중요한 특성이 있다. 병원은 개발조직이 아니라는 점이다. 개발에 투자할 수 있는 비용, 기간, 역량이 제한적이다. 그리고 또 한가지 특징이 있다. 병원은 환자를 대상으로 서비스를 하는곳이기 때문에, 환자 안전을 담보로 테스트를 할 수는 없다는 점이다. 즉, 병원에서 개발하기 위해서는 반드시 안정성이 담보되어야 한다는 특성이 있다. 이런점 때문에 애자일 방법론을 병원에 적용하기 어려운점이 있다.
하지만 애자일 방법론은 매우 큰 장점이 있다. 작게 개발하기 때문에 비용과 리스크가 적다는 점이다. 처음부터 많은 기능들을 대규모로 개발하는것이 아니라 꼭 필요한 기능만 우선 개발하고 점점 형상을 구체화하는 방식이기 때문에 이 장점을 포기하기는 매우 아쉽다. 또한가지 장점은 사용자 중심이라는 점이다. 시작점이 기업 측면의 기술,효율,수익에서 시작하는것이 아니라 사용자의 문제 해결을 목표로 시작하기 때문에, 사용자 가치가 높은 제품이 될 확률이 높을수밖에 없다.
Waterfall + Agile <이미지 : getty image>