① Symphony란 무엇인가 — 에이전트 감독의 종말

OpenAI Symphony는 2026년 3월 4일(UTC 기준) GitHub에 공개된
오픈소스 AI 에이전트 오케스트레이터입니다.
한 줄로 정의하자면, “프로젝트 관리 도구(이슈 트래커)에 등록된 작업을 AI 코딩 에이전트가
자율적으로 처리하도록 연결해주는 인프라”입니다.

지금까지 Cursor, Claude Code, Codex 같은 도구들은 눈부시게 발전해왔지만 근본적인 병목이
남아 있었습니다. 에이전트가 아무리 똑똑해져도 사람이 옆에서 지켜보며 작업을 하나씩
맡겨야 하는 구조가 바뀌지 않았던 것입니다. 에이전트 하나를 감독하는 데 드는 인지 비용이
직접 코딩하는 것과 별반 다르지 않다면, 이것을 ‘생산성 혁신’이라고 부를 수 있을까요?

Symphony의 답은 명확합니다. “에이전트를 감독(supervise)하는 것에서
업무를 관리(manage work)하는 것으로 패러다임을 전환한다.”
개발자가 Linear에 이슈를 등록하면, Symphony가 이를 감지하고 격리된 워크스페이스에서
에이전트를 생성합니다. 에이전트는 코드 작성, 테스트 실행, PR 생성, 리뷰 피드백 반영까지
자율적으로 수행한 뒤 “작업 증거(proof of work)”와 함께 결과를 보고합니다.
개발자는 완성된 결과물만 검토하면 됩니다.

Apache 2.0 라이선스로 공개된 Symphony는 Elixir/Erlang BEAM 런타임 기반 레퍼런스 구현체와
함께, 언어에 구애받지 않는 SPEC.md 사양서를 제공합니다.
“너의 코딩 에이전트에게 이 스펙대로 구현하라고 시켜라”는 설치 가이드 자체가 Symphony의
철학을 단적으로 보여줍니다. 에이전트가 충분히 똑똑하다면, 스펙만 주면 자기 자신을 만들 수
있어야 한다는 것입니다.

▲ 목차로 돌아가기

② 핵심 선행 개념: 하네스 엔지니어링(Harness Engineering)이 왜 중요한가

Symphony를 이해하고 실제로 도입하려면 OpenAI가 2026년 2월에 공식 방법론으로 정리한
하네스 엔지니어링(Harness Engineering)을 먼저 알아야 합니다.
이것은 “AI 코딩 에이전트가 효과적으로 동작할 수 있도록 코드베이스 자체를 정비하는 접근법”입니다.

OpenAI 팀은 5개월간 약 7명의 엔지니어로 수동으로 코드 한 줄도 작성하지 않고
백만 라인 규모의 소프트웨어 제품을 구축한 실험을 진행했습니다.
1인당 하루 평균 3.5개의 PR을 처리했고, 수동 작성 대비 약 10배 빠른 개발 속도를 달성했습니다.
이 실험의 핵심 통찰은 “에이전트가 볼 수 없는 것은 존재하지 않는 것”이라는 점입니다.

하네스 엔지니어링 4가지 핵심 요건

특히 문서화 전략은 OpenAI가 강조하는 부분입니다. 거대한 단일 매뉴얼 대신 목차 역할의
짧은 AGENTS.md(약 100줄)를 두고, 세부 내용은 docs/design-docs/,
docs/exec-plans/, docs/product-specs/ 등으로 분산 관리하는 방식을
권장합니다. 이 모든 문서는 Git 저장소 안에 버전 관리되어야 합니다.
Slack 대화나 Google Docs에 흩어진 지식은 AI 에이전트가 인식할 수 없기 때문입니다.

▲ 목차로 돌아가기

③ Symphony 아키텍처 8대 컴포넌트 완전 해부

Symphony의 내부 설계는 SPEC.md를 통해 완전히 공개되어 있습니다.
8개의 핵심 컴포넌트가 유기적으로 맞물려 작동합니다.

8대 컴포넌트 개요

왜 Elixir·BEAM인가

OpenAI가 Python·TypeScript 대신 Elixir를 레퍼런스 언어로 선택한 이유는 명확합니다.
AI 에이전트 작업은 수십 분씩 이어지는 장시간 실행이 기본이며, 중간에 실패할 가능성이 항상
존재합니다. Erlang/OTP의 슈퍼비전 트리(Supervision Tree)는 수백 개의
독립 프로세스를 동시에 관리하면서 하나가 충돌해도 전체 시스템에 영향을 주지 않습니다.
“Let it crash(충돌해도 괜찮다)” 철학 — 에러를 예방하는 대신 빠르게 복구하는
구조가 AI 자동화 인프라에 정확히 맞아떨어집니다.

▲ 목차로 돌아가기

④ 설치 및 설정 — WORKFLOW.md 작성법 실전 가이드

Symphony 설치는 두 가지 경로 중 하나를 선택합니다. 두 방법 모두 공식 지원이며,
팀의 기술 스택에 따라 선택하면 됩니다.

방법 1: AI 에이전트에게 직접 구현 요청 (권장)

OpenAI가 가장 적극적으로 권장하는 방법입니다. 원하는 언어(Python, TypeScript, Go 등)로
AI 에이전트에게 아래 프롬프트를 전달하면, 에이전트가 SPEC.md를 읽고 직접 구현합니다.

Implement Symphony according to the following spec:

방법 2: 공식 Elixir 레퍼런스 구현체 사용

git clone https://github.com/openai/symphony.git
cd symphony/elixir
# 의존성 설치
mix deps.get
# 환경 변수 설정
export LINEAR_API_KEY="your-api-key-here"
# 실행
mix run --no-halt

WORKFLOW.md — Symphony의 핵심 설정 파일

WORKFLOW.md는 YAML 프론트매터(설정) + 마크다운 본문(에이전트 프롬프트 템플릿)으로
구성됩니다. 이 파일 하나로 폴링 주기, 동시 에이전트 수, 품질 게이트, 에이전트 행동 지침을
모두 관리할 수 있습니다. 수정 즉시 재시작 없이 동적으로 반영됩니다.

---
tracker:
kind: linear
api_key: $LINEAR_API_KEY
project_slug: YOUR-PROJECT-ID
active_states:
- Todo
- In Progress
terminal_states:
- Done
- Closed
- Cancelled
polling:
interval_ms: 30000        # 30초마다 폴링
workspace:
root: ~/symphony_workspaces
hooks:
after_create: |
git clone https://github.com/your-org/your-repo.git .
npm install
before_run: |
git pull origin main
after_run: |
pnpm typecheck && pnpm test  # 품질 게이트
agent:
max_concurrent_agents: 5
max_turns: 20
server:
port: 8080
You are a software development agent working on Linear issues.
## Current Issue
- **Identifier**: {{ issue.identifier }}
- **Title**: {{ issue.title }}
- **Description**: {{ issue.description }}
## Guidelines
- Move the issue to "In Progress" before starting
- Write clean, well-tested code
- Run all tests before creating a PR
- Post a progress comment on the issue when complete

▲ 목차로 돌아가기

⑤ 이슈 → PR까지: 구현 실행 수명 주기 전체 흐름

Linear에 이슈가 등록된 순간부터 PR이 머지되기까지, Symphony 내부에서 일어나는 과정을
단계별로 살펴봅니다. 이 흐름을 이해하면 어디서 문제가 발생하는지, 어떻게 개입해야 하는지를
판단하기 훨씬 쉬워집니다.

실패 시 재시도 메커니즘

에이전트가 정상 종료했지만 이슈가 아직 활성 상태라면 1초 후 즉시 재개합니다.
비정상 종료(실패) 시에는 지수 백오프(10초 × 2^n, 최대 5분)가 적용됩니다.
외부 데이터베이스 없이 인메모리 상태만으로 동작하므로, 재시작해도 이슈 트래커에서
최신 상태를 다시 가져와 복구됩니다.

▲ 목차로 돌아가기

⑥ Stokowski: Claude Code 사용자를 위한 Symphony 대안

Symphony의 공식 구현체는 Codex를 에이전트로 사용합니다. 그런데 Claude Code를 주로 쓰는
개발자라면 어떨까요? 2026년 3월 7일, Reddit에 Stokowski라는 오픈소스
프로젝트가 공개됐습니다. 지휘자의 이름을 딴 것이 이미 의도를 드러냅니다 — Symphony를
오케스트레이션하는 지휘자입니다.

Stokowski는 OpenAI의 Symphony SPEC.md를 그대로 따르되, 에이전트를 Codex 대신
Claude Code로 교체한 Python 구현체입니다. Linear + GitHub + Claude Code를
연결하는 파이프라인으로, MCP(.mcp.json) 설정도 자동으로 불러오기 때문에 Figma MCP,
Linear MCP, Playwright 등 기존에 설정해둔 도구들을 에이전트가 그대로 활용합니다.

Stokowski vs Symphony 비교

개인적인 의견을 덧붙이자면, Claude Code 기반 팀이라면 Stokowski가 더 현실적인 선택일 수
있습니다. Claude Sonnet 4.6의 향상된 Computer Use와 에이전트 플래닝 능력,
그리고 MCP 생태계가 이미 팀에 구축되어 있다면 Stokowski를 통해 Symphony의 이점을
그대로 누릴 수 있습니다. 다만 아직 초기 단계이므로 프로덕션 적용 전에 충분한 테스트가 필요합니다.

▲ 목차로 돌아가기

⑦ 한계와 현실 — 프로덕션 도입 전 반드시 알아야 할 것들

솔직히 말하겠습니다. 현재의 Symphony는 "프로덕션 도구"보다 "비전 선언"에 더 가깝습니다.
OpenAI 스스로 "low-key engineering preview for testing in trusted environments"라고 명시했습니다.
다음 한계점을 파악하고 도입 여부를 판단하시길 권장드립니다.

그럼에도 Symphony가 그리는 미래는 설득력이 있습니다. 2025년이 "에이전트가 코드를 쓸 수 있다"를
증명한 해였다면, 2026년은 "에이전트를 어떻게 대규모로 운용할 것인가"가
핵심 경쟁축이 됩니다. Symphony는 그 경쟁의 첫 번째 공개 답안입니다.
엔지니어링의 추상화 수준이 어셈블리→고급언어→프레임워크→코드 작성→작업 정의와 검증으로
또 한 단계 올라가는 과정을 우리는 지금 목격하고 있는 것입니다.

▲ 목차로 돌아가기