OpenAI Symphony - 코딩 에이전트를 감독하지 않는 시대, 에이전트 기반 프로젝트 관리 자동화

개요

OpenAI가 2026년 3월 공개한 Symphony는 프로젝트 작업을 격리된 자율 실행(run) 형태로 전환하여, 개발팀이 코딩 에이전트를 직접 감독하는 대신 작업 단위의 결과물을 관리할 수 있게 해주는 오픈소스 프레임워크입니다. 기존의 "개발자 → AI에게 프롬프트 → 리뷰 → 수정 → 반복" 패턴에서 벗어나, "프로젝트 작업 → Symphony 실행 → 에이전트 구현 → 증거 생성 → 사람 리뷰 → 병합"이라는 새로운 패러다임을 제시합니다.

---

Symphony가 해결하는 문제

현재 AI 코딩 도구를 사용하는 대부분의 팀은 에이전트를 일일이 감독해야 합니다. 프롬프트를 작성하고, 결과를 확인하고, 피드백을 주고, 다시 수정을 요청하는 과정의 반복입니다. 이 방식은 에이전트가 아무리 빨라도 사람의 감독 시간이 병목이 됩니다.
Symphony는 이 병목을 제거합니다. 개발자의 역할을 "AI를 감독하는 사람"에서 "완성된 작업을 관리하는 프로젝트 매니저"로 전환합니다. 작업을 정의하면 에이전트가 독립적으로 수행하고, 완료 증거를 제출하면 사람이 결과만 검토하는 구조입니다.

---

핵심 동작 원리

Symphony의 동작은 크게 5단계로 나뉩니다.

1단계: 이슈 트래커 모니터링

Symphony는 장기 실행 데몬(daemon)으로 동작하며, Linear 같은 이슈 트래커의 프로젝트 보드를 지속적으로 폴링합니다. 설정된 상태(예: "Ready for Agent", "Todo")에 해당하는 작업이 감지되면 자동으로 다음 단계를 시작합니다.

• 폴링 간격은 polling.interval_ms로 설정 (기본값: 30초)
• 활성 상태(active_states)와 종료 상태(terminal_states)를 구분하여 관리
• 우선순위 기반 후보 선택으로 중요한 작업부터 처리

2단계: 격리된 워크스페이스 생성

작업이 감지되면 Symphony는 해당 이슈 전용의 격리된 파일시스템 디렉토리를 생성합니다. 이 워크스페이스는 다른 동시 실행 중인 작업과 완전히 분리됩니다.

• 이슈 식별자 기반의 결정론적 디렉토리 명명 (경로 탈출 방지를 위한 살균 처리)
• after_create 훅으로 Git 클론 등 초기 설정 자동 실행
• before_run 훅으로 의존성 설치(예: npm install) 자동 처리
• 워크스페이스는 재시도 시에도 재사용되어 일관성 유지

3단계: 에이전트 실행

워크스페이스가 준비되면 Symphony는 코딩 에이전트(현재 참조 구현에서는 Codex)를 App Server 모드로 해당 워크스페이스 내에서 실행합니다.

• WORKFLOW.md에 정의된 지침을 에이전트에 전달
• 기본 1시간의 턴 타임아웃 (codex.turn_timeout_ms)
• 최대 동시 에이전트 수 제한 (기본값: 10, max_concurrent_agents)
• 상태별 동시 실행 수 별도 제한 가능 (max_concurrent_agents_by_state)
• 토큰 사용량, 턴 수, 이벤트 로그 등 세션 메타데이터 추적

4단계: 작업 증거(Proof of Work) 제출

에이전트가 작업을 완료하면 단순히 코드만 제출하는 것이 아닙니다. Symphony는 작업 증거(Proof of Work) 시스템을 통해 작업의 품질을 검증합니다.

• CI/CD 상태: 모든 테스트가 통과했는지 확인
• PR 리뷰 피드백: 코드 리뷰 결과 반영 및 대응
• 복잡도 분석: 변경 사항의 복잡도 리포트 생성
• 실행 영상(Walkthrough Video): 변경 사항을 시연하는 워크스루 영상 자동 생성

이 증거들이 모두 충족되어야 작업이 "완료" 상태로 전환됩니다. 단순히 코드를 생성하는 것이 아니라, 검증 가능한 결과물을 제출하는 것이 Symphony의 핵심 차별점입니다.

5단계: 승인 및 자동 PR 병합

사람이 증거를 리뷰하고 승인하면, Symphony는 Pull Request를 자동으로 병합합니다. 전체 과정에서 사람의 개입은 최종 승인 단계에만 집중됩니다.

---

WORKFLOW.md 설정 구조

Symphony의 모든 동작은 WORKFLOW.md 파일 하나로 정의됩니다. YAML 프론트매터와 마크다운 프롬프트 템플릿으로 구성됩니다.

---
tracker:
  kind: linear
  api_key: $LINEAR_API_KEY
  project_slug: MY-PROJECT

polling:
  interval_ms: 30000

workspace:
  root: /path/to/workspaces

hooks:
  after_create: |
    git clone $REPO_URL .
  before_run: |
    npm install
  after_run: |
    echo "Cleanup complete"
  timeout_ms: 60000

agent:
  max_concurrent_agents: 10
  max_retry_backoff_ms: 300000

codex:
  command: codex app-server
  turn_timeout_ms: 3600000
  approval_policy: auto
  thread_sandbox: workspace-write
---

# Workflow Prompt

이슈에 명시된 작업을 구현하세요.
모든 테스트가 통과하는지 확인하고,
변경 사항에 대한 워크스루를 생성하세요.

주요 설정 항목을 정리하면 다음과 같습니다.

• tracker: 이슈 트래커 연동 설정 (현재 Linear 지원, $VARIABLE 형태의 환경 변수 참조 지원)
• polling: 이슈 트래커 폴링 주기
• workspace: 격리된 작업 디렉토리 루트 경로
• hooks: 워크스페이스 라이프사이클별 실행 스크립트 (after_create, before_run, after_run, before_remove)
• agent: 동시 실행 제한 및 재시도 백오프 설정
• codex: 에이전트 명령어, 타임아웃, 샌드박스 정책

---

아키텍처: 7개 핵심 컴포넌트

Symphony의 내부 아키텍처는 SPEC 문서에서 7개 핵심 컴포넌트로 정의됩니다.

• Workflow Loader: WORKFLOW.md 파일을 파싱하여 YAML 설정과 프롬프트 템플릿을 추출
• Config Layer: 환경 변수 참조($VAR)를 지원하는 타입 안전 설정 관리
• Issue Tracker Client: Linear API에서 후보 작업을 가져오고, 상태를 정규화하여 통합 이슈 모델로 변환
• Orchestrator: 폴링, 디스패치 결정, 동시성 관리, 재시도 로직을 담당하는 핵심 엔진
• Workspace Manager: 이슈별 격리 디렉토리 생성/관리, 라이프사이클 훅 실행
• Agent Runner: 코딩 에이전트 서브프로세스를 stdio 프로토콜로 실행, JSON-RPC 기반 통신
• Logging & Observability: 구조화된 이벤트 로깅, 선택적 HTTP 대시보드 제공

이 컴포넌트들은 정책(Policy) → 설정(Configuration) → 조율(Coordination) → 실행(Execution) → 통합(Integration) → 관찰(Observability) 계층으로 조직됩니다.

---

Harness Engineering: 에이전트 최적화 코드베이스

Symphony가 최적의 성능을 발휘하려면 코드베이스가 Harness Engineering 원칙을 채택해야 합니다. 이는 OpenAI가 제시한 코딩 에이전트 관리 방법론으로, 코드베이스를 기계가 읽고 검증하기 쉬운 구조로 만드는 것을 의미합니다.
Harness Engineering의 핵심 요구사항은 다음과 같습니다.

• 밀봉형(Hermetic) 테스트 스위트: 외부 의존성 없이 자체 완결적으로 실행 가능한 테스트 환경. 에이전트가 자신의 작업을 스스로 검증할 수 있어야 합니다.
• 모듈형 아키텍처: 작업 단위가 명확하게 분리되어 에이전트가 전체 시스템을 이해하지 않고도 특정 모듈을 수정할 수 있는 구조
• 명확한 인터페이스 정의: 모듈 간 경계가 잘 정의되어 에이전트의 변경이 다른 부분에 예상치 못한 영향을 주지 않는 구조

Symphony는 Harness Engineering의 다음 단계로, 에이전트의 행동을 관리하는 것에서 결과물을 관리하는 것으로의 진화를 나타냅니다.

---

Elixir 참조 구현체

Symphony의 참조 구현체는 Elixir 언어로 작성되었습니다 (코드베이스의 약 94.9%). Elixir를 선택한 이유는 명확합니다.

• Erlang/BEAM/OTP 기반: 장기 실행 프로세스 감독에 최적화된 런타임. 각 에이전트를 독립 프로세스로 관리하여 하나의 에이전트 실패가 전체 시스템에 영향을 주지 않습니다.
• 높은 동시성: 수십 개의 에이전트가 동시에 실행되어도 서로 간섭하지 않는 프로세스 격리 모델
• 핫 코드 리로딩: 실행 중인 에이전트를 중단하지 않고도 Symphony 자체를 업데이트할 수 있는 기능

설치 및 실행

# 저장소 클론
git clone https://github.com/openai/symphony
cd symphony/elixir

# 의존성 설치 (mise 패키지 매니저 사용)
mise trust && mise install
mise exec -- mix setup
mise exec -- mix build

# Symphony 실행
mise exec -- ./bin/symphony ./WORKFLOW.md

웹 대시보드

--port 옵션을 지정하면 Phoenix LiveView 기반의 관찰 대시보드를 사용할 수 있습니다.

mise exec -- ./bin/symphony ./WORKFLOW.md --port 4000

대시보드에서는 실행 중인 에이전트 상태, 이슈 진행 상황을 실시간으로 모니터링할 수 있으며, JSON API 엔드포인트(/api/v1/state, /api/v1/<issue>)도 제공됩니다.

---

SPEC 문서: 다른 언어로 직접 구현

Elixir 참조 구현체 외에도 Symphony는 SPEC.md 문서를 통해 완전한 기술 사양을 공개하고 있습니다. 이 사양을 기반으로 어떤 언어로든 Symphony를 직접 구현할 수 있습니다.
SPEC 문서에서 정의하는 핵심 사양은 다음과 같습니다.

• 이슈 모델 정규화: id, identifier(예: "ABC-123"), title, description, priority, state, labels, blocked_by 등 통합 필드 정의
• 상태 머신: Pending → Running → Retrying → Released의 오케스트레이션 상태 전이
• 동시성 제어: 글로벌 및 상태별 동시 실행 수 제한, 우선순위 기반 디스패치
• 재시도 로직: 실패 시 지수 백오프 (최대 max_retry_backoff_ms, 기본 5분)
• 에이전트 프로토콜: stdio 기반 JSON-RPC 유사 핸드셰이크 및 스트리밍 프로토콜
• 복구 메커니즘: 영속 데이터베이스 없이 워크스페이스 파일시스템과 이슈 트래커 상태로부터 인메모리 상태 재구성

SPEC 문서의 미지원 키는 하위 호환성을 위해 무시되므로, 점진적으로 새로운 기능을 추가하는 것도 가능합니다.

---

실전 데모 시나리오

Symphony의 공식 데모에서 보여주는 전체 워크플로우를 시나리오로 정리하면 다음과 같습니다.
1. Linear 보드에 작업 생성
팀원이 Linear에서 "사용자 프로필 페이지 반응형 레이아웃 구현" 이슈를 생성하고, 상태를 "Ready for Agent"로 변경합니다.

2. Symphony가 자동 감지
30초 간격으로 폴링 중이던 Symphony가 새 작업을 감지하고, 해당 이슈 전용 격리 워크스페이스를 생성합니다. after_create 훅이 실행되어 리포지토리가 클론됩니다.

3. 에이전트 할당 및 실행
에이전트가 자동으로 생성되어 워크스페이스 내에서 작업을 시작합니다. 이슈 설명과 WORKFLOW.md의 지침을 기반으로 코드를 작성합니다.

4. 작업 증거 제출
에이전트가 작업을 완료하면 다음 증거를 제출합니다.

• CI 파이프라인 실행 결과 (모든 테스트 통과)
• PR에 대한 자동 코드 리뷰 피드백 처리
• 변경 사항의 복잡도 분석 리포트
• 구현된 기능을 시연하는 워크스루 영상

5. 리뷰 및 자동 병합
팀 리드가 증거를 검토하고 승인하면, Symphony가 자동으로 PR을 병합합니다. Linear 이슈도 자동으로 "Done" 상태로 전환됩니다.

---

보안 및 운영 안전성

Symphony는 격리된 환경에서의 에이전트 실행을 전제로 설계되었지만, 몇 가지 보안 정책을 제공합니다.

• 샌드박스 정책: thread_sandbox 설정으로 에이전트의 파일시스템 접근 수준 제어 (read-only, workspace-write, danger-full-access)
• 승인 정책: approval_policy로 샌드박스 위반 시 동작 제어
• 훅 타임아웃: 무한 대기 방지를 위한 기본 60초 타임아웃
• 워크스페이스 격리: 경로 탈출 방지를 위한 키 살균(sanitization) 처리
• 비밀 관리: $VARIABLE 간접 참조로 API 키 등 민감 정보 보호

SPEC 문서는 Symphony가 "신뢰할 수 있는 환경"에서의 실행을 가정하며, 각 구현체는 자체적인 보안 정책을 명시적으로 문서화할 것을 요구합니다.

---

라이선스 및 커뮤니티

• 라이선스: Apache License 2.0 (상업적 사용, 수정, 배포 자유)
• GitHub: openai/symphony (6.2k+ 스타, 383+ 포크)
• 상태: 프로젝트 프리뷰(실험적 단계)

Apache 2.0 라이선스는 기업 환경에서도 자유롭게 사용할 수 있으며, SPEC 문서를 기반으로 자체 구현체를 만들어도 라이선스 제약이 없습니다.

---

마무리

Symphony는 AI 코딩 에이전트의 활용 패러다임을 근본적으로 바꾸는 프레임워크입니다. 핵심은 단순합니다. 에이전트의 코딩 속도를 높이는 것이 아니라, 엔지니어링 팀이 AI와 협업하는 방식을 재구성하는 것입니다.
기존 방식에서는 개발자가 AI의 "운전자"였다면, Symphony에서는 "교통 관제사"가 됩니다. 작업을 정의하고, 증거를 검토하고, 최종 승인만 내리면 됩니다. 아직 프로젝트 프리뷰 단계이지만, Harness Engineering과 결합하여 코드베이스를 에이전트 친화적으로 구조화한 팀이라면 바로 실험해볼 만한 가치가 있습니다.

---

참고 자료

• OpenAI Symphony GitHub 리포지토리
• Symphony SPEC 문서
• Symphony Elixir 구현체 README
• MarkTechPost - OpenAI Releases Symphony
• Top AI Product - Symphony 분석

이 글은 Claude Code를 활용하여 작성되었습니다.