OpenAI Symphony: 코딩 에이전트를 감독하는 시대에서 일감을 관리하는 시대로

2025년 8월, OpenAI의 작은 팀 세 명이 실험을 시작했다. 조건은 단 하나였다. 직접 코드를 한 줄도 작성하지 않는다. 모든 애플리케이션 로직, 테스트, CI 설정, 문서, 내부 도구는 Codex가 썼다. 다섯 달 뒤 레포지토리에는 약 100만 줄의 코드가 쌓였고, 1,500개의 PR이 머지됐다. 팀은 이를 “손으로 짰다면 열 배 걸렸을 것”이라고 추산했다.¹

이 경험에서 탄생한 방법론을 OpenAI는 하네스 엔지니어링(Harness Engineering)이라 불렀다. 그리고 2026년 3월 초, 그 방법론의 참조 구현체를 오픈소스로 공개했다. 이름은 Symphony다.²

문제의 핵심: 에이전트는 있는데, 관리자가 없다

Cursor, GitHub Copilot, Claude Code 같은 도구는 개발자가 질문하면 에이전트가 대답하는 구조다. 루프의 중심에 언제나 인간이 있다. 에이전트는 반응한다. 시작도, 모니터링도, 재시도도 사람이 한다.

이 구조의 한계는 규모에서 드러난다. 동시에 처리해야 할 이슈가 다섯 개, 열 개로 늘어나면 개발자의 주의(attention)가 병목이 된다. 에이전트 성능이 아무리 좋아도, 사람이 “자 시작해”라고 눌러줘야만 움직이는 한 처리량은 늘지 않는다.

Symphony가 풀려는 문제는 바로 이것이다. 에이전트를 감독하는 대신, 일감을 관리한다.

[!KEY] Symphony의 패러다임 전환: “개발자가 에이전트에게 작업을 던진다” → “이슈 트래커가 에이전트를 자동으로 소환한다”

무엇을 하는가: Implementation Run의 생애주기

Symphony의 핵심 실행 단위는 구현 런(Implementation Run)이다. 하나의 이슈가 지정된 상태(기본값: Todo 또는 In Progress)에 들어오는 순간부터 PR 머지 또는 인간 리뷰 단계까지, 에이전트가 자율적으로 처리하는 전 과정을 뜻한다.

flowchart TD
    A[Linear 이슈<br/>상태: Todo] -->|30초마다 폴링| B[오케스트레이터<br/>적격 이슈 탐지]
    B --> C[워크스페이스<br/>격리 생성]
    C --> D[WORKFLOW.md<br/>프롬프트 렌더링]
    D --> E[Codex App-Server<br/>실행]
    E --> F{결과}
    F -->|성공| G[CI 통과 / PR 생성<br/>Human Review 상태로 전환]
    F -->|실패| H[지수 백오프<br/>재시도 큐]
    F -->|이슈 상태 변경| I[에이전트 중단<br/>워크스페이스 정리]
    G --> J[인간 검토 후 머지]
    H -->|최대 5분 대기| B

각 이슈는 반드시 별도의 워크스페이스 디렉터리를 부여받는다. 에이전트 A가 ABC-42를 처리하는 동안 에이전트 B가 ABC-43을 건드려도 파일시스템 레벨에서 충돌이 없다. 이 격리가 Symphony가 기본값 10개, 설정에 따라 그 이상의 에이전트를 동시에 굴릴 수 있는 이유다.

증명 작업(Proof of Work)도 주목할 만하다. 에이전트는 코드를 짜는 것으로 끝이 아니다. CI 상태 보고, PR 리뷰 피드백, 복잡도 분석, 변경 사항 워크스루 영상까지 생성한 뒤에야 다음 단계로 넘어간다. “에이전트가 뭔가 했다”는 주장이 아니라, 검증 가능한 결과물로 완료를 증명한다.

아키텍처: 8개의 레이어

SPEC.md가 정의하는 Symphony의 구성 요소는 여덟 가지다.³

이 중에서도 오케스트레이터가 전체 상태를 단일 인메모리 맵으로 관리한다는 점이 인상적이다. running, claimed, retry_attempts, completed로 구성된 상태는 영속 데이터베이스 없이도 재시작 복구가 가능하도록 설계됐다. 실패한 에이전트는 지수 백오프(최대 5분) 뒤 자동으로 재시도 큐에 올라간다.

[!KEY] Symphony는 풀스택 워크플로 엔진이 아니다. SPEC.md가 명시하듯, “스케줄러/러너/트래커 리더”다. 티켓 상태 전환, PR 링크 달기, 코멘트 작성은 에이전트 자신이 도구를 통해 처리한다.

WORKFLOW.md: 에이전트 행동 규범을 코드처럼 버전 관리한다

Symphony에서 팀의 전략이 담기는 곳은 WORKFLOW.md다. 이 파일 하나가 에이전트의 작업 방식 전부를 결정한다.

---
tracker:
  kind: linear
  project_slug: "eng-backend"
  active_states: ["Todo", "In Progress"]
  api_key: $LINEAR_API_KEY
polling:
  interval_ms: 30000
workspace:
  root: ~/symphony-workspaces
  hooks:
    after_create: |
      git clone git@github.com:your-org/your-repo.git .
    before_run: |
      git checkout -b symphony/{{ issue.identifier }}
    after_run: |
      npm test && npm run lint
agent:
  max_concurrent_agents: 10
  max_turns: 20
codex:
  command: codex app-server
  approval_mode: auto-edit
---

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

{{ issue.description }}

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

핵심은 이 파일이 레포지토리 안에 산다는 점이다. 팀이 에이전트 행동 규범을 바꾸고 싶으면 WORKFLOW.md를 커밋한다. PR 리뷰를 거치고, 히스토리가 남는다. 에이전트 정책이 소스 코드와 함께 버전 관리된다.

30초 단위 폴링, 훅 타임아웃 기본 60초, after_create/before_run/after_run/before_remove 훅은 WORKFLOW.md 변경만으로 서비스 재시작 없이 즉시 반영된다.

Elixir를 선택한 이유: BEAM의 슈퍼파워

OpenAI의 기술 스택은 대부분 Python이다. 그런데 Symphony의 참조 구현체는 Elixir로 짜였다.⁴ 이유는 명확하다.

graph LR
    subgraph BEAM["Erlang/BEAM 런타임"]
        ORC["오케스트레이터<br/>프로세스"]
        W1["워커 프로세스<br/>ABC-42"]
        W2["워커 프로세스<br/>ABC-43"]
        W3["워커 프로세스<br/>ABC-44"]
        SUP["Supervisor<br/>크래시 감지 + 재시작"]
        ORC --> SUP
        SUP --> W1
        SUP --> W2
        SUP --> W3
    end
    C1["Codex<br/>인스턴스 1"] <-->|stdio JSON-RPC| W1
    C2["Codex<br/>인스턴스 2"] <-->|stdio JSON-RPC| W2
    C3["Codex<br/>인스턴스 3"] <-->|stdio JSON-RPC| W3

BEAM의 슈퍼비전 트리(Supervision Tree)는 각 에이전트 프로세스를 독립적으로 격리한다. 에이전트 A가 예외를 던지고 죽어도 B와 C는 영향을 받지 않는다. 슈퍼바이저가 A를 자동으로 재시작한다. Python의 스레드 모델이나 asyncio로 이런 수준의 격리와 복구를 구현하려면 훨씬 많은 코드가 필요하다.

Elixir의 경량 프로세스(스레드가 아닌 OS 수준 독립 프로세스)는 수백 개의 에이전트 런을 동시에 감독하기에 이상적이다. 각 Implementation Run이 LLM 추론을 기다리며 수 분씩 블로킹되는 환경에서, “기다리는 비용”이 거의 없는 BEAM 스케줄러는 자연스러운 선택이었다.

참조 구현체의 핵심 오케스트레이션 로직은 약 258줄의 Elixir 코드로 구성돼 있다. 이 간결함 자체가 BEAM의 추상화 수준을 방증한다.

하네스 엔지니어링: Symphony가 전제하는 환경

Symphony는 아무 레포에나 던져도 동작하지 않는다. README는 명확히 적는다: “Symphony works best in codebases that have adopted harness engineering.”⁵

하네스 엔지니어링은 OpenAI가 2026년 2월 공개한 엔지니어링 방법론이다. 핵심은 코드베이스를 에이전트가 읽고, 실행하고, 검증할 수 있는 환경으로 구성하는 것이다. 세 가지 기둥이 있다.

1. 헤르메틱 테스트(Hermetic Testing): 외부 의존성 없이 로컬에서 결정론적으로 실행되는 테스트. 에이전트가 자신의 변경이 올바른지 스스로 검증할 수 있어야 한다.

2. 기계 가독 문서(Machine-Readable Docs): 에이전트가 빌드, 테스트, 배포 방법을 자율적으로 파악할 수 있는 AGENTS.md, WORKFLOW.md, 스크립트 구조.

3. 모듈형 아키텍처(Modular Architecture): 사이드이펙트가 최소화돼 에이전트가 국소적인 변경을 높은 신뢰도로 수행할 수 있는 설계.

OpenAI의 실험 팀은 이 환경이 갖춰지지 않아 초반 진척이 예상보다 느렸다고 회고한다. “에이전트의 능력 부족이 아니라, 환경의 미명세(underspecified)“가 병목이었다. 에이전트에게 “더 잘 해”라고 요청하는 대신, “이 작업을 가능하게 할 인프라가 무엇인가”를 물었을 때 비로소 가속이 붙었다.

경쟁 도구와의 차이

Symphony가 등장한 맥락을 이해하려면 현재 시장을 봐야 한다.

GitHub Copilot Coding Agent가 가장 비슷한 개념이다. 이슈를 PR로 자동 변환한다는 점에서 목적이 겹친다. 차이는 생태계 종속성이다. Copilot은 GitHub 레포, GitHub Actions, GitHub Issues의 삼박자를 전제한다. Symphony는 Linear 어댑터가 기본이지만, SPEC.md의 “Integration Layer”는 GitHub Issues, Jira 등 어떤 트래커도 플러그인 방식으로 지원할 수 있도록 설계됐다. 커뮤니티에서 이미 GitHub Issues 어댑터 작업이 시작됐다는 언급도 있다.

Devin과의 차이는 더 근본적이다. Devin은 클라우드 SaaS 제품이다. 코드와 컨텍스트가 외부 서버로 전송된다. Symphony는 온프레미스 데몬이다. Codex API 키만 있으면 회사 방화벽 안에서 모든 것이 돌아간다.

Hacker News와 커뮤니티 반응

Symphony는 2026년 3월 4일 Hacker News에 등장했다.⁶ 반응은 조용했다. 20포인트, 6개의 댓글. 커뮤니티는 두 가지 지점에서 주목했다.

첫째, Elixir 선택. “Python이 아닌 Elixir”라는 사실 자체가 흥미로웠다. r/elixir 서브레딧에서는 “And, yes, it’s in Elixir”라는 한 줄로 스레드가 시작됐고, 회원들은 “Very cool”로 반응했다. Elixir 커뮤니티에게 OpenAI의 선택은 자신들의 언어가 프로덕션 AI 인프라에 적합하다는 검증처럼 읽혔다.

둘째, SPEC.md의 가독성. HN의 한 댓글은 신랄했다.

“The specs are inscrutable agent slop. I want it to tell me what it does and instead it just lists database fields.” — HN 댓글⁶

SPEC.md가 상태 머신을 언급하면서도 상태 전이를 명확히 기술하지 않는다는 비판이었다. OpenAI가 “Codex로 SPEC을 작성하게 해서 빌드하라”는 접근 방식과 사람이 읽기 위한 명세 사이의 긴장이 드러난 지점이다.

두 가지 사용 방법

Symphony는 용도에 따라 두 가지 진입점을 제공한다.

방법 1: 직접 구현. SPEC.md를 에이전트에게 주면 된다. “내가 쓰는 언어로 이 스펙대로 구현해줘”라는 프롬프트 한 줄로 시작할 수 있다. TypeScript, Python, Rust — 언어 제약이 없다. 이 방식은 Elixir 없이 기존 스택에 녹여 넣고 싶은 팀에게 적합하다.

방법 2: Elixir 참조 구현 사용. GitHub 레포의 elixir/ 디렉터리가 바로 이것이다. mise로 Elixir/Erlang 버전을 관리하고, mix setup && mix build로 빌드하면 ./bin/symphony WORKFLOW.md로 서비스가 시작된다.

git clone https://github.com/openai/symphony
cd symphony/elixir
mise trust && mise install
mise exec -- mix setup && mix build
LINEAR_API_KEY=your_key mise exec -- ./bin/symphony ./WORKFLOW.md

단, OpenAI는 참조 구현체에 경고를 붙인다: “prototype software intended for evaluation only.” 프로덕션 투입 전 자체적으로 강화된 버전을 구현하거나 철저한 검토를 권고한다.

무엇이 빠졌는가

Symphony가 해결하지 않는 것도 명확히 적혀 있다. SPEC.md의 Non-Goals 섹션은 아래를 명시한다.

• 풍부한 웹 UI나 멀티테넌트 컨트롤 플레인
• 범용 워크플로 엔진 또는 분산 잡 스케줄러
• 티켓, PR, 코멘트를 어떻게 편집할지의 비즈니스 로직
• 모든 구현체에 동일한 샌드박스 정책 강제

마지막 항목이 중요하다. Symphony는 신뢰된 환경(trusted environment)을 전제하는 저수준 엔지니어링 프리뷰다. 외부 기여자가 악의적인 이슈를 올려도 에이전트가 이를 실행하는 환경에서는 사용할 수 없다. 회사 내부 팀, 접근이 통제된 레포에서의 사용이 현재 상정된 컨텍스트다.

왜 지금인가

Codex의 앱 서버 모드(App-Server mode)가 공개된 것이 Symphony 등장의 직접적인 전제조건이었다. 앱 서버 모드는 Codex를 stdio 위의 JSON-RPC 서버로 실행하는 방식이다. 이 프로토콜이 있어야 Symphony 같은 오케스트레이터가 Codex를 서브프로세스로 기동하고, 이벤트 스트림을 수신하고, 에이전트 상태를 추적할 수 있다.

→ initialize     (오케스트레이터가 설정 전송)
← initialized    (Codex 확인)
← thread/start   (작업 스레드 시작)
← turn/start     (추론 턴 시작)
← turn/completed (턴 결과)
← turn/failed    (실패)

이 프로토콜의 중요한 특성은 Codex 전용이 아니라는 점이다. 동일한 인터페이스를 구현하는 Claude Code, 미래의 다른 에이전트도 Symphony에 연결할 수 있다. 오케스트레이터와 에이전트 사이의 인터페이스가 표준화된다면, 어느 에이전트를 쓸지는 WORKFLOW.md의 codex.command 한 줄을 바꾸는 문제가 된다.

그래서 이걸 어디에 쓸 수 있나

기술 스펙만 보면 감이 안 잡힐 수 있다. 구체적인 시나리오를 그려보자.

시나리오 1: 백로그 소화 기계. 스타트업 백엔드 팀이 5명이다. Linear 보드에 쌓인 버그 티켓이 30개. 우선순위 높은 기능 개발에 매달리느라 버그는 매주 밀린다. Symphony를 연결하면, Bug 라벨이 붙은 이슈가 Todo로 들어올 때마다 에이전트가 자동으로 분기를 따고, 수정하고, 테스트를 돌리고, PR을 올린다. 개발자는 출근해서 PR 리뷰만 하면 된다. 코드를 짜는 시간이 아니라 검토하는 시간만 쓴다.

시나리오 2: 야간 자동 처리. 퇴근 전에 이슈 5개를 Todo로 옮겨놓는다. 다음 날 아침 출근하면 PR 5개가 리뷰 대기 중이다. CI도 통과했고, 변경 사항 요약도 달려 있다. 에이전트가 밤새 일한 것이다. 개발자의 근무 시간과 에이전트의 작업 시간이 겹치지 않으므로 처리량이 사실상 두 배가 된다.

시나리오 3: 보일러플레이트 자동화. 새 API 엔드포인트를 추가할 때마다 라우터, 컨트롤러, DTO, 테스트, 문서를 반복적으로 만들어야 하는 프로젝트가 있다. 이슈에 “POST /api/orders 엔드포인트 추가, 스펙은 아래 참고”라고 적으면 에이전트가 기존 패턴을 학습해서 보일러플레이트를 생성한다. 반복 노동이 줄어들고, 개발자는 비즈니스 로직에 집중할 수 있다.

시나리오 4: 1인 개발자의 팀 확장. 혼자서 사이드 프로젝트를 운영하는 개발자에게 Symphony는 사실상 주니어 개발자 한 명을 고용하는 것과 비슷하다. 이슈를 적어놓으면 알아서 처리하고, 결과물을 검토만 하면 된다. 물론 코드 리뷰는 직접 해야 하지만, “구현”이라는 가장 시간 소모적인 단계를 위임할 수 있다.

공통적으로 중요한 전제가 있다. 테스트가 잘 갖춰진 프로젝트일수록 효과가 크다. 에이전트가 자기 작업을 스스로 검증할 수 있어야 하기 때문이다. 테스트 커버리지가 낮거나 수동 QA에 의존하는 프로젝트에서는 Symphony의 자율성이 발휘되기 어렵다.

접근성의 계단

Symphony가 제시하는 미래는 매력적이지만, 진입 장벽도 명확하다. 헤르메틱 테스트, 기계 가독 문서, 모듈형 아키텍처 — 이 세 가지를 모두 갖춘 코드베이스는 현재 소수다. 레거시 모노레포, 외부 서비스에 의존하는 테스트 스위트, 구전으로 전해지는 빌드 방법을 가진 팀에게 Symphony는 아직 먼 이야기다.

역설적으로, Symphony를 잘 활용할 수 있는 팀은 이미 에이전트 활용도가 높은 팀이다. 하네스 엔지니어링을 갖추는 과정 자체가 상당한 선행 투자를 요구한다. 신규 팀이 빈 레포에서 시작하기는 쉽지만, 기존 프로젝트를 Symphony에 맞게 개조하는 비용은 팀마다 다를 것이다.

그럼에도 불구하고 방향은 선명하다. OpenAI는 에이전트를 어떻게 쓸지를 제품으로 팔지 않고, 어떻게 하면 에이전트가 스스로 일하게 만들 수 있는지의 참조 설계를 오픈소스로 내놨다. Apache 2.0 라이선스는 기업 도입을 막을 제약이 없다.

Symphony의 진짜 가치는 258줄의 Elixir 코드가 아니다. “에이전트를 도구가 아니라 팀원처럼 운영하려면 오케스트레이션 레이어가 필요하다”는 명제를, 실행 가능한 형태로 증명했다는 데 있다.