Dify — 프로덕션 지향 Agentic Workflow / LLM App 플랫폼

한 줄 요약: Dify는 시각적 워크플로우·에이전트 빌더, RAG/Knowledge Pipeline, 멀티 모델 제공자 추상화, 플러그인/툴 런타임, 셀프호스팅 운영 구성을 하나의 모노레포에 통합한 오픈소스 플랫폼이다.

분석 스냅샷: 2026-04-07
분석 범위: GitHub README, 공식 Docs, GitHub Discussions, 소스 코드 구조, Docker Compose 배포 토폴로지
Wiki 참고: 공개 GitHub Wiki는 확인되지 않았고, 실질적인 문서 허브는 docs.dify.ai 및 저장소 내 docs/ 디렉터리다.

Quick Links

Repository: https://github.com/langgenius/dify
Official Docs: https://docs.dify.ai
Self-hosting (Docker Compose): https://docs.dify.ai/en/getting-started/self-hosting/docker-compose
Dify Cloud / Hosted Product: https://cloud.dify.ai
Project Website: https://dify.ai
GitHub Discussions: https://github.com/langgenius/dify/discussions
SDKs (in repo): sdks/nodejs-client, sdks/php-client
Related Paper: README/공식 Docs 기준으로 프로젝트 전용 논문 링크는 명시되어 있지 않음

Key Features

시각적 AI Workflow / Agent 빌더
- 노드 기반 캔버스에서 LLM, Tool, Code, Reasoning, Loop, Variable Assigner, Human Input 등을 조합해 앱을 설계할 수 있다.
- 최근 UI 스냅샷만 봐도 단순 챗봇이 아니라 반복(Loop)·툴 사용·상태 변수 관리가 가능한 agentic runtime으로 확장된 것이 보인다.
Knowledge / RAG 파이프라인의 제품화
- 단순 문서 업로드가 아니라, ingestion → split/extract → embed → retrieve까지 이어지는 Knowledge Pipeline을 별도 제품 표면으로 끌어올렸다.
- 내장 템플릿과 DSL 기반 파이프라인 구성을 통해 재사용 가능한 ingestion flow를 만들 수 있다.
멀티 모델 제공자 추상화
- OpenAI, Anthropic, Gemini, Azure OpenAI, Ollama, Hugging Face 등 다양한 제공자를 동일한 제품 표면에서 관리한다.
- 코드상으로도 ProviderManager, ModelManager, LBModelManager가 분리되어 있어 tenant 단위 설정·기본 모델 선택·로드밸런싱을 처리한다.
플러그인 / 툴 / 데이터소스 생태계
- 모델 플러그인뿐 아니라 Data Source Plugin(예: web crawler, online document, online drive) 계층이 있다.
- 실행 시 plugin_daemon을 통해 플러그인 라이프사이클을 관리하고, 외부 기능을 API core와 느슨하게 결합한다.
코드 실행 격리(Sandbox)
- 워크플로우의 code node 실행을 별도 sandbox 서비스로 격리한다.
- 이는 사용자 정의 코드, 동적 툴 호출, 외부 HTTP 접근을 포함하는 agent 시스템에서 매우 중요한 설계 포인트다.
비동기 워크플로우 실행과 스케줄링
- worker, worker_beat, Celery queue를 사용하여 긴 워크플로우, 문서 인덱싱, 스케줄/트리거, 정리 작업을 비동기로 처리한다.
- 코드상에서는 워크플로우 재개(resume), time-slice, trigger layer 같은 개념도 확인된다.
LLMOps / 운영 표면
- Prompt IDE, 앱 배포, 로그/트레이스, API 기반 BaaS 기능이 한 플랫폼 안에 모여 있다.
- 단순 라이브러리보다 제품 운영면(product surface) 이 훨씬 넓다.
셀프호스팅과 유연한 스토리지 선택
- 기본 quick start는 Postgres + Redis + Weaviate 조합이지만, Docker Compose profiles에 Qdrant, pgvector, Milvus, OpenSearch, Elasticsearch, Chroma 등 다양한 대안을 둔다.
- 즉, retrieval은 중요하지만 storage backend에는 강한 vendor lock-in을 피하는 전략을 취한다.
트리거 및 서비스 API 표면
- 백엔드 구조상 service_api, trigger, inner_api, mcp 등 별도 컨트롤러 계층이 있어, 단일 웹앱이 아니라 다중 API surface를 가진 플랫폼 구조다.
재사용 가능한 SDK / Client 계층
- 저장소 안에 Node.js / PHP SDK가 있고, 웹 프런트도 web/service/* 계층을 통해 도메인별 API client를 분리한다.

위 그림은 저장소에 포함된 실제 제품 스크린샷이다. Loop, Reasoning, Act, Variable Assigner가 함께 보이므로, Dify가 단순 프롬프트 래퍼를 넘어 상태ful agent workflow editor 방향으로 진화했음을 시사한다.

Tech Stack

1) 애플리케이션 / 언어 / 프레임워크

영역	기술	비고
Backend	Python `~3.12`	`api/pyproject.toml` 기준
Backend Web Framework	Flask `3.1.2`	API/Console/Web surface 구성
Async / Job Queue	Celery `5.6.2`	worker / beat 실행
ORM / DB Layer	SQLAlchemy `2.0.29`, Flask-SQLAlchemy `3.1.1`	관계형 DB 모델 및 세션 관리
Validation / Settings	Pydantic `2.12.5`, pydantic-settings `2.13.1`	설정과 데이터 모델
Serving	Gunicorn `25.3.0`, gevent `25.9.1`	프로덕션 웹 서빙
LLM Routing Layer	LiteLLM `1.82.6`	다양한 모델 제공자 연결
Vector DB Client	Weaviate Client `4.20.4`	기본 quick start vector backend 후보
Observability	OpenTelemetry API/SDK `1.40.0`	trace header/telemetry 계층
Frontend	TypeScript `6.0.2`	Monorepo workspace
Frontend Framework	Next.js `16.2.2`	`web/` 앱
UI Runtime	React `19.2.4`	App Router 기반
Styling	Tailwind CSS `4.2.2`	프런트 스타일링
Data Fetching	TanStack React Query `5.96.1`	클라이언트 데이터 패턴
Node-based Canvas	ReactFlow `11.11.4`	워크플로우 편집 UI 핵심
Rich Text / Editor	Lexical `0.42.0`	프롬프트/텍스트 편집기
Charts	ECharts `6.0.0`	시각화 요소
UI Dev Tooling	Storybook `10.3.4`	컴포넌트 개발
Workspace Tooling	Node `^22.22.1`, pnpm `10.33.0`	루트 workspace 기준
Python Tooling	`uv`	백엔드 개발/실행 도구 체인

2) 배포 / 런타임 구성 요소

구성 요소	버전 / 이미지	역할
`api`	`langgenius/dify-api:1.13.3`	Flask API 및 핵심 서비스
`worker`	`langgenius/dify-api:1.13.3`	Celery worker
`worker_beat`	`langgenius/dify-api:1.13.3`	Celery beat scheduler
`web`	`langgenius/dify-web:1.13.3`	Next.js 프런트엔드
`plugin_daemon`	`langgenius/dify-plugin-daemon:0.5.3-local`	플러그인 관리/실행
`sandbox`	`langgenius/dify-sandbox:0.2.14`	code node 격리 실행
`db_postgres`	`postgres:15-alpine`	관계형 DB
`redis`	`redis:6-alpine`	캐시/큐/상태
`weaviate`	`semitechnologies/weaviate:1.27.0`	기본 벡터 DB 옵션
`nginx`	`nginx:latest`	reverse proxy / ingress
`ssrf_proxy`	`ubuntu/squid:latest`	네트워크 안전성 보조

3) 선택 가능한 벡터 / 검색 / DB 프로파일

Docker Compose 프로파일에 다음 대안들이 보인다.

weaviate
qdrant
pgvector
pgvecto-rs
milvus
opensearch
elasticsearch
chroma
mysql
couchbase
oracle
oceanbase
seekdb
matrixone
myscale
opengauss
vastbase
iris

해석: Dify는 “하나의 특정 vector DB에 종속된 제품”이 아니라, RAG를 중심 기능으로 두되 백엔드 저장소는 교체 가능하도록 설계한 플랫폼이다.

4) 플러그인 관점의 기술 포인트

Data Source Plugin 문서 기준, 데이터 소스 플러그인은 대략 다음 구조를 갖는다:
- manifest.yaml
- provider/
- datasources/
- main.py
예시 문서에서 요구되는 플러그인 SDK는 dify-plugin >=0.5.0,<0.6.0
모델 플러그인 유형은 문서상 LLM, Embedding, Rerank, Speech2Text, Text2Speech까지 확장된다.

Architecture

1) 런타임 토폴로지

저장소에 포함된 docker/docker-compose.png를 기준으로 보면, Dify의 기본 self-host 구동은 다음과 같은 다층 런타임이다.

Ingress / Edge
- nginx
사용자 인터페이스 계층
- web (Next.js)
핵심 API / 오케스트레이션 계층
- api (Flask)
비동기 실행 계층
- worker
- worker_beat
툴 / 플러그인 계층
- plugin_daemon
격리 실행 계층
- sandbox
데이터 계층
- db_postgres
- redis
- weaviate 또는 다른 vector/search backend
네트워크 경계 / 보안 보조
- ssrf_proxy

2) 요청 / 데이터 흐름 해석

사용자는 nginx를 통해 웹 UI와 API에 접근한다.
브라우저는 web(Studio / Explore / Knowledge / Tools / Plugins UI)에서 화면을 렌더링한다.
프런트는 api의 여러 surface(console, web, service_api, files, trigger, inner_api, mcp)에 요청한다.
api는 내부 서비스 계층에서 앱, 워크플로우, RAG, 플러그인, 툴, 트리거 로직을 조합한다.
시간이 걸리는 작업은 Celery queue로 넘겨 worker가 수행한다.
워크플로우가 code node를 만나면 sandbox를 호출하고, 플러그인/툴 호출은 plugin_daemon을 경유한다.
상태/메타데이터는 Postgres와 Redis에 저장되고, 임베딩/검색용 데이터는 vector backend에 저장된다.
결과는 다시 API/UI로 흘러와 앱 응답, Studio 로그, Knowledge 상태 등으로 노출된다.

3) 코드 기준으로 본 레이어 구조

레이어	주요 경로	왜 중요한가
Composition Root	`api/app.py`, `api/app_factory.py`	Flask 앱이 어떻게 조립되고, 확장(ext)들이 어떤 순서로 연결되는지 보여준다.
API Surface	`api/controllers/*`, `api/extensions/ext_blueprints.py`	`console`, `web`, `service_api`, `files`, `trigger`, `inner_api`, `mcp` 등 공개 인터페이스를 구분한다.
Workflow Runtime	`api/core/workflow/*`	`WorkflowEntry`, graph runtime, variable pool, child engine builder 등이 있다.
Async Workflow Execution	`api/tasks/app_generate/`, `api/tasks/workflow_cfs_scheduler/`	비동기 워크플로우 실행, queue 분리, retry, schedule, resume 전략을 담는다.
RAG Core	`api/core/rag/*`	cleaner, extractor, splitter, embedding, retrieval, pipeline 등 문서 파이프라인의 핵심이다.
RAG Product Layer	`api/services/rag_pipeline/*`	파이프라인 템플릿, DSL, 관리 서비스, 태스크 프록시 등 제품 레벨 orchestration이 있다.
Model / Provider Abstraction	`api/core/provider_manager.py`, `api/core/model_manager.py`	멀티 provider 설정, default model 선택, provider bundle, load balancing이 구현된다.
Plugin Runtime	`api/core/plugin/`, `api/services/plugin/`	플러그인 연동을 core API에서 분리하는 계층이다.
Frontend App Shell	`web/app/*`	Next.js route 구조와 제품의 실제 사용자 표면을 본다.
Frontend API Binding	`web/service/*`	`apps.ts`, `datasets.ts`, `plugins.ts`, `tools.ts`, `use-flow.ts`, `use-models.ts` 등 도메인별 API 호출 계층
Deployment	`docker/*`	가장 빠르게 전체 시스템 경계를 이해하는 진입점
SDKs	`sdks/*`	외부 서비스 통합/사용법을 볼 수 있는 참고 구현
E2E / Stress	`e2e/`, `scripts/stress-test/`	실제 사용자 플로우와 성능 관심사를 확인 가능

4) 구현 관점에서 특히 눈에 띄는 설계 포인트

a. `app_factory.py`가 진짜 조립 중심점이다

이 파일은 설정 로드, 확장 초기화, 요청 전/후 처리, trace header 주입, blueprint 등록 등을 묶는 composition root 역할을 한다.
즉, Dify를 재구현하거나 일부만 참고하려면, 개별 기능보다 먼저 애플리케이션이 어떤 순서로 조립되는지 이해하는 것이 중요하다.

b. Workflow runtime은 “단순 DAG 실행기”보다 한 단계 복잡하다

WorkflowEntry는 내부적으로 GraphEngine을 만들고, worker 수/스케일 업/다운 관련 설정을 사용한다.
이는 Dify의 워크플로우가 단순 동기식 체인이 아니라, 동시성·재개(resume)·control channel을 염두에 둔 엔진이라는 뜻이다.

c. Celery 계층은 제품 플랜 / 리소스 정책까지 반영한다

async_workflow_tasks.py를 보면 queue가 PROFESSIONAL_QUEUE, TEAM_QUEUE, SANDBOX_QUEUE 등으로 나뉘어 있다.
즉, 큐 설계가 단순 백그라운드 작업이 아니라 멀티테넌트 제품 정책 + 워크로드 격리에도 연결되어 있다.

d. 모델 추상화가 꽤 성숙하다

ProviderManager는 tenant 단위 provider 설정을 관리하고, ModelManager는 기본 모델 선택과 제공자별 모델 인스턴스 획득을 담당한다.
LBModelManager는 Redis 기반 round-robin/cooldown 패턴을 사용해 로드밸런싱된 자격 증명 선택까지 처리한다.
이 부분은 의료 AI나 enterprise agent 제품에서 특히 참고할 가치가 높다.

e. RAG가 부가 기능이 아니라 “제품 축”이다

api/core/rag/가 매우 크고, 별도의 services/rag_pipeline/이 존재하며, release discussion에서도 Knowledge Pipeline이 강조된다.
이는 Dify가 retrieval을 부가 옵션으로 붙인 것이 아니라, 지식 ingestion과 검색을 워크플로우/앱과 동등한 핵심 축으로 본다는 의미다.

f. Plugin/Sandbox 분리는 보안과 확장성 측면에서 좋은 패턴이다

플러그인과 코드 실행을 API 프로세스에 직접 넣지 않고 외부 서비스로 분리한 것은,

blast radius 축소
언어/환경 격리
업그레이드 독립성
운영상 모니터링/제한 설정
이라는 면에서 좋은 설계다.

5) 재구현 또는 레퍼런스 학습 시 “먼저 읽을 파일”

docker/docker-compose.yaml
- 전체 시스템 경계를 가장 빨리 이해할 수 있다.
api/app_factory.py
- 앱 조립 순서와 확장 등록 구조 파악용.
api/extensions/ext_blueprints.py
- 어떤 API surface가 있는지 빠르게 본다.
api/core/workflow/workflow_entry.py
- 워크플로우 런타임 진입점.
api/tasks/app_generate/async_workflow_tasks.py
- 비동기 실행, resume, queue 전략 이해용.
api/core/rag/ 및 api/services/rag_pipeline/
- Dify식 RAG 제품화 패턴의 핵심.
api/core/provider_manager.py, api/core/model_manager.py
- 멀티 모델/멀티 provider abstraction 참고용.
web/app/, web/service/
- Studio UI와 API binding이 실제로 어떻게 연결되는지 본다.

6) Discussions에서 읽히는 프로젝트 방향성

1.9.0 release discussion의 핵심 키워드는 Knowledge Pipeline과 Queue-based Graph Engine이었다.
이는 Dify가 “프롬프트/챗봇 빌더”에서 “agentic workflow + ingestion orchestration 플랫폼”으로 무게중심을 옮기고 있음을 보여준다.
커뮤니티 discussion에서는 반복(loop)·review/refine·multi-agent 스타일 사용 사례에 대한 관심도 보인다.
동시에 Python + Celery 중심 구조가 커질수록 스케일/운영 복잡성이 커질 수 있다는 우려도 존재한다.

요약 해석:
Dify는 연구용 실험 프레임워크보다, 실제 제품 운영에 필요한 표면(UI, API, queue, plugins, self-hosting, logs, knowledge ingest) 을 하나로 묶는 방향으로 진화하고 있다.

Usage & Setup

1) 가장 빠른 셀프호스팅: Docker Compose

공식 문서 기준 최소 하드웨어 가이드는 대략 2 vCPU / 4 GiB RAM 수준이다.

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

초기 설치 화면:

http://localhost/install

문서 예시처럼 “최신 릴리스 태그”를 바로 체크아웃하려면 다음 방식도 가능하다.

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" \
  https://github.com/langgenius/dify.git

2) 소스 기반 로컬 개발

백엔드는 uv, 프런트는 pnpm 기반이다. 저장소의 dev/ 스크립트가 개발 편의 계층을 제공한다.

cd dify

./dev/setup
./dev/start-docker-compose
./dev/start-api
./dev/start-web
./dev/start-worker
# 필요 시
./dev/start-beat

3) 핵심 개발/검증 커맨드

백엔드:

cd api
uv run pytest
uv run ruff check .
uv run basedpyright

프런트엔드:

cd web
pnpm install
pnpm dev
pnpm test

4) 처음 만질 가능성이 높은 환경변수

초기 self-host나 사설망 배포 시 아래 변수부터 확인하는 편이 좋다.

CONSOLE_API_URL
CONSOLE_WEB_URL
SERVICE_API_URL
APP_API_URL
PLUGIN_DAEMON_URL
PLUGIN_DAEMON_KEY
PLUGIN_DIFY_INNER_API_URL
SANDBOX_API_KEY
SANDBOX_ENABLE_NETWORK
SANDBOX_HTTP_PROXY

5) 운영 관점에서 바로 체크할 것

docker compose ps
docker compose logs -f api
docker compose logs -f worker
docker compose logs -f web

실무 팁:
Dify는 “웹앱 하나”가 아니라 api + worker + beat + plugin_daemon + sandbox + db + redis + vector backend를 함께 운영하는 플랫폼이다.
프로덕션 배포 전에는 반드시 아래를 정해야 한다.

어떤 vector backend를 쓸지
sandbox의 네트워크 권한을 어디까지 열지
plugin_daemon 접근 제어를 어떻게 할지
로그/trace 보존 정책을 어떻게 둘지
worker scale-out 기준을 무엇으로 잡을지

Personal Insights

1) 의료 AI(Medical AI)에 주는 영감

왜 참고할 가치가 큰가

Knowledge Pipeline은 임상 문서 ingestion 흐름을 제품화하기에 좋은 패턴이다.
예: 진료지침 PDF / 병리 리포트 / 검사 매뉴얼 / 내부 SOP → 전처리 → chunking → embedding → QA app 연결
Human Input / Pause / Resume 계층은 의사 검토가 필요한 clinical copilot에 잘 맞는다.
Plugin/Data Source 구조는 FHIR, PACS, LIS, 보험청구 시스템, 내부 문서 저장소 등을 어댑터로 연결하기 좋다.
Sandbox 분리는 PHI가 걸린 코드 실행이나 변환 로직을 core API와 격리하는 데 유리하다.

어떻게 응용할 수 있는가

plugin_daemon 패턴을 활용해 병원 전산/EMR 연동을 별도 runtime으로 분리
RAG Pipeline 템플릿을 활용해 질환별/부서별 ingestion 템플릿 정의
WorkflowEntry + Celery 구조를 이용해 triage, documentation assistance, guideline retrieval를 비동기 처리
ModelManager 패턴을 활용해 민감 업무는 온프레미스 모델, 일반 업무는 외부 API 모델로 라우팅

주의할 점

Dify의 기본 quick start 자체가 의료 규제를 만족시키는 것은 아니다.
의료 환경에서는 반드시 다음이 필요하다.

데이터 저장 위치 통제
PHI 비식별화
audit/event retention
sandbox egress 통제
secret management
모델 호출 이력의 법적/조직적 추적성

2) Bioinformatics에 주는 영감

특히 잘 맞는 부분

긴 파이프라인을 UI로 설계하고, 비동기 작업으로 돌리며, 결과를 다시 보고서 생성으로 연결하는 구조가 실험실 워크플로우와 닮아 있다.
RAG는 다음과 같은 지식 기반을 연결하기 좋다.
- assay SOP
- variant interpretation guideline
- wet-lab protocol
- 내부 분석 노트
- 논문 초록 / 메서드 요약
Plugin 구조는 BLAST, VEP, Ensembl API, UCSC, 내부 LIMS를 툴로 감싸는 데 적합하다.

좋은 응용 시나리오

샘플 메타데이터 수집 → QC 결과 파싱 → variant annotation → 문헌 retrieval → 초안 리포트 생성
실험 SOP 질의응답 + human review + 최종 보고서 export
팀별/프로젝트별로 다른 모델 제공자와 지식 인덱스를 tenant 수준에서 분리

한계

Dify는 HPC 스케줄러가 아니다.
대규모 유전체 파이프라인 자체를 Dify worker에서 직접 처리하기보다,
Dify를 orchestration UI / AI reasoning layer로 두고, 실제 heavy compute는 Nextflow, Snakemake, Airflow, Kubernetes Jobs 같은 별도 시스템에 위임하는 구성이 더 현실적이다.

3) Autonomous Agent 개발에 주는 영감

가장 배울 만한 지점

Agent를 “모델 호출 루프”가 아니라 제품형 시스템으로 본다.
상태 변수, loop, tool calling, code execution, trigger, async queue, human input, plugin lifecycle을 하나의 플랫폼 안에서 다룬다.
특히 다음 패턴은 재사용 가치가 높다.
1. UI와 runtime 분리
2. plugin/tool plane의 외부화
3. code execution sandboxing
4. queue 기반 graph execution
5. tenant-scoped model/provider abstraction
6. resume 가능한 long-running workflow

실제 구현 영감

실험용 agent framework를 쓰더라도, 프로덕션으로 갈 때는 Dify처럼
- API 표면 분리
- 비동기 큐 설계
- 모델 credential 관리
- human checkpoint
- plugin runtime isolation
  을 초기에 설계하는 편이 좋다.

비판적으로 볼 지점

연구용으로 새로운 planning/search 알고리즘을 빠르게 실험하려면 Dify는 다소 무겁다.
반대로 “실험 코드를 제품으로 굳히는 시점” 에는 Dify의 구조가 매우 좋은 레퍼런스다.
즉, Dify는 “가장 자유로운 agent research sandbox”라기보다, agent를 운영 가능한 제품으로 만드는 데 필요한 시스템 패턴 모음에 가깝다.

4) 한 문장 결론

Medical AI: “감사 가능하고 review 가능한 임상용 copilot” 구조를 배울 수 있다.
Bioinformatics: “지식 기반 + 파이프라인 오케스트레이션 + 비동기 리포트 생성” 구조를 참고하기 좋다.
Autonomous Agents: “실험용 agent를 운영형 agent 플랫폼으로 승격시키는 아키텍처 패턴”을 배울 수 있다.

Figures Included

이 아카이브에는 다음 figure를 포함했다.

figures/GitHub_README_if.png
- 저장소/브랜드 커버 이미지
figures/docker-compose.png
- Self-host/Docker Compose 기반 시스템 아키텍처 다이어그램
figures/describe.png
- Studio / Agent workflow UI 스크린샷
figures/models.png
- 지원 모델 제공자 생태계 이미지

Sources Consulted

README / Repository

https://github.com/langgenius/dify

Official Docs

Discussions / Release Notes

https://github.com/langgenius/dify/discussions/26138 — 1.9.0 release discussion (Knowledge Pipeline, Queue-based Graph Engine)
https://github.com/langgenius/dify/discussions/5891 — loop / iterative workflow 관련 커뮤니티 관심
https://github.com/langgenius/dify/discussions/31943 — 스케일/모놀리식 구조에 대한 커뮤니티 시각

핵심 소스 경로(분석에 직접 사용)

api/app.py
api/app_factory.py
api/extensions/ext_blueprints.py
api/tasks/app_generate/async_workflow_tasks.py
api/core/workflow/workflow_entry.py
api/core/rag/*
api/services/rag_pipeline/*
api/core/provider_manager.py
api/core/model_manager.py
web/app/*
web/service/*
docker/docker-compose.yaml

'AI 생성 글 정리 > tech_github' 카테고리의 다른 글

Unsloth — unified local interface for running and training AI models (0)	2026.04.08
Understudy — GUI·브라우저·셸·메시징을 한 세션에서 묶는 로컬 퍼스트 컴퓨터 에이전트 (0)	2026.04.08
RAGFlow — Deep document understanding + Agent 기능을 결합한 오픈소스 RAG 엔진 (0)	2026.04.08
Paperclip — “자율 AI 회사”를 운영하기 위한 오픈소스 control plane (0)	2026.04.08
Oh My OpenAgent — OpenCode용 멀티모델 에이전트 오케스트레이션 하네스 (0)	2026.04.07