토큰 소모를 줄이기 위한 리팩터링 (Refactoring)
요약
AI 에이전트가 대규모 소프트웨어를 개발할 때 발생하는 설계 부채가 토큰 소모를 증가시키는 문제를 다룹니다. 리팩터링을 통해 코드의 경계를 명확히 하고 파일 크기를 줄임으로써, 에이전트가 작업 시 소비하는 컨텍스트 양을 획기적으로 줄일 수 있음을 실험으로 증명합니다.
핵심 포인트
- 리팩터링은 에이전트의 컨텍스트 회복을 돕고 토큰 비용을 절감함
- 거대한 파일은 에이전트가 무관한 컨텍스트를 읽게 만들어 효율을 저해함
- 단순한 코드 삭제보다 명확한 경계 설정과 책임 분리가 더 중요함
- 연속적인 변경이 예상되는 영역은 작업 전 리팩터링을 선행할 것
토큰 소모를 줄이기 위한 리팩터링 (Refactoring)
에이전트(Agent)가 대규모 소프트웨어를 작성할 때, 설계 부채(Design debt)는 사라지지 않습니다. 그것은 형태를 바꿀 뿐입니다. 코드를 이해하기 어렵게 만들 뿐만 아니라, 에이전트가 매 변경 사항마다 소비해야 하는 컨텍스트(Context)의 양을 증가시킵니다.
Giles Edwards-Alexander는 이를 생각하기에 특히 유용한 사례를 설명합니다. 그는 Claude Code와 Cursor를 사용하여, 생성된 코드를 체계적으로 검토하지 않고 약 15만 줄(주로 Rust 언어) 규모의 애플리케이션을 구축했습니다. 데이터 액세스 계층(Data access layer)은 결국 HTTP 요청 조립과 JSON 직렬화(Serialization)가 반복되는 17,155줄짜리 단일 파일에 집중되었습니다.
실험 가설: 지금 리팩터링(Refactoring)에 토큰을 투자하면, 다음 변경 사항을 구현하는 데 필요한 토큰을 줄일 수 있다.
측정 항목
저자는 대표적인 변경 사항을 정의하고, 리팩터링 단계 전후로 매 라운드마다 새로운 에이전트를 사용하여 실행했습니다. 이를 통해 에이전트가 진행 과정에서 코드에 대한 지식을 축적하는 것을 방지했습니다. 각 지점에서 코드 라인 수, 입력 및 출력 토큰(Input/Output tokens), 그리고 실행 시간을 기록했습니다.
가장 눈에 띄는 결과는 대량으로 코드를 삭제한 데서 온 것이 아니었습니다. 데이터 액세스 계층은 거의 동일한 크기인 16,608줄로 끝났습니다. 줄어든 것은 가장 큰 파일이었는데, 중복을 추출하고 책임을 더 작은 파일들로 분리한 후 17,155줄에서 3,695줄로 감소했습니다.
| 지표 | 결과 |
|---|---|
| 동일한 변경을 위한 입력 토큰 (Input tokens) | 159,564 → 27,360 |
| ... |
절단보다 메커니즘이 더 중요하다
파일을 임의로 나누는 것이 절약을 보장하지는 않습니다. 만약 분할이 하나의 책임을 너무 많은 곳으로 분산시킨다면, 에이전트는 여전히 그 모든 곳을 열고 가로질러야 합니다. 관찰된 이득은 두 가지 요소에 달려 있는 것으로 보입니다: 더 명확한 경계(Boundaries)와 각 변경 사항에 관련된 파일 세트의 축소입니다.
이러한 구분은 중요합니다. 아키텍처는 시스템을 탐색하는 인간의 어려움을 줄여줄 뿐만 아니라, 에이전트(Agent)의 컨텍스트 회복(Context Recovery)을 안내합니다. 실질적인 관점에서 리팩터링(Refactoring)은 변경 사항이 실제로 일어나야 할 위치를 더 쉽게 식별할 수 있게 함으로써 도움을 줍니다.
이것이 일상 업무에서 바꾸는 것
- 거대한 파일들을 신호로 활용하세요. 단순히 미적인 크기 규칙 때문이 아니라, 거대한 파일은 에이전트가 무관한 컨텍스트를 너무 많이 읽도록 강제하기 때문입니다.
- 일련의 변경 사항을 위임하기 전에 리팩터링하세요. 해당 영역이 계속해서 작업 대상이 된다면 초기 비용은 상쇄될 수 있습니다.
- 반복되는 변경 사항을 측정하세요. 대표적인 작업을 선택하여 변경 전후의 토큰(Tokens), 시간, 읽은 파일 수를 비교해 보세요.
- 아키텍처적 자율성을 기대하지 마세요. 보고서에 따르면, 에이전트들은 여러 리팩터링을 선택하고 적용하는 과정 모두에서 인간의 지침이 필요했습니다.
결론에 대한 한계점
이것은 아직 그린필드(Greenfield) 상태이며 한 명에 의해 유지 관리되는 애플리케이션을 대상으로 한 단일 실험입니다. 또한 도구가 신뢰할 수 있는 실시간 측정을 제공하지 않았기 때문에 토큰 계산은 문자를 기반으로 근사치를 낸 것입니다. 그리고 리팩터링 자체에 드는 총비용은 분리되어 계산되지 않았습니다. 저자는 전체 계획 및 실행 작업에 대해 약 500만 토큰의 상한선을 추정할 뿐입니다.
이러한 유보 사항에도 불구하고, 이 실험은 구체적인 논제를 제시합니다: AI 보조 개발에서 좋은 리팩터링은 단순히 미래의 유지보수를 위한 도박이 아닙니다. 그것은 바로 다음 작업에서 에이전트가 제대로 작동하기 위해 로드해야 하는 컨텍스트를 줄여줄 수 있습니다.
출처: Giles Edwards-Alexander의 “The Economic Benefit of Refactoring”을 바탕으로 한 각색 및 논평 (MartinFowler.com, 2026년 7월 30일 게시)
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기