Claude가 앱의 일상 유지보수를 맡는 실험

Boris Cherny (@bcherny)

게시물에 이름이 나온 네 루틴

네 루틴 모두 “찾는다”에서 끝나지 않고 수정 PR까지 갑니다. 특히 Dead-code remover는 하루를 기다립니다 — 정적 분석의 판단을 런타임 관측으로 한 번 더 검증하는 구조입니다.

번역상 주의점

• fuzz — 무작위 바이트를 넣는 전통적 퍼저만을 뜻하지 않습니다. 실제 앱을 실행하고 여러 UI 동작을 시도해 충돌 경로를 찾는 탐색적 E2E 퍼징까지 포함합니다.
• root cause — 증상만 막는 패치가 아니라, 충돌이나 테스트 불안정성의 근본 원인을 밝힌다는 뜻입니다.
• put up a PR — 수정 브랜치를 만들고 Pull Request를 올린다는 뜻입니다.
• leaky abstraction — 상위 계층이 하위 구현의 내부 사정을 알아야 하는 등 추상화 경계가 새는 상태입니다. 첨부 이미지의 목록은 Abstraction police를 “계층 위반 수정”으로 더 구체적으로 설명합니다.

사람 없는 자동 운영이 아니라, 매일 도는 반자동 유지보수 파이프라인이다

이 실험의 핵심은 “AI가 코드를 많이 쓴다”가 아닙니다. 그동안 경제성이 낮아 방치되던 유지보수 작업을, 매일 자동으로 찾아내 리뷰 가능한 작은 PR로 포장하는 비용이 급격히 낮아졌다는 점입니다. 최종 병합 권한은 여전히 사람에게 있습니다.

하루 한 바퀴. 오른쪽 끝에서 되돌아오는 굵은 선이 이 실험의 핵심입니다 — 되돌아가는 지점이 PR이 아니라 루틴입니다.

1. 탐지 — 저장된 루틴이 매일 실제 앱과 코드베이스, CI를 검사한다
2. 재현 — 충돌·중복·죽은 코드·불안정 테스트의 근본 원인을 찾는다
3. 제안 — claude/ 브랜치에 작은 수정과 PR을 만든다
4. 증빙 — 재현 절차, /verify 결과, 진리표를 PR에 첨부한다
5. 검토 — Claude Code Review가 코멘트를 남기고, 사람이 병합을 결정한다
6. 개선 — 결과가 나쁘면 PR이 아니라 루틴 자체를 고친다

↳ 6단계가 다시 1단계로 이어지는 것이 이 시스템의 진짜 제품입니다.

사전 분석 문서를 공개 자료와 대조한 결과

원 분석의 큰 틀은 정확합니다. 다만 제품 상태와 요금, 이미지 판독에서 보정할 항목 6가지가 나왔습니다.

네 개의 층이 겹쳐야 이 파이프라인이 성립한다

게시물은 간단해 보이지만, 실제로는 서로 다른 네 개의 제품이 한 줄로 엮여 있습니다. 하나라도 빠지면 같은 워크플로가 재현되지 않습니다.

루틴들은 어떻게 하나의 루프가 되는가

루틴 하나하나는 서로를 모릅니다. 그런데도 전체가 한 시스템처럼 움직이는 이유는 세 가지를 공유하기 때문입니다. 같은 완료 규격(재현 절차·/verify·진리표), 같은 리뷰 큐, 같은 피드백 채널(Slack 스레드 → 루틴 조정). 오케스트레이션은 소프트웨어가 아니라 이 세 가지 약속입니다.

진리표는 두 번 등장합니다. 실행 전에는 루틴 프롬프트 안의 완료 조건으로, 실행 후에는 PR에 첨부되어 리뷰어가 읽는 증빙으로. 이 이중 역할이 없으면 왼쪽의 독립된 루틴들과 오른쪽의 단일 리뷰 큐가 연결되지 않습니다.

지시문에 숨어 있는 것은 작업 내용이 아니라 완료 조건이다

2026년 7월 19일 오후 12:30과 12:43, 두 개의 메시지로 iOS·Android·Desktop의 E2E 충돌 퍼징, 비즈니스 로직 버그 수정과 단순화, 중복 통합, 불안정 테스트 근본 원인 수정, 무용 테스트 삭제, 죽은 코드 제거 루틴이 한꺼번에 만들어집니다. 여기서 중요한 것은 무엇을 시켰는지가 아니라, 무엇을 해야 끝난 것으로 인정하는지를 못 박았다는 점입니다.

여기서 말하는 진리표는 이런 형태입니다

이 표가 하는 일은 단 하나입니다. 정상 경로 하나가 통과했다는 이유로 에이전트가 작업을 끝났다고 선언하지 못하게 만드는 것. 자율 실행 세션에는 중간 승인이 없으므로, 완료 조건은 프롬프트 안에 미리 들어가 있어야 합니다.

11종은 다섯 가지 목적으로 묶인다

Improver와 Police는 반대 방향의 교정입니다. 전자는 추상화가 너무 많은 문제를, 후자는 있는 추상화가 지켜지지 않는 문제를 다룹니다. 하나는 계층을 줄이고, 하나는 건너뛴 계층을 되돌립니다. 이름이 비슷해서 하나로 합치면 두 방향이 서로를 되돌리는 PR을 만들게 됩니다.

Ant-only는 Anthropic 내부 전용 기능을 가리키는 사내 표현으로 보입니다. 이미지가 “forgotten internal-only features”라고 명시하므로 그 범위 안에서만 해석했습니다.

46.4%는 정확도가 아니다

이 비율을 정확도로 읽으면 안 되는 이유

• 분모가 아직 닫히지 않았습니다. 어제 열린 PR도 388에 들어 있지만 병합될 시간은 없었습니다. 관측 시점 비율은 최종 병합률의 하한에 가깝습니다.
• 208의 내역이 공개되지 않았습니다. 리뷰 대기, 중복, 우선순위 보류, CI 실패, 불필요 판정이 모두 섞여 있을 수 있습니다.
• PR 개수는 생산성이 아닙니다. 작고 기계적인 PR을 많이 만들면 숫자는 쉽게 올라갑니다. 크기·난이도·리뷰 시간·병합 후 회귀율이 없으면 품질을 알 수 없습니다.
• 환경이 분리되지 않았습니다. Anthropic 내부의 시뮬레이터, CI, 관측, 코드 리뷰 인프라가 결과에 얼마나 기여했는지 알 수 없습니다.

비용은 부분적으로 계산할 수 있습니다

사전 분석은 “비용 정보가 없다”고 했지만, 리뷰 쪽은 공개 단가가 있습니다. Code Review는 PR 크기와 복잡도에 따라 건당 평균 $15–25입니다. 388건 모두 리뷰가 돌았다고 가정하면 리뷰 비용만 대략 $5,800–9,700입니다. 여기에 388건의 루틴 실행 토큰, 시뮬레이터·CI 시간, 그리고 가장 비싼 항목인 사람의 리뷰 시간이 더해집니다. 자동화의 ROI는 PR 개수가 아니라 절약된 순공수 − (검토 + 운영 + 실패) 비용입니다.

실행 규모는 공개 한도를 넘어선다

지시문이 “앱마다 별도의 루틴”을 요구하므로 실행 횟수는 플랫폼 수와 루틴 수의 곱으로 늘어납니다.

현재 증거가 지지하는 결론은 여기까지입니다. 테스트와 리뷰 기반이 잘 갖춰진 대규모 코드베이스에서, 에이전트가 반복적인 유지보수 후보를 지속적으로 발굴하고 그중 상당수를 사람이 병합할 수 있는 PR로 만드는 일이 실용 단계에 접근했다는 것. “앱 유지보수가 자율화되었다”거나 “사람 개발자가 불필요해졌다”는 결론은 이 자료로 뒷받침되지 않습니다.

왜 하필 유지보수가 먼저 뚫렸는가

1. 목표가 좁고 검증 가능하다

신규 기능은 “무엇을 만들 것인가”부터 모호합니다. 반면 죽은 코드 제거, 플래그 정리, 충돌 재현은 성공 조건을 테스트와 diff로 표현할 수 있습니다. 정답이 있는 문제부터 넘긴 것입니다.

2. 실패가 PR에서 멈춘다

운영 환경 배포가 아니라 격리된 브랜치의 제안입니다. 잘못된 결과의 처리 비용이 “닫기” 한 번입니다.

3. 단발성 프롬프트가 아니라 개선되는 공정이다

잘못된 PR이 나오면 그 PR을 손보는 대신 생성 루틴을 고칩니다. 한 번의 개선이 이후 모든 실행에 재사용됩니다. 실질적으로는 에이전트용 SOP와 완료 규격을 계속 개발하는 일입니다. 게시물도 “며칠씩 걸리기도 한다”고 인정합니다.

4. 사람이 미루기 쉬운 일을 매일 한다

중복 제거, 불안정 테스트 조사, 오래된 플래그 삭제는 중요하지만 긴급하지 않아 밀립니다. 에이전트의 가치는 인간을 넘는 창의성보다 빠짐없는 성실성에 가깝습니다.

5. 관측을 먼저 추가하는 보수적 전략을 쓴다

확실한 죽은 코드는 삭제하지만, 의심만 되는 코드에는 먼저 로깅을 넣고 다음 날 판단합니다. 정적 분석 → 런타임 관측 → 삭제로 이어지는 다단계 검증입니다. 이 실험에서 가장 이식할 가치가 큰 패턴입니다.

기존 자동화와 무엇이 다른가

Renovate는 오래전부터 저장소를 검사해 의존성 업데이트 PR을 만들고, 필수 테스트가 통과하면 제한적으로 자동 병합까지 합니다. 다만 대상이 구조화된 영역에 한정됩니다. 무엇이 최신 버전인지는 기계가 판정할 수 있습니다.

GitHub Copilot cloud agent는 이슈를 배정받아 저장소를 조사하고 브랜치와 PR을 만들며, 일정이나 이벤트로 자동 실행하는 automation도 제공합니다. 업계 전체가 “사람이 과제를 지정하고, 에이전트가 격리된 변경 묶음으로 납품하며, 사람이 승인한다”는 형태로 수렴하고 있습니다.

이 실험이 다른 지점은 두 가지입니다. 첫째, 대상이 의미상 중복이나 충돌 원인처럼 판정 기준이 열린 문제라는 것. 둘째, 사람이 과제를 지정하지 않고 후보 발굴 자체를 상시 프로그램으로 만들었다는 것입니다.

복제하기 전에 계산해야 할 것들

PR 홍수와 리뷰 병목

생성 비용은 떨어져도 사람의 검토 시간은 자동으로 줄지 않습니다. 388개는 성과인 동시에 새로운 운영 부하입니다. 낮은 가치의 PR이 쌓이면 중요한 변경이 묻히고, 리뷰어가 자동 생성물을 습관적으로 승인하는 자동화 편향이 생깁니다. 게시물이 “병합을 간소화할 방법을 고민 중”이라고 쓴 것은 병목이 이미 생성에서 승인으로 옮겨갔다는 신호입니다.

작성자와 리뷰어의 상관된 오류

같은 모델 계열이 코드를 쓰고 리뷰하면 같은 잘못된 가정을 공유할 수 있습니다. Code Review는 여러 에이전트를 병렬로 돌리고 검증 단계로 오탐을 걸러 이 문제를 부분적으로 완화하지만, 독립적인 정적 분석·보안 검사·사람의 도메인 판단을 대체하지는 않습니다.

거짓 dead code

리플렉션, 동적 import, 플러그인, 드문 기능 플래그, 외부 진입점은 정적 분석에서 도달 불가능하게 보입니다. 런타임 로깅도 관측 기간에 실행되지 않았다는 사실만 보여 줄 뿐, 영원히 필요 없음을 증명하지 못합니다. 분기·연말 배치, 재해 복구 경로가 대표적인 함정입니다.

무의미한 테스트라는 판정

“실패할 수 없는 테스트”는 무가치할 수도 있지만, API 사용 예시나 타입 보장, 과거 회귀 방지, 문서 역할을 할 수도 있습니다. 삭제 전에 그 테스트가 왜 생겼는지를 확인해야 합니다.

주관적인 리팩터링

비슷한 구현이 의도적으로 분리돼 있을 수 있고, 새는 것처럼 보이는 추상화가 성능이나 호환성 때문에 필요할 수 있습니다. Dup unifier와 추상화 계열은 도메인 지식 없이 가장 쉽게 과잉 수정하는 영역입니다.

권한과 프롬프트 인젝션

루틴은 실행 중 대화형 승인 없이 셸 명령과 포함된 커넥터의 쓰기 도구까지 사용할 수 있습니다. 공식 문서는 저장소·환경 변수·네트워크 접근·커넥터를 필요한 최소 범위로 줄이라고 안내하며, 환경 변수는 그 환경을 쓰는 모든 사람에게 보인다고 경고합니다. 기본 환경은 허용 목록 외 도메인을 차단합니다. API 트리거로 들어온 텍스트는 신뢰할 수 없는 데이터로 표시되어 전달되지만, 실행 중 가져온 이슈·로그·문서의 내용은 여전히 인젝션 경로입니다.

신뢰 범위를 단계적으로 넓히는 5단계

1. 탐지만 수행 — 후보를 찾되 수정하지 않는다. 근거·예상 영향·재현 절차만 보고하고, 사람이 유효 후보 비율을 측정한다.
2. Draft PR만 생성 — 한 PR에 한 가지 기계적 목적만. diff 크기와 변경 파일 수에 상한을 둔다. 재현 절차, 진리표, 실행한 테스트, 롤백 방법을 PR 템플릿으로 강제한다.
3. 독립 검증을 강화 — CI, 타입 검사, 린터, 정적 분석, 보안 검사, E2E를 필수 상태 검사로. AI 작성자와 별개인 규칙 기반 검사를 두고 코드 오너 승인을 유지한다.
4. 위험도별 큐 운영 — 아래 표.
5. 지표를 바꾼다 — PR 개수 대신 아래 목록을 본다.

측정할 지표

• 후보 중 유효 항목 비율 / 첫 PR이 수정 없이 승인된 비율
• PR당 사람 리뷰 시간, 열린 자동 PR 수와 평균 대기 시간
• 병합 후 롤백·회귀율
• 삭제된 코드량, 줄어든 테스트 불안정성
• CI·모델·시뮬레이터·리뷰 비용 대비 실제로 절약된 엔지니어 시간

병목은 코드 작성량에서 완료 조건 설계로 옮겨간다

이 사례를 “Claude가 개발자를 대신해 앱을 관리한다”로 요약하면 과장입니다. 더 정확한 표현은 이렇습니다.

그리고 이것이 성립하려면 에이전트보다 주변 시스템이 먼저 준비되어야 합니다. 실제 앱을 자동 실행할 수 있어야 하고, 실패를 안정적으로 재현할 수 있어야 하며, 완료 조건을 /verify·진리표·불변조건으로 표현할 수 있어야 하고, 변경이 작은 PR과 격리 브랜치에 머물러야 하며, 잘못된 결과가 다음 루틴 개선으로 이어져야 합니다.

이 모델이 퍼지면 개발 조직의 병목은 좋은 완료 조건을 설계하는 능력, 검증 인프라, 리뷰 처리량, 권한 통제, 그리고 자동화의 경제성을 판단하는 능력으로 이동할 가능성이 큽니다. 388이라는 숫자보다, 그 숫자를 만든 루틴을 고치는 루프가 이 실험의 진짜 결과물입니다.

이 문서가 확인하지 못한 것

• 388개 PR, 180개 병합, “대체로 첫 시도에 맞는다”는 평가는 모두 자기보고입니다. 개별 PR은 비공개 저장소에 있어 독립 검증이 불가능합니다.
• 미병합 208개의 상태, PR 크기와 난이도, 사람의 리뷰 시간, 병합 후 회귀율은 공개되지 않았습니다.
• Claude Tag 정체성이 루틴을 보유·실행하는 구조는 공개 문서로 확인되지 않습니다. 사내 버전일 수 있습니다.
• Routines와 Code Review는 모두 research preview입니다. 한도, 요금, 기능이 바뀔 수 있으므로 도입 검토 시에는 문서를 다시 확인해야 합니다.
• 첨부 이미지의 루틴 표는 아래가 잘려 있어, 운영 중인 루틴의 전체 목록은 알 수 없습니다.