모르면 '왜?'만 물었다 — AI와 RAG 의료 챗봇 만들며 개념까지 배운 하루

📚 「AI 헬스케어 파이널 프로젝트」 연재 10편입니다. (9편: 좋은 답은 좋은 자료에서)

📝 한줄 요약

AI 코딩 도구(Claude Code)와 함께, 검증된 의료 가이드라인만 근거로 답하는 “지어내지 않는” 챗봇을 하루 만에 만들었습니다. 만드는 내내 모르는 개념은 “왜 필요한지”부터 물었더니, 결과물뿐 아니라 RAG·임베딩·벡터DB 같은 개념까지 손에 잡혔습니다. 지난 편에서 모은 자료를 이번엔 실제로 챗봇에 먹이고 답하게 만든 셈입니다.

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

목표: ChatGPT 같은 일반 AI가 의료 질문에 지어내는(환각) 위험을 없애기. 검증된 가이드라인만 근거로 답하는 RAG 챗봇을 만들자
깨달은 점: 모르는 개념은 그냥 따라 하지 말고 AI에게 “왜 필요한지” 물으면 개념이 진짜 이해된다
핵심 해법: 위험 질문을 먼저 거르고 → 검색하고 → 답을 만든 뒤 → 지어낸 내용은 없는지 검증하는 여러 단계를 거치게 했다
인상적 순간: 다 만든 줄 알았는데, AI가 “자동 테스트는 통과했지만 실제 표현은 위험하다”며 직접 잡아냄
교훈: 만들고 끝내지 말자. 직접 써봐야 진짜 문제(입력 버그 같은)가 보인다

🎯 이런 분들께 도움돼요

AI/ML 개발자로 전환 중이고, RAG나 LLM 앱을 직접 만들어보고 싶은 분
의료·법률처럼 “틀리면 안 되는” 분야에서 AI를 안전하게 쓰는 방법이 궁금한 분
AI 코딩 도구로 복잡한 시스템을 어떻게 단계적으로 쌓는지 궁금한 분

😫 문제 상황 (Before)

요즘 ChatGPT 같은 AI에게 건강 질문을 던지는 사람이 많습니다. 문제는 일반 AI가 그럴듯하지만 **사실이 아닌 답(환각)**을 자신 있게 말한다는 거예요. 일상 질문이면 괜찮습니다. 하지만 “만성콩팥병 환자가 단백질을 얼마나 먹어야 하나요?” 같은 의료 질문에서 지어낸 수치를 답하면 위험합니다.

그래서 목표를 분명히 했습니다. 검증된 의료 가이드라인(대한신장학회·국제 진료지침)에 실제로 적혀 있는 내용만 근거로 답하고, 근거가 없으면 함부로 답하지 않는 챗봇을 만들자. 이게 RAG라는 방식입니다. RAG는 “자료를 먼저 찾아 그 근거로 답하는 방식”인데, 말 그대로 신뢰할 자료에서 검색하고 그걸 근거로 답을 생성하는 구조예요.

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus 4.8
특이사항: 코드를 짜는 것만이 아니라, 모르는 개념을 설명받고 의료 안전을 검증받는 “대화 상대”로 활용

🔧 작업 과정

검색이 진짜 되네? — “되긴 되네”의 첫 증명

먼저 의료 가이드라인 문서를 잘게 나눴습니다. 그 조각을 컴퓨터가 이해하는 숫자(벡터)로 바꾸고, 검색 전용 데이터베이스에 차곡차곡 넣는 작업부터 했어요. 모듈을 만들고, 실제로 1만 3천여 개 조각을 넣은 뒤 첫 질문을 던졌습니다.

“만성콩팥병 환자의 단백질 권장량은?” — 그러자 가이드라인에 적힌 **“하루 0.8 g/kg”**을 출처(어느 문서 몇 페이지)와 함께 정확히 찾아왔습니다. 머릿속 설계가 실제로 도는 걸 처음 본 순간이라 “오, 진짜 되네” 싶었죠.

💡 막연하던 구조도 한 번 도는 걸 보면 확신이 생긴다. “될 것 같다”와 “실제로 됐다” 사이의 간격은 작은 스모크 테스트 하나로 메워집니다.

이걸 왜 해요? — 모르면 본질부터 물었다

작업 중 낯선 개념이 자꾸 나왔습니다. 그때마다 그냥 따라 하지 않고 “왜 필요한지”를 물었어요. 예를 들어 검색 서버를 띄우라는 단계에서 이렇게 물었습니다.

api키는 입력했어
그런데 docker compose up -d qdrant 이걸 왜 하는거지?

그랬더니 도서관 비유로 설명해줬습니다. “텍스트를 숫자로 바꾸는 일(임베딩)은 책 내용을 색인 카드로 만드는 것이고, 검색 서버(벡터DB)는 그 카드를 꽂아두고 빠르게 찾는 서랍장을 설치하는 것”이라고요. 본질을 이해하니 다음부터는 비슷한 개념이 나와도 헷갈리지 않았습니다.

💡 “왜 하는지”를 물으면 비유가 따라온다. 명령어를 외우는 대신 개념을 손에 쥐게 되고, 다음에 비슷한 게 나와도 막히지 않습니다.

챗봇의 ‘두뇌’ 만들기 — 검색에서 대화로

자료를 넣었으니 이제 사용자 질문을 받아 검색하고 답하는 “두뇌”가 필요했습니다. 단순히 검색 결과를 그대로 주는 게 아니에요. 위험 질문을 먼저 거르고(응급은 119, 자해는 1393 안내) → 검색하고 → 관련성이 약하면 질문을 스스로 고쳐 다시 검색하고 → 답을 만든 뒤 → 지어낸 내용은 없는지 검증하는 여러 단계를 거치게 했습니다. 의료 분야라 정확성이 중요해서, 일부러 검증 단계를 더 촘촘하게 넣었습니다.

💡 답을 잘 만드는 것만큼 “답을 의심하는 단계”가 중요하다. 위험한 분야일수록 생성보다 검증에 단계를 더 쓰는 게 안전합니다.

테스트는 통과했는데… — AI가 잡아낸 진짜 위험

거의 다 됐다고 생각하던 차에 코드 검토를 받아봤습니다. 그런데 의료 안전 관점의 검토에서 놀라운 지적이 나왔어요. **“고칼륨혈증으로 가슴이 두근거리는 환자가 ‘신장이 안 좋아서 그런가요?’ 하고 신장 챗봇에 먼저 묻는 건 매우 흔한데, 지금은 이게 응급 차단을 통과해버린다”**는 거였습니다.

게다가 자동 테스트는 통과했는데 실제로 돌려보니 “소변이 한 번도 안 나와요” 같은 진짜 사람 말투에서는 응급 감지가 빠지더라고요. 테스트 예문이 너무 깔끔했던 거죠. “자동 테스트는 통과해도 실제 표현은 다르다”는 걸 AI가 짚어줘서 위험 표현 패턴을 보강했습니다.

💡 자동 테스트의 깔끔한 예문이 실제 사람 말투를 가린다. 통과 = 안전이 아닙니다. 위험한 분야는 도메인 전문가의 눈으로 한 번 더 봐야 합니다.

직접 써보니 보였다 — 만들고 끝이 아니다

다 만든 뒤, 터미널에서 직접 써볼 수 있는 간단한 대화 도구를 만들어 질문을 던져봤습니다. 그런데 쓰다 보니 문제가 보였어요.

사용해보니 질문을 다시 쓰려고 백스페이스로 지우다보면 멈추는 오류가 있어

직접 써보지 않았으면 절대 몰랐을 버그였습니다. AI가 원인(한글 입력을 처리하는 라이브러리가 빠져 있던 것)을 진단해 바로 고쳐줬습니다. “만들고 끝”이 아니라 직접 써봐야 진짜 문제가 보인다는 걸 체감했죠.

💡 만든 사람은 자기 도구를 “예쁘게” 쓴다. 백스페이스로 지우다 멈추는 버그는 직접 손으로 써봐야만 드러납니다.

검색에 없으면 어떡하죠? — 단순 거절 대신 똑똑한 분기

직접 써보다 또 하나를 발견했습니다. 가이드라인에 없는 질문을 하면 그냥 “근거가 없습니다”로 끝나버리는 게 불친절했어요.

질문이 rag검색에 없더라도, ckd이외의 질문을 한다거나, 완전 다른 분야에 대해서
물어본다면 인터넷 검색이나 llm모델이 대답해주는 노드를 추가해야하지 않을까?
단순히 검색에 없습니다 라고 출력하기 보다는

다만 의료 분야라 “아무거나 답하면” 오히려 위험합니다. 그래서 AI에게 먼저 의료 안전을 검증받고, 질문을 유형별로 나눠 다르게 대응하게 했습니다. 의료 질문이면 “검증된 가이드라인은 아닌 일반 정보”라고 분명히 밝히며 답하고, 날씨·코딩 같은 비의료 질문이면 “저는 신장 건강 도우미예요”라고 안내하는 식이에요. 답변에 위험한 정보(약 이름·용량 같은)가 섞이면 아예 다른 답으로 바꾸는 안전장치까지 넣었습니다.

💡 “몰라요”와 “아무거나 답하기” 사이에 길이 있다. 질문 유형을 나누고 면책을 붙이면 친절함과 안전을 둘 다 챙길 수 있습니다.

✅ 결과 (After)

Before vs After

항목	Before	After
의료 답변 신뢰성	일반 AI는 지어낼 위험	검증된 가이드라인 근거 + 출처 표시
위험 질문	그대로 답할 수 있음	응급·자해·약물 질문 구조적으로 차단
검색에 없는 질문	”근거 없음” 단순 거절	유형별 분기(일반 정보+면책 / 안내)
나의 이해도	RAG가 막연한 개념	임베딩·벡터DB·검색 흐름을 손으로 이해

결과물

터미널에서 바로 써볼 수 있는 의료 RAG 챗봇이 완성됐습니다.

검증된 가이드라인을 근거로 정확히 답하고 출처를 함께 보여줌
응급·자해·약물 같은 위험 질문은 구조적으로 차단
검색에 없는 질문도 유형별로 안전하게 분기
만드는 과정에서 RAG·임베딩·벡터DB 개념을 직접 이해

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

효과적이었던 것

모르면 “왜 필요한지”부터 물어라 — 낯선 개념(docker·임베딩 같은)을 그냥 따라 하지 않고 본질을 물으면, 비유와 함께 설명해줘서 개념이 진짜 이해됩니다. 다음에 비슷한 게 나와도 헷갈리지 않아요.
만들고 꼭 직접 써봐라 — 자동 테스트가 다 통과해도, 직접 손으로 써보면 백스페이스 버그처럼 예상 못 한 문제가 보입니다. “쓰는 사람”의 눈으로 봐야 진짜 품질이 나옵니다.
위험한 분야는 도메인 관점으로도 검증받아라 — 코드가 깔끔한 것과 의료적으로 안전한 것은 다른 문제입니다. 의료 안전 관점의 검토가 “응급 환자가 챗봇에 먼저 묻는” 시나리오를 잡아준 게 결정적이었어요.

이렇게 하면 안 돼요

자동 테스트만 믿고 “다 됐다” 하지 않기 — 테스트 예문은 너무 깔끔해서 실제 사람 말투(“한 번도 안 나와요”)의 위험을 놓칠 수 있습니다.
의료처럼 위험한 분야에서 “검색에 없으면 AI가 아무거나 답하게” 두지 않기 — 친절함보다 안전이 먼저입니다. 답하더라도 “검증된 정보가 아님”을 분명히 밝혀야 합니다.

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

“검증된 자료만 근거로 답하는” 이 구조는 의료 말고도 쓸 데가 많습니다. 회사 내부 규정·매뉴얼만 근거로 답하는 사내 챗봇, 계약서·법령만 근거로 답하는 법률 도우미처럼 “아무 말이나 하면 안 되는” 모든 분야에 같은 원리를 적용할 수 있어요. 핵심은 “신뢰할 자료에서 먼저 찾고, 없으면 솔직히 밝히는” 태도입니다.

🚀 앞으로의 계획

이번엔 제가 직접 챗봇을 만들었지만, 다음엔 일을 나눠보려 합니다. AI 에이전트로 짜인 팀에게 챗봇을 실제 웹 서비스로 연결하는 통로(API)를 맡기는 거죠. 다음 편에선 그 과정에서 만난 “2단계 리뷰”가 어떻게 혼자서는 못 봤을 숨은 버그를 잡아냈는지 풀어보겠습니다. 만드는 손이 여럿이면 검증의 눈도 여럿이어야 한다는 이야기예요.

📋 재사용 가능한 프롬프트

프롬프트 1: 낯선 개념을 본질부터 이해하기

[낯선 개념/명령어]을 왜 하는지 본질적으로 설명해줘. 비유를 들어서, 이게 없으면 어떻게 되는지까지 알려줘.

[낯선 개념/명령어] 부분에 모르는 용어를 넣으세요. (예: “docker”, “임베딩”)

프롬프트 2: 위험한 분야의 안전성 검증받기

이 [기능]이 [도메인] 관점에서 안전한지 검증해줘. 어떤 위험이 빠져 있고, 어떤 안전장치가 꼭 필요한지 전문가 관점으로 짚어줘.

[기능]·[도메인]에 본인 상황을 넣으세요. (예: “검색 실패 시 답변 기능”, “의료”)

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