23차시. Modular RAG 개념
8. 흔한 오해 걷어내기
출처: 원본 PDF 23차시_ModularRAG개념.pdf 15쪽 · 쪽 그림 15쪽
| 오해 | 사실 |
|---|---|
| 모듈로 나누면 성능이 자동으로 좋아진다 | 성능이 아니라 '개선 가능성'이 좋아집니다. 측정과 튜닝은 따로 해야 합니다 |
| 모듈을 잘게 나눌수록 좋다 | 지나치게 쪼개면 State가 복잡해집니다. 3~6개가실무의 적정선입니다 |
| Verifier가 답변도 고쳐주면 좋겠다 | 판정과 수정은 분리합니다. 그래야 판정 기준을 따로 개선할 수 있습니다 |
| 모듈이 많을수록 정교한 시스템이다 | 필요 없는 모듈은 비용과 지연만 늘립니다 |
| Modular RAG는 특정 라이브러리 이름이다 | 설계 패턴입니다. LangGraph 없이도 같은 원리로 만들 수 있습니다 |
8-1) 모듈화의 비용도 있습니다
⚠️ 공짜가 아닙니다
① 코드가 길어집니다
15차시 rag.py 40줄 → 3부에서 파일 6개
② 응답이 조금 느려집니다
검증 노드가 LLM을 한 번 더 부릅니다
③ 비용이 늘어납니다
재시도가 있으면 호출 횟수가 늘어납니다
그래서 판단이 필요합니다.
· 사내 FAQ 챗봇 → 22차시 구조로 충분할 수 있습니다
· 법률·의료 문서 QA → 검증이 반드시 필요합니다
용도에 맞게 고르는 것도 설계 능력입니다.