이슈 티켓 하나로 PR까지 — OpenAI의 자율 개발 오케스트레이션 도구, Symphony

개발자가 코드를 한 줄도 쓰지 않는다면, 그의 일은 무엇이 될까. OpenAI가 2026년 3월 공개한 Symphony는 이슈 트래커와 AI 코딩 에이전트를 연결해 개발 작업 전체를 자율화하는 오픈소스 오케스트레이션 프레임워크다. 개발자는 코드를 직접 작성하는 대신 작업 명세를 관리하고 결과를 검토하는 역할로 전환된다.

5개월 실험에서 태어난 도구

Symphony는 OpenAI 내부의 하네스 엔지니어링(Harness Engineering) 실험에서 탄생했다. 2025년 8월 말, OpenAI의 엔지니어 Ryan Lopopolo를 비롯한 소규모 팀이 빈 git 레포지토리에서 시작해 5개월간 Codex 에이전트만을 활용한 개발을 시도했다. 결과는 놀라웠다. 애플리케이션 로직, 테스트, CI 설정, 문서, 내부 툴링까지 약 100만 줄의 코드가 수동 작성 없이 생성됐고, 수동 작성 대비 약 1/10의 시간이 소요됐다. 에이전트에게 레포지토리 작업 방법을 알려주는 AGENTS.md 파일도 Codex가 직접 작성했다.

기존 AI 코딩 도구는 개발자가 에이전트에게 프롬프트를 입력하고 결과를 검토하는 감독자 역할을 요구했다. Symphony는 이 패러다임을 뒤집는다. 개발자는 이슈 티켓에 작업 명세를 작성하고, Symphony가 이를 자동으로 감지해 에이전트를 실행하고, 검증된 Pull Request를 생성한다. 인간은 최종 승인만 담당한다.

"Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents."

Implementation Run이라는 단위

Symphony의 모든 작업은 Implementation Run이라는 단위로 처리된다. 이슈 트래커에서 특정 라벨(예: symphony)이 붙은 작업을 감지하면 하나의 Implementation Run이 시작된다.

⤢✕

각 단계는 독립적으로 격리된다. 에이전트 하나가 실패해도 다른 200개의 병렬 실행에 영향을 주지 않으며, 실패한 프로세스는 자동으로 재시작된다.

신뢰가 아니라 증명을 요구한다

Symphony의 특징적인 설계 원칙은 "신뢰가 아닌 증명"이다. 에이전트가 작업을 완료했다고 주장하는 대신, 검증 가능한 증거를 생성한다. Proof of Work에는 모든 테스트가 실제로 통과했다는 CI 통과 결과, 변경된 코드 전체인 PR diff, 변경사항의 영향도를 보는 복잡도 분석, 무엇을 왜 변경했는지 설명하는 변경사항 워크스루가 포함된다. 개발자는 에이전트의 결과물을 맹신하지 않아도 된다. CI 보고서와 테스트 결과가 자동으로 첨부되기 때문에, 검토자는 코드가 올바르게 동작한다는 것을 별도 확인 없이 판단할 수 있다.

에이전트 정책도 버전 관리 대상이다

Symphony는 에이전트 동작 정책을 WORKFLOW.md 파일로 코드와 함께 버전 관리한다. 에이전트 설정이 소스코드와 함께 PR 리뷰 대상이 된다는 뜻이다.

---
tracker:
  type: linear
  team_key: ENG
  candidate_label: "symphony"
polling:
  interval_ms: 30000
workspace:
  base_dir: /tmp/symphony-workspaces
agent:
  type: codex
  model: o4-mini
  timeout_ms: 600000
codex:
  approval_mode: auto-edit
---

You are working on issue {{ issue.identifier }}: {{ issue.title }}

{{ issue.description }}

## Requirements
- Write clean, well-tested code
- Follow existing code conventions
- Ensure all CI checks pass

YAML front matter 섹션에서 트래커 종류, 폴링 간격, 사용할 AI 모델 등을 선언하고, 그 아래 Liquid 호환 템플릿으로 에이전트에게 전달할 프롬프트를 작성한다. 레포지토리마다 다른 Symphony 설정을 적용할 수 있으며, 에이전트 정책 변경 이력이 git history에 남는다.

Python이 아니라 Elixir를 고른 이유

Symphony의 기술 스택에서 가장 눈에 띄는 점은 AI 툴링 생태계가 Python 중심임에도 Elixir(95.4%)를 선택했다는 것이다. 이유는 명확하다. Symphony는 수백 개의 에이전트를 동시에 장기 실행해야 한다. Python은 단일 에이전트 세션에는 적합하지만, 200개의 에이전트가 각각 10분씩 실행되는 환경에서는 하나의 실패가 전체에 영향을 주는 문제가 있다. Elixir가 구동되는 BEAM(Erlang VM)은 원래 텔레콤 인프라(WhatsApp 등)용으로 설계된 런타임으로, 수천 개의 경량 프로세스를 독립적으로 관리하며 실패한 프로세스를 Supervision Tree를 통해 자동 재시작한다.

항목	Python	Elixir/BEAM
동시 에이전트	제한적	수백~수천
프로세스 격리	어려움	기본 제공
장애 전파	위험	Supervision Tree로 격리
상태 영속성	별도 구현 필요	OTP 기반 내장

파이프라인을 이루는 8개 조각

Symphony는 8개의 컴포넌트가 파이프라인을 구성한다. WORKFLOW.md 파싱 및 에이전트 정책을 로드하는 Workflow Loader, Linear 등 이슈 트래커를 폴링하는 Issue Tracker Poller, 실행 가능한 작업을 클레임하는 Task Claimer, 이슈별로 격리된 작업 공간을 만드는 Workspace Manager, Codex 에이전트를 실행하고 감독하는 Agent Executor, CI 결과·복잡도 분석·워크스루를 생성하는 Proof of Work Generator, Pull Request를 생성하고 병합하는 PR Manager, PostgreSQL 기반으로 실행 상태를 영속화하는 State Store가 그것이다.

State Store가 PostgreSQL을 쓰기 때문에, Symphony 프로세스가 재시작되더라도 진행 중인 작업 상태가 보존된다. 분산 환경에서 여러 Symphony 인스턴스가 동일한 DB를 공유하며 작업을 분산 처리할 수도 있다.

Symphony가 성립하려면 하네스가 먼저다

Symphony가 효과적으로 동작하려면 코드베이스 자체가 하네스 엔지니어링 원칙으로 설계되어야 한다. 하네스는 에이전트와 현실 세계 사이의 구조화된 환경으로, 네 가지 기능을 제공한다. Constrain(제한)은 에이전트가 할 수 있는 범위를 아키텍처 경계와 의존성 규칙으로 명확히 제한해, 임의로 외부 라이브러리를 추가하거나 아키텍처 규칙을 위반하지 못하게 한다. Inform(안내)은 풍부한 컨텍스트 엔지니어링으로 에이전트가 무엇을 해야 하는지 명확히 알려준다 — AGENTS.md, 코드 주석, 구조화된 이슈 템플릿이 여기 해당한다. Verify(검증)는 에이전트 결과를 자동으로 검증한다. 테스트 커버리지, 린팅, CI 파이프라인이 에이전트의 코드가 올바른지 확인하며, LangChain의 Terminal Bench 2.0 벤치마크에서 모델 변경 없이 하네스만 개선했을 때 52.8%에서 66.5%로 성능이 향상된 사례가 있다. Correct(수정)는 잘못된 경우 에이전트가 자체적으로 수정할 수 있는 피드백 루프를 제공한다. CI 실패 메시지가 에이전트에게 전달되어 자가 수리 루프를 구성한다.

격리 우선부터 옵저버빌리티까지, 이 원칙들로 감독한다

Symphony의 설계는 여섯 가지 원칙을 기반으로 한다. 각 에이전트가 독립된 워크스페이스에서 실행돼 하나의 실패가 다른 실행에 영향을 주지 않는 격리 우선, 에이전트가 자체 인증하지 않고 CI 보고서·테스트 결과 등 검증 가능한 증거를 생성하는 신뢰가 아닌 증명, WORKFLOW.md로 선언적이고 버전 관리되는 에이전트 정책을 정의하는 계약 기반 행동, BEAM Supervision Tree로 실패한 에이전트를 자동 재시작하는 실패 가정·복구 설계, 인간은 작업과 수락 기준을 정의하고 에이전트는 실행하는 인간은 작업 관리·에이전트 아님, 모든 실행 상태가 추적 가능하며 중단 후 재개가 가능한 전체 라이프사이클 옵저버빌리티가 그것이다.

SPEC.md 직접 구현이냐, Elixir 참조 구현이냐

Symphony는 두 가지 방식으로 도입할 수 있다. SPEC.md가 공개되어 있어 어떤 언어로든 직접 구현할 수 있으며, 선호하는 코딩 에이전트에게 SPEC.md를 참조해 구현을 요청하면 된다. 아니면 OpenAI가 제공하는 Elixir 참조 구현을 직접 쓸 수 있다 — elixir/README.md에 상세한 설정 가이드가 있다.

현재 공식 지원하는 이슈 트래커는 Linear 하나이며, GitHub Issues 등으로 확장 가능하도록 설계되어 있다. Symphony는 현재 "low-key engineering preview" 단계로, 신뢰할 수 있는 환경에서의 테스트를 권장한다.

Codex, 그리고 GPT-5.4와의 접점

Symphony는 에이전트 실행 엔진으로 Codex를 쓴다. WORKFLOW.md의 agent.type: codex가 이를 지정한다. Codex가 실제 코드 작성, 테스트, 버그 수정 루프를 담당하며, agent.model 설정으로 사용 모델을 지정할 수 있다(예: model: o4-mini). 2026년 3월 OpenAI Build Hour에서는 GPT-5.4가 대용량 컨텍스트 추론과 툴 기반 에이전트 워크플로우에 활용됨이 발표됐다. Symphony는 이런 최신 모델과 연동해 더 복잡한 작업도 자율 처리할 수 있다.

시장은 이미 붐비고 있다

Symphony가 공개된 2026년 3월 5일, 같은 날 Cursor도 Automations 기능을 발표했다. AI 코딩 도구 시장은 Claude Code가 6개월 만에 $1B ARR을 달성하고, GitHub Copilot이 1,500만 유료 좌석을 확보하는 등 폭발적으로 성장하고 있다.

이 시장에서 Symphony의 차별화 포인트는 "단일 에이전트 + 감독"에서 "에이전트 플릿 + 오케스트레이션"으로의 전환이다. 다른 도구들이 개발자와 에이전트의 실시간 상호작용에 집중할 때, Symphony는 에이전트가 인간의 개입 없이 전체 개발 사이클을 완료하는 것을 목표로 한다.

GitHub 공개 2주 만에 약 12,307개의 스타와 955개의 포크를 기록했으며, 서드파티 래퍼 도구(npx @citedy/skills install symphony 등)가 등장하는 등 생태계가 빠르게 형성되고 있다.

Symphony는 단순한 코딩 도구가 아니라 소프트웨어 개발 프로세스 자체를 재설계하는 시도다. Harness Engineering, Implementation Run, Proof of Work 같은 개념은 에이전트가 신뢰할 수 있는 팀원으로 동작하기 위한 구조적 기반을 제공한다. OpenAI의 내부 실험이 5개월간 100만 줄의 코드를 수동 작성 없이 생성했다는 결과는, 개발자의 역할이 "코드를 작성하는 사람"에서 "시스템을 설계하고 에이전트를 감독하는 사람"으로 이미 전환되고 있음을 보여준다.