Claude Code + LightRAG = 막강한 조합

CChase AI
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00RAG의 시대가 끝났다는 말은 상당히 과장되었습니다.
00:00:03네, 저도 Opus 4.6과 같은 대규모 언어 모델들이
00:00:05최근 방대한 컨텍스트를 처리하는 능력이 훨씬 좋아졌다는 걸 압니다.
00:00:09하지만 그것 때문에 RAG가 전혀 필요 없다고 생각하신다면,
00:00:12단순히 프롬프트만으로는
00:00:14해결할 수 없는 벽에 부딪히게 될 것입니다.
00:00:16그래서 오늘은 언제 RAG가 필요한지,
00:00:192026년에 실제로 작동하는 RAG는 어떤 방식인지 설명해 드리겠습니다.
00:00:22지난 1년 동안 환경이 엄청나게 변했기 때문이죠.
00:00:25그리고 Cloud Code를 여러분의 RAG 시스템에
00:00:28연결하는 방법과 더불어,
00:00:30직접 활용할 수 있는 기술들을 알려드리겠습니다.
00:00:32오늘의 목표는 바로 이것입니다.
00:00:35Light RAG를 기반으로 구축하여
00:00:38Cloud Code와 함께 사용할 수 있는 그래프 RAG 시스템이죠.
00:00:40더 중요한 것은, 이 시스템이 우리가 AI를 사용할 때
00:00:43매우 유용하게 쓰일 것이라는 점입니다.
00:00:45엄청나게 방대한 양의 문서 뭉치를 다룰 때 말이죠.
00:00:49데모에서 보시는 것처럼 고작 5장, 10장의
00:00:51문서가 아닙니다.
00:00:52500장, 1,000장의 문서들입니다.
00:00:55왜냐하면 단순히 Cloud Code나
00:00:57다른 LLM이 제공하는 기본 컨텍스트 창에만
00:00:59의존하기에는 부족하기 때문입니다.
00:01:01규모가 거대해지기 시작하면,
00:01:03많은 대기업이나
00:01:05심지어 소규모 비즈니스에서도 볼 수 있듯이,
00:01:06이런 RAG 시스템을 갖추는 것이 일반적인 에이전트 방식의 검색보다
00:01:10실제로 더 저렴하고 빠릅니다.
00:01:12그러한 점을 염두에 두었을 때,
00:01:13이러한 종류의 RAG 시스템을 만드는
00:01:14기술을 보유하는 것은 매우 중요합니다.
00:01:16다행히도 방법은 꽤 간단합니다.
00:01:18방금 언급했듯이,
00:01:19오늘은 Light RAG를 사용할 것입니다.
00:01:21제가 정말 좋아하는 오픈 소스 저장소인데요.
00:01:25나온 지 꽤 되었고,
00:01:26지속적으로 업데이트가 이루어지고 있는 프로젝트입니다.
00:01:28마이크로소프트와 같은 더 정교한
00:01:30그래프 RAG 시스템과 경쟁할 수 있으면서도
00:01:32비용은 말 그대로 아주 적은 수준입니다.
00:01:35따라서 그래프 RAG 개념을 처음 접해보는 분들이
00:01:37테스트해 보기에 가장 완벽한 도구입니다.
00:01:40하지만 Light RAG를 제대로 활용하려면,
00:01:43기본적인 수준에서 RAG가 어떻게 작동하는지 이해해야 합니다.
00:01:46RAG의 판도가 바뀌었기 때문입니다.
00:01:482024년 말과 2025년 초에 우리가 했던 방식은
00:01:51가장 기초적인 수준인 '나이브(Naive) RAG'였습니다.
00:01:54그 당시의 n8n 자동화들을 기억하시나요?
00:01:56Pinecone이나 Supabase를 연결하던 방식 말이죠.
00:01:58그것이 나이브 RAG였습니다.
00:02:00이제 그런 방식은 통하지 않습니다.
00:02:02그걸로는 충분하지 않죠.
00:02:03우리는 더 정교한 버전의 RAG를 사용해야 하지만,
00:02:06먼저 기본 원리를 이해할 필요가 있습니다.
00:02:08그러니 Light RAG 설정을 살펴보기 전에
00:02:12RAG가 무엇이고 어떻게 작동하는지 빠르게 짚어봅시다.
00:02:14RAG는 '검색 증강 생성(Retrieval Augmented Generation)'의 약자입니다.
00:02:18작동 방식은 우선
00:02:20어떤 문서에서 시작합니다.
00:02:22제대로 된 RAG 시스템이라면
00:02:25이런 문서가 수천 개는 있을 것입니다.
00:02:27어쨌든 이 문서를
00:02:29RAG 시스템 내부의
00:02:31벡터 데이터베이스에 넣으려고 합니다.
00:02:34그런데 이때 문서를
00:02:38그냥 통째로 데이터베이스에 던져 넣는 것이 아닙니다.
00:02:40마치 구글 드라이브 같은 시스템이 아니니까요.
00:02:41문서는 임베딩 모델을 거쳐서
00:02:44벡터로 변환됩니다.
00:02:46하지만 그보다 더 중요한 점은,
00:02:47문서가 하나의 거대한 덩어리로 들어가지 않는다는 것입니다.
00:02:50여러 조각(chunk)으로 나뉩니다.
00:02:51예를 들어 여기 한 페이지짜리 문서가 있다면,
00:02:54이것은 1번 청크, 2번 청크, 3번 청크로 쪼개집니다.
00:02:59그리고 이 각각의 청크들이 벡터가 되는데,
00:03:03벡터는 단순히 그래프 위의 한 점,
00:03:05즉 벡터 데이터베이스 내의 한 좌표입니다.
00:03:06임베딩 모델이 이 청킹 과정을 담당합니다.
00:03:09문서를 가져와서 어떤 내용인지 파악하고,
00:03:11그것을 그래프 상의 좌표로
00:03:13변환하는 역할을 하는 것이죠.
00:03:16문서가 조각나고,
00:03:18임베딩 모델을 거치면,
00:03:20우리 문서는 그래프 위의 벡터가 됩니다.
00:03:24지금 보시는 건 3차원 그래프입니다.
00:03:27실제로는 수천 차원이지만,
00:03:30일단은 3차원 그래프라고 생각합시다.
00:03:33자, 이 문서가 군함(warships)에 관한 것이라고 가정해 보죠.
00:03:36각 벡터가 군함에 관한
00:03:39어떤 청크로 변환되었습니다.
00:03:40그럼 이것은 어디로 갈까요?
00:03:41당연히 보트나 배(ships) 데이터 근처로 가서
00:03:43자신만의 작은 벡터가 될 것입니다.
00:03:45여기서 벡터란,
00:03:46그 데이터를 나타내는 일련의 숫자들을 의미합니다.
00:03:50옆에 있는 바나나 예시를 보시면 알 수 있습니다.
00:03:53바나나는 0.52, 5.12, 9.31 등등으로 표현되죠.
00:03:57이런 숫자가 수천 개나 이어집니다.
00:04:00우리의 작은 배 데이터도 1, 2, 3,
00:04:05이런 식으로 계속되는 숫자로 표현됩니다.
00:04:07간단하죠.
00:04:08물론 바나나나 사과 옆에 위치하지는 않겠지만,” 이것이 문서 임베딩 과정이며
00:04:10동시에 청킹(chunking) 과정입니다.
00:04:15이제 여러분이 여기 있다고 해봅시다.
00:04:18이 행복해 보이는 작은 친구가 여러분이고,
00:04:20대규모 언어 모델에게
00:04:21군함에 대해 질문을 던졌습니다.
00:04:24이 RAG 시스템 시나리오에서는 그 질문조차도
00:04:27하나의 벡터로 변환됩니다.
00:04:30LLM이 여러분의 질문을 살펴보고,
00:04:34이 데이터베이스 내의 특정 벡터와
00:04:35매칭되는 일련의 숫자들을
00:04:38할당하는 것이죠.
00:04:41그런 다음 질문 벡터와
00:04:43그래프 상의 다른 벡터들을
00:04:45서로 비교하게 됩니다.
00:04:49이것을 '코사인 유사도'라고 부르는데,
00:04:51실제로는 그냥 이런 식입니다.
00:04:53"이 질문은 이런 내용이네."
00:04:55"숫자들을 이렇게 배정하자."
00:04:56"이 질문과 가장 가까운 벡터는 뭐지?"
00:04:58"어떤 숫자들이 이 질문과 가장 비슷할까?"
00:05:00아마 군함에 관한 벡터와
00:05:02보트나 배에 관한 벡터가 나올 것입니다.
00:05:04그러면 이제 해당 정보가 담긴
00:05:08모든 벡터를 검색(retrieve)해서 가져오고,
00:05:10그것을 바탕으로 답변 생성을 보강(augment)합니다.
00:05:13그래서 '검색 증강 생성(RAG)'인 것입니다.
00:05:16즉, 대규모 언어 모델이
00:05:17순전히 자신의 학습 데이터에만 의존하는 대신,
00:05:19벡터 데이터베이스 내부로 들어가서
00:05:22관련 있는 벡터들을 움켜쥐고
00:05:24다시 돌아와서 군함에 대한 답변을 내놓는 것입니다.
00:05:27이것이 RAG가 작동하는 방식입니다, 그렇죠?
00:05:29문서 수집, 그리고 벡터로 변환된 청크들.
00:05:32질문과 벡터를 비교하고,
00:05:35가장 유사한 것을 가져오면 짠! RAG 완성입니다.
00:05:39하지만 이건 '나이브 RAG'이고,
00:05:40사실 이건 성능이 별로 좋지 않습니다.
00:05:44그래서 여러분과 저보다 더 똑똑한 사람들이
00:05:46더 나은 방법들을 고안해 냈는데,
00:05:49대표적으로 하이브리드 검색, 그래프 RAG, 에이전트 RAG가 있습니다.
00:05:53오늘 우리가 집중할 것은 그래프 RAG입니다.
00:05:55그래프 RAG도 같은 과정을 거칩니다.
00:05:57여전히 문서가 필요하고
00:05:58여전히 청킹을 해야 하며,
00:05:59평면적인 벡터 데이터베이스에 저장됩니다.
00:06:03하지만 여기에 한 가지를 더 합니다.
00:06:05바로 '지식 그래프'를 함께 생성하는 것이죠.
00:06:07이런 복잡한 결과물을 만들어 냅니다.
00:06:08이게 다 뭘까요?
00:06:09이 수많은 벡터와 선들은 무엇일까요?
00:06:11이게 실제로 무엇을 의미할까요?
00:06:12이 모든 벡터, 즉 이 작은 원들은
00:06:14'엔티티(Entity, 개체)'라고 불리는 것들입니다.
00:06:17그리고 두 엔티티를 잇는 선은
00:06:21'에지(Edge)' 또는 '관계(Relationship)'입니다.
00:06:23다시 문서 예시로 돌아가서,
00:06:25이 문서가 Anthropic과 Cloud Code에 관한 것이라고 상상해 봅시다.
00:06:28그리고 추출된 청크 전체의 내용이 이렇다고 하죠.
00:06:31"Anthropic이 Cloud Code를 만들었다."
00:06:35시스템은 이것을 가져와서 엔티티와
00:06:36관계로 분해할 것입니다.
00:06:38여기서 두 엔티티는 무엇일까요?
00:06:39엔티티는 바로
00:06:41Anthropic과 Cloud Code가 될 것입니다.
00:06:44그리고 관계는 'Anthropic이 Cloud Code를 만들었다'는 것이죠.
00:06:48여기에 Anthropic이 있고
00:06:51여기에 Cloud Code가 있습니다.
00:06:54보시는 것처럼 이쪽도 엔티티, 저쪽도 엔티티이며
00:06:58둘은 관계를 맺고 있습니다.
00:06:59시각화된 그래프에서는 그냥 선일 뿐이지만,
00:07:03내부 코딩 상으로는
00:07:05두 엔티티 사이의 그 선에
00:07:08관계를 설명하는 수많은 텍스트가
00:07:10연결되어 있습니다.
00:07:11그래프 RAG 시스템에서는
00:07:13추가하는 모든 문서에 대해 이 작업을 수행합니다.
00:07:16이게 1,000장의 문서에 적용된다고 상상해 보세요.
00:07:19겨우 10장의 문서만으로도
00:07:21이토록 많은 관계와 엔티티가 생깁니다.
00:07:24이것이 단순한 벡터들이
00:07:26데이터베이스에 제각각 고립되어 있는 것보다
00:07:28얼마나 더 정교한지 짐작이 가실 겁니다.
00:07:30Light RAG 같은 시스템을 사용하면,
00:07:33지식 그래프의 생성과
00:07:35표준 벡터 데이터베이스 구축을
00:07:38동시에 병렬로 수행할 수 있습니다.
00:07:40그래서 이제 여러분이 LLM에게
00:07:43무언가에 대해 질문을 하면,
00:07:45시스템은 단순히 가장 유사한
00:07:47특정 벡터만 끌어오는 것이 아니라,
00:07:49아래로 내려가서 엔티티까지 살펴봅니다.
00:07:54가령 Anthropic에 대해 물었다고 칩시다.
00:07:56그럼 이제 시스템은 관계들, 즉 에지를 타고 넘나들며
00:07:59관련이 있다고 판단되는 모든 것을 찾아낼 것입니다.
00:08:03이것이 사용자 여러분에게
00:08:06그래프 RAG 시스템이 주는 의미는,
00:08:08이제 훨씬 더 심도 있는 질문을 할 수 있습니다.
00:08:11단순히 문서 하나에 대해 묻거나
00:08:13모든 목적에 대해 본질적으로
00:08:15단어 찾기(Control F)를 하는 수준이 아닙니다.
00:08:17이제 서로 다른 문서와 이론,
00:08:19그리고 아이디어들이 어떻게 연관되어 있는지 물을 수 있습니다.
00:08:21그 관계들이 모두 매핑되어 있기 때문이죠.
00:08:24이것이 핵심입니다.
00:08:25이질적인 정보들을 가져와 연결하는 것이죠.
00:08:30그것이 Graph RAG의 힘입니다.
00:08:32그것이 LightRAG의 힘이기도 하죠.
00:08:33오늘 우리가 바로 그것을 배울 것입니다.
00:08:35LightRAG를 설치하고 사용하는 것은
00:08:37여러분이 원하는 만큼 간단합니다.
00:08:40가장 쉬운 방법을 보여드릴 텐데,
00:08:42클라우드 코드를 활용할 것입니다.
00:08:44LightRAG의 URL을 주고
00:08:48"이것 좀 설정해 줘"라고 말하기만 하면 됩니다.
00:08:50그러면 사실상 모든 것을 알아서 해줄 겁니다.
00:08:52이 시나리오에서는 몇 가지만 준비하면 됩니다.
00:08:55RAG의 작동 방식 분석에서 보셨듯이,
00:08:58임베딩 모델이 필요합니다.
00:08:59그래서 API가 필요할 텐데요.
00:09:02OpenAI 사용을 추천합니다.
00:09:04매우 효과적인 임베딩 모델을 보유하고 있으니까요.
00:09:07따라서 OpenAI 키가 필요할 것입니다.
00:09:09물론 LightRAG를 사용하면
00:09:11이 모든 과정을 완전히 로컬로 만들 수도 있습니다.
00:09:14Ollama를 통해 로컬 모델을 구축하여
00:09:17임베딩 분석뿐만 아니라
00:09:20질의응답까지 모두 처리하게 할 수 있습니다.
00:09:21완전 로컬 방식도 옵션이라는 점을 이해하세요.
00:09:24우리는 반반 섞어서 진행할 겁니다.
00:09:25OpenAI 임베딩 모델과
00:09:28실제 작업을 수행할 모델을 설정할 것입니다.
00:09:31그리고 Docker도 필요합니다.
00:09:34Docker를 한 번도 사용해 본 적 없더라도
00:09:35설정은 꽤 쉽습니다.
00:09:36Docker Desktop을
00:09:39다운로드해서 설치하고 실행해 두기만 하면 됩니다.
00:09:41LightRAG를 실행할 때 말이죠.
00:09:42컨테이너가 필요하기 때문입니다.
00:09:45이제 여러분이 할 일은
00:09:46클라우드 코드를 열고
00:09:47LightRAG 저장소를 클론하라고 시키는 것입니다.
00:09:50GPT-4o mini와 text-embedding-3-large를 사용하는
00:09:53OpenAI용 .env 파일을 작성하고,
00:09:56모든 기본 로컬 스토리지를 사용하며
00:09:58Docker Compose로 시작하라고 하세요.
00:10:00그리고 LightRAG 링크를 전달하면 됩니다.
00:10:02그렇게 하면 모든 것을 대신 처리해 줄 겁니다.
00:10:06이 프롬프트를 무료 스쿨 커뮤니티에 올려둘 테니
00:10:10설명란의 링크를 확인해 보세요.
00:10:12또한 그곳에서
00:10:13잠시 후에 보여드릴
00:10:15클라우드 코드와 LightRAG 관련 스킬들도 찾을 수 있습니다.
00:10:17클라우드 코드에서 더 쉽게 제어할 수 있게 해주죠.
00:10:19거기서 확인하실 수 있을 겁니다.
00:10:22예상하셨겠지만,
00:10:22제 스쿨 이야기가 나온 김에
00:10:24클라우드 코드 마스터클래스 홍보를 좀 하겠습니다.
00:10:25비전공자가 AI 개발자로 거듭나기 위한
00:10:28최고의 방법이라고 자부합니다.
00:10:31링크는 고정 댓글에 있습니다.
00:10:33저는 말 그대로 매주 내용을 업데이트하고 있습니다.
00:10:35지난 2주 동안에만
00:10:36벌써 1시간 반 분량의
00:10:38추가 콘텐츠를 넣었습니다.
00:10:39그러니 꼭 확인해 보세요.
00:10:40클라우드 코드와 AI 전반을
00:10:42진지하게 마스터하고 싶다면 말이죠.
00:10:44하지만 처음이라 너무 부담스럽다면
00:10:46무료 스쿨을 먼저 확인해 보세요.
00:10:47시작하는 분들을 위한
00:10:49훌륭한 리소스들이 많이 준비되어 있습니다.
00:10:50실행하기 전에,
00:10:51Docker Desktop이 실행 중인지 확인하고
00:10:53OpenAI 키를 준비한 다음
00:10:55클라우드 코드가 일하게 하세요.
00:10:56클라우드 코드가 설치를 마치고
00:10:58env 파일에 OpenAI 키를 추가하면
00:11:01이런 화면을 보게 될 것입니다.
00:11:02우선 Docker Desktop에서
00:11:04LightRag라는 컨테이너가 실행 중인 것을 볼 수 있습니다.
00:11:07그리고 클라우드 코드가
00:11:11로컬 호스트 9621 포트 링크를 줄 겁니다.
00:11:13그 링크를 타고 들어가면 이런 페이지가 나옵니다.
00:11:15이것이 LightRag의 웹 UI입니다.
00:11:18여기서 문서를 업로드하고,
00:11:21지식 그래프를 확인하고, 정보를 검색할 수 있습니다.
00:11:24또한
00:11:25다양한 API 엔드포인트들도 살펴볼 수 있는데,
00:11:28나중에 아주 유용하게 쓰일 겁니다.
00:11:30지금 보시는 것들은 제가 이 영상을 위해
00:11:31업로드해 둔 문서들입니다.
00:11:33문서를 업로드하는 방법은 아주 간단합니다.
00:11:35오른쪽의
00:11:36업로드(Upload) 버튼 쪽으로 파일을 드래그하면 됩니다.
00:11:39다만 여기에 넣을 수 있는
00:11:42문서 유형에 제한이 있다는 점을 이해해야 합니다.
00:11:43텍스트 문서나 PDF 등,
00:11:46기본적으로 텍스트 기반 문서로 한정됩니다.
00:11:49물론 이를 우회하는 방법도 있습니다.
00:11:51이미지, 차트, 표 같은 것들 말이죠.
00:11:56범위에서 약간 벗어난 내용이라
00:11:57마지막에 따로 이야기하겠지만,
00:11:59방법은 알려드릴 겁니다.
00:12:00어쨌든 원하는 문서를 여기에 넣으면
00:12:02업로드되는 동안
00:12:04그 상태를 확인할 수 있습니다.
00:12:07시간이 좀 걸릴 수 있는데,
00:12:08업로드와 동시에 지식 그래프를 구축하기 때문입니다.
00:12:10그래서 꽤 오래 걸릴 수도 있습니다.
00:12:12만약 지식 그래프 페이지에서
00:12:14가끔 발생하는 일인데
00:12:16로딩이 안 된다는 메시지가 뜨면
00:12:18왼쪽 상단에 있는
00:12:19이 버튼을 눌러 초기화하면 됩니다.
00:12:21검색(Retrieval) 탭으로 이동하면
00:12:23거대 언어 모델에게
00:12:25지식 그래프에 대한 질문을 할 수 있습니다.
00:12:27임베딩에 사용한 것과 같은 키를 썼다면
00:12:30이 모델은 아마 OpenAI일 것입니다.
00:12:31오른쪽에는 몇 가지 파라미터가 있습니다.
00:12:33솔직히 당장 바꿀 필요가 있는 건 별로 없어요.
00:12:36잠시 후에 클라우드 코드가 어떻게 하는지 보여드릴게요.
00:12:39질문을 던져보면, 예를 들어
00:12:42전 AI와 RAG 관련 문서를 많이 넣어뒀는데요.
00:12:44"2026년에 RAG를 운영하는 데
00:12:47비용이 얼마나 드나?"라고 물었습니다.
00:12:48그러면 꽤 정교한 답변을 내놓습니다.
00:12:50게다가 답변의 모든 내용에 대해
00:12:53참조 문헌도 함께 제공합니다.
00:12:56여기 4, 3, 2번 보이시죠?
00:12:57페이지 하단에 보면
00:13:00가져온 문서들의
00:13:01실제 참조 정보를 확인할 수 있습니다.
00:13:03그리고 우리 지식 그래프 안에서
00:13:05엔티티와 관계를 설명해 줍니다.
00:13:07OpenAI 같은 엔티티 중 하나를 클릭하면
00:13:09몇 가지 속성을 볼 수 있습니다.
00:13:12LightRag의 임베딩 과정은 단순히
00:13:14관계와 엔티티를 추출하는 것 이상의 일을 합니다.
00:13:17실제로 조금 더 깊게 파고들어
00:13:19"이것은 어떤 유형의 엔티티인가?"를 분석하죠.
00:13:20조직인지 아니면 사람인지를 말입니다.
00:13:22추출한 특정 파일 정보와
00:13:25청킹(Chunking) ID도 가지고 있습니다.
00:13:27그리고 오른쪽 하단에서
00:13:29실제 관계들을 확인할 수 있습니다.
00:13:31잠시 이걸 치워볼게요.
00:13:32오른쪽 하단에 보면,
00:13:33그래프에 너무 뭉쳐 있어서
00:13:35시각적으로 잘 안 보일 때가 있는데
00:13:36그럴 때는 그냥 여기를 클릭하면
00:13:40해당 정보로 바로 이동할 수 있습니다.
00:13:41이 서버 API가 바로 우리가
00:13:43클라우드 코드와 연결할 때 사용할 도구입니다.
00:13:46웹 UI도 훌륭하지만,
00:13:48질문 하나 던지려고
00:13:50매번 검색 탭에 앉아 있고 싶지는
00:13:51않을 테니까요.
00:13:53그건 너무 번거로운 일입니다.
00:13:56대신에 이 API들을 사용할 겁니다.
00:13:57이 모든 API에는
00:14:00설명이 있고 파라미터 등을 볼 수 있는데,
00:14:03이 각각의 API를 '스킬'로 만들 수 있습니다.
00:14:05그게 제가 지금 보여드리고자 하는 것입니다.
00:14:08그렇게 하면 클라우드 코드가 LightRag를 사용하게 하고 싶을 때,
00:14:11그냥 클라우드 코드 안에서
00:14:15"LightRag 쿼리 스킬을 써서 질문해 줘"라고 하면 됩니다.
00:14:17이것은 검색 탭에서
00:14:19직접 질문하는 것과 똑같습니다.
00:14:22게다가 클라우드 코드는 그 답변을 받아서
00:14:23요약까지 해줄 것입니다.
00:14:26LightRag의 답변은 처음부터
00:14:28상당히 심층적일 수 있기 때문입니다.
00:14:30하지만 가공되지 않은 답변을 원한다면
00:14:32그렇게 설정할 수도 있습니다.
00:14:34핵심은 웹 UI가 있더라도,
00:14:36원치 않는다면
00:14:37직접 상호작용할 필요가 전혀 없다는 겁니다.
00:14:40우리의 클라우드 코드 생태계로
00:14:41가져오는 것이 정말 쉽거든요.
00:14:42가장 많이 쓰게 될 네 가지 주요 스킬은
00:14:44쿼리, 업로드, 탐색, 상태 확인입니다.
00:14:46이 네 가지 모두 무료 스쿨에 올려두겠습니다.
00:14:48보통 무엇을 가장 많이 할까요?
00:14:51새 문서를 추가하고
00:14:55그 문서들에 대해 질문하는 일을 하겠죠.
00:14:56그리고 아마 이런 궁금증도 생길 겁니다.
00:14:58"내가 정확히 뭘 넣어뒀더라?"
00:15:01문서가 엄청나게 많아지면
00:15:02똑같은 문서를 반복해서 넣는 실수를
00:15:04피하고 싶을 테니까요.
00:15:05클라우드 코드에서 똑같은 질문을 하면,
00:15:07LightRag 쿼리 스킬을 호출하게 되고
00:15:08그 요청이 LightRag로 전송됩니다.
00:15:12LightRag는 우리 컴퓨터에 호스팅되어
00:15:14Docker 컨테이너 안에서 실행되며 답변을 가져올 것입니다.
00:15:18다시 말씀드리면, 이것은 우리 컴퓨터에서 호스팅되며
00:15:21도커 컨테이너 내부에서 실행되고 있으며
00:15:22응답을 가져올 것입니다.
00:15:24이제 여러분은 이 반로컬 시스템에 국한되지 않습니다.
00:15:28만약 여러분이 LightRAG를 사용하여
00:15:30아주 크게 확장하고 있다면, 이것을
00:15:33표준 Postgres 서버에 호스팅할 수 있습니다.
00:15:36선택지는 많습니다. Neon 같은 서비스를 사용할 수도 있죠.
00:15:38말하자면 모든 범위를 아우릅니다.
00:15:40완전 로컬로 갈 수도 있고, 원한다면 이 모든 것을
00:15:43클라우드로 넘길 수도 있습니다.
00:15:44LightRAG는 매우, 매우 맞춤화가 가능합니다.
00:15:46여기에 Claude Code가 내놓은 응답이 있는데,
00:15:48이것 역시 LightRAG가 우리에게 준
00:15:52원시 응답의 요약이며, 출처도 인용합니다.
00:15:55저는 가공되지 않은 응답도 요청했는데,
00:15:57그것도 얻을 수 있기 때문입니다.
00:15:58Claude Code에 JSON 응답 형태로
00:16:00그냥 다시 가져오기 때문이죠.
00:16:02그게 전부입니다.
00:16:04그리고 다시 말씀드리지만, 원하시면 참조 문헌도 있습니다.
00:16:07방금 보셨듯이, LightRAG를 설치하는 것은 매우 쉽고
00:16:10Claude Code 워크플로우에 통합하는 것도 매우 간단합니다.
00:16:14이제 질문은 이렇습니다. "알겠어요, Chase. 다 좋네요."
00:16:18"문서가 엄청나게 많으면 이걸 써야 한다는 개념은 이해했습니다."
00:16:20"자, 그럼 그 경계선은 어디인가요?"
00:16:22"언제부터 LightRAG를 통합하기 시작해야 할까요?"
00:16:23글쎄요, 여기에는 정확한 숫자가 정해져 있지 않습니다.
00:16:26회색 지대는 제 생각에 대략 500페이지에서
00:16:282,000페이지 사이의 문서인 것 같습니다.
00:16:33그냥 '문서'라고만 말하고 싶지는 않은데,
00:16:36문서 하나가 얼마나 클지 알 수 없기 때문입니다.
00:16:37하지만 대략 500에서 2,000 텍스트 페이지 정도라고 보죠.
00:16:392,000페이지에 도달하면 이제
00:16:42백만 토큰 정도에 도달하기 시작합니다.
00:16:44그 지점을 넘어가면 확실히
00:16:47LightRAG를 통합하기 시작하는 것이 합리적입니다.
00:16:50왜냐하면 RAG가 구성된 방식 때문에,
00:16:52Claude Code의 표준 grep 방식에만 의존하는 것보다
00:16:54비용도 저렴하고 속도도 더 빠를 것이기 때문입니다.
00:16:57에이전트 기반의 grep, 즉 Claude Code가 파일을 검색하는
00:17:00기존 방식도 이미 훌륭합니다.
00:17:03Claude Code가 그 방식을 택한 데는 이유가 있죠.
00:17:04하지만 그것은 여러분이 2,000페이지나
00:17:074,000, 5,000페이지의 문서를 가졌다는 가정이 아니었습니다, 맞죠?
00:17:12분명히 상한선이 있습니다.
00:17:14다행인 점은 그 결정을 반드시
00:17:16확정해 둘 필요는 없다는 것입니다. 보셨다시피,
00:17:19이것을 구현하는 것은 매우 쉽습니다.
00:17:22그러니 그냥 실험해 보세요.
00:17:24문서가 너무 많아서 "이쯤에서
00:17:26RAG를 써야 할까?"라는 생각이 든다면,
00:17:28글쎄요, 저도 잘 모르겠으니 한번 해보세요.
00:17:30시간이 오래 걸리지 않습니다.
00:17:32가장 고통스러운 부분은 임베딩 과정입니다.
00:17:34그건 확실히 시간이 좀 걸릴 수 있지만, 감당 못 할 정도는 아닙니다.
00:17:36그리고 특히 LightRAG를 사용하면 비용이 미친 듯이 비싸지도 않습니다.
00:17:40이것을 Microsoft GraphRAG 같은 다른
00:17:43그래프 RAG 시스템과 비교해 보면,
00:17:45비용이 아주 적은 비율에 불과합니다.
00:17:48그리고 문서 크기가 매우 커지면,
00:17:49RAG를 쓰는 비용과 grep 같은 방식을 쓰는 비용의
00:17:52차이는 천 배 정도 더 저렴한 수준입니다.
00:17:56작년 여름에 이루어진
00:17:58연구 결과에 따르면
00:18:04그런 상황에서는 RAG를 사용하는 것이
00:18:071,250배나 더 저렴했다고 합니다.
00:18:08여기 텍스트 기반 RAG와 텍스트 기반 LLM의 비교,
00:18:10그리고 실제 응답 시간 차이를 보실 수 있습니다.
00:18:14자, 솔직히 말씀드리면 이것은 작년 7월 자료입니다.
00:18:19그래서 모델들이 변했습니다.
00:18:20RAG와 표준 텍스트 처리 상황을 비교했을 때
00:18:23지금도 여전히 그 정도로 미친 듯한 차이가 날지는 의문입니다.
00:18:26그리고 이건 Gemini 2.0 기준이었습니다.
00:18:28하네스(harness)에 대해 이야기하던 때가 아니었죠.
00:18:29그래서 많은 것이 변했습니다만,
00:18:31그 격차가 1,250배를 메울 만큼 변했을까요?
00:18:36그럴 수도 있고, 아닐 수도 있겠죠.
00:18:39저는 그렇게 생각하지 않습니다.
00:18:40어쨌든 그냥 한번 해보세요.
00:18:42잃을 건 별로 없다고 생각합니다.
00:18:44LightRAG의 또 다른 측면은,
00:18:46문서를 업로드하고 싶을 때에 대한 아이디어인데,
00:18:48아까 이 부분을 조금 언급했습니다.
00:18:49만약 표나 그래프처럼
00:18:53텍스트가 아닌 것들이 있다면 어떻게 할까요?
00:18:54LightRAG가 이것을 처리할 수 있을까요?
00:18:57정확히는 아니지만, 해결할 방법이 있습니다.
00:18:59그 정답은 바로 'RAG Anything'입니다.
00:19:02LightRAG와 똑같은 제작자들이 만든 것이죠.
00:19:04이것은 기본적으로 멀티모달이 될 수 있는 도구입니다.
00:19:07그리고 우리가 LightRAG로 구축한 것 위에
00:19:09바로 꽂아서 사용할 수 있는 것이죠.
00:19:10실망시켜 드리고 싶지 않지만,
00:19:13그것은 오늘 다룰 범위를
00:19:15벗어나는 내용입니다.
00:19:17하지만 내일 영상에서는
00:19:18무엇을 할 것 같으신가요?
00:19:19내일은 RAG Anything을 살펴보며
00:19:22기존에 LightRAG로 만든 것에
00:19:25어떻게 통합할 수 있는지 보여드릴 예정입니다.
00:19:27일종의 멋진 콤비가 될 것입니다.
00:19:28그러니 관심이 있으시다면
00:19:31좋아요와 구독을 눌러주세요.
00:19:32내일 바로 다룰 예정이니까요.
00:19:34그 점을 끝으로,
00:19:35여기서 마무리를 짓도록 하겠습니다.
00:19:39즐거우셨기를 바랍니다.
00:19:41이건 제 새로운 카메라 설정으로 찍은 첫 영상이기도 합니다.
00:19:43조명이 벌써부터 제가 원하던
00:19:46그런 느낌이 아니라는 게 느껴지네요.
00:19:48그 점에 대해서는 사과드립니다.
00:19:49여전히 문제점들을 고쳐나가는 중이지만,
00:19:50어쨌든 작동이 되고
00:19:52도중에 카메라가 과열되지 않아서 다행입니다.
00:19:55네, 모든 스킬은 무료 School 커뮤니티에 있습니다.
00:19:58RAG 관련 내용은 매우 흥미롭고, 특히 LightRAG가 그렇습니다.
00:20:01훌륭한 제품이었습니다.
00:20:02저도 꽤 오랫동안 사용해 왔습니다.
00:20:03그러니 100%, 꼭 한 번 확인해 보세요.
00:20:06보셨던 것처럼 Claude Code 내부에서
00:20:07통합하는 것도 아주 쉽습니다.
00:20:08그러니 스킬들을 얻으려면 무료 School을 확인하시고,
00:20:12필요하시다면 프롬프트도 확인하세요.
00:20:14솔직히 말씀드리면,
00:20:15Claude Code에 LightRAG를 연결하기만 하면
00:20:16알아서 아주 잘 설정해 줄 것입니다.
00:20:19그 외에는,
00:20:20마스터클래스를 직접 들어보고 싶으시다면
00:20:21Chase AI Plus를 꼭 확인해 보세요.
00:20:24그럼 다음에 뵙겠습니다.

Key Takeaway

500페이지 이상의 방대한 문서를 다룰 때는 Claude Code와 LightRAG를 결합하여 지식 그래프 기반의 검색 시스템을 구축하는 것이 일반적인 AI 에이전트 검색보다 속도와 비용 면에서 압도적으로 유리하다.

Highlights

LightRAG는 마이크로소프트의 GraphRAG와 대등한 성능을 제공하면서도 구축 비용은 훨씬 저렴한 오픈 소스 라이브러리다.

문서량이 500페이지에서 2,000페이지(약 100만 토큰)를 초과하는 시점부터는 표준 에이전트 검색보다 RAG 통합이 비용 효율적이다.

그래프 RAG는 단순 벡터 검색과 달리 엔티티(Entity)와 에지(Edge)를 통해 서로 다른 문서 간의 복잡한 아이디어 관계를 매핑한다.

Claude Code에 LightRAG URL을 제공하고 Docker Compose 실행을 명령하면 전체 시스템 설정이 자동으로 완료된다.

과거 연구에 따르면 대규모 데이터 환경에서 RAG를 사용하는 것이 표준 LLM 텍스트 처리 방식보다 1,250배 더 저렴하다.

Timeline

2026년 RAG 시스템의 필요성과 변화

  • LLM의 컨텍스트 창 확장이 RAG의 필요성을 완전히 대체하지 못한다.
  • 500장 이상의 대규모 문서군에서는 전용 RAG 시스템이 에이전트 방식보다 빠르고 저렴하다.
  • LightRAG는 적은 비용으로 고성능 지식 그래프를 구축할 수 있는 최적의 도구다.

최신 모델인 Opus 4.6 등이 방대한 컨텍스트 처리 능력을 갖추었음에도 불구하고, 특정 규모 이상의 데이터에서는 프롬프트만으로 해결할 수 없는 한계가 존재한다. 특히 비즈니스 환경에서 다루는 수천 장의 문서는 RAG 시스템을 통해 관리하는 것이 경제적이다. LightRAG는 마이크로소프트의 시스템과 경쟁 가능한 수준의 정교함을 갖춘 오픈 소스 프로젝트다.

나이브 RAG와 벡터 임베딩의 원리

  • 나이브 RAG는 문서를 청크로 나누어 벡터 데이터베이스에 저장하는 기초적인 방식이다.
  • 임베딩 모델은 텍스트 데이터를 수천 차원의 숫자로 이루어진 좌표 값으로 변환한다.
  • 질문과 가장 유사한 벡터를 코사인 유사도 계산을 통해 찾아내어 답변을 생성한다.

2024년 말까지 주로 사용되던 나이브 RAG 방식은 현재의 복잡한 요구사항을 충족하기에 부족하다. 문서를 통째로 넣는 것이 아니라 의미 단위인 청크로 쪼개고, 이를 벡터화하여 공간상의 좌표로 배치하는 과정이 핵심이다. 사용자의 질문 역시 벡터로 변환되어 데이터베이스 내에서 가장 가까운 정보를 찾아내고 이를 바탕으로 LLM의 답변을 보강한다.

지식 그래프를 활용한 그래프 RAG의 구조

  • 그래프 RAG는 벡터 데이터베이스 위에 엔티티와 관계를 연결한 지식 그래프를 추가한다.
  • 개체 간의 관계를 설명하는 텍스트가 에지에 포함되어 정보의 맥락을 보존한다.
  • 서로 다른 문서에 흩어진 아이디어들이 어떻게 연관되는지 심도 있게 질문할 수 있다.

단순한 벡터들이 고립되어 저장되는 대신, 개체와 개체 사이의 관계를 선(에지)으로 연결하여 매핑한다. 예를 들어 특정 기업이 어떤 제품을 만들었다는 정보를 엔티티와 관계로 분해하여 저장하면, 시스템은 이 경로를 타고 넘나들며 관련 정보를 검색한다. 이는 단순한 단어 찾기 수준을 넘어 이질적인 정보들 사이의 연결 고리를 찾아내는 강력한 기능을 제공한다.

Claude Code를 이용한 LightRAG 설치 및 연동

  • Claude Code에 저장소 링크를 전달하여 설치 및 환경 설정을 자동화할 수 있다.
  • OpenAI의 임베딩 모델과 Docker Desktop 설치가 필수 준비 사항이다.
  • LightRAG 웹 UI를 통해 문서 업로드 상태와 생성된 지식 그래프를 시각적으로 확인한다.

설치 과정은 Claude Code를 통해 자동화가 가능하며, 사용자는 OpenAI API 키와 Docker 실행 환경만 준비하면 된다. .env 파일을 작성하고 Docker Compose로 컨테이너를 실행하는 모든 과정을 AI가 대신 수행한다. 설치 후 제공되는 로컬 호스트 링크를 통해 웹 UI에 접속하면 텍스트 기반 문서나 PDF를 업로드하여 즉시 그래프 구축을 시작할 수 있다.

API 스킬 통합 및 워크플로우 최적화

  • 쿼리, 업로드, 탐색, 상태 확인의 4가지 주요 기능을 Claude Code 스킬로 등록한다.
  • 웹 UI에 접속할 필요 없이 터미널 내에서 직접 LightRAG에 질문하고 요약본을 받는다.
  • Neon이나 Postgres를 연동하여 시스템을 클라우드로 확장할 수 있다.

반복적인 작업을 줄이기 위해 LightRAG의 API 엔드포인트를 Claude Code의 스킬로 변환하여 사용한다. 이를 통해 터미널 환경에서 문서를 추가하거나 질문을 던지고, 출처가 인용된 정교한 답변을 즉시 얻을 수 있다. 사용자의 필요에 따라 완전 로컬 환경부터 대규모 클라우드 서버까지 유연하게 확장 가능한 구조를 지원한다.

RAG 도입 기준과 비용 효율성 분석

  • 문서량이 2,000페이지를 넘어가면 RAG 사용 시 비용이 최대 1,250배까지 저렴해진다.
  • 표나 그래프 같은 비텍스트 데이터는 RAG Anything 도구를 통해 멀티모달로 처리한다.
  • LightRAG는 타 그래프 RAG 시스템 대비 운영 비용이 매우 낮아 실험적 도입에 유리하다.

문서 분량이 500에서 2,000페이지 사이의 회색 지대를 지나면 RAG의 효율성이 극대화된다. 과거 연구 결과는 RAG 방식이 표준 텍스트 처리보다 압도적으로 저렴함을 증명하며, 응답 속도 또한 대규모 데이터셋에서 더 빠르다. 텍스트 이외의 데이터 처리를 원하는 경우 동일 제작자의 RAG Anything 도구를 통합하여 시스템 기능을 확장할 수 있다.

Community Posts

View all posts