PC에서 처리하던 진료실 업무를 현장에서 처리할 수 있도록 옮긴 슈퍼앱.
병원 운영 웹(CPE)의 기능 중 진료실에서 바로 사용해야 하는 업무를 역할별 미니앱으로 분리한 슈퍼앱입니다. 의사와 간호조무사는 진료실에서 모바일로 처치 전후 상태를 기록하고, 환자는 환자용 태블릿에서 피부 분석 결과와 병원 안내 콘텐츠를 확인합니다. 역할마다 권한과 기능이 달라 역할별 앱으로 나누되 하나의 모노레포에서 관리하도록 설계했습니다. Interaction App의 UX 기획과 전체 구현을 담당했으며, 마취 앱·진료 앱 등 다른 미니앱의 Figma 초안과 UX 흐름도 설계했습니다. V2 백엔드 전환에 맞춰 2개월간 앱을 재구축했고, 이후 신규 지점에 대응할 수 있도록 앱 번들에 묶여 있던 다국어 안내 콘텐츠를 CMS로 전환했습니다.
기존 진료실 화면은 의사와 간호조무사가 환자의 처치 상태를 확인하고 변경하는 기능을 제공했지만, PC 웹 환경에 한정되어 있었습니다.
이동이 잦은 진료 환경에서는 처치 직전·직후의 상태를 즉시 기록하기 어려웠고, 실제 업무가 이루어지는 시점과 시스템에 입력하는 시점 사이에 간극이 생겼습니다.
처치가 이루어지는 현장에서 상태를 기록할 수 있도록 진료실 업무를 모바일 환경으로 확장했습니다.
모든 기능을 하나의 앱에 넣기보다, 역할별 권한과 업무에 필요한 기능을 분리한 미니앱 구조로 설계했습니다.
역할별 앱은 하나의 모노레포에서 관리하도록 구성했습니다.
그중 Interaction App의 UX 기획과 전체 구현을 담당하고, 마취 앱·진료 앱 등 다른 미니앱의 Figma 초안과 UX 흐름도 함께 설계했습니다.
이후 동의서·진료 노트 등 새로운 현장 업무 앱이 같은 모노레포에 추가되며 역할별 미니앱 구조로 확장되었습니다.
마취 등 진료 과정에서는 대기 시간이 발생합니다. 이 시간을 단순히 기다리는 시간으로 두기보다, DERMA:CODE 결과와 병원 안내 콘텐츠를 보여주며 환자가 병원의 케어를 체감하는 경험으로 전환할 수 있다고 판단했습니다.
의료진은 마취 시작·종료 등의 상태를 기록하기 위해 매번 여러 뎁스(Depth)의 화면을 조작하며 환자를 찾아야 했고, 이로 인해 진료 외적인 낭비 시간이 발생하고 있었습니다.
진료실에 비치된 태블릿 하나로 환자의 대기 경험을 개선하는 동시에, 의료진의 기록 동선을 단축할 수 있다고 판단했습니다.
하나의 앱 안에 역할별(환자/의료진) 화면을 분리 구성하여 현장의 복합적인 니즈를 한 번에 해결하고자 했습니다.
환자 뷰: 마취 등 대기 시간 동안 자신의 DERMA:CODE 피부 분석 결과를 열람하거나, 근처 약국 및 교통 등 유용한 인프라 정보를 확인하며 시간을 보낼 수 있도록 구성했습니다.
의료진 뷰: 기존 PC와 진료 미니앱 중심의 업무 규칙(단계 전환, 관리자 인증 등)은 유지하되, 진료실 현장에서 의사와 간호조무사가 즉각적으로 상태 이벤트를 기록할 수 있도록 화면을 설계했습니다.
단순 요구사항 구현을 넘어 UX 기획부터 디자인 에셋 조율, 실제 구현까지 프로젝트 전 과정을 주도했습니다.
Flutter 실무 경험이 없는 상태에서도 AI 코딩 도구를 적극 활용하여 기능 정의와 검증을 직접 수행했으며, 2개월 만에 실제 출시 가능한 수준으로 MVP 개발을 완료했습니다.
기록용 사진을 촬영할 때마다 얼굴의 위치와 각도가 조금씩 달랐습니다. 한 번의 촬영에서 드는 시간은 크지 않았지만, 촬영할 때마다 구도를 다시 맞춰야 했고 재방문 환자의 시술 전후 사진을 비교할 때도 촬영 조건의 차이가 생겼습니다.
이 과정은 매번 반복되는 일이었지만 별도의 개선 요청으로 올라오지 않았고, 관련 기능도 요청서에 포함되어 있지 않았습니다.
요청서에 없더라도 반복해서 발생하고 이후 작업에 영향을 줄 수 있는 문제라면 먼저 개선하기로 했습니다.
촬영 화면에 얼굴 정렬 기준을 보여주는 방식이라 구현 비용도 크지 않았기 때문에, 별도 기능으로 추가하기보다 촬영 과정 자체에 기준을 넣기로 했습니다.
촬영 화면 위에 얼굴의 위치와 각도를 맞출 수 있는 정렬 가이드라인을 오버레이했습니다.
사용자는 가이드 안에 얼굴을 맞춘 뒤 촬영할 수 있도록 했습니다.
의료진과 대표에게 긍정적인 반응을 얻었고, 이후 기록용 사진을 촬영할 때 일정한 기준으로 구도를 맞출 수 있는 장치가 되었습니다.
요청서에 없던 기능이었지만, 반복되는 업무를 관찰해 재방문 환자의 사진 비교까지 고려한 개선으로 연결했습니다.
환자용 태블릿의 안내 콘텐츠(영상·이미지·지도·텍스트, 5개 언어)는 앱 번들 안의 파일이었습니다. 문구 하나를 고쳐도 앱을 다시 배포해야 했고, 한 지점 기준으로 하드코딩되어 신규 지점 추가 시 유연한 대응이 불가능했습니다.
처음에는 기획서로 요구사항을 전달했지만, 1차 구현은 이미지 주소를 옮기거나 기존 파일 구조를 그대로 API로 옮기는 수준에 머물렀습니다. 초기 전달 방식으로는 개발 의도가 백엔드 팀에 온전히 전달되지 않았습니다.
해석이 갈리지 않도록 요구사항이 아니라 인터페이스 계약 수준의 설계서를 다시 썼습니다. DB 스키마, API, 검증 규칙과 에러 코드, 어드민 화면, 앱 렌더링 규칙, 기존 지점의 시드 데이터까지 한 문서에 담았습니다.
편집 범위를 세 종류로 나눴습니다. 기존 항목은 수정과 숨김만 가능하고 삭제할 수 없습니다. 지점별 차이는 운영자가 직접 항목을 추가하여 대응하도록 설계했습니다. 환자 진료 데이터를 표시하는 메뉴는 콘텐츠가 아니므로 순서와 노출만 설정 가능합니다.
저장은 지점당 문서 하나로 정했습니다. 메뉴·탭·블록을 테이블로 나누면 블록 타입이 늘 때마다 마이그레이션이 생기기 때문입니다. 대신 서버가 스키마로 검증하고, 다국어와 이미지 주소를 해석한 완성본만 앱에 내려줍니다.
설계서를 넘긴 당일 백엔드 담당자가 세 저장소에 구현을 반영했고, 이후 운영자 편집기와 앱 반영을 이어서 완성했습니다.
앱은 문서를 세션 동안 캐시하고, 화면을 열 때 ETag로 변경 여부만 확인합니다. 바뀌지 않았으면 304 응답으로 끝납니다.
콘텐츠 변경과 지점 추가에 앱 배포가 필요 없는 구조가 되었습니다. 앱 배포가 필요한 경우는 새 블록 타입이 생길 때뿐입니다.
지도는 화면을 가득 채우도록 잘려서 깔리는데, 마커 좌표는 화면을 기준으로 계산되고 있었습니다. 기기 비율마다 잘리는 폭이 달라 같은 값이 다른 자리에 찍혔고, 편집기에서 찍은 자리와 태블릿의 자리도 달랐습니다.
먼저 좌표 기준을 지도 이미지로 바꿨는데, 이번에는 기존 값이 전부 밀렸습니다. 좌표의 의미 자체를 바꿨기 때문입니다. 기존 값이 맞춰져 있던 정의(기준 태블릿 화면 위의 정렬 좌표)로 되돌리고, 기준 화면에서의 위치를 지도 이미지 안의 비율 위치로 환산해 실제 화면 좌표로 변환되도록 로직을 재설계했습니다. 앱과 편집기가 동일한 계산식을 공유하도록 맞췄습니다.
기준 태블릿에서는 이전과 픽셀 단위로 같고, 다른 화면에서도 그림의 같은 지점에 찍힙니다. 기존 값 2개가 마커 중심 ±3px 안에 오는 것을 앱과 편집기 양쪽 테스트로 고정했습니다.
저장 위치를 옮기는 전환에서 데이터의 의미가 변질된다면, 이는 단순한 이관 실패를 넘어 데이터의 무결성을 훼손하는 일입니다. 설계서에 좌표의 기준 화면을 적지 않은 것이 원인이었고, 그 정의를 문서와 테스트로 재정의했습니다.
운영 데이터가 충분히 축적되지 않은 초기 결과이며, Flutter는 iOS 태블릿 출시를 위해 처음 실무 적용한 수준으로 Android 대응을 포함한 Flutter 전반의 실무 경험은 아직 제한적입니다.
CMS의 백엔드와 편집기 초기 버전은 설계서를 바탕으로 백엔드 담당자가 구현했습니다. 운영 중 발견한 백엔드 결함은 원인을 특정해 수정안까지 작성했고, 인프라 권한 문제로 최종 반영은 백엔드 담당자가 했습니다.