한눈에 보기

OpenAI가 2026년 4월 27일 An open-source spec for Codex orchestration: Symphony를 공개했습니다. 핵심은 Codex 같은 코딩 에이전트를 채팅창이나 터미널 세션 단위가 아니라 이슈 트래커 단위로 굴리겠다는 겁니다.

Symphony는 Linear 같은 프로젝트 관리 보드를 코딩 에이전트의 control plane으로 바꿉니다. 열린 작업마다 isolated workspace를 붙이고, 에이전트 실행, 재시작, retry, CI 상태 확인, 리뷰 흐름을 계속 추적합니다.

이건 단순히 "Codex를 더 많이 띄우자"는 이야기가 아닙니다. 개발팀의 일 관리 단위를 PR 하나나 세션 하나에서 티켓과 deliverable 중심으로 바꾸는 시도에 가깝습니다.

이번 발표 뭐가 나왔나

OpenAI는 Symphony를 오픈소스 spec이자 agent orchestrator로 설명합니다. 공식 글 기준 작성자는 Alex Kotliarskyi, Victor Zhu, Zach Brock입니다.

OpenAI가 말한 문제는 context switching입니다. 개발자가 Codex 세션을 여러 개 열고, 작업을 나눠 주고, 중간 결과를 확인하고, 실패한 세션을 다시 깨우는 방식은 어느 순간 사람의 주의력이 병목이 됩니다. OpenAI는 실제로 많은 사람이 3~5개 세션 정도를 넘어서면 부담이 커졌다고 설명합니다.

Symphony는 이 병목을 프로젝트 관리 보드 쪽으로 옮겨 풉니다. 사람이 세션을 직접 몰고 가는 대신, 열린 이슈가 agent workspace와 연결되고, orchestrator가 그 작업이 계속 진행되는지 지켜봅니다.

핵심 변화 3가지

1. 이슈 트래커가 agent control plane이 된다

Symphony에서 Linear 같은 이슈 보드는 단순한 할 일 목록이 아닙니다. 어떤 작업이 열려 있고, 어떤 작업이 막혀 있고, 어떤 작업이 리뷰 단계인지 판단하는 상태 머신에 가까워집니다.

각 open issue는 dedicated agent workspace와 연결됩니다. agent가 멈추거나 실패하면 Symphony가 다시 띄우고, 새 작업이 들어오면 가져가도록 만듭니다. 개발자는 개별 세션을 계속 감시하기보다 작업 단위와 결과물을 보는 쪽으로 이동합니다.

OpenAI Codex Symphony 작업 흐름

2. PR 하나가 아니라 deliverable 단위로 움직인다

OpenAI 공식 글에서 중요한 지점은 Symphony가 PR 중심 시스템만은 아니라는 점입니다. 어떤 이슈는 여러 repo에 걸친 여러 PR로 이어질 수 있고, 어떤 이슈는 코드 변경 없이 조사나 설계 리포트로 끝날 수 있습니다.

실제 개발팀 업무는 "PR 하나"보다 "버그 하나", "마이그레이션 한 단계", "분석 리포트 하나"처럼 deliverable 중심으로 굴러갈 때가 많습니다. Symphony는 에이전트를 그 deliverable에 붙입니다.

이 차이는 작지 않습니다. 코딩 에이전트가 잘 돌아가려면 모델 성능만큼이나 작업 정의, 테스트, 리뷰 기준, CI 흐름이 중요해지기 때문입니다.

3. 운영과 안전 장치가 같이 들어간다

GitHub openai/symphony 저장소의 SPEC.md는 Symphony를 장기 실행 automation service로 정의합니다. issue tracker를 읽고, issue별 workspace를 만들고, 그 안에서 coding agent session을 실행하는 구조입니다.

저장소에는 README.md, SPEC.md, Elixir 기반 reference implementation이 포함되어 있고, 라이선스는 Apache-2.0입니다. 다만 GitHub README는 Symphony를 trusted environment에서 테스트하기 위한 engineering preview로 설명합니다.

즉 바로 "아무 팀이나 켜면 끝"인 제품이라기보다는, 에이전트 운영 방식을 공개 spec으로 꺼내 놓은 쪽에 가깝습니다. 권한, sandbox, 승인 정책, CI 권한은 팀마다 따로 설계해야 합니다.

개발팀 입장에서는 뭐가 달라지나

개발자에게는 꽤 직접적인 뉴스입니다. Symphony는 Codex를 단발성 도구가 아니라 팀 workflow의 일부로 묶습니다.

OpenAI는 일부 팀에서 첫 3주 동안 landed PR 수가 500% 증가했다고 설명합니다. 다만 이 수치는 OpenAI 내부 일부 팀 기준입니다. 일반 회사나 작은 팀에서도 그대로 재현된다고 보면 곤란합니다.

오히려 실무적으로 중요한 질문은 따로 있습니다. 우리 팀의 이슈는 에이전트가 읽고 실행할 만큼 명확한가. 테스트는 자동으로 돌 수 있는가. 실패했을 때 retry와 사람 리뷰로 돌아오는 길이 있는가. 이 부분이 약하면 Symphony 같은 구조도 힘을 못 씁니다.

좋은 점

가장 좋은 점은 코딩 에이전트 운영 문제를 정면으로 다룬다는 겁니다. 지금까지 많은 AI 코딩 도구는 "한 사람이 한 세션을 얼마나 잘 쓰는가"에 초점이 있었습니다. Symphony는 여러 에이전트가 동시에 움직일 때 일을 어떻게 나누고, 상태를 어떻게 추적하고, 결과를 어떻게 검수할지를 묻습니다.

두 번째는 spec을 공개했다는 점입니다. OpenAI가 내부 workflow를 제품 광고로만 포장하지 않고, issue tracker, workspace, workflow prompt, observability 같은 구성 요소로 쪼개 공개한 건 실무자에게 참고가 됩니다.

세 번째는 기존 개발 문화의 중요성을 더 분명하게 만든다는 점입니다. 좋은 이슈, 좋은 테스트, 좋은 리뷰 기준이 있을수록 에이전트도 잘 굴러갑니다. 반대로 이 부분이 엉켜 있으면 에이전트가 많아질수록 혼란도 커질 수 있습니다.

아쉬운 점

아직은 preview 성격이 강합니다. GitHub README도 trusted environment용 low-key engineering preview라고 못 박고 있습니다. 운영 권한, 보안 경계, 승인 정책을 제품 수준으로 대신 해결해주는 단계는 아닙니다.

또 500% landed PR 증가는 흥미롭지만, OpenAI 내부 일부 팀의 사례입니다. 코드베이스 품질, 테스트 자동화, 이슈 작성 문화, CI 안정성에 따라 체감 효과는 크게 달라질 수 있습니다.

그리고 Linear 중심 예시가 강합니다. 다른 이슈 트래커나 사내 도구에 붙이려면 adapter와 workflow 설계가 필요합니다.

내 생각

Symphony에서 제일 중요한 건 "코딩 에이전트를 개발자 대신 쓰자"가 아닙니다. 더 정확히는 "코딩 에이전트가 일할 수 있도록 팀의 작업 시스템을 바꾸자"에 가깝습니다.

이 흐름은 최근 AI 도구 경쟁의 방향과도 맞습니다. Gemini CLI의 subagents가 CLI 안에서 역할을 나누는 방식이라면, Symphony는 그보다 위에서 이슈 트래커와 CI, 리뷰 흐름을 묶습니다. Microsoft Copilot agents나 GitHub Copilot 계열 흐름과도 같은 질문을 공유합니다. 에이전트를 어떻게 팀의 실제 업무 흐름 안에 넣을 것인가.

그래서 이 발표는 모델 성능표보다 운영 방식 쪽에 더 가까운 뉴스입니다. 앞으로 코딩 에이전트 경쟁은 "누가 코드를 더 잘 짜나"뿐 아니라 "누가 작업 관리, 검증, 권한, 리뷰까지 더 자연스럽게 묶나"로 갈 가능성이 큽니다.

OpenAI Codex Symphony 요약 카드

결론

OpenAI Codex Symphony는 코딩 에이전트를 세션 단위에서 티켓 단위로 옮기는 시도입니다. Linear 같은 이슈 보드가 control plane이 되고, 각 작업은 isolated workspace와 agent run으로 이어집니다.

당장 모든 팀이 바로 가져다 쓸 완성형 제품은 아닙니다. 하지만 코딩 에이전트를 실제 개발 조직 안에서 굴릴 때 무엇을 설계해야 하는지 보여주는 꽤 중요한 공개 사례입니다.

한 줄 평

Symphony는 Codex의 새 기능이라기보다, 코딩 에이전트를 팀 workflow 안에서 굴리기 위한 운영 설계도에 가깝습니다.

참고 출처