LLM 챗봇 개발, 왜 우리는 RAG를 선택했는가?

“AI를 직접 만들지 않아도, 잘 활용할 줄 아는 개발자가 되어야 한다.”

💡 마인드셋: 개발자의 AI 활용 전략

기존 프로그래밍 지식 + AI 기술 융합
단순 기능 구현이 아닌 문제 해결 중심 사고
현재 내 업무에 어떤 AI 기술이 실질적인 도구가 될지 판단할 수 있는 역량이 중요

🔍 RAG 도입 배경과 필요성

📌 LLM만으로는 한계가 있다

과제	설명
모델 직접 튜닝	고비용(GPU), 높은 기술 난이도
OpenAI API 사용	데이터 보안/최신성 이슈
Agent 최적화	Agent에 최신 정보 반영 어려움

✅ RAG의 핵심 장점

튜닝 없이 정보 반영 가능
- 검색 결과를 기반으로 답변 생성
- 모델 자체를 변경하지 않아도 최신 정보 활용 가능
즉시 반영 가능한 최신 정보
- RAG는 실시간 DB 연결로 정보 갱신이 자유로움
보안성과 유지보수의 용이함
- 사내 데이터 활용 시 API 의존도 감소
- 도메인 기반 운영 가능

📊 RAG vs 파인튜닝 비교

더 자세한 내용은 다음RAG vs. Fine-Tuning의 내용을 확인하도록 한다.

항목	RAG 방식	파인튜닝
적용 방식	검색 + 생성	모델 재학습
정보 반영 속도	즉시 가능	재학습 필요
비용	저렴	고비용 (GPU)
기술 난이도	낮음	AI 전문성 요구

결론: RAG는 비용 효율성과 운영 측면에서 매우 유리하다

🛠️ 회사 내 RAG 도입 과정

📌 1단계: BERT 파인튜닝 시도 (2023년)

Llama, GPT 로컬 모델 → 비용 문제로 실패
BERT 기반 지식 검색 → 답변 품질 저하
주요 이슈:
- 데이터 업데이트 어려움
- GPU 부족
- 파인튜닝 난이도

📌 2단계: RAG 전환 및 구축 (2024년)

3~4개월 RAG 학습 및 프로토타입 제작
도메인 특화 데이터로 테스트 후 도입 확정

⚙️ 운영 환경 구성

구성 요소	기술
LLM 실행	Ollama → vLLM 전환 진행 중
배포 환경	Kubernetes
인프라	T4 GPU 최적화
VectorDB	OpenSearch
상태 관리	Redis (멀티턴 대화용)
사용자 데이터 분석	MongoDB
Prompt 템플릿 관리	MariaDB

Ollama vs vLLM

Ollama는 경량 로컬 실행에 유리하지만, 대규모 요청에서는 응답 지연 발생.
vLLM은 병렬 처리 및 대규모 추론에 최적화되어 있어 빠름.

⚠️ 시행착오 & 해결 전략

문제	해결책
클러스터 운영 경험 부족	플랫폼 전문가 협업
상용 VectorDB 라이선스 문제	OpenSearch 사용
비정형 PDF 데이터	Markdown → JSON 변환

🧠 RAG 적용 시 필수 고려 사항

🎯 도메인 정의

법률 vs IT 문서 → 데이터 전처리 및 포맷 완전히 다름
목적에 따라 문서 chunking 방식도 달라짐

📐 데이터 포맷 설계

검색 정확도는 데이터 포맷에 달려 있다
JSON 기반 구조 + 메타 정보 필터링 + 문서 구분자 추가
좋은 포맷 → Prompt Engineering 효율 향상

🔍 최신 동향 파악

핵심 논문: “RAG: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”
리소스:
- Hugging Face Docs
- LangChain 공식 문서
- Teddy Note (실무 예제)

🛤️ AI 개발자 로드맵

🧱 1단계: 기초 역량

운영체제, 네트워크, DB
Python 숙련
실전 프로젝트 경험

🤖 2단계: AI 기술 스택

LangChain, vLLM, Ollama 이해
VectorDB 구조 (OpenSearch, Weaviate)
문서 전처리/인덱싱 이해

⚙️ 3단계: 운영환경 이해

Docker, Kubernetes 클러스터 운영
GPU 자원 관리 및 분산 서빙

🧩 결론: RAG은 선택이 아닌 전략이다

파인튜닝 없이도 실전 챗봇 구축 가능
데이터 보안, 도메인 대응, 최신성 확보에 매우 유리
AI 도입 초기부터 도메인 설계 + 포맷 설계 + 운영 전략을 함께 고민해야 성공 가능성이 높아진다