00:00:00Claude Code와 메모리 문제를 해결해 봅시다. AI 시스템이 안정적이고 정확하게
00:00:06과거의 대화나 방대한 문서 자료에 대해 답변하도록 만드는 것은 우리가 수년간
00:00:13해결하려고 노력해 온 문제이며, 이에 대한 전형적인 해답은 RAG(검색 증강 생성)였습니다.
00:00:20이 영상의 제목은 'Claude Code와 RAG의 7단계'이지만, 실제로 이 영상에서 다룰 내용은
00:00:26Claude Code뿐만 아니라 일반적인 AI 시스템의 메모리 문제를 해체하는 것이며,
00:00:33더 중요한 것은 AI 시스템과 메모리 사이의 싸움에서 여러분이 현재 어느 위치에 있는지,
00:00:37그리고 다음 단계로 가기 위해 무엇을 해야 하는지 보여주는 로드맵을 제공하는 것입니다. 자,
00:00:43Claude Code와 RAG의 7단계를 거치면서 우리는 많은 주제를 다루게 될 것입니다.
00:00:48하지만 GraphRAG 같은 복잡한 것부터 시작하지 않고, 아주 기초적인 단계부터 시작하겠습니다.
00:00:53그것은 바로 Claude Code에 내장된 기본 메모리 시스템입니다. 슬프게도 말이죠,
00:00:59이곳이 대부분의 사람들이 시작하는 곳일 뿐만 아니라, 머무르는 곳이기도 합니다. 오토 메모리와
00:01:04CLAUDE.md 같은 것들부터 시작해서, Obsidian 같은 외부 도구로 넘어갔다가,
00:01:10결국 진정한 RAG 시스템인 '거물급' 단계에 도달하게 될 것입니다. 이 단계들에서 우리는
00:01:16RAG가 실제로 무엇인지, 어떻게 작동하는지, Naive RAG, GraphRAG, Agentic RAG 등 다양한 유형과
00:01:21리랭커(re-ranker) 등에 대해 이야기할 것입니다. 그리고 각 단계마다 동일한 방식으로 분석할 것입니다.
00:01:25그 단계에서 기대할 수 있는 것, 마스터해야 할 기술, 피해야 할 함정,
00:01:29그리고 다음 단계로 넘어가기 위해 필요한 것을 설명하겠습니다. 이 영상이
00:01:34이러한 특정 시스템을 설정하는 방법에 대한 매우 심도 있고 기술적인 설명은 아닐 것입니다.
00:01:40왜냐하면 이미 많은 사례를 통해 설명했기 때문입니다. 예를 들어 GraphRAG나 LightRAG,
00:01:45혹은 RAG Anything 같은 더 고급 주제나 다양한 임베딩 시스템에 대해서는,
00:01:50처음부터 끝까지 직접 설정하는 방법을 분석한 영상들을 이미 제작했습니다.
00:01:55따라서 해당 섹션에 도달하면 관련 영상들을 링크하겠습니다. 이것은 우리 모두를 위해
00:02:00영상이 5시간이나 되지 않도록 하기 위함입니다. 하지만 각 수준에서 그것이 실제로 무엇을 의미하는지,
00:02:04각 시스템이 어떤 이점을 주는지, 언제 사용해야 하는지에 대해서는 여전히 이야기할 것입니다.
00:02:091단계를 시작하기 전에 오늘 스폰서인 '저'에 대해 잠시 소개하겠습니다. 바로 지난달에
00:02:15Claude Code 마스터 클래스를 출시했습니다. 비전공자라면 AI 개발자가 되기 위한
00:02:21가장 좋은 방법입니다. 이 마스터 클래스가 조금 특별한 이유는
00:02:25Claude Code 사용법을 익히기 위해 다양한 활용 사례에 집중하기 때문입니다. 그중 하나가
00:02:31프로덕션 수준의 RAG입니다. 이 영상에서 보게 될 RAG 시스템을 실제 시나리오에서 구축하고,
00:02:37실제 팀의 일원으로서 사용하거나 클라이언트에게 판매하는 방법을 중점적으로 다룹니다.
00:02:42관심이 있다면 Chase AI+에서 확인하실 수 있으며 고정 댓글에 링크가 있습니다. 많은 참여 바랍니다.
00:02:47이제 1단계인 '오토 메모리'부터 시작하겠습니다.
00:02:51이것은 Claude Code가 여러분이 대화한 내용을 실제로 기억하기 위해
00:02:58일종의 메모리 장치를 자동으로 생성하여 사용하는 시스템입니다. 만약 여러분이
00:03:02이전 대화나 코드베이스의 전반적인 맥락을 기억하도록 의도적으로 설정한 것이 없다면,
00:03:09여러분은 현재 이 단계에 있는 것입니다. 오토 메모리라고 말할 때,
00:03:13그것은 말 그대로 Claude Code를 사용할 때 자동으로 활성화되는 시스템을 의미합니다.
00:03:18기본적으로 Claude Code가 스스로 마크다운 파일을 생성하여,
00:03:26해당 프로젝트에서 여러분에 대해 중요하다고 생각하는 것들을 나열할 수 있게 해줍니다.
00:03:32이것은 전적으로 대화 내용을 바탕으로 한 AI 자체의 직관에 기반합니다. 생성된 메모리 파일들은
00:03:37직접 확인할 수 있습니다. .claud 폴더 내의 projects 폴더로 들어가면,
00:03:42memory라는 폴더가 보일 것입니다. 그 안에는 여러 마크다운 파일들이 들어 있습니다.
00:03:47여기에는 네 개가 있네요. 이것은 마치 Claude Code 버전의 포스트잇과 같습니다. '아, 이 사람이
00:03:51유튜브 프로젝트 성장 목표에 대해 언급한 적이 있었지. 적어두자'라고 하는 식이죠.
00:03:59모든 사용자의 memory 폴더에는 memory.md 파일이 있을 것입니다. 보시다시피 이 메모리 파일에는
00:04:04제 기술 중 하나에 대한 짧은 메모가 있고, 그 아래에는 하위 메모리 파일들의 인덱스가 있습니다.
00:04:09유튜브 성장, 수익, 참고 자료 등에 대한 파일들이 있고 그 내용이 무엇인지 알려줍니다.
00:04:13그래서 제가 볼트 파일에서 Claude Code와 대화하며 유튜브나 성장 목표 등에 대해
00:04:19언급하면, AI는 이것을 참고하여 '아, Chase는 2026년 말까지
00:04:23X명의 구독자를 달성하려고 했지'라고 말할 것입니다. 귀엽긴 하지만 궁극적으로는 그렇게 유용하지 않습니다.
00:04:30마치 ChatGPT 안에서 이전 대화의 뜬금없는 내용을 가져와서
00:04:35억지로 끼워 맞추는 것과 비슷합니다. '그래, 네가 이걸 기억하는 건 알겠는데,
00:04:40난 별로 관심 없고 솔직히 계속 들먹이는 게 좀 이상해. 안 그랬으면 좋겠어' 같은 느낌이죠.
00:04:44불행히도 대부분의 사람들은 메모리 여정에서 이 단계에 머물러 있습니다. 그리고 이것은
00:04:49우리 모두가 챗봇을 사용하며 겪어온 다소 학대적인 과거에 기반하고 있습니다.
00:04:54이 챗봇들은 대화와 대화 사이에 진정한 의미의 기억력이 없기 때문에,
00:05:00우리는 채팅창을 닫거나 터미널 세션을 종료하는 것을 죽도록 두려워합니다.
00:05:06내 대화 내용을 기억하지 못할까 봐 걱정하기 때문이죠. 이것은 실제로
00:05:10심각한 문제입니다. 채팅창이 아무것도 기억하지 못하는 상황에 대해
00:05:17사람들이 내놓는 유일한 답이 무엇일까요? 바로 그 대화를 영원히 유지하는 것입니다.
00:05:22종료하는 순간 모든 것을 잊어버릴까 봐 두렵기 때문이죠. 이러한 공포는 ChatGPT부터 시작해서
00:05:26Claude 웹 앱에 이르기까지 이 채팅창 안에서 탄생했습니다.
00:05:31솔직히 Claude 웹 앱은 예전에 훨씬 더 심했습니다. 100만 컨텍스트 윈도우가 나오기 전,
00:05:35Claude와 30분 정도 대화하면 '4시간 후에 봐요'라고 하던 시절을 다들 기억하실 겁니다.
00:05:39문제는 사람들이 그런 정신적이고 신경질적인 행동을 터미널로도 가져왔다는 것입니다.
00:05:45이제 100만 컨텍스트 윈도우 덕분에 그런 식으로 버틸 수 있게 되자,
00:05:50사람들은 절대 대화창을 비우지 않습니다. Claude Code가 내용을 잊어버리는 게 싫어서
00:05:55계속해서 대화를 이어 나갑니다. 하지만 문제는 메모리 문제 때문에
00:06:00동일한 세션 내에서 Claude Code와 대화가 길어질수록 효율성이 급격히 떨어진다는 점입니다.
00:06:05이것이 바로 '컨텍스트 부패(Context Rot)'의 핵심 개념입니다. 컨텍스트 부패가 무엇인지 모른다면,
00:06:10동일한 세션, 동일한 채팅 내에서 AI 시스템을 더 많이 사용하여
00:06:16컨텍스트 윈도우를 채울수록 성능이 나빠지는 현상을 말합니다. 여기서 보시다시피
00:06:23Claude Code의 100만 컨텍스트 중 25만 토큰, 즉 4분의 1만 채웠을 때
00:06:30정확도는 92%입니다. 하지만 끝에 가면 78%로 떨어집니다. 즉, 한 채팅에서 많이 쓸수록 성능이 저하되죠.
00:06:36이것이 사람들이 AI 시스템과 메모리에 대해 겪는 주요 문제 중 하나입니다. Claude Code는
00:06:42이제 100만 컨텍스트를 지원하지만, 여전히 대화 내용을 잊지 않기를 바라기 때문에
00:06:47창을 닫지 않고 계속해서 채워 넣습니다. 그러면 두 가지 일이 발생합니다. 첫째, 보신 것처럼 효율성이 떨어집니다.
00:06:51둘째, 사용량이 엄청나게 늘어납니다. 100만 컨텍스트에서 80만 토큰을 사용하는 것은
00:06:598만 토큰을 사용할 때보다 훨씬 더 많은 비용이 듭니다. 이것만이 유일한 문제는 아니지만,
00:07:08잠시 곁가지로 빠지자면, 현재 생태계의 모든 사람들이 Claude Code가 너프(성능 저하)되었고
00:07:12사용량이 자동으로 급증한다고 불평합니다. 여기에는 여러 이유가 있겠지만,
00:07:18의심할 여지 없이 큰 이유 중 하나는 100만 컨텍스트가 도입된 이후로 사람들이
00:07:24자신의 컨텍스트 윈도우를 관리하는 법을 전혀 모르며, 예전만큼
00:07:29적극적으로 대화를 초기화하고 비우지 않기 때문입니다. 하지만 이건 주제에서 좀 벗어난 얘기죠.
00:07:34이 모든 논의의 핵심은 RAG와 Claude Code의 메모리에 대해 이야기할 때
00:07:39컨텍스트 부패를 항상 염두에 두어야 한다는 것입니다. 우리는 'Claude Code가 여러 가지 질문에
00:07:44답변할 수 있도록 컨텍스트를 주입하고 싶다'는 욕구와, 동시에
00:07:50'컨텍스트가 너무 커져서 성능이 떨어지는 것은 원치 않는다'는 욕구 사이의 긴장을 다뤄야 합니다.
00:07:55메모리에 관한 논의에서 이 점은 항상 생각해야 할 요소입니다.
00:08:02다시 본론으로 돌아와서 1단계에서 사람들은 무엇을 하고 있을까요?
00:08:06답은 '아무것도 하지 않는다'입니다. 아무것도 하지 않기 때문에 그냥
00:08:10비대해진 컨텍스트 윈도우가 모든 걸 기억해 주길 바랄 뿐이죠. 여러분이 CLAUDE.md 파일을
00:08:15단 한 번도 수정한 적이 없고, Claude Code가 과거에 무엇을 했는지와
00:08:23앞으로 무엇을 해야 할지 인지하도록 돕는 어떤 산출물이나 파일도 만든 적이 없다면 이 단계입니다.
00:08:27그럼 이 단계에서 마스터해야 할 것은 무엇일까요? 제가 여기 적어둔 모든 내용에도 불구하고
00:08:31진정으로 마스터해야 할 것은 '오토 메모리만으로는 충분하지 않다'는 점을 이해하는 것입니다.
00:08:35우리는 Claude Code와 메모리 관계에서 능동적인 역할을 해야 합니다. 왜냐하면 이 단계의 함정은
00:08:40능동적인 역할을 하지 않으면 통제권을 잃는다는 것이기 때문입니다. 우리는 Claude Code가
00:08:44우리의 질문에 답할 때 고려하는 요소들을 제어해야 합니다. 1단계를 넘어 2단계로 가기 위해서는
00:08:50'명시적인 메모리'가 필요하며, 이를 실제로 구현하는 방법을 알아내야 합니다.
00:08:57이 관계에서 능동적인 역할을 하기 위해 어떤 파일을 수정하고 이해해야 할까요?
00:09:01이제 2단계는 하나의 특정 파일, 즉 CLAUDE.md 파일에 관한 것입니다. 이 파일을 알게 되면
00:09:06마치 신의 선물처럼 느껴집니다. 마침내 Claude Code가 항상 따르길 원하는
00:09:12규칙과 관습을 한곳에 적어둘 수 있고, AI가 그것을 수행할 것이기 때문입니다.
00:09:16기억하길 바라는 것들을 포함할 수 있고 실제로 기억될 것입니다. 처음에는 확실히 발전처럼 느껴집니다.
00:09:20여기 개인 비서 프로젝트를 위한 표준 CLAUDE.md 파일 템플릿이 있습니다.
00:09:29Claude Code는 자동으로 CLAUDE.md 파일을 생성하지만, 여러분은 이것을
00:09:33수정하거나 `/init` 같은 명령어를 사용하여 필요할 때 업데이트할 수 있는 권한이 있습니다.
00:09:38이 파일의 핵심 아이디어는 특정 프로젝트에 대한 Claude Code의 지침서, 즉 '성배'와 같다는 것입니다.
00:09:43모든 면에서 Claude Code는 어떤 작업을 실행하기 전에 이 파일을 가장 먼저 살펴봅니다.
00:09:50따라서 특정 사항을 기억하게 하고 싶다면 어떻게 해야 할까요? CLAUDE.md에 넣으면 됩니다.
00:09:54이론적으로 이것은 RAG보다는 작은 규모입니다. 여기에 방대한 문서 전체를
00:10:00넣지는 않지만, Claude Code가 항상 기억하길 바라는 내용이나
00:10:05따라야 할 관습들을 넣습니다. 예를 들어 여기에는 '내 정보' 섹션이 있고,
00:10:09파일 시스템의 구조와 명령을 내릴 때 어떻게 작동하길 원하는지에 대한 분석이 들어 있습니다.
00:10:14말씀드린 대로 이것은 기본적으로 모든 프롬프트에서 참조되기 때문에 Claude Code는 이를 아주 잘 따릅니다.
00:10:18그래서 특정 사항을 기억하게 하려는 아이디어에 아주 적합한 장소처럼 보입니다.
00:10:22하지만 주의해야 합니다. 너무 과해질 수 있기 때문이죠. 'Evaluating agents.md'와 같은
00:10:28연구 사례를 보면 (여기서 agents.md를 CLAUDE.md로 바꿔 생각해도 됩니다),
00:10:33이러한 파일들이 대규모 언어 모델 전반의 효율성을 실제로 떨어뜨릴 수 있다는
00:10:40결과가 나왔습니다. 왜 그럴까요? 역설적이게도 이 파일을 아주 좋게 만드는 요소,
00:10:45즉 거의 모든 프롬프트에 주입된다는 사실이 상황을 나쁘게 만들 수도 있기 때문입니다.
00:10:51우리가 실제로 '정확한' 컨텍스트를 주입하고 있는 것일까요? 소음을 뚫고 적절한
00:10:57신호를 주고 있는 것일까요, 아니면 그냥 좋다고 생각하는 것들을 몽땅 던져 넣고 있는 것일까요?
00:11:02프로젝트에서 실행할 거의 모든 프롬프트에 직접적으로 관련이 없는 내용이라면
00:11:08CLAUDE.md에 있어야 할까요? 제 생각에는 그렇지 않습니다.
00:11:15이것은 많은 사람들이 CLAUDE.md의 구조에 대해 말하는 것과는 상반되는 이야기입니다.
00:11:20연구 결과와 제 개인적인 경험에 비추어 볼 때, 적을수록 좋습니다. 컨텍스트 오염과 컨텍스트 부패는 실재합니다.
00:11:26따라서 CLAUDE.md 안에 있는 내용이 여러분이 주는 거의 모든 프롬프트에
00:11:32의미가 없다면, 넣지 말아야 합니다. 하지만 대부분은 이를 깨닫지 못하고
00:11:37비대해진 규칙서라는 함정에 빠집니다. 대신 우리가 마스터해야 할 기술은
00:11:42어떻게 높은 신호(high signal)의 프로젝트 컨텍스트를 만드느냐는 것입니다. 이 파일 안에
00:11:48넣는 내용이 정말 타당한지 확인해야 합니다. 그리고 여기에는 지난 단계에서 말한
00:11:53컨텍스트 부패에 대한 인식이 수반됩니다. 이 모든 것을 종합해 볼 때, 2단계는
00:11:57'내가 메모리에 능동적인 역할을 하고 있고 CLAUDE.md 파일도 있다'며 앞으로 나가는 기분이 들게 합니다.
00:12:02하지만 곧 이것만으로는 충분하지 않다는 것을 깨닫게 됩니다. 이제 3단계와
00:12:08거기서 더 나아갈 수 있는 방법에 대해 이야기할 때, 우리는 정적인 규칙서가 아니라
00:12:14진화할 수 있는 무언가를 생각해야 합니다. 또한 CLAUDE.md에만 모든 걸 의존하는 대신,
00:12:18CLAUDE.md를 Claude Code에게 올바른 방향을 알려주는 일종의 인덱스 파일로 활용하면 어떨까요?
00:12:24CLAUDE.md가 인덱스 역할을 하며 다른 파일들을 가리킨다는 게 무슨 뜻일까요?
00:12:30코드베이스 내의 아키텍처에 대해 말하는 것입니다. 단 하나의 마크다운 파일(CLAUDE.md)이
00:12:37모든 메모리 문제를 해결하려고 애쓰는 구조가 아닙니다. 대신 특정 작업들을 위해
00:12:41여러 개의 파일을 두는 것을 의미합니다. 이에 대한 아주 좋은 예시가 바로 GSD(Get Shit Done)”라는 오케스트레이션
00:12:47도구입니다. 이 도구는 '이걸 만들 거고, 이건 요구 사항이고, 이건 우리가 한 일이고,
00:12:53이건 앞으로 갈 방향이야'라고 말하는 파일을 단 하나만 만들지 않습니다.
00:12:56대신 여러 개를 만듭니다. 왼쪽을 보시면 project.md, requirements.md,
00:13:02roadmap.md, state.md가 있습니다. 요구 사항 파일은 Claude Code가 자신이 무엇을
00:13:08만들어야 하는지 항상 알고 기억할 수 있게 해줍니다. 로드맵은 우리가 지금 만들고 있는 것뿐만 아니라
00:13:12과거에 한 일과 미래에 할 일을 구체적으로 세분화합니다. 그리고 프로젝트 파일은
00:13:16우리가 높은 수준에서 무엇을 하고 있는지, 우리의 북극성이 무엇인지에 대한 컨텍스트와 메모리를 제공합니다.
00:13:22이런 시스템으로 메모리, 컨텍스트, 관습을 쪼개 놓음으로써 우리는 컨텍스트 부패,
00:13:29그리고 아까 연구에서 언급된 문제를 방지할 수 있습니다. 모든 프롬프트에 이런 파일들을
00:13:34항상 주입하는 것은(CLAUDE.md처럼) 사실 직관에 반하며, 더 나은 결과를 얻는 데 도움이 되지 않습니다.
00:13:39더 나아가, 정보를 덩어리(chunk)로 나누고 Claude Code가 따라갈 수 있는 명확한 경로를
00:13:44제시해 주는 것이 좋습니다. '이 정보가 어디 있는지 찾고 싶어? 아, CLAUDE.md로 가자.
00:13:49CLAUDE.md에 다섯 가지 옵션이 있네. 좋아, 그중 하나가 이거군. 가서 찾아보자'와 같은 식이죠.
00:13:54자주 말씀드리겠지만, 이게 여러분에게 무엇을 의미할까요? 우리가 4단계에서 다룰 시스템이 정말 필요할까요?
00:13:58진정한 RAG 시스템에서 볼 수 있는 청킹(chunking) 시스템과
00:14:04벡터 유사도 검색을 투박하게나마 재구성한 것이라고 볼 수 있습니다. 물론 이 단계는 아직
00:14:10규모가 작습니다. 마크다운 파일 네 개 정도를 다루는 수준이지,
00:14:14수천, 수만 개의 문서를 처리할 수 있는 시스템을 말하는 것이 아닙니다. 하지만 제가
00:14:20자주 강조하는 것이 있습니다. 이것이 '당신'에게 어떤 의미인가요? 여러분에게 정말로
00:14:264, 5, 6, 7단계에서 다룰 그 많은 문서를 처리할 수 있는 시스템이 필요한가요?
00:14:32대답은 '아닐 수도 있다'입니다. 따라서 이 RAG 여정의 핵심은 현재 여러분의 위치뿐만 아니라
00:14:36실제로 어디까지 가야 하는지를 이해하는 것입니다. Claude Code 내부에 항상
00:14:417단계 수준의 Agentic RAG 시스템을 구축할 필요가 있을까요? 하는 법을 아는 건 좋지만,
00:14:46그것을 구현할 필요가 없는 때를 아는 것도 그만큼 중요합니다. 때로는
00:14:52지금 보시는 이 정도의 시스템만으로도 많은 사람들에게 충분합니다. 따라서 그것을
00:14:58할 줄 아는 것과, 정말 해야 하는지를 아는 것 모두 중요합니다. 3단계와 상태(state) 파일에 대해
00:15:00이야기할 때, 우리가 이 단계에 있다는 걸 어떻게 알 수 있을까요? 아직 엄격하게
00:15:04Claude Code 생태계 안에 있고 외부 도구나 앱을 통합하지 않았을 때입니다.
00:15:09단지 여러 마크다운 파일을 만들어 자신만의 가내수공업식 메모리 청킹 시스템을 만든 상태죠.
00:15:14하지만 이것 역시 정말 중요합니다. 여기서도 진정한 기술들을 마스터하고 있으니까요.
00:15:18문서를 구조화하고, 매 세션마다 상태를 업데이트하는 시스템을 갖추는 것 등입니다.
00:15:23이것은 RAG에서도 문제가 될 수 있습니다. 모든 것을 어떻게 최신 상태로 유지할 것인가 하는 문제죠.
00:15:28그리고 아마도 이 시점에서는 GSD나 Superpowers 같은 오케스트레이션 레이어에
00:15:33의존하기 시작했을 것입니다. 이런 도구들은 멀티 마크다운 파일 아키텍처를 스스로 수행합니다.
00:15:40하지만 여기엔 실질적인 함정이 있습니다. 이 프로젝트에서 만든 것은 오직 그 프로젝트만을 위한 것입니다.
00:15:46그 마크다운 파일들을 다른 프로젝트로 옮기는 과정이 꽤나 번거롭고 투박하죠. 그래서
00:15:514단계에서는 Obsidian을 도입합니다. 이 도구는 요즘 엄청난 주목을 받고 있는데
00:15:56그럴 만한 이유가 있습니다. Andrej Karpathy 같은 분들이
00:16:00자신이 만든 LLM 지식 베이스에 대해 이야기할 때, 그것은 사실상
00:16:06Obsidian 기반으로 구축된 것입니다. 조회수가 2천만 회에 육박하니 우리도 그 원리를 살펴봐야 합니다.
00:16:11참고로 저는 이 'Andrej Karpathy 스타일의 Obsidian LLM 지식 베이스'에 대해
00:16:18이미 깊이 있게 다룬 영상이 있으니 위에 링크를 걸어두겠습니다. 구축 방법이 궁금하다면 확인해 보세요.
00:16:22그리고 제가 강조하고 싶은 점은, 지금 이야기하는 이 4단계 수준의 Obsidian 활용이
00:16:27사실상 대부분의 사람들이 목표로 삼아야 할 단계라는 것입니다.
00:16:32대부분의 사람과 사용 사례에서는 이것으로 충분하기 때문입니다. 5, 6, 7단계에서
00:16:37진정한 RAG 구조를 다루겠지만, 솔직히 말해서 대부분의 사람들에게는 과유불급입니다.
00:16:43정말 그렇습니다. 우리가 RAG에 대해 이야기하는 걸 좋아하긴 하지만요.
00:16:50Obsidian은 비용이 들지 않고 관리 부담이 거의 없으면서도 1인 운영자에게는
00:16:5680%를 넘어 99%의 해결책이 되어줍니다. 1인 운영자에게 충분하다는 말은,
00:17:02Claude Code를 수많은 문서와 마크다운 파일에 연결하고, 그로부터
00:17:07정확하고 시의적절한 정보를 얻어내는 문제를 해결해 준다는 뜻입니다. 또한 사람이
00:17:13직접 문서를 클릭했을 때 내부에서 무슨 일이 일어나고 있는지 통찰력을 얻을 수 있습니다.
00:17:19어떤 문서들이 서로 연결되어 있는지 아주 명확하게 보입니다. 링크를 클릭하면
00:17:24다른 문서로 이동하고, 또 클릭하면 더 많은 문서로 이어집니다.
00:17:30사람인 우리에게 이런 통찰력을 갖는 것은 매우 중요합니다.
00:17:36솔직히 말씀드리면, Obsidian 기반으로 얻는 문서에 대한 통찰력이
00:17:42수만 개의 문서를 GraphRAG 같은 시스템에 임베딩해서 얻는 통찰력보다 더 낫다고 생각합니다.
00:17:47수천 수만 개의 문서가 이런 그래프 RAG 시스템에 임베딩되어 있는 것을 보면 비주얼은 아주 훌륭합니다
00:17:52정말 멋져 보이죠. 하지만 실제로 그 안에서 무슨 일이 일어나는지 정확히 아시나요? 솔직히 알 수도 있겠지만
00:17:58어느 정도는 보여지는 답변과 링크 등에 의존하게 됩니다. 하지만 임베딩을 하나하나 파악하는 것은 확실히 어렵습니다
00:18:03결론은 옵시디언과 클로드 코드를 특별히 주목해야 한다는 것입니다. 왜냐하면 RAG로 가는 여정에서
00:18:08저는 항상 고객을 포함한 모든 분께 제안합니다. 일단 옵시디언으로 시작해서 어디까지 확장 가능한지 확인해 보자고요
00:18:13그러다 결국 한계에 부딪히면 그때 더 강력한 RAG 시스템으로 전환하면 됩니다
00:18:20그러니 왜 간단한 옵션을 먼저 시도하지 않겠습니까? 잘 작동한다면 비용도 들지 않고 공짜니까요
00:18:26반면 처음부터 RAG 시스템을 구축하려 한다면 무엇을 하려느냐에 따라 실제 운영 환경에 적용하기가 꽤 까다로울 수 있습니다
00:18:31항상 간단한 것부터 시작하세요. 더 복잡한 것으로 전환하는 것은 언제든 어렵지 않습니다
00:18:35그럼 레벨 4에서 우리가 정말로 이야기하려는 것은 무엇일까요? 레벨 3에서 구축하기 시작했던
00:18:40그 구조를 가져오는 것입니다. 인덱스 파일이 여러 마크다운 파일을 가리키던 구조 말이죠
00:18:45그것을 확장하고 옵시디언이라는 외부 도구를 도입해서, 인간인 여러분이
00:18:50이러한 연결 관계를 실제로 쉽게 볼 수 있게 만드는 것입니다. 이 버전의 가장 이상적인 형태는
00:18:56안드레 카파시가 제시한 방식과 거의 비슷합니다. 옵시디언 위에 LLM 지식 베이스를 구축하고
00:19:00클로드 코드로 구동하는 것이죠. 그 구조는 다음과 같습니다. 옵시디언을
00:19:05다운로드하면(다시 말하지만 완전 무료입니다. 이전에 올린 영상을 참고하세요) 특정 폴더를
00:19:11보관소(Vault)로 설정하게 됩니다. 이 보관소를 여러분이 만든 일종의 RAG 시스템,
00:19:16즉 '유사 RAG' 시스템이라고 생각하시면 됩니다. 보관소 내부의 아키텍처는
00:19:23단순히 파일들로 구성합니다. 'Vault'라는 최상위 폴더가 있고 그 안에
00:19:30여러 하위 폴더를 만듭니다. 안드레 카파시의 경우에는 세 개의 서로 다른 하위 폴더를 언급하는데
00:19:36사실 어떤 하위 폴더든 상관없습니다. 우리가 이야기할 테마에 맞추기만 하면 됩니다
00:19:41한 폴더에는 원본 데이터(raw data)가 들어갑니다. 이는 우리가 수집한 모든 것이며 나중에
00:19:47클로드 코드가 참조할 수 있도록 구조화할 대상입니다. 예를 들어 클로드 코드에게
00:19:52경쟁사 50곳을 분석하게 하고 각 경쟁사마다 50개의 사이트 정보를 가져오게 한다고 가정해 봅시다
00:19:58이것은 방대한 양의 정보입니다. 아마 약 2,500개의 데이터가 될 텐데,
00:20:03이 모든 것이 일종의 'raw' 폴더로 들어갑니다. 데이터의 스테이징 영역 같은 곳이죠
00:20:08그다음에는 위키(wiki) 폴더가 있습니다. 위키 폴더는 구조화된 데이터가 들어가는 곳입니다
00:20:14클로드 코드가 이 원본 데이터를 가져와서 본질적으로 서로 다른
00:20:20위키피디아 스타일의 문서로 구조화하여 위키 폴더에 넣습니다. 각 문서(article)는 각자의 폴더를 갖습니다
00:20:28이제 여러분이 클로드 코드에게 정보를 물어본다고 해봅시다. 예를 들어
00:20:33AI 에이전트에 대한 정보를 검색하게 했다면, 제가 "클로드 코드, AI 에이전트에 대해 알려줘"라고 말할 때
00:20:38마치 RAG 시스템에 쿼리를 던지는 것과 같습니다. 그러면 클로드 코드는 보관소로 가서
00:20:45위키 폴더로 들어갑니다. 위키 폴더에는 마스터 인덱스 마크다운 파일이 있습니다
00:20:50이전에 `claud.md`로 하려 했던 작업과 비슷하다고 생각하시면 됩니다. 레벨이 올라가도
00:20:56이런 테마들이 어떻게 이어지는지 보이시죠? 클로드는 마스터 인덱스를 살펴봅니다. 마스터 인덱스는
00:21:00이 옵시디언 RAG 시스템에 무엇이 있는지 알려줍니다. "오, AI 에이전트가 있네?" 하고 말이죠
00:21:08또한 존재하는 개별 문서들에 대해 설명하는 인덱스 파일도 가지고 있습니다. 제가 말하려는 것은
00:21:14클로드 코드가 정보를 찾고 싶을 때 참조할 수 있는 명확한 계층 구조가 있다는 것입니다
00:21:21Vault, Wiki, Index, Article 등으로 이어지는 구조죠. 정보를 찾는 방법이 매우 명확하고
00:21:31정보를 찾아 위키로 만드는 방법도 명확하기 때문에, RAG 없이도 수많은 문서를 가진
00:21:37시스템을 구축할 수 있습니다. 제대로만 한다면 수백, 수천 개의 문서도 가능합니다
00:21:44왜냐하면 시스템이 명확하게 "보관소를 확인하고 인덱스를 확인하면 모든 위치가 구분되어 있다"면
00:21:50클로드 코드가 무엇을 어디서 찾을지 파악하는 게 그리 어렵지 않기 때문입니다
00:21:54그래서 RAG가 아닌 구조로도 수천 개의 문서를 처리할 수 있습니다. 과거에는 이게 정말 힘들었는데
00:21:58대부분의 사람들이 아무런 구조 없이 데이터를 쌓아두기 때문입니다. 그냥 폴더 하나에 수억 개의
00:22:02파일을 흩뿌려 놓은 것과 같죠. 공장 바닥에 천만 개의 파일이 널려 있는 격입니다
00:22:08클로드 코드가 그걸 찾을 수 있을까요? 아니요, 사실 서류함만 있으면 됩니다. 클로드 코드는
00:22:13생각보다 꽤 똑똑하거든요. 그 아키텍처가 실제로 작동하는 모습을 여기서 볼 수 있습니다
00:22:17지금 보시는 것은 옵시디언 보관소 안에 있는 `claud.md` 파일입니다. 여기에는 무엇이 적혀 있을까요?
00:22:24보관소 구조와 위키 시스템, 즉 하위 폴더의 전반적인 구조와
00:22:30기본적인 작동 방식이 정리되어 있습니다. 여기서도 `claud.md`를 일종의 컨벤션 파일로 사용하고 있죠
00:22:36왼쪽을 보시면 위키 폴더가 있고 그 안에 마스터 인덱스가 있으며 그 내용들이 나열되어 있습니다
00:22:43여기서는 문서가 하나뿐이네요. 'claud managed agents'에 관한 것입니다. 그 폴더를 열면
00:22:49해당 주제에 대한 자체 위키 폴더가 있고, 실제 문서에 도달할 때까지 내용이 세분화되어 있습니다
00:22:55수행해야 할 단계가 매우 명확합니다. 그래서 제가 클로드 코드에게
00:23:01매니지드 에이전트에 대해 알려달라고 하면, 이미 위키가 있기 때문에 내장된 grep 도구로
00:23:06매우 쉽게 검색할 수 있습니다. 클로드는 실제 마크다운 파일을 링크하고 모든 내용을 요약해 줍니다
00:23:12이제 레벨 4에서의 관건은 규모(scale)의 문제입니다. 이런 방식의 시스템이
00:23:16계속해서 잘 작동하려면 얼마나 많은 문서까지 가능할까요? 안드레 카파시의 시스템이
00:23:22무너지기 시작하는 지점이 있을까요? 클로드 코드가 따라가야 할 경로가 명확하고
00:23:26인덱스를 참조하는 등의 과정이 2,000개, 2,500개, 3,000개의 문서에서도 유지될 수 있을까요?
00:23:31명확한 숫자가 있을까요? 정답은 '우리도 잘 모른다'입니다. 그리고 그 숫자는 더 낮을 수도 있습니다
00:23:37왜냐하면 여러분의 문서가 모두 제각각이기 때문입니다. 한계에 부딪히는 것은 단순히
00:23:43클로드 코드가 잘못된 답을 내놓거나 옵시디언 시스템에 파일이 너무 많아서가 아닙니다
00:23:47파일을 이렇게 많이 추가했을 때 토큰 비용은 얼마나 드는지, 그리고
00:23:52얼마나 빨리 처리하는지의 문제입니다. 특정 상황에서 RAG는 훨씬 더 빠르고 저렴할 수 있기 때문입니다
00:23:59여기서 보고 계신 것은 텍스트 기반 LLM(거대한 막대 그래프)과 텍스트 기반 RAG를 비교한 것입니다
00:24:06정확한 답변을 얻기 위해 사용된 토큰의 양과 답변을 얻는 데
00:24:11걸린 시간을 비교하고 있죠. 결과가 어떤가요? 텍스트 기반 RAG와 텍스트 기반 LLM 사이에는
00:24:18엄청난 차이가 있습니다. 약 1,200배 정도의 차이가 나죠. 저는 이 연구 결과를 토대로
00:24:25RAG가 텍스트 기반 LLM보다 1,200배 더 저렴하고 1,200배 더 빠르다고 말씀드리는 것입니다
00:24:33참고로 이 연구는 2025년에 수행되었으며 클로드 코드로 진행된 것은 아닙니다. 그 이후로
00:24:37모델들이 크게 변했죠. 이건 단순한 LLM들을 대상으로 한 것이지 코딩 에이전트 등은 아닙니다
00:24:48하지만 우리는 1,200배라는 차이에 대해 이야기하고 있습니다. 그러니 옵시디언 방식을 쓸지
00:24:54아니면 RAG 시스템을 구축할지 평가할 때, 단순히 정답을 맞히느냐 아니냐의 문제가 아닙니다
00:24:59옵시디언으로 정답을 얻을 수는 있지만 RAG를 쓰면 1,000배 더 저렴하고
00:25:04빠른 시나리오가 있을 수 있다는 거죠. 그래서 언제 옵시디언이 충분히 좋은지,
00:25:10언제 마크다운 파일 아키텍처로 충분한지, 아니면 언제 RAG가 필요한지의 경계는 매우 모호합니다
00:25:15명확한 답은 없습니다. 저도 여러분께 드릴 정답은 없고요. 여러분이 직접 실험해 보고
00:25:18둘 다 시도해서 무엇이 효과적인지 확인해야 합니다. 2025년의 이 수치는 구형 모델 기준이라
00:25:25RAG와 텍스트 LLM의 차이가 1,200배까지는 아닐 겁니다. 하지만 그 격차가 얼마나 줄었을까요?
00:25:3210배도 아니고 1,200배라는 수치는 엄청난 격차입니다. 알아야 할 것이 많고,
00:25:39미리 정답을 알 수는 없습니다. 어떤 영상을 보더라도
00:25:45어디가 한계선인지 아무도 말해주지 않을 겁니다. 여러분이 직접 실험하면서
00:25:49클로드 코드에게 질문할 문서의 양을 늘려가며 무엇이 적합한지 확인해야 합니다
00:25:54그런 의미에서 이제 레벨 5로 넘어가 보겠습니다. 여기서 드디어
00:25:59진짜 RAG 시스템에 대해 이야기하고 임베딩, 벡터 데이터베이스와 같은 RAG의 기본 요소들,
00:26:04그리고 데이터가 RAG 지식 베이스의 일부가 될 때 어떻게 흐르는지 알아볼 것입니다
00:26:10가장 기본적인 형태인 '나이브 RAG(Naive RAG)'부터 시작해 보죠. 가장 기초적이지만
00:26:16우리가 하는 모든 작업의 근간이 됩니다. RAG 시스템은 크게
00:26:21세 부분으로 나뉜다고 생각하시면 됩니다. 왼쪽에는 임베딩 단계가 있고
00:26:27그다음 벡터 데이터베이스가 있으며, 마지막으로 대규모 언어 모델을 통한 실제 검색 과정이 있습니다
00:26:331, 2, 3단계죠. 이 모델을 가장 잘 설명하기 위해
00:26:40지식 베이스의 일부가 될 문서가 어떤 과정을 거치는지 살펴보겠습니다. 대규모 RAG 시스템에서는
00:26:45수천 개의 문서를 다룰 수 있고 각 문서는 수천 페이지일 수도 있지만,
00:26:50이 예시에서는 한 페이지짜리 문서를 예로 들어보겠습니다
00:26:56우리가 이 문서를 데이터베이스에 추가하고 싶을 때, 문서 전체를
00:27:03통째로 가져오지는 않습니다. 대신 이 문서를 가져와서
00:27:08여러 조각으로 쪼개는 '청킹(chunking)' 과정을 거칩니다. 이 한 페이지짜리 문서는
00:27:15본질적으로 세 개의 청크가 됩니다. 이 세 청크는 임베딩 모델로 전송되고
00:27:21임베딩 모델은 이 청크들을 벡터 데이터베이스의 벡터(vector)로 변환하는 역할을 합니다
00:27:27벡터 데이터베이스는 일반적인 데이터베이스의 변형이라고 생각하시면 됩니다
00:27:32표준 데이터베이스라고 하면 엑셀 파일처럼 행과 열로 이루어진 형태를 떠올리시겠지만
00:27:37벡터 데이터베이스는 2차원 행과 열이 아니라 수백, 수천 개의 차원을 가집니다
00:27:43하지만 오늘은 이해를 돕기 위해 여기 보이는 것과 같은 3차원 그래프라고 생각합시다
00:27:50벡터는 그 그래프 상의 점들이고 각 점은 일련의 숫자들로 표현됩니다
00:27:57여기 '바나나(bananas)'가 있고 0.52, 5.12, 9.31로 표현된 것을 볼 수 있습니다
00:28:06이런 숫자들이 수백 개나 이어지죠. 거대한 다차원 그래프에서 각 벡터가
00:28:13어디에 위치할지는 '시맨틱 의미(semantic meaning)', 즉 단어의 실제 의미에 따라 결정됩니다
00:28:19보시는 것처럼 이쪽은 과일 섹션이라 바나나, 사과, 배가 있고, 저쪽은 배(ships, boats)들이 모여 있습니다
00:28:24다시 우리 문서로 돌아가서, 이 문서가 제2차 세계 대전의 군함에 관한 것이라고 가정해 봅시다
00:28:31그러면 각 청크는 일련의 숫자로 변환될 것이고
00:28:37그 숫자들은 이 그래프에서 하나의 점으로 표시될 것입니다. 어디로 갈 것 같나요? 아마도
00:28:42이 근처로 가겠죠. 1, 2, 3번 청크가요. 이것이 문서가 배치되는 방식입니다
00:28:49모든 문서는 청킹 과정을 거치고, 각 청크는 임베딩 모델을 통해 벡터 데이터베이스에 삽입됩니다
00:28:54수천 번 반복하다 보면 결국 우리의 지식 그래프, 즉 지식 베이스를
00:28:58대표하는 벡터 데이터베이스가 완성됩니다. 이제 3단계인 검색(retrieval) 부분으로 넘어가죠
00:29:04여기서 여러분은 어떤 역할을 할까요? 여러분을 다른 색깔로 표현해 보죠
00:29:09분홍색으로 하겠습니다. 자, 이게 여러분입니다. 여러분은 평소처럼
00:29:16클로드 코드에게 말을 걸고 제2차 세계 대전의 전함에 대해 질문을 던집니다
00:29:23일반적인 비 RAG 환경에서는 어떤 일이 벌어질까요? 대규모 언어 모델인 Opus 4.6이
00:29:29자신의 학습 데이터를 살펴보고 그 데이터를 바탕으로 답변을 줄 것입니다
00:29:342차 대전 전함에 대한 정보를요. 하지만 RAG 시스템에서는 더 많은 일을 합니다
00:29:39적절한 벡터들을 검색해 오고 그 벡터들을 사용하여 답변을 보강합니다
00:29:44그래서 '검색 보강 생성(Retrieval Augmented Generation)'이라고 부르는 것입니다
00:29:51이것이 RAG의 힘입니다. 대규모 언어 모델이 자신의 학습 데이터에 포함되지 않은
00:29:56정보를 끌어와서 답변을 보강할 수 있게 해줍니다. 이 예시에서는 2차 대전 전함이지만
00:30:02언어 모델이 이미 알고 있는 정보 대신, 웹에서 쉽게 구할 수 없는
00:30:06기업의 독점적인 대규모 데이터를 대입해 보세요. 그것이 RAG의 핵심 셀링 포인트입니다
00:30:15우리의 예시에서 RAG 설정으로 클로드 코드에게 2차 대전 전함 정보를 물어보면
00:30:21클로드는 우리의 질문을 가져와서 이쪽의 벡터들과 유사한
00:30:25일련의 숫자들로 변환합니다. 그런 다음 우리 질문의 숫자와
00:30:32벡터들의 숫자를 비교해서 어떤 벡터가 질문 벡터와 가장 유사한지 확인합니다
00:30:39질문과 벡터가 얼마나 비슷한지 따져보는 거죠. 그리고 상위 몇 개의 벡터를
00:30:46가져옵니다. 그게 1개든 5개든 20개든 말이죠. 클로드는 그 벡터들과
00:30:51거기에 담긴 정보를 대규모 언어 모델로 끌어옵니다. 이제 언어 모델은
00:30:56자신의 학습 데이터 기반 답변에 10개 정도의 벡터 정보를 더하게 됩니다. 이게 '검색' 단계죠
00:31:02그 추가 정보를 바탕으로 답변을 보강하고 생성합니다. 이것이 RAG가 작동하는 방식이고
00:31:09나이브 RAG가 작동하는 방식입니다. 하지만 이 방식은 여러 이유로 그리 효과적이지 않습니다
00:31:13이런 기본적인 구조는 처음부터 무너지기 쉬운데, 먼저 이런 문서들을
00:31:19어떻게 청킹할 것인가의 문제가 있습니다. 무작위로 할까요? 단순히 토큰 수에 맞출까요?
00:31:25일정한 중첩(overlap)을 둘까요? 문서 자체가 청킹하기에 적합한 구조인가요?
00:31:31예를 들어 3번 청크가 1번 청크의 내용을 참조하고 있는데, 우리가 청크를 불러올 때
00:31:36필요한 맥락이 담긴 다른 청크를 가져오지 못하면 어떻게 될까요?
00:31:42그럼 3번 청크의 내용이 말이 될까요? 아시겠지만 종종 질문에 답하기 위해
00:31:47문서 전체가 필요한 경우가 많습니다. 그래서 이렇게 조각난 답변을 얻는 방식은
00:31:53실제 상황에서 잘 작동하지 않습니다. 그럼에도 아주 오랫동안 RAG는 이런 식으로 설정되어 왔습니다
00:31:59다른 문제들도 있습니다. 서로 다른 벡터들 간의 관계에 대해
00:32:05질문하고 싶다면 어떻게 될까요? 현재 방식은 각 벡터를 독립적으로 가져오기 때문입니다
00:32:10만약 제가 보트와 바나나가 어떤 관계인지 알고 싶다면요? 무작위한 질문 같지만
00:32:17이런 표준적인 벡터 데이터베이스 기반의 나이브 RAG 접근 방식에서는 모든 게 고립되어 있어서
00:32:22정보를 연결하기 어렵습니다. 그리고 많은 부분이 원래의 문서들이 애초에
00:32:31RAG를 하기에 적절한 구조로 되어 있는지에 달려 있습니다
00:32:36수년에 걸쳐 우리는 이런 문제들을 완화할 방법들을 찾아냈습니다
00:32:41리랭커(re-ranker)나 우리가 가져온 모든 벡터를 살펴보고 언어 모델로 다시 한번
00:32:46관련성 순위를 매기는 시스템 같은 것들 말이죠. 하지만 전반적으로 이 나이브 RAG 시스템은
00:32:51유행이 지났습니다. 그럼에도 이 기초적인 작동 방식을 이해하는 것은 여전히 중요합니다
00:32:56더 강력한 RAG 접근 방식을 선택할 때 정보에 입각한 결정을 내릴 수 있게 해주니까요
00:33:03청킹이나 임베딩이 어떻게 작동하는지 모른다면 어떻게 문서 구조를 결정할 수 있겠습니까?
00:33:07그래프 RAG(graphrag)나 더 복잡한 임베딩 시스템에 대해 이야기할 때 말이죠
00:33:13구글에서 새로 나온 시스템은 텍스트뿐만 아니라 영상까지 처리할 수 있습니다. 이런 기초를
00:33:17모른다면 여러분은 '함정'을 이해하기 어려울 것입니다. 그 함정이란
00:33:22우리가 결국 형편없는 검색 엔진을 만들었다는 것입니다. 청크만 가져오고
00:33:27그들 사이의 관계를 이해할 수 없는 나이브 RAG 시스템이
00:33:31지나치게 복잡한 'Control+F' 시스템과 무엇이 다를까요? 사실 별 차이가 없습니다
00:33:36그래서 여전히 도처에 널려 있는 이런 단순하고 구식인 RAG 구조들,
00:33:42가령 "여기 내 파인콘(Pinecone) RAG 시스템이 있어" 혹은 "슈퍼베이스(Supabase) RAG야"라고 하면서
00:33:48그래프 RAG나 정교한 리랭커 시스템에 대해 언급하지 않는다면
00:33:54그건 형편없을 겁니다. 실제 정확도가 25% 정도밖에 안 될 수도 있죠
00:33:58거의 찍는 게 나을 정도입니다. 이걸 모르면 속거나 혼란스러울 수 있고
00:34:03심지어 말도 안 되는 RAG 시스템을 구매하는 사기를 당할 수도 있습니다
00:34:07그래서 레벨 5는 이런 나이브 RAG를 구현하는 법을 배우는 게 아니라
00:34:12더 정교한 것을 구현해야 할 때 무슨 일이 일어나고 있는지 이해하기 위해 그 원리를 아는 것입니다
00:34:18RAG에 대한 이 5분짜리 설명조차 대부분의 사람들은 제대로 이해하지 못하고
00:34:23"RAG 시스템이 필요해"라고 말하곤 합니다. 글쎄요, 정말 필요하신가요?
00:34:28시스템에 어떤 종류의 질문을 던지고 계신지 스스로 물어봐야 합니다
00:34:34지식 베이스를 단순히 거대한 규칙 모음집으로 취급하고 거기서 특정 정보를
00:34:38끄집어내기만 하면 된다면, 옵시디언으로 충분하거나 나이브 RAG로도
00:34:43해결될 수 있습니다. 하지만 정보 사이의 관계를 알아야 한다면,
00:34:48X와 Y가 어떻게 상호작용하는지 알아야 하는데 그들이 서로 다른 문서에 있고
00:34:54서로를 직접 언급하지도 않으며, 그런 문서가 수천 개라 컨텍스트에 다 넣을 수도 없다면
00:34:59그때가 바로 RAG가 필요한 시점이고 기본 벡터 RAG보다 더 정교한 것이
00:35:02필요한 때입니다. 그때부터 우리는 그래프 RAG에 대해 이야기해야 합니다
00:35:09그래서 클로드 코드와 RAG의 레벨 6에서 다룰 주제가 바로 그래프 RAG입니다
00:35:13제 생각에 여러분이 RAG를 사용한다면 이것이 구축해야 할 인프라의 최저 기준입니다
00:35:19완전 오픈 소스 도구인 LightRAG를 사용하는 방식인데, 제가 자세히 분석하고
00:35:23구축법을 설명한 영상 링크를 위에 달아두겠습니다. 그래프 RAG의 개념은 꽤 명확합니다
00:35:29모든 것이 연결되어 있다는 생각이죠. 벡터들이 고립된 벡터 데이터베이스가 아니라
00:35:34서로 연결되어 있는 구조입니다. 문서를 클릭하면 화면 오른쪽에서(제가 옮겨보겠습니다)
00:35:39벡터의 설명, 이름, 타입, 파일, 청크, 그리고 더 중요한 다양한 관계들을 볼 수 있습니다
00:35:44이런 관계 기반의 접근 방식은 더 효과적인 결과로 이어집니다. 여기 LightRAG 깃허브의 차트가 있습니다
00:35:50약 6~8개월 전 자료이며, LightRAG는 제가 아는 한 가장 가벼운
00:35:55그래프 RAG 시스템입니다. 마이크로소프트의 GraphRag처럼 아주 강력한 버전들도 있죠
00:36:00이름 자체가 그냥 Graph Rag입니다. 나이브 RAG와 LightRAG를 전반적으로 비교해 보면
00:36:05종종 100% 이상의 성능 향상을 보입니다. 31.6 대 68.4,
00:36:1024 대 76, 24 대 75 등등 계속 이어집니다. 그리고 LightRAG에 따르면
00:36:15자신들이 원래의 GraphRag보다 더 낫다고 하니, 그 부분은 어느 정도 걸러서 들으시고요
00:36:23이 지식 그래프 시스템을 보면 바로 옵시디언이 떠오르실 겁니다. 비주얼이 매우 비슷하거든요
00:36:30하지만 우리가 옵시디언에서 보는 것은 LightRAG나 다른 그래프 RAG 시스템에서
00:36:35옵시디언의 방식은 LightRAG나 다른 GraphRAG 시스템에서 일어나는 과정보다 훨씬 더 원시적입니다
00:36:4324 대 76, 24 대 75 등으로 계속 이어집니다. LightRAG에 따르면
00:36:49GraphRAG 자체보다 성능이 뛰어나다고 하지만, LightRAG의 수치이니 어느 정도 걸러서 들으세요.
00:36:54이제 이 지식 그래프 시스템을 보면 바로 Obsidian이 떠오르실 겁니다.
00:36:58모양은 매우 비슷해 보이니까요. 하지만 Obsidian에서 보는 것은
00:37:04LightRAG나 다른 GraphRAG 시스템에서 일어나는 일보다 훨씬 더 초보적인 수준입니다.
00:37:10왜냐하면 여기서 보는 일련의 연결들은 모두 수동적이고 다소 임의적이기 때문입니다.
00:37:16우리가 관련 문서를 설정했거나, Claude Code가 이 문서를 생성할 때
00:37:22관련 문서를 설정했기 때문에 연결된 것뿐이죠. 대괄호 몇 개만 추가하면 바로 연결됩니다.
00:37:27이론적으로는 실제로는 아무런 상관도 없는 무작위 문서들을 대량으로 연결할 수도 있습니다.
00:37:30물론 Claude Code가 멍청하지 않으니 그러지는 않겠지만, 여기 시스템과는 많이 다릅니다.
00:37:35여기서는 실제 임베딩 시스템을 거쳐서 실제 내용을 분석하고
00:37:41관계와 엔티티를 설정했습니다. Obsidian보다 관계를 정의하는 면에서
00:37:46LightRAG 내부적으로 훨씬 더 많은 작업이 이루어지고 있는 것이죠. 그렇다면 이 차이가
00:37:52실제로 저수준에서 엄청난 성능 차이를 만들어낼까요? 거대한 규모라면 아마 그럴 겁니다.
00:38:02다시 말하지만, 이는 규모와 구체적인 대상에 따라 달라지는 회색 지대에 있습니다.
00:38:07본인 외에는 아무도 그 질문에 답할 수 없으며 개인적인 경험이 필요하겠지만,
00:38:13이 두 가지가 같지 않다는 점을 이해해야 합니다. 완전히 다른 시스템입니다.
00:38:20하나는 꽤 정교하고 하나는 꽤 원시적입니다. 그 점을 이해하시고, GraphRAG의 레벨 6를 요약하자면
00:38:26Obsidian 같은 방식이 통하지 않고, Naive RAG를 사용할 수 없다는 결론이 났을 때입니다.
00:38:31성능이 나오지 않아 엔티티와 관계를 추출해야 하고,
00:38:36하이브리드 벡터 및 그래프 쿼리 시스템 설계를 진정으로 활용해야 할 단계인 거죠.
00:38:43하지만 여기 레벨 6에도 몇 가지 함정과 심각한 장애물이 있습니다.
00:38:48LightRAG에 대해 말할 때, 이건 그저 텍스트일 뿐입니다. 스캔한 PDF나
00:38:55비디오, 이미지가 있다면 어떨까요? 모든 문서가 구글 문서인 세상은 아닙니다.
00:39:01그래서 그런 경우에는 어떻게 해야 할까요? 멀티모달 검색은 매우 큰 과제이며,
00:39:06거기에 더해 이러한 시스템에 에이전트적인 특성을 부여해 AI 성능을 높여준다면 어떨까요?
00:39:11멀티모달에 대해 이야기한다면, 마침내 오늘날 RAG의 최첨단 단계로 이동할 수 있습니다.
00:39:172026년 4월 기준으로, 그것이 바로 레벨 7이 다루는 내용입니다.
00:39:24이제 레벨 7과 에이전틱 RAG에 대해 이야기할 때, 우리가 집중해야 할 큰 부분은
00:39:31멀티모달 데이터 수집(Ingestion)과 관련된 것들입니다. 이미 이에 대한 영상을 만들기도 했죠.
00:39:36이미지와 비텍스트 문서(스캔한 PDF 등)를 LightRAG 지식 그래프 구조로
00:39:44가져올 수 있게 해주는 RAG-Anything 같은 도구들이 있습니다. 또한 지난 3월에 출시된
00:39:49Gemini Embedding 2 같은 신제품은 비디오 자체를 벡터 데이터베이스에
00:39:56직접 임베딩할 수 있게 해줍니다. 솔직히 말해서 이 분야는 그 방향으로 가고 있습니다.
00:40:01단순히 텍스트 문서만으로는 부족합니다. 인터넷, 특히 유튜브 같은 곳에
00:40:06얼마나 많은 정보와 지식이 비디오 형태로 갇혀 있습니까? 우리는 단순한 자막 스크립트
00:40:10그 이상의 것을 원합니다. 자막만으로는 충분하지 않죠. 그래서 이 멀티모달 문제는 실재하며,
00:40:16이것은 불과 몇 주 전에 나온 기술들입니다. 또한 레벨 7은 우리의
00:40:20아키텍처와 파이프라인에 주의를 기울여야 하는 단계입니다. RAG 시스템으로 들어오고 나가는
00:40:25데이터에 대해서 말이죠. 단순히 데이터를 집어넣는 것만으로는 부족합니다.
00:40:30이런 모든 연결을 갖추는 건 좋지만, 팀 환경에서 데이터가 어떻게 전달되나요?
00:40:35데이터가 거기서 어떻게 추출되나요? 특정 문서의 정보가 변경되었다면요?
00:40:40누군가 수정했다면 어떻게 업데이트되나요? 중복 데이터가 추가되면 어쩌죠?
00:40:46프로덕션 수준의 시스템이라면 이러한 질문들을 스스로에게 던지기 시작해야 합니다.
00:40:50n8n의 에이전틱 RAG 시스템을 예로 들어보면, 여기 표시된
00:40:54인프라의 대다수는 모두 데이터 수집과 동기화에 관한 것임을 알 수 있습니다.
00:41:01실제 RAG와 관련된 부분은 아주 작은 조각에 불과합니다. 왜냐하면
00:41:06데이터를 정제하고 분석할 수 있는 시스템이 필요하기 때문입니다. 방금 문서를 수집했는데
00:41:11이게 사실 버전 1의 버전 2라면, 다시 돌아가서 데이터를 정리할 수 있을까요?
00:41:17문서가 시스템에 직접 입력되는 대신, 구글 드라이브 같은 곳에
00:41:21데이터 수집 파이프라인을 구축하여 거기서 GraphRAG 시스템으로 수집되고
00:41:27기록되게 하는 방식입니다. 이런 것들이 실제 사용 시 RAG 시스템의 성패를 좌우합니다.
00:41:31에이전틱 RAG에 대해 이야기하자면, 여기 좀 흐릿하게 보이긴 합니다만
00:41:37AI 에이전트가 이 전체 프로그램을 실행한다고 가정해 봅시다. 팀을 위한
00:41:42어떤 챗봇을 설정했다고 할 때, 항상 이 데이터베이스를 조회해야 할까요? 아마 아닐 겁니다.
00:41:49팀이나 비즈니스 환경에서는 이런 데이터베이스에 있는 텍스트 정보뿐만 아니라,
00:41:54SQL로 쿼리하고 싶은 대량의 정보가 담긴 일반적인 PostgreSQL 같은
00:41:58또 다른 데이터베이스 세트도 가지고 있을 확률이 높기 때문입니다.
00:42:03그래서 에이전틱 RAG 시스템이라고 하면 이 모든 것을 갖춰야 합니다.
00:42:08여기에 표시된 GraphRAG 데이터베이스를 조회할지, 아니면
00:42:15Postgres에서 SQL 쿼리를 실행할지 지능적으로 결정할 수 있는 능력이 필요하죠.
00:42:20이런 것들은 꽤 복잡해질 수 있습니다. 모든 것은 사례에 따라 다르기 때문에
00:42:23모든 예외 케이스를 영상에 담기는 어렵습니다. 레벨 7의 핵심 포인트는
00:42:30들어보지도 못한 엄청난 RAG 시스템이 있다는 것이 아니라, 디테일에 악마가 있다는 것입니다.
00:42:34그것은 주로 데이터 수집 부분과 최신 상태 유지에 관한 것입니다. 또한
00:42:39실제로 이 시스템에 어떻게 접근하느냐의 문제도 있죠. 데모에서는 쉽습니다.
00:42:46그냥 LightRAG 화면으로 가서 질문을 던지면 되니까요. 하지만 팀 단위로
00:42:50모두가 서로 다른 각도에서 접근하는 상황이라면 시나리오가 달라집니다.
00:42:55웹 앱 상의 LightRAG에 모든 사람이 직접 업로드 권한을 갖는 걸 원치 않으실 테니까요.
00:43:01그건 그렇고, 멀티모달 기능을 수행할 수 있는 정교한 RAG 시스템을 구축하려는
00:43:07개인 개발자에게는 RAG-Anything과 LightRAG의 조합을 추천합니다.
00:43:14이에 대한 영상을 이미 올렸거나 위에 링크를 걸어두겠습니다. 몇 가지 이유로 이를 추천하는데,
00:43:19우선 오픈 소스이고 가볍기 때문입니다. 자신의 사용 사례에 실제로
00:43:26적합한지 확인하는 데 많은 비용이나 시간을 들일 필요가 없습니다.
00:43:31우리가 원하는 것은 빠져나올 방법도 없이 거액을 쏟아부은 시스템에 갇히지 않는 것입니다.
00:43:37그래서 저는 항상 Obsidian을 좋아하고 LightRAG나 RAG-Anything 같은 것을 추천합니다.
00:43:42한번 시도해 보고 본인에게 맞지 않거나 말이 안 된다고 느껴지면 그냥 두면 됩니다.
00:43:45몇 시간 낭비한 셈 치면 되니까요. 결코 저렴하지 않은
00:43:50마이크로소프트의 GraphRAG에 거금을 쓰는 것과는 다릅니다. 그렇다면 언제 본인이
00:43:56레벨 7에 있다고 알 수 있을까요? 이미지, 테이블, 비디오를 색인화해야 하고
00:44:02정보에 답하기 위해 어떤 경로를 택할지 지능적으로 결정하는 에이전트 시스템을 통합할 때입니다.
00:44:06레벨 7에서는 아마 이 모든 것을 통합하고 있을 겁니다. 어떤 영구적인 정보는
00:44:12Claude MD 파일로 가지고 있고, 어떤 정보는 검색이 용이하도록 코드베이스 내의 마크다운 파일로,
00:44:16어떤 부분은 Obsidian 보관소에 있을 수도 있습니다. 거기에 더해
00:44:20일부 문서들은 GraphRAG 데이터베이스에 들어있을 수도 있겠죠.
00:44:25그리고 최상단에 있는 AI 시스템이 질문을 보고 어떤 경로로 가서 답을 찾을지
00:44:33결정하게 됩니다. 그것이 제가 제안하는 성숙한 형태의 메모리 아키텍처입니다. 하지만 여기서 함정은 무엇일까요?
00:44:40솔직히 말해서, 함정은 굳이 필요하지 않은데도 억지로 이 단계의 정교함을
00:44:47추구하려는 것입니다. 사실 여러분 대부분은 Obsidian만으로 충분합니다.
00:44:52GraphRAG도 필요 없고 일반적인 RAG도 굳이 필요 없습니다. 레벨 7이 필요하다는 것이
00:44:57명확하지 않거나, 아직 Obsidian 방식을 시도해보지 않았다면 여기에 올 필요가 없습니다.
00:45:01시간 낭비일 가능성이 높습니다. 하지만 이 영상의 전체적인 목적은 제가 아는 한
00:45:07RAG와 메모리, 그리고 Claude Code가 가진 다양한 레벨의 문제들을 여러분께 노출해 드리는 것이었습니다.
00:45:12이 문제의 본질이 무엇인지, 어떤 긴장 상태와 트레이드오프가 있는지, 그리고
00:45:18여러분의 사례에서 어디쯤 머물러야 하는지에 대해서 말이죠. 가장 중요한 것은 실험입니다.
00:45:24시작하기 전에 정답을 다 알 필요는 없습니다. 그냥 시도해 보세요. 가능하다면 오름차순으로요.
00:45:28Claude 시스템 내의 마크다운 파일만으로 충분하고 잘 작동한다면 그것으로 좋습니다.
00:45:34그다음 Obsidian을 써보고, 그것도 부족하면 LightRAG를 써보는 식으로 하세요.
00:45:39오늘 이야기는 여기서 마치겠습니다. 특히 팀을 위해 RAG를 구축하거나
00:45:43고객에게 제공하는 것과 같은 프로덕션 측면에 대해 더 알고 싶으시다면,
00:45:47Chase AI Plus에 관련 모듈이 준비되어 있으니 확인해 보세요. 그 외에 궁금한 점은 댓글로 남겨주시고,
00:45:52꽤 긴 영상이었는데 시청해 주셔서 감사합니다. 다음에 또 뵙겠습니다.