오픈 멀티 에이전트
목표 한 줄을 주면 할 일을 작업 그래프(task DAG)로 자동 분해해 여러 에이전트에게 나눠 맡기는 오픈소스 실행 프레임워크다. 멀티 에이전트에서 "누가 무슨 일을 어떤 순서로 할지"를 손으로 엮지 않고, 목표 입력부터 결과 취합까지 한 번에 돌리고 싶을 때 쓴다.
| 단계 | 직접 짤 때 | 오픈 멀티 에이전트 |
|---|---|---|
| 할 일 나누기 | 사람이 설계 | 코디네이터가 자동으로 분해 |
| 순서 정하기 | 의존 관계를 코드로 연결 | task DAG로 자동 정리 |
| 실행 | 하나씩 직접 호출 | 독립 작업은 병렬, 이어진 작업은 순서대로 |
| 결과 모으기 | 직접 취합 | 런타임이 취합 |
task DAG: 작업 사이의 선후 관계를 화살표로 이은 그래프. 한 바퀴 돌아 제자리로 오는 순환은 없다.
목표만 넘기면 계획부터 실행까지
가장 간단한 사용법은 runTeam()에 "X를 만들어줘" 같은 목표를 넘기는 것이다. 코디네이터가 계획을 세우고 팀을 꾸려 실행까지 한 번에 처리하므로 그래프를 직접 그릴 필요가 없다.
진행 상황은 onProgress 이벤트와 onTrace 스팬으로 지켜본다. 어느 작업이 어디서 막혔는지 찾을 때 유용하다. 셸이나 CI에서 돌릴 때는 JSON 출력 위주의 oma CLI를 쓰면 된다.
모델과 도구를 작업마다 바꿔 낀다
특정 모델 회사에 묶이지 않아서 작업마다 Claude, GPT 같은 다른 모델을 끼울 수 있다. 외부 도구는 connectMCPTools()로 MCP 서버를 연결해 에이전트에게 통째로 열어 준다. 예를 들어 역할을 이렇게 나눌 수 있다.
| 에이전트 | 맡는 일 | 쓰는 도구 |
|---|---|---|
| 에이전트 A | GitHub 이슈 읽기 | MCP 서버 |
| 에이전트 B | 코드 고치기 | 파일시스템 샌드박스 |
잘못 쪼개면 엉뚱한 그래프가 된다
자동 분해가 편한 대신, 코디네이터가 목표를 잘못 쪼개면 엉뚱한 DAG가 만들어진다. 그래서 실제 서비스에 쓸 때는 아래 제어 장치를 함께 켜 두는 것이 권장된다.
| 장치 | 하는 일 |
|---|---|
| 컨텍스트 관리 | 슬라이딩 윈도우, 요약·압축 |
| 재시도·백오프 | 실패한 작업을 간격을 두고 다시 시도 |
| 루프 감지·출력 자르기 | 무한 반복과 너무 긴 도구 출력 막기 |
작업 흐름을 사람이 미리 정해 두고 싶다면 YAML로 흐름을 고정하는 결정론적 방식(예: Conductor)이 더 맞을 수 있다.
여러 단계로 나뉘는 일을 통째로 맡긴다
주로 목표는 분명한데 중간 단계가 여러 개로 갈리는 일에 쓴다. 흐름을 일일이 짜는 대신 목표만 넘기고, 단계마다 맞는 모델과 도구를 붙여 맡기는 방식이다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 코딩 에이전트 | 한 에이전트가 이슈를 읽고, 다른 에이전트가 샌드박스에서 코드를 고치도록 역할을 나눔 |
| 셸·CI 자동화 | oma CLI로 팀을 돌리고 JSON 결과를 다음 파이프라인 단계에 넘김 |
| 조사·정리 작업 | 서로 독립된 자료 수집은 병렬로 돌리고, 요약·정리는 그 결과를 받아 순서대로 처리 |
