RAGFlow 완벽 가이드: 프로덕션급 RAG 애플리케이션 구축

깔끔한 PDF 두어 개로는 잘 작동하던 RAG 데모가, 실제 엔터프라이즈 문서에서는 아무 답도 못 하는 경험을 몇 번이나 하셨나요?

현장에서 벌어지는 일은 이렇습니다. 표는 납작해지고, 스캔된 페이지는 사라지며, 슬라이드 덱은 제목 계층을 잃고, 청킹 로직은 본문과 섹션 헤더를 갈라놓습니다. 프로덕션 RAG 시스템은 벡터 데이터베이스가 붙은 LLM과는 거리가 멉니다. 문서 파싱, 청킹 전략, 하이브리드 검색, 재순위화, 인용 추적, 에이전트 오케스트레이션 등 여러 구성 요소를 직접 설정해야 합니다.

RAGFlow는 이 모든 조각을 하나의 스택으로 합친 오픈 소스 플랫폼입니다. 심층 문서 파싱, 템플릿 기반 청킹, 하이브리드 검색, 에이전트 워크플로, MCP 통합을 단일 UI와 API 뒤에서 처리하므로, 지식 베이스에만 집중하시면 됩니다.

이 글에서는 RAGFlow의 내부 동작 방식, 아키텍처, LangChain 및 LlamaIndex와의 비교, 그리고 배포 방법까지 차근차근 살펴보겠습니다.

RAG 작동 방식이 궁금하시면 Retrieval Augmented Generation (RAG) with LangChain 과정을 수강해 보세요. 오후 한나절이면 기본을 탄탄히 잡을 수 있습니다.

RAGFlow란 무엇인가?

RAGFlow는 InfiniFlow가 개발해 2024년 4월 Apache 2.0 라이선스로 공개한 오픈 소스 RAG 엔진입니다.

검색 품질이 성패를 좌우하는 프로덕션 AI 애플리케이션을 위해 설계되었습니다. 프로젝트의 초점은 심층 문서 이해이며, 파싱과 청킹을 이후 모든 단계의 기반으로 여깁니다. PDF, 스프레드시트, 슬라이드 덱이 엉망이면 더 좋은 재순위화 모델이나 더 큰 LLM도 소용없습니다. 먼저 문서 품질을 다듬어야 합니다.

RAGFlow가 대부분의 RAG 도구와 다른 점은 풀스택이라는 것입니다. 문서 파싱, 템플릿 기반 청킹, 하이브리드 검색, 재순위화, 인용 추적, 에이전트 워크플로 빌더, MCP 지원까지 한 시스템에 들어 있습니다. 벡터 DB를 고르고, 파서를 설정하고, 재순위화를 덧붙이고, 그 위에 UI를 만드는 일을 직접 할 필요가 없습니다. 하나의 웹 인터페이스와 API 뒤에 모두 준비되어 있습니다.

즉, RAGFlow는 프레임워크라기보다 플랫폼에 가깝습니다.

RAGFlow의 동작 방식

RAGFlow는 표준 RAG 파이프라인을 따르지만, 각 단계가 직접 코드를 작성하는 대신 구성 가능한 컴포넌트로 제공됩니다.

문서를 업로드하는 순간부터 LLM이 응답을 보내기까지 다음과 같은 과정이 진행됩니다.

1. 문서 수집(Ingest): 파일을 업로드하거나 데이터 소스를 연결합니다. RAGFlow는 PDF, Word, Excel, PowerPoint, Markdown, HTML, 이미지, 스캔본을 지원합니다. v0.25부터는 Confluence, S3, Notion, Discord, Google Drive와의 동기화도 가능합니다.
2. 콘텐츠 파싱 및 구조화: DeepDoc 엔진이 OCR, 표 구조 인식, 레이아웃 인식으로 각 파일을 읽습니다. 결과물은 제목, 표, 도형, 읽기 순서 등의 메타데이터가 포함된 구조화된 콘텐츠입니다.
3. 임베딩 생성: 구성에서 선택한 임베딩 모델로 각 청크를 임베딩합니다. OpenAI, Cohere, Voyage, 로컬 모델 등 지원되는 모델을 사용할 수 있습니다.
4. 지식 색인화: 청크와 벡터가 문서 엔진에 저장됩니다. 기본은 Elasticsearch이며, 하이브리드 검색에 특화된 InfiniFlow의 데이터베이스 Infinity로 전환할 수 있습니다.
5. 관련 컨텍스트 검색: 쿼리가 들어오면, RAGFlow는 벡터 검색, BM25 키워드 검색, 재순위화를 함께 수행합니다. 원문에 대한 인용과 함께 상위 청크를 반환합니다.
6. LLM으로 응답 생성: 검색된 청크를 프롬프트에 넣고 LLM이 답변을 작성합니다. RAGFlow는 인용을 첨부해 사용자가 모든 주장 근거를 원문 구절로 추적할 수 있게 합니다.

순서는 새로울 것 없습니다. 중요한 점은 각 단계가 플랫폼의 구성 가능한 부품이며, 매 단계의 출력물을 확인할 수 있다는 것입니다.

RAGFlow 아키텍처

RAGFlow의 아키텍처는 네 개의 계층으로 이루어져 있으며, 각 계층은 RAG 파이프라인의 특정 문제를 해결합니다. 아래는 간단한 시각적 개요입니다.

RAGFlow 아키텍처 시각화

이제 각 계층을 차례로 살펴보겠습니다.

문서 수집

시작 지점입니다. RAGFlow는 PDF, Word/Excel/PowerPoint 등 Office 문서, Markdown 파일, 웹 페이지를 받습니다. OCR이 내장되어 있어 스캔 문서와 이미지도 처리됩니다.

UI로 직접 업로드하거나, 클라우드 소스를 연결하거나, API로 푸시할 수 있습니다. 수집 계층은 다음 단계로 넘기기 전에 모든 문서를 공통 포맷으로 정규화합니다.

지식 처리

이 단계에서 DeepDoc이 사용됩니다.

파싱은 원시 파일을 제목, 문단, 표, 도형이 갖춰진 구조화 콘텐츠로 바꿉니다. 청킹은 선택한 템플릿(General, Paper, Book, Q&A, Manual, Table, Naive)에 따라 검색 단위로 분할합니다. 메타데이터 추출은 페이지 번호, 섹션 제목, 페이지 내 위치 등 각 청크에 컨텍스트를 붙입니다.

이 계층을 거친 청크는 구조를 유지합니다. 표는 표로 남고, 제목은 해당 섹션과 함께하며, 도형 캡션은 도형과 함께 유지됩니다. 전통적인 RAG 청킹처럼 무작위로 느껴지지 않습니다.

검색 엔진

검색 엔진은 구성한 문서 엔진에 따라 Elasticsearch 또는 Infinity 위에서 동작합니다.

세 가지 검색을 병렬로 실행합니다.

• 벡터 검색으로 의미적 유사성 탐지
• BM25 키워드 검색으로 정확한 용어 일치
• 재순위화로 병합 결과를 다시 정렬해 가장 관련 높은 청크를 상단에 노출

이 계층은 LLM 프롬프트에 넣을 소수의 고품질 청크를 제공합니다.

LLM 계층

LLM 계층은 검색된 청크를 연결된 모델(OpenAI, DeepSeek, Gemini, Claude, 로컬 Ollama 모델 등 RAGFlow가 지원하는 어떤 모델이든)로 보냅니다.

응답은 인용과 함께 돌아옵니다. 답변의 모든 주장은 특정 청크를 가리키고, 각 청크는 원문 문서의 특정 위치를 가리킵니다. RAGFlow는 이것을 근거 기반 답변(grounded answers)이라 부르며, 사용자는 인용을 클릭해 정확한 출처 구절을 확인할 수 있어 환각을 잡아내기 쉽습니다.

이 네 계층은 파이프라인처럼 작동합니다. 수집이 지식 처리로, 지식 처리가 검색 엔진으로, 검색 엔진이 LLM 계층으로 데이터를 넘깁니다.

RAGFlow의 핵심 기능

현실 세계의 복잡한 문서로 RAG 시스템을 구축할 때 특히 중요한 기능들입니다.

고급 문서 파싱

RAGFlow의 파서는 DeepDoc이라 하며, 플랫폼이 존재하는 이유이기도 합니다.

DeepDoc은 각 문서에 대해 세 가지 비전 모델을 사용합니다. 텍스트 추출을 위한 OCR, 표 구조 인식을 위한 TSR, 문서 레이아웃 인식을 위한 DLR입니다. 즉, PDF를 문자 흐름으로 보지 않고 사람처럼 읽습니다. 표의 위치, 컬럼 분할, 제목 텍스트와 각주 텍스트를 구분해 파악합니다.

이 구조는 청크에도 반영됩니다. 표는 헤더와 함께 유지되고, 다단 레이아웃은 올바른 순서로 읽히며, 도형은 캡션을 유지합니다.

이 작업을 수작업으로 해 보셨다면, 다양한 문서 유형을 규모 있게 잘 처리하는 일이 얼마나 어려운지 아실 겁니다.

하이브리드 검색

시맨틱 검색만으로는 정확한 단어가 중요한 쿼리를 놓치기 쉽습니다. 키워드 검색만으로는 표현이 달라도 의미가 같은 쿼리를 놓칩니다.

RAGFlow는 둘을 동시에 수행합니다.

• 벡터 검색은 의미적 일치를 잡아냅니다 - "revenue"로 "sales", "income"을 찾습니다.
• 키워드 검색은 정확 일치를 잡아냅니다 - 임베딩 모델이 이해하지 못하더라도 제품 코드나 법률 용어를 찾습니다.
• 재순위화는 결합된 결과를 전용 모델로 다시 정렬해 상위 청크가 실제로 가장 관련 높은 결과가 되도록 합니다.

워크플로 빌더

워크플로 빌더는 코드를 작성하는 대신 파이프라인을 구성하는 시각적 캔버스입니다.

검색, 재순위화, LLM, 코드 실행, HTTP 호출, 반복, 분기 등을 캔버스에 끌어다 놓고 플로우로 연결합니다. Retrieve - Rerank - Answer, Deep Research, Data Analytics 같은 일반 패턴 템플릿도 제공합니다.

비엔지니어 중심 팀이라면, 이 방식으로 일주일 만에 작동하는 프로토타입을 만들 수 있습니다.

에이전트 지원

v0.20부터 RAGFlow는 일반 워크플로와 동일한 캔버스에서 완전한 에이전트 워크플로를 지원합니다.

에이전트 컴포넌트는 계획 수립, 반성, 도구 호출, 하위 에이전트 위임을 수행합니다. 프롬프트와 도구 목록을 구성하면, 에이전트가 런타임에 어떤 도구를 어떤 순서로 호출할지 결정합니다. 도구는 내장 컴포넌트, 연결한 MCP 서버, 다른 에이전트가 될 수 있습니다.

핵심 가치는 검색된 지식 위에서의 추론입니다. 

예를 들어, 지원 에이전트는 지식 베이스에서 검색하고, 외부 API로 티켓 상태를 확인한 뒤, 에스컬레이션 여부를 결정할 수 있습니다. 이 모든 과정을 하나의 플로우에서, 문서 기반 부분에는 인용을 붙인 채 수행합니다.

문서 파싱과 지식 추출

검색 품질은 파싱 품질에서 시작합니다. 이 부분이 잘못되면, 재순위화나 더 큰 LLM도 도와주지 못합니다.

대부분의 RAG 실패는 문서 단계에서 발생합니다. 표로 가득한 PDF가 콤마 구분값으로 추출되거나, 슬라이드 덱이 시각적 계층을 잃어버립니다. 이런 청크가 벡터 DB에 도달하면 더는 가치가 없습니다.

RAGFlow는 파싱을 일급 문제로 다룹니다.

표

표는 문서 파싱에서 가장 어렵습니다. 일반 PDF 파서는 표를 행 단위로 읽어 헤더 없는 숫자 흐름으로 바꿉니다. 구조를 잃는 것이죠.

DeepDoc은 청킹 전에 TSR(표 구조 인식)을 수행합니다. 표 경계, 헤더 행, 컬럼, 셀 관계를 식별합니다. 청커가 문서를 분할할 때 표는 헤더와 함께 온전히 유지되고, 각 행은 자체 컨텍스트를 지닙니다.

이미지와 스캔

DeepDoc은 스캔 페이지에서 OCR로 텍스트를 추출하며, v0.19부터는 비전-언어 모델을 사용해 PDF와 DOCX 내부 이미지를 해석할 수 있습니다.

즉, 다이어그램, 차트, 영수증 사진도 검색 가능한 콘텐츠가 됩니다.

다단 레이아웃

학술 논문과 재무 보고서는 다단 레이아웃을 사용합니다. 단순 파서는 왼쪽에서 오른쪽으로 줄 단위로 읽어 컬럼을 섞어 의미 없는 내용을 만들곤 합니다.

DeepDoc은 먼저 DLR(문서 레이아웃 인식)로 읽기 순서를 파악합니다. 1열이 2열보다 먼저 오고, 헤더가 두 열을 가로지른다는 것을 압니다.

메타데이터

모든 청크에는 페이지 번호, 섹션 제목, 페이지 내 위치, 출처 파일 등의 메타데이터가 포함됩니다.

이 덕분에 인용이 가능합니다. LLM이 구절을 인용하면, RAGFlow는 원문 문서의 정확한 페이지와 위치를 가리킬 수 있습니다. 또한 청크 단위 필터링이 가능해져 특정 섹션이나 특정 문서 내부만 검색할 수 있습니다.

청크 품질

마지막은 청킹 자체입니다. RAGFlow는 템플릿 기반 청킹을 사용합니다. 즉, 문서 유형에 맞는 템플릿(General, Paper, Book, Q&A, Manual, Table, Naive)을 고릅니다.

각 템플릿은 분할 위치에 대한 규칙이 다릅니다. Paper 템플릿은 초록, 방법, 결과를 별도 단위로 유지합니다. Q&A 템플릿은 질문과 답변을 함께 유지합니다. Manual 템플릿은 제목과 절차를 존중합니다. 요지는 이렇습니다.

결과적으로 청크 자체가 온전히 의미를 갖습니다. LLM의 컨텍스트 윈도우에 들어갔을 때, 질문에 답할 만한 충분한 의미를 지닙니다.

RAGFlow의 검색

문서가 파싱되고 청킹되면, 검색 단계가 LLM이 올바른 컨텍스트를 보느냐를 결정합니다. RAGFlow의 검색 엔진은 세 부분이 함께 동작합니다.

벡터 검색

벡터 검색은 의미적 유사성을 잡습니다. 동일한 모델로 쿼리와 각 청크를 임베딩하고, 쿼리 벡터와 가장 가까운 청크를 반환합니다.

이를 통해 "revenue growth"로 검색해도 "sales increase"를 포함한 청크를 찾을 수 있습니다. RAGFlow는 OpenAI, Cohere, Voyage, BGE, 로컬 모델 등 임베딩 모델을 선택할 수 있고, 시스템 전체를 재구축하지 않고도 나중에 교체할 수 있습니다.

하이브리드 검색

벡터 검색은 정확 용어에 약할 수 있습니다. 제품 코드나 법적 참조처럼 의미적 신호는 약하지만 정확 문자열 일치가 매우 중요한 항목이 있습니다.

RAGFlow는 벡터 검색과 함께 BM25 키워드 검색을 수행하고 결과를 결합합니다. 하나의 쿼리에서 임베딩의 의미적 재현율과 키워드 매칭의 정밀도를 동시에 얻습니다.

재순위화

첫 검색 라운드는 보통 상위 30~50개 청크의 후보 집합을 줍니다. LLM 컨텍스트 윈도우엔 너무 많고, 상단 결과가 종종 시끄럽습니다.

재순위화는 쿼리와 각 청크를 함께 읽는 전용 모델로 이 후보를 다시 정렬합니다. 재순위화 모델은 쿼리와 "유사"한 것이 아니라 "관련"된 것을 압니다. 재순위화 후 상위 5~10개 청크만 프롬프트에 들어갑니다.

컨텍스트 선택

마지막 단계는 LLM 컨텍스트에 무엇을 넣을지 결정하는 것입니다. RAGFlow는 청크 개수, 유사도 임계값, 최소 재순위화 점수를 설정할 수 있습니다.

또한 RAPTOR(멀티홉 질문을 위한 계층적 요약)이나 롱 컨텍스트 RAG(문서 수준 자동 목차 생성으로 LLM에 원문 지도를 제공) 같은 고급 옵션도 사용할 수 있습니다. 평면 청크 검색만으로 부족한 경우를 위한 옵션입니다.

검색 엔진의 목적은 LLM에 꼭 필요한 컨텍스트만 정확히 전달하는 것입니다.

RAGFlow vs 전통적 RAG 파이프라인

전통적인 RAG 파이프라인은 독립 도구들을 조합해 만듭니다. 파서(Unstructured, LlamaParse, PyMuPDF), 청커(LangChain 텍스트 스플리터, 커스텀 코드), 임베딩 모델, 벡터 DB(Pinecone, Weaviate, Chroma, Qdrant), 재순위화(Cohere, BGE), LLM 클라이언트, UI를 고르고, 이 모두를 엮는 코드를 작성합니다.

이 방식은 통제가 최상이지만, 엔지니어링 노력이 많이 듭니다.

모든 통합 지점이 계획·작성·테스트·유지해야 하는 코드입니다. 인용 추적을 추가하고 싶다면 직접 만들어야 합니다. 어떤 컴포넌트의 API가 바뀌면 파이프라인을 고쳐야 합니다.

RAGFlow는 반대 접근을 취합니다.

파싱, 청킹, 검색, 재순위화, 인용, 워크플로 오케스트레이션, 웹 UI가 기본 포함된 통합 플랫폼입니다. 코딩 대신 웹 인터페이스로 구성하며, 부품들은 이미 연결되어 있습니다.

대신 유연성을 일부 포기합니다. 새로운 청킹 알고리즘이나 연구용 재순위화를 바꾸고 싶다면, 파이썬을 쓰기보다 RAGFlow의 플러그인 모델 범위 안에서 작업해야 합니다. 대부분의 프로덕션 용도에는 충분하지만, 실험적 용도에는 다소 제약적으로 느껴질 수 있습니다.

차이는 다음과 같이 요약됩니다.

어느 쪽이 항상 더 낫다고 할 수는 없습니다. 전체 제어가 필요하고 엔지니어링 시간이 있다면 전통 파이프라인이 맞습니다. 지식 베이스에 집중하고 싶다면 RAGFlow가 더 빠릅니다.

RAGFlow vs LangChain 및 LlamaIndex

RAGFlow를 고려하고 계시다면 LangChain과 LlamaIndex도 들어보셨을 겁니다. 어떻게 다른지 살펴보겠습니다.

LangChain

LangChain은 LLM 앱을 위한 애플리케이션 프레임워크입니다. 주요 역할은 오케스트레이션으로, 프롬프트, 도구, 메모리, 모델을 체이닝해 워크플로를 구성합니다. LangChain은 문서를 어떻게 파싱하거나 검색을 어떻게 구성하는지에는 큰 관심이 없습니다. 검색 이후에 무슨 일이 벌어지는지에 집중합니다.

툴 호출, 다단계 추론, 분기 로직, 휴먼 인 더 루프 등 에이전트 중심 프로젝트라면 LangChain(및 그 상태 머신 계층인 LangGraph)이 많은 팀의 선택입니다.

LlamaIndex

LlamaIndex는 LLM을 위한 데이터 프레임워크입니다. 데이터 수집, 데이터에 대한 인덱스 구축, 그리고 효율적 쿼리에 초점을 둡니다. 160개 이상의 데이터 커넥터, 여러 인덱스 유형(벡터, 키워드, 트리, 지식 그래프), 합리적인 청킹/검색 기본값을 제공합니다.

문서가 많고, 깊은 검색 요구가 있으며, 다양한 소스 시스템을 다뤄야 하는 검색 중심 프로젝트라면 LlamaIndex가 코드 우선 선택지로 가장 강력합니다.

RAGFlow

RAGFlow는 통합형 RAG 플랫폼입니다. 파이썬에 임포트해 쓰는 라이브러리가 아니라, 배포하는 시스템입니다. 파싱, 청킹, 검색, 재순위화, 인용, 워크플로, 에이전트, 웹 UI가 함께 제공됩니다.

복잡한 문서 위에서 파이프라인 코드를 처음부터 쓰지 않고 프로덕션 RAG 시스템을 가동하는 것이 우선이라면, RAGFlow가 가장 빠릅니다.

세 도구는 함께 쓰이기도 합니다. 흔한 패턴은 수집에 LlamaIndex, 에이전트 오케스트레이션에 LangChain 또는 LangGraph, 수제 코드 대신 완전한 자체 호스팅 스택이 필요할 때 RAGFlow를 사용하는 것입니다.

다음은 요약입니다:

RAGFlow로 RAG 애플리케이션 구축

RAGFlow가 구동되면, RAG 애플리케이션 구축은 다섯 단계를 따릅니다. 파이프라인 코드를 작성하지 않고 UI나 API로 각 단계를 구성합니다.

문서 수집

먼저 문서를 업로드합니다. 웹 UI에서 파일을 추가하거나, Google Drive, S3, Notion, Confluence, Discord 같은 데이터 소스를 연결하거나, API로 파일을 추가할 수 있습니다.

문서 수집 예시

RAGFlow는 대부분의 일반 포맷을 지원하므로, 사전 변환이 필요 없습니다.

지식 베이스 구성

RAGFlow의 지식 베이스는 문서, 청크, 설정을 담는 컨테이너입니다. 문서 유형에 맞는 청크 템플릿(혼합 콘텐츠는 General, 연구는 Paper, 기술 문서는 Manual, 지원 티켓은 Q&A 등)을 고르고, 임베딩 모델과 파서를 선택합니다.

지식 베이스 구성

이 단계의 선택은 중요합니다. 좋은 템플릿 선택만으로도 이후의 많은 골칫거리를 줄일 수 있습니다.

검색 전략 선택

검색 방식을 결정합니다. 반환할 상위 청크 개수, 유사도 임계값, 하이브리드/벡터 검색 여부를 설정합니다. 재순위화를 켜고 모델을 선택할 수도 있습니다.

고급 사용 사례를 위해, RAGFlow는 계층적 요약을 위한 RAPTOR와 엔터티 기반 검색을 위한 지식 그래프를 지원합니다. 지식 베이스 설정에서 켤 수 있습니다.

LLM 연결

RAGFlow에는 LLM이 포함되어 있지 않습니다. OpenAI, DeepSeek, Gemini, Claude, Ollama를 통한 로컬 모델 등 지원되는 모델을 직접 연결합니다.

모델 옵션

설정에서 API 키를 추가하고, 모델을 선택하고, 시스템 프롬프트를 지정합니다. 

응답 테스트

마지막 단계는 테스트입니다. RAGFlow에는 지식 베이스를 질의하고 인용이 첨부된 답변을 확인할 수 있는 채팅 인터페이스가 있습니다.

인용을 클릭하면, 원문 문서에서 해당 청크의 위치가 하이라이트된 화면으로 이동합니다.

대부분의 팀은 유용한 답을 얻기 전까지 이 과정을 몇 차례 반복합니다. 어떤 RAG 시스템이든 정상적인 절차이지만, RAGFlow에서는 파이썬 코드를 다시 쓰는 대신 UI에서 설정만 바꾸면 됩니다.

채팅 구성 예시

프로덕션 환경의 RAGFlow

RAGFlow는 주로 문서 품질과 인용 추적이 특히 중요한 특정 사용 사례에서 프로덕션에 도입됩니다.

엔터프라이즈 지식 베이스

대기업은 공유 드라이브, Confluence, SharePoint, 이메일 첨부의 PDF 등 수천 건의 문서를 보유합니다. 직원들은 원하는 정보를 찾기 어렵고, RAG 없이 LLM에 묻기만 하면 환각이 늘어납니다.

RAGFlow는 이런 환경에 잘 맞습니다.

오래된 PDF, 스캔된 정책 문서, 피벗 테이블이 있는 엑셀, 예전 파워포인트 덱까지 모두 파싱됩니다. 인용 기능 덕분에 법무/컴플라이언스 팀은 답변을 신뢰할 수 있고, 웹 UI 덕분에 비엔지니어도 지식 베이스를 관리할 수 있습니다.

고객 지원 도우미

지원 팀은 수년 치 티켓, FAQ, 제품 매뉴얼, 내부 런북을 갖고 있습니다. 지원 도우미는 이 모든 자료를 검색해 올바른 구절을 찾고, 에스컬레이션 시점을 알아야 합니다.

RAGFlow의 Q&A 청크 템플릿은 바로 이를 위해 만들어졌습니다. 티켓 히스토리를 넣으면 질문-답변 쌍을 검색 단위로 다룹니다. 여기에 에이전트 레이어를 얹고 주문 조회 API를 연결하면, 일상적인 문의는 처리하고 어려운 건 충분한 컨텍스트와 함께 전달하는 도우미가 됩니다.

내부 문서 검색

엔지니어링 팀은 런북, 아키텍처 문서, 사고 포스트모템, API 레퍼런스가 Notion, Confluence, GitHub 곳곳에 흩어져 있습니다. Grep은 키워드에는 유용하지만, "이 알림이 마지막으로 떴을 때 어떻게 처리했나?"에는 도움이 되지 않습니다.

RAGFlow는 전체 코퍼스에 대한 시맨틱 검색과 출처 인용을 제공합니다. 엔지니어는 한 번에 구절과 원문 링크를 받을 수 있습니다.

리서치 도우미

리서치 팀은 논문, 특허, 리포트, 내부 실험을 다룹니다. RAGFlow의 Deep Research 템플릿은 이를 위해 설계되었으며, 에이전트가 질문을 분해하고, 답의 구성요소를 검색해, 이를 종합하는 다중 턴 검색과 사고의 사슬 추론을 포함합니다.

금융, 법률, 제약 리서치에서는 모든 주장을 출처로 추적할 수 있는 능력이 도우미를 실사용 가능하게 만드는 핵심입니다.

공통점은 문서가 가장 어려운 요소라는 것입니다. 원자료가 깔끔하고 단순하면 대부분의 RAG 도구가 잘 작동합니다. 복잡하고 구조화되어 있다면, RAGFlow의 파싱 계층이 파이프라인을 처음부터 작성하는 것보다 더 멀리 데려다줄 가능성이 큽니다.

RAGFlow 배포

RAGFlow는 세 가지 배포 경로를 제공합니다. 각각을 살펴보겠습니다.

Docker 배포

Docker Compose가 기본 경로입니다. 레포를 클론하고, docker 폴더로 이동해 docker compose up -d를 실행합니다. 그러면 RAGFlow 서버와 함께 Elasticsearch, MinIO, MySQL, Redis가 시작됩니다.

최소 사양은 CPU 4코어, RAM 16GB, 디스크 50GB입니다. 실제로는 큰 문서 컬렉션을 운영한다면 RAM을 더 늘려야 합니다. Elasticsearch와 Infinity는 메모리를 많이 필요로 합니다.

Docker 이미지는 x86을 대상으로 합니다. Apple Silicon 등 ARM64 머신이라면 변환 계층으로 실행은 가능하지만, 성능 향상을 위해 RAGFlow 문서의 ARM64 가이드를 따라 직접 이미지를 빌드하는 것이 좋습니다.

로컬 개발

RAGFlow 소스 코드를 수정하려면 백엔드와 프론트엔드를 소스에서 실행할 수 있습니다. Python 의존성은 uv를 사용하고, docker compose -f docker/docker-compose-base.yml up -d로 MinIO, Elasticsearch, MySQL, Redis 같은 보조 서비스를 띄운 뒤, 셸 스크립트로 백엔드를, npm run dev로 프론트엔드를 시작합니다.

이 경로는 프로젝트에 기여하거나 디버깅할 때만 권장됩니다. 대부분의 사용자에게는 Docker Compose가 더 빠릅니다.

클라우드 배포

InfiniFlow는 cloud.ragflow.io에서 호스팅 버전을 운영합니다. 월 5개 앱과 500 크레딧의 무료 플랜이 있으며, 유료 플랜은 $29, $129, 엔터프라이즈 요금제가 있습니다.

클라우드 버전은 프로토타입과 소규모 팀에 적합합니다. 민감한 데이터를 다루는 본격적인 프로덕션 용도라면, 대부분 자체 인프라에 셀프 호스팅합니다. 소규모는 단일 VM, 대규모는 Helm 차트를 사용한 Kubernetes 배포가 일반적입니다.

스케일링 고려사항

RAGFlow 기본 배포는 모든 구성요소를 한 머신에서 실행합니다. 어느 정도까지는 괜찮지만, 문서 수, 쿼리 부하, 팀 규모 중 하나에서 한계에 도달합니다.

독립적으로 스케일할 수 있는 구성 요소는 문서 엔진(Elasticsearch 또는 Infinity), 객체 저장소(MinIO), RAGFlow 앱 자체입니다. 대규모 배포에서는 이 서비스들을 분리 배치하고, 관리형 Elasticsearch나 S3 호환 객체 저장소를 사용하며, 로드 밸런서 뒤에서 여러 RAGFlow 앱 인스턴스를 실행합니다.

DeepDoc의 GPU 가속도 고려할 만합니다. 기본적으로 파싱은 CPU 집약적이지만, 설정에서 GPU 모드를 켜면 대규모 문서 수집 작업에서 큰 차이를 보입니다.

나머지는 표준 인프라 작업이며, RAGFlow가 이를 방해하지 않습니다.

RAGFlow의 장점과 한계

모든 도구에는 트레이드오프가 있으며, RAGFlow도 예외가 아닙니다. 사용 전 알아야 할 점입니다.

장점

• 통합 플랫폼: 파서, 벡터 DB, 재순위화, 청커, UI 프레임워크를 고르고 코드를 작성할 필요가 없습니다. RAGFlow에 모두 포함됩니다.
• 가장 강한 것은 문서 처리: DeepDoc은 PDF, 스캔본, 표, 복잡한 레이아웃을 대부분의 대안보다 잘 처리합니다. 문서가 복잡하다면 이 점만으로도 선택할 이유가 됩니다.
• 처음부터 프로덕션 지향: 근거 인용, 청크 시각화, 에이전트 워크플로, MCP 지원, 관리용 UI가 기본 탑재되어 있습니다. 
• Apache 2.0 오픈 소스: 셀프 호스팅하고, 코드를 수정하며, 자체 인프라에서 운영할 수 있습니다. GitHub 레포는 별 8만+와 활발한 개발이 이어지고 있어 프로젝트의 지속성이 높습니다.

한계

• 배포가 처음 생각만큼 간단하진 않음: Docker Compose가 도움은 되지만, 앱과 함께 Elasticsearch 또는 Infinity, MinIO, MySQL, Redis를 운영해야 합니다. 언젠가 무언가가 깨질 수 있고, 이를 해결할 만큼의 Docker 지식이 필요합니다.
• 인프라 요구사항: 공식 최소는 RAM 16GB, CPU 4코어지만 이는 소규모 작업 기준입니다. 실제 배포는 32GB 이상이 필요할 때가 많습니다(특히 Infinity 사용이나 대량 수집 시). 월 $5 VPS로는 어렵습니다.
• 학습 곡선: 워크플로 빌더는 강력하지만 컴포넌트가 많습니다. 올바른 청크 템플릿과 검색 설정을 찾는 데 시간이 걸립니다. 생산성을 내기까지 며칠은 투자해야 합니다.

RAGFlow가 사용 사례에 맞다면, 어느 것도 치명적 한계는 아닙니다. 라이브러리가 아닌 플랫폼을 사용하는 데 드는 비용이라 생각하세요.

누가 RAGFlow를 써야 할까?

RAGFlow가 모든 프로젝트에 이상적인 것은 아닙니다. 적합한 사용자와 가벼운 대안이 더 나은 경우를 정리합니다.

가장 적합

프로덕션 RAG 시스템을 구축하는 AI 엔지니어. 목표가 동작하는 RAG 앱을 만드는 것이지 또 다른 청킹 라이브러리를 쓰는 게 아니라면, RAGFlow는 배관 작업 대부분을 덜어줍니다.

엔터프라이즈 AI 팀. 법무, 컴플라이언스, 재무, 지원 팀은 인용과 추적 가능성이 필요합니다. 비엔지니어도 사용할 수 있는 UI 역시 장점입니다. 

복잡한 문서를 다루는 개발자. 표가 많은 PDF, 스캔본, 다단 레이아웃, 혼합 포맷에서 DeepDoc의 강점이 두드러집니다. 원자료가 깔끔한 텍스트가 아니라면, RAGFlow의 파싱 품질을 따라가기 어렵습니다.

대규모 문서 컬렉션을 가진 조직. 수천 건을 넘기면, 대규모 수집·인덱싱·검색이 가능한 시스템이 필요합니다. 이 경우 RAGFlow가 적합합니다.

덜 적합

단순 챗봇 프로토타입. Markdown 파일 몇 개에 대한 질문에 답하면 된다면, RAGFlow는 과합니다. LlamaIndex 스크립트나 간단한 LangChain 파이프라인이 더 빠릅니다.

매우 작은 프로젝트. 개인용 PDF 몇 개에 대한 Q&A라면 인프라 비용이 과합니다. 실제 프로젝트보다 Docker 명령어에 시간을 더 쓸 수 있습니다.

완전 무설정을 원하는 팀. 5분 만에 가입하고 가동하고 싶다면, 호스팅 서비스나 경량 라이브러리가 더 맞습니다. RAGFlow 클라우드가 있지만(가치의 대부분이 있는) 셀프 호스팅 경로는 어느 정도의 셋업이 필요합니다.

간단한 판단 기준은 이렇습니다. 복잡한 문서에서의 검색 품질이 프로젝트의 어려운 부분이라면, RAGFlow는 셋업 비용만큼의 가치가 있습니다. 그렇지 않다면 더 가벼운 도구를 쓰세요.

마무리

RAGFlow는 현실 세계 문서로 프로덕션 RAG 애플리케이션을 구축하는 풀스택 플랫폼입니다.

가장 큰 강점은 문서 처리, 검색, 재순위화, 생성이 별도 도구 결합이 아니라 하나의 워크플로 안에 있다는 점입니다. 단일 UI와 API 뒤에서 DeepDoc 파싱, 하이브리드 검색, 근거 인용, 에이전트 워크플로를 사용할 수 있습니다.

문서가 복잡하고 검색 품질이 중요하다면, RAGFlow는 셋업 비용을 치를 가치가 있습니다.

무료 클라우드 플랜이나 로컬 Docker 배포로 시작해, 가장 까다로운 문서 몇 개를 업로드하고, 답변이 어떻게 돌아오는지 확인해 보세요. 적합성 판단을 가장 빠르게 할 수 있는 방법입니다.

RAG 아키텍처는 설계상 단순하지만, 복잡한 사용 사례에도 충분히 통합니다. 조밀 검색, 재순위화, 다단계 추론을 다룬 Advanced RAG Techniques 블로그 글도 읽어보세요.