AI 코딩 에이전트가 코드를 쓰는 단계는 이제 제일 화려하지만, 제일 혼자 떨어져 있는 단계가 됐다. 실제 팀 운영에서는 티켓을 받고, 브랜치를 만들고, PR을 열고, CI 실패를 고치고, 리뷰 코멘트를 반영하고, 머지 뒤 기록까지 남겨야 한다.
Optio가 흥미로운 지점은 바로 여기다. 공식 README 기준 Optio는 AI 코딩 에이전트를 위한 self-hosted engineering platform이고, GitHub Issue, Linear, Jira, Notion 같은 입력에서 작업을 받아 에이전트 실행, PR 생성, CI 확인, 코드 리뷰, 실패 수정, 머지까지 이어지는 흐름을 Kubernetes 위에서 굴리려는 프로젝트다.
내가 이 글을 TECHTAEK 백로그에서 살린 이유도 단순히 새 도구라서가 아니다. 요즘 AI 코딩 도구는 “코드를 잘 쓰나”보다 “작업이 끝났다는 증거를 어디에 남기나”가 더 중요해지고 있다. 우리도 블로그 OS에서 실험을 계속 돌리다 보니, 실행보다 판정과 회수 루프가 병목이라는 걸 매일 맞고 있다. 자동화도 인생도, 마감 증거 없으면 대충 했다는 소리 듣기 딱 좋다.
지금 판단
Optio는 개인이 오늘 바로 설치해서 가볍게 써볼 장난감이라기보다, 이미 Kubernetes와 GitHub 운영 기준이 있는 팀이 AI coding agent를 내부 플랫폼으로 끌어안고 싶을 때 보는 쪽에 가깝다. README의 Quick Start도 Kubernetes v1.33+, Docker Desktop Kubernetes, Node.js 22+, pnpm 10+, Helm을 요구한다.
그래서 첫 판단은 간단하다. hosted coding agent에 repo를 올리는 것이 조직 정책상 괜찮고, PR 몇 개를 빨리 자동화하는 게 목표라면 더 단순한 제품이 빠를 수 있다. 반대로 코드, secret, agent log가 외부 SaaS로 나가는 게 곤란하거나, Claude Code, Codex, Copilot, Gemini, OpenCode를 repo별로 바꿔가며 쓰고 싶다면 Optio 같은 self-hosted 오케스트레이터를 검토할 이유가 생긴다.
| 상황 | Optio 검토 가치 | 이유 |
|---|---|---|
| 개인 사이드프로젝트 한두 개 | 낮음 | Kubernetes와 운영 비용이 과하다 |
| 보안 민감 repo를 외부 SaaS에 못 올림 | 높음 | 코드와 로그를 자기 클러스터 안에 두는 구조 |
| 여러 에이전트 벤더를 A/B 테스트하고 싶음 | 높음 | Claude Code, Codex, Copilot, Gemini, OpenCode를 한 운영면에 올리는 방향 |
| 단순 PR 자동생성만 원함 | 중간 | ticket-to-PR은 가능하지만 플랫폼 무게가 있다 |
| on-call triage, 보고서, cron 작업까지 에이전트화 | 높음 | Jobs와 Persistent Agents가 repo 없는 작업도 다룸 |
Optio가 잡는 운영 공백
일반적인 AI 코딩 흐름은 프롬프트에서 시작해 diff에서 끝난다. 하지만 팀 운영에서는 diff가 끝이 아니다. CI가 깨지면 다시 고쳐야 하고, reviewer가 변경 요청을 남기면 그 맥락을 읽어야 하며, branch protection과 issue close까지 이어져야 한다.
Optio README는 이 피드백 루프를 전면에 둔다. CI 실패, merge conflict, review feedback이 생기면 에이전트를 다시 깨워 실패 맥락과 함께 이어가게 하고, 모든 조건이 통과하면 PR을 squash merge하고 issue를 닫는 흐름을 설명한다. 여기서 중요한 건 “에이전트가 똑똑하다”가 아니라 “실패를 다시 먹이는 운영 고리가 있다”는 점이다.
이 차이는 작아 보이지만 실제 운영에서는 크다. 단발성 에이전트는 한 번의 작업을 잘 끝내면 박수를 받지만, 실패 이벤트가 생기는 순간 사람이 다시 맥락을 모아줘야 한다. 오케스트레이터는 그 맥락 수집, 재개, 상태 추적을 시스템의 일로 넘기려는 시도다.
세 가지 작업 모델
Optio는 작업을 Tasks, Jobs, Agents로 나눈다. 이 구분이 마음에 드는 이유는 모든 자동화를 “PR 만들어줘”로 밀어넣지 않기 때문이다. 우리 쪽 .claude 운영에서도 글쓰기, 수익 실험 체크, URL 요약, 하네스 헬스 체크는 서로 다른 작업 형태인데, 한 이름으로 묶으면 금방 지저분해진다.
Tasks는 repo 작업이다. GitHub Issue나 Linear, Jira, Notion에서 들어온 일을 받아 isolated environment를 만들고, git worktree에서 agent가 코드를 수정하고, PR과 CI와 review 상태를 따라간다. 코드 변경이 남아야 하는 작업이라면 이 모델이 맞다.
Jobs는 repo checkout이 필요 없는 반복 실행이다. 보고서 생성, alert triage, dependency audit, database query, Slack post처럼 코드 변경보다 실행 결과가 중요한 작업이 여기에 가깝다. prompt template, schedule, webhook, retry, budget을 붙일 수 있다는 점에서 우리 블로그 수익 체크 자동화와도 닮은 구석이 있다.
Persistent Agents는 장기 실행 서비스 모델이다. 이름과 inbox가 있고, user message, agent message, webhook, cron tick, ticket event로 깨어난다. pod lifecycle도 always-on, sticky, on-demand로 나뉘어서 latency와 비용을 선택하게 한다. 장기 에이전트를 그냥 채팅방에 두는 게 아니라, 언제 깨어나고 언제 멈추는지 상태 기계를 갖춘다는 점이 핵심이다.
| 모델 | 맞는 작업 | 피해야 할 사용 |
|---|---|---|
| Tasks | 티켓을 PR로 닫는 코드 변경 | 애매한 제품 방향 탐색 |
| Jobs | 주기적 보고서, 점검, triage | repo 전체 수정이 필요한 작업 |
| Persistent Agents | 장기 inbox, webhook, cron 기반 운영 | 비용 기준 없이 항상 켜두는 세션 |
Kubernetes와 worktree 격리
Optio의 운영 방향은 pod-per-repo architecture와 git worktree isolation이다. repo마다 긴 수명의 pod를 두고, 작업별로 worktree를 나눠 병렬 작업 충돌을 줄이는 식이다. 유휴 pod 정리와 multi-pod scaling도 주요 기능으로 설명된다.
이 구조는 예쁘지만 공짜는 아니다. Kubernetes를 이미 운영하는 팀에는 자연스럽지만, 로컬에서 AI 코딩 도구 몇 개를 쓰는 개인에게는 준비물이 꽤 무겁다. README가 Docker image build, Helm deploy, metrics-server 설치까지 setup script에서 처리한다고 설명해도, 장애가 났을 때 봐야 할 층은 확실히 늘어난다.
그래서 설치 전 질문은 “이게 멋진가”가 아니라 “우리 팀은 이 운영면을 책임질 준비가 됐나”여야 한다. Kubernetes, Postgres, Redis, OAuth, secret, log retention, cost tracking을 볼 사람이 없다면, agent가 코드를 잘 써도 플랫폼 자체가 새 운영 부채가 될 수 있다. 멋진 자동화도 관리자가 없으면 금방 방치된 대시보드가 된다.
보안과 권한 체크
Optio가 self-hosted를 강조하는 이유는 분명하다. README는 코드, secrets, agent logs가 네트워크 밖으로 나가지 않는 구조와 encrypted secrets at rest, OIDC/OAuth, Kubernetes RBAC, audit-friendly task history를 장점으로 둔다. 보안 민감 조직이라면 이 포인트가 hosted agent보다 중요할 수 있다.
다만 self-hosted라는 단어가 자동으로 안전을 뜻하지는 않는다. GitHub App 권한만 봐도 contents read/write, pull requests read/write, issues read/write, checks read 같은 권한 설계가 필요하다. agent가 PR을 열고 merge까지 할 수 있다면, permission review와 branch protection이 운영의 일부가 되어야 한다.
여기서 내가 보는 최소 체크는 네 가지다. 첫째, repo별 agent 권한이 분리되는가. 둘째, secrets와 logs가 redaction과 retention 정책을 갖는가. 셋째, PR merge 조건이 사람 리뷰와 CI를 제대로 반영하는가. 넷째, agent가 실패를 자동 수정할 때 변경 범위가 worktree와 branch policy 안에 갇히는가.
| 체크 | 질문 | 위험 신호 |
|---|---|---|
| GitHub 권한 | App 권한이 repo와 조직 정책에 맞나 | PAT 하나로 모든 repo를 열어둠 |
| Secret 관리 | Kubernetes Secret, external secret, rotation이 정해졌나 | agent log에 token이 남음 |
| Merge 조건 | CI와 review approval이 필요한가 | agent가 조건 없이 merge 가능 |
| Audit | 누가 어떤 task를 만들었는지 남나 | PR만 있고 실행 기록이 없음 |
내 자동화 시스템에 붙인다면
내가 지금 바로 Optio를 설치한다면 첫 대상은 큰 제품 개발이 아니라 작은 운영 루프다. 예를 들어 “블로그 수익 실험 리포트가 FAIL이면 원인 요약과 다음 액션 PR을 만든다” 같은 repo-bound task는 Tasks로 실험할 수 있다. 반면 매일 수익, 색인, UTM을 읽어 보고서만 쓰는 작업은 Jobs에 더 가깝다.
Persistent Agents는 더 조심해서 봐야 한다. 장기 에이전트는 편하지만, inbox와 cron과 webhook이 붙는 순간 비용과 권한이 은근히 번진다. 내가 운영한다면 always-on은 거의 쓰지 않고, sticky나 on-demand로 시작해 latency보다 비용과 로그 품질을 먼저 볼 것이다.
중요한 건 Optio가 우리 .claude/agents, .claude/skills, 하네스 구조를 대체하느냐가 아니다. 더 현실적인 질문은 지금 우리 자동화에서 빠진 부분, 특히 ticket-to-PR 상태 추적, CI 실패 재개, review feedback 반영, 비용 기록을 어디까지 플랫폼으로 올릴 가치가 있느냐다.
설치 전 체크리스트
Optio를 설치하기 전에는 기능표보다 운영 조건부터 봐야 한다. 로컬 테스트도 Kubernetes를 요구하므로, “한 번 깔아보고 판단”의 비용이 작은 편은 아니다. 그냥 npx 한 줄로 끝나는 도구처럼 접근하면 시작부터 피곤해진다.
| 체크 | 확인할 것 | 통과 기준 |
|---|---|---|
| 인프라 | Kubernetes v1.33+, Docker Desktop Kubernetes, Helm | 로컬 실험 클러스터가 따로 있음 |
| 런타임 | Node.js 22+, pnpm 10+ | repo 요구사항과 일치 |
| GitHub | GitHub App 또는 PAT fallback | App 권한과 branch protection 검토 |
| 데이터 | Postgres, Redis, secrets | 로컬과 운영 분리 |
| 에이전트 | Claude Code, Codex, Copilot, Gemini, OpenCode 중 쓸 벤더 | repo별로 하나만 먼저 연결 |
| 관측 | live logs, cost tracking, task history | 실패 원인을 다시 볼 수 있음 |
첫 파일럿은 딱 하나가 좋다. “작은 issue 하나를 PR로 만들고, CI 실패가 나면 한 번만 자동 재개한다” 정도면 충분하다. 여기서 PR 생성, CI polling, review request 반영, cost 기록까지 확인한 뒤에야 Jobs나 Persistent Agents로 넓히는 편이 안전하다.
FAQ
Optio는 Claude Code 대체제인가?
대체제라기보다 운영층에 가깝다. README 기준 Optio는 Claude Code, OpenAI Codex, GitHub Copilot, Google Gemini, OpenCode 같은 여러 agent vendor를 한 플랫폼에서 다루려는 방향이다. Claude Code 자체의 코딩 능력을 대체한다기보다, 작업 접수, 실행 환경, PR, CI, review, merge 루프를 묶는 쪽에 더 가깝다.
개인 개발자도 Optio를 써볼 만한가?
호기심 실험은 가능하지만 기본값으로 추천하기는 어렵다. Kubernetes, Helm, Postgres, Redis, GitHub 권한까지 같이 봐야 해서 개인 프로젝트에는 운영 무게가 크다. 이미 self-hosted agent platform을 실험하고 있거나, 여러 agent vendor를 비교해야 하는 상황이라면 별도 테스트 repo에서만 가볍게 보는 편이 낫다.
Tasks와 Jobs는 어떻게 다르나?
Tasks는 repo와 PR이 중심이다. 티켓을 받아 worktree에서 코드를 고치고, PR과 CI와 review feedback을 따라간다. Jobs는 repo checkout이 없어도 되는 반복 실행이다. 보고서 생성, alert triage, dependency audit처럼 결과물이나 알림이 중심인 작업에 더 잘 맞는다.
Optio를 도입하기 전에 제일 먼저 볼 것은?
설치 명령보다 권한 모델을 먼저 봐야 한다. 어떤 repo에 어떤 agent가 접근하는지, GitHub App 권한은 어디까지인지, CI 실패 자동수정이 어떤 branch policy 안에서 움직이는지 확인해야 한다. agent가 PR을 만들고 merge까지 갈 수 있다면, 그건 개발 도구가 아니라 운영 시스템이다.