소프트웨어 리팩터링은 오랫동안 개발자 경험과 유지보수성 차원의 이야기로 다뤄져 왔다. 그런데 AI 코딩 에이전트가 코드 변경의 주체로 올라선 지금, 리팩터링은 모델 호출 1회당 과금되는 토큰 비용을 직접 좌우하는 경제 행위로 재정의된다. GeekNews가 소개한 Martin Fowler 사이트의 실험 데이터는 이 변화를 수치로 보여준다.
- 17,155줄 단일 Rust 파일을 응집도 높은 19개 모듈로 분할, 최대 파일 크기 3,695줄로 축소
- 기능 변경 1회당 입력 토큰이 159,564개에서 27,360개로 감소해 83% 절감 효과 확인
- Claude 모델은 리팩터링 시점을 자율적으로 선택하지 못해, 인간의 계획적 지침이 비용 안전망 역할을 하는 것으로 분석됨
LLM 친화적 아키텍처는 곧 비용 아키텍처이며, 파일 하나가 모델 호출 단가의 핵심 변수가 된다.
AI 에이전트 비용의 숨은 변수, 입력 토큰
출력 토큰보다 비싼 입력 토큰의 구조
대부분의 개발자는 AI 비용을 출력 토큰, 즉 모델이 생성한 텍스트 길이로 직관한다. 그러나 에이전트가 기존 코드를 읽고 수정 결정을 내리는 워크플로우에서 실제 비용의 대부분은 입력 토큰에서 발생한다. 본문에서는 Sonnet 4.5 기준 입력 단가가 일부 명시되어 있으며, 출력 단가보다 입력 단가가 더 비싼 구조가 토큰 경제의 방향을 결정한다.
컨텍스트 윈도우와 가격 곡선의 관계
컨텍스트 윈도우가 커질수록 모델은 더 많은 코드를 한 번에 읽을 수 있지만, 그만큼 한 번 호출당 과금되는 토큰도 비례해 증가한다. 동일한 기능을 변경하더라도 컨텍스트 구성이 바뀌면 같은 작업이 전혀 다른 비용으로 청구된다. 즉, 어떤 파일을 어떤 경계로 잘라 모델에 넘기느냐가 곧 비용 설계다.
17,155줄에서 19개 파일로, 리팩터링 실험 설계
실험 조건: 단일 Rust 데이터 접근 계층
실험 대상은 17,155줄짜리 단일 Rust 데이터 접근 계층이다. 이 파일은 도메인 모델, 매퍼, 쿼리 빌더, 캐시 어댑터가 한 모듈 안에 섞여 있었다. 리팩터링은 동일 동작을 유지하면서 응집도 높은 모듈로 가르는 작업으로 진행됐다.
측정 지표: 입력 토큰, 출력 토큰, 구현 기능량
평가는 단순한 라인 수 비교가 아니다. 동일한 기능 변경을 수행할 때 발생하는 입력 토큰 수와 출력 토큰 수, 그리고 실제 구현된 기능의 양을 함께 측정한다. 이렇게 해야 토큰이 줄면서 정작 기능까지 줄어드는 퇴행이 발생했는지를 구분할 수 있다.
파일 크기별 토큰 절감 곡선
아래 표는 실험 전후의 구조 변화를 요약한다.
| 지표 | 리팩터링 전 | 리팩터링 후 |
|---|---|---|
| 파일 수 | 1개 (단일 파일) | 19개 (모듈 분할) |
| 최대 파일 크기 | 17,155줄 | 3,695줄 |
| 기능 변경 1회당 입력 토큰 | 159,564개 | 27,360개 |
| 감소율 | – | 약 83% |
| 출력 토큰 및 구현 기능량 | 기준점 | 거의 동일 유지 |
83% 토큰 절감의 실체: 무엇이 줄고 무엇이 남았나
입력 토큰 159,564개에서 27,360개로의 변화
가장 큰 변화는 입력 토큰 수의 급감이다. 같은 기능을 변경하는 데 필요한 컨텍스트가 159,564개에서 27,360개로 줄었으며, 이는 약 83%의 감소율에 해당한다. 리팩터링 전에는 에이전트가 변경 지점과 무관한 코드까지 함께 읽어야 했지만, 리팩터링 후에는 관련 모듈만 선택적으로 로드해 동일한 결정을 내릴 수 있게 된 것으로 해석된다.
최대 파일 크기 3,695줄로 축소된 구조
19개 파일로 분할한 뒤에도 최대 파일 크기는 3,695줄에 그쳤다. 이는 무작위 분할이 아니라 도메인 경계를 따른 응집도 높은 분할이 적용됐음을 시사한다. 파일이 작아질수록 모델이 한 번에 처리해야 할 컨텍스트 밀도가 낮아지고, 결과적으로 변경에 필요한 토큰이 줄어드는 구조가 만들어진다.
출력 토큰과 구현 기능량은 왜 동결되는가
핵심은 입력이 줄어도 출력과 구현 기능량은 거의 변동이 없었다는 점이다. 이는 리팩터링이 모델의 작업 능력을 깎아내린 것이 아니라, 모델이 읽어야 할 범위만 정밀하게 축소했음을 보여준다. 즉, 효율 개선은 모델 성능이 아니라 입력 설계에서 발생했다.
Claude는 스스로 리팩터링하지 않는다, 인간 감독의 경제적 의미
리팩터링 트리거와 사람의 개입 지점
실험 과정에서 사용된 모델은 Claude이며, 리팩터링의 시작점은 인간이 명시한 계획적 지침이었다. 모델은 주어진 지침에 따라 파일을 분할했지만, 언제 리팩터링을 시작할지를 스스로 결정하지는 못한 것으로 보인다.
LLM이 적절한 리팩터링 시점을 선택하지 못하는 한계
에이전트는 현재 컨텍스트 안에서 작업을 수행하는 데는 강하지만, 전체 코드베이스의 구조적 부채를 평가해 선제적으로 모듈을 나누는 작업은 안정적으로 해내지 못하는 경향이 있다. 리팩터링은 본질적으로 변경하지 않아도 동작이 유지되는 작업이기 때문에 모델의 보상 신호와 정렬되기 어렵다.
계획적 지침이 만들어내는 비용 안전망
결과적으로 리팩터링은 자동화 대상이 아니라 인간이 트리거를 설계해야 하는 작업으로 남는다.인간이 설계하고 트리거하는 작업으로 남는다. 인간이 적절한 시점에 분할을 지시할 때만 83% 수준의 토큰 절감이 실현되며, 그렇지 않은 경우 컨텍스트 비대화에 따른 비용 폭증이 발생한다. 이는 인간 감독이 단순한 품질 관리가 아니라 비용 통제 장치임을 보여준다.
에이전트 시대의 코드베이스 설계 원칙
작은 파일과 높은 응집도 원칙
하나의 파일이 거대한 컨텍스트 덤프가 되는 구조는 에이전트 비용에서 가장 비싼 안티패턴이다. 반대로 책임이 작고 응집도가 높은 모듈은 에이전트가 필요한 파일만 골라 읽게 만들어 입력 토큰을 직접 줄인다.
도메인 경계를 따른 모듈 분할 권장
무작위 라인 수 기준 분할이 아니라, 도메인 경계와 책임 범위를 따라 모듈을 나누는 접근이 효과적이다. 실험에서도 17,155줄을 무작위로 쪼갠 것이 아니라 의미 단위로 분할했을 때 출력과 기능량이 유지된 것으로 보인다.
LLM 친화 아키텍처는 곧 비용 아키텍처
에이전트 시대의 아키텍처는 사람의 가독성만이 아니라 모델 호출 비용까지 설계 변수에 포함해야 한다. 파일 구조, 모듈 경계, 임포트 깊이 같은 전통적 설계 판단이 그대로 토큰 단가로 직결된다.
실무자 행동 체크리스트
- 단일 파일이 5,000줄을 넘으면 에이전트 호출 단가 상승 위험으로 보고 도메인 경계 기준 분할을 검토한다.
- 기능 변경 1회당 입력 토큰 수를 주기적으로 측정해 토큰 비용 회귀를 조기 탐지한다.
- 리팩터링 트리거는 모델이 아닌 사람이 가진 도구로 유지해 비용 안전망 역할을 보장한다.
- 모듈 분할 시 도메인 경계와 책임 범위를 우선 기준으로 삼아 기능 동등성을 보존한다.
- 출력 토큰과 구현 기능량을 동시에 추적해 입력 절감이 능력 저하로 이어지지 않는지 검증한다.