AI 에이전트에게 코드를 작성하게 하는 시대가 되면서, 리팩터링 (Refactoring)의 가치를 측정하는 방법이 하나 늘었을지도 모른다. 가독성이나 유지보수성 같은 기존의 이유에 더해, "에이전트가 다음에 수정할 때 소비하는 토큰이 줄어든다"는 금액으로 나타낼 수 있는 효과다.

Thoughtworks의 CTO인 Giles Edwards-Alexander가 이 효과를 실험으로 수치화한 기사를 공개했다 (Martin Fowler의 사이트 내, The economic benefit of refactoring). 에이전트 개발을 일상적으로 진행하는 엔지니어나 테크 리드(Tech Lead)에게 리팩터링의 투자 대비 효과를 상사나 자신에게 설명할 자료로 사용할 수 있는 내용이다. 요약하자면, 15단계의 리팩터링을 거쳐 동일한 기능 추가에 소요되는 입력 토큰이 83% 감소했다는 이야기다.

저자는 15만 행 규모의 애플리케이션을 거의 전부 AI 에이전트(주로 Claude Code와 Cursor)로 구축했다. Web UI, 머신러닝 (Machine Learning), 백그라운드 잡 (Background Job), 자동 배포를 포함하는 구성으로, 그중 약 12만 행이 Rust이며 나머지는 TypeScript와 Terraform이다.

문제가 발생한 곳은 데이터 액세스 계층 (Data Access Layer)이었다. 기능을 추가할 때마다 에이전트가 코드를 덧붙여 써 내려가면서, 하나의 Rust 파일이 17,155행까지 팽창해 있었다. 동일한 HTTP 요청 조립, 동일한 JSON 인코딩/디코딩이 데이터베이스 조작이 일어날 때마다 반복해서 작성되고 있었다. 사람이 작성해도 일어날 수 있는 부패(Corruption)이지만, 에이전트는 "기존의 작성 방식에 따라 추가한다"는 특성 때문에 중복이 가속화되기 쉽다.

이 파일이 크면 무엇이 문제인가. 에이전트가 작은 기능 하나를 추가하기 위해서만 거대한 파일 1개를 통째로 읽어야 하는 상황이 발생한다. 읽는 양이 그대로 입력 토큰이 되어, API 비용과 실행 시간에 직접적인 영향을 미친다.

저자는 효과를 엄격하게 측정하기 위해 다음과 같은 절차를 구성했다. 먼저 Martin Fowler 방식의 리팩터링 계획을 세운다. 그다음 대표적인 기능 추가로서 "ItemWatchStore라는 trait를 3개의 메서드와 함께 추가한다"는 작업을 준비한다. 그리고 리팩터링을 한 단계 적용할 때마다 이 동일한 기능 추가를 처음부터 다시 시키며, 입력 토큰, 출력 토큰, 실행 시간, 행 수를 기록해 나간다.

여기서 교묘한 점은 매번 완전히 새로운 (fresh) 에이전트를 사용했다는 점이다. 동일한 에이전트에게 계속 시키면 "학습"하게 되어 두 번째 이후부터 유리해지기 때문에, 그러한 편향을 배제한 것이다. 토큰 수는 tiktoken을 사용하여 글자 수를 4로 나눈 근사치로 계산했다고 한다.

적용한 것은 Fowler의 패턴을 따른 꾸준한 분할 및 추출의 연속이다. 대략 다음과 같은 흐름으로 진행된다.

• HTTP 통신을 담당하는 FirestoreClient를 도메인의 쿼리 처리로부터 분리
• 반복해서 등장하는 헬퍼 함수 (도큐먼트 ID 추출 등)를 공통화
• 15회 이상 재사용되던 필터링 로직을 술어 (Predicate)로 집약
• 128회 이상 호출되던 JSON 생성 매크로를 함수로 교체
• 32개의 쿼리 상수를 queries.rs로, 17개의 trait 정의를 traits.rs로 이동
• trait를 도메인별 (계획, 콘텐츠, 사람, 시스템) 4개 파일로 분할
• 인코더/디코더를 codec.rs로, 테스트용 FakeStore를 fake_store.rs로 이동
• 거대한 FirestoreStore를 trait별로 10개 파일 (각 120~650행)로 분해
• 테스트를 소스 옆으로 재배치하고, 마지막으로 store/ 하위 디렉토리를 정리

요컨대, 하나의 거대한 덩어리를 의미 있는 단위로 나누어 가는 작업이다. 새로운 마법은 없으며, 교과서적인 리팩터링이다.

결과는 명확했다. 동일한 기능 추가에 소요되는 입력 토큰이 베이스라인인 159,564에서 최종적으로 27,360까지 떨어졌다. 차이값은 132,204 토큰이며, 비율로는 83%의 절감이다. 최대 파일 크기는 17,155행에서 3,695행으로 (약 78% 감소). 반면 데이터 계층 전체의 행 수는 17,155에서 16,608로 거의 유지되었다. 코드 총량을 줄인 것이 아니라 배치를 바꿨을 뿐인데 이러한 차이가 나타난 것이다.

Sonnet 5의 입력 가격(100만 토큰당 3달러)으로 환산하면, 1회 변경당 약 39.7센트의 절약이 된다. 금액 자체는 작지만, 데이터 액세스 계층 (Data Access Layer)을 건드리는 모든 미래의 변경 사항에 효과가 미친다는 점이 저자의 주장의 핵심이다.

흥미로운 점은 출력 토큰이 1,705에서 2,113으로 미세하게 증가(+24%)하여 거의 보합세를 유지했다는 점이다. 이는 리팩터링 (Refactoring)이 줄이는 것은 '읽기 복잡성 (Reading Complexity)'이지 '쓰기 복잡성 (Writing Complexity)'이 아니라는 시사점을 준다. 에이전트가 생성하는 코드량 자체는 정리하더라도 크게 변하지 않는다.

절감 효과가 가장 컸던 것은 파일을 분할하는 단계였으며, 단순히 함수를 추출하기만 했던 초기 단계에서는 효과가 크지 않았다. 에이전트가 '관련된 파일만을 더 작게 좁혀나갈 수 있게 되는 것'이 절약의 원천이며, 코드를 깨끗하게 만드는 것 자체가 직접적으로 작용하는 것은 아니라는 이해가 가능하다.

또 하나 현장에서 느끼는 중요한 점은, 저자가 "Claude는 리팩터링을 잘하지 못했다"라고 솔직하게 기술했다는 것이다. 에이전트가 어디를 어떻게 고쳐야 할지 자율적으로 찾아내지는 못하며, 인간의 명시적인 지시가 필요하다. 기계적인 적용도 정교하지 못해, sed나 grep 스크립트는 들여쓰기 (Indent) 처리에서 막히기도 했다. 가장 효과가 컸던 store의 분할은 처음에는 간과되었다가 나중에 다시 수행했다고 한다.

즉, 리팩터링의 판단과 설계는 여전히 인간의 영역이라는 의미이기도 하다. 실험 전체는 약 8시간(대부분 무인 상태로 방치)이 소요되었으며, 토큰 소비의 상한 추정치는 약 500만 토큰이다. 이 사전 준비 비용과 미래의 변경 사항을 통해 회수할 수 있는 절약분을 저울질하는 구도가 된다.

여기서부터는 개인적인 견해지만, 이 기사의 가치는 '83%'라는 숫자 그 자체보다 리팩터링의 효용을 객관적으로 측정하기 위한 실험 프레임을 제시했다는 점에 있다고 생각한다. 전후로 동일한 태스크를 새로운 (fresh) 에이전트에게 반복시켜 토큰을 측정하는 방식은 자신의 리포지토리 (Repository)에서도 모방할 수 있다. 기술 부채 (Technical Debt)를 '상환해야 한다'는 감정론으로 말하는 대신, '이 계층에 한 달에 몇 번의 변경이 들어오며, 1회당 몇 센트를 절약할 수 있는가'라는 언어로 말할 수 있게 된다.

다만 한계점 또한 저자 스스로 인정하고 있다. 이번 기능 추가는 작고 단순한 것이었기에, 대규모 구조 변경이나 더 복잡한 기능에서는 출력 토큰의 거동도 달라질 수 있다. 또한 단일 데이터 계층에서의 실험이기도 하다. 과도한 일반화는 금물이며, 어디까지나 탐색적인 첫걸음이라는 위치에 있다. 그럼에도 불구하고, AI 에이전트 시대에 '왜 리팩터링을 하는가'에 대한 답이 하나 더 늘어난 것은 분명할 것이다.

출처: Giles Edwards-Alexander 「The economic benefit of refactoring」(뉴스레터 『Leadership in Tech』에서 소개). 원문: https://martinfowler.com/articles/exploring-gen-ai/refactoring-economic-benefit.html