출처

요약

저자는 여러 AI 코딩 에이전트를 병렬로 돌리다 병목이 에이전트가 아니라 자신이라는 사실을 깨달았다. CI 통과 확인, 리뷰 코멘트 읽기, 에러 복사-붙여넣기 같은 조정 작업에 시간을 뺏기면서 “코드를 작성하는 일”이 “코드를 작성하는 것들을 돌보는 일”로 바뀌었다는 것이다. 이를 해결하기 위해 약 2,500줄짜리 bash 스크립트로 tmux 세션과 git 워크트리를 관리하는 오케스트레이터를 만들었고, 이후 이 오케스트레이션 작업 자체를 에이전트들에게 맡겼다. 에이전트들이 오케스트레이터의 TypeScript 버전(v1)을 만들었고, v1이 관리한 에이전트들이 v2를 만들었으며, v2는 이후 스스로를 개선해왔다. 결과물은 Agent Orchestrator로 오픈소스 공개되었다(github.com/ComposioHQ/agent-orchestrator).

핵심 주장은 오케스트레이터 자체가 대시보드나 크론 잡이 아니라 지능적인 AI 에이전트라는 점이다. 코드베이스를 읽고 백로그를 작업 단위로 분해하며, CI 실패 시 로그를 에이전트 세션에 재주입하고, 리뷰 코멘트를 올바른 세션으로 라우팅한다. 아키텍처는 Tracker(GitHub/Linear), Workspace, Runtime(tmux/프로세스), Agent(Claude Code/Aider 등), Terminal, SCM, Reactions, Notifier의 8개 교체 가능한 플러그인 슬롯으로 구성되며, GitHub 이벤트에 반응해 자동으로 에이전트를 재생성하는 reactions 설정(YAML)으로 CI 실패나 리뷰 요청을 자동 처리한다.

8일간(실제 집중 시간은 약 3일) 40,000줄의 TypeScript, 17개 플러그인, 3,288개 테스트, 102개 중 86개 PR을 에이전트가 생성했다. 모든 커밋에는 어떤 모델이 작성했는지 식별하는 git 트레일러가 붙어 있으며, Opus 4.6은 복잡한 아키텍처 작업을, Sonnet은 플러그인 구현·테스트·문서 등 대량 작업을 담당했다. Cursor Bugbot이 700개의 자동 코드 리뷰 코멘트를 남겼고 에이전트가 약 68%를 즉시 수정, 7%는 의도된 것으로 설명, 4%는 후속 PR로 미뤘다. 가장 극적인 사례(PR #125, 대시보드 리디자인)는 인간 개입 없이 12번의 CI 실패→수정 사이클을 거쳐 출시되었고, 9개 브랜치 41개 CI 실패가 모두 자체 수정되었다(전체 CI 성공률 84.6%).

저자가 직접 한 일은 아키텍처 결정, 세션 생성과 이슈 할당, 아키텍처 수준 PR 리뷰, 에이전트 간 충돌 해결, 판단 호출뿐이었고 기능 브랜치에 직접 커밋한 적은 없다. 모든 코드는 PR을 통과했다. Claude Code의 JSONL 세션 이벤트 파일을 직접 파싱해 에이전트가 실제로 활성 상태인지, 유휴 상태인지 판단하는 활동 감지 기능도 갖췄다. 저자는 이것이 “재귀적 자기 개선 루프”이며, 개별 에이전트 성능보다 이를 병렬로 배포·관찰·개선하는 오케스트레이션 시스템의 한계가 더 중요하다고 주장한다.

관련 위키

원문 보존 위치

원문 전체는 raw source: web-2026-04-30-self-improving-ai-system-built-itselfsource_url과 함께 저장되어 있다.