Optio: 완전한 자동화된 AI 코딩 에이전트 오케스트레이터

AI가 코드를 써주는 시대는 이미 왔습니다.
그런데 팀에 바로 도움이 되는 건 “코드 생성”이 아니라, 실패한 CI를 다시 고치고, 리뷰 코멘트를 반영하고, 결국 PR을 머지하는 자동화입니다.

optio는 바로 그 지점을 겨냥한 프로젝트입니다. 단순히 에이전트를 한 번 실행하는 도구가 아닙니다. AI 코딩 작업을 실제 소프트웨어 전달 파이프라인으로 바꾸는 시스템에 가깝습니다. 작업을 넣으면 저장소 전용 실행 환경을 만들고, Claude Code나 OpenAI Codex를 돌리고, PR을 열고, CI와 리뷰 상태를 감시하다가, 실패하면 다시 에이전트를 깨워 수정하고, 통과하면 자동으로 머지까지 진행합니다. 2026년 3월 24일 기준 0.1.0으로 공개된 초기 버전이며, 저장소는 TypeScript 기반 모노레포 구조로 정리되어 있습니다. (GitHub)

 

GitHub - jonwiggins/optio: Workflow orchestration for AI coding agents, from task to merged PR.

 

---

프로젝트 소개

Optio는 Jon Wiggins가 공개한 오픈소스 프로젝트로, 저장소 설명 자체가 AI Agent Workflow Orchestration입니다. 핵심 메시지는 단순합니다.
**“AI 에이전트가 코드를 작성한다”**에서 멈추지 않고, **“그 작업이 병합 가능한 Pull Request가 되도록 끝까지 밀어붙인다”**는 것입니다. 수동 작업, GitHub Issue, Linear 티켓에서 태스크를 받아 Kubernetes 환경에 격리 실행 공간을 만들고, 에이전트를 실행한 뒤, PR 수명주기를 계속 추적합니다. 웹 UI도 포함되어 있어서 실행 중인 작업, 로그, 비용, 클러스터 상태를 볼 수 있습니다. (GitHub)

기술 스택도 이 목적에 맞게 상당히 실용적으로 구성되어 있습니다. API는 Fastify 5, 데이터 계층은 Drizzle ORM과 PostgreSQL, 큐는 Redis + BullMQ, 프론트엔드는 Next.js 15와 Tailwind CSS 4, 런타임은 Kubernetes, 배포는 Helm chart를 사용합니다. 에이전트 어댑터는 Claude Code와 OpenAI Codex를 지원하고, 티켓 공급자는 GitHub Issues와 Linear로 분리되어 있습니다. (GitHub)

---

왜 이런 프로젝트가 등장했을까

요즘 AI 개발 도구는 많습니다. 하지만 대부분은 여기서 멈춥니다.

1. 프롬프트를 넣는다.
2. AI가 코드를 만든다.
3. 사람이 PR을 열거나, CI를 확인하거나, 리뷰 피드백을 반영한다.

즉, “코드 생성”은 자동화됐는데 “개발 워크플로”는 여전히 사람 손에 남아 있는 상태입니다. Optio는 이 간극을 메우려는 시도입니다. README에서도 차별점으로 강조하는 부분이 바로 feedback loop입니다. CI가 실패하면 실패한 체크 이름을 포함해 다시 에이전트를 재개하고, 리뷰어가 변경 요청을 남기면 그 코멘트를 프롬프트로 넘겨 다시 수정하게 하고, 모든 조건이 충족되면 squash merge까지 처리합니다. (GitHub)

이 관점이 중요한 이유는, 실제 팀 개발에서 병목이 “코드를 초안으로 만드는 일”이 아니라 완성도를 올리는 반복 루프에 있기 때문입니다.

• 테스트가 깨진다
• 머지 충돌이 난다
• 리뷰에서 수정 요청이 들어온다
• 다시 푸시하고 다시 확인한다

Optio는 이 반복을 “사람이 에이전트를 다시 호출하는 작업”이 아니라 시스템이 상태를 보고 다음 행동을 결정하는 작업으로 바꿉니다. 그래서 이 프로젝트는 AI IDE라기보다, AI용 CI/CD 엔진으로 이해하는 편이 더 정확합니다. (GitHub)

---

이 프로젝트를 한 문장으로 요약하면

Optio는 AI 코딩 에이전트를 단발성 실행기에서, PR 병합까지 책임지는 상태 기반 오케스트레이터로 바꾸는 프로젝트다.

---

핵심 기능 분석

1) 자동 피드백 루프

가장 중요한 기능입니다. Optio는 PR이 열린 뒤에도 일을 끝냈다고 보지 않습니다.
PR watcher가 30초마다 PR 상태를 확인하면서, 다음 이벤트에 반응합니다.

• CI 실패
• 리뷰 변경 요청
• 머지 충돌
• 승인 완료 및 병합 가능 상태

이때 시스템은 단순 알림을 보내는 것이 아니라, 에이전트를 다시 큐에 넣어 이어서 작업하게 만듭니다. 이 구조가 있어야 AI가 진짜 “개발 파이프라인의 구성원”처럼 동작합니다. (GitHub)

예를 들어 개발자 경험은 대략 이렇게 바뀝니다.

기존 방식
Issue 생성 → AI에게 코드 작성 요청 → 사람이 PR 생성/수정/재실행/리뷰 대응

Optio 방식
Issue 생성 → Optio 실행 → PR 생성 → CI 실패 시 자동 수정 → 리뷰 반영 → 자동 머지

---

2) Pod-per-repo + Git worktree 구조

이 프로젝트에서 제일 아키텍처적으로 인상적인 부분입니다.

Optio는 “태스크마다 컨테이너 1개”를 띄우지 않습니다. 대신 저장소마다 장수명 Kubernetes Pod 하나를 유지하고, 태스크마다 그 안에서 git worktree를 생성해 격리 실행합니다. 저장소는 한 번만 clone하고, 여러 작업은 worktree 단위로 병렬 처리합니다. README와 CLAUDE 문서에 따르면 이 구조는 persistent volume, idle cleanup, health monitoring, multi-pod scaling까지 고려되어 있습니다. maxPodInstances와 maxAgentsPerPod를 조합해 저장소별 처리량도 조절합니다. (GitHub)

이 설계가 좋은 이유는 분명합니다.

• 매 태스크마다 fresh clone 할 필요가 없습니다.
• 언어 툴체인, 캐시, 설치 패키지를 재사용할 수 있습니다.
• 같은 저장소의 여러 작업을 동시에 돌릴 수 있습니다.
• 재시도 시 같은 Pod를 선호해 worktree를 재활용할 수 있습니다.

즉, 이 프로젝트는 AI 실행기를 만들면서도 인프라 비용과 대기 시간을 같이 최적화하고 있습니다. 단순한 데모 구조가 아니라, 실제 운영을 염두에 둔 설계입니다. (GitHub)

---

3) 코드 리뷰 에이전트 분리

Optio는 “코드 작성”과 “코드 리뷰”를 같은 에이전트 책임으로 섞지 않습니다.
리뷰 에이전트를 별도 subtask로 실행할 수 있고, CI 통과 시점이나 PR 오픈 시점에 트리거되며, 더 저렴한 모델을 리뷰 전용으로 붙이는 구성도 가능합니다. 부모 태스크가 리뷰 태스크 완료를 기다리는 blocking 방식도 지원합니다. (GitHub)

이건 꽤 좋은 판단입니다. 이유는 간단합니다.

• 코딩 에이전트와 리뷰 에이전트의 프롬프트 목적이 다릅니다.
• 비용 최적화 전략이 다릅니다.
• 팀에 따라 “작성은 공격적으로, 리뷰는 보수적으로” 운영하고 싶을 수 있습니다.

즉, Optio는 AI를 단일 호출이 아니라 역할이 분리된 작업 체인으로 봅니다.

---

4) 저장소별 에이전트 튜닝

Optio는 전역 설정 하나로 모든 저장소를 돌리는 도구가 아닙니다. 저장소마다 Claude 모델 종류, 컨텍스트 크기, thinking 여부, effort level, 프롬프트 템플릿, 동시성, 추가 패키지, 시작 시 setup 명령 등을 다르게 줄 수 있습니다. .optio/setup.sh도 실행 가능하고, 프로젝트 언어를 감지해 Node/Python/Go/Rust/Full 이미지 프리셋을 자동 선택하는 기능도 있습니다. (GitHub)

이 기능이 중요한 이유는 저장소마다 요구 조건이 완전히 다르기 때문입니다.

• 프론트엔드는 브라우저 빌드 도구가 필요하고
• 백엔드는 DB 마이그레이션과 테스트 환경이 필요하고
• 인프라 저장소는 CLI와 cloud SDK가 필요합니다

이 차이를 흡수하지 못하면, AI 에이전트는 “대부분의 저장소에서 실패하는 장난감”이 되기 쉽습니다. Optio는 이 부분을 꽤 현실적으로 다루고 있습니다. (GitHub)

---

5) 실시간 운영 UI와 비용 분석

이 프로젝트가 단순 CLI가 아니라 시스템이라고 느껴지는 이유입니다.
웹 UI에는 태스크 목록, 태스크 상세 로그, 파이프라인 진행 단계, 이벤트 타임라인, 저장소 관리, 클러스터 상태, 시크릿 관리, 비용 분석 페이지가 있습니다. 비용 API는 기간별 총 비용, 평균 비용, 저장소별 비용, 작업 유형별 비용, 상위 고비용 태스크까지 제공합니다. 로그는 WebSocket과 Redis pub/sub로 실시간 스트리밍됩니다. (GitHub)

즉, 운영자는 이렇게 질문할 수 있습니다.

• 어떤 저장소에서 비용이 많이 드는가?
• 어떤 태스크가 실패를 반복하는가?
• 어떤 Pod가 OOM으로 죽었는가?
• 리뷰 대기 때문에 병목이 생기는가?

이 질문에 답할 수 있다는 건, Optio가 단순 “AI 실행 버튼”을 넘어서 운영 가능한 플랫폼을 지향한다는 뜻입니다. (GitHub)

---

프로젝트 아키텍처 분석

README와 내부 문서를 함께 보면 Optio의 큰 구조는 아래처럼 정리할 수 있습니다. (GitHub)

이 구조를 개발자 관점에서 해석해보면 핵심은 세 가지입니다.

첫째, API와 실행 환경이 분리되어 있다

웹/API는 제어 평면(control plane)이고, 실제 코드 수정은 Kubernetes Pod 내부 worktree에서 일어납니다. 이 분리는 안정성과 보안 면에서 자연스럽습니다. (GitHub)

둘째, 상태 전이가 명확하다

태스크는 queued → provisioning → running → pr_opened → completed/failed 같은 식으로 흘러가고, 서브태스크와 리뷰 태스크도 같은 오케스트레이션 안에 들어갑니다. changelog에 명시된 상태 머신 설계가 이 프로젝트의 핵심 토대입니다. (GitHub)

셋째, 이벤트 기반 재개가 가능하다

CI 실패, 리뷰 요청, 충돌 같은 외부 이벤트가 들어오면 PR watcher가 이를 감지하고 task worker를 다시 깨웁니다. 즉, 에이전트 실행이 “한 번 돌고 끝”나는 배치 작업이 아니라, 외부 신호에 반응하는 장기 워크플로가 됩니다. (GitHub)

---

디렉터리 구조에서 보이는 설계 의도

문서에 나온 디렉터리 레이아웃만 봐도 프로젝트 경계가 꽤 선명합니다. (GitHub)

apps/
  api/
    routes/
    services/
    workers/
    ws/
    db/
  web/
    app/
    components/
    hooks/
    lib/

packages/
  shared/
  container-runtime/
  agent-adapters/
  ticket-providers/

images/
helm/optio/
k8s/
scripts/

이 구조를 보면 Optio는 다음 원칙을 따릅니다.

• apps/api: 오케스트레이션과 상태 관리
• apps/web: 관찰성과 운영 경험
• packages/agent-adapters: AI 공급자 교체 가능성
• packages/container-runtime: 실행 환경 추상화
• packages/ticket-providers: 입력 채널 확장성
• packages/shared: 상태 머신, 타입, 템플릿, 에러 분류 공통화

즉, “AI 도구 하나”가 아니라 플랫폼 코어 + 어댑터 계층 + 운영 UI로 나눈 전형적인 확장형 설계입니다. 나중에 다른 에이전트나 티켓 시스템을 붙이기 쉬운 이유도 여기 있습니다. (GitHub)

---

실제 동작 흐름을 코드로 상상해보기

Optio는 내부적으로 이런 식의 상태 머신 사고방식으로 이해하면 쉽습니다.

type TaskState =
  | "queued"
  | "provisioning"
  | "running"
  | "pr_opened"
  | "completed"
  | "failed"
  | "cancelled"
  | "needs_attention";

async function runTask(task: Task) {
  await transition(task, "provisioning");

  const pod = await repoPool.acquire(task.repoUrl);
  const worktree = await pod.createWorktree(task.id);

  await transition(task, "running");
  const result = await agent.run({
    prompt: task.prompt,
    repoPath: worktree.path,
    model: task.model,
  });

  if (result.prOpened) {
    await transition(task, "pr_opened");
    await prWatcher.watch(result.prNumber);
  } else {
    await transition(task, "failed");
  }
}

async function onPullRequestEvent(event: PREvent) {
  if (event.type === "ci_failed") {
    await resumeAgentWithContext(event.taskId, event.failedChecks);
  }

  if (event.type === "changes_requested") {
    await resumeAgentWithContext(event.taskId, event.reviewComments);
  }

  if (event.type === "merge_ready") {
    await squashMerge(event.prNumber);
    await closeLinkedIssue(event.taskId);
    await transitionByTaskId(event.taskId, "completed");
  }
}

물론 실제 구현은 더 복잡하지만, 개발자가 이해해야 할 핵심은 이것입니다.

Optio의 본질은 “AI 호출”이 아니라 “상태 전이와 재개 가능한 워크플로”다.

---

이 프로젝트가 특히 흥미로운 이유

많은 AI 개발 툴은 사용자 경험이 IDE 중심입니다.
반면 Optio는 처음부터 저장소, PR, CI, 리뷰, 비용, 큐, 클러스터를 중심에 둡니다. 이건 개인 생산성 도구보다 팀 단위 운영 도구에 더 가깝습니다. (GitHub)

그래서 이 프로젝트가 잘 맞는 곳은 대체로 이런 팀입니다.

잘 맞는 경우

• GitHub PR 기반 협업이 팀 표준인 경우
• CI가 잘 구축되어 있는 경우
• 반복적인 유지보수/리팩터링/이슈 처리량이 많은 경우
• “AI가 작성한 코드”보다 “자동으로 끝난 작업”이 더 중요한 경우
• 쿠버네티스 운영이 가능한 팀인 경우

덜 맞는 경우

• PR/CI 문화가 약한 팀
• 저장소마다 로컬 수동 설정이 심한 팀
• AI가 생성한 변경을 항상 사람 손으로 세밀하게 검토해야 하는 고위험 도메인
• Kubernetes 운영 복잡도를 감당하기 어려운 작은 팀

Optio는 분명 강력하지만, 그만큼 전제도 있습니다. 개발 프로세스가 이미 구조화된 팀일수록 이 프로젝트의 가치가 커집니다. (GitHub)

---

이 프로젝트의 강점

가장 큰 강점은 “AI를 개발 파이프라인의 일부로 넣을 때 무엇이 필요한가”를 꽤 정확히 짚었다는 점입니다.
실행 환경 격리, 저장소 캐시, PR watcher, 상태 머신, 서브태스크, 리뷰 에이전트, 비용 추적, 에러 분류까지 포함하고 있어서, 단순한 자동 코딩 데모를 넘습니다. 특히 pod-per-repo + worktree 조합은 성능과 운영성을 동시에 챙긴 설계로 보입니다. (GitHub)

또 하나는 확장 포인트가 분명하다는 점입니다. agent adapter, container runtime, ticket provider가 패키지로 분리되어 있어, 미래에 다른 모델이나 실행 백엔드가 붙어도 구조가 크게 흔들리지 않습니다. (GitHub)

---

이 프로젝트를 볼 때 함께 생각해야 할 한계

초기 공개 버전이라는 점은 분명히 감안해야 합니다. changelog 기준 0.1.0이고, 저장소 메타데이터상 stars/forks도 아직 작은 편입니다. 즉, 지금 시점의 Optio는 “검증이 끝난 업계 표준”이라기보다 매우 흥미로운 초기 플랫폼에 가깝습니다. (GitHub)

그리고 구조적으로도 운영 난이도가 있습니다.

• Kubernetes가 필요합니다
• GitHub/Linear/OAuth/Agent credential 구성이 필요합니다
• PR 기반 자동 머지는 팀 정책과 충돌할 수 있습니다
• AI 자동 수정이 항상 올바른 방향으로 간다고 보장할 수는 없습니다

즉, 이 프로젝트는 강력하지만 공짜는 아닙니다.
도입 효과를 보려면 팀이 CI 규율, 리뷰 정책, 실행 환경 관리를 어느 정도 갖추고 있어야 합니다. (GitHub)

---

개발자가 배울 수 있는 설계 포인트

Optio를 직접 쓰지 않더라도, 이 저장소는 AI 시스템 설계 관점에서 배울 점이 많습니다.

1. 에이전트는 “호출”보다 “재개”가 중요하다

실무에서는 첫 시도가 아니라 두 번째, 세 번째 수정 루프가 더 중요합니다.

2. 실행 환경은 태스크 단위보다 저장소 단위가 효율적일 수 있다

특히 의존성 설치 비용이 큰 프로젝트에서 그렇습니다.

3. AI 기능도 결국 상태 머신 문제다

좋은 UX는 멋진 프롬프트가 아니라, 실패와 재시도를 다루는 상태 전이에서 나옵니다.

4. 관찰성이 없으면 자동화는 운영할 수 없다

실시간 로그, 이벤트 타임라인, 비용 분석이 따로 있는 이유입니다. (GitHub)

---

언제 써보면 좋을까

개인적으로 Optio는 이런 시나리오에서 가장 매력적입니다.

- 레거시 저장소의 반복 이슈 처리
- 테스트 수정 / 타입 에러 수정 / 의존성 업데이트
- 작은 기능 추가와 리팩터링
- 명확한 acceptance criteria가 있는 GitHub Issue 처리
- 리뷰 코멘트 반영 자동화

반대로, 요구사항이 매우 모호하거나, 제품 맥락 이해가 깊게 필요하거나, 작은 코드 차이도 큰 리스크를 만드는 도메인에서는 완전 자동보다는 부분 자동이 더 적합할 수 있습니다.

---

마무리

Optio는 “AI가 코드를 짠다”는 이야기에서 한 단계 더 나아갑니다.
이 프로젝트가 던지는 질문은 이겁니다.

AI가 코드를 작성할 수 있다면,
왜 아직도 사람은 CI 실패를 확인하고, 리뷰 코멘트를 복사하고, PR을 머지하는가?

Optio의 답은 명확합니다.
그 반복 루프까지 시스템이 맡아야 한다.

그래서 이 프로젝트는 단순한 AI 코딩 도구라기보다,
AI 에이전트를 위한 소프트웨어 전달 플랫폼으로 보는 편이 맞습니다. 아직 초기 버전이지만, 방향성은 분명합니다. 앞으로 AI 개발 인프라가 성숙해질수록, 이런 종류의 “에이전트 오케스트레이션 계층”은 점점 더 중요해질 가능성이 큽니다. (GitHub)