Codex orchestration Symphony 오픈소스: Linear를 에이전트 컨트롤 플레인으로 바꾸는 법

왜 코딩 에이전트가 많아질수록 생산성이 아니라 운영 피로가 먼저 올라갈까

코딩 에이전트를 팀에 붙이면 처음 며칠은 확실히 빨라집니다. 문제는 그다음입니다. 세션이 늘고, 각 세션이 서로 다른 브랜치와 태스크를 물고, 사람은 어디서 무엇이 멈췄는지 관리하느라 다시 컨텍스트 스위칭 지옥으로 들어갑니다. OpenAI가 2026년 4월 27일 공개한 Symphony 글(https://openai.com/index/open-source-codex-orchestration-symphony/)이 중요한 이유가 여기 있습니다. 이 글은 “에이전트가 더 똑똑해졌다”는 이야기보다, 에이전트를 사람이 손으로 돌보는 운영 방식 자체가 병목이 되었다는 사실을 드러냅니다.

원문은 코딩 세션 중심이 아니라 티켓 중심으로 에이전트를 돌리자는 쪽으로 시선을 바꿉니다. OpenAI 설명에 따르면 Symphony는 프로젝트 관리 보드, 예시로는 Linear를 에이전트 오케스트레이션의 컨트롤 플레인으로 쓰는 공개 스펙입니다. 각 오픈 태스크에 에이전트를 붙이고, 에이전트가 계속 실행되며, 사람이 결과를 검토합니다. 원문에는 일부 팀에서 landed pull request 수가 3주 동안 500% 증가했다고 적혀 있습니다. 이 숫자만 보고 흥분하면 안 됩니다. 더 중요한 건 왜 그런 변화가 가능했는지입니다.

문제의 본질은 모델 성능이 아니라 사람의 감독 비용이다

대부분의 팀은 에이전트 생산성을 모델 품질로만 봅니다. 하지만 실제 운영에서는 모델보다 인간의 감독 비용이 더 빨리 커집니다. 에이전트 하나를 띄우는 건 쉽습니다. 다섯 개, 열 개를 동시에 굴리기 시작하면 누가 어떤 작업을 하는지 추적하고, 멈춘 세션을 다시 깨우고, PR 상태와 CI 실패를 일일이 보는 작업이 생깁니다.

Symphony가 겨냥하는 병목은 바로 이 지점입니다. 원문은 엔지니어가 보통 3~5개 세션 정도까지만 편하게 관리할 수 있었다고 설명합니다. 그 이상은 세션을 기억하는 비용이 성과를 잡아먹습니다. 즉 코딩 에이전트 시대의 첫 번째 운영 병목은 “코드 생성”이 아니라 “사람의 주의력”입니다.

실무적으로 이건 매우 중요합니다. 지금 팀이 에이전트를 써도 성과가 생각보다 안 나온다면, 모델 교체보다 먼저 작업 단위를 다시 설계해야 할 수 있습니다.

Symphony가 바꾸는 것은 세션 관리 방식이 아니라 작업 단위의 정의다

원문에서 가장 실용적인 포인트는 티켓을 상태 머신처럼 쓰는 방식입니다. 에이전트가 세션에 귀속되는 것이 아니라 이슈에 귀속됩니다. 오픈된 Linear 이슈마다 전용 워크스페이스를 만들고, 작업이 끝날 때까지 오케스트레이터가 계속 살펴봅니다. 에이전트가 죽거나 멈추면 다시 시작하고, 새 작업이 생기면 집어갑니다.

이 구조가 좋은 이유는 세 가지입니다.

첫째, 세션과 산출물을 분리합니다. 어떤 이슈는 PR 하나로 끝나지만, 어떤 이슈는 여러 저장소에 걸친 PR이 필요하고, 어떤 이슈는 분석 문서만 만들 수도 있습니다. 세션 중심 사고로는 이 차이를 깔끔하게 다루기 어렵습니다.

둘째, 종속성 관리가 쉬워집니다. 원문은 React 업그레이드가 Vite 마이그레이션에 막혀 있었고, 선행 작업이 끝난 후 에이전트가 후속 태스크를 이어서 처리했다고 설명합니다. 즉 “브랜치 하나”가 아니라 “작업 DAG” 단위로 병렬화를 가져갑니다.

셋째, 사람 아닌 직군도 일을 시작할 수 있습니다. 제품 매니저나 디자이너가 직접 티켓을 만들고, 에이전트가 그걸 받아 탐색과 구현을 시작하는 구조가 됩니다. 이건 개발 속도 문제이기도 하지만, 팀 인터페이스 문제이기도 합니다.

기존 이슈 트래커를 에이전트 컨트롤 플레인으로 바꿀 때 꼭 필요한 설계

이 아이디어를 바로 흉내 내다가 실패하는 팀이 많을 겁니다. 이유는 “티켓에 에이전트 붙이기”만 보고, 그 아래 필수 설계를 빠뜨리기 때문입니다.

1) 이슈 상태 정의를 먼저 좁혀야 한다

에이전트가 언제 시작하고, 언제 멈추고, 언제 사람 검토를 기다리는지 상태가 명확해야 합니다. 사람이 읽는 상태와 에이전트가 읽는 상태를 섞으면 금방 꼬입니다. 예를 들어 backlog, ready, in progress, blocked, review, merge-ready처럼 최소 상태부터 시작하는 편이 낫습니다.

2) 워크스페이스 격리가 필요하다

원문도 per-issue workspace를 강조합니다. 이유는 단순합니다. 여러 에이전트가 같은 저장소에서 동시에 움직이면 브랜치 충돌, 임시 파일 덮어쓰기, 컨텍스트 오염이 바로 터집니다. 이 구조 없이 멀티 에이전트를 늘리면 속도보다 사고가 먼저 납니다.

3) CI와 리뷰를 자동 루프에 넣어야 한다

Symphony는 단순히 코드를 쓰는 수준이 아니라 CI 감시, rebase, conflict 해결, flaky check 재시도까지 맡는 방향을 보여줍니다. 여기서 핵심은 “에이전트가 PR을 열 수 있다”가 아니라 “PR이 머지 가능한 상태로 흘러가게 돕는다”입니다. 많은 팀이 이 마지막 20%를 자동화하지 못해 오히려 운영 부담만 늘립니다.

4) 실패를 결과로 남기는 구조가 필요하다

원문이 흥미로운 이유 중 하나는 실패를 낭비로 보지 않는다는 점입니다. 잘못된 산출물도 시스템 설계의 빈틈을 드러내는 신호로 취급합니다. 실무에서는 실패한 에이전트 작업에서 guardrail, skill, 문서 개선 포인트를 뽑아내는 루틴이 있어야 합니다.

이 방식이 특히 잘 맞는 팀과 그렇지 않은 팀

잘 맞는 팀은 반복 구현과 유지보수 작업이 많고, 이슈 트래커 사용이 이미 정착된 팀입니다. 모노레포, CI가 긴 팀, 사소한 버그·리팩터링·문서 정리 태스크가 쌓이는 팀은 효과를 크게 볼 가능성이 높습니다.

반대로 아직 테스트가 약하고, 리뷰 기준이 불명확하고, 작업 정의가 늘 모호한 팀은 Symphony 스타일을 바로 넣으면 혼란이 커질 수 있습니다. 에이전트가 못해서가 아니라 팀의 작업 규약이 느슨하기 때문입니다. 에이전트 오케스트레이션은 숨겨진 운영 부채를 확대해서 보여주는 거울에 가깝습니다.

지금 바로 적용할 현실적인 도입 순서

가장 좋은 시작은 전체 개발 프로세스를 바꾸는 게 아닙니다. 하루 안에 끝날 수 있는 작은 반복 업무 묶음부터 떼어내는 겁니다.

1. 최근 2주간 반복적으로 발생한 태스크 20개를 모읍니다.
2. 그중 명확한 완료 기준이 있는 태스크만 고릅니다.
3. 이슈 상태를 최소 5개 수준으로 정의합니다.
4. 태스크당 격리 워크스페이스와 브랜치 전략을 정합니다.
5. CI 통과, 스크린샷, 테스트 결과처럼 사람이 검토할 artifact 형식을 정합니다.
6. 처음에는 코드 작성보다 조사·초안·테스트 작성 같은 저위험 작업부터 맡깁니다.

이 순서를 지키면 “에이전트 수를 늘리는 실험”이 아니라 “감독 비용을 줄이는 실험”으로 바뀝니다. 그 차이가 큽니다.

결국 중요한 질문은 하나다

Symphony가 던지는 질문은 화려하지 않습니다. “좋은 코딩 에이전트가 있느냐”가 아니라 “사람이 세션을 직접 관리하지 않아도 일이 앞으로 가도록 작업 체계를 바꿨느냐”입니다. 앞으로 멀티 에이전트 도입이 늘수록 승부는 모델 품질보다 오케스트레이션 품질에서 갈릴 가능성이 큽니다.

에이전트를 더 많이 쓰는 팀일수록, 세션 UI보다 이슈 구조와 검토 루프를 먼저 설계해야 합니다. 그걸 놓치면 에이전트는 생산성 도구가 아니라 새로운 운영 잡무 생성기가 됩니다.

실행 체크리스트

• 현재 팀이 관리 가능한 에이전트 세션 수의 한계를 숫자로 알고 있는가
• 이슈 상태가 사람용 메모가 아니라 자동화 가능한 상태 머신으로 정의되어 있는가
• 태스크별 격리 워크스페이스와 브랜치 전략이 있는가
• 에이전트 산출물을 사람이 빠르게 검토할 artifact 형식이 있는가
• CI, rebase, conflict 처리 같은 마지막 20%까지 자동화 대상에 넣었는가
• 실패한 에이전트 작업에서 문서·스킬·가드레일 개선점을 회수하는 루틴이 있는가
• 다음 분기 생산성 실험을 “모델 교체”가 아니라 “감독 비용 절감” 기준으로 설계할 수 있는가