OpenAI Symphony, 티켓 쓰면 코드가 나옵니다

Published on

2026년 3월 28일

2026.03.05 공개 기준
Engineering Preview
Apache 2.0 오픈소스

OpenAI Symphony, 티켓 쓰면 코드가 나옵니다

2026년 3월 5일, OpenAI가 Symphony를 깃허브에 공개했습니다.
이름은 생소하지만 개념은 단순합니다. Linear 보드에 티켓을 올려두면
AI 에이전트가 알아서 코드를 작성하고 PR을 만들어 줍니다. 사람이 할 일은
결과 검토뿐입니다. 그런데 공식 문서를 직접 읽어보면 “아, 이 조건이 있었구나”
싶은 부분이 생각보다 많습니다.

30초

기본 폴링 주기

최대 10개

동시 에이전트 기본값

Linear 전용

현재 지원 이슈 트래커

Symphony가 하는 일 한 줄 요약

OpenAI Symphony는 이슈 트래커를 주기적으로 확인하면서
‘에이전트가 처리할 수 있는’ 상태의 티켓을 발견하면 자동으로 독립된 작업 공간을 만들고,
Codex AI 에이전트를 실행해서 코드를 작성하고 PR을 생성하는 오케스트레이션 서비스입니다.
(출처: OpenAI GitHub 공식 리포지터리, 2026.03.05)

중요한 건 이것이 “AI한테 코딩을 시키는 도구”가 아니라는 점입니다.
기존 코딩 어시스턴트들은 사람이 먼저 프롬프트를 쳐야 움직였습니다.
Symphony는 반대입니다. 사람이 티켓만 만들어두면 시스템이 알아서 작업을 집어가고,
완료 시점에 검증된 PR을 돌려줍니다. 사람의 역할이 ‘코드를 쓰는 사람’에서
‘작업을 정의하고 결과를 검토하는 사람’으로 바뀌는 구조입니다.

💡 공식 리포지터리에는 이렇게 나옵니다:
“Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.”
— github.com/openai/symphony README (2026.03.05)

에이전트를 ‘감시’하는 게 아니라 ‘작업 자체를 관리’하는 것으로 추상화 수준을 높인 도구입니다.
이 차이가 Symphony가 다른 코딩 에이전트들과 결정적으로 다른 지점입니다.

▲ 목차로 돌아가기

흐름을 알면 ‘와, 이게 되네’ 합니다

Symphony의 핵심 작동 순서는 아래와 같습니다.
공식 SPEC.md에 명시된 내용을 기반으로 정리했습니다.
(출처: github.com/openai/symphony/blob/main/SPEC.md, 2026.03.05 기준)

① 폴링 (30초 주기)

Linear 보드를 30초마다 확인해서 “에이전트 처리 가능” 상태 티켓을 찾습니다.

② 격리 워크스페이스 생성

티켓 1개당 독립된 폴더를 만들고 리포지터리를 클론합니다. 작업들이 서로 충돌하지 않습니다.

③ Codex 에이전트 실행

WORKFLOW.md에 적힌 프롬프트 템플릿으로 에이전트를 구동합니다. 최대 20턴까지 자율 실행합니다.

④ 작업 증명(Proof of Work)

CI 결과, 단위 테스트 통과 여부, PR 리뷰 피드백, 코드 복잡도 분석까지 검증 후 PR을 생성합니다.

실패해도 알아서 재시도합니다

에이전트가 실패하면 지수 백오프 방식으로 재시도 대기열에 들어갑니다.
공식 SPEC.md에 명시된 지연 시간 공식은 아래와 같습니다.

지연 = min(10,000ms × 2^(시도횟수-1), 최대 300,000ms)

1회: 10초 → 2회: 20초 → 3회: 40초 → 4회: 80초 → 5회: 160초 → 6회~: 300초(5분) 고정

최대 재시도를 모두 소진하면 티켓이 다시 ‘미처리’ 상태로 되돌아가 사람이 직접 처리할 수 있게 됩니다.
무한 루프에 빠지지 않도록 안전장치가 설계된 것입니다.

▲ 목차로 돌아가기

쓸 수 있는 사람과 바로 못 쓰는 사람

Symphony를 실제로 돌리려면 이슈 트래커가 Linear여야 합니다.
GitHub Issues를 쓰는 팀이라면 지금 당장은 못 씁니다.
현재 공식 지원 트래커는 Linear 하나뿐이고, GitHub Issues·Jira 어댑터는
“로드맵에 있다”고만 나와 있습니다.
(출처: ComposioHQ agent-orchestrator discussions #526, 2026.03.27)

✅ 지금 바로 쓸 수 있는 조건 (전부 충족해야 함)

이슈 트래커: Linear (Linear API Key 필요)
에이전트 런타임: OpenAI Codex (OpenAI API Key 필요)
실행 환경: Elixir 1.15+ / Erlang OTP 26+
코드베이스에 WORKFLOW.md 파일 작성 완료

❌ 지금은 사용 불가 조건

GitHub Issues를 이슈 트래커로 쓰는 팀
Jira·Notion·Asana를 메인 트래커로 쓰는 팀
Codex 대신 Claude·Gemini 에이전트를 쓰고 싶은 경우 (별도 App-Server Protocol 구현 필요)

‘하네스 엔지니어링’ 환경이 먼저입니다

Symphony 공식 README에는 이런 문구가 있습니다.
“Symphony works best in codebases that have adopted harness engineering.”
(출처: github.com/openai/symphony README, 2026.03.05)

하네스 엔지니어링이란 AI 에이전트가 안정적으로 작동할 수 있도록 설계된 코드베이스 구조를 의미합니다.
외부 서비스 의존 없이 독립적으로 실행 가능한 테스트, AI가 읽을 수 있는 문서,
모듈화된 코드 구조가 갖춰져 있어야 합니다.
레거시 코드가 뒤엉킨 프로젝트에 Symphony를 바로 붙이면 에이전트 실패율이 높을 수밖에 없습니다.

▲ 목차로 돌아가기

WORKFLOW.md가 결국 전부입니다

Symphony를 쓰면서 가장 먼저 맞닥뜨리는 현실은 이겁니다.
에이전트가 얼마나 잘 작동하느냐는 WORKFLOW.md를 얼마나 잘 썼느냐에 달려 있습니다.
환경 변수 설정이나 Elixir 설치보다 이 파일 하나가 에이전트 결과 품질을 좌우합니다.

💡 실제로 공식 문서와 SPEC.md를 같이 읽어보면 구조가 보입니다.
WORKFLOW.md 안에는 YAML 프론트 매터(설정)와 Liquid 템플릿(에이전트 프롬프트)이 함께 있습니다.
팀의 작업 규칙과 에이전트의 행동 방식이 코드와 함께 버전 관리된다는 의미이고,
PR 리뷰에서 에이전트 행동 변경 내역도 추적할 수 있습니다.

WORKFLOW.md의 핵심 설정 항목

항목	기본값	역할
polling.interval_ms	30,000ms	Linear 보드 확인 주기
agent.max_concurrent_agents	10개	동시 실행 에이전트 수 (= API 비용 직결)
agent.max_turns	20턴	에이전트 1회 실행 당 최대 대화 횟수
codex.turn_timeout_ms	3,600,000ms (1시간)	에이전트 단일 턴 최대 실행 시간
hooks.after_create	없음	워크스페이스 생성 후 실행 스크립트 (npm install 등)

특히 max_concurrent_agents 값이 중요합니다.
기본값 10개로 설정된 상태에서 복잡한 작업을 동시에 돌리면
Codex API 토큰 비용이 예상보다 빠르게 소진될 수 있습니다.

WORKFLOW.md는 재시작 없이 실시간 반영됩니다.
파일을 수정하면 다음 폴링 사이클부터 새 설정이 적용됩니다.
(출처: SPEC.md Section 6.2 Dynamic Reload Semantics)

▲ 목차로 돌아가기

공식 문서에서 확인한 현실적인 한계

Symphony가 소개될 때 “티켓 하나면 코드가 자동으로 나온다”는 식으로 퍼졌습니다.
틀린 말은 아닌데, 공식 README에는 “Engineering Preview for testing in trusted environments”라는
경고 배너가 달려 있습니다. 프로덕션 투입 전 읽어야 할 내용이 있습니다.

📌 티켓 품질이 나쁘면 코드 품질도 나쁩니다

많은 글에서 “에이전트가 알아서 다 해준다”고 쓰지만, 공식 문서는 반대로 명시합니다.
“Issue quality matters — Symphony is only as good as your issue descriptions.”
(출처: heyuan110.com, OpenAI Symphony 상세 가이드, 2026.03.06)
모호한 티켓은 모호한 코드를 냅니다. 결론적으로 가장 중요한 인풋은 티켓 작성 실력입니다.

📌 병렬 작업이 가능하지만 비용은 선형으로 증가합니다

기본 설정 기준 동시에 최대 10개 작업을 병렬 처리할 수 있습니다.
문제는 에이전트 1개당 Codex API 토큰을 독립적으로 소비한다는 점입니다.
1개 티켓 처리에 1만 토큰이 든다면 10개 동시 처리 시 10만 토큰이 소요됩니다.
규모가 커질수록 비용 추적이 필수입니다.

잘 맞는 작업 유형과 맞지 않는 작업 유형

✅ 잘 작동하는 경우

재현 단계가 명확한 버그 수정
테스트 코드 작성
문서 업데이트 및 유지보수
의존성 업그레이드
범위가 좁고 잘 정의된 기능 추가

❌ 아직 어려운 경우

여러 모듈을 가로지르는 아키텍처 리팩터링
복잡한 비즈니스 로직 설계
설명이 모호하거나 맥락이 없는 작업
레거시 코드가 뒤엉킨 코드베이스

Symphony 자체는 아직 ‘엔지니어링 미리보기(Engineering Preview)’ 단계입니다.
공식 README에 “trusted environments”에서 테스트하라고 명시된 이유가 있습니다.
PR은 반드시 사람이 검토 후 병합해야 하며,
Codex가 만든 코드를 자동으로 메인 브랜치에 병합하는 설정은 권장하지 않습니다.

▲ 목차로 돌아가기

비교: Symphony vs 다른 자동화 도구들

공식 발표 자료와 커뮤니티 분석을 교차해서 보면
Symphony가 어디에 위치하는지 더 선명하게 보입니다.
같은 날인 2026년 3월 5일, GitHub Copilot의 Jira용 코딩 에이전트가 퍼블릭 프리뷰로 나왔고,
Google ADK도 Linear·Jira·Asana·Notion 연동을 확장했습니다.
(출처: sjramblings.io, OpenAI Symphony 아키텍처 분석, 2026.03.12)
프로젝트 자동화 경쟁이 같은 날에 동시에 치열해진 셈입니다.

항목	Symphony	GitHub Copilot 에이전트	Devin
오픈소스	✅ Apache 2.0	❌	❌
셀프 호스팅	✅ 가능	❌ GitHub 호스팅	❌ 클라우드 전용
이슈 트래커	Linear (확장 가능)	GitHub Issues 전용	자체 시스템
동시 처리	최대 10개 (기본)	1개 (리포 당)	1개 (세션 당)
커스터마이징	WORKFLOW.md 전체 제어	제한적	제한적

Symphony의 가장 큰 차별점은 팀 소유의 설정 파일이 코드베이스 안에 있다는 겁니다.
에이전트 행동 방식이 환경 변수나 외부 대시보드 설정이 아니라,
PR 리뷰로 추적 가능한 파일로 관리됩니다.
어떤 외부 플랫폼도 이 방식을 쓰지 않는다는 점이 현 시점에서 실질적인 차이점입니다.

▲ 목차로 돌아가기

Q&A — 가장 많이 묻는 것들

Q1. Symphony 자체는 무료인가요?

네. Symphony 코드 자체는 Apache 2.0 오픈소스로 무료입니다.
단, 실제로 쓰려면 OpenAI API Key(Codex 실행 비용)와 Linear API Key(이슈 트래커 연동)가 필요합니다.
두 서비스 모두 유료 과금이 발생할 수 있습니다.

Q2. GitHub Issues로도 쓸 수 있나요?

지금은 안 됩니다. 현재 공식 지원 트래커는 Linear뿐입니다.
GitHub Issues 어댑터는 커뮤니티에서 개발 중이라는 언급이 있지만,
공식 로드맵이나 출시 일정이 공개된 바는 없습니다.
(출처: ComposioHQ GitHub discussions, 2026.03.27 기준)

Q3. Elixir를 모르면 못 쓰나요?

레퍼런스 구현체가 Elixir/OTP 기반이라 실행 환경이 필요합니다.
Elixir 코드를 직접 작성할 줄 몰라도 설치 및 실행 자체는 가능합니다.
SPEC.md가 언어 독립적으로 작성되어 있어서, 원한다면 다른 언어로 직접 구현할 수도 있습니다.

Q4. 에이전트가 코드를 망가뜨리면 어떻게 되나요?

각 티켓은 독립된 워크스페이스(별도 디렉터리)에서 실행되므로
다른 작업이나 메인 코드베이스에 직접 영향을 주지 않습니다.
에이전트는 PR을 생성할 뿐이고, 실제 병합은 사람이 직접 결정합니다.
자동 병합 설정(approval_policy: never)을 그대로 쓰면 에이전트가 만든 코드가 자동으로 메인에 들어가지 않습니다.

Q5. Claude나 Gemini 에이전트를 쓸 수 있나요?

공식적으로 지원하는 에이전트는 OpenAI Codex뿐입니다.
SPEC.md에 App-Server Protocol(JSON-RPC 2.0 over stdio)이 공개되어 있어서,
이 프로토콜을 구현하면 다른 에이전트를 연결하는 것이 원리적으로 가능합니다.
다만 공식 구현체가 없으므로 직접 작업이 필요합니다.

▲ 목차로 돌아가기

마치며

Symphony는 “AI가 코드를 대신 짜준다”는 개념을 처음 제시한 도구가 아닙니다.
Devin도 있었고, GitHub Copilot 에이전트도 있었습니다.
그럼에도 Symphony가 눈에 띄는 건 구조 자체가 다르기 때문입니다.
에이전트 행동 방식을 팀이 소유하고 버전 관리하는 형태가 된 것,
그리고 그 진입점이 오픈소스라는 점이 다른 도구와 결정적으로 다릅니다.

솔직히 말하면, 지금 당장 일반적인 팀에서 쓰기에는 장벽이 있습니다.
Linear를 써야 하고, Elixir 실행 환경이 필요하고,
하네스 엔지니어링 수준의 코드베이스가 갖춰져야 제대로 작동합니다.
이 세 가지 조건을 모두 충족하는 팀이 한국에서 얼마나 될지 솔직히 의문이긴 합니다.

그럼에도 한 가지는 분명합니다. “이슈 트래커에 있는 티켓이 곧 에이전트의 태스크 큐”라는 개념은
앞으로 더 많은 도구에서 나올 패러다임입니다.
Symphony는 그 미래가 어떻게 생겼는지를 지금 보여주는 레퍼런스입니다.

▲ 목차로 돌아가기

📚 본 포스팅 참고 자료

본 포스팅은 2026.03.28 기준으로 작성되었습니다.
OpenAI Symphony는 엔지니어링 미리보기(Engineering Preview) 단계이며,
본 포스팅 작성 이후 서비스 정책·UI·기능·지원 트래커가 변경될 수 있습니다.
최신 정보는 공식 GitHub 리포지터리(github.com/openai/symphony)에서 확인하시기 바랍니다.

AI 자동화, AI 코딩 에이전트, ChatGPT Codex, 하네스 엔지니어링, OpenAI Symphony

OpenAI Symphony, 티켓 쓰면 코드가 나옵니다

OpenAI Symphony, 티켓 쓰면 코드가 나옵니다

Symphony가 하는 일 한 줄 요약