Show HN: Optio – K8s에서 AI 코딩 에이전트를 오케스트레이션하여 티켓을 PR로 변환하기
요약
Optio는 Kubernetes(K8s) 환경에서 AI 코딩 에이전트를 오케스트레이션하는 셀프 호스팅 플랫폼입니다. 티켓을 PR로 자동 변환하는 태스크, 독립적인 작업을 수행하는 잡, 그리고 장기 실행되는 에이전트라는 세 가지 계층을 통해 개발 워크플로우를 자동화합니다.
핵심 포인트
- K8s 기반의 셀프 호스팅 AI 엔지니어링 플랫폼 제공
- 티켓(GitHub, Jira 등)을 분석하여 격리된 환경에서 PR 생성부터 CI 모니터링, 자동 수정 및 병합까지 수행
- 태스크(Tasks), 잡(Jobs), 에이전트(Agents)의 세 가지 계층 구조를 통한 유연한 작업 모델 지원
- MCP(Model Context Protocol) 호환 서버 및 다양한 외부 서비스(Slack, Notion 등)와의 커넥션 지원
- CI 실패 시 컨텍스트를 파악하여 자동으로 재시도하는 피드백 루프 기능 탑재
Optio
셀프 호스팅(Self-hosted) AI 엔지니어링 플랫폼 — 당신의 클러스터, 당신의 에이전트, 당신의 코드.
Optio는 에이전트 작업을 세 가지 계층으로 구성하며, 이 모든 계층은 동일한 트리거 유형, 프롬프트 템플릿 엔진(prompt-template engine), 로그 스트리밍(log streaming) 및 /api/tasks HTTP 인터페이스에 의해 구동됩니다:
- 태스크 (Tasks) (Repo Tasks) — 티켓을 병합된 풀 리퀘스트(Pull Request, PR)로 변환합니다. 태스크를 제출하면 (수동으로, 또는 GitHub Issue, Linear, Jira, Notion으로부터), Optio는 격리된 환경을 프로비저닝하고, AI 에이전트를 실행하며, PR을 생성하고, CI를 모니터링하며, 코드 리뷰를 트리거하고, 실패를 자동 수정(auto-fixes)하며, 모든 것이 통과되면 병합합니다.
- 잡 (Jobs) (Standalone Tasks) — 리포지토리 체크아웃(repo checkout) 없이 실행되는 재사용 가능한 매개변수화된(parameterized) 에이전트 실행입니다. 보고서 생성, 알림 분류(triage), 의존성 감사(audit), 데이터베이스 쿼리, Slack 게시 등 PR로 반영될 필요가 없는 모든 작업을 수행합니다.
- 에이전트 (Agents) (Persistent Agents) — 수명이 길고, 이름이 지정되며, 메시지 기반(message-driven)으로 작동하는 에이전트 프로세스입니다. 각 에이전트는 안정적인 슬러그(slug), 인박스(inbox), 그리고 순환 상태 머신(cyclic state machine)을 가집니다. 사용자 메시지, 에이전트 메시지, 웹훅(webhooks), 크론 틱(cron ticks) 또는 티켓 이벤트에 의해 깨어납니다. 세 가지 포드(pod) 라이프사이클 모드(
always-on/sticky/on-demand)를 지원합니다. 에이전트 간 HTTP API를 통해 서로 통신합니다. 4개 에이전트로 구성된 Forge 데모와 Mars Mission Control 예시를 확인해 보세요. - 커넥션 (Connections) — 에이전트에게 외부 서비스에 대한 접근 권한을 부여합니다. Notion, Slack, Linear, GitHub, PostgreSQL, Sentry 또는 모든 MCP 호환 서버를 연결하면, Optio는 런타임(runtime)에 이를 에이전트 포드에 주입합니다.
Tasks와 Jobs는 **작업 모델 (job model)**입니다. 이는 실행(run) 자체가 정체성이 되는 일회성 실행(one-shot runs)을 의미합니다. Persistent Agents는 **서비스 모델 (service model)**입니다. 여기서 하나의 턴(turn)은 작업 단위가 아니라, 장기 실행되는 프로세스(long-lived process)에 대한 입력값입니다. 작업의 형태에 따라 적절한 티어(tier)를 선택하세요. 실행 가능한 시작점은 examples/를, 전체적인 세부 분류는 docs/tasks.md를 참조하십시오.
피드백 루프(feedback loop)는 Tasks를 차별화하는 요소입니다. CI(지속적 통합)가 실패하면, 에이전트는 실패 컨텍스트(failure context)를 가지고 자동으로 재개됩니다. 리뷰어가 수정을 요청하면, 에이전트는 리뷰 코멘트를 파악하여 수정 사항을 푸시합니다. 모든 검증을 통과하면, PR(Pull Request)은 스쿼시 머지(squash-merged)되고 이슈(issue)는 종료됩니다. 사용자는 작업 내용을 설명하기만 하면 됩니다. Optio가 이를 완료될 때까지 구동합니다.
내부적으로 모든 태스크(task) 및 포드(pod) 상태 변경은 Kubernetes 스타일의 조정 제어 평면 (Kubernetes-style reconciliation control plane)을 통해 흐릅니다. 이는 주기적인 재동기화(resync)를 포함하는 순수 결정 및 CAS 실행기(CAS-executor) 루프로, 유실된 이벤트로 인해 실행이 중단되는 것을 방지합니다.
<p align="center"> <img src="docs/screenshots/overview.png" alt="Optio dashboard showing 10 running tasks, 19 completed, with Claude Max usage, active pods, and recent task activity" width="100%"/> </p> <p align="center"><em>대시보드 — 실행 중인 에이전트, 포드 상태, 비용 및 최근 활동에 대한 실시간 개요</em></em></p> <p align="center"> <img src="docs/screenshots/task-detail.png" alt="Task detail view showing live agent logs, pipeline progress through stages (queued, setup, running, PR, CI checks, review, merge, done), and cost tracking" width="100%"/> </p> <p align="center"><em>태스크 상세 — 파이프라인 진행 상황, PR 추적 및 비용 내역이 포함된 에이전트 실시간 출력 스트림</em></em></p>왜 Optio인가?
AI 코딩 에이전트 분야는 매우 혼잡합니다. Devin, Charlie Labs, Cursor 백그라운드 에이전트, Sweep 등이 모두 티켓을 PR로 자동화한다고 약속합니다. Optio의 공략 지점은 다릅니다. Optio는 여러분의 인프라 내에서, 여러분이 신뢰하는 에이전트 벤더를 통해, 여러분이 이미 운영 중인 Kubernetes 클러스터 위에서 실행됩니다.
| Optio | 호스팅형 대안 (Hosted alternatives) |
|---|---|
| Self-hosted (자체 호스팅) — 여러분의 Kubernetes 클러스터(GKE, EKS, AKS 또는 규격에 맞는 모든 K8s) 내에서 완전히 실행됩니다. 코드, 비밀 정보(secrets), 에이전트 로그가 여러분의 네트워크를 절대 벗어나지 않습니다. | Hosted SaaS (호스팅형 SaaS) — 여러분의 코드가 해당 업체의 클라우드로 전송됩니다. |
| ... |
만약 아무런 고민 없이 호스팅된 에이전트로 배포할 의향이 있다면, 호스팅 옵션이 더 간단합니다. 하지만 여러분의 저장소(repo)를 타인의 클라우드로 보내는 것이 불가능하거나, 모델 선택의 자유를 유지하고 싶다면 Optio가 바로 여러분을 위해 만들어졌습니다.
이 서비스는 누구를 위한 것인가요?
- 보안을 중시하는 조직 (Security-conscious organizations) — 소스 코드, 비밀 정보(secrets), 또는 프로덕션 데이터를 제3자 AI 서비스로 전송할 수 없거나 전송하지 않으려는 팀.
- 규제 산업 (Regulated industries) — 데이터 거주성(data residency), 감사 가능성(auditability), 테넌시 격리(tenancy isolation)가 타협 불가능한 금융, 의료, 정부, 국방 등의 분야.
- 이미 Kubernetes를 운영 중인 팀 — Helm을 통한 즉시 설치, BYO Postgres/Redis 지원, 기존의 관찰성(observability), 인그레스(ingress), 그리고 ID 스택(identity stack)과 통합 가능.
- 멀티 에이전트 활용 기업 (Multi-agent shops) — 여러 에이전트 벤더를 평가 중이며, 특정 플랫폼의 로드맵에 종속되기를 원치 않는 엔지니어링 팀.
- 내부 AI 도구를 구축하는 플랫폼 팀 — Optio는 오케스트레이션 계층(orchestration layer) 역할을 합니다. 여러분은 프롬프트(prompts), 정책(policies), 연결(connections), 그리고 리뷰 표준을 가져오기만 하면 됩니다.
만약 위의 사항 중 어디에도 해당하지 않는다면, Devin이나 Cursor의 백그라운드 에이전트와 같은 호스팅 제품이 더 빠르게 가치를 제공할 것입니다. 저희는 모든 사람에게 모든 것을 제공하려는 것이 아닙니다.
작동 방식
태스크 (Tasks) — 티켓에서 병합된 PR까지
태스크 생성 Optio가 에이전트 실행 Optio가 루프 종료
───────────────── ────────────────────── ──────────────────────
...
- 수집 (Intake) — 웹 UI, GitHub Issues (원클릭 할당), Linear, Jira 또는 Notion으로부터 태스크가 들어옵니다.
- 프로비저닝 (Provisioning) — Optio는 해당 리포지토리를 위한 Kubernetes 포드(pod)를 찾거나 생성하며, 격리를 위해 git 워크트리(worktree)를 생성합니다.
- 실행 (Execution) — AI 에이전트(Claude Code, OpenAI Codex 또는 GitHub Copilot)가 사용자가 설정한 프롬프트, 모델 및 설정값과 함께 실행됩니다.
- PR 라이프사이클 (PR lifecycle) — Optio는 CI 상태, 리뷰 상태 및 병합 준비 여부를 확인하기 위해 30초마다 PR을 폴링(poll)합니다.
- 피드백 루프 (Feedback loop) — CI 실패, 병합 충돌(merge conflicts) 및 리뷰 피드백은 컨텍스트(context)와 함께 에이전트를 자동으로 재개시킵니다.
- 완료 (Completion) — PR이 스쿼시 병합(squash-merged)되고, 연결된 이슈가 종료되며, 비용이 기록됩니다.
잡 (Jobs) — 리포지토리 없이 재사용 가능한 에이전트 작업
당신이 작업을 정의하면 Optio가 트리거함 Optio가 실행 및 추적
──────────────────── ───────────────── ───────────────────
...
잡 (Jobs, 독립형 작업)은 git checkout 없이 격리된 포드 (pod)에서 에이전트를 실행합니다. {{PARAM}} 플레이스홀더가 포함된 프롬프트 템플릿 (prompt template)을 정의하고, 트리거 (수동, cron 스케줄, 웹훅 (webhook), 또는 티켓)를 구성하면 Optio가 실행, 재시도 및 비용 추적을 처리합니다. 작업은 동일한 트리거 유형을 가진 **블루프린트 (blueprints)**로 저장할 수도 있습니다 — docs/tasks.md를 참조하세요.
에이전트 (Agents) — 장기 실행, 메시지 기반
에이전트를 생성하면 깨우는 소스 (Wake sources) 턴 (Per turn) 당
────────────────────── ───────────────── ──────────────────────
...
지속형 에이전트 (Persistent Agents, PAs)는 동일한 워크스페이스 내의 다른 에이전트가 호출할 수 있는 장기 실행 프로세스입니다. 각 PA는 하나의 작업 **턴 (turn)**을 실행하고, 중단된 후 메시지나 트리거 이벤트에 의해 다시 깨어나기를 기다립니다. 포드 생명주기 (pod lifecycle)는 에이전트별로 구성할 수 있습니다: always-on (최저 지연 시간, 최고 비용), sticky (각 턴 이후 유휴 시간 동안 warm 상태 유지 — 기본값), 또는 on-demand (매 턴 콜드 스타트 (cold-start)). PAs는 기존의 트리거 시스템, 리컨실러 (reconciler), 그리고 포드 풀 (pod-pool) 프리미티브 (primitives)를 재사용합니다. docs/persistent-agents.md 및 examples/persistent-agents 디렉토리를 참조하세요.
커넥션 (Connections) — 에이전트 기능 확장
커넥션은 에이전트가 런타임 (runtime)에 외부 도구 및 데이터에 접근할 수 있도록 합니다. 프로바이더 (provider)를 한 번 구성하여 리포지토리나 에이전트에 할당하면, Optio가 에이전트 포드에 MCP 서버를 자동으로 주입합니다.
내장 프로바이더: Notion, GitHub, Slack, Linear, PostgreSQL, Sentry, 파일 시스템 (Filesystem), 그리고 커스텀 MCP 서버 및 HTTP API.
주요 기능
- 자율 피드백 루프 (Autonomous feedback loop) — CI 실패, 머지 충돌 (merge conflicts), 리뷰 피드백 발생 시 에이전트를 자동으로 재개하며, 모든 조건이 충족되면 자동으로 머지 (auto-merges)합니다.
- 3단계 작업 계층 (Three Task tiers) — **태스크 (Tasks)**는 PR을 통해 코드를 반영합니다; **잡 (Jobs)**은 보고서 작성, 분류 (triage), 운영 (ops)을 위해 빈 포드 (pods)에서 에이전트를 실행합니다; **에이전트 (Agents)**는 메시지 기반의 장기 실행 서비스입니다. 이 세 가지는 모두 트리거 (수동 / 스케줄 / 웹훅 / 티켓), 프롬프트 템플릿 (prompt templates), 리컨실러 (reconciler), 그리고 통합된
/api/tasksHTTP 레이어를 공유합니다. - 에이전트 간 메시징 (Inter-agent messaging) — 지속성 에이전트 (Persistent Agents)는
/api/internal/persistent-agents/*를 통해 서로에게 직접 메시지 또는 브로드캐스트를 보낼 수 있어, 멀티 에이전트 팀 구성을 가능하게 합니다 (Forge 데모 참조). - 연결 (Connections) — 외부 서비스 (Notion, Slack, Linear, GitHub, PostgreSQL, Sentry, 커스텀 MCP 서버)를 레포지토리 (repo) 및 에이전트 유형별로 세분화된 액세스 제어 (access control)를 통해 에이전트 포드에 연결할 수 있습니다.
- 레포지토리별 포드 아키텍처 (Pod-per-repo architecture) — 각 레포지토리당 하나의 장기 실행 Kubernetes 포드를 할당하며, git 워크트리 (worktree) 격리, 멀티 포드 확장 (multi-pod scaling), 유휴 상태 정리 (idle cleanup) 기능을 제공합니다.
- 코드 리뷰 에이전트 (Code review agent) — 별도의 프롬프트와 모델을 사용하여 리뷰 에이전트를 서브태스크 (subtask)로 자동 실행합니다.
- 멀티 에이전트 지원 (Multi-agent support) — 레포지토리별 모델 및 프롬프트 설정을 통해 Claude Code, OpenAI Codex, GitHub Copilot, Google Gemini 또는 OpenCode를 실행할 수 있습니다.
- GitHub Issues, Linear, Jira 및 Notion 입력 (Intake) — UI 또는 티켓 동기화 (ticket sync)를 통해 이슈를 Optio에 할당합니다.
- 리컨실리에이션 컨트롤 플레인 (Reconciliation control plane) — 4가지
RunKind(repo,standalone,pr-review,persistent-agent)에 대해 주기적인 재동기화 (resync)를 수행하는 K8s 스타일의 순수 결정 및 CAS 실행기 (CAS-executor) 루프를 갖추고 있습니다. 이를 통해 이벤트 유실 시에도 상태가 멈추지 않도록 유지합니다. - 실시간 대시보드 (Real-time dashboard) — 라이브 로그 스트리밍, 파이프라인 진행 상황, 비용 분석 (cost analytics), 클러스터 상태 (cluster health)를 제공합니다.
아키텍처 (Architecture)
┌──────────────┐ ┌────────────────────┐ ┌────────────────────────────┐
│ Web UI │────→│ API Server │────→│ Kubernetes │
│ Next.js │ │ Fastify │ │ │
...
태스크 생명주기 (Task lifecycle)
┌──────────────────────────────────────────────────┐
│ INTAKE │
│ │
...
Quick Start (빠른 시작)
Prerequisites (사전 요구 사항)
- Kubernetes v1.33+ — 컨트롤 플레인(control plane)의 양자 내성 TLS (post-quantum TLS)를 위해 필요합니다. v1.33은 Go 1.24를 기반으로 구축된 첫 번째 릴리스로, 하이브리드 X25519MLKEM768 키 교환 (key exchange)을 자동으로 활성화합니다. 이전 버전에서도 실행은 가능하지만, Optio와 Kubernetes API 서버 간에 양자 내성 TLS 협상이 이루어지지 않습니다.
- Kubernetes가 활성화된 Docker Desktop (Settings → Kubernetes → Enable)
- Node.js 22+ 및 pnpm 10+
- Helm (
brew install helm)
Setup (설정)
git clone https://github.com/jonwiggins/optio.git && cd optio
./scripts/setup-local.sh
끝입니다. 설정 스크립트는 의존성(dependencies)을 설치하고, 모든 Docker 이미지(API, web, agent presets)를 빌드하며, Helm을 통해 전체 스택을 로컬 Kubernetes 클러스터에 배포하고, metrics-server를 설치합니다.
Web UI ...... http://localhost:30310
API ......... http://localhost:30400
웹 UI를 열면 설정 마법사(setup wizard)가 GitHub 액세스, 에이전트 자격 증명(API key 또는 Max/Pro 구독), 그리고 첫 번째 리포지토리(repository)를 추가하는 과정을 안내합니다.
Updating (업데이트)
./scripts/update-local.sh
최신 코드를 가져오고, 이미지를 다시 빌드하며, Helm 변경 사항을 적용하고, 배포(deployments)를 롤링 재시작(rolling-restarts)합니다.
Teardown (삭제)
helm uninstall optio -n optio
Project Structure (프로젝트 구조)
apps/
api/ Fastify API 서버, BullMQ 워커 (reconciler,
persistent-agent 워커 포함), WebSocket 엔드포인트, standalone-task
...
GitHub App Setup (GitHub App 설정)
Optio는 GitHub 작업을 위해 개인 액세스 토큰(Personal Access Token) 대신 GitHub App을 사용할 수 있습니다. 이를 통해 사용자 범위 액세스(CODEOWNERS, 브랜치 보호 및 리포지토리 권한 준수), 자동 토큰 갱신, 그리고 PR 및 커밋에 대한 명확한 귀속(attribution)을 제공합니다.
Creating the GitHub App (GitHub App 생성)
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기