요약
⏱ 01:18RAG는 문서를 작은 청크로 나누어 임베딩하고, 질문과 관련된 정보를 검색해 LLM의 답변을 보강한다. 용도에 맞는 전략 3~5개를 결합하는 것이 권장된다. 리랭킹은 많은 후보를 검색한 뒤 관련성이 높은 일부만 전달하여, 청크 20개나 50개를 한꺼번에 넘길 때의 정보 과부하를 줄인다.
⏱ 03:52에이전틱 RAG는 의미 검색이나 문서 전체 읽기를 선택해 유연성을 높이지만 명확한 지침이 필요하다. 지식 그래프는 개체 관계를 검색하고, 맥락 기반 검색은 청크 앞에 문서 맥락을 덧붙인다. 두 방식은 준비 비용이 커진다. 쿼리 확장과 다중 질의는 검색의 정밀도나 범위를 높이는 대신 호출과 질의가 늘어난다.
⏱ 00:001. RAG의 기본 흐름과 전략 선택
⏱ 00:00검색 증강 생성(RAG)은 AI 에이전트에게 지식과 문서를 검색하고 활용할 수 있는 능력을 제공하는 방식입니다. 그러나 RAG 전략이 마치 백만 가지나 되는 듯해서 어떤 것이 자신의 사용 사례에 가장 적합한지 알기 어렵습니다. 어떤 RAG 전략을 선택할 수 있으며, 일부를 함께 조합해야 할까요? 사용 사례에 맞게 RAG 시스템을 최적화하려고 할 때 금방 압도당할 수 있습니다. 다행히 이 영상에서 이러한 모든 질문에 답해드리겠습니다.
⏱ 00:35이것은 정보 밀도가 높은 영상입니다. 더 짧으면서도 가치 있는 콘텐츠를 제공하는 새로운 형식을 시도하고 있습니다. 영상을 보면서 특정 RAG 전략에 대한 별도의 영상을 원하신다면 댓글로 알려주세요. 이미 그러한 영상이 있다면 해당 전략을 다룰 때 링크를 제공하겠습니다. 현재의 목표는 당신의 사용 사례에 적용할 수 있는 전략들을 생각해보고 이들을 어떻게 조합할 수 있을지 이해하도록 돕는 것입니다. 일반적으로 최적의 솔루션은 3~5개의 RAG 전략을 조합합니다.
⏱ 01:09이 영상을 보기 전에 RAG를 적어도 큰 틀에서는 이해하고 계시기를 바랍니다. RAG에는 데이터 준비 단계와 실제 검색 증강 생성 단계가 있습니다. 데이터 준비에서는 문서를 가져와 대규모 언어 모델(LLM)이 다루기 좋은 작은 정보 조각, 즉 청크(chunk)로 나눕니다. 그런 다음 이를 임베딩하여 벡터 데이터베이스에 넣습니다. 나중에 설명하겠지만 지식 그래프를 사용할 수도 있습니다.
⏱ 02:172. 리랭킹과 에이전틱 RAG


⏱ 02:17첫 번째는 리랭킹(re-ranking)입니다. 거의 모든 RAG 구현에서 제가 가장 먼저 사용하는 전략입니다. 각 전략과 함께 참고할 자료로, 아래에 링크할 GitHub 저장소도 준비했습니다. README에는 오늘 다룰 11가지 전략을 더 깊이 설명해 두었고, docs 폴더에는 연구 자료와 참고할 의사 코드 예제가 있습니다. 전체 구현도 있지만 실제 운영에 바로 쓸 수 있는 상태는 아닙니다. 가능한 한 많은 전략을 한꺼번에 결합하는 것이 이상적이지는 않기 때문입니다. 참고용으로 만든 것이니, AI 코딩 도우미에게 전달해 출발점으로 활용하셔도 좋습니다.
⏱ 02:54리랭킹으로 돌아오면, 이 전략은 두 단계로 검색합니다. 먼저 벡터 데이터베이스에서 많은 청크를 가져옵니다. 그런 다음 특화된 리랭커 모델을 사용합니다. 흔히 크로스 인코더(cross-encoder)를 사용하여 질의와 실제로 관련 있는 청크들을 골라내고, 그중 일부만 반환합니다. 결국 LLM은 소수의 청크만 받지만, 그 청크들이 가장 관련성 높은 것들입니다.
⏱ 03:16이 점은 매우 중요합니다. LLM에 처음부터 청크 20개, 50개 또는 그 이상을 한꺼번에 넘기면 모델이 정보에 압도되기 때문입니다. 특화된 모델이 더 많은 맥락을 가져오되 LLM에 전달할 분량은 줄이면, LLM에 부담을 주지 않으면서 더 많은 지식을 고려할 수 있습니다. 모델이 하나 더 필요하므로 비용은 조금 늘어나지만 증가 폭은 크지 않습니다. 저는 대부분의 RAG 구현에서 리랭킹을 즐겨 사용합니다. 관심이 있다면 화면의 코드 예제를 일시 정지하고 살펴보세요. 앞으로 소개하는 각 전략에도 이런 예제를 준비했습니다.
⏱ 03:47다음으로 에이전틱 RAG(agentic RAG)가 있습니다. 이 전략은 제 채널에서 이전에 여러 번 다루었으며, 관련 영상 링크도 여기에 표시하겠습니다. 핵심은 에이전트에게 지식 기반을 검색하는 방법을 선택할 수 있는 능력을 주는 것입니다. 예를 들어 전통적인 의미 검색을 수행할 수도 있고, 원한다면 한 문서의 전체 텍스트를 읽을 수도 있습니다.
⏱ 04:04이제 실제 프로젝트에서 직접 보여드리겠습니다. Neon 대시보드에 들어와 있는데, 이 서비스는 제가 Postgres를 쓸 때 가장 먼저 찾는 선택지가 되고 있습니다. 대부분의 RAG AI 에이전트에는 Postgres와 pgvector를 함께 쓰는 것을 좋아합니다. 여기에는 청크용 테이블 하나와 각 문서의 상위 수준 정보를 저장하는 다른 테이블이 있습니다. 에이전트는 질문에 따라 어디를 검색할지 선택할 수 있습니다. 이 방식은 RAG를 매우 유연하게 만들지만 예측 가능성은 낮아집니다. 따라서 제공한 여러 검색 방식을 각각 언제 사용해야 하는지 지침이 아주 명확할 때 에이전틱 RAG를 도입하는 것이 좋습니다. 여기에도 코드 예제가 있으니 일시 정지하고 살펴보세요.
⏱ 04:443. 지식 그래프와 맥락 기반 검색


⏱ 04:44다음은 지식 그래프(knowledge graph)입니다. 제 콘텐츠에서 많이 다룬 주제이며, 관련 영상 링크도 여기에 표시하겠습니다. 앞의 도식에서 보여드린 전통적인 벡터 검색을, 개체 간 관계를 저장하는 새로운 유형의 데이터베이스인 그래프 데이터베이스와 결합합니다. 그러면 에이전트는 유사성 검색뿐 아니라 지식에 담긴 여러 개체의 관계를 따라 검색할 수 있습니다. 보통 입력한 원문 텍스트에서 LLM이 개체와 관계를 추출해 화면과 같은 그래프를 만듭니다.
⏱ 05:16지식 그래프는 상호 연결된 데이터에 유용합니다. 그러나 보통 문서에서 개체와 관계를 추출하는 데 LLM을 사용하므로 지식 그래프를 만드는 데 훨씬 더 많은 시간이 걸리고 비용이 더 많이 들 것임을 염두에 두십시오. Graphiti를 사용한 예시를 보고 싶다면 이 의사 코드를 살펴보십시오. Graphiti는 지식 그래프 작업을 위한 제가 가장 좋아하는 라이브러리입니다.
⏱ 05:34다음은 맥락 기반 검색(contextual retrieval)입니다. Anthropic이 많은 연구를 해 온 분야이며, 일반적인 검색 과정에 얼마나 도움이 되는지 보여주는 상당히 매력적인 통계도 제시했습니다. 여기서는 LLM으로 각 청크에 정보를 보강합니다. 그 청크가 문서의 나머지 부분과 어떤 관계에 있는지 설명하는 정보를 청크의 맨 앞에 덧붙이는 방식입니다.
⏱ 05:55Neon 대시보드로 돌아가 실제 데이터베이스에서 어떤 모습인지 보여드리겠습니다. 저장된 청크 중 아무거나 하나를 클릭해 보면, 이 청크가 문서 전체에서 어떤 위치와 맥락을 갖는지 설명하는 텍스트가 앞에 붙어 있습니다. 그다음에는 대시 세 개(---)가 있고, 이어서 실제 청크의 내용이 나옵니다. 모든 청크에서 이 설명도 나머지 정보와 함께 임베딩합니다. 따라서 저장하는 정보마다 더 많은 맥락이 포함됩니다. 다만 이제 각 청크를 만들 때마다 LLM을 사용하므로, 지식 그래프처럼 준비 과정이 훨씬 느려지고 비용도 늘어납니다.
⏱ 06:274. 쿼리 확장과 문서 구조를 살리는 청킹
⏱ 06:27다음은 쿼리 확장(query expansion)이며, 가장 간단한 전략 중 하나입니다. 사용자 질의를 검색에 보내기 전에 LLM으로 확장하여 더 구체적으로 만듭니다. 지식 기반에서 더 관련성 높은 청크를 가져올 수 있다고 판단한 방향으로 세부 내용을 더하는 것입니다. 따라서 관련 있는 세부 정보를 추가해 정밀도를 높이도록 지침을 정합니다. 물론 대가도 있습니다. 검색을 수행할 때마다 LLM 호출이 한 번 더 필요하므로 처리 속도가 느려집니다.
⏱ 07:00또 다른 간단하고 비슷한 전략은 다중 질의 RAG(multi-query RAG)입니다. LLM으로 질의 하나를 확장하는 대신, 서로 다른 여러 변형 질의를 만든 다음 병렬로 검색에 보냅니다. 따라서 더 포괄적인 범위를 검색할 수 있습니다. 대신 이 방식 역시 매 검색 전에 LLM을 호출하는 비용이 들고, 전체 데이터베이스 질의 수도 늘어납니다. 화면에는 이 과정을 보여주는 간단한 코드 예제가 있습니다.
⏱ 07:24이제 맥락 인식 청킹(context-aware chunking)으로 넘어가겠습니다. 이 전략은 조금 다릅니다. 지금까지는 질의 처리 전략을 이야기했지만, 데이터 준비에도 탄탄한 전략이 필요합니다. 지식 기반에 넣을 문서를 어떻게 나눌지에 관한 이야기입니다. 문서를 분할하는 일은 꼭 필요합니다. LLM이 다루기 좋은 작은 정보 조각으로 나누지 않으면 임베딩이 부정확해지고, 에이전트가 지나치게 많은 정보를 가져오게 됩니다. 하지만 문서를 나눌 때에는 문서 구조를 유지해야 합니다.
⏱ 07:54여기서는 임베딩 모델을 사용해 문서의 자연스러운 경계를 찾아 분할합니다. 무료이면서 빠르고, 문서 구조도 유지할 수 있습니다. 1,000자마다 무조건 자르는 식의 단순한 분할보다는 분명 복잡하지만, 저는 그만한 가치가 충분하다고 봅니다. 제가 Python에서 사용하는 Docling 라이브러리는 맥락 인식 청킹의 한 형태인 하이브리드 청킹(hybrid chunking)을 매우 쉽게 구현하도록 도와줍니다. 이 주제를 다룬 영상 링크도 여기에 표시하겠습니다.
⏱ 08:235. 레이트 청킹과 계층적 RAG


⏱ 08:23또 다른 청킹 전략으로 레이트 청킹(late chunking)이 있습니다. 먼저 솔직하게 말씀드리면, 오늘 소개하는 전략 중 제가 직접 사용해 보지 않은 유일한 방식입니다. 가장 복잡한 전략이기도 하지만 아주 흥미롭다고 생각해서 포함했습니다. 대부분의 청킹 전략과 달리, 문서를 나누기 전에 문서에 임베딩 모델을 적용합니다. 그런 다음 토큰 임베딩을 청크로 나눕니다. 이렇게 하면 각 청크가 문서의 나머지 부분에 대한 맥락을 계속 유지할 수 있습니다.
⏱ 08:50따라서 문서 전체의 맥락을 더 잘 보존할 수 있으며, 긴 맥락을 처리하는 임베딩 모델을 활용하게 됩니다. 물론 훨씬 더 복잡하다는 대가가 따릅니다. 어쩌면 “콜, 잠깐만요. 너무 복잡한데요. 대체 무슨 이야기를 하는 건가요?”라고 생각하실 수도 있습니다. 앞서 다른 전략들에 대해서도 말씀드렸듯이, 레이트 청킹을 따로 설명하는 영상이 필요하다면 알려주세요.
⏱ 09:10다음은 계층적 RAG(hierarchical RAG)입니다. 데이터베이스에 지식을 여러 계층으로 저장한다는 생각입니다. 청크 사이에 부모·자식 관계를 만들고, 보통 각 청크의 메타데이터에 그 관계를 기록합니다. 그러면 개별 문단처럼 작은 단위를 아주 정밀하게 검색한 뒤, 찾은 특정 청크가 속한 문서 전체를 가져올 수 있습니다. 작게 검색하는 정밀도와 크게 반환하는 맥락 사이의 균형을 맞추는 것입니다. 계층적 RAG를 에이전틱 RAG의 일종이라고 볼 수도 있습니다. 앞서 Neon에서 보여드린 내용과 상당히 비슷하게 들리실 것입니다.
⏱ 09:46Neon으로 잠깐 돌아가 직접 보여드리겠습니다. 검색 결과로 화면의 이 청크를 찾았다고 해 보겠습니다. 메타데이터를 살펴보면 어느 파일에서 나온 청크인지 알 수 있습니다. 이어서 문서 메타데이터 테이블에 가서 그 파일의 내용 전체를 가져올 수 있습니다. 정밀하게 검색하되 더 넓은 맥락도 읽고 싶은 시스템에 아주 좋은 접근입니다. 물론 문서 전체를 읽을 수 있을 만큼 문서가 크지 않다는 전제가 필요합니다. 에이전틱 RAG처럼 복잡성과 약간의 예측 불가능성이 추가되지만, 그래도 매우 강력한 전략입니다.
⏱ 10:166. 검색 자기 점검과 임베딩 미세 조정, 추천 조합

⏱ 10:16다음은 자기 성찰형 RAG(self-reflective RAG)입니다. 앞의 복잡한 전략들에 이어 다시 간단한 것을 보여드리겠습니다. 핵심은 스스로 수정하는 검색 루프입니다. 먼저 검색을 수행하고, 청크와 질문을 LLM에 전달하여 일종의 점수를 매기게 합니다. 예를 들어 1~5점 척도에서 3점 미만이면, RAG 도구를 다시 호출하면서 검색을 다듬어 더 관련성 높은 청크를 찾습니다. 이렇게 자동으로 수정하지만 LLM 호출이 늘어납니다. 검색할 때마다 에이전트에 청크를 반환하기 전에 별도 LLM을 호출해야 하고, 필요하면 검색을 다시 시도하기 때문입니다.
⏱ 10:51마지막은 임베딩 미세 조정(fine-tuned embeddings)입니다. 이 전략은 질의 처리 때의 임베딩과 색인을 만드는 과정의 임베딩 모두에 적용됩니다. 임베딩 모델도 LLM처럼 법률이나 의료 등 특정 분야의 데이터셋으로 미세 조정할 수 있습니다. 제가 조사한 바에 따르면 정확도가 5~10% 개선될 수 있고, 더 작은 임베딩 모델이나 오픈소스 모델도 특정 활용 사례에서는 더 큰 범용 모델을 능가하게 만들 수 있습니다. 다만 직접 관리하는 임베딩 모델이므로 학습에 많은 데이터가 필요하고, 인프라와 지속적인 유지 관리도 필요합니다. 그래도 모델을 학습시킬 데이터셋이 있을 때에는 매우 강력한 활용 방법입니다.
⏱ 11:31예를 들어 텍스트의 의미적 유사성보다 감정에 기반한 유사성을 원할 수 있습니다. 사전 학습된 임베딩 모델에서는 “내 주문이 늦었다(my order was late)”와 “배송이 빨랐다(shipping was fast)”가 비슷하다고 판단할 수 있습니다. 개별 상품에 대한 이야기라기보다 둘 다 주문 자체에 대한 이야기이기 때문입니다. 하지만 모델을 미세 조정하면 “내 주문이 늦었다”를 “상품이 늘 품절이다(items are always sold out)”와 가장 비슷하게 만들 수 있습니다. 이제 감정에 더 큰 비중을 두기 때문입니다. 감정에 기반한 학습 데이터셋을 사용하여 임베딩 모델이 이런 방식으로 동작하게 만들 수 있습니다.
⏱ 12:02이렇게 주요 RAG 전략과 각각의 장단점을 살펴보았습니다. 어느 전략이든 더 깊이 알아보고 싶다면 다시 이 저장소를 확인해 주세요. Postgres와 pgvector 사용을 중심으로 다양한 의사 코드 예제를 준비했습니다. 그 이유는
⏱ 12:15특히 Neon과 함께 사용하는 이 구성이 지금 제 RAG 에이전트를 만들 때 가장 먼저 선택하는 방식이기 때문입니다.
⏱ 12:20끝으로 유용한 팁 하나를 더 드리겠습니다. 처음에 집중할 RAG 전략 세 가지를 고르고 싶으신가요? 기억하시겠지만, 가장 정확한 결과를 얻으려면 3~5가지 전략을 결합하는 것을 권합니다. 저는 리랭킹, 에이전틱 RAG, 맥락 인식 청킹을 살펴보겠습니다. 특히 Docling을 이용한 하이브리드 RAG가 제게는 아주 좋은 성과를 내고 있습니다. 이것이 마무리하면서 드리는 매우 실용적인 추천입니다. 영상이 도움이 되었고 앞으로도 AI 에이전트와 RAG에 대한 콘텐츠를 보고 싶으시다면 좋아요와 구독을 부탁드립니다. 다음 영상에서 뵙겠습니다.






