DoorDash가 Claude 에이전트로 스테일 플래그 50건 중 45건의 PR을 냈다. 핵심은 틀려도 동작은 그대로 두고 코드만 남게 짠 두 개의 관문이다. 우리 에이전트 작업이 실패하면 무엇이 남는지부터 두 칸으로 나눠 세라.
에이전트 파일럿을 보고하는 자리에서 첫 숫자는 대개 성공률이다. 90%면 확대, 60%면 보류. 이 숫자는 나머지가 무엇을 남기는지 말하지 않는다. 틀린 결과가 리뷰에서 걸리는 미완성인지, 아무도 모르게 운영 동작을 바꾸는 변경인지에 따라 같은 90%의 값은 완전히 달라진다.
InfoQ 9월 18일 보도에 따르면 DoorDash 실험 플랫폼에는 623개 저장소에 걸쳐 6만 개 넘는 피처 플래그가 있고, 매달 약 2,300개가 새로 생긴다. 90일간 수정되지 않았는데 코드에 남은 플래그가 스테일로 분류되며 1,000개를 넘는다. 수작업 정리는 건당 1~2시간이다. DoorDash는 이 일을 멀티 에이전트 시스템에 넘겼다. 결과보다 볼 만한 것은 실패의 모양을 미리 정해 둔 방식이다.
에이전트가 코드에서 알 수 없는 값 하나는 사람이 먼저 확정한다
DoorDash 엔지니어링 블로그 원문의 구조는 두 단계다. 1단계에서 Claude Sonnet 오케스트레이터가 Jira에서 스테일 플래그 티켓을 가져오고, MCP로 실험 플랫폼에 롤아웃 비율과 목표값을 묻는다. 엔지니어가 그 목표값을 확인해야 2단계로 넘어간다.
이유는 하나다. ZenML LLMOps 데이터베이스 정리가 옮긴 원문 표현대로, 소스 코드의 기본값에서 추론한 값을 하드코딩하면 실제 롤아웃 상태와 다를 때 동작이 조용히 바뀐다. 플래그 정리에서 가장 나쁜 실패는 코드를 덜 지우는 것이 아니라 켜져 있던 기능을 꺼진 쪽으로 굳히는 것이다. 그 실패의 입력값을 에이전트의 추론이 아니라 운영 데이터와 사람의 확인으로 막았다.
2단계는 Claude Opus 정리 에이전트가 맡는다. 에이전트마다 격리된 Git 워크트리를 쓰고, 저장소당 최대 4개가 동시에 돌며, 1시간 하드 타임아웃이 걸린다. 빌드·테스트·Detekt 정적 분석·JaCoCo 패치 커버리지 95% 이상을 통과해야 PR이 열린다. 격리가 처리량을 정한다는 이야기는 코딩 에이전트는 격리된 작업장만큼만 일한다에서 다뤘다. 여기서 격리는 처리량보다 실패를 워크트리 하나에 가두는 장치로 쓰였다.
90%와 62% 사이에 사람의 리뷰 시간이 있다
| 복잡도 | 건수 | 성공률 | 평균 비용 | 평균 시간 |
|---|---|---|---|---|
| 단순 | 6 | 100% | $2.69 | 7.5분 |
| 중간 | 18 | 94% | $3.46 | 10.4분 |
| 복잡 | 26 | 85% | $6.20 | 17.7분 |
| 전체 | 50 | 90% | $4.79 | 13.8분 |
세 비율을 건수로 되돌리면 45건이다. ICSME 2026 산업 트랙 초록은 이 45건을 엔지니어가 승인한 PR로 적는다. 그중 첫 패스로 병합된 것은 31건이고 14건은 한 번 수정을 거쳤다. 첫 패스 기준으로는 62%다. 나머지 5건은 깊은 호출 체인과 인터페이스를 넘나드는 파라미터 전달에서 엔지니어가 개입했다. $4.79와 13.8분은 에이전트의 값이고, 수정 14번과 개입 5번은 사람의 시간이다.
그래도 이 62%를 받아들일 수 있는 건 실패의 방향이 정해져 있어서다.
원문은 한계를 이렇게 적었다. 이 시스템은 복잡한 호출 체인에서 안전하지 않은 의미 변경을 하기보다 죽은 코드를 덜 지운 채 남길 가능성이 더 높다. 평가한 50건에서 버그나 회귀는 보고되지 않았다. 덜 지운 코드는 다음 정리 때 다시 잡는 부채이고, 바뀐 동작은 장애다.
같은 설계는 배포에서도 보인다. GitHub 9월 18일 npm 공지의 'stage only' 토큰은 npm stage publish로 버전을 올려 두기만 하고, 실제 배포는 메인테이너가 2FA로 승인한다. 2FA 우회 설정이 있어도 직접 npm publish는 거절된다. 자동화가 최악으로 틀려도 남는 건 배포되지 않은 스테이징 버전이다.
반대 방향의 사례도 있다. InfoQ 9월 20일 보도에 따르면 Alibaba의 OpenCodeReview는 AACR-Bench 독립 테스트에서 정밀도 약 12%, 최대 설정 재현율 20%였다. 리뷰에서 LLM의 실패는 조용한 통과로 나타난다. 이런 도구를 병합 전 유일한 관문으로 두면 실패는 아무도 모르는 쪽으로 쌓인다.
가져갈 것
에이전트에 넘길 백로그 작업 하나를 정해 두고 답해 보라.
- 에이전트가 코드만 보고는 알 수 없는 운영 값(DoorDash의 실험 플랫폼 목표값)을 작업 시작 전에 사람이 확인하는 단계가 있는가?
- PR을 여는 조건이 빌드·테스트·정적 분석·패치 커버리지(DoorDash는 Detekt, JaCoCo 95%) 통과로 파이프라인에 박혀 있는가?
- 에이전트마다 격리된 워크트리를 주고, 저장소당 동시 실행 수(DoorDash는 4개)와 하드 타임아웃(1시간)을 정했는가?
- 파일럿 보고서에 '쓸 만한 PR 비율'과 '첫 패스 병합 비율'(DoorDash 90% 대 62%)을 따로 적는가?
- 실패 사례를 '덜 끝냄'과 '동작을 바꿈' 두 칸으로 나눠 세고, 두 번째 칸이 0건인지 확인하는가?
- npm 자동 배포 토큰을 2027년 1월 2FA 우회 토큰 직접 배포 종료 전에 'Read and write (stage only)'로 바꿀 담당자가 있는가?
안 되는 경우
- 평가 표본은 Kotlin 저장소의 스테일 플래그 50건이다. 다른 언어나 마이그레이션 같은 다른 작업에서 같은 비율이 나온다는 근거는 소스에 없다.
- 플래그 목표값을 실험 플랫폼이 아니라 설정 파일·환경변수로만 관리하는 조직에는 1단계의 MCP 조회가 성립하지 않는다. 사람이 무엇을 기준으로 확인할지부터 새로 정해야 한다.
- 소스는 $4.79에 엔지니어의 목표값 확인·리뷰·수정 시간이 들어가는지 밝히지 않는다.
- 수치 시점이 섞여 있다. ICSME 초록은 2025년 5월 기준 플래그 5만6천 개·스테일 1,659개, InfoQ 기사는 6만 개 이상·스테일 1,000개 이상이다. 전체 백로그 중 실제로 정리한 건수는 공개되지 않았다.
이번 주에 바꿀 것은 파일럿 보고서의 첫 줄이다. 성공률 옆에 '실패하면 무엇이 남는가'를 한 칸 더 두고, 그 칸이 동작 변경이면 에이전트보다 앞에 사람의 확인 단계를 먼저 만든다. 어느 업무에 에이전트를 먼저 붙일지 정하는 자리에서도 이 질문은 모델 비교보다 앞에 와야 한다. 사업영역 →