코딩알려주는누나의 영상 **「에이전틱 RAG vs 파인튜닝 vs LLM위키, 도대체 뭐가 다른가요?」**에서는 RAG, Agentic RAG, Fine-tuning, LLM Wiki를 실제 기업 적용 관점에서 비교합니다. ## 먼저 RAG는 무엇인가? RAG는 LLM이 모르는 사내 규정, 법률, 매뉴얼, 내부 문서 등을 **질문 시점에 찾아서 참고하도록 만드는 구조**입니다. 쉽게 말하면: **질문 → 관련 자료 검색 → 검색 결과를 LLM에 전달 → 답변 생성** 입니다. PDF 하나를 ChatGPT에 올려 질문하는 것도 넓은 의미에서는 비슷한 원리지만, 기업용 RAG는 검색 방식, 임베딩 모델, 청크 크기, 권한, 모델, 프롬프트 등을 직접 제어할 수 있다는 점이 다릅니다. ## 왜 기업은 직접 RAG를 구축할까? 영상에서는 대표적으로 다음 이유를 설명합니다. - 외부 LLM을 사용할 수 없는 보안 환경 - 사내 데이터가 외부로 나가면 안 되는 경우 - 검색 로직을 직접 제어해야 하는 경우 - 답변 근거를 투명하게 관리해야 하는 경우 - 로컬 LLM·SLM과 연결해야 하는 경우 즉, 기업용 RAG의 핵심은 단순히 “문서를 읽게 하는 것”이 아니라 **검색과 생성 과정을 통제할 수 있다는 것**입니다. ## RAG와 파인튜닝은 무엇이 다른가? 이 둘은 자주 혼동되지만 역할이 다릅니다. ### RAG 모델의 파라미터는 그대로 둡니다. 대신 질문할 때 참고 문서를 추가합니다. 즉: **모델은 그대로 + 컨텍스트 추가** 입니다. ### Fine-tuning 모델의 파라미터 자체를 업데이트합니다. 특정 도메인의 표현 방식, 말투, 패턴, 업무 스타일을 더 자연스럽게 학습시키는 데 적합합니다. 즉: **모델 자체를 바꿈** 입니다. ## 둘 중 하나만 쓰는 것이 아니다 기업에서는 실제로 RAG와 파인튜닝을 함께 사용하는 경우가 많습니다. 예를 들어: - Fine-tuning → 도메인 표현·응답 스타일·업무 패턴 학습 - RAG → 최신 문서·규정·내부 지식 제공 처럼 역할을 나눌 수 있습니다. 특히 로컬 SLM을 사용하는 환경에서는 모델 자체 성능을 보완하기 위해 파인튜닝을 하고, 최신 지식을 주기 위해 RAG를 추가하는 구조가 자연스럽습니다. ## 기업 RAG에서 기술보다 어려운 문제 영상에서 흥미로운 부분은 실제 기업 구축에서 **기술 문제보다 정책과 운영 문제가 더 어렵다**는 점입니다. 예를 들어 HR RAG를 만든다고 가정해 보겠습니다. 인턴 직원이 에이전트에게: > 부사장급 연봉이 얼마야? 라고 질문했을 때 권한 제어가 없다면 검색 시스템이 해당 문서를 찾아 답할 수 있습니다. 즉, RAG에서 중요한 것은 단순 검색 정확도가 아니라: - 누가 어떤 문서를 볼 수 있는가 - 어떤 질문은 거부해야 하는가 - 어떤 데이터는 검색 후보에서 제외해야 하는가 입니다. ## Agentic RAG란? 기존 RAG에서는 개발자가 검색 로직을 미리 정해 두는 경우가 많았습니다. 예를 들어: - 인사 질문 → HR DB - 기술 질문 → 기술 문서 - 법률 질문 → 법률 DB 처럼 규칙 기반 라우팅을 합니다. 하지만 데이터 소스가 많아지면 모든 경우를 사람이 미리 정의하기 어렵습니다. Agentic RAG는 이 판단을 LLM 에이전트에게 맡깁니다. **질문 → LLM이 어떤 데이터 소스를 찾을지 판단 → 검색 → 필요하면 추가 검색 → 답변** 즉, 검색 과정 자체에 **계획과 판단**이 들어갑니다. ## Agentic RAG의 장점 - 여러 데이터 소스 중 적절한 곳을 선택 - 복잡한 질문을 여러 검색 단계로 분해 - 첫 검색 결과가 부족하면 다시 검색 - 검색 결과에 따라 다음 행동 결정 - 규칙 기반 라우팅보다 유연함 기존 RAG가 하나의 정해진 파이프라인이라면 Agentic RAG는 **검색을 수행하는 에이전트**에 가깝습니다. ## 무조건 Agentic RAG로 바꿔야 할까? 영상에서는 반드시 그럴 필요는 없다고 설명합니다. LLM이 판단을 맡으면 개발은 편해질 수 있지만 새로운 문제가 생깁니다. - 잘못된 데이터 소스 선택 - 불필요한 검색 반복 - API 비용 증가 - 실행 시간 증가 - 결과 재현성 저하 - 디버깅 어려움 따라서 단순한 검색 문제라면 기존 RAG가 더 안정적일 수 있습니다. 반대로 데이터 소스가 많고 질문 유형이 복잡하다면 Agentic RAG의 효과가 커집니다. ## LLM Wiki는 어디에 위치할까? 영상에서는 LLM Wiki를 RAG와 비슷한 목적을 가진 다른 지식 관리 방식으로 설명합니다. LLM Wiki는 별도 Vector DB 없이 Markdown 문서와 링크 구조로 지식을 정리해 두고, Claude Code나 Codex 같은 에이전트가 필요할 때 파일을 직접 찾아 읽는 방식입니다. 즉: **Raw 자료 → AI가 Wiki 형태로 정리 → 필요할 때 파일 탐색 → 답변** 구조입니다. ## RAG와 LLM Wiki 차이 ### RAG - Vector DB나 검색 엔진 활용 - 대규모 문서 검색에 적합 - 의미 기반 검색 가능 - 기업 서비스에 적합 - 권한·검색 최적화 가능 ### LLM Wiki - Markdown 중심 - 구조가 단순함 - 사람이 직접 읽고 관리 가능 - 개인·소규모 지식베이스에 적합 - AI 코딩 에이전트와 연결하기 쉬움 즉, LLM Wiki는 RAG의 완전한 대체라기보다 **작은 규모에서 더 단순한 지식 관리 방식**으로 보는 것이 적절합니다. ## ChatGPT에 PDF를 올리는 것과 RAG 차이 영상에서는 같은 PDF를 일반 ChatGPT와 직접 만든 RAG 시스템에 넣어 비교합니다. 일반 ChatGPT는: - 검색 방식 - 컨텍스트 구성 - 프롬프트 - 모델 동작 을 서비스가 내부적으로 결정합니다. 반면 직접 구축한 RAG는: - Chunk Size - Embedding Model - Vector DB - Retrieval 방식 - 검색 개수 - System Prompt - LLM 모델 을 개발자가 직접 조절할 수 있습니다. 즉, **편의성은 ChatGPT가 높고 제어 가능성은 자체 RAG가 높습니다.** ## 기업 RAG에서 중요한 권한 설계 기업에서는 검색 정확도보다 더 중요한 문제가 있습니다. **검색 전에 권한을 적용하는 것**입니다. 사용자가 볼 수 없는 문서는 애초에 Retrieval 후보에 들어가지 않도록 해야 합니다. 이 구조가 없으면 AI가 민감한 정보를 읽은 뒤 나중에 답변에서 숨기는 방식이 되어 보안상 위험합니다. ## 실제 기업 도입에서 자주 생기는 문제 RAG 챗봇을 만들었다고 업무가 자동으로 줄어드는 것은 아닙니다. 영상에서는 HR 챗봇 사례처럼: 1. 직원이 AI에게 질문 2. AI 답변이 완벽하지 않음 3. 직원이 다시 HR 담당자에게 질문 4. HR 업무가 오히려 증가 하는 상황도 소개합니다. 즉, AI 시스템 성공 여부는 기술뿐 아니라: - 데이터 품질 - 정책 - 권한 - 업무 프로세스 - 사용자 신뢰 - 운영 조직 까지 함께 설계해야 합니다. ## 네 기술을 한 번에 정리하면 ### RAG **외부 지식을 검색해 LLM에 제공** ### Agentic RAG **LLM이 검색 과정과 데이터 소스 선택까지 판단** ### Fine-tuning **모델 자체의 파라미터를 학습** ### LLM Wiki **AI가 지식을 Markdown 구조로 미리 정리하고 직접 탐색** ## 어떤 상황에서 무엇을 쓰면 좋을까? ### 최신 사내 문서를 정확히 검색 → **RAG** ### 여러 데이터 소스와 복잡한 검색 흐름 → **Agentic RAG** ### 특정 말투·업무 패턴·도메인 스타일 학습 → **Fine-tuning** ### 개인·소규모 팀 지식관리 → **LLM Wiki** ### 보안이 중요한 사내 AI → **Local LLM + Fine-tuning + RAG** 처럼 조합할 수 있습니다. ## 핵심 정리 이번 영상의 가장 중요한 메시지는 **이 기술들이 서로 경쟁 관계가 아니라 서로 다른 문제를 해결한다는 것**입니다. 기업용 AI 시스템은 결국 다음과 같이 여러 층으로 구성될 가능성이 높습니다. **Fine-tuned LLM** + **RAG / Agentic RAG** + **권한 관리** + **업무 Agent** + **지식 관리 레이어** 따라서 중요한 것은 “무엇이 최신 기술인가?”가 아니라 **우리 조직의 어떤 문제를 해결하려는가**부터 정의하는 것입니다.