Agentic Orchestrator

문샷(moonshot)을 한 번에 달성하고 — 그 다음에는 10번을 병렬로 실행하세요.

Agentic Orchestrator는 모든 엔지니어를 승수 효과(force multiplier)로 만들어주는 AI 개발 워크플로우 오케스트레이터 (orchestrator)입니다. 기능을 설명하고 상위 수준의 결정을 내리면, AI가 나머지 작업인 리서치 (research), 계획 (planning), 구현 (implementation), 코드 리뷰 (code review), 풀 리퀘스트 (pull request)를 단일 터미널에서 모두 병렬로 처리합니다.

로컬 CLI는 agentico입니다

왜 Agentic Orchestrator인가?

에이전트 기반 코딩 (agentic coding)에서 어려운 점은 모델에게 파일을 수정하라고 요청하는 것이 아닙니다. 진짜 어려운 점은 문맥 (context)을 잃거나, 설계 작업을 건너뛰거나, 잘못된 계획이 거대한 디프 (diff)를 생성하게 만들지 않으면서, 모호하고 상위 수준의 기능 요청으로부터 검토 가능한 PR (pull request)까지 도달하는 것입니다. 관리되지 않은 상태로 방치하면 팀은 다음과 같은 'AI 슬롭 (AI slop)'을 얻게 됩니다: 신뢰할 수 있는 코드를 만드는 데 필요한 문맥, 테스트, 리뷰 프로세스보다 더 빠르게 생성된, 그럴싸해 보이기만 하는 코드 말입니다. Agentic Orchestrator는 바로 이 문제를 중심으로 구축되었습니다. 이는 하나의 기능 프롬프트 (prompt)를 문맥을 수집하고, 질문을 던지고, 접근 방식을 설계하며, 작업을 분해하고, 구현하고, 검증하고, 리뷰하고, 게시하는 내구성 있는 엔지니어링 워크플로우 (engineering workflow)로 전환합니다.

이것이 진정한 "원샷 (oneshot)" 가치입니다. 엔지니어는 대규모 기능을 한 번만 설명하면 되며, 모든 프롬프트, 터미널 세션, 워크트리 (worktree), 테스트 실행, 리뷰 단계, PR 단계를 수동으로 인도하는 대신 판단이 중요한 체크포인트 (checkpoints)를 감독하기만 하면 됩니다.

컨텍스트는 희망하는 것이 아니라 구축되는 것입니다 (Context is built, not hoped for) — Large 및 Moonshot 기능은 저장소(repo)별 지식 베이스를 구축하는 것부터 시작하여, 계획(planning)을 세우기 전에 조사(inquiry), 연구(research), 설계(design) 단계를 수행합니다. 구현 에이전트(implementation agent)는 단일하고 과부하된 채팅 기록에 의존하는 대신 구조화된 산출물(artifacts)을 읽습니다.
복잡성은 단계별로 처리됩니다 (Complexity is phased) — 계획(Planning) 단계에서 로드맵을 생성한 다음, 각 로드맵 단계는 고유의 상세 단계 계획(phase plan)을 갖게 됩니다. 트레이서 불렛(tracer-bullet) 단계가 경로를 설정하면, 이후의 TDD 채우기 단계가 스텁(stubs)을 제거하고 커버리지를 확장합니다.
차이(diff) 비용이 커지기 전에 품질 게이트(Quality gates)가 작동합니다 — 계획 검증기(Plan validators)가 아키텍처, 범위, 구조를 검토하며, 위험도가 높은 작업의 경우 보안, 성능 및 테스트를 검토합니다. 구현(Implementation) 및 최종 검토(Final Review) 루프는 기능이 배포 가능해지기 전에 명시적인 검증 증거(verification evidence)를 사용합니다.
인간의 주의력은 의사결정을 위해 보존됩니다 (Human attention is reserved for decisions) — 선택적 게이트(Optional gates)는 조사 검토, 연구 검토, 설계 검토, 로드맵 검토, 단계 계획 검토, 사용자 입력, 그리고 배포 결정 단계에서 일시 중지됩니다. 사용자는 방향을 승인하거나, 반복(iteration)을 요청하거나, 타겟팅된 질문에 답변합니다. 오케스트레이터(orchestrator)가 워크플로 상태를 유지합니다.
병렬성은 전제가 아니라 승수입니다 (Parallelism is the multiplier, not the premise) — 모든 기능에 격리된 워크트리(worktrees), 브랜치(branches), 세션(sessions) 및 산출물(artifacts)이 할당되기 때문에, 상태를 혼합하거나 메인 체크아웃(main checkout)을 차단하지 않고도 여러 복잡한 워크플로를 동시에 실행할 수 있습니다.
프로바이더 오케스트레이션(Provider orchestration)은 명시적입니다 — 전체 워크플로를 실행하는 데는 하나의 프로바이더(provider)만으로도 충분하며, 작업을 분할하려면 더 추가할 수 있습니다. Claude, Codex, OpenCode는 동등한 지위를 갖습니다. 각 단계의 기본값은 감지된 모든 프로바이더 중에서 해당 역할에 가장 적합한 모델이며, 모델은 단계별로 재정의하거나 런타임(runtime)에 교체할 수 있습니다. --providers를 사용하여 오케스트레이터가 실제로 설치된 CLI로만 제한하도록 설정할 수 있습니다.

이 설계는 Anthropic의 Building Effective Agents 기사에서 설명된 패턴인 프롬프트 체이닝 (prompt chaining), 병렬화 (parallelization), 오케스트레이터-워커 (orchestrator-workers), 그리고 평가자-최적화 루프 (evaluator-optimizer loops)를 따릅니다. 또한 Claude Code의 explore → plan → code 워크플로우와 에이전트 오케스트레이션 및 가드레일 (orchestration and guardrails)에 관한 OpenAI의 가이드를 코드화했습니다.

빠른 시작 (Quick Start)

Homebrew가 있다면 사용하고, 그렇지 않다면 미리 빌드된 바이너리 (prebuilt binary)를 가져오세요. agentico 자체를 개발하는 경우가 아니라면 소스에서 빌드하지 마세요.

Homebrew (권장 — macOS/Linux):

brew install doordash-oss/agentic-orchestrator/agentico

Prebuilt binary — Homebrew나 Go가 필요 없음 (macOS/Linux, amd64/arm64):

OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/')
TAG=$(curl -fsSLI -o /dev/null -w '%{url_effective}' https://github.com/doordash-oss/agentic-orchestrator/releases/latest | sed 's@.*/@@')
...

From source — agentico 기여를 위한 경우 (Go 1.25+):

go install github.com/doordash-oss/agentic-orchestrator/cmd/agentico@latest
# 또는: git clone https://github.com/doordash-oss/agentic-orchestrator.git && cd agentic-orchestrator && make install

그 다음 agentico를 실행하세요. agentico update를 통해 언제든 업데이트할 수 있으며, 설치 방식에 맞는 적절한 방법을 사용합니다.

처음 실행할 때, Agentic Orchestrator는 워크스페이스 디렉토리를 선택할 수 있도록 웰컴 플로우 (welcome flow)를 안내합니다. 그 이후에는 대시보드 (dashboard)로 진입합니다.

기억해야 할 세 가지 키: n (새 기능), ? (도움말), a (활성 작업 모니터링; 프롬프트가 나타나면 답변, 승인 또는 검토). 그 외의 모든 기능은 도움말 오버레이 (help overlay)를 통해 확인할 수 있습니다.

필수 요구 사항 (Prerequisites)

필수

도구 (Tool)	용도 (Purpose)	설치 (Install)
`git`	Worktree, 브랜치 (branch), 커밋 (commit), 리베이스 (rebase) 작업	대부분의 시스템에 사전 설치됨
`gh` CLI	Publish 단계에서의 Push 시점 PR 생성 및 저장소 간 PR 본문 업데이트	GitHub CLI 문서 참조 후 `gh auth login` 실행

Provider CLI — 최소 하나 이상 설치

Agentic Orchestrator를 사용하려면 최소 하나의 AI Provider CLI가 필요합니다.

도구 (Tool)	역할 (Role)	설치 (Install)
Claude Code CLI >= 2.1.81 (`claude`)	KB (지식 베이스), 문의 (inquiry), 조사 (research), 설계 (design), 계획 (planning), 구현 (implementation) 및 채팅 (chat)을 위한 백엔드 (Backend)	Claude Code 설정 또는 `npm install -g @anthropic-ai/claude-code@latest`
...

OpenCode는 설정된 백엔드 프로바이더 (Anthropic, OpenAI, Google, 로컬 Ollama 모델 등)를 하나의 CLI를 통해 라우팅 (route)합니다. opencode auth login으로 인증하고, opencode models로 준비 상태를 확인하세요. Agentico는 관리되는 세션별 설정 (per-session config)을 기반으로 모든 OpenCode 세션을 실행하며, 사용자의 전역 (global) OpenCode 설정을 절대 수정하지 않습니다. --providers opencode를 사용하여 명시적으로 참여하거나, CLI가 설치 및 인증되었을 때 자동으로 참여하도록 할 수 있습니다.

선택 사항 (Optional)

도구 (Tool)	용도 (Purpose)	설치 (Install)
Go 1.25+	`agentico`를 소스에서 빌드할 때만 필요 — 사전 빌드된 릴리스 바이너리 사용 시에는 필요하지 않음	go.dev
Node.js 18+ 및 npm	npm을 통해 Claude Code 또는 Codex를 설치할 때만 필요	nodejs.org

provider CLI(명령줄 인터페이스)를 설치한 후, agentico를 실행하기 전에 각 CLI가 인증되었는지 확인하십시오 — claude auth status, codex login status, 그리고/또는 opencode models (백엔드 provider가 구성된 후에만 모델 목록을 표시함) — 더불어 gh auth status를 확인해야 합니다. CLI가 누락되었거나, 너무 오래되었거나, 아직 인증되지 않은 provider는 시작 시 한 줄의 알림과 함께 필터링되며, orchestrator는 준비된 provider들을 대상으로 계속 실행됩니다.

작동 방식

기능 라이프사이클 (Feature Lifecycle)

라이프사이클은 프로필(profile)에 따라 달라지며 체크포인트(checkpoint) 기반으로 구동됩니다. Medium 프로필은 계획(planning) 단계부터 시작합니다. Large 및 Moonshot 프로필은 먼저 컨텍스트(context)를 구축하고, 의도(intent)를 명확히 하며, 설계 옵션을 탐색합니다. 그 후 모든 프로필은 로드맵 루프(roadmap loop)에 진입합니다: 로드맵을 생성하고, 한 번에 하나의 로드맵 단계(phase)를 계획하며, 이를 구현하고, 단계 앵커(phase anchors)를 커밋하며, 마지막 단계가 최종 검토(Final Review)에 도달할 때까지 계속합니다.

지식 베이스 구축 (Knowledge Base Build) — 아키텍처(architecture), 컨벤션(conventions), API 표면(API surface), 의존성(dependencies) 및 검증(verification)을 다루는 저장소(repo)별 지식 베이스를 구축하거나 갱신합니다. 최신 지식 베이스(KB)가 있는 경우 이를 재사용하며 해당 단계는 건너뜁니다.

질의, 조사, 설계 (Inquire, Research, Design) — 상위 수준의 요청을 명시적인 답변, 조사 결과 및 설계 방향으로 전환합니다. Q&A 산출물(artifacts)은 영구 저장되어 다음 단계로 전달되므로, 이후 단계들이 메모리(memory)에만 의존하지 않도록 합니다.

로드맵 및 단계 계획 (Roadmap and Phase Planning) — 최상위 로드맵을 생성한 다음, 각 로드맵 단계에 대한 세부 계획을 수립합니다. Large 및 Moonshot은 계획 검증기(plan validators)를 실행하며, Medium은 오버헤드를 줄이기 위해 계획 비평가(plan critics) 단계를 건너뜁니다.

구현 (Implementation) — 단계 범위 내의 저장소 세트(repo set) 전체에 대해 통합된 단계 구현 루프를 실행합니다. Medium 및 Large는 최종 검토(Final Review)에 의존하며, Moonshot은 구현 중에도 반복(iteration)별 검토를 유지합니다.

최종 검토 (Final Review) — 마지막 로드맵 단계(roadmap phase) 이후, 아직 게시되지 않은 모든 관련 리포지토리(repo)를 대상으로 단 한 번 실행됩니다. 이 단계는 자체적인 검토/수정 루프(review/fix loop)를 포함합니다. 최종 검토를 통과하면 해당 기능은 CodeReady 상태로 이동하며, 루프를 완료하지 못하거나 단계 계약(phase contract)을 위반하면 기능 구현이 실패합니다.

게시 (Publishing) — 자동 게시(auto-publish)가 활enabled되어 있으면, Agentic Orchestrator가 커밋(commit), 리베이스(rebase), 푸시(push), PR 생성 및 리포지토리 간 PR 링크 삽입를 자동으로 수행합니다. 수동 게시(manual publish)가 활성화되어 있으면, TUI가 CodeReady 단계에서 일시 중지되어 사용자가 먼저 차이점(diff)과 PR 설명을 검토할 수 있도록 합니다.

파이프라인 프로필 (Pipeline Profiles)

기능을 생성할 때, 파이프라인 깊이(pipeline depth)를 선택하십시오:

프로필 (Profile)	단계 (Phases)	적합한 용도
Medium	로드맵 계획 (Roadmap plan) → 단계별 계획/구현 루프 (per-phase plan/implement loop) → 최종 검토 (Final Review) → 게시 (Publish)	접근 방식을 이미 알고 있는 작고 명확한 변경 사항
...

워크트리 격리 (Worktree Isolation)

각 기능은 ~/.agentic-orchestrator/worktrees/ 하위의 개별 git 워크트리(worktree)에서 실행됩니다 (기존 설치 버전은 사용자가 옵트인(opt in)할 때까지 ~/.agentic-workflow/worktrees/를 계속 사용합니다). 이는 다음을 의미합니다:

여러 기능이 동일한 리포지토리에서 동시에 작업할 수 있음
동시 실행되는 기능 간의 브랜치 충돌(branch conflicts)이 없음
사용자의 메인 작업 복사본(main working copy)이 그대로 유지됨
워크트리는 완료 후 c 명령어로 정리됨

다중 리포지토리 (Multiple Repositories)

모든 기능은 동일한 라이프사이클(lifecycle)과 상태 머신(state machine)을 가진 하나 이상의 리포지토리를 대상으로 합니다. 기능이 하나 이상의 리포지토리에 걸쳐 있는 경우, Agentic Orchestrator는 다음과 같이 동작합니다:

각 대상 리포지토리에 워크트리 생성
리포지토리 간 의존성 순서(dependency ordering)를 고려한 실행 계획 수립
리포지토리별 구현 실행 (의존성에 따라 순차적 또는 병렬로 수행)
리포지토리 간 PR 자동 교차 참조 (cross-references)

기능이 단일 리포지토리를 대상으로 하는 경우, 리포지토리별 진행 상황(Repo Progress) 패널, 사이클 선택 모달(cycle-selector modal), 그리고 PR 교차 참조 테이블은 축소(collapse)되지만, 나머지 라이프사이클은 동일합니다.

지식 베이스 (Knowledge Base)

특정 기능에 뛰어들기 전에, Agentic Orchestrator는 저장소(per-repo)별 지식 베이스(Knowledge Base)를 구축할 수 있습니다. 이는 아키텍처(architecture), 컨벤션(conventions), API 표면(API surface), 의존성(dependencies), 그리고 검증 방법(verification methods)을 다루는 구조화된 문서 그래프(document graph)입니다. KB는 캐시(cached)되며 (HEAD가 변경될 때만) 점진적으로 업데이트되므로, 동일한 저장소 내의 후속 기능들은 더 빠르게 시작할 수 있습니다.

계획 검증 게이트 (Plan Validation Gate)

구현이 시작되기 전에 전문화된 AI 비평가(critics)들이 계획을 검토합니다:

비평가 (Critic)	중점 사항 (Focus)	활성화 시점 (When Active)
Architecture	로드맵 수준의 패턴 일관성, 모듈 경계, 의존성 방향	Large/Moonshot, 모든 리스크 레벨
...

비평가들은 병렬로 실행되며 독립적인 판결을 내립니다. 만약 어떤 비평가라도 변경을 요청하면, 계획은 자동으로 수정되고 재검증됩니다. Medium 모드는 계획 비평가(plan critics) 단계를 건너뛰지만, 게시(publish) 전에는 여전히 최종 검토(Final Review)를 수행합니다.

사용법 (Usage)

TUI 대시보드 (TUI Dashboard)

agentico로 실행합니다. 대시보드는 모든 기능을 상태별로 정리하여 보여줍니다:

In Progress — 활발히 작업 중 (조사 중, 계획 중, 구현 중)
Published — PR 생성됨, 머지(merge) 대기 중
Completed — 완료로 표시됨

사용자의 주의가 필요한 기능(권한 대기, 도움 요청 등)은 경고 표시기가 나타납니다.

기능 생성하기 (Creating a Feature)

대시보드에서 n을 눌러 위저드(wizard)를 엽니다:

What — 기능의 이름을 지정하고 설명합니다. 이미지 붙여넣기(Ctrl+V) 및 파일 첨부(@)를 지원합니다.
Where — 대상 저장소(repo)를 선택합니다. 새 디렉토리를 탐색하거나 즉석에서 저장소를 생성할 수 있습니다.
Pipeline — Medium, Large 또는 Moonshot을 선택하고 사용 가능한 게이트(gate) 옵션을 확인합니다.
Review — 리스크 레벨, 단계별 모델, 체크포인트(문의 검토, 조사 검토, 설계 검토, 로드맵 검토, 단계 계획 검토, 수동 게시), 종료 기준(exit criteria)을 조정합니다. 제출하여 시작합니다.

에이전트와 상호작용하기 (Interacting with Agents)

Watch (a) — 진행 중인 작업을 실시간으로 엽니다. 에이전트가 입력(input)을 필요로 할 때, 동일한 키가 Answer(답변), Approve(승인) 또는 Review(검토)로 바뀝니다.

Overview (o) — 대시보드 우측 패널을 Live Preview (라이브 미리보기)에서 상세 Overview (개요)로 전환합니다. Overview 상태에서 l을 누르면 Live Preview로 돌아갑니다. Overview 상태가 아닐 때 l을 누르면 여전히 로그(logs)를 엽니다.

Insights

Show HN: Agentic Orchestrator, 장기 실행 코딩 에이전트를 위한 TUI

요약

핵심 포인트