비대면 진료 서비스 문제 분석

사용자 불편을 비즈니스 관점과 데이터 관점으로 재해석하기

0. 분석 관점

이번 분석에서는 사용자의 불편을 단순 VOC로만 보지 않고, 두 가지 관점에서 다시 해석했다.

첫 번째는 비즈니스 관점이다.
사용자의 불편이 회사의 KPI, 매출, 비용, 리텐션, 법적 리스크에 어떤 영향을 주는지 보는 관점이다.

그래서 이 불편이 우리 회사의 매출, 비용, 신뢰도, 리텐션에 어떤 타격을 주는가?

두 번째는 데이터 관점이다.
이 문제가 실제로 존재하는지 어떤 로그와 데이터로 확인할 수 있는지, 그리고 해결 이후 어떤 지표로 개선 여부를 볼 수 있는지 정의하는 관점이다.

어떤 로그를 보면 이 문제가 맞다고 확신할 수 있는가?
어떤 데이터와 방식으로 이 문제를 개선할 수 있는가?

---

1. 앱 진입 단계

발견된 문제

앱 진입 단계에서 사용자는 증상을 선택하고 진료 과목을 고르게 된다.
하지만 이 과정이 너무 쉽고 빠르게 설계되어 있으면, 환자가 자신의 증상에 맞지 않는 진료 과목을 선택할 위험이 있다.

또한 사용자는 매번 진료를 받을 때마다 본인이 복용 중인 약, 알레르기, 기존 질환 정보를 반복해서 설명해야 한다. 이 과정은 번거로울 뿐 아니라, 의료진이 중요한 정보를 놓칠 경우 부작용이 있는 약을 처방받을 수 있다는 불안으로 이어질 수 있다.

즉 이 단계의 핵심 문제는 다음과 같다.

비대면 진료의 진입은 빠르지만, 환자에게 필요한 의료 맥락 정보가 충분히 전달되지 않아 잘못된 진료 연결이나 처방 리스크가 발생할 수 있다.

---

해결 방향

이 문제를 해결하기 위해서는 의사와 약사가 환자의 주요 건강 정보를 진료 전에 확인할 수 있어야 한다.

핵심은 단순히 문진표를 추가하는 것이 아니라, 진료에 필요한 환자 맥락 정보를 안전하게 수집하고 전달하는 구조를 만드는 것이다.

가능한 방식은 세 가지다.

1. OS에 내장된 건강앱 데이터 불러오기
2. 국가 마이데이터 연동하기
3. 접수 단계에서 자체 문진표 작성하기

초기 단계에서는 법적·기술적 부담이 큰 외부 데이터 연동보다, 자체 문진표를 통해 필요한 최소 정보를 구조화해서 받는 방식이 현실적일 수 있다.

이후 사용자의 동의 기반으로 건강앱 데이터나 마이데이터 연동을 확장할 수 있다.

---

데이터 관점

이 문제를 데이터로 확인하려면, 먼저 사용자가 진료 전 어떤 정보를 입력했는지와 실제 진료 결과 사이의 관계를 봐야 한다.

확인할 수 있는 데이터는 다음과 같다.

• 증상 선택 로그
• 진료 과목 선택 로그
• 문진표 작성 완료율
• 복용 약물 입력 여부
• 알레르기 정보 입력 여부
• 진료 후 처방 약물 정보
• 약물 중복 또는 충돌 경고 발생 횟수
• 진료 후 CS 인입 사유
• 처방 관련 불만 VOC

이 데이터를 통해 다음 질문에 답할 수 있다.

• 사용자가 증상에 맞는 진료 과목을 선택하고 있는가?
• 문진표를 작성한 사용자의 진료 만족도나 재진료율이 더 높은가?
• 복용 약물이나 알레르기 정보가 입력되지 않은 경우 처방 관련 CS가 더 많이 발생하는가?
• 특정 증상 선택 이후 진료 과목 변경이나 진료 취소가 자주 발생하는가?
• 약물 중복 또는 충돌 가능성이 있는 처방이 얼마나 발생하는가?

⸻

비즈니스 관점

헬스케어 비즈니스에서 가장 치명적인 리스크는 의료 사고와 신뢰 하락이다.
특히 약물 중복, 약물 충돌, 알레르기 관련 처방 문제는 환자 안전과 직접 연결된다.

환자의 기존 데이터를 바탕으로 처방 충돌을 줄일 수 있다면, 플랫폼은 다음 효과를 기대할 수 있다.

• 의료 사고 및 법적 리스크 감소
• 플랫폼 신뢰도 상승
• 진료 만족도 개선
• 재이용률 증가
• 처방 관련 CS 비용 감소

또한 환자의 건강 정보가 안전하게 축적되면, 장기적으로는 맞춤형 병원·의사 추천에도 활용될 수 있다.

예를 들어 단순히 가까운 병원을 연결해주는 것을 넘어, 특정 질환이나 증상에 맞는 전문의를 추천할 수 있다. 특히 지방 환자와 수도권 전문의를 연결하는 방식으로 확장하면, 플랫폼의 지리적 한계를 줄이고 거래 매출을 확대할 가능성도 있다.

다만 환자 건강 정보는 민감 정보이므로, 데이터 수집과 활용에는 반드시 사용자 동의, 법적 검토, 보안 설계가 함께 필요하다.

---

2. 비대면 진료 과정

발견된 문제

비대면 진료 과정에서 사용자는 병원 대표 번호나 앱 내 통화 시스템이 아니라, 010으로 시작하는 개인 번호로 전화를 받는 경우가 있다.

이 경우 사용자는 해당 전화가 의사에게서 온 전화인지 알기 어렵다.
스팸이나 모르는 번호라고 생각해 전화를 받지 않을 수 있고, 그 결과 앱 안에서는 계속 진료를 기다리는 상태가 된다.

즉 이 단계의 핵심 문제는 다음과 같다.

비대면 진료 전화의 발신 주체가 명확하지 않아, 사용자가 진료 전화를 인식하지 못하고 진료 연결이 실패할 수 있다.

---

해결 방향

이 문제를 해결하기 위해서는 사용자가 “지금 오는 전화가 진료 전화다”라고 명확히 알 수 있어야 한다.

가능한 해결 방향은 세 가지다.

첫 번째는 050 안심번호 도입이다.
의사의 앱 또는 웹 화면에는 환자 개인 번호 대신 임시로 발급된 050 안심번호만 노출한다. 사용자는 진료 전화가 050 번호로 올 것이라는 안내를 미리 받는다.

두 번째는 앱 내 통화 시스템 도입이다.
장기적으로는 카카오톡 보이스톡처럼 닥터나우 앱 안에서만 통화가 이루어지도록 VoIP 기반 시스템을 구축할 수 있다.

세 번째는 진료 전 안내 메시지 강화다.
진료 대기 화면에 다음과 같은 문구를 명확히 보여준다.

곧 앱 안에서 전화가 올 거예요.
또는 050 안심번호로 진료 전화가 표시돼요.

초기에는 안내 문구와 050 안심번호 도입이 현실적이고, 장기적으로는 앱 내 통화 시스템을 통해 통화 품질과 진료 데이터를 더 정교하게 관리할 수 있다.

---

데이터 관점

이 문제를 데이터로 확인하려면 통화 연결 과정의 로그가 필요하다.

확인할 수 있는 데이터는 다음과 같다.

• 진료 요청 후 첫 통화 시도까지 걸린 시간
• 통화 연결 성공률
• 부재중 비율
• 재통화 시도 횟수
• 통화 지속 시간
• 통화 중 끊김 횟수
• 진료 취소율
• 진료 대기 이탈률
• 통화 관련 CS 인입 건수
• 통화 실패 후 재예약 여부

앱 내 통화 시스템이 도입된다면, 더 정교한 로그 수집이 가능하다.

예를 들어 다음 질문에 답할 수 있다.

• 실제로 진료가 1분 이내에 끝나는 경우가 얼마나 되는가?
• 특정 의사의 평균 진료 시간이 지나치게 짧은가?
• 통화 연결 실패가 특정 시간대나 특정 병원에서 집중되는가?
• 통화 실패 사용자는 이후 재예약을 하는가, 이탈하는가?
• 통화 품질 문제가 CS 증가와 연결되는가?

---

비즈니스 관점

비대면 진료에서 통화 연결 실패는 곧 진료 실패로 이어질 수 있다.
사용자가 의사의 전화를 받지 못하면 진료 경험은 중단되고, 사용자는 서비스에 불신을 느낄 수 있다.

이 문제를 해결하면 다음 효과를 기대할 수 있다.

• 진료 연결 성공률 증가
• 진료 대기 중 이탈 감소
• 진료 취소율 감소
• 통화 관련 CS 감소
• 사용자 신뢰도 향상
• 의사와 환자 모두의 운영 효율 개선

특히 앱 내 통화 시스템은 단순히 사용자 편의 기능이 아니라, 플랫폼이 진료 품질을 관리할 수 있는 기반이 된다.

현재처럼 외부 전화로 진료가 이루어지면 플랫폼은 진료 연결 여부나 통화 품질을 정확히 알기 어렵다.
하지만 앱 내 통화가 가능해지면 통화 연결 성공률, 통화 시간, 끊김 횟수, 평균 진료 시간 등을 확인할 수 있다.

이는 향후 병원·의사 품질 관리, CS 예방, 사용자 경험 개선으로 이어질 수 있다.

---

정리

이번 분석에서 중요한 것은 사용자의 불편을 곧바로 기능 아이디어로 바꾸지 않는 것이다.

예를 들어 “010 번호로 전화가 와서 불편하다”는 말은 단순히 번호 표시 문제처럼 보일 수 있다. 하지만 비즈니스 관점에서는 진료 연결 실패와 CS 증가로 이어질 수 있고, 데이터 관점에서는 통화 연결 성공률과 진료 이탈률로 확인할 수 있는 문제다.

또 “복용 약이나 알레르기 정보를 매번 말하기 귀찮다”는 불편도 단순 입력 편의성 문제가 아니다. 헬스케어 서비스에서는 처방 안전성, 플랫폼 신뢰도, 법적 리스크와 연결될 수 있다.

즉 PM은 사용자 불편을 다음 세 단계로 바꿔야 한다.

1. 사용자는 무엇을 불편해하는가?
2. 이 불편은 비즈니스에 어떤 영향을 주는가?
3. 이 문제는 어떤 데이터로 확인하고 개선할 수 있는가?

⸻

한 문장 요약

사용자 불편은 기능 아이디어의 출발점일 뿐이다.
PM은 그 불편을 비즈니스 임팩트와 데이터로 검증 가능한 문제로 바꿔야 한다.