Codex를 3~5개 병렬로 돌리면 어느 순간부터 에이전트보다 사람이 더 바빠집니다. 어느 탭이 막혔는지 확인하고, 멈춘 에이전트를 재시작하고, 컨텍스트를 다시 집어넣는 일이 반복됩니다. AI가 빠를수록 그걸 감독하는 사람이 병목이 되는 아이러니가 생기죠.
OpenAI가 이 문제를 정면으로 다룬 오픈소스 스펙을 공개했습니다. 이름은 Symphony. Linear 같은 이슈 트래커와 Codex를 직접 연결해, 열려 있는 티켓마다 자동으로 에이전트를 붙이고 작업이 완료될 때까지 관리하는 오케스트레이션 레이어입니다.
출처: An open-source spec for Codex orchestration: Symphony – OpenAI
에이전트를 감독하는 대신, 일을 관리한다
Symphony의 핵심 발상은 단순합니다. “열려 있는 모든 작업에는 항상 에이전트가 붙어 있어야 한다.”
지금까지 Codex를 팀 단위로 쓰려면 누군가가 계속 세션을 열어두고 지켜봐야 했습니다. 에이전트가 멈추면 재시작하고, 새 티켓이 생기면 세션을 새로 만들고, PR이 리뷰 단계에 걸리면 수동으로 확인해야 했죠. Symphony는 이 감독 역할을 오케스트레이터에게 맡깁니다.
작동 흐름은 이렇습니다.
- Symphony가 Linear 보드를 폴링하면서 활성화된 이슈를 감지합니다.
- 이슈마다 격리된 워크스페이스를 만들고 Codex 에이전트를 스폰합니다.
- 에이전트가 PR 생성, CI 감시, 리뷰 패킷 준비까지 자율적으로 처리합니다.
- 에이전트가 멈추거나 오류가 나면 오케스트레이터가 자동으로 재시작합니다.
- 티켓 상태가 ‘Human Review’나 ‘Done’으로 바뀌면 해당 에이전트가 종료됩니다.
엔지니어가 보는 건 완성된 PR과 CI 결과, 그리고 에이전트가 준비한 리뷰 패킷뿐입니다. Codex 세션을 열지 않아도 됩니다.
제품이 아닌 스펙으로 공개한 이유
Symphony는 제품으로 출시된 게 아닙니다. OpenAI 스스로 “낮은 강도의 엔지니어링 프리뷰”라고 표현했고, GitHub에 올린 것도 실행 파일이 아닌 SPEC.md — 명세서입니다.
이 접근이 흥미로운 이유는 메타적입니다. OpenAI 팀은 스펙을 쓰고, Codex에게 “이 스펙으로 Symphony를 구현해줘”라고 시켜 TypeScript, Go, Rust, Java, Python 버전을 동시에 만들었습니다. 스펙의 모호한 부분은 구현 과정에서 드러났고, 그 피드백으로 스펙을 다듬었죠. Symphony 자체가 Symphony 방식으로 만들어진 셈입니다.
어떤 언어 스택이든 SPEC.md를 읽고 직접 구현하거나, Codex에게 구현을 맡길 수 있습니다. Elixir 기반의 레퍼런스 구현도 레포에 포함되어 있습니다.
워크플로우 정책은 코드베이스가 직접 정의한다
Symphony에서 에이전트가 어떻게 일할지는 각 레포가 직접 정의합니다. WORKFLOW.md 파일에 이슈 트래커 설정, 폴링 주기, 에이전트 동작 방식을 담아두면, Symphony가 이 파일을 읽어 에이전트를 설정합니다. 파일이 바뀌면 재시작 없이 다음 폴링 사이클부터 바로 반영됩니다.
에이전트가 Linear에 댓글을 달거나 PR을 열거나 상태를 바꾸는 것도 모두 WORKFLOW.md에 정의된 도구를 통해 이루어집니다. Symphony 오케스트레이터 자체는 Linear에 직접 쓰지 않습니다. 어떤 작업을 어떻게 할지에 대한 정책은 코드베이스 안에 있고, 오케스트레이터는 그 정책을 실행하는 런타임 역할만 합니다.
에이전트 시대의 다음 단계
OpenAI는 Symphony를 “harness engineering의 다음 단계”로 위치시킵니다. 에이전트가 실수 없이 작동하려면 자동화된 테스트, 명확한 가드레일, 에이전트 친화적인 레포 구조가 먼저 갖춰져 있어야 합니다. Symphony는 그 위에 얹는 레이어입니다.
OpenAI 내부에서 Symphony를 도입한 일부 팀은 3주 만에 머지된 PR이 500% 늘었다고 했습니다. 에이전트 속도보다 감독 비용이 더 컸다는 걸 보여주는 수치입니다. Symphony가 그 감독 비용을 오케스트레이터에게 이전한 결과입니다.
참고자료:
답글 남기기