
2026년, 에이전트의 harness를 직접 구축하기──모든 레이어의 '현재 살아있는' OSS를 확인하여 정리
요약
2026년 AI 에이전트 구축을 위한 17개 레이어별 오픈소스(OSS) 도구 카탈로그를 정리했습니다. 단순 프레임워크 선택을 넘어 본체, 기억, 도구 연결 등 각 계층별로 살아있는 최신 리포지토리를 전수 조사하여 제안합니다.
핵심 포인트
- 단일 프레임워크 시대가 끝나고 레이어별 harness 구축 시대 도래
- 17개 레이어(본체, 기억, 샌드박스 등)로 구성된 에이전트 생태계
- gh api를 통한 실시간 업데이트 및 활성 상태 검증 완료
- opencode, gemini-cli, aider 등 용도별 최적의 도구 추천
최첨단 AI를 기술 내용까지 파헤치는 「AI Watch」 기사입니다. 원문은 anmolbaranwal 씨의 "Open Source Toolkit for Building AI Agents in 2026" (17개 레이어·각 레이어별 제1 후보 + 대안)입니다. 다만, 이러한 종류의 「정리」 글은 링크 끊김, 리포지토리(Repository) 이전, 개발 중단 등으로 인해 순식간에 쓸모없어지곤 합니다. 그래서 원문 기사에 등장하는 약 100개의 리포지토리를 2026-06에 gh api로 전수 확인하였으며, 스타(Star) 수·최종 push·리포지토리 이전·아카이브(Archive) 여부를 확인한 후 다시 정리했습니다. ★은 대략적인 수치이며, push는 최종 업데이트 월(확인된 값)입니다. 각 레이어는 「제1 후보를 조금 깊게 + 대안은 목록으로」 구성되어 있습니다.
"에이전트 프레임워크, 결국 무엇을 사용해야 하는가?"라는 질문은 2026년에는 이미 구식입니다. 단일 프레임워크의 승자를 선택하는 시대는 끝났으며, 레이어별로 harness를 구축하는 시대가 되었습니다. 본체, 편성, 기억, 도구 연결, 샌드박스(Sandbox), 평가, 관측──나아가 UI·음성·스크레이핑(Scraping)·문서 처리까지, 구현의 모든 레이어에 각각 전문적인 OSS가 존재합니다.
이 기사의 목적은 두 가지입니다. (1) 구현의 전경을 17개 레이어로 망라한다 (완전성). (2) 그 전부를 실제로 실행하여 「지금도 살아있는가」를 확인한다 (신선도). 정리 글의 링크를 맹신하지 않고, 이전·중단·아카이브된 것들을 걸러냈습니다.
이전 기사에서 지시 시스템을 L0–L7의 능력 사다리(Ability Ladder)로 정리했습니다. 그것은 「제약을 어느 채널에 실을 것인가」에 대한 척도였습니다. 이번에는 그 자매편으로, 실제로 구축하기 위한 "부품 카탈로그"입니다. harness를 「제대로 달린다(실행) / 계속 달린다(상태) / 안정적으로 달린다(거버넌스)」의 3층 구조로 파악하는 관점이 여기서도 그대로 적용됩니다.
이하, 원문 기사의 17개 레이어를 3개 그룹으로 묶어, 각 레이어의 확인된 수치와 함께 나열합니다.
터미널/IDE에서 실제로 코드를 작성하는 본체. 경쟁이 가장 치열하며, 거의 전부가 최근에 push되었습니다.
제1 후보는 opencode (현재 anomalyco/opencode, ~169k)입니다. 이 카테고리에서 가장 많은 스타를 보유하고 있으며, 터미널 네이티브·75개 이상의 프로바이더(Provider) 대응·병렬 세션이 강점입니다. 특정 IDE에 얽매이지 않고 어떤 모델이라도 동일한 조작감으로 돌릴 수 있다는 점이 유효합니다. 다만 원래의 sst/opencode에서 소유자(Owner)가 이전했으므로, 오래된 기사의 링크는 현재의 정식 명칭과 차이가 있다는 점에 주의하십시오. 용도에 따라 선택한다면, Google 계열은 gemini-cli, OpenAI 공식은 codex, VS Code 안에서 승인하며 진행하고 싶다면 cline, Git 기반의 페어 프로그래밍(Pair Programming)은 aider를 추천합니다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
opencode (현재 anomalyco/opencode) | ~169k | 06 | 터미널 네이티브·75+ 프로바이더·병렬 세션. sst/opencode에서 이전 |
| gemini-cli (google-gemini) | ~105k | 06 | Google 제작, 1M 토큰 컨텍스트 |
| codex (openai) | ~88k | 06 | OpenAI 공식 터미널 에이전트 |
OpenHands (현재 OpenHands/OpenHands) | ~76k | 06 | 브라우징·PR까지. All-Hands-AI/에서 이전 |
| cline (VS Code 확장) | ~63k | 06 | 단계별 승인 |
| aider | ~46k | 05 | Git 네이티브 페어 프로그래밍 |
goose (현재 aaif-goose/goose) | ~46k | 06 | Block 개발, MCP 퍼스트. 소유자 이전 |
「계획→도구→상태 유지→서브 에이전트」를 돌리는 토대.
제1 후보는 LangGraph (~34k)입니다. 에이전트(Agent)의 움직임을 「상태를 가진 그래프」로 작성하고, 각 노드(Node)에서 체크포인트(Checkpoint)를 잡을 수 있는 것이 핵심입니다. 도중에 멈춰서 인간이 판단하고 다시 재개하는 (human-in-the-loop) 방식을 자연스럽게 작성할 수 있으므로, 「실패하면 되돌아가기·분기하기」를 정교하게 만들고 싶은 실무 환경에서 강력합니다. 디팩토(De facto) 중 하나이며 자료도 많습니다. 취향에 따라 선택한다면, TypeScript 중심이라면 Mastra, 구조화된 출력(Structured Output)의 타입 안정성(Type Safety)을 중시한다면 Pydantic AI, 영구 기억을 포함한 가벼움을 원한다면 Agno, Google 스택이라면 ADK를 추천합니다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| Agno | ~40k | 06 | 경량 + 영구 기억, AgentOS (FastAPI) 포함 |
| LangGraph | ~34k | 06 | 상태 그래프 (State Graph) + 체크포인트. 디팩토 (De facto) 중 하나 |
| Mastra | ~25k | 06 | TypeScript 퍼스트, RAG/관측/MCP 포함 |
| Deep Agents (LangGraph 상) | ~24k | 06 | 계획 · FS 툴 · 서브 에이전트 · 문맥 압축 |
| Google ADK | ~20k | 06 | 공식 ADK, Vertex AI 연동 |
| Pydantic AI | ~17k | 06 | 타입 안전성 · 구조화된 출력 검증이 강점 |
| PocketFlow | ~11k | 03 | 100줄 미니멀 LLM 프레임워크 |
본체를 「자율적으로 돌아가는」 상태로 만드는 골격 (계획 · FS · 서브 에이전트 · 문맥 압축).
제1 후보는 Deep Agents (LangGraph 상, ~24k)이다. 코딩 에이전트 (Coding agent)를 「자율적으로 길게 돌아가는」 상태로 만들기 위한 골격으로, 계획 수립 · 파일 시스템 (FS) 계열 툴 · 서브 에이전트 · 문맥 압축을 처음부터 갖추고 있다. 제로 베이스에서 harness를 작성하는 것보다, 이곳을 토대로 부족한 부품을 추가하는 것이 압도적으로 빠르다. 「설명으로부터 결정적이고 재현 가능한 harness를 생성한다」는 발상으로 접근한다면 Archon, 달성도에 따라 에이전트 자체가 진화하는 outcome(결과) 중심이라면 Hive도 후보이다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| Archon | ~22k | 06 | 설명으로부터 결정적 · 재현 가능한 harness를 생성 |
| browser-harness (browser-use) | ~14k | 05 | LLM이 CDP를 직접 호출하는 자기 복구 (Self-healing) harness |
| Deep Agents | ~24k | 06 | (위의 편성 중복) 계획 + 서브 에이전트 |
| Hive | ~10k | 05 | 목표 달성도에 따라 에이전트가 진화하는 outcome 중심 |
여러 에이전트 (Agent)를 역할 분담/병렬로 구동.
제1 후보는 CrewAI (~53k)이다. 「리서치 담당 · 집필 담당 · 리뷰 담당」과 같이 역할 (Role)을 나누어 협조시키는 발상이 직관적이라 첫걸음을 떼기 쉽다. 나아가 Flows를 통해 이벤트 드리븐 (Event-driven) 제어도 추가할 수 있으므로, 프로토타입에서 프로덕션까지 끊김 없이 가져갈 수 있다. 대화 드리븐 (Conversation-driven)을 세밀하게 구성한다면 AG2 (AutoGen 커뮤니티 fork), 장기 지원을 노린다면 Microsoft Agent Framework를 추천한다. 참고로 MetaGPT (~68k)는 FoundationAgents/로 이전되었고 마지막 push가 2026-01로 다소 정체된 상태이므로, 채택 시 활성도를 확인하고 싶다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
MetaGPT (현 FoundationAgents/MetaGPT) | ~68k | 01 | PM/설계/구현 역할로 「소프트웨어 회사」를 모의. 이전 + 다소 정체 |
| CrewAI | ~53k | 06 | 역할 분담. Flows로 이벤트 드리븐도 지원 |
| AgentScope (Alibaba) | ~26k | 06 | 음성 · MCP · A2A 대응의 프로덕션 지향 |
| OWL (camel-ai) | ~20k | 05 | 계획 + 실행, GAIA 벤치마크 상위권 |
| Microsoft Agent Framework | ~11k | 06 | AutoGen의 후속 (장기 지원 지향) |
| AG2 (AutoGen 커뮤니티 fork) | ~4.6k | 06 | Conversable agents / Group chat |
API가 없는 앱을 「화면 단위로」 조작시키는 계층.
제1 후보는 UI-TARS Desktop (bytedance, ~36k)이다. 스크린샷으로부터 버튼이나 입력창의 위치를 맞추는 「GUI 접지 (Grounding)」 모델을 탑재하고 있어, API가 준비되지 않은 데스크톱 앱이라도 에이전트가 조작할 수 있다. 동일 리포지토리에 계획 중심의 Agent TARS도 포함되어 있다. VM 샌드박스에서 안전하게 구동하려면 cua, 시각 드리븐 (Visual-driven)으로 Web/모바일까지 다룬다면 Midscene을 추천한다. 주의할 점으로, 인기 있는 Bytebot (~11k)은 아카이브됨 (최종 push 2025-09) 상태이므로 신규 채택은 피하고 싶다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| UI-TARS Desktop (bytedance) | ~36k | 05 | GUI 접지 (Grounding) 모델. Agent TARS도 동일 리포지토리 |
| cua (trycua) | ~17k | 06 | macOS/Linux의 VM 샌드박스에서 agent 실행 |
| Midscene | ~14k | 06 | 시각 구동 UI 자동화 (Web/Android/iOS) |
| Agent-S (simular-ai) | ~12k | 05 | 계층적 계획 (Hierarchical Planning) + 과거 대화 지식 베이스 |
| Bytebot | ~11k | 2025-09 | ⚠️ 아카이브됨 (개발 중단). 채택 주의 |
헤드리스 브라우저 (Headless Browser)를 agent가 운전하게 하는 계층.
제1 후보는 Browser Use (~97k)이다. LLM 퍼스트 (LLM-first)로 설계된 브라우저 agent로, 페이지 구조를 읽고 "다음에 어디를 클릭하고 무엇을 입력할지"를 LLM이 결정하게 한다. 스크립트를 직접 작성하는 기존의 자동화와 달리, 레이아웃이 다소 변하더라도 쉽게 무너지지 않는 것이 강점이다. Desktop 버전이나 클라우드 실행을 위한 Box 등 파생 프로젝트도 활발하다. act/extract/observe/agent의 입도 (granularity)로 제어하고 싶다면 Stagehand, 이미지 인식을 통해 미지의 사이트를 공략하는 swarm 형태라면 Skyvern, Playwright를 그대로 MCP화 하고 싶다면 playwright-mcp를 추천한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| Browser Use | ~97k | 06 | LLM 퍼스트 브라우저 agent. Desktop/Box 파생도 존재 |
| Scrapling | ~59k | 06 | 셀렉터 드리프트 (Selector Drift)에 강하며 anti-bot 회피가 가능한 스크레이퍼 |
| playwright-mcp (microsoft) | ~33k | 05 | Playwright를 MCP 서버로 변환 |
| Stagehand (browserbase) | ~23k | 06 | act/extract/observe/agent의 4가지 프리미티브 (Primitives) |
| Skyvern | ~22k | 06 | 이미지 인식으로 미지의 사이트를 공략하는 agent swarm |
외부 정보를 agent의 문맥 (Context)으로 흘려넣는 입구.
제1 후보는 Firecrawl (현재 firecrawl/firecrawl, ~128k)이다. 사이트를 크롤링하여 LLM용 Markdown / JSON으로 정리해 주는 정석적인 도구로, JS 렌더링이나 인증이 필요한 페이지도 처리할 수 있다. RAG의 전단계로서 "일단 이것으로 가져온다"는 식의 제1 후보이다. mendableai/에서 이전되었으므로 링크 확인이 필요하다. API 키 없이 셀프 호스팅 (Self-hosting)을 하고 싶다면 crawl4ai, 프롬프트로 구조화된 추출 (Structured Extraction)을 지시하고 싶다면 ScrapeGraphAI, GitHub 리포지토리를 통째로 프롬프트화 하고 싶다면 Gitingest, URL 앞에 붙이기만 하면 되는 간편함을 원한다면 Jina Reader를 사용한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
Firecrawl (현재 firecrawl/firecrawl) | ~128k | 06 | 사이트 → LLM용 Markdown/JSON. mendableai/에서 이전 |
| crawl4ai | ~68k | 06 | 셀프 호스팅 · API 키 불필요 · RAG 최적화 |
| ScrapeGraphAI | ~27k | 06 | 프롬프트 구동 방식의 구조화된 추출 |
| Gitingest | ~15k | 06 | GitHub 리포지토리 → 프롬프트용 추출 |
| Jina Reader | ~11k | 05 | URL 앞에 r.jina.ai/를 붙여 Markdown화 |
PDF나 오피스 문서를 "LLM이 읽을 수 있는 구조"로 바꾸는 계층.
제1 후보는 Docling (IBM, ~61k)이다. PDF나 오피스 문서를 표, 레이아웃, 읽기 순서를 유지한 채 "DocTags"라는 구조로 변환한다. Granite-DocLing VLM을 사용하여 무너지기 쉬운 표 구성이나 단락 구성도 정밀하게 포착할 수 있어, RAG의 전처리 단계에서 효과적이다. 표와 수식 추출에 특화하고 싶다면 MinerU, 분석부터 분할 및 검색까지 일관된 흐름(End-to-end)을 원한다면 RAGFlow (~82k), 다국어 OCR은 PaddleOCR, 160개 이상의 커넥터를 가진 RAG 기반을 원한다면 LlamaIndex를 사용한다. Marker는 datalab-to/
로 이전됨.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| RAGFlow | ~82k | 06 | DeepDoc의 해석→분할→검색 end-to-end |
| PaddleOCR | ~79k | 06 | 100+ 언어 OCR |
| MinerU | ~66k | 06 | PDF 표·수식 추출 SOTA |
| Docling (IBM) | ~61k | 06 | Granite-DocLing VLM으로 DocTags 변환 |
| LlamaIndex | ~50k | 05 | 160+ 커넥터를 가진 RAG 프레임워크 |
Marker (현 datalab-to/marker) | ~36k | 05 | PDF/EPUB/PPTX→Markdown. 이전 |
| Unstructured | ~15k | 06 | 65+ 형식 (메일·표·이미지) |
듣기·말하기를 실시간으로 다루는 계층.
제1 후보는 Pipecat (~13k)이다. STT→LLM→TTS 파이프라인을 실시간으로 연결하는 '음성 에이전트(voice agent)를 위한 오케스트레이션 framework'로, 끼어들기(barge-in)나 지연 시간 관리 등 음성 특유의 난제들을 처리해 준다. 전화·음성 봇을 구축할 때의 토대다. WebRTC를 포함한 인프라까지 필요하다면 LiveKit Agents (ChatGPT Voice에서도 사용), 받아쓰기 단독으로는 Whisper (~101k), 목소리 클로닝은 fish-speech / GPT-SoVITS / CosyVoice를 사용한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| Whisper (OpenAI) | ~101k | 04 | 다국어 STT의 정석 |
| GPT-SoVITS | ~58k | 04 | 적은 양의 음성으로 목소리 클로닝 |
| fish-speech | ~31k | 06 | 다국어 제로샷(zero-shot) 음성 클로닝 |
| CosyVoice (Alibaba) | ~21k | 05 | 다국어 제로샷(zero-shot) 생성 |
| Pipecat | ~13k | 06 | STT/LLM/TTS를 연결하는 실시간 음성 framework |
| LiveKit Agents | ~11k | 06 | WebRTC, ChatGPT Voice에서도 사용됨 |
| Moonshine | ~8k | 06 | 저지연·온디바이스(on-device) STT |
에이전트를 사람에게 보여주는 계층.
제1 후보는 CopilotKit (~32k)이다. 단순한 채팅 UI 부착이 아니라, 에이전트가 앱의 상태를 읽으면서 화면을 구성하는 '생성형 UI (generative UI)'까지 가능하다는 점이 다른 것과 차별화되는 지점이다. React의 hooks를 통해 프론트엔드 측의 상태나 액션을 에이전트의 문맥(context)으로 전달하고, 반대로 에이전트의 출력을 UI 컴포넌트로 렌더링할 수 있다. 백엔드의 LangGraph / CrewAI와도 연결되므로, '백엔드 오케스트레이션'과 '프론트엔드 화면'을 하나로 관통하고 싶을 때의 제1 후보다. 벤더 중립적으로 가볍게 사용하려면 vercel/ai (AI SDK), 생성형 UI 부품에 특화한다면 tambo, headless 방식으로 구축한다면 assistant-ui를 사용한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| vercel/ai (AI SDK) | ~25k | 06 | 스트리밍/도구 호출(tool calling), Next.js 최적화 |
| CopilotKit | ~32k | 06 | 채팅 UI + hooks + 생성형 UI |
| tambo | ~11k | 06 | 생성형 UI 컴포넌트 특화 React SDK |
| assistant-ui | ~10k | 06 | 채팅 UI의 headless 프리미티브 |
| TanStack/ai | ~2.7k | 06 | 벤더 중립·모듈형 AI SDK |
| agent-native (BuilderIO) | ~448 | 06 | 에이전트와 UI가 동일한 액션 모델을 공유 |
긴 태스크·여러 세션에 걸쳐 '기억하기'.
제1후보는 mem0 (~57k)이다. 대화에서 '기억해야 할 사실'을 추출하여, 압축된 자연어(Natural Language) 형태로 유지 및 검색하는 선두 주자다. 컨텍스트 윈도우(Context Window)에 모든 것을 채워 넣는 대신, 필요한 기억만을 추출하여 주입하므로 긴 태스크나 여러 세션에 걸친 일관성을 유지하기 쉽다. 사실의 유효 기간까지 갖는 시간적 지식 그래프(Temporal Knowledge Graph)가 필요하다면 Graphiti, 에이전트(Agent)를 가로지르는 기억 API라면 Supermemory, 시스템 프롬프트(System Prompt)에 기억을 각인시키는 발상의 원조는 Letta (구 MemGPT), 대규모 코퍼스(Corpus)를 위한 결정적 그래프 기억은 Cognee다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| mem0 | ~57k | 06 | 중요한 사실을 추출하여 압축된 자연어로 유지. 선두 주자 |
| Graphiti (getzep) | ~27k | 05 | 사실의 유효 기간을 갖는 시간적 지식 그래프 |
| Supermemory | ~25k | 06 | 에이전트 가로지르는 기억 API |
| Letta (구 MemGPT) | ~23k | 05 | 기억을 시스템 프롬프트에 각인. 발상의 원조 |
| Cognee | ~18k | 06 | 대규모 코퍼스를 위한 결정적 지식 그래프 기억 |
모델이 '외부 세계'를 접하게 한다. MCP가 표준으로 정착 중.
제1후보는 Composio (~29k)이다. Gmail이나 Slack 등 외부 서비스로의 접속을 OAuth 관리와 함께 에이전트(Agent)에게 전달할 수 있는 통합 계층이다. 툴 라우터(Tool Router)를 통해 '현재 태스크에 필요한 도구만' 선택하여 노출할 수 있으므로, 도구를 늘릴수록 컨텍스트(Context)가 비대해지는 문제를 억제할 수 있다. 모델 측을 100개 이상의 프로바이더(Provider)로 통일하여 사용한다면 LiteLLM (~49k, 이쪽은 모델 게이트웨이의 사실상 표준), SQL로 데이터 소스를 다룬다면 MindsDB (minds-platform으로 이전), 가드레일(Guardrail)을 포함한 게이트웨이라면 Portkey를 사용한다. MCP 자체는 이미 표준으로 정착되어 있다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| LiteLLM | ~49k | 06 | 100+ 프로바이더를 통일 API + 비용 추적. 사실상 표준 |
MindsDB (현 mindsdb/minds-platform) | ~39k | 06 | SQL로 200+ 데이터 소스에 액세스. 이전 |
| Composio | ~29k | 06 | OAuth 관리를 포함한 통합 계층, Tool Router |
| Portkey AI Gateway | ~12k | 05 | 1,600+ 모델 + 가드레일 |
| ACI (aipotheosis-labs) | ~4.8k | 05 | 600+ 도구를 단일 MCP 서버로 |
생성된 코드를 격리하여 실행하는 계층. ClickHouse 기사의 '판단의 벽'을 안전하게 돌리려면 빼놓을 수 없다.
제1후보는 E2B (~12k)이다. 에이전트(Agent)가 작성한 수상한 코드를 Firecracker microVM 내에서 ~150ms 만에 기동하여 독립된 커널(Kernel)에서 격리 실행한다. ClickHouse 기사에서 언급된 '판단의 벽'을 안전하게 돌리기 위한 토대로, 호스트를 휘말리게 하지 않고 '일단 실행해 보고 결과로 판단한다'는 방식이 성립된다. 영구 환경과 Git 연동이 필요하다면 Daytona (~73k), 클라우드에 의존하지 않고 로컬에 두고 싶다면 microsandbox, 코딩/GUI/브라우저(browser)를 일괄적으로 다루는 기반이라면 OpenSandbox를 사용한다. 하위의 microVM 기반 자체는 Firecracker다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| Daytona | ~73k | 06 | ~90ms 기동의 영구 환경, Git 연동 |
| Firecracker (microVM 기반) | ~35k | 06 | E2B 등의 하위 기반 |
| E2B | ~12k | 06 | Firecracker microVM, ~150ms 기동 · 독립 커널 |
| OpenSandbox (Alibaba) | ~11k | 06 | coding/GUI/browser 에이전트 대응 기반 |
| microsandbox | ~6k | 06 | 클라우드 비의존적 로컬 · 프로그래머블 |
에이전트(Agent)의 출력이 '맞는지'를 기계로 측정하는 계층.
가장 유력한 후보는 DeepEval (~16k)이다. LLM / agent를 위해 50개 이상의 평가 지표 (Evaluation Metrics)를 보유하고 있으며, "이 출력이 올바른가"를 pytest 방식으로 작성하여 실행할 수 있다. 출력의 좋고 나쁨을 수동 리뷰에 의존하지 않고 CI(지속적 통합)에 포함할 수 있다는 점이 핵심이며, 이것이 L0–L7에서 말하는 L6(확정적 장벽)를 만드는 재료가 된다. CLI 퍼스트로 실행하려면 promptfoo, OTel(OpenTelemetry) 네이티브로 트레이스(Trace)와 일체화하려면 Phoenix, 평가와 트레이스를 모두 잡으려면 Opik, 취약점 스캔은 NVIDIA garak, MCP 서버/스킬의 레드팀(Red Teaming)은 Tencent AI-Infra-Guard를 사용한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| mlflow | ~26k | 06 | ML 라이프사이클 + LLM/agent 평가 기능 |
| promptfoo | ~22k | 06 | CLI 퍼스트 평가 + 레드팀 |
| Opik (comet-ml) | ~19k | 06 | 평가 + 트레이스 (관측과 겸임) |
| DeepEval | ~16k | 06 | 50+ 지표, 에이전트 특화 |
| Phoenix (Arize) | ~10k | 06 | OTel 네이티브 트레이스 + 평가 |
| garak (NVIDIA) | ~8k | 06 | LLM 취약점 스캐너 |
| AI-Infra-Guard (Tencent) | ~3.8k | 06 | MCP 서버/스킬 레드팀 |
실제 운영 환경에서 "agent가 실제로 무엇을 했는가"를 추적하는 계층.
가장 유력한 후보는 Langfuse (~28k)이다. OSS LLM 관측 (Observability)의 사실상 표준(De facto)이다. 트레이스, 평가, 프롬프트 버전 관리를 두루 갖추고 있어, "agent가 실제로 무엇을 생각했고, 어떤 도구를, 얼마의 비용을 들여 호출했는지"를 사후에 추적할 수 있다. 장애 발생 시 원인 규명과 비용 관리 모두를 여기서 제어할 수 있다. 게이트웨이와 최적화까지 통합하고 싶다면 TensorZero, OTel 계측(Instrumentation)을 통해 기존 관측 기반에 맞추고 싶다면 OpenLLMetry / Logfire, 평가와 일체로 사용하고 싶다면 Opik을 사용한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| Langfuse | ~28k | 06 | OSS LLM 관측의 표준. 트레이스/평가/프롬프트 버전 관리 |
| Opik | ~19k | 06 | 트레이스/평가/대시보드 |
| TensorZero | ~11k | 06 | 게이트웨이 + 관측 + 최적화 통합 |
| OpenLLMetry (traceloop) | ~7k | 05 | LLM 트레이스 OTel 계측 |
| Logfire (pydantic) | ~4.3k | 06 | OTel 네이티브 관측 |
L0–L7에서 말하는 L4(스킬) / L7(자기 기술)의 실체.
가장 유력한 후보는 공식적인 anthropics/skills (~146k)이다. 스킬을 "YAML 프론트매터(Frontmatter) + 절차서 디렉토리"라는 정해진 형태로 구현하는 규약으로, L0–L7에서 말하는 L4(위임)의 표준 형태 그 자체이다. SKILL.md에 "언제 사용하는가 / 절차 / 주의사항 / 검증"을 작성해 두면, agent가 필요할 때만 읽어 들인다. 타입을 강제하는 것이 품질 보증이 된다는 설계 사상은 L7과도 맞닿아 있다. 실무적인 입도(Granularity)를 원한다면 addyosmani/agent-skills (23개의 프로덕션급 스킬), "AI스러운" 느낌을 지우고 싶다면 taste-skill, 리포지토리를 AI용으로 패키징하고 싶다면 Repomix를 사용한다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| anthropics/skills (공식) | ~146k | 05 | 스킬 디렉토리 형식. L4의 표준 형태 |
| addyosmani/agent-skills | ~48k | 06 | 23개의 프로덕션급 엔지니어링 스킬 모음 |
| taste-skill | ~32k | 05 | "AI스러운" 느낌을 지우는 심미적 스킬 |
| Repomix | ~26k | 06 | 리포지토리 전체를 AI용 단일 파일로 패키징 |
코드를 작성하지 않고 agent 파이프라인을 구축하는 계층.
첫 번째 후보는 Langflow (~149k)입니다. 드래그 앤 드롭 (Drag & Drop)으로 agent 파이프라인을 구성하고, 이를 그대로 REST API로 출력할 수 있습니다. 비엔지니어와 함께 프로토타입을 제작하고, 가능성을 확인하면 코드로 구현하는 흐름이 매우 빠릅니다. 앱 기반으로서 플러그인 시장까지 포함하여 구축하고자 한다면 Dify (~144k), 범용 워크플로우 자동화에 AI를 추가하고자 한다면 n8n (~191k, 이 리스트 중 최대 규모), 더 간편한 LangChain 빌더를 원한다면 Flowise가 적합합니다.
| 프로젝트 | ★ | push | 한 줄 요약 |
|---|---|---|---|
| n8n | ~191k | 06 | 400개 이상의 연동을 지원하는 워크플로우 자동화 + AI 노드 |
| Langflow | ~149k | 06 | D&D 파이프라인, REST 출력 |
| Dify | ~144k | 06 | LLM 앱 기반, 플러그인 시장 |
| Flowise | ~53k | 06 | 더 간단한 노코드 (No-code) LangChain 빌더 |
| Sim | ~29k | 06 | 활발한 D&D 에이전트 편성 |
| Coze Studio (ByteDance) | ~21k | 04 | RAG/플러그인의 비주얼 기반 |
- 프로토콜 (Protocol): MCP (
modelcontextprotocol/servers~87k, Linux Foundation 소속), A2A (a2aproject/A2A~24k, Google에서 시작된 agent 간 통신), AG-UI (ag-ui-protocol/ag-ui~14k, agent ↔ user). - 학습 (Learning):
12-factor-agents(~23k, 단 최종 push가 2025-09로 사실상의 안정화된 매니페스트), Stanford의generative_agents(~21k, 2024-08에 업데이트 중단),microsoft/ai-agents-for-beginners
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기