환자 기록을 진료에 연결하고, 의사의 판단과 환자의 이해를 잇는 AI 보조 커뮤니케이션 서비스
환자가 남긴 기록을 의사가 진료 전에 읽을 수 있게.
환자가 자연어로 남긴 증상을 AI가 구조화해, 의사가 진료 전에 확인할 수 있는 기록으로 바꿉니다.
의사가 판단에 필요한 핵심 정보를 한눈에 볼 수 있게.
환자 기록, 증상 변화, 핵심 요약을 통합해 짧은 진료 시간 안에서 빠르게 판단할 수 있도록 돕습니다.
환자가 진료 결과와 치료 계획을 다시 볼 수 있게.
진단, 치료 계획, 처방, 주의사항을 환자가 다시 이해하고 참고할 수 있는 형태로 정리합니다.
바이브 코딩으로 직접 설계 · 구현한 AI 보조 진료 서비스.
환자기록을 정리해 의사는 빨리 판단하고, 환자는 결과를 쉽게 이해할 수 있도록 했습니다.
진료 결과는 정상이었지만, 환자의 증상은 계속 됐고 병원을 전전하는 계기가 됐다.
의사는 판단을 마쳤지만, 검사 결과는 정상인데 증상이 계속되는(PPS/MUS) 환자는 왜 그런 판단인지, 이후 어떻게 관리해야 하는지 모른 채 돌아갔습니다. 이 문제가 가장 선명한 곳은 1차의료기관이었습니다. 동네 의원은 환자의 첫 접점이고, 지속 증상이 자주 모이며, 5분이라는 진료 시간이 환자와 의사 모두에게 소통의 제약이 되기 때문입니다.
문제를 넓게 보고 핵심만 남긴 뒤, 바이브 코딩으로 프로토타입까지.
병명이나 기능부터 정하지 않고, 환자와 의사 사이에서 무엇이 끊기는지 먼저 찾았습니다. 그 끊김을 줄이는 최소 진료 연결 서비스로 좁혔습니다.
환자는 정상인데 증상이 계속되는 답답함과 막막함이, 의사는 짧은 시간안에 파악할 정보 구조의 부족이 문제.
문헌 15개, 환자 텍스트 데이터, 환자 · 의사 인터뷰를 함께 보니 환자 쪽에서는 '정상'이라는 결과가 안심이 아니라 답답함으로 이어졌고, 의사 쪽에서는 짧은 진료 안에 핵심을 파악할 수 있는 정보 구조가 부족했습니다.
시간 제약 안에서 의사와 환자는 충분히 소통하지 못했다.
핵심 문제는 정보 부족이 아니라, 환자 경험이 임상 정보로 번역되지 않는 데 있었습니다. 15개 문헌에서 안심 실패, 번역 실패, 시간 압박을 핵심 문제로 정리한 뒤, 환자 텍스트와 인터뷰로 검증했습니다.
진료 결과를 받아들이지 못한 환자는 스스로 답을 찾아 검색을 반복했다.
가장 자주 나타난 문제는 진료 결과가 환자에게 이해되지 않는다는 것이었고, 환자는 답을 찾아 같은 검색을 반복했습니다.
환자는 병원을 전전하며 답을 찾았지만 달라지지 않았고, 의사는 짧은 시간 안에 환자를 온전히 파악하기 어려워했다.
문헌과 온라인 데이터만으로는 이 상황이 진료 현장에서 실제로 어떻게 벌어지는지 확인하기 어려웠습니다. 그래서 사전 인터뷰로 질문을 다듬고, 환자와 의사를 1:1로 만나 실제 경험을 들었습니다. 다음으로 환자와 의료진 관점을 따로 정리한 뒤, 어디서 어긋나는지 비교했습니다.
진료시간 5분은 환자와 의사 모두에게 소통하기 부족한 시간.
검사 결과가 정상이어도 환자에겐 불안이 남았고, 환자 경험은 짧은 진료 안에서 충분히 쓰이지 못했습니다. 문제를 '환자 기록 → 진료 맥락, 진료 결과 → 환자 이해와 다음 행동'이 끊기는 구조로 정의했습니다.
왜 그런 결과이고, 다음에 무엇을 해야 하는지.
정상이라는 말은 환자에게 정보가 아니라 “갈 길이 없다”는 상태로 느껴졌고, 환자가 원한 것은 결과 한 줄이 아니라 이유와 다음 단계가 연결된 구조였습니다.
짧은 시간 안에 빠르게 훑을 수 있는 요약.
의료진에게 더 필요한 것은 더 많은 정보가 아니라, 판단에 바로 쓸 수 있는 핵심 정보와 한눈에 읽히는 요약 포맷이었습니다. 소스에서도 최소 의사결정 정보와 선호 포맷을 따로 구조화했고, “눈에 팍 보이게” 읽히는 정보가 필요하다는 표현이 반복되었습니다.
환자가 원하는 것은 결과 자체보다 이유와 관리 계획이었습니다.
텍스트 분석과 인터뷰를 따로 보면, 환자가 실제로 무엇을 원하고 무엇에서 막히는지 설계 기준으로 쓰기 어려웠습니다. 온라인 텍스트와 환자 인터뷰를 통합해 페인 포인트와 니즈를 하나의 구조로 정리했습니다.
다음으로 이 요구가 의료진의 실제 진료 흐름 안에서도 성립하는지 확인했습니다.
의료진에게 필요한 것은 더 많은 데이터보다, 짧은 시간 안에 바로 판단에 쓸 수 있는 정보였습니다.
의료진이 실제로 먼저 보는 정보와 병목을 하나의 구조로 묶었습니다. 인터뷰를 개별 사례로만 보면, 의료진이 무엇을 먼저 확인하고 어디서 판단이 막히는지 설계 기준으로 쓰기 어려웠습니다. 의료진 인터뷰를 요약 코드와 클러스터로 통합해 최소 판단 정보, 정보 공백, 워크플로우 병목, 문서화 부담을 하나의 구조로 정리했습니다.
다음으로 이 구조를 환자 니즈와 같은 비교축 위에 놓고, 실제 진료 안에서 무엇이 연결을 끊는지 다시 정의했습니다.
핵심은 정보 부족이 아니라, 짧은 진료 안에서 의사의 판단이 환자에게 왜 그런지와 진료 후 어떻게 해야 하는지까지 충분히 설명되지 않는다는 점이었습니다.
문제를 단순한 정보 부족이 아니라, 환자와 의료진 사이에서 설명과 맥락이 끊기는 구조로 다시 정의했습니다. 환자와 의료진 결과를 따로 보면 서로 다른 문제처럼 보이지만, 실제 설계는 두 결과 사이에서 어디서 이해가 끊기는지를 함께 다뤄야 했습니다. 환자 결과와 의료진 결과를 같은 축으로 비교해 통합 해석과 설계 시사점으로 정리했습니다.
이후에는 이 통합 해석을 바탕으로, 어떤 사용자가 어떤 맥락에서 어디서 막히는지를 구체화하며 문제를 다시 정의했습니다.
환자는 증상에 대한 설명과 이후 방향을 듣고 싶었고, 의사는 판단에 필요한 핵심 증상 정보를 먼저 파악하고 싶었습니다.
통합분석에서 확인한 간극을 실제 진료 안의 사람과 상황으로 구체화했습니다. 환자는 왜 이런 증상이 의심되는지와 진료 후 어떻게 해야 하는지를 알고 싶어 했지만, 의사는 짧은 시간 안에 판단에 필요한 증상 정보를 먼저 추려야 했습니다. 그래서 이 단계에서는 두 사람이 같은 진료를 어디서 다르게 경험하는지 페르소나와 유저 저니맵으로 구체화하고, 그 어긋남을 Problem Statement, User story, How Might We로 다시 정리했습니다.
이렇게 정의한 문제를 바탕으로, 다음 단계에서는 이 간극을 줄이기 위한 기능과 흐름을 구체화했습니다.
기능을 줄이고, 환자 기록 → 의사 판단 → 환자 이해로 이어지는 최소 구조만.
기능 수가 아니라 핵심 루프가 기준이었습니다. 기록이 진료로 연결되고, 판단이 환자 이해로 이어지는 흐름만 남겼습니다.
가능한 기능을 먼저 넓게 펼쳤습니다. 처음부터 답을 좁히면 핵심 가치보다 개별 기능에 끌릴 위험이 커서, 환자와 의사 양쪽의 아이디어를 폭넓게 수집했습니다.
핵심 루프에 필요한 기능만 다시 좁혔습니다. 모든 기능을 같은 무게로 두지 않고, 준비 -- 연결 -- 판단 -- 이해 흐름을 직접 만드는 기능을 우선순위 기준으로 걸러냈습니다.
끝가지 남길 최소 범위를 확정했습니다. 우선순위 결과를 다시 정리해, 판단과 이해를 잇는 핵심 루프만 MVP에 남기고 나머지는 보류하거나 확장 범위로 분리했습니다.
AI로 환자는 증상을 쉽게 기록하고, 의사는 핵심 정보를 빠르게 파악하며, 진료 결과는 환자가 이해하고 치료 계획으로 이어지게 하는 최소 진료 연결 서비스.
의료는 작은 오해도 위험할 수 있고 법 · 규제가 AI 역할과 환자 데이터 처리를 제한하므로, 화면보다 AI의 역할 범위 · 의사 판단의 정보 위계 · 환자 설명 원칙을 먼저 검토.
그래서 화면 설계에 들어가기 전, 관련 법과 규제가 AI의 역할 범위와 환자 데이터 처리 방식에 어떤 제약을 두는지, 의료 데이터 하이어라키가 짧은 진료 안에서 의사가 무엇부터 빠르게 확인해야 하는지를 어떻게 구조화하는지, 의료 UX writing 원칙이 환자 설명과 건강 문해력 측면에서 어떤 기준을 요구하는지를 먼저 검토한 뒤, 이를 바탕으로 와이어프레임과 프로토타입의 정보 구조와 문구 체계를 설계했습니다.
AI는 진단이 아니라 참고 정보 범위로 제한해야 했고, 민감한 건강정보와 국외 이전에는 별도 동의가 필요했으며, 의사용 화면에는 비닫힘 경고와 검토 책임 고지가 계속 노출되어야 했습니다.
의사용 패널은 좁은 플로팅 구조 안에서 핵심 판단 정보를 먼저 보여줘야 했기 때문에, 알레르기·주호소·위험 신호를 우선 배치하고 나머지 데이터는 단계적으로 확인할 수 있는 구조로 정리했습니다.
환자용 문구는 의학적으로 정확해야 할 뿐 아니라, 건강 문해력을 고려해 쉬운 말을 먼저 쓰고 필요한 경우에만 의학용어를 병기해야 했으며, AI가 풀어쓴 내용이라는 점도 명확히 드러나야 했습니다. 의사용 화면 역시 320–360px 안에서 빠르게 읽을 수 있도록 간결한 텍스트 기준이 필요했습니다.
손스케치로 구조를 잡고, 바이브 코딩으로 실제 AI가 작동하는 프로토타입까지.
손스케치와 로우파이로 구조를 잡은 뒤, 바이브 코딩으로 실제 AI가 연결된 프로토타입까지 만들었습니다.
환자의 자유 입력을, 의사가 읽을 수 있는 기록으로 바꾸는 시작점입니다.
짧은 진료 안에서 환자 정보와 AI 브리핑을 빠르게 파악하는 화면입니다.
의사의 결과를 환자가 다시 확인할 수 있게 정리한 화면입니다.
환자는 더 개인화된 설명을, 의사는 더 빠른 요약을.
핵심 문제는 기능 부족이 아니라, 기록 · AI · 진료가 연결돼도 환자에게는 이해로, 의사에게는 판단으로 바로 이어지지 않는 구조였습니다.
사용성 테스트는 MVP가 어디를 더 선명하게 해야 이 강점이 제대로 읽히는지를 확인 할 수 있는 과정이었습니다.
검증 결과, 사용자가 크게 느낀 가치는 기록 기능 자체보다 기록이 진료와 이해로 이어지는 연결에 있었습니다. 그래서 이후 수정도 기능을 바꾸는 데보다, 왜 이런 판단이 나왔는지와 다음에 무엇을 해야 하는지가 더 먼저 읽히도록 메시지, 정보 구조, 출처 표기, AI 역할 구분을 다듬는 데 집중했습니다.
환자 앱의 사용성 점수는 76.5점, 의사용 패널은 75점. 기본 사용성은 나쁘지 않았지만, 핵심은 어떤 가치로 읽히는가였습니다.
환자는 기록 기능보다 진료 연결에서 가치를 느꼈고, 메인 화면 · 기록 이해 과업은 4.6점으로 가장 낮았습니다. 반복된 질문은 "왜 이런 판단인지"와 "어떻게 관리해야 하는지"였습니다.
중요 정보 확인 과업 2점(최저), AI 후보 · 근거 검토 7점(최고). 필요한 것은 AI 기능 추가가 아니라 출처가 분명한 짧은 요약이었습니다.
환자에게는 이유와 관리 계획이, 의사에게는 흐름을 방해하지 않는 짧은 요약이 먼저 필요했습니다.
전문가 평가는 이 서비스를 기능 부족보다 정보 제시 방식과 역할 전달의 문제로 봤습니다. 즉 환자와 의사의 반응이 보여준 문제를, 전문가 평가가 정보 구조의 관점에서 다시 확인해준 셈이었습니다.
이번 테스트는 방향성 확인에는 유효했지만, 일반화에는 한계가 있습니다. 의사 표본 1명, 더미 데이터 사용. 실제 임상 환경의 반복 사용 효과까지 입증한 것은 아닙니다.
환자에게는 나에게 맞는 설명과 데이터를, 의사에게는 바로 훑을 수 있는 요약으로 빠르게 환자를 파악할 수 있게.
사용성 테스트에서 확인된 핵심 문제는 기능 부족이 아니라, 환자에게는 설명이, 의사에게는 요약이 충분히 읽히지 않는 구조였습니다. 그래서 기능을 더하기보다, 환자 기록 → 의사 판단 → 환자 이해와 다음 행동으로 이어지는 전달 구조를 다시 설계했습니다.
환자에게는 진료 결과의 이유와 다음에 무엇을 해야 하는지, 의사에게는 짧은 요약이 먼저 보이도록 다시 설계했습니다. 새 기능을 더한 것이 아니라, 이미 만든 구조가 더 잘 이해되도록 다듬는 과정이었습니다.
지금 내 상태가 먼저 보이도록.
첫 화면에서 서비스의 핵심 가치가 바로 읽히지 않았고, 기록 기능이 서비스 전체를 대표하는 것 처럼 보였습니다. 그래서 무엇을 할 수 있는지보다, 지금 어떤 상태인지와 다음에 무엇이 필요한지를 먼저 읽히도록 바꾸었습니다.
의사가 환자 상태의 핵심만 빠르게 파악할 수 있도록.
의사에게 필요한 것은 더 많은 정보가 아니라, 판단에 바로 쓸 수 있는 핵심 요약이었습니다. 그래서 환자 기록과 핵심 요약이 먼저 읽히도록 정리했습니다.
환자 관점에서 기본적인 다음 단계 안내를 넘어, 왜 이런 판단인지와 이후 무엇을 해야 하는지를 이해할 수 있도록.
환자는 결과를 받았지만, 왜 그런 판단인지와 다음에 무엇을 해야 하는지가 충분히 이해되지 않았습니다. 초기 프로토타입에도 기본적인 다음 단계 안내는 있었지만, 환자 관점의 설명으로는 부족했습니다. 그래서 의사의 판단을 환자 관점의 요약으로 다시 풀고, 치료 계획 · 처방 · 주의사항 · 다음 단계를 한 번에 읽히도록 정리했습니다.
개별 화면보다, 서비스 전체가 하나의 흐름으로 읽히도록 구조를 다시 정리.
화면을 각각 다듬는 것만으로는 부족했습니다. 각 화면이 좋아져도 서비스 전체가 하나의 흐름으로 읽히지 않으면 기능 모음처럼 보일 수 있었기 때문입니다. 그래서 정보 구조(IA)와 사용자 흐름(User Flow)을 기능 나열이 아니라, 상태 확인 → 진료 연결 → 결과 이해 순서가 먼저 읽히도록 핵심 루프 중심으로 다시 정리했습니다.
화면 · 기능 · 로직 문서를 함께 남겨
프로토타입 이후 개발을 이어갈 수 있도록.
화면 상세 정의서에서는 정보 위계와 컴포넌트 구조를, 기능 상세 정의서에서는 데이터 조건과 표시 규칙을, 로직 문서에서는 홈 상태 분기 · 의사 화면 전환 · 결과 읽음 처리 · AI 요약 반영 방식까지 정리했습니다.
기존에는 화면 중심으로 흩어져 있던 정의를, 최종 단계에서는 화면 · 기능 · 로직으로 분리해 다시 하나의 흐름으로 연결함으로써 이후 개발을 이어갈 수 있는 구조로 정리했습니다.
AI가 기록을 정리하고 설명까지 이어지도록 설계.
AI는 세 단계에서 각각 다른 역할을 합니다. 환자가 남긴 자연어 기록을 의사가 읽을 수 있는 구조로 바꾸고, 진료 중에는 환자 상태의 핵심을 짧은 브리핑으로 요약하며, 진료 후에는 의사의 판단을 환자가 이해할 수 있는 설명으로 다시 풀어줍니다. 세 단계가 따로 작동하는 것이 아니라, 기록 → 판단 → 이해가 하나의 흐름으로 이어지도록 AI의 역할을 설계했습니다.
초기에는 AI가 일부 화면에서 부분적으로 작동했다면, 최종 단계에서는 환자 기록 입력부터 의사 판단 지원, 환자용 설명까지 하나의 흐름으로 연결되도록 설계했습니다.
환자는 왜 그런 결과인지와 앞으로 할 일을, 의사는 핵심 요약을 바로 볼 수 있는 최소 진료 연결 서비스 완성.
이 프로젝트는 환자 기록이 진료에 쓰이고, 의사의 판단이 다시 환자의 이해와 다음 행동으로 남게 하는 최소 구조로 정리되었습니다. 제품 관점에서는 핵심 루프를 더 선명하게 남겼고, 구현 관점에서는 실제 AI가 연결된 프로토타입과 화면 · 기능 · 로직 정의까지 함께 전달했습니다.
문제는 명확했지만, 검증 환경은 제한적이었다.
환자는 정상 결과를 받아도 판단의 이유와 다음 행동을 이해하지 못하고, 의료진은 짧은 시간 안에 환자 맥락을 파악하고 설명하기 어렵다. 다만 의료진 인터뷰 섭외가 쉽지 않아, 응답을 일반화하지 않고 반복적으로 드러난 공통 병목에 집중했다. 이 한계는 오히려 프로젝트 범위를 보수적으로 좁히는 기준이 되었다.
AI 기능보다 중요한 것은 정보의 연결이었다.
핵심은 AI 기능 자체가 아니라, 기록된 정보가 의료진의 판단과 환자의 이해로 이어지는 구조였다. 의료진에게 필요한 건 더 많은 데이터가 아니라 판단에 쓸 우선순위였고, 환자에게 필요한 건 결과가 아니라 이유와 다음 행동이었다. 그래서 MVP는 기능을 늘리는 대신, 기록이 의료진의 판단으로 정리되고 다시 환자의 이해로 돌아오는 핵심 루프에 집중했다.
구현 과정에서 보이지 않던 제약을 배웠다.
백엔드와 DB를 직접 다루며 데이터 흐름과 AI API 연동 구조를 여러 번 다시 만들었다. 비용 부담, 외부 API로 보낼 수 있는 데이터의 범위, AI 출력 표현의 한계까지 동시에 고려해야 했다. 이를 통해 구현은 화면을 작동하게 만드는 일이 아니라, 데이터·비용·법적 책임·사용자 안전을 함께 조율하는 일임을 체감했다.
제약은 자유도를 줄인 것이 아니라 판단 기준이 되었다.
의료 도메인의 제약은 처음에는 자유도를 줄이는 듯했지만, 결국 무엇을 말할 수 있고 무엇은 말하면 안 되는지 정하는 기준이 되었다. AI 출력은 진단이 아닌 참고 키워드와 요약으로 제한했고, 의료진의 최종 검토 구조를 유지했다. 이는 타협이 아니라 안전하게 쓸 수 있는 제품에 가까워지기 위한 조건이었다.
다음 프로젝트를 위한 메모.
다시 한다면 완성도 높은 프로토타입보다 핵심 정보 구조를 더 일찍 검증했을 것이다. 의료진이 어떤 정보를 먼저 보고 판단하는지, 환자가 어떤 설명에 납득하는지를 더 빠르게 비교했을 것이다. 이번 프로젝트는 여러 제약 속에서 환자와 의료진 사이의 이해 차이를 줄이는 최소 연결 구조를 찾아간 과정이었다.
