RAG를 어렵게 느끼는 이유는 개념이 아니라 '처음부터 임베딩·벡터 DB·청킹을 다 갖춰야 한다'는 오해 때문입니다. 오픈북 시험 비유로 RAG의 뼈대를 3분 안에 잡고, 라이트하우스 뉴스레터가 정리한 6가지 RAG 레시피를 전문 검색부터 전체 임베딩까지 계단처럼 올라가며 살펴봅니다. 실제 시스템의 60%는 검색기 하나와 프롬프트 한 장으로 충분합니다. 우리 팀에 맞는 출발점을 고르는 진단 도구와, 같은 질문을 세 방식으로 검색해 보는 놀이터를 함께 담았습니다.
RAG 강의를 듣고 나면 대개 이런 상태가 됩니다. "임베딩 모델을 고르고, 문서를 청크로 자르고, 벡터 DB를 세우고, 코사인 유사도로 찾고, 리랭커를 붙이고…" 단어는 다 아는데 어디서부터 손을 대야 할지 모르겠고, 하나라도 빼면 안 될 것 같은 기분. RAG가 어렵게 느껴지는 진짜 이유는 개념이 아니라 이 목록의 길이입니다.
이 글은 그 목록을 뒤집습니다. 데이터 엔지니어 라파엘 피에르(Rafael Pierre)가 라이트하우스 뉴스레터에 쓴 「RAG Is Simpler Than You Think」의 주장을 뼈대로 삼아, RAG를 "검색기 하나 + 프롬프트 한 장"에서 시작해 필요할 때만 한 계단씩 올라가는 여섯 가지 레시피로 다시 설명합니다. 결론을 먼저 말하면, 실제 시스템의 60%는 첫 두 계단에서 끝납니다.
RAG가 왜 태어났는지, LLM이 왜 거짓말을 하는지 같은 배경은 「RAG 완전 이해」에서 다뤘습니다. 이 글은 그 다음 질문 — "그래서 뭘 먼저 만들어야 하는데?" — 에 답합니다.
먼저 RAG의 뼈대를 3분 안에 잡고 갑시다. 어려운 용어를 다 걷어내면 RAG는 한 문장입니다. "답하기 전에 먼저 찾아보게 한다."
LLM은 학습이 끝난 시점까지 읽은 것을 기억에 의존해 답하는 학생입니다. 닫힌 책 시험(closed-book)이죠. 우리 회사 취업규칙, 어제 올라온 장애 보고서, 고객 계약서처럼 학습 데이터에 없던 내용을 물으면 모른다고 하거나 — 더 나쁘게는 — 그럴듯하게 지어냅니다.
RAG는 이 시험을 오픈북(open-book)으로 바꿉니다. 질문이 들어오면 ① 관련 자료를 먼저 찾고(Retrieve) ② 찾은 자료를 질문 앞에 붙여서(Augment) ③ 그걸 읽고 답하게(Generate) 합니다. 그게 전부입니다.
②와 ③은 프롬프트 몇 줄이면 됩니다. RAG의 난이도는 거의 전부 ①, 즉 "어떻게 찾을 것인가"에 몰려 있습니다. 그리고 여기서 대부분의 팀이 첫 번째 실수를 합니다.
RAG 튜토리얼 대부분은 ①을 이렇게 가르칩니다. 문서를 조각내고(청킹), 각 조각을 임베딩 모델로 숫자 벡터로 바꾸고, 벡터 DB에 넣고, 질문도 벡터로 바꿔 가장 가까운 조각을 찾는다. 이 방식은 뜻이 비슷한 문서를 찾는 데 강합니다. 하지만 시작하자마자 다음 결정을 전부 강요합니다.
| 임베딩부터 시작하면 즉시 결정해야 하는 것 | 전문 검색(BM25)으로 시작하면 |
|---|---|
| 청크 크기는? 겹침은? 문단 단위? 고정 길이? | 청킹 결정이 없다. 문서 통째로 색인 |
| 임베딩 모델은 무엇? 한국어 성능은? 비용은? | 모델이 없다. 단어 일치 + 통계 |
| 벡터 DB는 무엇? 운영은 누가? | Elasticsearch/OpenSearch/PostgreSQL 전문 검색으로 충분 |
| 문서가 바뀌면? 전부 다시 임베딩 | 색인 갱신이 즉시, 무료 |
| 임베딩 모델이 단종되면? 전 문서 재임베딩 | 해당 없음 |
| 약점: 동의어·의미 유추에 강함, 정확 일치엔 약함 | 약점: 동의어·표현 차이를 못 잡음 |
원문의 지적은 날카롭습니다. 전문 검색(full-text search, 대표 알고리즘이 BM25)은 "질문에 나온 단어가 실제로 들어 있는 문서"를 통계적으로 잘 찾아냅니다. 제품명, 오류 코드, 조항 번호, 사내 약어처럼 정확한 단어가 중요한 기업 문서에서는 오히려 임베딩보다 정확할 때가 많습니다. 임베딩은 "제7조"와 "제8조"를 거의 같은 뜻으로 보지만, BM25는 그 둘을 정확히 구분합니다.
그럼 전문 검색의 약점 — "표현이 다르면 못 찾는다" — 은 어떻게 하느냐. 여기가 이 글의 핵심 통찰입니다.
사용자가 "아기가 태어나면 며칠 쉴 수 있나요"라고 물었는데 규정 문서에는 "배우자 출산 특별휴가 10일"이라고 쓰여 있습니다. 단어가 하나도 겹치지 않으니 BM25는 빈손입니다. 대부분의 팀이 여기서 "역시 의미를 이해하는 임베딩이 필요하구나"라고 결론 내립니다.
원문은 다른 진단을 내립니다. 문제는 검색 엔진이 의미를 못 알아듣는 게 아니라, 질문이 검색어로 잘못 쓰였다는 것입니다. 그리고 우리 손엔 이미 세상에서 가장 좋은 "질문 → 검색어 번역기"가 있습니다. LLM입니다.
이 세 단어로 BM25를 돌리면 정답 문서가 1등으로 올라옵니다. 비용은 질의당 약 $0.001, 지연은 250ms 안팎. 임베딩 모델도, 벡터 DB도, 청킹도 없이 "의미 검색 문제"가 풀렸습니다.
더 중요한 건 유연성입니다. 검색이 엉뚱하게 나오면 임베딩 방식에서는 청킹을 바꾸고 전 문서를 다시 임베딩해야 합니다. 질의 재작성 방식에서는 시스템 프롬프트의 용어집 한 줄을 고치면 끝납니다. 첫 검색이 부족하면 LLM이 결과를 보고 검색어를 고쳐 한 번 더 찌르는 루프(agentic loop)를 붙일 수도 있고, 이것도 재색인 없이 됩니다.
아래 놀이터에서 직접 확인해 보세요. 같은 질문을 ① 그대로 키워드 검색, ② LLM이 다듬어 검색, ③ 임베딩 검색으로 돌렸을 때 순위가 어떻게 바뀌는지 — 특히 두 번째 시나리오에서 임베딩이 오히려 헷갈리는 장면을 눈여겨보세요.
원문은 RAG 아키텍처를 단순한 것부터 복잡한 것까지 여섯 가지 레시피로 정리합니다. 핵심 규칙은 하나입니다. 낮은 계단에서 시작해 측정하고, 데이터가 "부족하다"고 증명할 때만 다음 계단으로.
가장 낮은 계단이자 MVP입니다. 문서를 그대로 Elasticsearch·OpenSearch·PostgreSQL(tsvector) 같은 전문 검색기에 색인하고, 질문으로 검색해 상위 몇 건을 LLM에 넘깁니다. ML 지식이 전혀 필요 없고, 청킹 결정도 없고, 문서가 바뀌면 그 문서만 다시 색인하면 됩니다. 사용자가 제품명·오류코드·조항 번호로 묻는 환경이면 이것만으로도 놀랄 만큼 잘 됩니다. 약점은 동의어와 표현 차이.
3장에서 본 그것입니다. 레시피 1 앞에 LLM 한 단계를 붙여 질문을 검색어로 다듬습니다. 어휘 불일치와 사내 용어 문제를 대부분 해결하고, 프롬프트만 고치면 즉시 동작이 바뀌는 유연성이 있습니다. 질의당 약 $0.001. 원문은 실제 시스템의 60%가 여기서 끝난다고 봅니다.
여기서 처음 임베딩이 등장하지만, 주인공이 아니라 조연입니다. BM25로 후보 50~100건을 빠르게 뽑고, 그 후보만 임베딩(또는 크로스 인코더)으로 다시 점수 매겨 상위 10건을 고릅니다. 키워드의 정확함과 의미의 유연함을 함께 얻는 대신, 지연이 100~500ms로 늘고 청킹 결정이 다시 돌아옵니다. 질의 재작성으로도 안 잡히는 "비슷한 사례 찾아줘"류 질문이 많을 때 올라오는 계단입니다.
"임베딩을 쓰되 미리 해 두지 않는다"는 발상입니다. 질의가 들어오면 그때 후보 문서를 임베딩해 비교합니다. 매 질의마다 임베딩 비용이 들지만(하루 1천 질의 기준 월 $15 수준), 문서가 하루 10% 이상 바뀌는 환경(티켓, 뉴스, 로그)에서 재임베딩 파이프라인을 아예 안 만들어도 됩니다. 임베딩 모델을 바꾸는 것도 코드 한 줄. 지연은 200~500ms.
문서 접근은 대개 파레토 분포를 따릅니다 — 20%의 문서가 80%의 트래픽을 받습니다. 그 20%(핫)만 미리 임베딩해 두고 나머지(콜드)는 레시피 4처럼 즉시 처리합니다. 자주 쓰는 문서는 50~100ms로 빠르게, 재임베딩 비용은 5분의 1로. 접근 통계를 관리해야 하니 운영 복잡도가 한 단계 올라갑니다.
튜토리얼이 "RAG"라고 부르는 바로 그것. 전 문서를 미리 임베딩해 벡터 DB(ANN 인덱스)에 넣고 50ms 안에 찾습니다. 하루 1만 질의 이상, 지연 요구가 빡빡하고, 문서가 잘 안 바뀌는 대규모 서비스에서 값어치를 합니다. 가장 아픈 순간은 임베딩 모델 단종입니다. 문서 100만 건을 다시 임베딩하는 데 1만 달러 이상이 들 수 있습니다.
| 레시피 | 질의당 비용 | 지연 | 청킹 필요 | 모델 단종 시 | 어울리는 상황 |
|---|---|---|---|---|---|
| 1. 전문 검색 | $0 | ~15ms | 없음 | 영향 없음 | 정확한 용어로 묻는 사내 문서, 파일럿 |
| 2. 질의 재작성 | ~$0.001 | ~250ms | 없음 | 프롬프트만 수정 | 말하듯 묻는 사용자, 사내 용어 불일치 |
| 3. 하이브리드 | $0.001~0.005 | 100~500ms | 있음 | 후보만 재계산 | 의미 유추 질문이 많음 |
| 4. 즉시 임베딩 | ~$15/월(1천 질의·일) | 200~500ms | 있음 | 코드 한 줄 | 문서가 매일 10%+ 바뀜, 모델 실험 중 |
| 5. 핫/콜드 | 중간 | 50~100ms | 있음 | 핫 20%만 재임베딩(~$2,000/100만 건) | 트래픽 편중이 뚜렷한 중규모 |
| 6. 전체 임베딩 | 인프라 비용 | <50ms | 있음 | 전량 재임베딩($10,000+/100만 건) | 1만 질의/일 이상, 안정적 문서, 전담 팀 |
원문이 제시하는 분포는 이렇습니다. 60%는 레시피 1~2, 25%는 레시피 3~5, 10%만 레시피 6, 나머지 5%는 맞춤 설계. 그리고 한 줄로 못을 박습니다.
원문은 계단을 고르는 다섯 가지 기준을 제시합니다.
다섯 질문에 답하면 출발점이 나옵니다. 아래 진단 도구는 원문의 기준을 점수로 옮긴 것입니다. 결과가 레시피 1이나 2로 나와도 실망할 일이 아닙니다 — 그게 정상이고, 그게 60%입니다.
여섯 계단으로도 안 풀리는 질문이 하나 있습니다. 의도가 여러 개 섞인 질문입니다. 원문의 비유는 "피자, 초밥, 타코를 다 파는 식당 찾기"입니다. 그런 식당은 없습니다. 하지만 피자집, 초밥집, 타코집을 각각 찾는 건 쉽죠.
"CSV를 읽어서 결측치를 정리하고 결과를 그래프로 그려줘"라는 질문을 검색기 하나에 통째로 넣으면, 세 가지 의도가 뒤섞인 벡터 하나가 나오고 어느 문서와도 딱 맞지 않습니다. 임베딩을 아무리 좋게 바꿔도 그렇습니다. 문제는 검색 방식이 아니라 질문을 쪼개지 않은 것입니다.
이 패턴은 Perplexity 같은 답변 엔진이 쓰는 방식이라 원문은 "Perplexity 플레이북"이라 부릅니다. 주목할 점은 여기서도 벡터 DB가 필수 부품이 아니라는 것입니다. 질문을 잘 쪼개고, 하위 질의마다 알맞은 계단을 고르는 판단이 성능을 만듭니다. 더 정교한 판단 — 찾은 자료가 답하기에 충분한지 스스로 검증하고 부족하면 다시 찾는 구조 — 은 「에이전틱 RAG」에서 다뤘습니다.
원문의 실행 경로를 그대로 옮기면 다섯 줄입니다.
RAG를 어렵게 만드는 건 RAG가 아닙니다. 첫날부터 마지막 계단에 올라서려는 습관입니다. 오픈북 시험을 떠올리세요 — 학생에게 필요한 건 잘 정리된 교과서와 찾아볼 줄 아는 요령이지, 도서관 전체를 벡터로 바꾸는 일이 아닙니다.
참고 자료
