brunch

You can make anything
by writing

C.S.Lewis

by 채드 Apr 10. 2024

병원의 WinWin 오픈이노베이션


<메이요클리닉과 구글의 협업>


2021년도 의료데이터중심병원


최근 국내 병원들이 네이버,카카오,KT같은 빅테크 기업과 협업하기 위해 컨소시엄을 구성하거나 MOU를 맺는다는 기사를 자주 접하게 된다. 이는 국내 뿐 아니라 글로벌 최고 병원인 메이요클리닉도 마찬가지다. EHR(전자건강기록)시스템 개발을 위해 구글과 협업하고, 의료 AI개발을 위해 AI 반도체 업체와 협업하고, EHR 데이터 통합을 위해 아마존과 협업하고 있다. 이렇게 병원이 외부기업과의 오픈이노베이션을 추진하려는 이유는 무엇인지, 그리고 그 과정에서 어떤 어려움이 있으며, 성공전략은 무엇인지에 대해 이야기 하고자 한다.


✅ 병원이 오픈이노베이션을 원하는 이유

병원이 자체적으로 필요해서 개발하는 솔루션은 보통 외주 업체를 활용해서 개발하지만, 아직 한번도 시도해보지 않은 솔루션, 또는 이미 상용화된 기술이기는 하지만 병원에는 처음 적용해보는 솔루션, 그리고 로봇이나 AI처럼 전문 기술과 인프라 없이는 개발 자체가 불가능한 솔루션 같은 경우는 병원 혼자서 개발하기 어렵다. 예를 들어 차세대 스마트수술실, 생성형 AI기반의 병원 키오스크, 한국형 원격 중환자실(eICU), 음성 녹음을 통해 EMR에 자동으로 기록해주는 시스템, CCTV 얼굴인식을 통해 환자ID 확인 및 동선추적 솔루션등이 이런 경우에 해당한다.


한번도 시도해보지 않은 새로운 컨셉의 솔루션을 만든다는건 기본적으로 리스크를 포함하고 있다는 이야기다. 기술, 예산이 부족해서, 시장상황이 변해서 언제든 실패할 수 있기 때문이다. 그래서 이런경우 많은 병원들이 외부기업과의 파트너십을 선호한다. 이런 과제 포멧을 병원에서는 보통 ‘공동연구개발’ 과제라고 부른다. 공동연구개발 과제는 리스크를 서로 나눠가지면서 공동의 목표를 달성할 수 있다는 장점이 있다. 


그리고 또한가지 장점은 공동의 목표가 상품화를 통한 수익창출이기 때문에 일정 퀄리티를 확보할때까지 지속적으로 업그레이드가 가능하다는 장점이 있다. 이점이 외주개발과 가장 큰 차이점이라고 할 수 있다. 외주개발은 정해진 기능과 스펙을 개발하고 끝이지만, 공동연구개발과제는 기능과 스펙이 아직 정해지지 않은 상태에서 리스크를 분담하고, 제품이 완성될때까지 함께 노력해서 결과물을 만들어야 서로에게 윈윈이기 때문에 새로운 솔루션을 개발할때는 공동연구개발이라는 오픈이노베이션 형태의 과제 포멧을 선호하게 된다.


하지만 장점만 있는것은 아니다. 실제로 과제를 추진하다보면 패턴처럼 발생되는 문제들이 있는데, 보통 서로 이 장벽을 넘지 못해서 MOU를 맺은뒤 결과물 없이 과제가 흐지부지 끝나게 되는 경우를 종종 보게 된다. 그동안의 경험을 바탕으로 이유들을 정리해보면 다음과 같다. 




✅ 병원의 오픈이노베이션의 허들

• 기업은 병원을 모른다

병원은 한번 연을 맺은 기업은 잘 바꾸지 않으려는 성향이 있다. 그 이유는 새로운 업체를 발굴하면서 발생하는 리스크나 시행착오를 겪는 과정이 기업과 병원 양측에게 너무 길고 험난한 시간이기 때문이다. 병원이 새로운 업체와 MOU를 맺고 본격적으로 과제가 시작되면 병원에서 가장먼저 하는 업무가 업체 교육이다.  업체는 병원을 모르기 때문에 현장을 답사하고, 설명하고, 자료를 제공하고, 문답하는 지난한 과정을 거치게 된다. 여기에서 문제는 아무리 설명해도 기업은 그 정보들을 소화하는데 시간이 걸리고, 업체가 이해를 했다고 해도 이후에 제안되는 병원의 현실과는 맞지 않는 결과물들을 보게되면 담당자들은 어디에서 어떻게 설명해야 할지 암담해진다. 


예를들어 병동 환자에게 태블릿을 대여해주는 서비스를 제안했다고 가정해보자. 여기에대해 가장 먼저 나오는 피드백은 그 태블릿 충전, 소독, 파손관리, 재물조사 이걸 다 누가해야하냐는 간호사들의 질책부터 시작된다. 또는 응급실에 들어오는 환자의 신원파악이 어렵다는 문제를 해결하기위해 얼굴이나 지문인식을 활용하자는 아이디어를 제안한다면, 그 즉시 응급실 환자는 얼굴을 알아보기 어려운 경우도 많고, 지문이 달아서 인식 자체가 안된다는 피드백을 1초도 안되서 받게 된다. 


이렇게 얘기하면 기업 입장에서는 이해가 안된다. 보통 100명을 만족시키려면 그중 9명의 Edge case를 위한 보완책을 만들고 여기에 해당 안되는 한두명은 어쩔수 없이 포기하는 형태가 일반적인 솔루션 개발방식인데 무조건 안된다고 말하는 병원이 답답하기만 하다. 하지만 병원은 0.1%도 오류가 있으면 안되는 곳이다. 천명중 한명이 자칫 오류로 인해 생명에 위협이 될수도 있기 때문이다. 만약 A환자를 바코드 시스템오류로 B환자라고 인식해서 약물이 서로 뒤바뀌거나 수술실이 뒤바뀐다면 본인의 의지와는 상관없이 정말 돌이킬 수 없는 테러를 당할수도 있기 때문이다. 이렇게 서로 답답한 상태에서 계속 업무를 주고받게되면 둘다 번아웃 되는 상황이 온다. 병원은 교육을 시켜도시켜도 딴소리만 하는 기업에게 실망하고, 기업은 병원의 느리고 보수적인 피드백과 의사결정에 지치는 상황이 오게된다. 이런 지난한 과정을 다시 겪기 싫어서 병원도 왠만하면 한번 함께 일한 파트너와 지속적으로 함께하고 싶어한다.



• 병원은 기업을 모른다

병원은 MOU를 맺고 본격적으로 과제를 추진하게되면 기업에서 적극적으로 인력,비용,인프라를 투입해서 개발을 시작 할 것으로 기대한다. 하지만 기업은 이윤이 없거나 가능성이 보이지 않으면 투자하지 않는다. 함께 잘 해보자고 MOU는 맺었지만, 개발할 솔루션이 기업 입장에서 연구개발비가 얼마나 투입되는지도 산정해봐야하고, 예상되는 리스크, 솔루션을 사용할 고객, 마켓 사이즈등 검토해야할 내용이 엄청나게 많다. 그래서 기업에서 섯부르게 대규모의 개발인력을 투입하거나, 병원에 파견을 보내거나등의 행위를 하지 않는다. 하지만 기업의 생리를 잘 모르는 병원은 같이 잘 만들어서 사업화하면 된다는 순진한 생각으로 접근하는 경우가 많다. 이렇게 서로 기대만 하다가 시간은 흐르고, 기대가 점점 실망으로 바뀌면서 실익이 없다고 판단하고 흐지부지 되는 경우가 발생한다.



• 신뢰관계 형성이 쉽지 않다

비의료 기업은 병원이 만들고자 하는 솔루션의 시장성을 파악하기 쉽지 않다. 우선 병원 관련 정보 자체가 퍼블릭 대상으로 오픈되는 경우가 많지 않다. 그리고 의료적으로 얼마나 가치있는 솔루션인지에 대해 가늠하기도 쉽지 않고, 그렇다고 병원에서 의료진들이 말하는대로 그대로 맞춰서 개발하기도 애매하자. 막상 개발했는데 해당 제품이 다른 병원에 확산 적용되어야 투자금을 회수할수 있을텐데 실제로 다른 병원의 상황을 알기 어렵기 때문에 지금 개발하고 있는 제품의 확장성이 얼마나 있는지도 의심된다. 결국 제품의 퀄리티와는 별개로 제품의 '시장성'을 판단해야하는데 이부분이 좁혀지기가 쉽지 않다. 


그래서 보통 파트너사가 요청하는 조건은 개발한 솔루션을 외부병원에 판매하기 위해서는 레퍼런스가 필요하기 때문에, 그리고 과제 동력유지 차원에서 병원이 해당 솔루션을 구매한다는 조건을 요청하는 경우가 많다. 이렇게 되면 병원은 병원나름대로의 걱정이 시작된다. 만약 파트너사만 믿고 개발한 솔루션이 생각보다 퀄리티가 낮게 나올수도 있고, 개발비용을 오히려 더 높게 책정해서 비용이 더 들수도 있기 때문이다. 


어떤 기업은 처음부터 함께 공동개발할 생각보다는 기존에 가지고 있던 제품을 이번 공동연구개발 과정에서 판매하려는 목적으로 과제를 시작하기도 한다. 시간이 지나도 연구개발 인력보다는 영업인력을 위주로 할당하여 논의가 진전이 잘 안되는 사례도 있다.




✅ WinWin 오픈이노베이션을 위한 숙제

결국 병원의 성공적인 오픈이노베이션을 위해서는 병원과 기업 어느 한쪽도 의존해서는 안된다. 정신 똑바로 차리고 서로를 견제할 수 있는 능력을 갖춰야한다. 


우선 병원은 기업의 개발프로세스를 이해해야하고, 무엇보다 사용자가 누구이고, 어떤 문제를 해결해야 하며, 이 문제를 왜 해결해야하는지, 이를위해 어떤 방법이 가장 효율적이며, 무엇을 개발해야 하는지에 대해 명확하게 말할 수 있어야한다. 즉, Design Thinking 기반으로 Product를 기획할 수 있는 역량이 필요하다. 파트너사가 안심할 수 있도록 Product를 기획하고 설득할 수 있어야 한다. 


기업은 초반에 병원이 교육하다가 에너지가 소진되지 않도록 병원에 대한 이해도를 높여서 Communication cost를 최소화 해야한다. 또한 공동연구개발 하기위한 Product의 상품성과 시장성을 파악하는건 기업의 몫이다. 병원은 자신의 병원의 의료질을 높이는것이 목적이기 때문에 이 역할을 병원에 의존하면 안되고 기업이 객관적으로 사용자가 누구인지, 해결하고자 하는 문제가 얼마나 가치있는 문제인지에대해 병원에 대한 이해도를 바탕으로 Right problem을 검증하고, 해당 유저의 예상 숫자와 시장규모를 파악할 수 있어야한다. 그렇지 않으면 업무 진행 자체가 어려워질 수 있다.


병원과 기업이 각각 서로 의사결정권자에게 프로젝트 추진 동력을 얻기 위해서는 서로 아쉬운걸 채워줘야 한다. 너무 한쪽의 이익을 주장하면 과제 자체가 성립되기 어렵다. 보통 병원이 오픈이노베이션을 하려는 목적은 비용과 인력이 없어서이고, 업체가 병원과 협업하려는 이유는 레퍼런스를 확보하거나 신사업 기회를 발굴하고자 하는것이다. 병원이 무조건 개발한 솔루션을 무상으로 사용하려고 한다거나 기업에게 인력투자를 요청하면 기업이 받아들이기 어렵고, 반대로 기업이 병원에게 무조건 구매하는것을 조건으로 해야 과제가 시작될 수 있다는 조건을 걸면 과제의 진도가 안나간다. 서로 MOU만 맺고 시작조차 못하는 상황을 피하기 위해서는, 서로가 이부분에 대해 어디까지 제공하고 어디까지 양보할 수 있는지 처음부터 제시해야한다. 그래야 이야기가 시작될 수 있다.


마지막으로 컨셉이 아니라 청사진을 만들어야한다. 목적 없이 개발에만 집중하면 쓸만한 결과물없이 기간만 늘어져서 만들다가 서로 지치게 된다. 특히 IT기업 환경은 서로 언제 어떻게 변할지 모른다. 지금 담당자와 의사결정권자가 언제 바뀔지 모른다. 그렇기 때문에 목표점과 결과물을 명확히 하고, 기간을 최대한 짧게 가져가는것이 오픈이노베이션의 모멘텀을 유지하는 길이다. 목표점을 너무 길게 잡지 말고, 중간 결과물을 서로 실용적으로 활용할 수 있는 방향으로 뽑아내고, 그 중간 결과물이 합쳐져서 최종 결과물을 완성해가는 형태로 애자일의 Sprint형태로 과제가 진행되어야 한다. 그렇지 않으면 컨셉만 만들다가 흐지부지 프로젝트가 종료되는 상황을 보게될 수도 있다.



브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari