Issue-Orchestrator: 코딩 에이전트를 위한 소프트웨어 엔지니어링 컨트롤 플레인 (Control Plane)

코딩 에이전트 (Coding agents)는 제한된 범위의 작업(bounded tasks)을 완료하는 데 매우 능숙합니다.

하지만 그 자체만으로는 대규모 시스템을 관리하는 훌륭한 관리자(stewards)가 되지는 못합니다.

이러한 차이점이 저로 하여금 Issue-Orchestrator를 구축하게 만들었습니다. 이는 코딩 에이전트를 위한 소프트웨어 엔지니어링 컨트롤 플레인 (control plane)입니다.

이 모델은 분업화된 구조를 가집니다.

사용자는 자신의 코드베이스에 대해 무엇이 "좋은" 것인지 정의합니다. Issue-Orchestrator는 이러한 표준이 에이전트 워크플로 (workflow) 내에서 강제될 수 있도록 만듭니다.

사용자가 가져오는 표준:

• 명명된 아키텍처 (architecture)
• 테스트, 검증(validation), 및 커버리지 게이트 (coverage gates)
• 리뷰 기준 (review criteria)
• 적절한 규모의, 리뷰 가능한 이슈 (issues)
• 각 이슈에 대한 명확한 완료 정의 (definition of done)

Issue-Orchestrator가 제공하는 강제성:

• 이슈당 격리된 워크트리 (worktree)
• 리뷰어 에이전트 (reviewer agents) 및 제한된 재작업 (rework)
• 충돌 복구 (crash recovery) 및 조정 (reconciliation)
• 검사를 위한 타임라인, 트랜스크립트 (transcripts), 및 세션 리플레이 (session replay)
• 인간의 머지 권한 (human merge authority)

이 시스템을 작동하게 만드는 변화는 간단합니다: 에이전트의 출력물은 주장(claim)일 뿐, 권한(authority)이 아니라는 점입니다.

에이전트가 완료되었다고 말한다고 해서 작업이 저절로 진행되지는 않습니다. 오케스트레이터 (orchestrator)는 이슈를 다음 단계로 넘기기 전에 GitHub 상태, 워크트리 상태, 검증 기록, 그리고 리뷰 출력물을 다시 관찰(re-observes)합니다. 그렇지 않으면 작업은 재작업되거나, 차단되거나, 인간을 기다리게 됩니다.

이것이 중요한 이유는 프롬프트 규율 (prompt discipline)만으로는 스스로 확장(scale)될 수 없기 때문입니다. 에이전트에게 아키텍처를 준수하고, 더 나은 테스트를 작성하며, 커버리지를 유지하고, 검증을 우회하지 말라고 지시하는 명령어를 계속 추가할 수는 있습니다. 하지만 어느 시점에 이 지시어들은 소음 (noise)이 됩니다. 표준이 중요하다면, 그것은 확인 가능해야 하며 강제되어야 합니다.

Issue-Orchestrator는 GitHub 이슈 (Issues)와 마일스톤 (Milestones)을 외부 작업 시스템으로 사용합니다. 거대한 목표는 마일스톤이 됩니다. 마일스톤은 인간이 처리할 수 있는 규모의 이슈가 됩니다. 이슈에는 수락 기준 (Acceptance Criteria), 레이블 (Labels), 의존성 (Dependencies), 그리고 에이전트가 프로젝트 계획을 즉석에서 임의로 만들어내지 않고도 제한된 범위의 작업을 시도할 수 있을 만큼 충분한 컨텍스트 (Context)가 포함됩니다.

대시보드 아래에서, 실행 중인 각 이슈는 강제된 워크플로 (Workflow)입니다. 오케스트레이터 (Orchestrator)는 코딩, 검증 (Validation), 리뷰 (Review) 단계로 작업을 위임하지만, 상태 전이 (State Transitions)를 관리합니다. 에이전트는 작업물을 생성할 수 있습니다. 시스템은 그 작업물이 다음 단계로 진행될 수 있는지 여부를 결정합니다.

이것은 완전히 자율적인 코딩 시스템도 아니며, 단순한 프롬프트 (Prompt) 모음도 아닙니다. 이는 에이전트 기반의 소프트웨어 개발을 실제 소프트웨어 엔지니어링 (Software Engineering)과 더 유사하게 만들려는 시도입니다: 명시적인 표준, 기계적 검사, 복구 가능한 상태, 검사 가능한 산출물 (Artifacts), 그리고 머지 (Merge) 단계에서의 인간의 참여를 포함합니다.

이 프로젝트는 Apache 2.0 라이선스 하에 오픈 소스로 공개되어 있습니다:

https://github.com/BruceBGordon/issue-orchestrator

상태: 초기 베타 (Early Beta). 핵심 오케스트레이션, 가드레일 (Guardrails), 리뷰 워크플로, 대시보드는 매일 사용되고 있으며, 외부 설정 부분은 여전히 강화 작업 중입니다.

만약 실제 저장소 (Repos)에서 코딩 에이전트를 사용하고 계신다면, 여러분은 동일한 문제를 어떻게 처리하고 계신지 궁금합니다. 무엇을 기계적으로 강제하고 계신가요? 무엇을 리뷰에 맡기고 계신가요? 그리고 에이전트가 여전히 시스템을 조용히 침식하고 있는 지점은 어디인가요?