진단받은 사람과 아직 아닌 사람을, 서비스가 다르게 대하도록

📚 「AI 헬스케어 파이널 프로젝트」 연재 20편입니다. (19편: 대시보드는 위험군인데 챌린지는 딴소리)

📝 한줄 요약

콩팥병을 이미 진단받은 사람과, 아직 진단받지 않은 사람을 우리 서비스가 다르게 대하도록 가른 날입니다. 진단받은 사람은 이미 의료의 영역에 있으니 우리가 위험 점수를 매기지 않고 “주치의 지시를 따르세요”라고 안내합니다. 아직 아닌 사람이 우리가 도울 대상이고요. 이 한 가지 결정이 화면 구성부터 챌린지 내용, 챗봇 답변까지 줄줄이 바꿔놨습니다.

바쁘시면 이것만 읽어도 돼요:

우리 서비스의 본질은 ‘진단’이 아니라 ‘의사에게 가야 할 사람을 골라내는 선별’입니다
그래서 이미 진단받은 사람은 우리가 점수를 매기지 않고 의료의 영역으로 넘깁니다
진짜 관리 대상은 아직 병은 아니지만 위험한 경계선에 있는 사람들입니다
진단 여부를 어디서 입력하느냐가 흩어져 있어 화면이 따로 노는 버그가 있었고, 입력 창구를 하나로 모아 해결했습니다
같은 날 두 번 고친 정보가 챗봇에 반영 안 되던 숨은 버그도 잡았습니다

🎯 이런 분들께 도움돼요

서비스나 제품이 사용자 유형에 따라 다르게 작동해야 하는 분
“우리가 정작 무엇을 해주는 서비스인가”를 한 줄로 정리하고 싶은 분
정보가 여러 곳에 흩어져 화면이 따로 노는 문제를 겪는 분

😫 문제 상황 (Before)

그때까지 우리 서비스는 모두를 똑같이 대했습니다. 누가 와도 콩팥병 위험 점수를 매기고, 똑같은 챌린지를 권하고, 똑같은 화면을 보여줬어요.

그런데 곰곰이 생각해보니 이상했습니다. 이미 콩팥병을 진단받은 사람에게 우리가 “당신은 위험 등급입니다”라고 점수를 매기는 게 무슨 의미일까요. 그 사람은 이미 병원에 다니고 주치의가 있습니다. 우리가 끼어들 자리가 아니죠. 오히려 어설픈 점수가 혼란만 줍니다.

그래서 큰 방향을 다시 잡았습니다. 진단받은 사람과 아직 아닌 사람을 처음부터 갈라서, 화면 구성도 챌린지도 다르게 가는 거였죠.

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus
특이사항: 하나의 큰 결정(진단 여부 분기)이 화면·챌린지·챗봇으로 퍼지는 걸 따라가며, 그 과정에서 드러난 숨은 버그까지 함께 잡음

🔧 작업 과정

”우리는 진단하는 게 아니라, 의사에게 갈 사람을 골라내는 거야”

크게 개선되어야 할 사항은 서비스를 ckd 진단자와 비진단자를 우선 가려서
대시보드 구성부터 챌린지 내용 등이 구별되어야 해

이 한 줄이 그날 작업의 출발점이었습니다. 그리고 이 결정 뒤에는 우리 서비스의 본질에 대한 정리가 있었어요.

우리는 콩팥병을 ‘진단’하지 않습니다. 진단은 의사의 몫이니까요. 우리가 하는 건 선별입니다. 아직 병원에 갈 생각이 없는 사람 중에서, “당신은 한번 검사받아 보는 게 좋겠어요”라고 짚어주는 일이요. 특히 핵심은 아직 병은 아니지만 위험한 경계선에 있는 사람들입니다. 혈압이나 혈당이 슬슬 올라가는데 본인은 모르는 분들이죠.

AI와 이 관점을 정리하고 나니, 자연스럽게 사람을 두 갈래로 나누게 됐습니다. 이미 진단받은 사람은 의료의 영역으로 넘기고, 아직 아닌 사람이 우리가 관리할 대상이라고요. 그리고 이 결정을 세 개의 작은 작업으로 쪼갰습니다. ① 진단받은 사람에게는 위험 예측과 리포트를 건너뛰기 ② 진단받은 사람 전용 화면 만들기 ③ 진단받은 사람 전용 챌린지(투석 일정 같은) 만들기.

💡 “우리가 정작 무엇을 해주는 서비스인가”를 한 줄로 정리하면, 흩어진 결정들이 한 방향으로 정렬됩니다. “우리는 진단이 아니라 선별을 한다”는 문장 하나가, 그날 모든 작업의 기준이 됐어요.

진단받은 사람에게는 점수 대신 안내를

모듈 ② 진단자 대시보드 진행해줘

진단받은 사람이 로그인하면, 위험도 그래프나 “앞으로 이렇게 하면 점수가 이만큼 좋아져요” 같은 시뮬레이션 위젯이 보일 이유가 없습니다. 그건 아직 진단 안 받은 사람을 위한 거니까요.

그래서 진단받은 사람의 대시보드(서비스의 첫 화면, 한눈에 상태를 보여주는 상황판)에서는 예측 관련 위젯을 다 숨기고, 의료 관리에 맞는 안내로 채웠습니다. 화면이 사용자 유형을 알아보고 알아서 갈래를 트는 거죠.

💡 “안 보여주는 것”도 설계입니다. 모두에게 모든 걸 보여주는 게 친절이 아니에요. 그 사람에게 필요 없는 정보를 덜어내는 게 더 나은 경험일 때가 많습니다.

화면이 따로 노는 버그 — 진단 입력 창구가 흩어져 있었다

ckd 진단에 체크하면 검진 이력 변경으로 챌린지가 안 변하네

여기서 이상한 버그가 튀어나왔습니다. 분명 “콩팥병 진단받았어요”에 체크했는데, 챌린지는 안 바뀌는 거예요. 진단받은 사람용 챌린지로 넘어가야 하는데 그대로였습니다.

AI와 차근차근 원인을 파봤습니다(무작정 고치지 않고 원인부터 찾는 방식으로요). 알고 보니 진단 여부를 입력하는 창구가 여러 군데 흩어져 있던 게 문제였어요. 한 곳에서 고친 정보를 다른 기능이 안 보고 있었던 거죠.

그리고 ckd 진단에 대한 체크는 문진표에서 하도록 해줘

그래서 입력 창구를 딱 하나로 모았습니다. 진단 여부는 문진표(설문지처럼 건강 정보를 묻는 항목)에서만 입력하고, 나머지 기능은 전부 그 한 곳을 바라보게요. 한 곳만 보면 되니, 고친 정보가 모든 화면에 빠짐없이 퍼졌습니다.

💡 같은 정보를 여러 곳에서 입력받으면, 언젠가 서로 어긋납니다. 중요한 정보일수록 “여기서만 입력한다”는 단 하나의 창구를 정하세요. 엑셀이든 서류든 똑같습니다.

화면을 두 덩어리로 — 챌린지와 기록

챌린지 수정이 필요
ckd 진단자 기준
챌린지와 나머지 기록 챌린지로 묶어줘
챌린지는 그대로
내 기록 챌린지는 하나로 묶어서 순서대로 아래로 나열
두 분류로만 나눠서 ui 수정

진단받은 사람의 챌린지 화면이 너무 잘게 쪼개져 있었습니다. 탭이 일곱 개나 됐어요. 이걸 두 덩어리로 합치기로 했습니다. 하나는 ‘챌린지’, 하나는 ‘기록’으로요.

[화면 캡처] 2개의 탭이 반반씩 차지하도록 크기를 키워줘 디자인을 바꿔도 좋고

탭 두 개가 화면을 반반씩 차지하도록 키우고, 기록 쪽에는 수분·체중·수면·감정·운동 같은 항목을 위에서 아래로 죽 나열했습니다.

그리고 ckd 진단자 챌린지 ui를 ckd 비진단자 챌린지에도 동일하게 적용해줘 ui 양식 통일

그리고 진단받은 사람용으로 다듬은 이 모양을, 아직 진단 안 받은 사람의 챌린지에도 똑같이 입혔습니다. 사람은 두 갈래로 나뉘어도, 화면을 다루는 방식은 하나로 통일한 거죠. 그래야 나중에 한 군데만 고쳐도 양쪽이 같이 좋아지니까요.

💡 유형은 나누되, 만드는 틀은 하나로 두세요. 진단자와 비진단자는 내용이 다르지만 화면 골격은 같게 했습니다. 갈래마다 따로 만들면 나중에 두 배로 고생합니다.

챗봇이 “방금 고친 걸” 모르던 진짜 이유

머지 완료했고
RAG에도 ckd 진단 비진단에 나눠서 입력이 되는지 확인해주고
내가 방금 챗봇을 시도해 보면 문진표 수정을 통해 ckd 진단 비진단을 변경하고 물어봤는데 구별하지 못하는 것 같아
문진표의 수정사항이 반영이 되지 않는 것 같은데 확인해줘

이게 그날의 가장 골치 아픈 버그였습니다. 문진표에서 “진단받았어요”로 바꾸고 챗봇에게 물어보니, 챗봇이 그걸 모르는 거예요. 바뀌기 전 정보로 대답했습니다.

원인을 파보니 의외로 단순하면서 무서운 문제였어요. 챗봇은 “가장 최근 문진표”를 가져와서 답하는데, 같은 날 두 번 고치면 둘 중 어느 게 최신인지 못 가렸던 겁니다. 날짜만 보고 골랐거든요. 같은 날이면 날짜가 같으니까요.

해결은 날짜에 더해 “그중에서도 나중에 저장된 것”까지 보도록 기준을 하나 더 얹는 거였습니다. 그 한 줄을 챗봇·리포트·챌린지 등 다섯 군데에 똑같이 맞춰주니, 방금 고친 정보가 곧바로 챗봇에 반영됐어요.

이왕 챗봇을 손보는 김에 사용성도 같이 다듬었습니다. 답변이 오래 걸려서 화면이 멈춘 것처럼 보이던 걸, “생성 중 · 몇 초” 카운트를 띄우고 마지막 답변을 한 글자씩 타이핑하듯 보여줬어요. 읽기 쉽게 서식도 입히고, 맨 아래 면책(우리 답변은 참고용이고 의학적 판단은 의사에게 받으라는 책임 한계 안내) 문구의 모양도 정돈했고요.

아니 다시 생성 버튼 기능을 지우자
리포트의 목적과 맞지 않는 것 같아 내용을 보고 다시 생성한다는 것은

작은 결정도 하나 있었습니다. 리포트에 ‘다시 생성’ 버튼이 있었는데, 가만 보니 리포트의 목적과 안 맞았어요. 리포트는 검진을 바탕으로 한 번 만드는 결과물인데, 내용을 보고 마음에 안 든다고 다시 뽑는 건 결이 다르죠. 그래서 버튼을 지우고 ‘복사’ 기능만 남겼습니다.

💡 숨은 버그는 보통 “흔할 때는 멀쩡한데 가장자리에서 터지는” 경우입니다. 같은 날 두 번 고치는 건 흔치 않지만, 막상 일어나면 사용자는 “왜 안 되지?”만 반복합니다. 데이터가 멀쩡한지부터 확인하고, 화면이 안 보이는 건지 데이터가 틀린 건지 먼저 갈라보세요.

✅ 결과 (After)

Before vs After

항목	Before	After
서비스 대상	모두를 똑같이 대함	진단자/비진단자 분기 (의료 영역 vs 관리 대상)
진단 입력	여러 곳에 흩어짐 → 화면 따로 놈	문진표 한 곳으로 통일
챌린지 화면	탭 7개로 쪼개짐	2탭으로 통합, 진단자·비진단자 같은 틀
챗봇 최신성	같은 날 두 번 고치면 옛 정보	항상 최신 문진 반영 (5곳 정합)

결과물

진단받은 사람과 아닌 사람을 가르는 서비스 분기(화면·챌린지·예측)
진단 입력을 문진표 하나로 모은 단일 창구
두 덩어리로 통일한 챌린지 화면
최신 정보를 놓치지 않는 챗봇과, 읽기 편해진 답변

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

본질을 한 줄로 먼저 정리: “우리는 진단이 아니라 선별을 한다”가 모든 작업의 기준이 됨
버그는 원인부터: 무작정 고치지 않고, 진단 입력이 흩어진 구조 자체를 찾아 뿌리를 뽑음
유형은 나누되 틀은 하나로: 진단자·비진단자 내용은 달라도 화면 골격은 통일

이렇게 하면 안 돼요

같은 정보를 여러 곳에서 입력받기: 언젠가 서로 어긋남. 창구는 하나로
“안 보인다”를 바로 코드 탓으로 몰기: 데이터가 멀쩡한지부터 확인. 표시 문제일 때가 많음
목적에 안 맞는 기능을 그냥 두기: ‘다시 생성’ 버튼처럼, 안 맞으면 과감히 덜어냄

🌍 다른 업무에 적용한다면?

“대상을 유형별로 다르게 대한다”는 건 어디에나 통합니다. 고객을 신규와 기존으로 나누고, 회원을 무료와 유료로 나누는 일처럼요. 이때 핵심은 두 가지예요. 먼저 “우리가 이 사람에게 정작 뭘 해주는가”를 한 줄로 정리하는 것, 그리고 유형을 나누더라도 기준 정보는 한 곳에서만 입력받는 것. 정보가 흩어지면 유형 구분 자체가 어긋나기 시작하니까요.

🚀 앞으로의 계획

이렇게 서비스의 큰 뼈대를 정리하고 나니, 정작 실제 서비스에서는 자잘한 버그가 줄줄이 터지기 시작했습니다. 챌린지가 중복으로 보이고, 진단군이 화면에 안 잡히고, 관리자 화면에 민감한 정보가 그대로 노출되고. 게다가 화면 디자인이 영 마음에 안 들어서, 하루 날을 잡고 서비스 전체의 옷을 통째로 갈아입히는 작업까지 하게 됩니다. 다음 편에서는 실서비스를 직접 써보며 터진 버그들을 잡고, 디자인을 한 번에 바꾼 하루를 풀어볼게요.

📋 재사용 가능한 프롬프트

프롬프트 1: 서비스의 본질로 대상 가르기

우리 서비스를 [유형 A]와 [유형 B]로 먼저 가르려고 해. 가르기 전에, 우리가 각 유형에게 정작 무엇을 해주는 서비스인지 한 줄로 정리해줘. 그 정리에 따라 화면·기능이 어떻게 달라져야 하는지도 짚어줘.

프롬프트 2: 흩어진 입력 창구 하나로 모으기

[중요한 정보]를 입력하는 곳이 여러 군데로 흩어진 것 같아. 어디서 입력받는지 전부 찾아주고, 한 곳에서만 입력받도록 모으는 방향을 정리해줘. 나머지 기능은 전부 그 한 곳을 바라보게.

프롬프트 3: “방금 고친 게 반영 안 됨” 버그 추적

[방금 고친 정보]가 다른 화면에 반영이 안 돼. 무작정 고치지 말고, 데이터 자체는 멀쩡한지부터 확인해줘. 화면이 안 보이는 건지 데이터가 틀린 건지 먼저 갈라서 원인을 짚어줘.

📌 「AI 헬스케어 파이널 프로젝트」 연재 20편입니다. 다음 막에서 또 이어집니다.