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

Related Resources

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