AnythingLLM은 로컬 우선(local-first)으로 운영 가능한 RAG(검색증강생성) 및 AI 에이전트 플랫폼입니다. 문서를 업로드하면 벡터화하여 워크스페이스 단위로 저장하고, 원하는 LLM 공급자와 벡터DB를 골라 연결한 뒤 채팅형 UI로 질의응답과 에이전트 작업(도구 사용, MCP 연동 등)을 수행할 수 있습니다. Docker, Kubernetes/Helm, AWS/GCP/DigitalOcean, HuggingFace Spaces, OpenShift 등 다양한 배포 방식을 공식 지원하는 자체 호스팅형 제품입니다.
레포는 frontend(React/Vite), server(Node/Express, Prisma ORM), collector(Node 문서 처리 서비스) 세 개의 서비스로 구성됩니다. collector는 PDF, DOCX, XLSX, EPUB, 오디오(Whisper/ffmpeg 변환), 이미지(OCR/Tesseract+Sharp), 웹링크, YouTube 자막, Confluence/GitHub/GitLab/Gitea 저장소, Obsidian Vault, PaperlessNgx 등 매우 다양한 소스를 텍스트로 추출·청크화하는 전용 엔드포인트 집합(/ext/*)을 express로 노출하며, verifyPayloadIntegrity·setDataSigner 같은 미들웨어로 페이로드 위변조를 검증합니다. 추출된 텍스트는 server로 전달되어 임베딩 생성 후 선택한 벡터DB(LanceDB 등)에 저장되고, 채팅 시 워크스페이스 컨텍스트+LLM 호출로 응답을 생성합니다. 배포는 docker-compose 또는 각 클라우드용 Dockerfile/Helm 차트/CloudFormation/Terraform으로 처리되며, entrypoint 스크립트가 초기 설정과 헬스체크를 담당합니다. 개발 시엔 collector/server/frontend를 yarn dev 스크립트로 각각 띄우는 3-프로세스 구조이며, devcontainer 설정으로 GitHub Codespaces 개발도 지원합니다.
- STEP 01
레포를 클론하고 docker-compose 또는 yarn setup으로 collector/server/frontend 세 서비스를 각각 설치·실행하면, 처음엔 온보딩 마법사 화면이 뜨고 LLM 공급자와 벡터DB를 선택하도록 안내받습니다.
- STEP 02
개발 모드(NODE_ENV=development)로 서버를 켤 경우 설정값이 저장되지 않아 재시작할 때마다 온보딩 화면으로 되돌아가므로, .env.development 파일에 직접 설정을 넣어야 한다는 점을 devcontainer 문서에서 명시적으로 경고합니다.
- STEP 03
워크스페이스를 만들고 PDF나 웹링크, GitHub 저장소 등을 업로드하면 collector가 이를 텍스트로 변환해 서버로 넘기고, 임베딩이 생성되어 벡터DB에 쌓이는 과정을 진행 상태로 확인할 수 있습니다.
- STEP 04
채팅창에서 업로드한 문서에 대해 질문하면 관련 청크가 검색되어 LLM 응답에 인용 근거로 함께 표시되는 RAG 답변을 받게 됩니다.
- STEP 05
MCP나 에이전트 스킬을 활성화하면 단순 Q&A를 넘어 웹 스크래핑, 저장소 동기화 같은 에이전틱 작업을 채팅 안에서 호출해 볼 수 있습니다.
- STEP 06
HuggingFace Spaces나 OpenShift처럼 특수 환경에 배포할 경우 전용 Dockerfile(예: 아비트러리 UID/GID 처리, 퍼시스턴트 스토리지 심볼릭 링크)을 따로 써야 정상 동작한다는 점을 직접 겪게 됩니다.
실행하면 문서 업로드부터 임베딩·검색·LLM 응답까지 이어지는 자체 호스팅 RAG 챗봇 UI와, 워크스페이스별로 격리된 지식베이스, 다양한 문서/저장소 커넥터, 에이전트·MCP 도구 실행 환경을 손에 넣게 됩니다. 데이터는 로컬 스토리지 또는 지정한 퍼시스턴트 볼륨에 남아 외부로 나가지 않는 것이 핵심 가치입니다.
개발 모드에서는 설정이 저장되지 않아 재시작마다 온보딩으로 돌아가는 알려진 동작이 README에 명시되어 있어, 초기 설정 후 반드시 .env.development를 손대야 합니다.
Puppeteer/Chromium, ffmpeg, Tesseract OCR 등 무거운 네이티브 의존성이 많아 설치·이미지 빌드 시간이 길고, ARM64 등 일부 아키텍처에서는 별도 대응(예: Chromium 바이너리 미제공)이 필요할 수 있습니다.
OpenShift처럼 임의 UID/GID로 컨테이너를 실행하는 환경에서는 표준 docker/Dockerfile이 아닌 별도의 OpenShift 전용 Dockerfile과 entrypoint를 써야 하며, 두 배포 경로를 혼용하면 권한 문제가 발생합니다.
제공된 자료만으로는 벡터DB나 LLM 공급자별 실제 응답 품질, 임베딩 속도, 대용량 문서 처리 시 성능은 확인할 수 없어 이 부분은 실사용 전까지 알 수 없습니다.
사내 문서나 개인 지식베이스를 외부 클라우드로 보내지 않고 직접 운영하고 싶은 팀·개인에게 적합하며, Docker/Helm/클라우드 배포 스크립트가 이미 갖춰져 있어 자체 인프라에 얹기 수월합니다. collector의 다양한 로더, 미들웨어 기반 페이로드 검증, 세분화된 배포 문서(OpenShift 주의사항, devcontainer 체크리스트 등)를 보면 단순 데모가 아니라 실제 운영 이력이 쌓인 성숙한 코드베이스임을 소스 구조와 주석만으로도 충분히 확인할 수 있어, 직접 설치해보지 않아도 이 판단에는 무리가 없습니다.