RAG
학습(Fine-tuning) 없이도 최신 데이터와 사내 지식을 실시간으로 연동하는 하이브리드 AI.
— LLM의 지식 한계를 극복하기 위해 제안된 메타 AI 연구진의 기념비적인 논문
말이 좋아 검색 증강 생성이지, 실상은 사내에 굴러다니는 개판 오분전 PDF와 포맷 다 깨진 아래한글(HWP) 파일들을 눈물 흘리며 정제하는 전산실 수작업 노가다의 극치. 파인 튜닝 하면 돈이 수천만 원 깨지니까 꼼수로 때우려다가 벡터 디비 청킹 지옥에 갇혔습니다 살려주세요
1. 개요
검색 증강 생성(Retrieval-Augmented Generation, RAG)은 거대 언어 모델의 고질적인 한계인 할루시네이션과 정보의 최신성 결여를 해결하기 위해 등장한 구원투수이자, 현직 AI 엔지니어들을 야근의 구렁텅이로 몰아넣은 만악의 근원이다. 개념 자체는 매우 직관적이다. 똑똑하긴 한데 가끔 헛소리를 찍찍 해대는 LLM에게 '너가 외운 기억(매개변수 지식)에만 의존해서 소설 쓰지 말고, 내가 옆에 놓아준 참고서(외부 데이터 소스)에서 관련 내용을 찾아서 보고 답변해라'라며 오픈북 시험지를 쥐여주는 아키텍처다. 이론상으로는 가중치를 직접 업데이트하는 파인 튜닝에 비해 수천분의 일 수준의 비용으로 최신 정보나 보안이 중요한 사내 기밀 문서를 안전하게 실시간 연동할 수 있는 완벽한 해결책처럼 묘사된다. 그러나 현실은 수많은 파싱 에러와 임베딩 불일치 속에서 개발자가 직접 텍스트 노가다를 뛰어야 하는 늪에 가깝다.(...)
2. 이상과 현실: 오픈북 시험의 비극
작동 메커니즘 자체는 매우 아름답고 논리적이다. 사용자가 질문(Query)을 던지면, 시스템이 질문의 핵심 키워드나 의미를 분석하여 벡터 데이터베이스나 일반 검색 엔진에서 연관성 높은 문서 조각(Chunk)들을 빛의 속도로 긁어모은다. 이후 프롬프트 엔지니어링을 적용해 원래 질문과 검색된 문서들을 엮어 우아한 프롬프트로 재조합한 뒤 LLM에 쑤셔 넣는다. LLM은 그저 눈앞에 던져진 텍스트를 보고 그럴싸하게 요약하여 뱉기만 하면 끝이다. 하지만 실무에서는 검색기(Retriever)가 개소리가 담긴 문서를 가져오는 순간 전체 아키텍처가 통째로 무너진다. LLM은 가져온 똥글을 기반으로 세상에서 가장 우아하고 신뢰감 넘치는 어조로 배설물을 정성껏 포장하여 사용자에게 선사한다.1 결국 '쓰레기를 넣으면 쓰레기가 나온다(GIGO)'라는 전산학의 대원칙을 AI 시대에도 매일 아침 절절하게 깨닫게 된다.
3. 엔지니어를 말려 죽이는 청킹과 임베딩의 덫
RAG 시스템의 성능을 좌우하는 핵심은 텍스트를 적절한 크기로 자르는 청킹(Chunking)과 이를 다차원 공간의 좌표로 변환하는 임베딩 과정이다. 하지만 사내 매뉴얼이나 규정집들은 절대 기계가 읽기 좋게 친절하게 작성되어 있지 않다. 병목의 주범은 역시나 악명 높은 PDF 파싱인데, 조금만 복잡한 표(Table)나 다중 열(Multi-column) 레이아웃이 등장하면 텍스트 순서가 스파게티처럼 뒤죽박죽으로 깨지며 완전히 붕괴한다.2 이를 해결하겠답시고 정규표현식을 깎아 정제 규칙을 만들고 LangChain이나 LlamaIndex 등의 프레임워크 소스코드를 까보며 헤매다 보면, 내가 인공지능 엔지니어인지 단순 텍스트 정제 타이피스트인지 자괴감이 든다.(...) 결국 튜닝을 거듭하다 지친 엔지니어들은 눈물을 머금고 검색 결과의 우선순위를 다시 매기는 하이브리드 검색 및 리랭킹(Reranking) 솔루션을 꾸역꾸역 이어 붙이는 누더기 코딩을 반복하게 된다.
4. 관련 밈 및 드립
4.1. PDF는 사람이 보라고 만든 디자인 포맷입니다
RAG 구축 프로젝트에 투입된 주니어 개발자들이 고작 텍스트 추출 단계에서 일주일 내내 야근을 한 뒤 해탈하며 외치는 단골 넋두리. PDF는 레이아웃과 디자인 서식을 보존하기 위한 포맷이지, 기계가 자연어 처리 흐름에 맞게 텍스트를 읽어 들이도록 설계된 포맷이 아니다. 표와 줄 바꿈이 뒤엉킨 문서를 파싱하려 끙끙대다 보면, 현대 AI 아키텍처의 근간은 LLM 알고리즘이 아니라 인턴의 눈물겨운 PDF 수작업 복사-붙여넣기 노가다라는 뼈아픈 블랙 유머가 마음에 와닿게 된다.
4.2. 임베딩 코사인 유사도의 함정
개발자가 질문과 문서 간의 의미론적 유사성을 비교하기 위해 코사인 유사도(Cosine Similarity)를 측정했을 때 97%의 높은 매칭률을 보여 안심했으나, 막상 결과를 까보니 '본 보고서는 대외비입니다'나 '상기 내용은 사실과 다를 수 있습니다' 같은 문서의 표준 꼬리말(Footer)만 기가 막히게 긁어와 매칭해 둔 촌극을 비꼬는 밈. 검색기는 유사도가 높다고 기뻐하고, LLM은 꼬리말만 앵무새처럼 복창하며, 개발자는 조용히 모니터를 끄고 퇴근을 고민하는 삼중주가 연출된다.
5. 여담
- 아래한글이라는 통곡의 벽: 한국에서 RAG를 구축하는 엔지니어들에게 최고의 주적은 .hwp 포맷이다. 한글과컴퓨터 특유의 독자적인 바이너리 구조 때문에 파이썬 파서 라이브러리가 멋대로 표를 깨뜨리거나 문맥을 뭉개버리기 일쑤여서, 한글 문서를 통째로 텍스트로 바꾸다 정신을 놓아버리는 개발자가 한둘이 아니다.(...)
- Meta AI의 기묘한 부활: 이 개념은 2020년 메타의 AI 연구진이 처음 제안했다. 발표 당시에는 '그냥 이런 연구도 있구나' 정도로 묻힐 뻔했으나, ChatGPT 광풍 이후 기업들이 막대한 파인 튜닝 비용에 비명을 지르기 시작하면서 '가장 현실적인 엔터프라이즈 AI 구현 기법'으로 급부상해 화려하게 역주행에 성공했다.
- 인간 위키화: 결국 RAG의 성능 한계를 극복하는 최고의 튜닝법은 문서 구조 자체를 컴퓨터가 읽기 편하도록 마크다운 형식으로 깔끔하게 인간이 선수작업해 놓는 것이다. 이 때문에 RAG 도입 기업의 베테랑 기획자들과 개발자들은 실시간으로 사내 위키를 편집하고 문서 포맷을 일체화하는 '위키 노예'로 전락하곤 한다.