논문 리뷰 · 2026년 10월 26일
멀티 에이전트 LLM 시스템으로 대규모 Feature Flag 정리 자동화: DoorDash 산업 적용 사례
Automating Feature Flag Cleanup at Scale with Multi-Agent LLM Systems: An Industrial Experience at DoorDash
Orchestrator 에이전트와 병렬 제거 에이전트로 오래된 Feature Flag 정리를 자동화해, 50개 중 45개(90%)에서 엔지니어가 승인한 PR을 건당 평균 4.79달러·13.8분에 만들었다.
문제
Feature Flag는 기능을 점진 배포하거나 실험할 때 쓰지만, 배포가 끝나면 기술 부채가 되고 휴면 코드가 다시 켜질 위험이 생긴다. DoorDash에는 623개 저장소에 5만 6천 개가 넘는 Flag(사내 명칭 DV)가 있고, 2026년 5월 기준 1,659개가 오래된 상태다. 수동 정리에는 건당 1~2시간이 든다(사내 추정). Piranha 같은 AST 기반 규칙 도구는 의존성 주입 래퍼 패턴, 불리언이 아닌 Flag, 여러 파일에 걸친 수정 때문에 이 환경에 적용할 수 없었다.
방법
Google ADK로 만든 2단계 멀티 에이전트 시스템이다. 1단계에서는 Claude Sonnet 4.6 기반 Orchestrator가 Jira 티켓을 읽고, MCP로 실험 플랫폼에서 실제 운영 Rollout 상태(Rollout 비율, 최종 값)를 조회하고, 코드 참조를 찾아 정리 보고서를 만든다. 엔지니어가 목표 값을 확인하면, 2단계에서 Claude Opus 4.6 기반 제거 에이전트가 Flag마다 격리된 git worktree에서 병렬로 작업한다(저장소당 최대 4개). 제거 에이전트는 상수·래퍼·호출부 제거, 조건문 단순화, 테스트 수정, 빌드·테스트 통과, 패치 커버리지 95% 이상, Detekt 린트를 거쳐 PR을 만든다. 에이전트당 1시간 타임아웃도 둔다.
결과
- 최근 50개 Flag 정리 중 31개(62%)는 첫 시도에 그대로 승인됐고, 14개(28%)는 작은 수정 후 승인, 5개(10%)는 엔지니어 개입이 필요했다. 전체 정리 성공률은 90%다.
- CI 첫 통과율은 88%(44/50)였다. 실패 6건은 모두 패치 커버리지 부족 때문이었고, 잘못된 코드 변경 때문은 아니었다.
- 복잡도별 성공률은 단순 100%(6/6), 중간 94%(17/18), 복잡 85%(22/26)였다. 저자들은 실패 원인이 Flag 유형이나 파일 수가 아니라 여러 인터페이스를 거치는 깊은 호출 체인이라고 분석했다.
- 건당 평균 13.8분(중앙값 12.3분), LLM API 비용 평균 4.79달러(중앙값 3.49달러)였다. 사내 추정 수동 작업 시간(1~2시간)보다 크게 짧다.
- 저자들은 생성된 50개 PR 모두에서 버그나 회귀가 관찰되지 않았다고 보고했다. 한계는 정확성이 아니라 완결성(일부 죽은 코드 누락)에 있다는 해석이다.
한계
한 회사의 Kotlin 저장소, 특정 DV 접근 패턴(의존성 주입 래퍼)에서 50건만 평가했다. 각 Flag는 한 번만 실행해 LLM 비결정성의 영향을 보지 못했다. 복잡도 분류는 저자들이 사후에 정했고, 수동 정리 1~2시간은 실측이 아닌 사내 추정이다. 개발자 피드백은 비공식적으로 모았다. Piranha 등 기준선과 같은 데이터에서 직접 비교한 실험은 없다. 다른 언어나 Flag 프레임워크로의 일반화는 추가 검증이 필요하다.
의미
코딩 에이전트를 실제 운영 코드베이스의 반복적인 정리 작업에 투입한 사례로, 성공률·비용·시간·실패 원인을 수치로 공개했다. 저자들은 실제 배포 상태를 조회하는 데이터 소스, 병렬 작업을 위한 worktree 격리, PR 생성 전의 결정론적 검증 게이트를 실무 전제 조건으로 제시한다. 비슷한 자동화를 검토하는 팀에게 바로 참고가 된다.
핵심 용어
- Feature Flag
- 코드를 다시 배포하지 않고 런타임 설정으로 기능을 켜고 끄는 장치다. 점진 배포, A/B 테스트, 긴급 차단에 쓴다.
- MCP(Model Context Protocol)
- LLM 에이전트가 외부 도구·데이터 소스를 표준 방식으로 호출하게 하는 프로토콜이다. 이 시스템에서는 실험 플랫폼의 실제 Rollout 상태를 조회하는 데 썼다.
- git worktree
- 한 저장소에서 여러 작업 디렉터리를 동시에 쓰게 하는 git 기능이다. 병렬 에이전트가 서로의 파일을 덮어쓰지 않도록 격리하는 데 썼다.
- 패치 커버리지(Patch Coverage)
- 이번 변경으로 바뀐 코드 줄 중 테스트가 실행하는 비율이다. 이 시스템은 95% 이상을 PR 생성 조건으로 둔다.
원문
저자: Atharv Chandratre, Jai Datar · 게시 2026-10-22 · 라이선스 arXiv 비독점 배포 라이선스 · 본문 기준 분석
이 리뷰는 AI가 논문을 읽고 작성한 요약이며, 정확한 내용은 원문을 기준으로 확인해 주세요.