Optio – K8s에서 AI 코딩 에이전트를 오케스트레이션해 티켓에서 PR까지 자동화

Who Should Read

AI 코딩 에이전트를 팀 개발 워크플로우에 통합하고 싶은 DevOps 엔지니어 또는 플랫폼 엔지니어. 특히 Kubernetes 인프라를 운영하면서 반복적인 코드 작업을 자동화하려는 팀에게 적합하다.

Core Mechanics

• Optio는 GitHub Issue, Linear 티켓, 수동 입력 등 세 가지 방식으로 작업을 받아서, 각 태스크마다 격리된 Kubernetes Pod를 프로비저닝하고 그 안에서 AI 에이전트(Claude Code 또는 OpenAI Codex)를 실행한다.
• 단순 코드 생성에서 끝나지 않고 '피드백 루프'가 핵심이다. CI가 실패하면 실패 컨텍스트와 함께 에이전트를 자동으로 재개하고, 리뷰어가 변경을 요청하면 에이전트가 리뷰 코멘트를 읽고 수정 커밋을 푸시한다.
• 모든 조건이 통과되면 PR을 squash merge하고 이슈를 자동으로 닫는다. 사람이 PR 버튼을 누를 필요 없이 '작업 설명 → 머지 완료'까지 완전 자동화가 목표다.
• 각 태스크는 독립된 git worktree를 생성해서 실행되므로, 여러 태스크가 동시에 병렬로 진행될 수 있다. 대시보드에서 실행 중인 에이전트 수, Pod 상태, 비용, 최근 활동을 실시간으로 확인할 수 있다.
• 태스크 상세 뷰에서는 에이전트 출력이 라이브 스트리밍되고, 파이프라인 진행 상황, PR 추적, 태스크당 비용 분석을 확인할 수 있어 운영 가시성을 제공한다.
• Helm 차트가 포함되어 있어 Kubernetes 클러스터에 배포가 가능하고, docker-compose.yml도 제공해 로컬 개발 환경에서도 실행할 수 있다. pnpm + Turborepo 모노레포 구조로 API, 웹, 에이전트 컴포넌트가 분리되어 있다.
• 오픈소스(MIT 라이선스)이며 CLAUDE.md, CONTRIBUTING.md 등 AI 에이전트가 작업할 수 있도록 컨텍스트를 제공하는 파일들이 레포에 포함되어 있다. 현재 GitHub에서 Star 366개를 받았다.

Evidence

• '인간 감독 없이는 제대로 동작하지 않는다'는 회의론이 여러 댓글에서 제기됐다. GitHub Issue만 보고 AI가 올바른 방향으로 작업할 수 있는 건 가장 단순한 티켓뿐이라는 지적이 나왔고, LLM의 역할은 코드 생성보다 설계/아키텍처를 사람에게 커뮤니케이션하는 데 있어야 한다는 의견도 있었다.
• 병렬 실행 시 충돌 문제가 실질적 우려사항으로 제기됐다. 에이전트 A가 shared/utils.py를 수정하는 PR 작업 중에 에이전트 B도 같은 파일이 필요한 티켓을 받으면 어떻게 되냐는 질문이 있었다. 오케스트레이터가 사전에 의존성 분석을 하는지, 아니면 머지 충돌로 처리하는지 궁금해했지만 명확한 답변은 없었다.
• 리트라이 토큰 비용 문제에 대한 실제 경험이 공유됐다. 비슷한 시스템을 만들고 있다는 개발자가 에이전트 리트라이 시 토큰을 너무 많이 소비하는 게 가장 큰 난제였다고 밝혔다. 자신은 체크포인트를 만들어 실패 시 이전 상태로 되돌리는 방식을 쓰고 있는데, Optio는 이를 어떻게 처리하는지 물어봤다.
• Kubernetes가 필수 요건이라는 점에 부담을 느끼는 반응이 있었다. K8s를 좋아하지만 에이전트 설정의 중심이 아닌 선택지 중 하나여야 한다는 의견이 나왔다. 반면 'GitHub Actions + @claude 멘션'으로 비슷한 효과를 더 저렴하게 낼 수 있다는 대안도 언급됐다.
• '코드베이스를 망가뜨리는 쓰레기를 뱉는 걸 막는 게 뭐냐'는 직접적인 비판도 있었다. 이에 대해 '에이전트 출력을 리뷰하고 싶어야 한다'는 의견도 제시됐으며, MCP(Model Context Protocol) 지원 여부, 샌드박스 멀티테넌트 격리 지원 여부, Pod가 레포 단위인지 태스크 단위인지 등 실용적 질문들도 이어졌다.

How to Apply

• Linear나 GitHub Issues로 백로그를 관리하는 팀이라면, 반복적이고 명세가 명확한 티켓(예: 특정 API 엔드포인트 추가, 타입 오류 수정, 테스트 커버리지 보강)부터 Optio에 연결해 자동화 파이프라인을 실험해볼 수 있다. 처음에는 CI 자동 수정 루프가 제대로 작동하는지 검증하는 데 초점을 맞추는 것이 좋다.
• K8s 없이 시도해보려면 레포에 포함된 docker-compose.yml로 로컬에서 먼저 실행해볼 수 있다. `.env.example`을 참고해 Claude 또는 OpenAI API 키와 GitHub 토큰을 설정하면 로컬 환경에서 전체 워크플로우를 테스트할 수 있다.
• 프로덕션 배포 시에는 `helm/optio` 디렉토리에 있는 Helm 차트를 사용해 기존 K8s 클러스터에 올릴 수 있다. 단, 멀티테넌트 환경이라면 Pod 간 샌드박스 격리가 충분한지 먼저 검증이 필요하다 — 현재 커뮤니티에서도 이 부분이 명확히 문서화되지 않았다는 지적이 있었다.
• 병렬 에이전트 실행 시 동일 파일을 수정하는 충돌 리스크를 줄이려면, 초기에는 서로 독립적인 모듈이나 파일을 다루는 태스크만 병렬로 실행하고, 공유 유틸리티를 건드리는 작업은 순차 실행하도록 태스크 할당 전략을 수립하는 것이 안전하다.

Code Example

# 로컬에서 실행하기
git clone https://github.com/jonwiggins/optio
cd optio
cp .env.example .env
# .env에 ANTHROPIC_API_KEY, GITHUB_TOKEN 등 설정
docker-compose up

# Helm으로 K8s에 배포
helm install optio ./helm/optio \
  --set env.ANTHROPIC_API_KEY=<your-key> \
  --set env.GITHUB_TOKEN=<your-token>

Terminology

관련 논문

• ctx – 로컬 머신의 코딩 에이전트 히스토리를 검색하는 CLI 도구

  Claude Code, Cursor, Codex 등 코딩 에이전트가 이전 세션의 논의·결정·실패 시도를 잊지 않도록 SQLite로 인덱싱해 재사용할 수 있게 해주는 오픈소스 CLI 도구다.

• Micro-Agent: Model API 내부 협업으로 Frontier 모델을 이기는 방법 (vLLM Semantic Router)

  vLLM 팀이 단일 모델 API 호출 뒤에서 여러 모델이 협업하는 'Micro-Agent' 개념을 공개했습니다. 별도의 에이전트 코드 없이 라우터 레이어에서 모델 조합을 실행해 GPT-4급 결과를 더 저렴하게 낼 수 있다는 아이디어입니다.

• Ornith-1.0: 에이전틱 코딩을 위한 자기 개선형 오픈소스 모델

  Gemma 4와 Qwen 3.5를 기반으로 파인튜닝한 코딩 특화 오픈소스 모델로, RL(강화학습)을 통해 스캐폴드(에이전트 실행 구조)까지 함께 최적화하는 방식을 주장하지만, 커뮤니티에서는 벤치마크 과최적화에 불과하다는 의심을 받고 있다.

• Tool-Augmented Agent에서의 Entity Binding 실패 분석

  AI 에이전트가 올바른 도구를 선택해도 잘못된 대상에 실행하는 'Entity Binding 실패' 문제를 정의하고, 이를 막는 실행 정책을 평가한 논문.

• Herdr: 터미널에서 여러 AI Agent를 한 번에 관리하는 Agent Multiplexer

  여러 AI 코딩 에이전트(Claude, Codex 등)를 하나의 터미널에서 동시에 실행·관리할 수 있는 Rust 기반 오픈소스 툴로, tmux처럼 세션이 유지되고 SSH로 원격 접속도 가능해 멀티 에이전트 워크플로우를 크게 단순화해준다.

• Ornith-1.0: 스스로 Scaffold를 생성하는 Agentic Coding LLM

  모델이 문제 풀이 전략(scaffold)을 직접 생성하고 개선하는 자기강화 학습 프레임워크를 적용한 오픈소스 코딩 특화 LLM으로, 9B 소형 모델부터 397B 대형 모델까지 라인업을 갖추고 SWE-Bench 등 주요 벤치마크에서 Claude Opus 4.7을 능가하는 성능을 보여줬다.

Related Resources

• https://github.com/jonwiggins/optio
• https://github.com/redwoodjs/agent-ci