오픈AI Symphony 인간의 주의력이 병목이다 에이전트가 스스로 티켓 처리하는 시대

OpenAI가 개발자들 사이에서 회자되던 문제를 공식화했습니다. “에이전트들은 빨랐다. 병목은 인간의 주의력이었다.”

Symphony는 이 병목을 해결하기 위해 설계된 오픈소스 사양입니다. 개발자가 여러 AI 세션을 동시에 감독하며 각각에 작업을 배분하는 방식을 뒤집어, 에이전트가 Linear 같은 작업 추적 도구에서 직접 오픈 티켓을 가져와 완료될 때까지 실행합니다. 인간은 결과를 검토하는 역할로 물러납니다.

일부 팀에서 첫 3주 만에 병합된 풀 리퀘스트(PR)가 6배 증가했다고 OpenAI는 밝혔습니다.

관련 브리핑: aikorea24.kr 2026-05-05 브리핑

Symphony가 바꾸는 것

기존 AI 코딩 워크플로우에서 개발자는 동시에 3~5개의 Codex 세션을 운영하는 것이 현실적 한계였습니다. 세션마다 어떤 작업이 진행 중인지 파악하고, 막히면 개입하고, 완료되면 다음 작업을 배정해야 했습니다. AI의 처리 속도는 빠른데, 인간이 따라가지 못하는 구조였습니다.

Symphony는 이 구조를 역전시킵니다.

작업 보드(Linear)가 작업 지휘 센터가 됩니다. 모든 오픈 티켓에는 자동으로 Codex 에이전트가 배정됩니다. 에이전트는 해당 티켓을 가져가 독립된 워크스페이스에서 완료될 때까지 실행합니다. 에이전트가 실패하거나 멈추면 Symphony가 자동으로 재시작합니다.

중요한 것은 에이전트의 역할 범위입니다. 단순한 코드 작성을 넘어, 여러 저장소에 걸친 풀 리퀘스트 생성, 순수 리서치나 분석 작업, 동영상 워크스루 생성까지 가능합니다. 에이전트가 작업 중 성능 문제나 리팩토링 기회를 발견하면, 새 티켓을 자동으로 생성하고 등록합니다.

제품 매니저나 디자이너도 기능 요청을 직접 제출하면 코드를 체크아웃하지 않고도 동영상 워크스루가 포함된 검토 패키지를 받을 수 있습니다.

왜 이 설계가 중요한가

Symphony의 설계 철학에는 AI 에이전트 운영에 관한 중요한 통찰이 담겨 있습니다.

첫째, 상태 기계(state machine) 방식의 한계 인정입니다. 초기에는 에이전트를 고정된 노드처럼 취급하는 엄격한 프로세스 설계를 시도했습니다. 그러나 모델 성능이 빠르게 향상되면서 에이전트가 처음 계획했던 것보다 더 큰 문제를 다룰 수 있게 되었습니다. 엄격한 프로세스가 오히려 에이전트의 능력을 제한하는 것입니다.

둘째, 과정보다 목표를 주는 방식으로의 전환입니다. OpenAI 팀은 단계별 지시를 주는 방식 대신, 달성해야 할 결과를 주는 방식으로 전환했습니다. “이 함수를 이렇게 수정하라”가 아니라 “이 기능이 동작하도록 만들어라”입니다. 마치 관리자가 직원에게 방법이 아닌 목표를 주는 것과 같습니다.

셋째, 스펙 자체가 아티팩트입니다. Symphony의 핵심은 복잡한 모니터링 시스템이 아닙니다. SPEC.md라는 마크다운 파일 하나에 문제와 솔루션을 정의하고, 에이전트가 이 스펙을 읽고 구현합니다. Codex가 이 구현을 단번에 작성했으며, 스펙이 변경되면 WORKFLOW.md 파일만 수정하면 됩니다.

3주에 PR 6배 — 이 수치를 어떻게 봐야 하는가

OpenAI가 발표한 “3주 만에 병합 PR 6배 증가”라는 수치는 인상적이지만, 맥락을 함께 봐야 합니다.

증가한 PR은 에이전트가 처리한 루틴 작업들입니다. Symphony는 명확하게 “판단이 필요하거나 모호한 작업은 여전히 개발자가 직접 인터랙티브 세션에서 처리한다”고 밝힙니다. PR 수의 증가가 개발 품질의 향상과 동일하지는 않으며, 루틴 작업 자동화로 인한 처리량 증가로 해석하는 것이 정확합니다.

중요한 질문은 따로 있습니다. 에이전트가 처리하는 루틴 작업의 비중이 늘어날수록, 개발자가 집중해야 할 “판단이 필요한 복잡한 작업”도 함께 증가합니까, 아니면 전체 작업량이 줄어듭니까. 전자라면 개발자의 일은 더 어려워지고 더 흥미로워집니다. 후자라면 개발자 수요 자체가 감소합니다.

Linear 창업자 카리 사리넨이 Symphony 출시 이후 새 워크스페이스가 급증했다고 언급한 것은 이 도구가 실제로 채택되고 있다는 외부 신호입니다.

커뮤니티의 반응과 확장

Symphony는 오픈소스입니다. OpenAI는 이것을 독립 제품이 아닌 레퍼런스 구현으로 제공했으며, 커뮤니티가 이미 다양한 방향으로 확장하고 있습니다.

가장 주목할 만한 것은 Anthropic의 Claude Code와 GitHub Issues를 연동한 포크입니다. OpenAI의 Codex가 아닌 Claude를 활용하는 Symphony 구현이 이미 등장했다는 것은, 이 아키텍처가 특정 모델에 종속되지 않는 범용 에이전트 오케스트레이션 패턴임을 보여줍니다.

레퍼런스 구현은 Elixir로 작성되었으며, Codex가 이 구현을 한 번에 완성했습니다. 호환성 검증을 위해 TypeScript, Go, Rust, Java, Python 구현도 별도로 작성되었습니다.

개발자와 개발팀에 미치는 실질적 영향

Symphony가 보여주는 방향은 개발자의 역할 변화를 구체적으로 예고합니다.

루틴 코딩 작업은 에이전트로 이동합니다. 버그 수정, 단순 기능 추가, 코드 리팩토링, 테스트 작성 같은 명확하게 정의된 작업들이 에이전트의 영역으로 넘어갑니다.

개발자는 더 적은 작업을 더 깊이 다루게 됩니다. 에이전트가 루틴을 처리하면, 개발자는 아키텍처 설계, 복잡한 트레이드오프 판단, 새로운 기능의 방향 설정에 더 많은 시간을 쓸 수 있습니다.

작업 보드 관리 방식이 달라집니다. 티켓 작성의 품질이 더 중요해집니다. 에이전트가 티켓을 읽고 작업하기 때문에, 모호하게 작성된 티켓은 모호한 결과로 돌아옵니다.

이 변화에 적응하는 팀과 그렇지 않은 팀 사이의 생산성 격차는 이미 벌어지기 시작했습니다.

주목해야 할 포인트

Symphony가 열어놓은 가장 중요한 논점은 인간의 감독 역할이 어디까지 후퇴할 수 있는가입니다.

지금은 에이전트가 루틴 작업을 처리하고 인간이 결과를 검토합니다. 모델 성능이 계속 향상되면, “검토가 필요한 복잡한 작업”의 기준이 계속 올라갑니다. 오늘의 복잡한 작업이 내년에는 에이전트의 루틴 작업이 될 수 있습니다.

OpenAI 스스로 “모델은 계속 좋아지고 있으며, 계획이 예상했던 것보다 더 큰 문제를 처리할 수 있게 된다”고 밝혔습니다. 에이전트의 능력과 인간의 감독 범위 사이의 관계는 고정된 것이 아닙니다. 이 관계가 어떻게 진화할지를 주시하는 것이 개발자와 개발 조직 모두의 과제입니다.

#OpenAI #Symphony #AI에이전트 #Codex #자율에이전트 #AI개발자도구 #PR자동화 #AI생산성