리포트 여는 데 25초? 7밀리초로 줄였다 — '미리 만들어두기'의 힘

📚 「AI 헬스케어 파이널 프로젝트」 연재 16편입니다. (15편: 데이터에 구멍이 있으면 AI도 거짓말을 한다)

📝 한줄 요약

건강 분석 보고서(리포트)를 열 때마다 무려 25초나 걸렸습니다. 디자인을 손대기 전에 “왜 이렇게 느린지”부터 측정했더니, 범인은 보고서를 열 때마다 AI 가이드를 그 자리에서 새로 만드는 일이었습니다. 그래서 가이드를 미리 만들어두는 방식으로 바꿨더니 25초가 7밀리초로 줄었습니다. 내친김에 챗봇이 답을 한 글자씩 흘려보내게 고치고, 손으로 그리던 그래프도 전문 차트로 갈아끼웠습니다.

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

느릴 땐 추측하지 말고 측정부터. “어디가 느린지”를 숫자로 찍어 범인을 특정
범인은 보고서를 열 때마다 매번 새로 만들던 AI 가이드(25초의 거의 전부)
해법은 미리 만들어두기(캐싱): 분석이 끝나는 순간 뒤에서 가이드를 만들어 저장 → 열 땐 읽기만
결과는 25초 → 7밀리초. 같은 보고서를 다시 열어도 즉시 뜸
덤으로 챗봇 답을 한 글자씩 흘려보내(스트리밍) 첫 글자가 1.5초 만에 뜨게 개선
손코딩 그래프를 전문 차트로 교체(부드러운 곡선·구간 색칠)

🎯 이런 분들께 도움돼요

만든 건 되는데 느려서 답답한 분
“어디가 느린지” 감으로 찍지 말고 제대로 찾고 싶은 분
같은 계산을 매번 반복하느라 시간 버리는 작업이 있는 분

😫 문제 상황 (Before)

앞선 작업들로 우리 서비스는 사용자의 건강 데이터를 받아 콩팥병 위험을 예측하고, “왜 그런 점수가 나왔는지”까지 보여주는 보고서를 만들 수 있게 됐습니다. 그런데 막상 그 보고서를 열어보니 너무 느렸습니다. 버튼을 누르고 화면이 다 뜰 때까지 25초. 짧은 것 같아도, 빈 화면을 25초 보고 있으면 “이거 고장 났나” 싶어집니다.

원래 그날 계획은 보고서 화면을 더 예쁘게 다듬는 거였어요. 그런데 생각해보니 순서가 틀렸더군요. 빈 화면이 25초씩 뜨는데 예쁜 게 무슨 소용일까요. 디자인보다 속도가 먼저였습니다.

리포트 UI/UX 개선 전에, 뜨는 속도 병목부터 확인하자

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus
특이사항: “어디가 느린지” 측정으로 범인을 특정한 뒤, 미리 만들어두는 방식으로 근본 해결

🔧 작업 과정

”느리다”는 느낌을, “어디서 25초”라는 숫자로 바꾸기

느릴 때 가장 흔한 실수는 “아마 여기가 느릴 거야” 하고 감으로 찍는 겁니다. 저는 대신 화면이 뜨는 과정을 둘로 쪼개서 각각 시간을 재봤습니다.

보고서 목록을 불러오는 단계 → 눈 깜짝할 사이(몇 밀리초)
보고서 본문을 불러오는 단계 → 25초 전부

범인이 또렷해졌습니다. 그리고 그 25초 안을 더 들여다보니, 진짜 범인은 AI 가이드였어요. 보고서에는 “이 결과를 보고 뭘 하면 좋을지” 알려주는 AI 작성 가이드가 들어가는데, 이걸 보고서를 열 때마다 그 자리에서 새로 쓰고 있었던 겁니다. AI가 자료를 뒤지고 문장을 만드는 데 25초가 걸렸고, 그동안 사용자는 그냥 기다린 거죠.

더 어이없던 건, 같은 보고서를 두 번째 열어도 또 25초라는 점이었습니다. 분명 방금 만든 글인데, 저장해두질 않아서 매번 처음부터 다시 쓰고 있었어요.

💡 느릴 땐 추측하지 말고 측정하세요. “여기가 느릴 것 같다”는 자주 틀립니다. 과정을 잘게 쪼개 시간을 재면 범인은 대개 한 군데에 숨어 있습니다.

해법은 단순했다 — “미리 만들어두기”

범인을 알고 나니 답은 의외로 단순했습니다. 열 때마다 만들지 말고, 미리 만들어두면 되잖아?

마침 우리 서비스에는 비슷한 사례가 이미 있었습니다. “왜 이 점수가 나왔는지” 분석하는 다른 계산은, 예측이 끝나는 그 순간 뒤에서 미리 계산해 저장해두고 있었거든요. 그래서 보고서를 열 때는 그냥 꺼내 보여주기만 하면 됐죠. AI 가이드도 똑같이 만들면 됐습니다.

비유하자면 이래요. 손님이 올 때마다 빵을 처음부터 굽는 빵집과, 아침에 미리 구워두고 손님이 오면 건네주기만 하는 빵집의 차이입니다. 손님 입장에선 후자가 비교도 안 되게 빠르죠. 이렇게 미리 만들어 저장해두는 걸 흔히 **캐싱(미리 만들어 저장해 두기)**이라고 부릅니다.

그래서 이렇게 바꿨습니다. 사용자의 예측이 끝나는 순간, 사용자가 안 보는 사이에 뒤에서 AI 가이드를 한 번 만들어 저장(캐싱)해둡니다. 그럼 나중에 보고서를 열 때는 만드는 게 아니라 저장된 걸 읽기만 하면 되죠.

결과는 놀라웠어요. 25초가 7밀리초가 됐습니다. 7밀리초는 1초의 140분의 1입니다. 누르자마자 뜨는 셈이죠. 같은 보고서를 몇 번을 다시 열어도 매번 바로 떴습니다.

💡 같은 계산을 반복하고 있다면, 한 번만 해서 저장해두세요. “미리 만들어두기”는 단순하지만 가장 강력한 속도 무기입니다. 손님이 올 때마다 굽지 말고, 미리 구워두세요.

챗봇도 한 글자씩 — 다 만들고 보여주지 말고 흘려보내기

속도 이야기가 나온 김에, 챗봇도 손봤습니다.

챗봇의 응답속도를 개선하기 위해 스트리밍 옵션을 적용해줘

기존 챗봇은 답을 완전히 다 만든 다음에 한꺼번에 보여줬습니다. 그래서 답이 길면 사용자는 6초에서 길게는 20초 넘게 빈 화면을 봐야 했죠. 사람이 말할 때 문장을 다 머릿속에 완성한 다음 한 번에 쏟아내는 게 아니라, 떠오르는 대로 이어 말하잖아요. 챗봇도 그렇게 만들기로 했습니다.

이렇게 글자가 만들어지는 대로 화면에 흘려보내는 방식을 스트리밍이라고 합니다. 영상이 다 내려받기 전에 재생되는 것과 같은 원리예요. 적용했더니 첫 글자가 1.5초 만에 떴습니다. 답이 다 끝나길 기다리지 않고, 타이핑되듯 읽으면서 기다릴 수 있게 된 거죠.

다만 까다로운 점이 하나 있었습니다. 우리 챗봇은 단순히 답을 그대로 내보내지 않습니다. 답을 만든 뒤 스스로 검토해서 다시 쓰기도 하고, 어려운 수치는 음식에 빗대 풀어주고, 마지막에 면책 문구도 붙입니다. 글자를 흘려보내는 도중에 답이 통째로 바뀌면 화면이 꼬일 수 있었죠. 그래서 “다시 쓰는 경우엔 화면을 한 번 비우고 새로 흘려보내기”, “최종본은 완성된 깔끔한 답으로 교체하기” 같은 규칙을 정해 안전장치를 살려뒀습니다.

💡 결과를 다 만들고 한꺼번에 주지 말고, 만들어지는 대로 보여주세요. 같은 시간이 걸려도 체감 속도가 완전히 달라집니다. 사람은 ‘얼마나 걸리느냐’보다 ‘뭐가 보이느냐’에 더 민감하니까요.

보고서 그래프, 손그림에서 전문 차트로

속도를 잡고 나니 이제 원래 하려던 디자인 차례였습니다.

리포트 ui/ux 개선 작업 진행하자

보고서에는 “내 수치가 같은 나이대 사람들과 비교해 어디쯤인지” 보여주는 그래프가 있었습니다. 처음엔 제가 직접 선을 긋듯 그린 그래프였는데, 솔직히 좀 투박했어요.

또래 집단은 정규분포 곡선으로 보여주고 내가 첨부한 이미지처럼

아니 그래프 퀄리티가 너무 낮다고

주니(저)의 솔직한 피드백이 날아왔죠. 그래서 손으로 그리던 그래프를 전문 차트 도구로 갈아끼웠습니다. 또래 비교는 매끄러운 종 모양 곡선으로 그리고, “낮음·보통·높음” 구간을 색으로 칠하고, 또래 평균선과 내 위치를 또렷하게 표시했습니다. 한눈에 “아, 내가 또래보다 이쪽에 있구나”가 읽히게요.

그런데 여기서 작은 함정도 있었습니다. 모든 그래프를 전문 차트로 바꾸려다, 막대그래프는 오히려 어색해졌어요.

아니 막대는 rechart 쓰지 말고 원래대로 되돌리자

그래서 곡선만 전문 차트로 두고, 막대는 원래 모양으로 되돌렸습니다. 새 도구가 항상 더 나은 건 아니더군요. 어울리는 자리에만 쓰는 게 맞았습니다.

💡 “고급 도구로 다 바꾸기”가 정답은 아닙니다. 곡선엔 곡선 도구가, 막대엔 단순한 게 더 나을 수 있어요. 바꿔보고 어색하면 되돌릴 줄 아는 것도 실력입니다.

✅ 결과 (After)

Before vs After

항목	Before	After
보고서 여는 속도	25초 (열 때마다 가이드 새로 생성)	7밀리초 (미리 만들어둔 걸 읽기만)
같은 보고서 재오픈	또 25초	즉시
챗봇 첫 응답	6~25초 빈 화면	첫 글자 1.5초 (흘려보내기)
또래 비교 그래프	손코딩 투박한 선	전문 차트(부드러운 곡선·구간 색칠)

결과물

예측이 끝나는 순간 뒤에서 미리 만들어두는 AI 가이드(보고서는 읽기만)
한 글자씩 흘려보내는 챗봇(첫 글자 1.5초)
전문 차트로 교체한 또래 비교 그래프

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

효과적이었던 것

측정부터: “느린 것 같다”가 아니라 과정을 쪼개 시간을 재서 범인을 특정
미리 만들어두기: 반복되는 계산은 한 번만 해서 저장 → 다음부터는 읽기만
체감 속도 챙기기: 같은 시간이라도 만들어지는 대로 보여주면 훨씬 빠르게 느껴짐

이렇게 하면 안 돼요

감으로 범인 찍기: “여기가 느릴 거야”는 자주 틀림. 측정 없이 고치면 엉뚱한 데 손댐
같은 계산 매번 반복: 방금 만든 결과를 안 저장해두면, 두 번째도 똑같이 느림
새 도구로 전부 갈아엎기: 어울리지 않으면 되돌릴 것. 도구는 자리에 맞게

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

“미리 만들어두기”는 코드가 아닌 일에도 그대로 통합니다. 매주 똑같이 만드는 보고서가 있다면, 매번 처음부터 쓰지 말고 틀을 미리 짜두고 숫자만 갈아끼우는 식이죠. 자주 받는 질문 답변을 정리해두는 것도, 발표 자료의 공통 슬라이드를 템플릿으로 빼두는 것도 같은 원리예요. “이거 매번 다시 만들고 있네?” 싶은 순간이 곧 미리 만들어둘 신호입니다.

그리고 무언가 느릴 땐, 답답하다고 아무 데나 손대지 말고 “정확히 어디서 시간을 쓰는지”부터 재보세요. 막연한 “느림”을 “여기서 25초”라는 구체적 숫자로 바꾸는 순간, 해결은 절반쯤 끝난 셈입니다.

🚀 앞으로의 계획

속도와 그래프를 손봤으니, 이제 보고서는 빠르고 보기 좋게 떴습니다. 그런데 우리 서비스의 진짜 핵심은 따로 있었어요. 바로 콩팥 건강을 꾸준히 챙기게 만드는 챌린지입니다. “물 마시기, 체중 재기” 같은 습관을 매일 실천하게 돕는 기능인데, 지금 구조로는 한계가 보였습니다. 그래서 다음 편에서는 챌린지를 게임처럼 통째로 다시 설계한 이야기를 풀어볼게요. 콩팥 건강을 어떻게 재미있게 만들 수 있을지, 그 고민의 기록입니다. 다음 막에서 이어집니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 디자인보다 속도 먼저

[내 화면/기능]을 예쁘게 다듬기 전에, 뜨는 속도부터 확인하자. 과정을 단계별로 쪼개서 어디에서 시간이 가장 많이 걸리는지 측정해줘.

프롬프트 2: 미리 만들어두기로 속도 개선

[반복되는 계산]이 열 때마다 매번 새로 실행돼서 느려. 미리 한 번만 만들어 저장해두고, 열 때는 읽기만 하도록 바꿔줘.

프롬프트 3: 결과를 흘려보내기

[답변/결과]를 다 만든 다음 한꺼번에 보여주지 말고, 만들어지는 대로 화면에 흘려보내서 첫 부분이 빨리 뜨게 해줘.

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