오픈소스 orchestration 스펙: Symphony

6 개월 전, 내부 생산성 도구를 개발하던 중 우리 팀은 당시 논란이 된 결정을 내렸습니다. 우리는 인간이 작성한 코드가 없는 저장소를 구축하기로 했습니다. 프로젝트 저장소의 모든 줄은 Codex 에 의해 생성되어야 했습니다.

이를 가능하게 하기 위해 우리는 엔지니어링 워크플로우를 처음부터 다시 설계했습니다. 에이전트 친화적 저장소를 구축하고, 자동화된 테스트와 가이드레일을 투자했으며, Codex 를 완전한 팀원으로 대했습니다. 우리는 이전 블로그 포스트 (harness engineering) 에서 이 여정을 문서화했습니다.

그것은 작동했지만, 다음 병목 현상에 부딪혔습니다: 컨텍스트 전환.

이 새로운 문제를 해결하기 위해 우리는 Symphony 라는 시스템을 구축했습니다. Symphony(opens in a new window) 는 Linear 와 같은 프로젝트 관리 보드를 코딩 에이전트의 제어 평면으로 변환하는 에이전트 오케스트레이터입니다. 모든 열린 작업에는 에이전트가 할당되며, 에이전트는 지속적으로 실행되고 인간은 결과를 검토합니다.

이 포스트는 Symphony 를 어떻게 생성했는지 설명하며 (어떤 팀에서는 500% 증가한 landed pull requests), 이를 사용하여 자신의 issue tracker 를 항상 켜진 오케스트레이터로 만드는 방법을 설명합니다.

상호작용 코딩 에이전트의 한계

사용법이 쉬워지더라도, 웹 앱이나 CLI 를 통해 액세스되는 코딩 에이전트는 여전히 상호작용 도구입니다.

OpenAI 에서 에이전트 작업의 규모가 커짐에 따라 우리는 새로운 형태의 부담을 발견했습니다. 각 엔지니어는 몇 개의 Codex 세션을 열고 작업을 할당하고 출력을 검토하며 에이전트를 방향지시하고 반복했습니다. 실제로 대부분의 사람들은 컨텍스트 전환이 고통스러워지기 전에 한 번에 3~5 개의 세션을 편안하게 관리할 수 있었습니다. 그 이상이면 생산성은 떨어졌습니다. 우리는 어떤 세션이 무엇을 하는지 잊고, 에이전트를 원래 궤도로 되돌리도록 터미널을 이동하며, 중간에 멈췄던 장기 실행 작업을 디버깅했습니다.

에이전트는 빠르지만, 우리는 인간 주의력이라는 시스템 병목 현상을 가지고 있었습니다. 우리는 매우 능숙한 저급 엔지니어 팀을 구축하고, 그들을 마이크로 관리하는 방식으로 우리 인간 엔지니어를 할당했습니다. 이는 확장되지 않았습니다.

관점의 전환

우리가 잘못된 것을 최적화하고 있다는 것을 깨달았습니다. 우리는 PR 과 세션을 중심으로 시스템을 방향지시했지만, PR 과 세션은 실제로 목적수단에 불과합니다. 소프트웨어 워크플로우는 대부분 deliverables 에 기반하여 조직됩니다: 이슈, 작업, 티켓, 마일스톤.

따라서 우리가 에이전트를 직접 감독하는 대신 우리 작업 추적기에서 작업을 끌어들이게 했다면 어떤 일이 일어날지 스스로에게 물었습니다.

이 아이디어는 Symphony 가 되었습니다. 이는 오케스트레이션된 에이전트 작업을 감독자로 기능하는 문서화된 스펙입니다.

Issue tracker 를 오케스트레이터로 전환

Symphony 는 간단한 개념으로 시작했습니다: 열린 작업은 반드시 에이전트에 의해 취해지고 완료되어야 합니다. 여러 탭에서 Codex 세션을 관리하는 대신, 우리는 issue tracker 를 제어 평면으로 만들었습니다.

이 설정에서, 각 열린 Linear 이슈는 전용 에이전트 워크스페이스에 매핑됩니다. Symphony 는 지속적으로 작업 보드를 감시하며, 모든 활성 작업이 수행될 때까지 루프 내에서 에이전트가 실행되도록 보장합니다. 에이전트가 충돌하거나 멈추면 Symphony 는 이를 재시작합니다. 새로운 작업이 나타나면 Symphony 는 이를 취하고 작업을 조직합니다.

우리는 티켓 상태에 기반하여 워크플로우를 구축했으며, 작업 관리자 Linear 를 상태 기계로 사용했습니다.

실제로 Symphony 는 작업을 세션과 PR 에서 분리했습니다. 일부 이슈는 여러 저장소에 걸쳐 여러 PR 을 생성하며, 다른 것은 코드베이스를 만지지 않는 순수 조사나 분석입니다.

이렇게 작업이 추상화되면 티켓은 훨씬 더 큰 작업 단위를 나타낼 수 있습니다.

우리는 정기적으로 복잡한 기능과 인프라 마이그레이션을 오케스트레이션하기 위해 Symphony 를 사용합니다. 예를 들어, 우리는 에이전트에게 코드베이스, Slack 또는 Notion 을 분석하고 구현 계획을 생성하도록 요청하는 작업을 제출할 수 있습니다. 우리가 계획에 만족하면 에이전트는 작업 단계를 나누고 작업 간 의존성을 정의하는 작업의 트리를 생성합니다.

에이전트는 막힌 작업이 아닌 작업에만 시작하므로 실행은 자연스럽게 최적적으로 병렬로 진행됩니다 (DAG - 순서)