에이전트가 읽는 코드도 리팩터링하면 토큰 비용이 83% 줄어든다

실험 배경

• Martin Fowler가 에이전트 기반 개발 환경에서 리팩터링의 경제적 이득을 직접 실험함

  • 대상 앱은 약 15만 줄 규모고, Rust가 약 12만 줄, 나머지는 TypeScript와 Terraform임
  • 고품질 웹 UI, 동적 갱신, 모달, 자동 저장, 외부 시스템 연동, 머신러닝과 텍스트 분석, 백그라운드 잡, 자동 배포까지 있는 앱이라고 함
  • 코드는 거의 전부 Claude Code와 Cursor가 작성했고, 저자는 가끔 흥미로 볼 때 말고는 읽거나 리뷰하지 않았음

• 문제는 데이터 접근 계층이 단일 Rust 파일 1만7155줄까지 커졌다는 점임

  • 같은 HTTP 요청 설정, JSON 인코딩과 디코딩, 읽기와 쓰기 패턴이 계속 반복됨
  • 내부 언어도 없고, 함수 추출이나 중복 제거도 거의 없었다고 함
  • 그래도 외부 인터페이스 경계는 명확해서 리팩터링 대상으로는 좋았음

실험 설계

• 목표는 “지금 리팩터링에 토큰을 쓰면, 앞으로 기능 변경에 드는 토큰이 줄어드는가”를 보는 것임

  • 인간 개발자는 반복 작업을 하며 학습하므로 실험이 오염될 수 있음
  • 반대로 에이전트는 매번 새 세션으로 시작하면 이전 시도에서 배우지 않기 때문에 같은 변경을 반복 측정하기 좋다고 봄

• 절차는 꽤 엄격했음

  • 전체 리팩터링 계획을 만들고, 대표 기능 변경 프롬프트를 하나 정함
  • 기준 상태에서 새 하위 에이전트에게 같은 변경을 시키고 토큰 사용량을 기록함
  • 변경은 버리고, 리팩터링 한 단계를 적용한 뒤 다시 같은 변경을 새 에이전트에게 시킴
  • 각 단계마다 입력 토큰, 출력 토큰, 걸린 시간, 코드 줄 수를 기록함

• 대표 변경은 Firestore 계층에 ItemWatchStore 비동기 trait을 추가하는 작업이었음

  • watch_item, unwatch_item, watched_items_for_user 세 메서드를 추가해야 했음
  • 실제 FirestoreStore와 인메모리 FakeStore 양쪽에 구현해야 했음
  • item_watches 컬렉션에 itemId, userId, createdAt 필드를 쓰는 조건도 포함됨

결과

• 최종 결과는 꽤 세게 나옴. 같은 변경의 입력 토큰이 83% 줄었음
  • 기준 입력 토큰은 159,564개
  • 최종 리팩터링 뒤 입력 토큰은 27,360개
  • 절감량은 132,204토큰이고, 비율로는 83%임
  • Sonnet 5 가격을 100만 토큰당 3달러로 계산하면 한 변경당 약 39.7센트 절약이라고 함

• 가장 큰 단일 파일 크기가 줄어들 때 입력 토큰도 본격적으로 떨어짐

  • 시작점에서는 데이터 접근 계층 전체가 1만7155줄짜리 단일 파일이었음
  • 최종 단계에서는 데이터 접근 계층이 19개 Rust 파일로 나뉨
  • 가장 큰 단일 파일은 1만7155줄에서 3695줄로 줄었음
  • 마지막 단계에서 입력 토큰이 104,080개에서 27,360개로 거의 절벽처럼 떨어졌다고 함

• 출력 토큰은 크게 줄지 않았음

  • 코드를 실제로 작성하는 출력 토큰 수는 대체로 비슷하게 움직임
  • 즉 리팩터링이 대표 변경 자체를 더 작게 만든 건 아니었음
  • 이번 실험에서 절약된 건 주로 “읽어야 하는 코드”였음

sequenceDiagram
    participant 개발자
    participant 리팩터링된코드
    participant 하위에이전트
    participant 토큰측정
    개발자->>리팩터링된코드: 한 단계 리팩터링 적용
    개발자->>하위에이전트: 같은 기능 변경 프롬프트 전달
    하위에이전트->>리팩터링된코드: 필요한 파일 탐색 및 읽기
    하위에이전트->>리팩터링된코드: ItemWatchStore 변경 작성
    하위에이전트->>토큰측정: 읽은 문자 수와 응답 문자 수 보고
    개발자->>리팩터링된코드: 변경 폐기 후 다음 단계 진행

무엇이 효과를 만들었나

• 단순히 파일을 랜덤하게 쪼갠다고 같은 효과가 나는 건 아니라고 함

  • 파일이 작아져도 관련 코드를 찾기 위해 여러 파일을 뒤져야 하면 토큰 절약이 약해질 수 있음
  • 이번에는 중복을 먼저 추출하고, 공통 구조가 보인 뒤 의미 있는 모듈 경계로 나눈 게 중요했음
  • FirestoreClient 추출, query helper, value constructor, FieldsBuilder, traits 분리, codec 분리, FakeStore 분리, store 하위 모듈 분리 같은 단계가 이어짐

• 에이전트는 리팩터링을 스스로 잘하지 못했다고 평가함

  • 명시적인 리팩터링 프롬프트와 사람이 만든 계획에 직접 반응해서 작업했을 뿐임
  • 저자의 개발 harness에 리팩터링 단계가 있었지만, Claude가 알아서 이 거대한 파일을 개선하지는 못했음
  • Claude.ai가 Claude Code보다 리팩터링 계획을 더 잘 잡았다는 관찰도 있음

• 적용 과정도 매끈하지 않았음

  • 실제 기계적 리팩터링은 Python 스크립트와 grep, sed로 수행됐는데, 들여쓰기 때문에 자주 꼬였다고 함
  • 가장 가치 있는 분리 단계가 첫 패스에서 빠져서 나중에 다시 지시해야 했음
  • 전체 실험은 약 8시간 걸렸고, 대부분은 방치형으로 돌아갔음

의미

• 이 실험은 AI 코딩 시대에 리팩터링의 경제적 의미가 바뀐다는 걸 보여줌

  • 예전 리팩터링은 주로 사람이 읽고 바꾸기 쉬운 구조를 만드는 일이었음
  • 이제는 에이전트가 관련 파일만 정확히 읽게 만들어 토큰 비용과 실행 시간을 줄이는 일도 됨
  • 한 번의 변경에서 39.7센트 절약은 작아 보여도, 디버깅과 반복 기능 개발 전체에 곱해지면 무시하기 어려움

• 다만 실험 한 번으로 일반화하긴 이르다고 저자도 말함

  • 리팩터링 자체에 든 토큰을 정확히 세지 못했고, 상한은 500만 토큰 정도로 추정함
  • 더 복잡한 변경, 더 넓은 코드베이스, 지속적 리팩터링, 리팩터링 방식별 효율 비교가 후속 과제로 남음

기술 맥락

• 이 글의 중요한 선택은 리팩터링 효과를 감으로 말하지 않고, 같은 변경을 반복 실행해서 토큰 비용으로 잰 거예요. 에이전트 코딩에서는 비용 단위가 시간뿐 아니라 입력 토큰이기 때문에, 구조 개선의 경제성이 더 직접적으로 드러나요.

• 단일 1만7000줄 파일을 나누는 이유는 “큰 파일은 못생겼다”가 아니에요. 에이전트가 변경 지점을 찾으려면 파일을 많이 읽어야 하고, 그 읽기 비용이 매번 반복되기 때문이에요.

• 여기서 중요한 건 파일 개수보다 경계예요. query, codec, fake store, trait, store 구현처럼 의미 있는 단위로 나눠야 에이전트가 필요한 부분만 고를 수 있어요. 그냥 줄 수만 맞춰 자르면 오히려 탐색 비용이 남아요.

• 인간의 역할도 분명해져요. 에이전트가 코드를 많이 만들 수는 있지만, 어떤 구조로 쪼개야 다음 변경이 싸지는지 판단하는 일은 아직 사람이 강하게 잡아줘야 해요.

• 이 실험은 DevOps 비용 관점으로도 볼 수 있어요. CI 시간이 줄어드는 리팩터링처럼, 에이전트 입력 토큰이 줄어드는 리팩터링도 앞으로는 아키텍처 의사결정의 한 축이 될 수 있어요.