이번 주 개발자 커뮤니티에서는 AI 에이전트를 여러 개 띄워놓고 씨름하다가 결국 멘탈이 나가는 상황이 화두다. 터미널 창을 수십 개 열어두고 어떤 에이전트가 어떤 코드를 짜고 있는지 일일이 확인하며 마이크로 매니징하는 모습이 일상이 됐다. 에이전트는 빠르지만 이를 관리하는 인간의 주의력이 병목이 되어, 정작 개발자는 세션 사이를 오가는 컨텍스트 스위칭(작업 전환 시 발생하는 인지적 비용)에 에너지를 다 쓰고 있다.

Symphony: Linear를 제어판으로 쓰는 에이전트 오케스트레이터

OpenAI 연구팀은 프로젝트 관리 도구인 Linear(이슈 트래커)를 제어판으로 활용하는 에이전트 오케스트레이터(여러 AI 에이전트의 작업을 조율하는 시스템)인 Symphony를 공개했다. 이 시스템은 Linear의 오픈 티켓 하나를 전담 에이전트 워크스페이스 하나에 매핑한다. Symphony는 태스크 보드를 실시간으로 감시하며, 활성화된 모든 작업에 Codex(AI 코딩 모델) 에이전트가 할당되어 완료될 때까지 루프를 돌게 만든다. 에이전트가 충돌하거나 멈추면 Symphony가 자동으로 재시작하며, 새로운 작업이 등록되면 즉시 이를 포착해 작업을 조직한다.

세션 중심에서 티켓 중심으로 바뀐 워크플로우

예전에는 개발자가 직접 Codex 세션을 열고 작업을 지시한 뒤 결과를 리뷰하는 인터랙티브한 방식이었다. 이제는 사람이 에이전트를 직접 감독하지 않고, 에이전트가 이슈 트래커에서 할 일을 스스로 가져가는 방식으로 바뀌었다. 특히 DAG(작업 간의 의존 관계를 나타낸 방향성 비순환 그래프) 구조를 도입해, 예를 들어 Vite(빠른 빌드 도구) 마이그레이션이 끝나야만 React(사용자 인터페이스 라이브러리) 업그레이드 작업을 시작하도록 순서를 제어한다. 에이전트가 작업 중 성능 개선이나 리팩토링(코드의 기능은 유지하되 구조를 개선하는 작업) 기회를 발견하면 스스로 새로운 이슈를 생성해 등록하기도 한다.

개발자가 체감하는 가장 큰 변화는 결과물의 양이다. OpenAI 내부 일부 팀에서는 도입 3주 만에 머지된 PR(코드 변경 사항을 반영해달라는 요청) 수가 500% 증가했다. 인간이 구현 과정에 직접 개입하는 비용이 사라지면서, 가설 검증을 위한 실험적 작업이나 리팩토링 티켓을 생성하는 심리적 문턱이 거의 제로에 가까워졌다. 이제는 개발자가 아니더라도 제품 관리자(PM)나 디자이너가 Linear에 기능 요청을 올리는 것만으로 AI 에이전트가 실제 구현에 착수하는 구조가 됐다.

이제 코딩의 핵심 역량은 어떻게 짜느냐가 아니라 어떤 티켓을 발행하느냐라는 기획의 영역으로 완전히 넘어갔다.