디에스 DevOps Lab

사내 문서로 RAG 챗봇을 만들어 돌려 보면 꼭 이런 순간이 옵니다. "작년 AKS 업그레이드 때 뭐가 문제였지?"라고 물었는데, 검색기가 엉뚱한 GKE 문서를 끌어오고, 모델은 그 문서를 근거로 자신 있게 틀린 답을 합니다. 검색이 틀렸다는 걸 아무도 확인하지 않았기 때문입니다. 지난 글에서 LangChain으로 30줄짜리 RAG를 만들었는데, 그건 "검색 → 프롬프트 → 생성"이 한 방향으로 흐르는 체인(Chain) 이었습니다. 이 구조는 한 번 틀리면 되돌릴 방법이 없습니다. 오늘은 그 한계를 LangGraph 로 푸는 이야기입니다. 검색 결과를 스스로 평가하고, 엉터리면 질문을 고쳐 다시 검색하고, 답변에 근거가 없으면 다시 쓰는 RAG. 요즘 에이전틱 RAG(Agentic RAG) 라고 부르는 그것을, 논문 이름으로는 CRAG(Corrective RAG)라고 부르는 패턴을 중심으로, 노드 6개짜리 그래프로 직접 만들어 봅니다. 단순 RAG가 틀리는 4가지 순간 체인 RAG의 문제는 성능이 아니라 구조 에 있습니다. 첫째, 검색 결과가 엉터리여도 그대로 답변합니다. 벡터 유사도 상위 4개를 가져왔을 뿐, 그게 질문과 정말 관련 있는지는 아무도 보지 않습니다. 둘째, 질문이 모호해도 다시 묻거나 고쳐 쓰지 않습니다. "그거 설정 어떻게 해?" 같은 질문은 검색 자체가 실패합니다. 셋째, 답변이 검색된 문서에 근거하고 있는지 확인하지 않습니다. 모델이 문서를 무시하고 자기 지식으로 답해도 막을 수 없습니다. 넷째, 그래서 한 번 틀리면 끝입니다. 재시도라는 개념이 없습니다. 지난 글에서 "청킹 튜닝, 하이브리드 검색, 리랭커를 붙이면 품질이 오른다"고 했는데, 그건 모두 검색을 더 잘하게 만드는 방법입니다. 그래도 검색은 실패합니다. 에이전틱 RAG는 접근이 다릅니다. 검색이 실패할 것을 전제하고, 실패를 감지해서 고치는 루프 를 넣습니다. LangChain은...

ChatGPT API 호출 한 줄로 "AI 기능 붙였다"고 말할 수 있던 시절은 끝났습니다. 내 회사 문서로 답하게 하고, 검색도 시키고, 계산기도 쓰게 하고, 대화 맥락까지 기억하게 하려면 그 사이를 이어 주는 배관 공사 가 필요합니다. 그 배관의 표준 도구가 바로 LangChain(랭체인) 입니다. 20년 가까이 SI와 클라우드 아키텍처를 하면서 RAG 파이프라인을 직접 만들어 본 입장에서, 랭체인이 정확히 무엇이고 언제 써야 하는지 한 편으로 정리합니다. LangChain이 뭔가요? 한 문장으로 LangChain은 LLM을 중심으로 애플리케이션을 조립하는 오픈소스 프레임워크 입니다. 2022년 10월 Harrison Chase가 공개했고, Python과 JavaScript/TypeScript 두 언어를 지원합니다. 핵심 아이디어는 단순합니다. 모델, 프롬프트, 외부 데이터, 도구, 메모리 같은 부품을 표준화된 인터페이스 로 감싸서 레고처럼 연결할 수 있게 하는 것입니다. 덕분에 OpenAI GPT로 만든 체인을 Anthropic Claude나 Google Gemini, 혹은 vLLM으로 띄운 로컬 Llama 모델로 바꿀 때 코드 한두 줄만 손대면 됩니다. 벡터 DB를 Chroma에서 pgvector로 옮길 때도 마찬가지입니다. 이 "교체 가능성"이 랭체인을 쓰는 가장 큰 이유입니다. 핵심 구성요소 5가지만 알면 전체가 보인다 ① Model — 채팅 모델(ChatOpenAI, ChatAnthropic 등)과 임베딩 모델을 같은 인터페이스로 다룹니다. 어떤 벤더든 invoke() 한 번으로 호출합니다. ② Prompt Template — 프롬프트를 코드에 하드코딩하지 않고 변수가 있는 템플릿으로 관리합니다. 시스템 메시지, 예시(few-shot), 대화 기록을 조합하기 쉽습니다. ③ Output Parser — 모델이 뱉은 텍스트를 JSON, Pydantic 객체, 리스트 등 프로그램이 쓸 수 있는...