Apache License 2.0
Engineering Preview
OpenAI Symphony,
쓰기 전에 이 조건 확인하세요
결론부터 말씀드리면, Linear 이슈 트래커를 쓰지 않는 팀이라면 Symphony는 지금 당장 쓸 수 없습니다. “에이전트가 알아서 PR 올려준다”는 이야기만 듣고 도입을 검토하다가 Elixir 환경 설정에서 막히는 경우가 생기고 있습니다. 공식 SPEC.md와 실제 비교 데이터를 직접 확인했습니다.
Symphony가 실제로 하는 일 — PR 자동화의 정확한 범위
OpenAI Symphony는 2026년 3월 5일, GitHub에 오픈소스로 공개된 에이전트 오케스트레이션 서비스입니다. 한 줄로 설명하면 “Linear 보드의 티켓을 감지해 Codex 에이전트를 자동 실행하고, PR을 생성·병합까지 처리하는 상시 가동 데몬”입니다. (출처: GitHub openai/symphony README, 2026.03.05)
공식 README에 “코딩 에이전트를 감독하는 것이 아니라 업무를 관리하는 구조”라고 딱 나와 있습니다. 에이전트가 코드를 쓰는 동안 개발자는 티켓 보드만 관리하면 된다는 개념입니다. 기본 동시 실행 에이전트 수는 10개이고, 최대 재시도 백오프는 5분(300,000ms)으로 SPEC에 고정돼 있습니다. (출처: openai/symphony SPEC.md, §5.3.5)
💡 공식 SPEC과 실제 동작을 함께 놓고 보면 이런 흐름이 보입니다
① Linear 보드 30초 간격 폴링 → ② 이슈 상태 감지 → ③ 격리 워크스페이스 생성 → ④ Codex 에이전트 실행 → ⑤ PR 생성 + 병합. 각 이슈는 완전히 독립된 디렉토리에서 실행되므로 에이전트 간 간섭이 없습니다.
에이전트 한 번 실행으로 끝나지 않는 경우를 위해 멀티턴 실행 구조가 있습니다. 첫 번째 턴은 전체 컨텍스트로 실행하고, 이후 턴은 “이전에 작업하던 이슈를 이어서 해줘”라는 최소 프롬프트만 전달합니다. 기본 최대 턴 수는 20회입니다. 워크스페이스가 유지되기 때문에 에이전트가 이전 커밋과 테스트 결과를 그대로 이어받아 작업합니다. (출처: openai/symphony SPEC.md, §7.1)
Linear 전용이라는 조건이 왜 치명적인가
Symphony의 공식 SPEC.md §5.3.1을 직접 보면 tracker.kind 필드에서 현재 지원하는 값이 linear 하나뿐이라고 명시돼 있습니다. GitHub Issues, Jira, Notion은 없습니다. (출처: openai/symphony SPEC.md §5.3.1, 2026.03.05)
⚠️ Linear를 안 쓰면 Symphony는 지금 당장 쓸 수 없습니다.
공식 문서에 이유를 별도로 밝히지 않았지만, Linear의 GraphQL API 구조를 기반으로 오케스트레이터가 설계되어 있어 다른 트래커로의 전환은 아키텍처 수준의 수정이 필요합니다. GitHub Issues·Jira를 쓰는 팀이라면 현재 시점에서는 대안을 찾아야 합니다.
에이전트가 Linear 이슈를 직접 업데이트하는 구조도 주목할 점입니다. Symphony는 에이전트 세션 안에 linear_graphql 동적 툴을 주입합니다. 에이전트가 이슈 상태를 “In Progress” → “Human Review”로 직접 변경하고, 코멘트를 달고, PR 링크를 업데이트하는 작업까지 모두 처리합니다. 이 구조 자체가 Linear API에 강하게 결합돼 있습니다. (출처: openai/symphony SPEC.md §10.5)
공식 문서가 “신뢰된 환경(trusted environments)에서의 엔지니어링 프리뷰”라고 명시한 점도 중요합니다. 에이전트가 코드베이스에 대한 광범위한 쓰기 권한을 갖고 실행되기 때문에, 외부 공개 리포지토리나 멀티테넌트 환경에는 적합하지 않다는 의미입니다. (출처: mintlify.com/openai/symphony/introduction)
구조를 알면 보이는 것들 — 6개 레이어와 WORKFLOW.md
Symphony의 핵심 아이디어 중 하나는 모든 에이전트 동작 정책을 WORKFLOW.md 파일 하나에 담는 것입니다. 이 파일이 리포지토리 안에 버전 관리됩니다. 에이전트 프롬프트, 폴링 간격, 동시 실행 제한, 워크스페이스 훅 스크립트가 전부 여기에 들어갑니다. 팀 전체가 같은 설정을 공유하고, 변경 이력이 Git에 남습니다. (출처: openai/symphony SPEC.md §5)
| 레이어 | 역할 | 변경 가능 여부 |
|---|---|---|
| 정책 레이어 | WORKFLOW.md 프롬프트·규칙 | ✅ 팀 커스텀 가능 |
| 설정 레이어 | YAML 프론트매터 타입 파싱 | ✅ 팀 커스텀 가능 |
| 조정 레이어 | 오케스트레이터 폴링·재시도 | ⚙️ 설정값으로 조정 |
| 실행 레이어 | 워크스페이스·에이전트 프로세스 | ⚙️ 훅으로 확장 |
| 통합 레이어 | Linear GraphQL API 연동 | ❌ Linear 전용 고정 |
| 관찰 레이어 | 구조화 로그·상태 대시보드 | ✅ 확장 가능 |
Elixir/OTP 기반이라는 점도 단순한 기술 선택이 아닙니다. OTP 슈퍼비전 트리 덕분에 에이전트 하나가 충돌해도 전체 서비스가 멈추지 않고 해당 프로세스만 재시작됩니다. Python이나 TypeScript로 같은 기능을 구현하려면 수개월이 걸릴 수 있는 프로세스 격리와 장애 내성이 Elixir에서는 언어 기본 기능입니다. (출처: sjramblings.io/openai-symphony-autonomous-agent-orchestration, 2026.03.12)
PR 리뷰 요청이 들어오면 Symphony는 처음부터 다시 합니다
“에이전트가 PR을 올리면 리뷰 코멘트도 반영해서 수정해주겠지”라고 기대하면 실망할 수 있습니다. Symphony의 참조 구현 워크플로우는 리뷰어가 변경 요청을 남기면 기존 PR을 닫고 새 브랜치에서 처음부터 재구현합니다. 기존 코드베이스 위에서 코멘트를 반영해 수정하는 방식이 아닙니다. (출처: dev.to 비교 분석, 2026.03.18)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
경쟁 도구인 Agent Orchestrator(AO)는 리뷰 코멘트를 기존 브랜치에 증분 전달해 에이전트가 이어서 수정합니다. Symphony는 전체 재구현입니다. 작은 수정이 필요한 PR에는 오히려 비효율적입니다. 이 차이가 실무에서 어떤 의미인지는 WORKFLOW.md를 어떻게 설계하느냐에 따라 달라집니다.
재시도 로직도 눈여겨볼 만합니다. 에이전트 실행이 비정상 종료되면 백오프 공식은 min(10초 × 2^시도횟수, 300초)입니다. 즉 첫 실패 후 10초, 두 번째 실패 후 20초, 세 번째 40초, 최대 5분으로 올라갑니다. (출처: openai/symphony SPEC.md §8.4) 에이전트가 연속 실패하면 최대 5분마다 한 번씩만 재시도되므로, 대규모 백로그 처리에서 병목이 될 수 있습니다.
스톨(stall) 타임아웃도 있습니다. 에이전트가 마지막 이벤트를 보낸 후 기본 5분(300,000ms) 동안 아무 응답이 없으면 강제 종료 후 재시도 큐에 들어갑니다. (출처: openai/symphony SPEC.md §5.3.6) 오래 걸리는 작업이 많은 코드베이스라면 이 값을 올려야 합니다.
경쟁 도구와 비교해보니 이런 차이가 있었습니다
Symphony와 같은 날 공개 프리뷰에 들어간 도구가 있습니다. GitHub Copilot의 Jira 연동 코딩 에이전트가 2026년 3월 5일 같은 날 퍼블릭 프리뷰를 시작했습니다. (출처: sjramblings.io/openai-symphony-autonomous-agent-orchestration, 2026.03.12) 우연의 일치가 아니라 “이슈 → PR 자동화” 시장에 여러 회사가 동시에 진입한 것입니다.
| 항목 | Symphony | Agent Orchestrator(AO) |
|---|---|---|
| 이슈 트래커 | Linear 전용 | GitHub·Linear·Jira |
| 에이전트 지원 | Codex 공식 (Claude 커뮤니티) | Claude·Codex·Aider 등 |
| 리뷰 코멘트 처리 | PR 닫고 전체 재구현 | 기존 브랜치에 증분 반영 |
| 장애 내성 | OTP 슈퍼비전 트리 | 폴링 기반 감지 후 복구 |
| 동시 실행 기본값 | 10개 | 5개 (설정 가능) |
| 첫 실행까지 소요 시간 | 약 30~60분 | 약 10분 |
| 라이선스 | Apache 2.0 | MIT |
※ 출처: dev.to 비교 분석(2026.03.18) 및 openai/symphony SPEC.md 기준
수치로 보면 Symphony의 초기 설정 시간이 30~60분으로, AO의 10분보다 훨씬 깁니다. Elixir 런타임 설치부터 시작해야 하기 때문입니다. 처음 써보는 팀에게 이 허들은 작지 않습니다. 이미 Node.js 환경이 있는 팀이라면 AO가 실제로 더 빠릅니다.
도입 전 실제로 필요한 것들 — 공식 문서 기준
공식 문서와 비교 데이터를 모두 확인하고 나면, Symphony가 잘 맞는 팀과 그렇지 않은 팀이 꽤 뚜렷하게 갈립니다. 단순히 “AI가 코드 써준다”는 기대로 접근하면 설정 단계에서 막히는 경우가 많습니다.
✅ 맞는 상황
- Linear를 이미 이슈 트래커로 쓰고 있는 팀
- 테스트 커버리지와 CI/CD가 갖춰진 코드베이스
- 반복적인 루틴 작업이 백로그에 쌓여있는 경우
- Elixir 환경을 다룰 수 있는 팀원이 있는 경우
- 신뢰된 내부 환경(사내망·비공개 리포)에서 운영 가능한 경우
❌ 맞지 않는 상황
- GitHub Issues 또는 Jira를 쓰는 팀
- CI가 없거나 자동화 테스트가 부족한 프로젝트
- 에이전트가 매 리뷰를 증분으로 처리하길 원하는 경우
- Elixir 런타임 신규 구축이 부담스러운 팀
- 공개 리포지토리 또는 멀티테넌트 환경
Symphony가 “엔지니어링 프리뷰”임을 공식 문서에서 명확히 밝히고 있습니다. 프로덕션 환경에 대한 지원 약속은 아직 없습니다. (출처: mintlify.com/openai/symphony/introduction) 6개월 뒤에도 적극적으로 유지보수될지는 아직 불분명한 부분입니다.
💡 OpenAI가 Codex와 Symphony를 함께 묶는 이유를 생각해보면 이런 그림이 나옵니다
Symphony는 독자적인 프레임워크이기도 하지만, 사실상 Codex의 “사용 이유”를 만들어주는 상위 레이어입니다. Codex를 더 많이 쓰게 만드는 구조 안에 Symphony가 있습니다. Apache 2.0으로 오픈소스를 공개한 것도, 어떤 언어로든 직접 구현해서 써도 된다고 한 것도, 결국 Codex API 소비를 늘리는 방향과 맞닿아 있습니다.
Q&A
Q. Symphony를 사용하려면 반드시 OpenAI 계정이 필요한가요?
네, 현재 공식 참조 구현은 Codex(OpenAI)를 기반으로 합니다. 다만 SPEC.md 자체는 언어 중립적으로 작성되어 있어, 커뮤니티에서 Claude 기반 구현체도 나오고 있습니다. OpenAI API 키 없이 쓰려면 직접 구현하거나 커뮤니티 포크를 써야 합니다.
Q. Elixir를 모르는 팀도 쓸 수 있나요?
공식 README에 “좋아하는 코딩 에이전트에게 SPEC.md를 읽혀서 원하는 언어로 구현하게 해도 된다”고 나와 있습니다. Elixir 참조 구현이 유일한 선택지는 아닙니다. 하지만 프로덕션 수준의 안정성이 필요하다면 OTP 없이 같은 수준의 장애 내성을 갖추기가 쉽지 않습니다.
Q. 에이전트가 main 브랜치에 직접 푸시할 수 있나요?
아닙니다. Symphony는 항상 feature 브랜치에서 작업하고 PR을 생성합니다. main 브랜치는 병합 전까지 건드리지 않습니다. 다만 에이전트의 승인 정책(approval_policy)을 never로 설정하면 파일 쓰기, 명령 실행 모두 자동 승인되므로, 워크스페이스 내 권한은 사실상 무제한입니다.
Q. API 비용이 얼마나 나오나요?
SPEC에서 토큰 사용량을 Live Session 단위로 추적하는 구조가 있습니다(codex_input_tokens, codex_output_tokens). 실제 비용은 이슈 복잡도와 최대 20턴 실행 여부에 따라 크게 달라집니다. 공식 문서에서 예상 비용을 별도로 제시하지 않았습니다. 초기에는 작은 이슈부터 테스트하고 토큰 로그를 모니터링하는 것이 안전합니다.
Q. Jira 지원은 언제 될까요?
OpenAI가 공식 답변을 내놓지 않은 부분입니다. SPEC.md에 “Unknown keys는 하위 호환성을 위해 무시한다”고 나와 있어 확장 가능성은 열려 있습니다. 커뮤니티에서 GitHub Issues·Jira 어댑터를 구현하는 시도가 나오고 있지만, 공식 지원 일정은 현재 없습니다.
마치며
Symphony를 써봐야 할 팀과 지금 당장은 건너뛰어도 되는 팀이 꽤 명확하게 나뉩니다. Linear + 내부 환경 + CI가 갖춰진 곳이라면 실제로 에이전트가 PR을 올려주는 경험을 할 수 있습니다. 반면 GitHub Issues나 Jira에 의존하는 팀, Elixir가 낯선 팀에게는 지금 시점에서 진입 장벽이 적지 않습니다.
솔직히 말하면, “에이전트가 알아서 다 해준다”는 표현은 좀 과합니다. WORKFLOW.md를 얼마나 잘 써두느냐, 티켓 설명이 얼마나 구체적이냐에 따라 결과물의 품질이 크게 달라집니다. 에이전트를 잘 쓰는 팀의 핵심 역량이 “코드 작성”에서 “명세 작성”으로 이동하고 있다는 걸 Symphony가 가장 직접적으로 보여주는 도구라는 생각이 듭니다.
📚 본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. OpenAI Symphony는 현재 엔지니어링 프리뷰 단계로, 업데이트로 인해 내용이 달라질 수 있습니다. 본 포스팅은 2026.03.28 기준으로 작성되었으며 투자·법률 조언이 아닙니다.
댓글 남기기