DoorDash가 2단계 멀티 에이전트 LLM 시스템으로 방치된 피처 플래그 제거를 자동화했다. 테스트 50건 가운데 45건에서 엔지니어 승인을 받은 풀 리퀘스트가 나왔고, 플래그 하나당 평균 4.79달러와 13.8분이 들었다. 사내 수작업 기준으로는 1~2시간이 걸리던 일이다. 이 결과는 DoorDash 엔지니어 Atharv Chandratre와 Jai Datar가 쓴 ICSME 2026 산업 트랙 논문에 실렸다.
핵심 요약
- 시스템은 방치된 플래그 50건 중 45건을 쓸 만한 풀 리퀘스트로 정리했다. 전체 성공률 90%, 가장 복잡한 유형에서도 85%를 기록했다.
- Claude Sonnet 오케스트레이터가 MCP를 통해 정리 계획을 세우고, 실제 코드 수정은 Claude Opus 에이전트가 맡는다. 에이전트는 각자 별도의 git worktree에서 최대 4개까지 동시에 돌아간다.
- 빌드, 테스트, 패치 커버리지 95%, 정적 분석을 로컬에서 모두 통과하기 전에는 풀 리퀘스트가 열리지 않는다.
저장소 623곳에 쌓인 죽은 플래그가 유지보수 문제가 된 이유
피처 플래그는 런타임 설정이다. 점진적 롤아웃을 열고 닫거나, 실험군을 나누거나, 수동 킬 스위치 역할을 한다. 기능이 완전히 출시되고 나면 플래그는 제 몫을 다한다. 그런데도 분기 로직은 죽은 무게로 코드베이스에 남고, 아무도 테스트하지 않는 잠든 경로가 실수로 다시 켜질 수 있다.
손으로 감당할 수 없게 만드는 건 규모다. 논문은 저장소 623곳에 피처 플래그가 5만 6000개 넘게 있고, 2025년 5월 기준 그중 1659개가 방치 상태였다고 집계했다. DoorDash가 직접 쓴 엔지니어링 블로그는 현재 플랫폼의 동적 값이 6만 개를 넘었고 매달 2300개가량이 새로 생긴다고 밝혔다. 저자들은 규칙 기반 정리 도구로는 DoorDash 코드베이스를 감당하지 못했다고 적었다. 플래그를 제대로 걷어내려면 심벌을 패턴으로 찾는 수준이 아니라, 주변 조건문이 어떤 값으로 수렴하는지를 따져야 하기 때문이다.
2단계 에이전트 시스템은 이렇게 돌아간다
1단계는 계획이다. Claude Sonnet으로 돌아가는 오케스트레이터 에이전트가 Jira 티켓을 가져오고, MCP로 실험 플랫폼의 실시간 롤아웃 데이터를 조회하며, 저장소 전체를 의미 단위로 훑은 뒤, 플래그를 어떤 값으로 대체할지 명시한 구조화된 정리 계획을 내놓는다. 코드에 손대기 전에 엔지니어가 그 대체 값을 확인한다. 이 루프에서 사람이 개입하는 유일한 지점이다.
2단계는 수술이다. 확정된 값 하나당 제거 에이전트 하나가 Claude Opus로 붙고, 저장소당 최대 4개가 동시에 돌아간다. 각 에이전트는 별도의 git worktree에서 작업해 병렬 수정이 서로 충돌하지 않는다. Gradle은 --no-daemon으로 실행해 빌드 상태가 worktree 사이로 새지 않게 막고, 에이전트마다 1시간 하드 타임아웃을 건다.
진짜 눈여겨볼 대목은 게이트다. 에이전트가 풀 리퀘스트를 열려면 빌드, 테스트 스위트, JaCoCo 패치 커버리지 하한선 95%, Detekt 정적 분석을 먼저 통과해야 한다. 하나라도 실패하면 PR은 아예 생기지 않는다. 모델을 나눈 기준도 대놓고 경제적이다. 값싼 모델이 메타데이터 수집과 계획을 맡고, 비싼 모델은 호출 체인 추론과 실제 코드 수정에��� 투입한다.
플래그 50건 평가가 실제로 보여준 것
평가 대상은 쉬운 사례만 골라 담지 않았다. 불리언 값 41개, 문자열 6개, 정수형 3개로 구성했고, 파일 한두 개만 건드리는 단순 사례 6건, 파일 3~5개에 걸친 중간 사례 18건, 중첩 조건문과 파일 간 의존성이 얽힌 복잡 사례 26건으로 나눴다.
1차 시도 성공률은 복잡도를 거의 그대로 따라갔다. 단순 100%, 중간 94%, 복잡 85%다. 비용도 마찬가지였다. 단순 정리는 평균 7.5분에 2.69달러, 중간은 10.4분에 3.46달러, 복잡은 17.7분에 6.20달러가 들었다. 승인된 풀 리퀘스트 45건 중 14건은 사소한 수정이 한 번 필요했고, 5건은 엔지니어가 직접 손을 봐야 했다.
실패 양상은 구체적이라 참고할 만하다. 재작업 6건은 패치 커버리지 미달에서, 8건은 불완전한 제거에서 나왔다. 변수가 하나 남았거나, 호출 체인 깊은 곳에 참조가 살아 있는 식이다. 사람이 개입한 5건은 전부 호출 체인의 깊이, 그리고 인터페이스를 가로질러 파라미터가 전달되는 구조와 얽혀 있었다. 파일 단위 시야로 일하는 코딩 에이전트가 가장 취약한 지점이 바로 이 추론이다.
살아남는 에이전트 도입은 무엇이 다른가
구조를 뜯어보면 낯익은 패턴이 보인다. 작업 단위별 격리, 좁게 잡은 사람의 승인 지점, 그리고 에이전트가 말로 넘어갈 수 없는 기계적 게이트다. Cloudflare가 컨텍스트를 공유하지 않는 에이전트 4개로 Astro의 열린 이슈를 85% 줄였을 때와 같은 모양이다. 모델 선택은 비용 항목일 뿐이고, 제품의 본체는 게이트다.
경제성은 가장 나쁜 구간에서도 성립한다. 복잡 사례가 6.20달러에 18분 미만이고, 사람이 하면 1~2시간짜리 일이다. 걸리는 건 표본 크기다. 50건은 파일럿이지 1659건짜리 백로그가 아니다. 게다가 비용과 실패는 그 백로그의 다수를 차지하는 복잡 구간에 몰려 있다. 85%가 전체 대기열과 부딪히고도 유지되는지가 지켜볼 숫자다.
자주 묻는 질문
DoorDash의 정리 시스템은 어떤 모델을 쓰나
역할을 나눠 두 가지를 쓴다. Claude Sonnet 오케스트레이터가 Jira 조회, 실시간 롤아웃 데이터에 대한 MCP 질의, 계획 수립을 맡는다. 코드 수정은 Claude Opus 에이전트가 수행한다. 호출 체인 추론이야말로 더 비싼 모델이 값을 하는 영역이기 때문이다.
에이전트가 빌드를 깨뜨리는 건 무엇이 막나
각 에이전트는 격리된 git worktree에서 작업하고, 풀 리퀘스트를 만들기 전에 빌드, 테스트 스위트, JaCoCo 패치 커버리지 95% 기준, Detekt 정적 분석을 모두 통과해야 한다. 멈춰 선 에이전트는 1시간 하드 타임아웃으로 끊는다.
이 정리 작업은 완전 자율인가
아니다. 계획 단계 끝에서 엔지니어가 대체 값을 확인한 뒤에야 코드 수정이 시작되고, 그렇게 나온 풀 리퀘스트도 평소와 같은 리뷰를 거친다. 평가에서도 50건 중 5건은 엔지니어가 직접 개입해야 했다.
