RAG 시스템을 처음부터 구축한 개발자의 성공과 실패 — 실전에서 배운 것들

RAG를 직접 만들어본 개발자의 솔직한 후기

요즘 LLM(대규모 언어 모델)을 활용한 서비스를 만들려면 거의 필수적으로 마주치는 개념이 하나 있어요. 바로 RAG(Retrieval-Augmented Generation)인데요. RAG가 뭐냐면, AI가 답변을 생성할 때 외부 데이터베이스에서 관련 정보를 먼저 검색해서 가져온 다음, 그 정보를 바탕으로 답변을 만드는 방식이에요. 쉽게 말하면 "오픈북 시험"이라고 생각하면 돼요. AI가 자기 머릿속 지식만으로 답하는 게 아니라, 참고 자료를 찾아보고 답하는 거죠.

한 개발자가 RAG 시스템을 아예 처음(zero)부터 구축하면서 겪은 성공과 실패를 상세하게 공유했는데, 이론적인 설명이 아니라 실전 경험이라 배울 점이 정말 많아요.

왜 RAG가 필요한 걸까

ChatGPT 같은 LLM은 훈련 데이터에 포함된 정보만 알고 있어요. 그래서 우리 회사의 내부 문서, 최신 제품 정보, 특정 도메인의 전문 지식 같은 건 모르거든요. 이걸 해결하는 방법이 크게 두 가지인데, 하나는 파인튜닝(모델 자체를 재훈련하는 것)이고, 다른 하나가 RAG예요.

파인튜닝은 비용도 많이 들고 데이터가 바뀔 때마다 다시 해야 하는 반면, RAG는 검색 데이터베이스만 업데이트하면 되니까 훨씬 유연해요. 그래서 실무에서는 RAG를 먼저 시도하는 경우가 많아요.

구축 과정에서 배운 핵심 교훈들

이 개발자가 강조한 첫 번째 교훈은 "청킹(chunking)이 모든 것을 좌우한다"는 거예요. 청킹이 뭐냐면, 원본 문서를 AI가 처리할 수 있는 작은 조각으로 나누는 과정이에요. 예를 들어 100페이지짜리 매뉴얼이 있으면, 이걸 문단 단위나 섹션 단위로 쪼개는 거죠.

문제는 이걸 어떻게 쪼개느냐에 따라 검색 품질이 완전히 달라진다는 점이에요. 너무 잘게 쪼개면 맥락이 사라지고, 너무 크게 쪼개면 관련 없는 내용이 섞여 들어와요. 이 개발자는 처음에 고정 크기(예: 500토큰)로 단순하게 잘랐다가 품질이 안 나와서, 결국 문서의 구조(제목, 소제목, 문단)를 기반으로 의미 단위로 쪼개는 방식으로 바꿨더니 확 좋아졌다고 해요.

두 번째 교훈은 임베딩 모델 선택의 중요성이에요. 임베딩이 뭐냐면, 텍스트를 숫자 벡터(쉽게 말하면 좌표)로 변환하는 거예요. "서울 맛집"이라는 텍스트와 "강남 레스토랑 추천"이라는 텍스트가 의미적으로 비슷하다는 걸 컴퓨터가 알 수 있게 숫자로 바꿔주는 거죠. 이 벡터들 간의 거리를 계산해서 가장 관련 있는 문서 조각을 찾아오는 게 RAG의 검색 단계예요.

여기서 실패 경험이 나오는데, 범용 임베딩 모델을 그냥 갖다 쓰면 도메인 특화 용어가 많은 문서에서는 검색 정확도가 떨어진다는 거예요. 예를 들어 의료 문서에서 "MI"가 "심근경색(Myocardial Infarction)"인지 "머신 인텔리전스"인지를 범용 모델은 잘 구분 못하거든요.

세 번째는 하이브리드 검색의 위력이에요. 벡터 검색(의미 기반)만 쓰면 키워드가 정확히 매칭되어야 하는 경우를 놓치고, 키워드 검색(BM25 같은 전통적인 방식)만 쓰면 유의어나 문맥을 못 잡아요. 둘을 조합한 하이브리드 검색이 실무에서는 거의 항상 더 나은 결과를 줬다고 해요.

실패에서 얻은 인사이트

가장 큰 실패는 평가 체계 없이 개발을 시작한 것이었다고 해요. RAG 시스템은 파라미터를 하나 바꿀 때마다 전체 성능이 변하는데, "좋아졌는지 나빠졌는지"를 객관적으로 측정할 방법이 없으면 그냥 감으로 튜닝하게 되거든요. 나중에 평가 데이터셋(질문-정답 쌍)을 만들고 자동화된 평가 파이프라인을 구축한 뒤에야 개선 속도가 확 붙었다고 해요.

또 하나 흥미로운 실패는 "더 많은 컨텍스트가 항상 좋은 건 아니다"는 발견이에요. 검색 결과를 많이 넣어주면 AI가 더 잘 답할 거라 생각했는데, 오히려 관련 없는 정보가 섞이면 AI가 혼란스러워해서 답변 품질이 떨어졌다고 해요. 검색 결과 상위 3~5개만 넣어주는 게 10개 넣는 것보다 나았다는 거예요.

비슷한 도구들과 비교

요즘 RAG를 쉽게 만들어주는 프레임워크가 많이 나와 있어요. LangChain, LlamaIndex, Haystack 같은 것들이 대표적이죠. 이런 프레임워크를 쓰면 빠르게 프로토타입을 만들 수 있지만, 이 개발자는 프로덕션 수준으로 가려면 결국 각 컴포넌트를 직접 이해하고 커스터마이징할 수 있어야 한다고 강조했어요. 프레임워크가 추상화해주는 부분(청킹, 임베딩, 리랭킹 등)을 블랙박스로 두면 문제가 생겼을 때 디버깅이 거의 불가능하거든요.

최근에는 GraphRAG(지식 그래프 기반), Agentic RAG(에이전트가 검색 전략을 동적으로 결정) 같은 발전된 패턴도 나오고 있는데, 이 글의 저자는 "기본 RAG를 제대로 못 만들면서 고급 패턴을 도입하면 복잡도만 올라간다"고 조언해요. 맞는 말이에요.

한국 개발자에게 주는 시사점

한국에서도 사내 챗봇, 고객 응대 AI, 문서 검색 시스템 등에 RAG를 도입하는 프로젝트가 빠르게 늘고 있어요. 이 글에서 얻을 수 있는 실전 팁을 정리하면 이래요.

첫째, 평가 체계를 먼저 만드세요. 질문-정답 쌍 50개만 있어도 큰 차이가 나요. 둘째, 청킹 전략에 시간을 투자하세요. 단순 고정 크기 분할보다는 문서 구조 기반 분할이 거의 항상 낫고요. 셋째, 하이브리드 검색을 기본으로 깔고 가세요. 벡터 검색만으로는 한국어처럼 조사가 붙는 언어에서 특히 키워드 매칭이 약할 수 있거든요.

한국어 특화 이슈도 있어요. 한국어는 교착어라서 "개발하다", "개발했는데", "개발하면서" 같은 활용형이 많잖아요. 임베딩 모델이 이런 변형을 잘 처리하는지 확인하는 게 중요하고, 필요하면 형태소 분석기를 전처리에 넣는 것도 방법이에요.