🔥 Symphony — OpenAI는 작업 단위를 한 칸 올렸다

새 도구 발표인 줄 알았다. 글을 끝까지 읽고 나서야 알았다 — Symphony는 도구가 아니라 작업 단위 결정이다. 일부 OpenAI 팀에서 PR 500% 증가, 발표 사흘 만에 GitHub star 17K 돌파 같은 숫자보다, 그 한 줄이 발표 전체를 끝까지 비추는 진짜 핵심이었다.

처음엔 그게 잘 안 보였다. 블로그 포스트 첫 문단부터 "Linear를 컨트롤 플레인으로 쓴다", "오픈된 모든 티켓에 에이전트가 붙는다" 같은 기능 설명이 먼저 나오고, 가운데에는 1,300줄짜리 SPEC.md 발췌가 통째로 실려 있다 (저장소의 실제 SPEC.md는 그보다 더 길어 2,100줄을 넘는다). 그 1,300줄 가운데 한 줄도 정말로 새롭지는 않다. 폴링, 워크스페이스 격리, 백오프 재시도 — 다 익숙한 운영 디자인이다. 그런데 글이 끝나갈 때쯤 한 문장이 나온다. "Software workflows are largely organized around deliverables: issues, tasks, tickets, milestones." 그 한 줄을 읽고 나서야 앞의 모든 게 다시 보였다.

SPEC.md 한 장이 본체다

OpenAI가 Symphony 저장소를 열어두고 처음 들이대는 카드는 코드가 아니다. 저장소 루트의 SPEC.md 한 파일이다. 명세 안에는 폴링 간격, 워크스페이스 키 정규화, 재시도 큐, 동시 실행 한도, 추적 시스템 어댑터 인터페이스가 차곡차곡 적혀 있다. 그러면 코드는 어디에 있나. Elixir 디렉터리가 하나 있는데 — 그건 Codex가 그 명세를 보고 한 번에 짜낸 결과물이다.

처음엔 이게 무슨 자랑인지 잘 안 와닿았다. 그러다 본문에서 한 줄을 더 읽었다. "To polish the spec, we even asked Codex to implement it in several other languages — TypeScript, Go, Rust, Java, Python — and use the results to identify ambiguities and simplify the system. It succeeded in every language." 명세를 다듬는 방법으로 다섯 언어로 한번씩 짜 보게 한 것이다. 같은 모호함이 다섯 언어에서 다르게 깨진다면, 그 모호함은 명세 잘못이다. 같은 자리에서 다섯 언어가 동일하게 작동하면 명세가 단단한 것이다. 컴파일러 fuzzing을 사람 명세에 들이댄 셈이다.

그래서 Symphony가 진짜로 들고 나오는 건 도구가 아니라 명세를 일급 산출물로 다루는 사고방식이다. 코드가 사실상 공짜에 가까워진 환경에서, 사람이 시간을 들여 다듬어야 하는 건 지시 구조라는 주장. 한 번 그 사고방식을 받아들이면 1,300줄 명세가 과하다가 아니라 그 정도 길이가 필요했구나로 읽힌다.

작업 단위가 한 칸 위로 올라갔다

OpenAI 팀이 글 안에서 솔직하게 짚는 자기 진단이 한 군데 있다. 한 사람이 편하게 다룰 수 있는 Codex 세션은 3~5개가 한도였다. 그 이상이 되면 어떤 세션이 무엇을 하고 있는지 까먹기 시작하고, 터미널 사이를 왔다 갔다 하느라 시간을 잃는다. 에이전트는 빠른데 사람 주의력이 병목이 된다. 본문에서 직접 옮긴 한 줄은 더 따끔하다 — "We had effectively built a team of extremely capable junior engineers, then assigned our human engineers to micromanaging them." 매우 유능한 주니어 엔지니어 팀을 만들어 두고, 인간 엔지니어들을 그들을 마이크로매니징하는 자리에 앉혔다는 것이다.

여기서 한 박자 멈췄다. 이 진단을 듣고 떠오른 건 어제 Codex 세션 다섯 개를 동시에 띄워둔 자리였다. 한 세션은 리팩토링, 다른 세션은 새 기능, 또 다른 세션은 버그 픽스를 시켰다. 시작할 때는 손이 다섯 개로 늘어난 기분이었다. 그러다 한 세션이 멈췄다는 알림에 다른 탭으로 옮기는 순간, 그 전 세션이 어디까지 시킨 건지 다시 더듬어야 했다. 결국 한 번에 한 세션밖에 못 봤다. 더 빠른 모델이 나와도 이 부분은 안 풀린다고 생각한다. 모델이 빠를수록 내가 결정해야 할 분기점이 더 자주 들어오기 때문이다.

Symphony가 한 일은 의외로 단순하다. 작업 단위를 세션에서 티켓으로 한 칸 위로 올렸다. "세션 5개를 운영"에서 "열린 티켓 50개를 보드에 두고 전부 에이전트한테 맡김"으로. 사람이 세션 단위 의사결정에서 빠지고, 티켓 안에서 일어나는 일은 에이전트가 알아서 한다. 사람은 티켓이 닫혔는지, 결과물이 쓸 만한지만 본다.

이 한 칸 차이가 왜 그렇게 큰지가 처음엔 안 보였다. 한 박자 멈춰 시나리오로 풀어 보면 이렇다. 옛날 방식: 내가 Codex에 "X 함수에서 NPE 잡아 줘"라고 시키고, 5분 뒤 "왜 이 부분에 try-catch를 넣었지" 묻고, 또 5분 뒤 "다른 호출자도 확인했어?" 묻는다. 한 작업에 내 주의력 30분, 거기서 다른 작업으로 점프하면 컨텍스트 다시 올리는 데 또 5분. 새 방식: 티켓을 적는 데 1분, 에이전트가 PR을 띄우면 그것만 본다. 그 사이 30분은 다른 결정에 쓸 수 있다. PR 500%가 코드를 5배 빨리 짠 게 아니라, 사람 주의력이 5배 자유로워진 결과라는 게 더 정직한 해석이다.

그 500%, 진짜로 믿어도 되나

물론 마케팅 숫자는 그대로 받기 어렵다. OpenAI가 글에서 한 말을 다시 읽으면 — "some teams at OpenAI", "first three weeks". 즉 전체가 아니라 일부 팀, 지속적이 아니라 첫 3주. 어떤 베이스라인 대비인지도 안 적혀 있다. 한 팀이 직전 분기에 PR을 한 자릿수만 머지했다면 5배는 너무 쉬운 숫자다. 전사 평균 PR 처리량 5배였다면 — 그건 그대로 안 적었을 리가 없다.

Hacker News 반응도 갈렸다. 호의적인 쪽은 "이미 Codex 쓰던 팀이라면 자연스러운 한 칸 위 추상"이라 짚었고, 회의적인 쪽은 더 날카로웠다. 한 사용자는 명세를 보고 "inscrutable agent slop"이라 불렀다. "그저 데이터베이스 필드만 나열할 뿐, 시스템이 무엇을 하는지 설명하지 않는다"는 비판이었다. 한 Haskell 블로그는 다른 언어로 재구현해 본 뒤 Dijkstra의 표현을 빌려 "verbal precision을 추구하는 헛수고(vain attempt at verbal precision)"라며 마감을 떨어뜨렸다. AI가 쓴 명세를 AI가 만든 회사가 그대로 발표할 일이냐는 메타 회의도 한 줄 섞여 있다.

이 비판들은 전부 일부씩 맞는다고 생각한다. SPEC.md를 직접 읽어 보면 "id (string) — Stable tracker-internal ID" 같은 자료형 정의 줄이 수백 개 이어진다. 사람이 읽으라고 쓴 글이 아니다. Codex가 받아 구현하라고 쓴 글이다. Codex가 다섯 언어에서 한 번에 통과시켰다는 건 그 자체로 인상적이지만, 사람 입장에서 무엇을 만드는 시스템인가는 명세가 아니라 블로그 포스트 본문에서만 나온다. 한 사람이 다른 사람에게 시스템을 설명하던 자리가 — Codex에게 시스템을 설명하는 자리로 옮겨갔다. 좋고 나쁘고를 떠나, 2026년의 명세가 어디로 가는지 보여주는 한 장면 같다.

또 인정할 한계가 있다. 명세가 정의하는 추적기 어댑터는 현재 Linear 한 종류뿐이다. Jira, GitHub Issues, Notion DB 같은 다른 추적기로 옮기려면 같은 인터페이스를 직접 구현해 끼워 넣어야 한다. 단일 티켓에 단일 에이전트라는 가정 위에서 동작하니, 코드 리뷰나 교차 모델 검증은 별도 단계로 빠진다. 품질 게이트는 WORKFLOW.md에 적는 프롬프트로 강제한다 — 즉 가드레일 자체도 자연어다. 운영 환경에서 코딩 에이전트가 잘못된 PR을 자동으로 머지하지 않게 하려면 결국 사람이 한 단계 더 막아야 한다.

다음에 할 일은 작업 단위를 한 칸 위로 옮기는 일

발표 사흘이 지난 지금 내 머릿속에 남은 한 줄은 PR 500%가 아니다. "우리는 세션이 아니라 인도물(deliverable) 단위로 작업을 조직한다." 이 한 줄을 내 작업 흐름 위에 옮겨 보면 — 나는 Codex 세션 다섯 개를 세션 단위로 보고 있었지, 결과물 한 개 단위로 보고 있지 않았다. 결과물 한 개가 닫혀야 다음 결과물이 의미 있는데, 세션 다섯 개가 동시에 돌면 다섯 자리가 반쯤 열린 채 늘어진다. Symphony 식으로 옮기면 — 열린 결과물 한 개가 곧 티켓이고, 에이전트는 그 티켓이 닫힐 때까지 자기 워크스페이스 안에서만 산다.

그 발상을 그대로 복제하기는 어렵다. OpenAI가 Linear에 붙인 깊이는 Codex App Server JSON-RPC 모드와 linear_graphql 동적 툴 호출 같은 것 위에 서 있다. 작은 팀이 흉내 내려면 티켓 보드는 GitHub Issues나 Notion DB로 바꾸고, 워크스페이스는 git worktree 정도로 줄이고, 에이전트는 Codex 또는 Claude로 바꾸면 된다. 그 정도 축소판은 두세 주말이면 짤 수 있다는 게 발표가 노린 메시지인 것 같다.

다만 한 가지는 내 안에서 정리됐다. 다음 6개월 동안 "코드를 짜는 도구"보다 "코드를 시키는 단위"가 빠르게 발전할 거라는 감이 잡혔다. Symphony는 그 첫 공식 진열장일 뿐이다. 발표 직후 Linear의 공동창업자 Karri Saarinen도 새 Linear 워크스페이스가 갑자기 늘었다는 트윗을 올렸다. 나도 같은 줌아웃을 받아들이는 중인 것 같다.

내가 다음에 할 일은 명확해졌다. 일단 띄워둔 Codex 세션들을 결과물 한 개 단위로 다시 묶는다. 세션 자체를 더 늘리는 건 그 다음 일이다.

참고 자료

• An open-source spec for Codex orchestration: Symphony — OpenAI Blog — 본 글의 원전. Symphony가 무엇이고 왜 만들었는지, 내부에서 어떻게 쓰는지를 설명한 OpenAI 공식 발표.
• openai/symphony — GitHub Repository — 1,300줄 발췌가 실려 있는 본격적인 SPEC.md(저장소 기준 2,100줄+)와 Elixir 레퍼런스 구현. 다른 언어 포팅을 시도해 볼 수 있는 출발점.
• Harness engineering: leveraging Codex in an agent-first world — OpenAI Blog — Symphony 직전 단계의 글. "코드 한 줄도 사람이 쓰지 않은 백만 줄 프로젝트"가 어떤 환경에서 나왔는지를 다룬다.
• Codex App Server — OpenAI Developer Documentation — Symphony가 의지하는 JSON-RPC 모드 명세. 동적 툴 호출 등 본문에 등장하는 메커니즘이 여기에 있다.
• Karri Saarinen on X — Symphony 발표 직후 Linear 워크스페이스 폭증 — Linear 창업자 본인이 짚은 사용 패턴 변화.