3주 만에 PR 500%—이 숫자를 어떻게 읽을 것인가
OpenAI가 공개한 Symphony는 단순한 AI 코딩 보조 도구가 아니다. 이슈 트래커를 에이전트 제어 플랫폼으로 전환해, 에이전트가 직접 티켓을 가져와 처리하고 PR을 올리는 구조다. CIO.com 보도에 따르면 일부 내부 팀은 도입 후 3주 만에 병합된 풀 리퀘스트가 500% 증가했다.
솔직히 말하면, 이 숫자는 축하보다 경계를 먼저 불러일으킨다. 그레이하운드 리서치 CEO 산치트 비르 고지아가 정확히 짚었다. "생성은 쉽게 확장되지만 검증은 그렇지 않다." PR이 5배 늘었다고 팀의 실질 생산성이 5배가 되는 건 아니다. 리뷰 부담, 테스트 커버리지, 거버넌스 비용이 함께 커지지 않으면 그 숫자는 부채 누적 속도일 뿐이다.
Symphony가 실제로 해결한 문제
Symphony의 출발점은 명확하다. OpenAI 엔지니어들이 Codex 세션을 3~5개 이상 동시에 돌리기 시작하면서 문맥 전환 부담이 병목이 됐다. 에이전트 속도는 빠른데, 그걸 감독하는 인간이 따라가지 못하는 구조적 문제였다.
Symphony의 오케스트레이션 레이어는 이 문제를 정면으로 공략한다. 이슈 상태 추적, 중단된 에이전트 재시작, 충돌 해결, CI 모니터링—인간이 하던 감독 업무를 시스템이 떠안는다. 포레스터 애널리스트 비스와지트 마하파트라의 표현을 빌리면, "AI를 개인용 코딩 보조 도구에서 공유 엔지니어링 인프라로 전환"하는 것이다.
이 전환의 핵심은 에이전트가 많아질수록 오케스트레이션 레이어의 역할이 커진다는 데 있다. 에이전트 수가 늘면 감독 비용도 선형으로 증가하는데, Symphony는 그 관계를 끊으려는 시도다.
에이전트가 잊는다는 문제—Stateless 구조의 실제 비용
Symphony가 오케스트레이션을 해결해도 남는 문제가 있다. 에이전트는 기억하지 못한다. 세션이 끊기면 컨텍스트 윈도우는 리셋되고, 병렬로 돌아가는 에이전트들은 서로의 결정을 모른다.
dev.to의 한 개발자가 이 문제를 실제로 겪은 사례는 직관적이다. 같은 프로젝트에서 두 에이전트가 각자 다른 세션에서 작업하고 있었다. 한쪽이 디자인 토큰 네이밍 컨벤션을 웹에서 재탐색하려던 순간, 다른 세션에서 이미 몇 시간을 투자해 결론을 내린 결정이 있었다. 개입하지 않았다면, 두 에이전트는 같은 프로젝트에서 조용히 서로 다른 방향으로 표류했을 것이다.
이 문제를 해결하는 방법은 모델 안이 아니라 바깥에 있다. 외부 메모리 시스템—구체적으로는 에이전트가 읽을 수 있는 구조화된 마크다운 파일 체계—을 설계하는 것이다. 핵심은 세 가지 레이어다. 글로벌 컨텍스트(기술 스택, 작업 스타일), 프로젝트 인덱스(결정 목록과 파일 포인터), 개별 메모리 파일(규칙·Why·적용 방법). 특히 'Why'가 중요하다. 규칙만 있으면 에이전트는 그걸 따른다. 이유가 있으면 예상치 못한 엣지 케이스에도 판단할 수 있다.
에이전트가 많아질수록 이 메모리 구조의 부재는 기하급수적으로 문제가 커진다. PR 500%가 가능한 팀이라면, 에이전트 간 드리프트를 막는 외부 메모리 설계도 함께 있어야 한다.
AI 불투명성 부채—속도 뒤에 쌓이는 것
PR 수가 늘어도 팀이 코드베이스를 이해하지 못하면, 그건 부채가 쌓이는 속도다. dev.to의 또 다른 글은 이를 'AI opacity debt(AI 불투명성 부채)'라고 명명한다.
패턴은 이렇다. AI가 코드를 짠다. 작동한다. 테스트도 통과한다. 3주 후 요구사항이 바뀐다. 그 모듈을 열면, 기술적으로는 맞지만 구조적으로 낯선 코드가 있다. 직접 작성했다면 머릿속에 있었을 지도—엣지 케이스, 트레이드오프, 전제 조건—가 없다. 결국 이해하는 데 생성하는 것보다 더 많은 시간이 걸린다.
Symphony 맥락에서 이 문제는 더 증폭된다. 에이전트가 PR을 자율적으로 생성하고, 인간 감독 없이 CI를 통과하는 변경이 누적되면, 불투명성 부채는 리뷰어가 커버할 수 있는 속도보다 빠르게 쌓인다. 오케스트레이션이 자동화할수록 사람이 코드 결정의 맥락을 의식적으로 기록하지 않으면 팀은 자기 코드베이스에서 길을 잃는다.
실용적인 처방은 세 가지다. 데이터 모델, API 계약, 모듈 경계 같은 구조적 시임은 AI에게 결정을 넘기지 말 것. 코드를 수락하기 전에 "왜 이게 작동하는가"를 설명할 수 있는지 확인할 것. 통합 지점에서는 속도를 늦추고 사람이 직접 판단할 것. 그리고 의사결정 로그—두 문장이라도—를 남길 것. 이게 에이전트가 대신 만들어주지 않는 지도다.
팀이 실제로 설계해야 할 것
Symphony가 그리는 세계—에이전트가 이슈를 가져가 PR로 돌려주는 세계—는 이미 현실이 되고 있다. 그 세계에서 팀이 설계해야 할 것은 에이전트 숫자나 도구 선택이 아니다.
첫째, 에이전트 간 메모리 일관성. 세션 리셋과 병렬 실행은 에이전트의 기본 조건이다. 외부 메모리 시스템—에이전트가 읽고 갱신하는 구조화된 지식 베이스—없이 에이전트를 늘리면 드리프트가 늘어날 뿐이다.
둘째, 리뷰 게이트와 감사 추적. Counterpoint Research 닐 샤의 지적처럼, 에이전트에게 부여할 자율성 수준과 감사 추적 범위를 미리 정하지 않으면 보안과 책임 소재 문제가 터진다. PR 500%의 세계에서 리뷰어 병목은 이미 예측 가능한 다음 문제다.
셋째, 측정 지표의 재정의. 포레스터가 강조하듯, PR 수나 코드 라인은 에이전트 시대의 생산성 지표가 아니다. 기능 리드타임, 결함 유출률, 운영 안정성, 개발자 인지 부담—이 네 가지로 팀의 측정 기준을 바꾸지 않으면 속도 착시에 갇힌다.
에이전트 시대의 테크 리드 역할
결국 Symphony가 제기하는 질문은 도구에 관한 게 아니다. "에이전트가 PR을 생성하는 속도를 팀이 감당할 수 있는 구조를 갖췄는가"다.
테크 리드의 역할은 에이전트를 더 많이 돌리는 게 아니라, 에이전트가 빠르게 움직일 수 있는 환경—메모리 일관성, 리뷰 게이트, 명확한 자율성 경계—을 설계하는 것으로 이동하고 있다. 코드 생성이 자동화될수록, 사람이 담당해야 할 판단의 층위가 더 명확하게 드러난다.
Symphony는 오케스트레이션 레이어를 제공한다. 하지만 그 위에서 팀이 무엇을 결정하고, 어디에 개입하고, 무엇을 기록할 것인지—그건 여전히 사람이 설계해야 한다.