동작한다 ≠ 충분하다 — RAG를 더 똑똑한 방식으로 갈아엎고 '청킹 무용론'까지 따져본 하루

📚 「AI 헬스케어 파이널 프로젝트」 연재 8편입니다. (7편: AI가 의료 질문을 거절했는데, 알고 보니 그게 정답이었다)

📝 한줄 요약

지난 편에서 의료 RAG 챗봇의 첫 PoC가 돌아갔습니다. 그런데 “돌아간다”에 만족하지 않고, 더 정확한 답을 위해 RAG의 뼈대를 더 똑똑한 방식(LangGraph)으로 갈아엎었습니다. 여기서 RAG는 “자료를 찾아 근거로 답하는 방식”입니다. 그 과정에서 “요즘 AI는 똑똑해져서 청킹(긴 문서를 잘게 나눠 저장하는 것)이 필요 없다”는 유행하는 주장도 직접 따져봤고, 챗봇이 실제로 살아갈 집(인프라)까지 세웠습니다.

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

결단: PoC가 이미 돌아갔지만, 더 정확한 방식이 보여서 뼈대를 갈아엎음 (“동작한다 ≠ 충분하다”)
신중함: 큰 변경이라 작은 PoC로 먼저 검증하고 본 작업에 들어감
판단력: “청킹은 이제 필요 없다”는 유행 주장을 그대로 믿지 않고, 우리 맥락에서 직접 따져 “여전히 필요”라고 결론
준비: 챗봇이 살 집(벡터 DB·관찰 도구)을 Docker로 미리 세움
핵심 교훈: 통설·유행을 맹신하지 말고 “우리 경우엔 어떤가?”를 AI와 따져보라

🎯 이런 분들께 도움돼요

“일단 되니까 그냥 두자” vs “더 나은 방식으로 다시” 사이에서 고민하는 분
AI·기술 분야의 유행하는 주장을 어디까지 믿어야 할지 헷갈리는 분
큰 변경을 안전하게 적용하는 방법이 궁금한 분
RAG·AI 챗봇을 실제 서비스로 준비하는 분

😫 문제 상황 (Before)

지난 편에서 RAG 챗봇의 첫 PoC(개념 증명)가 잘 돌아갔습니다. 보통은 여기서 “오, 되네!” 하고 다음으로 넘어가죠. 그런데 자료를 더 보다 보니, 검색 결과를 스스로 점검하고 교정하는 더 똑똑한 방식이 있다는 걸 알게 됐습니다.

고민이 됐습니다. “이미 돌아가는데, 굳이 갈아엎어야 하나?” 동시에 커뮤니티에선 “요즘 AI는 한 번에 읽는 양(컨텍스트)이 커져서 자료를 잘게 쪼개는 청킹은 이제 필요 없다”는 주장도 보였습니다. 이게 맞다면 제 작업 방향이 통째로 바뀔 수도 있었어요.

그래서 이번 편의 숙제는 두 가지였습니다. 더 나은 방식으로 갈아엎을 것인가, 그리고 ‘청킹 무용론’이 우리에게도 맞는가를 따지는 일이었죠.

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus
특이사항: 더 나은 구조를 함께 설계하는 아키텍트이자, 유행하는 주장을 우리 맥락에서 검증해주는 토론 상대로 활용

🔧 작업 과정

1) “동작한다”에 안주하지 않고 — 더 똑똑한 방식으로 갈아엎기

PoC가 돌아갔지만, 더 정확한 방식이 보였습니다. 그래서 결단했어요.

변경사항이 있어. RAG의 시스템을 LangChain에서 LangGraph로 변경하려고 해
(자료 참고) 이 이미지의 구조와 비교를 해줘

쉽게 말하면, 챗봇이 “검색한 자료가 질문에 맞나?”를 스스로 점검하고 부족하면 다시 찾는 구조(자기교정 방식)로 뼈대를 바꾼 겁니다. 답이 더 정확해지니까요. “돌아간다”와 “충분하다”는 다르다 — 이게 이날의 첫 번째 교훈이었습니다.

💡 이미 돌아가는 결과물을 더 나은 방식으로 다시 짤지는, “지금이 바꾸기 가장 싼 시점인가”로 판단하면 됩니다. 초반일수록 전환 비용이 쌉니다.

2) 큰 변경은 작게 먼저 — PoC로 검증

뼈대를 통째로 바꾸는 건 위험한 일이죠. 그래서 바로 본 작업에 들어가지 않았습니다.

새로 변경된 사항을 PoC로 테스트 해봐야하지 않을까?

작은 PoC를 먼저 만들어 새 방식이 실제로 흐름이 통하는지 확인한 뒤에 진행했습니다.

💡 큰 변경일수록 작게 먼저 시도하세요. 핵심 흐름만 빠르게 확인하면, 통째로 바꾼 뒤에 터지는 사고를 막을 수 있습니다.

3) ‘청킹 무용론’을 그대로 믿지 않고 직접 따지기

이제 두 번째 숙제. 유행하는 주장을 그대로 받아들이지 않고 물었습니다.

질문: 요즘은 AI의 컨텍스트 윈도우가 커졌기 때문에
청크(자료 쪼개기) 과정이 의미 없다는 의견이 있는데 어떻게 생각해?

AI와 따져보니, 우리 경우엔 여전히 청킹이 필요했습니다. 자료를 통째로 넣으면 ① 비용이 커지고 ② 엉뚱한 부분까지 섞여 답이 흐려지고 ③ “정확히 어느 근거에서 나온 답인지” 대기 어려웠거든요(의료에선 치명적입니다). 그래서 오히려 “작게 찾아서, 큰 맥락으로 답하는” 더 정교한 방식(Parent-Child)을 다음 단계에 미리 반영했습니다.

💡 유행하는 주장도 “우리 경우엔 어떤가?”를 따져봐야 합니다. “남들이 그렇다더라”는 의사결정의 근거가 아닙니다.

4) 챗봇이 살 집을 세우다 — 인프라 준비

코드를 본격적으로 짜기 전에, 챗봇이 실제로 돌아갈 환경을 먼저 준비했습니다.

RAG Phase 2 인프라부터 진행해줘

AI가 벡터 DB(자료를 의미로 검색하는 저장소)와 관찰 도구(챗봇이 일을 잘하는지 지켜보는 장치)를 Docker로 묶어 세팅했습니다. “집을 먼저 짓고 가구를 들이는” 순서로, 나중에 코드를 붙이기 쉽게요.

💡 코드를 짜기 전에 그 코드가 돌아갈 환경부터 세우면, 뒤따르는 작업이 한결 매끄럽습니다.

5) 다음 단계 재료 모으기 — 인덱싱 자료 탐색

마지막으로, 챗봇이 근거로 삼을 신뢰할 의료 자료를 찾기 시작했습니다.

인덱싱 전에 인덱싱에 사용할 자료를 찾아봐줘
우리는 생활습관 개선이 목표인데 더 자료가 없을까?

신장학회·질병관리청 가이드라인을 탐색하며, “생활습관 개선”이라는 우리 목적에 맞는 자료를 골라뒀습니다. 이 자료 수집은 다음 편에서 본격적으로 이어집니다.

💡 AI에게 자료를 찾게 할 때는 “우리 목적”을 분명히 박아주세요. 목적을 주면 양으로 채우는 대신 맞는 것만 골라옵니다.

✅ 결과 (After)

Before vs After

항목	Before	After
RAG 뼈대	PoC 수준 (동작은 함)	더 정확한 자기교정 방식(LangGraph)으로 전환
청킹 방향	”무용론, 따라야 하나?” 흔들림	우리 맥락에서 “필요” 확정 + 더 정교한 전략 채택
인프라	없음	벡터 DB·관찰 도구 Docker 세팅
변경 안전성	—	큰 변경을 PoC로 먼저 검증

결과물

LangGraph 기반 RAG 뼈대(자기교정) + 검증 PoC
Phase 2 인프라(벡터 DB·관찰 도구 Docker)
RAG 학습카드·로드맵 갱신 + 인덱싱 자료 후보

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

효과적이었던 것

“동작한다”에 안주하지 마라 — 더 나은 방식이 보이면, AI와 함께 갈아엎는 비용을 따져보세요. 초반일수록 바꾸기 쉽습니다.
유행·통설은 “우리 경우엔?”으로 검증하라 — “요즘은 X가 필요 없대”를 그대로 믿지 말고, 내 맥락에서 AI와 따져보세요.
큰 변경은 작은 PoC로 먼저 — 통째로 바꾸기 전, 작게 시도해 흐름을 확인하면 사고를 막습니다.
코드 전에 환경(집)부터 — 도구가 돌아갈 인프라를 먼저 세우면, 나중 작업이 매끄럽습니다.

이렇게 하면 안 돼요

“되니까 그냥 두자”로 안주하지 마세요 — 특히 정확도가 중요한 분야(의료 등)에선, 동작이 곧 충분함은 아닙니다.
남의 주장을 근거 없이 따르지 마세요 — “다들 그렇다더라”는 의사결정 근거가 될 수 없습니다.

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

도구·방식 선택: “이 도구가 대세래”를 따르기 전에, “우리 규모·목적엔 정말 맞나?”를 AI와 따져보세요.
개선 vs 안주: 이미 돌아가는 프로세스라도 더 나은 방식이 보이면 ‘바꾸는 비용 vs 얻는 이득’을 계산해보세요. 초기일수록 전환이 쌉니다.

🚀 앞으로의 계획

뼈대도 더 똑똑해졌고, 챗봇이 살 집도 세웠습니다. 이제 필요한 건 챗봇이 근거로 삼을 좋은 자료입니다.

다음 편(9편)에서는 챗봇이 공부할 의료 자료를 본격적으로 모읍니다. 신장학회 진료지침부터 시작해 금연 자료 41건을 직접 긁어옵니다. 그리고 마침 새 AI 모델(Opus 4.8)이 나와서, 그동안의 프로젝트 전체를 ultracode로 다시 점검하며 숨은 문제를 손보는 이야기도 함께 풀어볼게요. 좋은 답은 좋은 자료에서 나오니까요.

📋 재사용 가능한 프롬프트

프롬프트 1: ‘더 나은 방식으로 전환할지’ 판단

지금 [현재 방식]으로 [작업]이 돌아가고 있어. 그런데 [대안 방식]이 더 낫다는 이야기를 들었어. 두 방식의 장단점을 우리 상황([규모·목적·제약]) 기준으로 비교하고, 지금 갈아엎는 게 맞는지(전환 비용 vs 이득)를 판단해줘. 바꾼다면 안전한 전환 순서도 알려줘.

프롬프트 2: 유행하는 주장을 내 맥락에서 검증

“[유행하는 주장, 예: 요즘은 청킹이 필요 없다]“는 의견을 봤어. 이게 우리 경우([우리 상황·목적])에도 맞는지 따져줘. 일반론이 아니라, 우리 맥락에서 이 주장이 성립하는 조건과 성립하지 않는 조건을 구분해서 알려줘.

프롬프트 3: 큰 변경 전 작은 검증(PoC)

[큰 변경]을 적용하기 전에, 작은 PoC로 먼저 검증하고 싶어. 핵심 흐름만 최소한으로 만들어서, 이 변경이 실제로 통하는지 빠르게 확인할 수 있는 PoC를 만들어줘.

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