리팩터링이 만드는 경제적 이점

에이전트가 작성한 17,155줄 규모의 Rust 데이터 접근 계층을 단계적으로 리팩터링하자, 같은 기능 변경에 필요한 입력 토큰이 159,564개에서 27,360개로 83% 감소함 전체 코드량은 거의 그대로였지만 관련 코드를 응집도 높은 파일로 분리하면서, 에이전트가 변경에 필요한 최소 파일 집합만 읽을 수 있게 됨 입력 토큰은 가장 큰 파일이 충분히 작아지기 전까지 크게 줄지 않았으며, 최종적으로 데이터 계층을 19개 Rust 파일로 나누고 최대 파일 크기를 17,155줄에서 3,695줄로 줄임 출력 토큰과 기능 구현량은 거의 변하지 않았고 Claude도 적절한 리팩터링을 스스로 선택하거나 안정적으로 수행하지 못해, 계획과 실행에 사람의 적극적인 지침이 필요했음 Sonnet 5의 입력 가격 $3/MTok 기준으로 변경 1회당 절감액은 약 $0.397에 불과하지만, 이후 데이터 접근 계층을 수정할 때마다 비용이 반복적으로 줄어들 가능성을 확인함 에이전트가 만든 17,155줄짜리 파일 업무 지원용 애플리케이션은 동적 갱신·조회가 가능한 웹 UI, 모달과 자동 저장, 외부 시스템 연동, 머신러닝과 텍스트 분석, 백그라운드 작업, 자동 배포 환경을 갖춤 전체 약 15만 줄 가운데 Rust가 약 12만 줄이고 나머지는 TypeScript와 Terraform이며, 대부분 Claude Code와 일부 Cursor를 이용해 에이전트가 작성함 개발자는 흥미로 가끔 살펴본 경우를 제외하면 코드를 읽거나 검토하지 않았음 데이터 접근 계층은 모든 읽기·쓰기 쿼리에서 같은 HTTP 요청 설정과 JSON 인코딩·디코딩을 반복하면서 6,000줄 이상으로 성장했고, 결국 하나의 Rust 파일이 17,155줄에 도달함 이 모듈에는 중복 제거와 내부 언어가 없고 함수 추출이 제한적이며 클래스 추출도 거의 없었지만, 보존할 인터페이스와 명확한 경계가 있어 리팩터링 실험에 적합했음 동일한 변경을 반복한 측정 방식 목표는 현재 리팩터링에 토큰을 투자해 향후 기능 변경의 토큰 소비를 낮출 수 있는지 확인하는 것이었음 에이전트는 이전 작업에서 학습하지 않으므로, 매 단계마다 새 하위 에이전트에게 정확히 같은 변경을 요청해 학습 효과가 섞이지 않도록 함 실험은 다음 순서로 진행함 엄격한 리팩터링 원칙에 따라 전체 계획을 작성함 하나의 프롬프트로 대표 변경을 정의함 하위 에이전트가 변경을 수행하고 토큰 소비량을 보고하게 해 기준값을 측정함 변경 결과를 ...