코딩 에이전트를 팀에 붙이면 처음 며칠은 확실히 빨라집니다. 문제는 그다음입니다. 세션이 늘고, 각 세션이 서로 다른 브랜치와 태스크를 물고, 사람은 어디서 무엇이 멈췄는지 관리하느라 다시 컨텍스트 스위칭 지옥으로 들어갑니다. 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개 세션 정도까지만 편하게 관리할 수 있었다고 설명합니다. 그 이상은 세션을 기억하는 비용이 성과를 잡아먹습니다. 즉 코딩 에이전트 시대의 첫 번째 운영 병목은 “코드 생성”이 아니라 “사람의 주의력”입니다.
실무적으로 이건 매우 중요합니다. 지금 팀이 에이전트를 써도 성과가 생각보다 안 나온다면, 모델 교체보다 먼저 작업 단위를 다시 설계해야 할 수 있습니다.
원문에서 가장 실용적인 포인트는 티켓을 상태 머신처럼 쓰는 방식입니다. 에이전트가 세션에 귀속되는 것이 아니라 이슈에 귀속됩니다. 오픈된 Linear 이슈마다 전용 워크스페이스를 만들고, 작업이 끝날 때까지 오케스트레이터가 계속 살펴봅니다. 에이전트가 죽거나 멈추면 다시 시작하고, 새 작업이 생기면 집어갑니다.
이 구조가 좋은 이유는 세 가지입니다.
첫째, 세션과 산출물을 분리합니다. 어떤 이슈는 PR 하나로 끝나지만, 어떤 이슈는 여러 저장소에 걸친 PR이 필요하고, 어떤 이슈는 분석 문서만 만들 수도 있습니다. 세션 중심 사고로는 이 차이를 깔끔하게 다루기 어렵습니다.
둘째, 종속성 관리가 쉬워집니다. 원문은 React 업그레이드가 Vite 마이그레이션에 막혀 있었고, 선행 작업이 끝난 후 에이전트가 후속 태스크를 이어서 처리했다고 설명합니다. 즉 “브랜치 하나”가 아니라 “작업 DAG” 단위로 병렬화를 가져갑니다.
셋째, 사람 아닌 직군도 일을 시작할 수 있습니다. 제품 매니저나 디자이너가 직접 티켓을 만들고, 에이전트가 그걸 받아 탐색과 구현을 시작하는 구조가 됩니다. 이건 개발 속도 문제이기도 하지만, 팀 인터페이스 문제이기도 합니다.
이 아이디어를 바로 흉내 내다가 실패하는 팀이 많을 겁니다. 이유는 “티켓에 에이전트 붙이기”만 보고, 그 아래 필수 설계를 빠뜨리기 때문입니다.
에이전트가 언제 시작하고, 언제 멈추고, 언제 사람 검토를 기다리는지 상태가 명확해야 합니다. 사람이 읽는 상태와 에이전트가 읽는 상태를 섞으면 금방 꼬입니다. 예를 들어 backlog, ready, in progress, blocked, review, merge-ready처럼 최소 상태부터 시작하는 편이 낫습니다.
원문도 per-issue workspace를 강조합니다. 이유는 단순합니다. 여러 에이전트가 같은 저장소에서 동시에 움직이면 브랜치 충돌, 임시 파일 덮어쓰기, 컨텍스트 오염이 바로 터집니다. 이 구조 없이 멀티 에이전트를 늘리면 속도보다 사고가 먼저 납니다.
Symphony는 단순히 코드를 쓰는 수준이 아니라 CI 감시, rebase, conflict 해결, flaky check 재시도까지 맡는 방향을 보여줍니다. 여기서 핵심은 “에이전트가 PR을 열 수 있다”가 아니라 “PR이 머지 가능한 상태로 흘러가게 돕는다”입니다. 많은 팀이 이 마지막 20%를 자동화하지 못해 오히려 운영 부담만 늘립니다.
원문이 흥미로운 이유 중 하나는 실패를 낭비로 보지 않는다는 점입니다. 잘못된 산출물도 시스템 설계의 빈틈을 드러내는 신호로 취급합니다. 실무에서는 실패한 에이전트 작업에서 guardrail, skill, 문서 개선 포인트를 뽑아내는 루틴이 있어야 합니다.
잘 맞는 팀은 반복 구현과 유지보수 작업이 많고, 이슈 트래커 사용이 이미 정착된 팀입니다. 모노레포, CI가 긴 팀, 사소한 버그·리팩터링·문서 정리 태스크가 쌓이는 팀은 효과를 크게 볼 가능성이 높습니다.
반대로 아직 테스트가 약하고, 리뷰 기준이 불명확하고, 작업 정의가 늘 모호한 팀은 Symphony 스타일을 바로 넣으면 혼란이 커질 수 있습니다. 에이전트가 못해서가 아니라 팀의 작업 규약이 느슨하기 때문입니다. 에이전트 오케스트레이션은 숨겨진 운영 부채를 확대해서 보여주는 거울에 가깝습니다.
가장 좋은 시작은 전체 개발 프로세스를 바꾸는 게 아닙니다. 하루 안에 끝날 수 있는 작은 반복 업무 묶음부터 떼어내는 겁니다.
이 순서를 지키면 “에이전트 수를 늘리는 실험”이 아니라 “감독 비용을 줄이는 실험”으로 바뀝니다. 그 차이가 큽니다.
Symphony가 던지는 질문은 화려하지 않습니다. “좋은 코딩 에이전트가 있느냐”가 아니라 “사람이 세션을 직접 관리하지 않아도 일이 앞으로 가도록 작업 체계를 바꿨느냐”입니다. 앞으로 멀티 에이전트 도입이 늘수록 승부는 모델 품질보다 오케스트레이션 품질에서 갈릴 가능성이 큽니다.
에이전트를 더 많이 쓰는 팀일수록, 세션 UI보다 이슈 구조와 검토 루프를 먼저 설계해야 합니다. 그걸 놓치면 에이전트는 생산성 도구가 아니라 새로운 운영 잡무 생성기가 됩니다.
