🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

📰 An open-source spec for Codex orchestration: Symphony

💡 한 줄 요약

OpenAI의 Symphony는 Linear 같은 이슈 트래커를 코딩 에이전트의 상시 오케스트레이션 제어판으로 바꿔, 인간의 세션 관리 부담을 줄이고 작업 단위 중심으로 에이전트가 병렬 실행되도록 만든 오픈소스 명세입니다.

📌 핵심 요약

• OpenAI 팀은 내부 생산성 도구를 만들며 저장소의 모든 코드를 Codex가 생성하도록 하는 실험을 진행했고, 이를 위해 에이전트 친화적 저장소, 자동화 테스트, 가드레일, Codex를 팀원처럼 다루는 워크플로를 구축했다.
• 초기 방식은 효과가 있었지만, 엔지니어가 여러 Codex 세션을 직접 열고 지시·검토·수정하는 과정에서 컨텍스트 전환 부담이 커졌고, 보통 3~5개 세션을 넘어서면 생산성이 떨어지는 병목이 드러났다.
• Symphony는 이 문제를 해결하기 위해 이슈 트래커를 제어판으로 삼아 각 열린 Linear 이슈에 전용 에이전트 워크스페이스를 매핑하고, 에이전트가 충돌하거나 멈추면 재시작하며, 새 작업이 생기면 자동으로 실행하도록 설계됐다.
• 작업을 세션이나 PR이 아니라 티켓과 deliverable 중심으로 추상화하자, 하나의 이슈가 여러 저장소의 PR을 만들 수도 있고, 코드 변경 없는 조사·분석 작업도 포함할 수 있게 되었으며, 복잡한 기능 개발과 인프라 마이그레이션도 DAG 형태로 병렬 진행할 수 있게 됐다.
• Symphony 도입 뒤 일부 OpenAI 팀에서는 첫 3주 동안 랜딩된 PR 수가 500% 증가했고, 엔지니어는 반복 구현과 CI·리베이스·충돌 처리 같은 마지막 구간을 덜 직접 관리하면서 더 어렵고 탐색적인 문제에 집중하게 됐다.

🧩 주요 포인트

1. OpenAI 팀은 내부 생산성 도구를 만들며 저장소의 모든 코드를 Codex가 생성하도록 하는 실험을 진행했고, 이를 위해 에이전트 친화적 저장소, 자동화 테스트, 가드레일, Codex를 팀원처럼 다루는 워크플로를 구축했다.
2. 초기 방식은 효과가 있었지만, 엔지니어가 여러 Codex 세션을 직접 열고 지시·검토·수정하는 과정에서 컨텍스트 전환 부담이 커졌고, 보통 3~5개 세션을 넘어서면 생산성이 떨어지는 병목이 드러났다.
3. Symphony는 이 문제를 해결하기 위해 이슈 트래커를 제어판으로 삼아 각 열린 Linear 이슈에 전용 에이전트 워크스페이스를 매핑하고, 에이전트가 충돌하거나 멈추면 재시작하며, 새 작업이 생기면 자동으로 실행하도록 설계됐다.
4. 작업을 세션이나 PR이 아니라 티켓과 deliverable 중심으로 추상화하자, 하나의 이슈가 여러 저장소의 PR을 만들 수도 있고, 코드 변경 없는 조사·분석 작업도 포함할 수 있게 되었으며, 복잡한 기능 개발과 인프라 마이그레이션도 DAG 형태로 병렬 진행할 수 있게 됐다.
5. Symphony 도입 뒤 일부 OpenAI 팀에서는 첫 3주 동안 랜딩된 PR 수가 500% 증가했고, 엔지니어는 반복 구현과 CI·리베이스·충돌 처리 같은 마지막 구간을 덜 직접 관리하면서 더 어렵고 탐색적인 문제에 집중하게 됐다.

🧠 상세 정리

1. Codex만으로 저장소를 만드는 실험에서 출발한 문제

글은 OpenAI 팀이 6개월 전 내부 생산성 도구를 만들면서 내린 과감한 결정에서 시작한다. 이들은 프로젝트 저장소의 모든 코드를 사람이 직접 쓰지 않고 Codex가 생성하도록 하기로 했다. 이를 가능하게 하려면 단순히 에이전트에게 코드를 맡기는 수준이 아니라, 저장소 구조와 개발 절차 자체를 에이전트가 일하기 좋은 방식으로 다시 설계해야 했다. 그래서 자동화 테스트와 가드레일에 크게 투자하고, Codex를 일회성 도구가 아니라 실제 동료처럼 취급하는 워크플로를 만들었다. 이 접근은 효과가 있었지만, 성공 이후에는 코드 생성 능력이 아니라 사람이 여러 에이전트 작업을 관리하는 방식이 새로운 병목으로 떠올랐다.

2. 인터랙티브 코딩 에이전트의 한계와 인간 주의력 병목

OpenAI가 관찰한 핵심 문제는 코딩 에이전트가 아무리 빨라져도 웹앱이나 CLI를 통해 쓰는 방식은 여전히 인터랙티브 도구에 가깝다는 점이었다. 엔지니어는 여러 Codex 세션을 열고, 각 세션에 일을 맡기고, 결과를 검토하고, 다시 방향을 조정하는 일을 반복해야 했다. 실제로 대부분의 사람은 3~5개 세션 정도까지는 편하게 관리할 수 있었지만, 그 이상이 되면 어떤 세션이 무엇을 하는지 잊거나 터미널을 오가며 에이전트를 다시 궤도에 올려야 했다. 장시간 실행되는 작업이 중간에 멈추면 이를 디버깅하는 부담도 생겼다. 결국 에이전트의 속도가 아니라 인간의 주의력과 컨텍스트 전환 비용이 시스템 전체의 확장성을 제한했다.

3. 세션과 PR이 아니라 작업 단위로 관점을 전환

팀은 자신들이 잘못된 대상을 최적화하고 있다는 점을 깨달았다. 기존에는 코딩 세션과 병합된 PR을 중심으로 시스템을 바라봤지만, 실제 소프트웨어 워크플로는 대체로 이슈, 태스크, 티켓, 마일스톤 같은 deliverable을 기준으로 조직된다. PR과 세션은 목적 자체가 아니라 작업을 끝내기 위한 수단에 가깝다. 그래서 팀은 사람이 에이전트를 직접 감독하는 대신, 에이전트가 작업 추적기에서 일을 가져가도록 만들면 어떤 변화가 생길지 질문했다. 이 관점 전환이 Symphony의 출발점이 되었고, Symphony는 에이전트 작업을 감독하고 조율하는 written spec으로 정의됐다.

4. Linear 이슈 트래커를 에이전트 오케스트레이터로 바꾸는 방식

Symphony의 기본 개념은 열린 작업은 에이전트가 가져가 완료해야 한다는 것이다. 여러 탭이나 터미널에서 Codex 세션을 직접 관리하는 대신, 팀은 Linear 같은 이슈 트래커를 제어판으로 삼았다. 각 열린 Linear 이슈는 전용 에이전트 워크스페이스에 매핑되고, Symphony는 작업 보드를 계속 감시하면서 활성 태스크마다 에이전트가 실행 중인지 확인한다. 에이전트가 충돌하거나 멈추면 Symphony가 다시 시작하고, 새 작업이 나타나면 이를 감지해 실행을 조직한다. 이 구조에서는 티켓 상태가 일종의 상태 머신 역할을 하며, 작업의 진행과 재시도, 중단, 완료가 이슈 트래커의 흐름과 연결된다.

5. 티켓 중심 추상화가 만드는 더 큰 작업 단위

Symphony는 작업을 세션과 PR로부터 분리한다. 어떤 이슈는 여러 저장소에 걸친 여러 PR을 만들 수 있고, 어떤 이슈는 코드베이스를 전혀 건드리지 않는 조사나 분석으로 끝날 수도 있다. 작업을 이렇게 추상화하면 티켓은 훨씬 큰 단위의 일을 표현할 수 있다. OpenAI 팀은 Symphony를 복잡한 기능 개발이나 인프라 마이그레이션을 조율하는 데 정기적으로 사용한다고 설명한다. 예를 들어 에이전트에게 코드베이스, Slack, Notion을 분석해 구현 계획을 만들라고 요청하고, 그 계획이 적절하다고 판단되면 에이전트가 작업 트리를 생성해 단계와 의존성을 나눌 수 있다. 이후 차단되지 않은 작업부터 에이전트가 실행하므로 DAG 형태의 작업이 자연스럽게 병렬로 진행된다.

6. 탐색 비용 하락과 작업 시작 주체의 확장

Symphony 방식의 가장 눈에 띄는 효과는 산출량 증가였지만, 글은 더 깊은 변화가 팀이 일을 바라보는 방식에 있었다고 설명한다. 엔지니어가 Codex 세션을 직접 감독하는 데 시간을 쓰지 않게 되자, 코드 변경의 체감 비용이 크게 낮아졌다. 아이디어를 시도하거나 리팩터링을 탐색하거나 가설을 테스트하는 speculative task를 가볍게 만들고, 유망한 결과만 남기는 방식이 쉬워졌다. 또한 작업을 시작할 수 있는 사람의 범위도 넓어졌다. 제품 매니저나 디자이너도 저장소를 체크아웃하거나 Codex 세션을 직접 관리하지 않고 기능 요청을 Symphony에 넣을 수 있으며, 실제 제품 안에서 기능이 동작하는 모습을 담은 비디오 워크스루가 포함된 review packet을 받을 수 있다.

7. 대형 모노레포와 PR 랜딩 과정에서의 운영 효과

Symphony는 OpenAI처럼 큰 모노레포를 사용하는 환경에서 특히 강점을 보인다고 설명된다. 이런 환경에서는 PR을 실제로 메인 브랜치에 랜딩시키는 마지막 단계가 느리고 취약할 수 있다. Symphony는 CI를 지켜보고, 필요할 때 리베이스하며, 충돌을 해결하고, flaky check를 재시도하면서 변경이 파이프라인을 통과하도록 돌본다. 그래서 티켓이 Merging 상태에 도달할 때쯤에는 사람이 계속 지켜보지 않아도 변경이 메인 브랜치에 들어갈 가능성이 높다는 확신을 가질 수 있다. 글에 따르면 일부 OpenAI 팀에서는 Symphony 도입 후 첫 3주 동안 랜딩된 PR 수가 500% 증가했다. 이 수치보다 중요한 변화는 엔지니어가 반복 구현을 더 많이 위임하고, 더 어렵고 탐색적인 문제에 집중하게 되었다는 점이다.

8. 상시 오케스트레이션이 가져온 새 문제와 대응

글은 Symphony가 모든 문제를 없애는 것이 아니라 다른 종류의 문제를 만든다고도 말한다. 사람이 에이전트를 실시간으로 조종하던 방식에서 티켓 단위로 일을 맡기는 방식으로 바뀌면서, 중간에 계속 방향을 수정하고 세밀하게 개입하는 능력은 줄어들었다. 때로는 에이전트가 완전히 빗나간 결과를 만들기도 했지만, 팀은 이를 단순 실패가 아니라 시스템의 빈틈을 드러내는 유용한 정보로 보았다. 결과물을 사람이 수동으로 고치는 대신, 다음번에는 에이전트가 성공할 수 있도록 가드레일과 스킬을 추가했다. 그 과정에서 엔드투엔드 테스트 실행, Chrome DevTools를 통한 앱 조작, QA smoke test 관리 같은 기능이 harness에 추가됐고, 문서화와 성공 기준도 더 명확해졌다.

9. 엄격한 상태 머신보다 목표와 도구를 주는 방향

OpenAI 팀은 모든 작업이 Symphony 방식에 적합한 것은 아니라고 인정한다. 특히 강한 판단력과 전문성이 필요한 모호한 문제는 여전히 엔지니어가 인터랙티브 Codex 세션으로 직접 다루는 편이 낫고, 이런 작업이 오히려 엔지니어에게 가장 흥미로운 일이라고 설명한다. 동시에 팀은 에이전트를 딱딱한 상태 머신의 노드처럼 취급하는 방식도 잘 작동하지 않는다는 점을 배웠다. 초기에는 Codex에게 단순 구현만 요청했지만, 모델은 여러 PR을 만들고 리뷰 피드백을 읽고 반영하는 등 더 큰 문제를 풀 수 있었다. 그래서 gh CLI, CI 로그를 읽는 스킬 같은 도구를 제공하고, 오래된 PR 닫기나 완료·중단 작업 보고서 작성 같은 일도 맡기게 됐다. 결론적으로 팀은 엄격한 전이보다 목표를 주는 방식, 즉 좋은 관리자가 팀원에게 목표를 맡기는 방식에 더 가까워졌다고 설명한다.

10. Symphony 자체도 SPEC.md 중심의 명세로 구성

글의 후반부는 Symphony 저장소를 열면 가장 먼저 보이는 것이 복잡한 감독 시스템이 아니라 SPEC.md 파일이라는 점을 강조한다. Symphony는 문제와 의도한 해결책을 정의하는 명세이며, 에이전트에게 높은 수준의 방향을 주는 방식으로 설계됐다. 명세에 따르면 Symphony는 이슈 트래커를 계속 읽고, 각 이슈마다 격리된 워크스페이스를 만들며, 그 안에서 코딩 에이전트 세션을 실행하는 장기 실행 자동화 서비스다. 요구사항에는 고정 주기로 이슈 트래커를 폴링하고, 제한된 동시성으로 작업을 배치하며, 결정적 per-issue 워크스페이스를 만들고, 일시적 실패를 exponential backoff로 복구하는 내용이 포함된다. 반면 특정 대시보드나 범용 워크플로 엔진, 티켓·PR·댓글 편집 방식의 내장 비즈니스 로직, 단일한 샌드박스 정책을 강제하지 않는다는 점도 명시된다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 코딩 에이전트의 성능 문제가 더 이상 코드 생성 자체에만 있지 않고, 여러 에이전트가 수행하는 작업을 어떻게 관리·관찰·복구할 것인가로 이동하고 있다는 점이다.
• Symphony가 이슈 트래커를 제어판으로 삼은 것은 개발 조직이 이미 사용하는 deliverable 중심 구조를 그대로 활용해, 에이전트 워크플로를 별도 도구가 아니라 기존 업무 흐름 안으로 끌어들인 선택으로 볼 수 있다.
• OpenAI 팀이 실패한 에이전트 결과를 수동 수정하지 않고 가드레일·스킬·문서 개선으로 되돌린 점은, 에이전트 운영에서 개별 결과물보다 반복 가능한 시스템 학습과 워크플로 품질이 더 중요해지고 있음을 보여준다.

✅ 액션 아이템

• Symphony가 Linear 같은 issue tracker를 coding agent control plane으로 바꾸는 구조를 팀의 기존 ticket workflow에 매핑해 본다.
• 사람이 Codex 세션을 직접 관리할 때의 3~5개 세션 한계와 Symphony의 always-on orchestration이 줄이는 context switching 비용을 비교한다.
• agent-friendly repository, automated tests, guardrails, Chrome DevTools, QA smoke tests처럼 Symphony 운영에 필요한 기반을 체크리스트로 정리한다.
• 500% landed PR 증가라는 성과를 산출량뿐 아니라 review packet 품질, CI 안정성, 실패 복구 방식까지 포함해 평가한다.

❓ 열린 질문

• Issue tracker를 agent control plane으로 쓰면 어떤 작업은 티켓 단위로 맡기고, 어떤 작업은 여전히 interactive Codex session으로 다뤄야 할까?
• Symphony처럼 agent가 여러 PR과 후속 issue를 만들 수 있을 때 human review와 merge authority는 어디에서 강하게 유지해야 할까?
• 실패 결과를 사람이 직접 고치는 대신 guardrail과 skill 개선으로 되돌리는 방식은 어느 정도 규모의 팀부터 효과가 커질까?
• SPEC.md 중심의 lightweight orchestrator 설계가 복잡한 workflow engine보다 나은 조건과 한계는 무엇일까?