Claude에게 앱 일상 유지보수를 맡기는 실험

셋업 — Slack 채널 하나가 전부다

구성은 단순하다. proj-claude-maintains-apps라는 Slack 채널에서 Claude Tag가 매일 자동 루틴(daily routines)을 돌린다. 대상은 Claude 제품군 전체 — iOS · Android · Desktop · web · CLI · Agent SDK 6개 플랫폼이다. 사람이 작업을 지시하는 게 아니라, 미리 정의된 루틴이 매일 스스로 코드베이스를 순찰하고 PR을 연다.

루틴 카탈로그 — 11종의 자동 유지보수 봇

루틴은 각각 하나의 유지보수 관점을 담당한다. 공개된 카탈로그 전수는 다음과 같다.

결함 탐지·수리

Crash fuzzer — 시뮬레이터에서 실제 앱을 열고 탭을 난사해 크래시를 유발, 근본원인을 찾아 수정 PR을 연다

Logic bugfixer — 까다로운 비즈니스 로직을 형식적으로 모델링해 버그를 찾아 고친다

Flaky-test fixer — 불안정한 CI 테스트의 근본원인을 추적한다

코드 다이어트

Dead-code remover — 정적으로 도달 불가능한 코드를 삭제한다. 죽었다고 의심되는 코드에는 로깅을 심어 하루 관찰 후, 정말 죽었으면 다음 날 제거한다

Useless-test pruner — 실패할 수 없는(무의미한) 테스트를 삭제한다

Shipped-feature inliner — 완전히 출시된 기능의 피처 플래그를 걷어낸다

Ant-only shipper — 방치된 내부 전용 기능을 사용량 기준으로 출시하거나 삭제한다

구조 개선

Dup unifier — 비슷하지만 미묘하게 갈라진 중복 구현을 스캔해 하나로 통합하는 PR을 연다

Logic simplifier — 뒤엉킨 비즈니스 로직을 단순화한다

Abstraction improver — 과잉 설계된 추상화를 평탄화한다

Abstraction police — 새는 추상화(leaky abstraction)와 레이어링 위반을 고친다

결과 — 388 PR 중 180 머지, 첫샷 정확도가 관건

수주간 루틴들이 388개 PR을 열었고, 그중 180개(~46%)가 Claude Code Review + 휴먼 리뷰를 거쳐 머지됐다.

저자의 평가는 "surprisingly positive". Claude는 대체로 첫 시도에 올바른 PR을 만들고, 틀리면 사람이 고쳐주는 게 아니라 Claude에게 루틴 자체를 튜닝시켜 다음 날 더 잘하게 만든다 — 때로는 며칠의 튜닝이 걸린다. 즉 운영 루프는 "PR 수정"이 아니라 "루틴 개선"이다. 팀은 현재 이런 기계적 변경(mechanical changes)의 머지를 더 매끄럽게 만드는 방법을 고민 중이다.

재현 경로

동일 워크플로우는 Claude Code나 Tag에게 요청하거나, claude.ai/code에서 루틴을 직접 생성해 시도할 수 있다. 저자는 실제 사용한 Slack 프롬프트 원문(7/19)도 공개했다 — 크래시 퍼저는 "목 없이 실제 앱 구동(no mocks)", 각 PR은 "/verify 실행 + 재현(repro)과 truth table을 PR에 첨부", 로직 버그픽서는 "로직을 형식적으로 모델링(formally model the logic)"하라는 식으로, 검증 산출물을 PR에 강제하는 설계다.

비용 논쟁 — 개인은 무리, 회사 규모에서 유효

"And it only costs $1000/day to use Claude models to do so!" — 댓글 반응

댓글의 핵심 반론은 비용이다("일 $1000", "무제한 토큰 예산이 있어야"). 저자도 이를 부정하지 않고 인정한다: "개인에게는 아마 말이 안 되지만, 여러 앱을 만드는 회사에게는 정말 유용했다." 즉 이 워크플로우의 경제성은 토큰 비용 대비 유지보수 인건비가 큰 조직 규모에서 성립한다는 게 저자 스스로의 포지셔닝이다.

원본 (완역)

포스트 1/4 원문

지난 몇 주간 해본 좀 이상한 실험이 하나 있는데, 우리 앱들의 일상 유지보수(day-to-day maintenance)를 Claude에게 통째로 맡겨보는 것이다. 이게 가능할지도 모른다는 초기 신호들이 보이고 있다.

셋업은 단순하다. proj-claude-maintains-apps라는 Slack 채널이 하나 있고, 그 안에서 Claude Tag가 iOS, Android, 데스크톱, 웹, CLI, Agent SDK 전반에 걸쳐 여러 개의 데일리 루틴(daily routine)을 돌린다:

포스트 2/4 원문

Crash fuzzer(크래시 퍼저): 시뮬레이터에서 앱을 열고 여기저기 탭하면서 크래시를 일으키는 방법을 찾아낸 다음, 근본 원인을 파악해 크래시를 고친다
Dup unifier(중복 통합기): 코드베이스에서 비슷하지만 미묘하게 갈라진 추상화들을 스캔해서, 이를 하나로 통일하는 PR을 올린다
Dead-code remover(데드 코드 제거기): 정적으로 도달 불가능한 코드를 제거하고, 데드 코드로 의심되는 코드에는 로깅을 추가해 정말 죽은 코드인지 확인한 뒤, 맞으면 다음 날 제거한다
Abstraction police(추상화 경찰): 새는 추상화(leaky abstraction)를 고친다
그 외 여러 가지..

Claude가 돌리는 유지보수 루틴 표: Crash fuzzer, Ant-only shipper, Logic simplifier, Logic bugfixer, Dup unifier, Dead-code removal, Useless-test pruner, Shipped-feature inliner, Flaky-test fixer, Abstraction improver, Abstraction police — **이미지 1 — 루틴(Routine) | 하는 일(What it does) 표:**

**Crash fuzzer**: 실제 앱에서 크래시를 찾아 근본원인 수정 PR을 연다

**Ant-only shipper**: 잊힌 사내 전용(internal-only) 기능을 사용량 기반으로 출시하거나 삭제한다

**Logic simplifier**: 뒤엉킨 비즈니스 로직을 단순화한다

**Logic bugfixer**: 까다로운 로직을 모델링해 버그를 찾아 고친다

**Dup unifier**: 중복 구현을 하나로 합친다

**Dead-code removal**: 증명 가능하게 도달 불가능한 코드를 지운다

**Useless-test pruner**: 실패할 수 없는 테스트를 지운다

**Shipped-feature inliner**: 완전 출시된 기능의 플래그를 제거한다

**Flaky-test fixer**: 불안정한(flaky) CI 테스트의 근본원인을 잡는다

**Abstraction improver**: 과잉 설계된 추상화를 평탄화한다

**Abstraction police**: 레이어링 위반을 고친다

포스트 3/4 원문

결과는 놀랄 만큼 긍정적이었다. 지난 몇 주 동안 이 루틴들이 우리 레포들에 걸쳐 388개의 PR을 열었고, 그중 180개를 Claude Code Review + 사람 리뷰를 거쳐 머지했다. 지금은 이런 기계적인(mechanical) 변경들의 머지를 더 쉽게 만들기 위해 이 과정을 어떻게 간소화할지 고민하고 있다.

Claude는 대체로 이런 PR을 첫 시도에 제대로 만들어내고, 그렇지 못하면 다음 날 더 잘하도록 Claude에게 자기 루틴을 튜닝하라고 시킨다. 며칠간의 튜닝이 필요할 때도 있다.

포스트 4/4 원문

비슷한 워크플로우를 시도해 보려면 Claude Code나 Tag에게 요청하거나, claude.ai/code…에서 직접 루틴을 만들면 된다. 실제로 내가 사용한 프롬프트 몇 개를 아래에 첨부한다.

비슷한 워크플로우를 실험해 본 사람 있는가?

**이미지 2 — Boris가 Slack에서 실제로 입력한 루틴 생성 프롬프트 4개 (7월 19일):**

**boris, 7월 19일 12:30 PM** — "iOS, Android, 데스크톱 앱을 e2e로 크래시 퍼징(crash fuzzing)하는 새 데일리 루틴들을 시작하자. 각 앱마다 루틴을 만들되, 워크플로우를 써서 실제 앱을 (목(mock) 없이) 구동하고 퍼징해서 크래시를 유발한 다음, 그 크래시들에 대한 수정 PR을 올려라. 모든 PR은 반드시 /verify를 실행하고 재현(repro)과 진리표(truth table)를 PR에 게시해야 한다. 업데이트는 이 채널의 새 최상위 Fuzzer 스레드에 게시하라"
(원문: "lets start new daily routines for crash fuzzing ios, android, and desktop apps e2e. make routines for each that use workflows to run the real apps (no mocks) and fuzz them to trigger crashes, then put up fix prs for those crashes. each pr must run /verify and post a repro and truth table to the pr. post updates in a new top level Fuzzer thread in this channel")

**boris** — "business-logic-bugfixer-daily와 business-logic-simplifier-daily, 그리고 dup-unifier도 만들어라. 같은 방식이다 — 앱별로 별도 루틴, 업데이트를 올리는 최상위 스레드, 항상 진리표와 함께 e2e로 검증. 이 모든 루틴에서, 갭과 중복을 찾아내고 모든 엣지 케이스가 잘 테스트되도록 로직을 형식적으로(formally) 모델링하는 것도 잊지 마라"
(원문: "also make business-logic-bugfixer-daily and business-logic-simplifier-daily and dup-unifier. same story -- separate routine per app, top level thread with updates, always verify e2e with truth table. for all of these, remember to formally model the logic also to spot gaps and duplication and to make sure all edge cases are well tested")

**boris** — "불안정한(flaky) 테스트의 근본 원인을 찾아 고치는 것과 쓸모없는 테스트를 지우는 것에 대해서도 똑같이 해라"
(원문: "also do this for finding and fixing root causes of flaky tests, and deleting useless tests")

**boris, 7월 19일 12:43 PM** — "데드 코드 제거(dead code removal)용 루틴도 하나 만들어라"
(원문: "also do one for dead code removal")

runninwithit (2시간 전): "그리고 그렇게 하는 데 Claude 모델 비용이 하루에 겨우 $1000밖에 안 든다!"
(원문: "And it only costs $1000 / day to use Claude models to do so!")

haifengkao (2시간 전): "토큰을 무제한으로 주면 나도 그거 할 수 있다"
(원문: "I can do that if you give me unlimited tokens")

boris_cherny (1시간 전, 저자): "개인한테는 아마 수지가 안 맞겠지만, 여러 앱을 만드는 회사 입장에서는 정말 유용했다"
(원문: "This probably doesn't make sense for individuals, but for a company building a bunch of apps it's been really useful")

jason.ycw (47분 전): "그 회사에 무제한 토큰 예산이 있을 때만 그렇겠지"
(원문: "Only if that company has unlimited token budget")