코딩 에이전트가 빨라질수록 새로운 병목이 생긴다. 바로 인간의 주의력이다. Symphony는 이 병목을 해결하기 위해 OpenAI 팀이 내부 생산성 도구를 만들면서 개발한 시스템으로, 2026년 4월 27일 오픈소스 스펙으로 공개됐다. Linear 같은 이슈 트래커를 제어 평면으로 삼아 모든 오픈 태스크에 에이전트를 자동 할당하고, 사람은 세션을 감독하는 대신 작업을 관리한다.

왜 만들었나

OpenAI 팀은 먼저 agent-harness 엔지니어링으로 “인간 코드 없는 저장소”를 구현했다. 다음 병목은 컨텍스트 전환(context switching)이었다. 엔지니어 한 명이 동시에 관리할 수 있는 Codex 세션은 3~5개 수준이었고, 그 이상에서는 생산성이 오히려 감소했다. 에이전트팀은 있었지만 에이전트를 미세 감독(micromanage)하는 구조가 병목이 됐다.

동작 원리

Symphony는 SPEC.md 파일로 정의된 긴 실행 자동화 서비스다. 실제 로직보다 스펙이 핵심으로, 에이전트가 스펙을 읽고 구현한다.

1. 이슈 트래커 감시: Linear(또는 다른 트래커) 보드를 지속 모니터링
2. 워크스페이스 격리: 오픈 이슈마다 독립 워크스페이스 생성 후 에이전트 실행
3. 상태 머신: 티켓 상태(In Progress → Review → Merging)를 제어 흐름으로 사용
4. DAG 실행: 이슈 간 의존성 정의 → 비차단 태스크를 병렬 실행
5. CI 감시: CI 결과 확인, 리베이스, 충돌 해결, 재시도까지 에이전트가 처리

# Option 1: 에이전트에게 SPEC.md 기반 구현 위임
# "Implement Symphony according to: github.com/openai/symphony/blob/main/SPEC.md"

# Option 2: 제공된 Elixir 참조 구현 사용
# github.com/openai/symphony — elixir/README.md 참조

주요 성과

• PR 머지 건수 500% 증가 — 일부 OpenAI 팀 첫 3주 데이터
• 탐색적 작업 비용 제로화 — 티켓을 파일링하면 에이전트가 자동 처리, 결과만 검토
• PM·디자이너가 직접 기능 요청 — 저장소 체크아웃 없이 Linear에 티켓 작성만으로 기능 구현
• 코드 리뷰·워크스루 영상 자동 생성 — 에이전트가 증거(proof of work)와 함께 PR 제출

하네스 엔지니어링과의 관계

Symphony는 하네스 엔지니어링의 다음 단계다. 하네스가 “어떻게 에이전트를 실행할 것인가”를 정의한다면, Symphony는 “어떤 작업을 에이전트에게 줄 것인가”를 관리한다.

Symphony는 하네스가 잘 갖춰진 코드베이스에서 가장 효과적으로 동작한다. 자동화된 테스트, 명확한 AGENTS.md, CI 파이프라인이 전제 조건이다.

중요한 교훈

에이전트를 엄격한 상태 머신의 노드로만 대하면 한계가 생긴다. OpenAI 팀은 초기에 “구현만 하라”고 지시했다가 한계를 경험한 후, 목표(objective)를 주고 툴과 컨텍스트를 제공하는 방식으로 전환했다. 에이전트는 PR 생성, 코드 리뷰 피드백 반영, CI 로그 분석까지 스스로 수행할 수 있다.

사용 대상 및 케이스

라이선스

Apache 2.0

관련 문서

• agent-harness — Symphony가 요구하는 하네스 엔지니어링 기반
• codex — Symphony가 오케스트레이션하는 Codex 에이전트
• gastown — 멀티 에이전트 워크스페이스 관리자

참고 자료

• openai/symphony — GitHub 공식 저장소
• An open-source spec for Codex orchestration: Symphony — OpenAI (2026-04-27)