RAGFlow를 도입할 가치가 있는지는 문서가 정말 '까다로운지'에 달려 있습니다. InfiniFlow가 GitHub에 오픈소스로 공개한 RAG 엔진으로, 깊은 문서 파싱이 강점입니다. 스캔 PDF, 표와 레이아웃이 있는 문서, 텍스트와 이미지가 섞인 자료도 먼저 구조화된 조각으로 쪼개 인덱싱하고 답변에 인용을 붙입니다. 지식 베이스가 소량의 깨끗한 일반 텍스트 웹페이지뿐이라면 그 파싱 능력은 쓰이지 않고, 들이는 노력의 의미는 훨씬 작아집니다.
공식 저장소 정보는 본문에 분명히 적습니다. 플랫폼은 GitHub, 조직명은 InfiniFlow, 프로젝트명은 RAGFlow, 라이선스는 Apache 2.0입니다. 시스템은 여러 컨테이너로 구성됩니다. RAGFlow 본체가 화면, API, 작업 실행을 맡고, Elasticsearch 또는 Infinity가 문서 엔진, MySQL이 메타데이터, Redis가 파싱 작업 대기열, 오브젝트 스토리지가 업로드 파일을 담당합니다. 모델은 직접 연결해야 합니다. 1.0 오픈소스 버전에서 파싱에 쓰이는 DeepDoc은 CPU 추론으로 동작하며 레이아웃 분석, OCR, 표 인식을 담당합니다.
배포 비용: 권장 구성에서 시작하세요
공식 권장 시작 구성은 CPU 4코어, 메모리 16GB, 디스크 50GB이며, Docker 24.0.0 이상, Docker Compose v2.26.1 이상입니다. 배포는 저장소를 복제한 뒤 docker 디렉터리로 들어가 Docker Compose로 미리 빌드된 이미지를 시작하는 방식입니다. Elasticsearch를 쓸 때는 호스트의 vm.max_map_count를 262144 이상으로 설정해야 합니다. 미리 빌드된 이미지는 현재 x86 버전만 제공되므로 ARM64 머신은 공식 안내를 확인하세요. 실제 비용은 문서량, 파싱 작업 수, 동시 실행 수에 따라 달라집니다. 스캔 문서를 대량으로 파싱할 때는 CPU가 병목이 되므로, 먼저 수십 건의 실제 문서로 전체 과정을 테스트한 뒤 운영 구성을 정하세요.
실제 함정은 네 가지입니다. 첫째, 파싱 품질은 문서 자체에 달려 있습니다. 흐릿한 스캔, 페이지를 넘나드는 표, 특이한 레이아웃의 자료는 먼저 표본 검사를 해야 하며, 파싱이 틀리면 나중에 청킹을 조정해도 구할 수 없습니다. 둘째, 모델은 직접 설정해야 합니다. 채팅 모델, 임베딩 모델, 재정렬 모델을 잘못 고르면 답변 품질과 비용이 함께 나빠지므로, 배포 전에 세 모델의 출처와 과금을 정하세요. 셋째, 다중 컨테이너 스택 운영은 지속적인 비용입니다. 업그레이드, 백업, 디스크 정리에 담당자가 필요하고, '한 번 설치하고 잊고 싶다'는 사람은 몇 달 뒤 아무도 관리하지 않는 오래된 버전을 마주하기 쉽습니다. 넷째, 답변에 인용이 붙었다고 인용이 반드시 맞는 것은 아닙니다. 계약이나 컴플라이언스 자료가 걸린 장면에서는 원문을 표본 확인하고, 권한 분리도 실제 조직 구조에 맞게 설정해야 합니다.
적합한 사람은 대량의 PDF, 스캔 문서, 표 문서를 보유하고, 추적 가능한 답변이 필요하며, Docker 스택을 직접 유지할 의향이 있는 팀이나 개인 개발자입니다. 적합하지 않은 사람은 문서가 적고 형식이 깔끔하며 빠른 Q&A 데모만 만들고 싶은 사람으로, 더 가벼운 방법이나 호스팅 서비스가 더 빠릅니다. 운영 시간이 없어 바로 쓸 수 있는 것을 원하는 사람도 마찬가지입니다. 파싱 능력이 아무리 강해도 운영 공백을 메울 수는 없습니다. 먼저 공식 클라우드 서비스로 파싱을 시험해 결과가 좋은 것을 확인한 뒤 직접 호스팅을 결정하세요.
