open-multi-agent 추천: 목표를 작업 DAG로 나누는 TypeScript 멀티 에이전트 프레임워크
설치, MCP 연결, oma CLI, tracing까지 실무 도입 전에 확인할 것
open-multi-agent 추천: 무엇을 해결하는 도구인가
open-multi-agent는 자연어 목표를 작업 DAG로 분해하고 여러 에이전트 실행을 조율하는 TypeScript/Node.js 프레임워크입니다. open-multi-agent MCP multi agent orchestration을 찾는 독자라면 설치 명령보다 먼저 목표 분해 방식, MCP 권한, tracing, CLI 한계를 함께 봐야 합니다.
여러 AI 에이전트를 띄우는 일 자체는 이제 큰 장벽이 아닙니다. 실제로 막히는 부분은 누가 먼저 일하고, 어떤 작업이 끝나야 다음 단계로 넘어가며, 실패했을 때 어느 trace를 봐야 하는지입니다.
open-multi-agent는 그 문제를 TypeScript 쪽에서 풀려는 저장소입니다. 공식 README는 coordinator가 목표를 작업 DAG로 나누고, 독립적인 작업은 병렬화하며, 마지막에 결과를 합성하는 TypeScript 백엔드 프레임워크로 설명합니다. npm 패키지는 `@open-multi-agent/core`이고, Node.js 18 이상이 필요합니다.
제가 먼저 보는 부분은 기능 이름보다 운영 표면입니다. `runTeam`, `runTasks`, `runAgent`, `planOnly`, `oma CLI`, MCP 연결, `onTrace` 기반 관측성이 한 저장소 안에 같이 들어 있습니다. 그래서 “멋진 에이전트 프레임워크인가”보다 오늘 작은 내부 자동화에 붙여도 되는지, 어떤 순서로 확인해야 하는지, 언제 접는 편이 나은지에 맞췄습니다.
최근 흐름: 2026년 3월 공개부터 1.4.2까지
open-multi-agent는 2026년 3월 말 공개된 뒤 4월 v1.0.0, 4월 v1.2.0 MCP 통합, 5월 v1.4.x 패키지 전환과 v1.4.2 업데이트로 빠르게 보강됐습니다. GitHub stars와 push 시각은 변하는 값이므로 확인 시점 기준 신호로만 읽어야 합니다.
2026년 3월 31일 생성된 저장소가 4월과 5월 사이에 빠르게 릴리스 흐름을 만들었습니다. 브리프의 GitHub API 확인값에는 2026년 5월 24일 push 갱신과 6,233 stars가 기록돼 있고, keyword research의 이후 확인값에는 약 6.2천 stars, 2천 개 이상 forks, 2026년 5월 26일 push 기록이 잡혀 있습니다. 숫자는 계속 바뀌므로 “최근에도 움직이는 저장소”라는 신호로만 읽는 편이 맞습니다.
릴리스 흐름도 첫 공개 소개에 머물지 않습니다. v1.0.0에서는 structured output, task retry, observability, human approval hook 같은 생산 사용에 가까운 기능이 언급됐고, v1.2.0에서는 `connectMCPTools()` 기반 MCP 통합과 `oma` CLI가 추가됐습니다. v1.4.0에서는 새 프로젝트 설치 대상이 `@open-multi-agent/core`로 정리됐고, v1.4.2 release notes는 `npm install @open-multi-agent/core@1.4.2`를 명시합니다.
> 이 저장소를 볼 이유는 유행어 때문이 아니라, 목표 분해와 실행 관측을 같은 개발자 경험 안에 묶으려는 방향 때문입니다.
무엇이 다른가: 에이전트 수보다 작업 의존성이 중요하다
open-multi-agent의 차이는 여러 에이전트를 호출하는 데서 끝나지 않고, 목표를 DAG로 나눈 뒤 의존성이 없는 작업을 병렬 실행하고 결과를 합성하는 데 있습니다. 그래서 단순 챗봇보다 검토, 작성, 테스트, 요약처럼 단계가 나뉘는 업무에 더 잘 맞습니다.
일반적인 에이전트 래퍼는 “이 모델에게 이 도구를 주고 실행한다”에 가까운 경우가 많습니다. open-multi-agent는 그 위에 coordinator를 둡니다. 목표를 받으면 작업 단위로 쪼개고, 작업 사이의 `dependsOn` 관계를 보고, 병렬 처리 가능한 일을 먼저 보냅니다.
실행 모드 선택은 아래처럼 갈립니다.
| 모드 | 맞는 상황 | 확인할 점 |
|---|---|---|
| `runAgent()` | 단일 에이전트 기준선 확인 | 모델 키, 도구 호출, 응답 품질을 먼저 분리해서 본다 |
| `runTeam()` | 목표 기반 자동 분해 | coordinator가 만든 DAG가 업무 의도와 맞는지 `planOnly`로 본다 |
| `runTasks()` | 고정된 의존성 그래프 | 감사 가능한 task title과 `dependsOn` 배열을 직접 관리한다 |
LangGraph JS처럼 명시적 그래프와 durable checkpointing을 먼저 설계하는 접근과는 출발점이 다릅니다. open-multi-agent는 목표를 먼저 주고 런타임에서 분해하는 쪽에 가깝습니다. 제가 보기에는 이 차이 때문에 “처음부터 그래프를 다 그릴 수 없는 내부 자동화 실험”에는 가볍게 시작하기 좋습니다. 반대로 상태기계 수준의 체크포인트가 핵심인 시스템이라면 이 저장소만 보고 결정하면 곤란합니다.
도입 시뮬레이션: 설치부터 첫 테스트까지
가장 안전한 첫 테스트는 Node.js 18 이상에서 `@open-multi-agent/core`를 설치하고 `runAgent()`로 단일 기준선을 본 뒤, `runTeam(..., { planOnly: true })`로 DAG를 확인하고, 마지막에 `runTeam()` 또는 `runTasks()`를 실행하는 순서입니다. MCP나 파일 쓰기 도구는 이 기준선이 통과한 뒤 붙이는 편이 좋습니다.
새 프로젝트에서는 `npm install @open-multi-agent/core`를 쓰면 됩니다. 릴리스 고정을 원할 때는 v1.4.2 release notes의 `npm install @open-multi-agent/core@1.4.2`처럼 pin을 거는 쪽이 낫습니다. 공식 예제 clone 방식은 `git clone https://github.com/open-multi-agent/open-multi-agent`, `npm install`, 모델 API 키 설정, `npx tsx examples/basics/team-collaboration.ts` 실행 흐름을 제시합니다.
처음부터 복잡한 MCP 서버를 붙이면 실패 원인이 흐려집니다. 저는 아래 순서를 먼저 권합니다.
1. `runAgent()`로 provider, API key, 기본 응답 품질을 확인합니다.
2. `runTeam()`에 `planOnly: true`를 넣어 coordinator가 만든 작업 DAG를 미리 봅니다.
3. 같은 goal을 실제 `runTeam()`으로 실행하고 `result.success`, `result.totalTokenUsage`, task별 상태를 확인합니다.
4. 반복 업무라면 `runTasks()`로 title과 `dependsOn`을 명시해 재현 가능한 파이프라인으로 바꿉니다.
5. 그 다음에 `connectMCPTools()`나 `toolPreset`을 붙이고 권한 범위를 좁힙니다.
한국 사용자 입장에서는 이 순서가 꽤 중요합니다. 사내 GitHub, 문서 저장소, 이슈 트래커를 붙이는 순간 도구 권한과 토큰 비용이 같이 움직입니다. 작은 goal 하나로 plan과 trace를 남기고 나서야 실무 도입 여부를 말할 수 있습니다.
MCP와 oma CLI는 어디까지 쓸 수 있나
MCP는 GitHub 같은 외부 도구를 에이전트에게 연결하는 통로이고, `oma` CLI는 shell이나 CI에서 JSON 결과와 exit code를 받는 경로입니다. 다만 progress stream, approval callback, custom memory 같은 세밀한 운영은 TypeScript API가 더 적합합니다.
open-multi-agent MCP multi agent orchestration에서 MCP는 이름보다 권한 경계가 더 중요합니다. 공식 tool configuration 문서는 `connectMCPTools()`를 통한 stdio MCP 서버 연결을 설명하고, `@modelcontextprotocol/sdk`를 optional peer dependency로 둡니다. GitHub MCP 예제는 `GEMINI_API_KEY`, `GITHUB_TOKEN`, `@modelcontextprotocol/server-github`, `namePrefix: github` 같은 구성을 사용합니다.
여기서 볼 부분은 MCP 입력 검증과 권한 면이 서버마다 달라진다는 점입니다. GitHub 토큰을 붙이는 순간 이슈, PR, repository 읽기/쓰기 범위가 실제 권한으로 이어질 수 있습니다. `readonly`, `readwrite`, `full` preset을 바로 넓게 주기보다 allowlist와 denylist로 좁히고, `maxToolOutputChars`와 tool result compression으로 출력 폭주를 막는 편이 낫습니다.
`oma CLI`는 자동화용으로 쓸모가 분명합니다. 문서상 `oma run`, `oma task`, `oma provider` 같은 명령과 JSON-first 출력, 안정적인 exit code가 제공됩니다. 다만 CLI 문서는 interactive REPL, session persistence, JSON-configured approval callback, progress stream 같은 기능이 없다고 밝힙니다. CI에서 간단히 돌릴 때는 CLI, 운영 로깅과 승인 흐름이 필요할 때는 TypeScript API를 우선 보는 구분이 현실적입니다.
한국 개발자에게 먼저 맞는 사용처
한국 독자에게는 코드 리뷰 보조, 릴리스 노트 요약, GitHub 이슈 triage, 문서 검토, 경쟁사 모니터링처럼 작업 단계를 나누기 쉬운 반복 업무부터 실험하는 편이 현실적입니다. 단순 챗봇보다 검토와 합성이 함께 필요한 내부 자동화에서 open-multi-agent의 장점이 더 잘 드러납니다.
고객 응대 전체 자동화나 사내 핵심 배포 파이프라인부터 넣는 것은 성급합니다. 첫 실험은 작은 내부 업무가 맞습니다. 예를 들어 GitHub issue를 읽고, 관련 파일을 찾고, 수정 후보를 요약하고, 리뷰어에게 확인 질문을 만드는 흐름은 DAG로 나누기 쉽습니다.
문서 검토도 맞습니다. 초안 요약, 누락된 근거 찾기, 표현 리스크 점검, 최종 요약을 서로 다른 agent 역할로 나누면 사람이 검토할 중간 산출물이 남습니다. observability 문서의 `onProgress`, `onTrace`, `renderTeamRunDashboard(result)`는 이런 중간 산출물을 추적하고 사후 검토하는 데 도움이 됩니다.
open-multi-agent MCP multi agent orchestration을 한국 업무 환경에 붙인다면 “한 번에 완전 자동화”보다 “작업 DAG가 사람에게 설명 가능한지”를 먼저 봐야 합니다. 팀원이 plan을 보고 납득하지 못하면, 실행 결과가 좋아도 운영 도구로 남기 어렵습니다.
도입 전 확인할 리스크
open-multi-agent를 모든 MCP 서버와 모든 모델이 자동으로 잘 맞는 도구처럼 보면 안 됩니다. 실제 도입 전에는 Node.js 18, provider tool calling, MCP 권한, token budget, output cap, trace 저장, rollback pinning을 확인해야 합니다.
실제로 확인할 부분은 꽤 구체적입니다. 먼저 runtime입니다. Node.js 18 이상을 쓸 수 없는 환경이면 시작부터 맞지 않습니다. Python-first 팀이 이미 CrewAI 같은 생태계에 맞춰 자동화를 쌓고 있다면 TypeScript 전환 비용부터 계산해야 합니다.
두 번째는 모델과 provider입니다. provider 문서는 Anthropic, Gemini, OpenAI, Azure OpenAI, Copilot, Grok, DeepSeek, MiniMax, Qiniu, Bedrock, Ollama/vLLM/LM Studio 같은 OpenAI-compatible endpoint 경로를 폭넓게 다룹니다. 하지만 이 말이 모든 모델의 tool calling이 같은 품질로 작동한다는 뜻은 아닙니다. 로컬 모델은 특히 tool-capable 모델인지, timeout과 sampling 설정이 맞는지 따로 봐야 합니다.
세 번째는 운영 제어입니다. `maxTurns`, `maxTokenBudget`, `maxToolOutputChars`, `compressToolResults`, allowlist/denylist, trace span 저장이 없는 상태에서 파일 쓰기나 bash 도구를 넓게 열면 디버깅과 보안 검토가 어려워집니다. open-multi-agent MCP multi agent orchestration은 실험용으로 흥미롭지만, 운영 도구로 남기려면 실패 로그와 되돌릴 npm version pin이 먼저 있어야 합니다.
추천 판단: 누구에게 맞고 누구에게 과한가
open-multi-agent는 TypeScript/Node.js 팀이 목표 기반 멀티 에이전트 자동화를 작게 실험하고, DAG와 tracing으로 결과를 검토하려는 상황에 맞습니다. 반대로 단일 LLM 호출, Python-first 자동화, durable checkpointing 중심 운영에는 다른 도구가 더 단순하거나 안정적일 수 있습니다.
제가 보기에는 open-multi-agent의 현재 포지션은 “완성형 엔터프라이즈 오케스트레이터”가 아니라 “TypeScript 팀이 goal-first multi-agent orchestration을 코드와 CLI 양쪽에서 실험하는 프레임워크”에 가깝습니다. 그래서 추천 대상도 꽤 좁혀집니다.
AI 코드 리뷰 보조, research monitoring, 문서 검토, GitHub triage, 릴리스 노트 요약처럼 여러 하위 작업을 만들 수 있고 사람이 plan을 검토할 수 있는 workflow라면 시도할 만합니다. 특히 MCP 서버를 이미 보고 있거나, `onTrace` span을 내부 로깅에 넣고 싶은 팀이라면 open-multi-agent MCP multi agent orchestration이 비교 후보가 됩니다.
다만 단순 채팅 UI, provider abstraction, 한 번의 요약 호출이 목적이라면 과합니다. 이럴 때는 Vercel AI SDK나 직접 provider SDK가 더 간단합니다. 고정 그래프, durable checkpointing, 장기 상태 복구가 핵심이라면 LangGraph JS 같은 graph-first 도구와 비교한 뒤 결정하는 편이 맞습니다.
자주 묻는 질문
Q. open-multi-agent는 일반 에이전트 프레임워크와 무엇이 다른가?
A. 단일 agent 실행을 감싸는 수준이 아니라 목표를 작업 DAG로 분해하고, 의존성이 없는 작업을 병렬 실행한 뒤 결과를 합성하는 쪽에 초점이 있습니다. 공식 README는 `runAgent()`, `runTeam()`, `runTasks()`를 나눠 설명합니다.
Q. open-multi-agent 설치와 첫 테스트는 어떻게 하면 되나?
A. Node.js 18 이상에서 `npm install @open-multi-agent/core`를 먼저 실행합니다. 그 다음 `runAgent()` 기준선을 확인하고, `runTeam(..., { planOnly: true })`로 DAG를 미리 본 뒤 실제 `runTeam()`이나 `runTasks()`를 실행하는 순서가 안전합니다.
Q. MCP 기반 멀티 에이전트 오케스트레이션은 어디에 쓸 수 있나?
A. GitHub issue triage, 문서 검토, 릴리스 노트 요약, 코드 리뷰 보조처럼 외부 도구와 여러 하위 작업이 함께 필요한 업무에 맞습니다. MCP는 `connectMCPTools()`로 stdio 서버를 붙이는 방식이 문서화돼 있지만, 서버별 권한과 token scope를 별도로 점검해야 합니다.
Q. `runTeam`, `runTasks`, `runAgent`는 각각 언제 써야 하나?
A. `runAgent()`는 단일 모델과 도구 기준선을 볼 때, `runTeam()`은 목표를 주고 coordinator가 작업을 나누게 할 때, `runTasks()`는 title과 `dependsOn`을 직접 정한 고정 DAG를 실행할 때 적합합니다.
Q. `oma CLI`만으로 실무 자동화를 운영할 수 있나?
A. shell이나 CI에서 JSON 결과와 exit code가 필요하면 `oma CLI`가 유용합니다. 하지만 progress stream, approval callback, session persistence, custom memory 같은 세밀한 운영은 CLI 문서상 제한이 있으므로 TypeScript API 쪽을 봐야 합니다.
Q. TypeScript 팀이 open-multi-agent를 도입하지 말아야 할 상황은 무엇인가?
A. 단일 LLM 호출이면 과하고, Python-first 팀이면 생태계 전환 비용이 큽니다. durable checkpointing과 고정 상태기계가 핵심인 운영 시스템이라면 LangGraph JS 같은 graph-first 대안을 먼저 비교하는 편이 맞습니다.
함께 읽으면 좋은 글
- FastMCP GitHub 추천: Python으로 MCP 서버와 클라이언트 빠르게 만들기 — GITHUB 추천
- promptfoo 추천: LLM 앱과 RAG를 배포 전 자동 평가하는 오픈소스 도구 — GITHUB 추천
- Understand Anything 추천: 코드베이스를 AI가 읽기 쉬운 지식 그래프로 바꾸는 방법 — GITHUB 추천
참조 링크
- open-multi-agent/open-multi-agent — 공식 owner/repo, README 포지셔닝, license, examples, docs 진입점 확인
- GitHub API repository metadata for open-multi-agent/open-multi-agent — 생성일, stars/forks, pushed_at 같은 변동 가능한 저장소 활동 지표 확인
- v1.4.2 release notes — 최신 확인 릴리스, pin 설치 명령, 업데이트 내용 확인
- v1.2.0 release notes — MCP 통합, oma CLI, context management 추가 흐름 확인
- @open-multi-agent/core — 공식 npm 패키지명, 최신 dist-tag, Node.js 요구사항 확인
- package.json — entrypoint, CLI binary, runtime dependencies, optional peer dependency 확인
- Command-line interface (oma) — oma CLI 명령, JSON output, exit code, dashboard flag, CLI limitation 확인
- Tool Configuration — tool preset, allowlist, denylist, output cap, MCP stdio integration 확인
- Observability — onProgress, onTrace, dashboard rendering, trace persistence 확인
- Providers — provider shortcut, OpenAI-compatible endpoint, local model 주의점 확인
- Examples index — team collaboration, task pipeline, integrations 예제 경로 확인
- MCP GitHub integration example — GitHub MCP server, GITHUB_TOKEN, GEMINI_API_KEY, disconnect cleanup 예제 확인