배경 및 맥락

코딩 에이전트의 초기 도입은 대부분 사람이 여러 세션을 직접 띄워 놓고 지시하고 점검하는 방식이었다. 이 접근은 데모 단계에서는 인상적이지만, 팀 단위로 확장되면 사람의 attention이 금세 병목이 된다. 세션이 늘수록 누가 무엇을 하고 있는지 추적 비용이 커지고, long-running task가 멈췄을 때 복구도 수동으로 이뤄져야 한다.

OpenAI가 공개한 Symphony는 이 문제를 작업 단위 재설계로 풀려는 접근이다. 세션을 중심으로 agent를 운영하는 대신, issue tracker를 state machine이자 control plane으로 삼아 각 티켓마다 agent workspace와 실행 루프를 붙이는 식이다.

---

핵심 내용

OpenAI는 2026년 4월 27일 Engineering 포스트를 통해 Symphony를 소개했다. Symphony는 제품이 아니라 spec 중심의 orchestration layer로, Linear 같은 issue tracker를 읽어 active task마다 전용 workspace를 만들고 agent를 계속 돌린다. agent가 멈추거나 실패하면 재시도하고, 작업 상태가 바뀌면 정지·재조정하며, 성공 시에는 Human Review 같은 workflow-defined handoff state로 넘긴다.

OpenAI 설명에 따르면 팀은 기존에 각 엔지니어가 3~5개의 Codex 세션 정도만 편하게 관리할 수 있었지만, Symphony 도입 후 일부 팀에서는 landed PR 수가 500% 증가했다. 공개된 spec은 WORKFLOW.md 기반 정책 로딩, typed config, issue tracker client, orchestrator, workspace manager, agent runner, observability 레이어를 분리하고, restart recovery와 retry queue 같은 운영 요소까지 포함한다.

---

경쟁 구도 / 비교

대부분의 코딩 에이전트 논의는 모델 성능이나 IDE 통합에 집중돼 왔다. Symphony가 보여주는 차별점은 agent를 더 똑똑하게 만드는 대신, agent가 안전하고 반복 가능하게 일할 운영 체계를 스펙화했다는 점이다. 이 접근은 단일 Copilot형 보조보다 훨씬 시스템적이며, agent-friendly repo 설계와 harness engineering을 전제로 한다.

또한 Symphony는 티켓을 더 큰 실행 단위로 취급해 분석, 계획 수립, 복수 PR 생성, CI 관찰, 후속 이슈 생성까지 포함할 수 있게 한다. 이는 코딩 에이전트가 편집기 안의 assistant에서 backlog를 소화하는 준-운영 시스템으로 옮겨가고 있음을 보여준다.

---

의미

이 뉴스의 핵심 의미는 에이전트 시대의 생산성 함수가 모델 IQ만으로 결정되지 않는다는 점이다. repo 구조, 문서화 품질, 테스트 자동화, handoff state, observability, retry 설계가 실제 산출량을 좌우한다. 앞으로는 '어떤 모델을 쓰는가' 못지않게 '어떤 orchestration contract 위에서 돌리는가'가 팀 경쟁력이 될 가능성이 크다.

실무적으로는 에이전트 도입팀이 세션 수를 늘리는 것보다 운영 프로토콜을 먼저 표준화해야 한다. 적절한 workflow contract와 guardrail 없이 병렬 agent를 늘리면 성과보다 감독 비용이 더 빨리 증가할 수 있다.