OpenAI Symphony는 Linear 티켓을 코딩 에이전트에게 자동 배분하는 오케스트레이터다. 처음 설정하고 나서 내가 한 건 티켓에 라벨 하나 달아놓은 것뿐이었는데, 4분 18초 후 PR이 도착해 있었다. 라우트 코드, 테스트, 브랜치 푸시까지 전부 에이전트 혼자서.
결론부터: 티켓 하나가 PR이 됐다, 4분 18초 만에
솔직히 처음에는 반신반의했다. Devin이 나왔을 때도, Codex가 나왔을 때도 비슷한 말이 있었으니까. "AI가 코드를 짜준다"는 건 이미 익숙한 문장이다. 근데 Symphony는 접근이 달랐다.
테스트로 넣은 첫 번째 티켓은 단순했다. "/health 엔드포인트를 추가하고, 응답에 uptime_seconds를 포함할 것." Linear에서 해당 티켓을 "ready-for-codex" 상태로 옮겼다. 그리고 그냥 기다렸다. 31초 뒤 Symphony가 티켓을 잡았고, 4분 18초 뒤에 PR이 생겼다. 라우트 코드, 테스트 코드, 브랜치 푸시까지 다 됐다. TypeScript 타입 추론 에러가 한 번 나서 두 번째 시도에서 고쳤다는 로그도 있었다.
그 다음에 rate limiting 미들웨어 티켓을 넣어봤다. "공개 API 엔드포인트에 rate limiting 추가, 기본 60 req/min, 라우트별 오버라이드 가능." 11분 뒤에 draft PR이 들어왔다. 미들웨어 코드, 라우트별 오버라이드 구조, 테스트 3개. diff가 완벽하진 않았다. 테스트 하나는 내가 거부하고 주석도 다듬었다. 하지만 '일'은 됐다.
Symphony가 실제로 하는 일
30초 폴링과 격리 워크스페이스
Symphony의 작동 방식은 단순하다. Linear를 30초마다 폴링하다가 특정 상태(예: "ready-for-codex")로 이동한 티켓을 발견하면 잡는다. 그런 다음 격리된 git worktree를 새로 만들고, 거기서 Codex 또는 Claude Code 에이전트를 부팅해서 실행한다. 에이전트가 PR을 만들거나 실패 이유를 내놓을 때까지 계속 돌린다.
기본 동시 에이전트 수는 10개다. 상태는 Elixir GenServer의 in-memory에 저장되고, 재시작하면 Linear에서 다시 빌드한다. 데이터베이스 없이 운용된다는 뜻이다. 이전에 Chrome DevTools MCP 보안 이슈를 다뤘을 때처럼 AI 에이전트가 내 코드베이스 전체에 접근한다는 건 신경 써야 할 부분이긴 하다. Symphony도 레포 전체 클론 권한이 필요하다.
Codex/Claude Code 에이전트가 PR까지
에이전트는 WORKFLOW.md를 기반으로 움직인다. 이 파일이 핵심이다. "Before you start" 섹션에 적어놓은 가이드, npm test / npm run lint / npm run typecheck 같은 computational sensor들이 에이전트의 행동을 결정한다. LLM-as-judge 같은 복잡한 설정 없이도 이것만 잘 잡아도 동작한다. 오픈소스 스펙(Apache 2.0)이라 Elixir 레퍼런스 구현을 쓰거나, 스펙 보고 다른 언어로 직접 구현하는 것도 가능하다. GitHub 스타가 2만을 넘은 데는 이 유연함이 한몫했다.
90분 만에 처음 설정하는 방법
WORKFLOW.md 한 파일이 전부
설정 자체는 생각보다 단순하다. Symphony 레포 클론하고, Elixir 설치하고, Linear API 키 받고, WORKFLOW.md 하나 작성하면 된다. 실제로 git clone부터 첫 PR까지 90분 걸렸는데, 그 중 대부분은 Linear 설정이었다. Symphony 코드 자체를 건드린 시간은 15분 정도였다.
WORKFLOW.md에서 tracker는 Linear 프로젝트 슬러그, active_states에 "Todo / In Progress", agent에는 최대 동시 에이전트 수와 max_turns를 설정한다. hooks.after_create에 레포 클론 커맨드 넣으면 에이전트 워크스페이스가 준비된다. AI 코드 리뷰 시간이 늘어난다는 문제와 비슷하게, 설정보다 운용 단계에서 생각이 더 많이 필요했다.
harness engineering이 선행 조건인 이유
Symphony 공식 문서가 "harness engineering 원칙을 따르는 코드베이스에서 가장 잘 동작한다"고 명시한다. 테스트 커버리지, 명확한 빌드 커맨드, 자동화된 CI/CD 파이프라인. 이게 없으면 에이전트가 뭘 고쳤는지 검증할 수단이 없다. 테스트가 통과했다는 게 에이전트가 보낼 수 있는 가장 강한 신호인데, 테스트 자체가 없으면 에이전트도 맹인과 비슷해진다. 레거시 코드베이스에 바로 적용하기 어려운 이유다.
잘 되는 티켓과 안 되는 티켓, 이 차이가 핵심이었다
모호한 티켓에서 실제로 겪은 문제
3주간 사이드 프로젝트에서 써봤는데, 잘 스코프된 단일 기능 티켓에서는 PR 처리량이 3~4배 올랐다. 반면 모호하게 적은 티켓에서는 개발자+Claude Code 조합보다 성능이 떨어졌다. 에이전트가 스펙의 모호한 부분에서 추측을 하고, 그 추측이 틀리면 오류가 복리로 쌓였다. "사용자 경험 개선", "성능 최적화" 같은 지시어는 에이전트에게 사실상 의미가 없다.
티켓을 잘 쓰는 습관이 생겼다는 건 예상치 못한 부작용이었다. 에이전트가 읽을 수 있도록 구체적으로 쓰다 보니, 사람이 봐도 더 명확한 티켓이 됐다.
PR 리뷰가 새 병목이 되는 위험
OpenAI가 내부적으로 발표한 수치는 첫 3주에 landed PR 500% 증가다. 이 숫자 자체는 인상적이다. 근데 그 PR들이 다 충분히 검토됐는지는 다른 문제다. 생성 속도가 빨라지면 리뷰 큐가 쌓이고, 쌓이면 rubber-stamping(무검토 머지)의 유혹이 커진다. 그렇게 되면 Symphony는 기술 부채를 더 빠른 속도로 쌓는 도구가 된다.
병목이 "코드 작성"에서 "스펙 작성 + PR 리뷰"로 이동한 거다. 이걸 생산성 향상으로 볼 수 있는 건, 리뷰 프로세스가 그 속도를 따라갈 때뿐이다. 솔직히 개인 프로젝트에서는 괜찮았는데, 팀 단위로 쓰면 리뷰 문화부터 점검해야 할 것 같다는 생각이 들었다.
📎 참고 자료
- openai/symphony — GitHub (Apache 2.0 오픈소스)
- Symphony Quickstart — 공식 문서
- OpenAI Symphony: The Coding Agent Orchestrator Tested (Engr Mejba Ahmed, 2026-04-30)
🔗 함께 보면 좋은 글
📌 함께 보면 좋은 글
'AI.IT' 카테고리의 다른 글
| Google Antigravity 써봤는데, 무료라는 말과 실제 할당량이 달랐다 (2) | 2026.05.06 |
|---|---|
| Lovable vs Bolt.new vs v0, 바이브코딩 앱 빌더 직접 써본 결과 정리 (2) | 2026.05.05 |
| AI 코드 리뷰 시간이 작성 시간보다 길어진 이유, 데이터가 보여줬다 (2) | 2026.05.03 |
| AI로 코드 다 짰는데 배포는 누가 하나, Cafe24 AI Space 써봤다 (1) | 2026.05.02 |
| Gemini Code Assist 무료 한 달 써봤더니, PR 리뷰가 진짜 핵심이었다 (2) | 2026.05.01 |
