저는 오랫동안 XP/TDD (Extreme Programming/Test-Driven Development) 스타일로 작업해 왔기에, AI 코딩 도구들이 실제 업무에 유용할 정도로 발전했을 때 빠르게 도입했습니다. 제가 마주한 첫 번째 병목 현상은 코드 생성 (code generation)이 아니라 검증 (verification)이었습니다. AI는 코드와 테스트를 빠르게 작성할 수 있었지만, 구현 내용을 검토하고, 흐름을 클릭하며 확인하고, 로그를 점검하고, 데이터베이스 (database) 상태를 조사하며, 결과가 실제로 정확한지 결정하는 역할은 여전히 저의 몫이었습니다.

이로 인해 저는 검증 과정을 더 앞 단계로 옮기게 (move validation further left) 되었습니다. 구현 전에는 AI가 테스트 계획 (test plans)을 생성해야 했고, 구현 후에는 그 계획을 직접 실행해야 했습니다. 즉, 브라우저를 구동하고, 로그를 조사하며, DB 상태를 확인하고, 실패에 대한 티켓을 생성하고, 이를 수정하며, 결과가 수렴할 때까지 재테스트를 수행하는 과정입니다. Auth9 (https://github.com/c9r-io/auth9)는 이러한 방식을 검증하는 시험장이 되었습니다. 이 방법이 확실히 작동한다는 것을 확인한 후, 저는 프로세스가 제가 모든 단계를 수동으로 감독하는 것에 의존하지 않도록 Agent Orchestrator를 구축하기 시작했습니다.

2월 중순쯤, 저는 이미 Auth9 내부에서 초기 Orchestrator 스타일의 자동화를 사용하고 있었습니다. 3월 중순에는 지금까지 중 가장 위험도가 높았던 리팩터링(refactor), 즉 헤드리스(headless) Keycloak 설정을 네이티브 auth9-oidc 엔진으로 교체하는 작업 중에 이를 사용했습니다. 핵심 교체 작업은 3일에 걸쳐 완료되었으며, 동일한 방식과 도구를 통해 후속 기술 부채 (technical debt)를 해결하고 이달 말까지 커뮤니티 OIDC 인증 테스트를 완료할 수 있었습니다. 그때 저는 이 방식이 신규 프로젝트 (greenfield work)뿐만 아니라 실제 시스템에서 위험도가 높은 변경 사항을 관리 (governing)하는 데에도 유용하다는 확신을 갖게 되었습니다.

당시 제가 가장 중요하게 생각했던 단어는 "오케스트레이션 (orchestration)"이었고, 그것이 프로젝트의 이름이 된 이유입니다. 나중에 OpenAI의 Harness Engineering 프레임워크를 접하며 이 작업의 더 넓은 형태를 나타내는 더 나은 이름을 찾게 되었습니다. 현재 이 프로젝트는 장기 실행되는 에이전트 워크플로 (agent workflows)를 위한 로컬 우선 (local-first) Rust 제어 평면 (control plane)입니다. YAML 리소스, SQLite 기반의 작업 상태 (task state), 기계 판독 가능한 CLI 출력, 구조화된 로그, 그리고 셸(shell) 기반 에이전트를 위한 가드레일 (guardrails)을 제공합니다.

• GitHub: https://github.com/c9r-io/orchestrator
• Docs: https://docs.c9r.io
• Auth9: https://github.com/c9r-io/auth9
• 설치: brew install c9r-io/tap/orchestrator 또는 cargo install orchestrator-cli orchestratord
• 라이선스: MIT