리팩터링하자 AI 코딩 입력 토큰이 83% 줄었어요

리팩터링하자 AI 코딩 입력 토큰이 83% 줄었어요

AI 뉴스 썸네일

AI 코딩 도구가 큰 파일을 통째로 읽어야 하면 작은 기능 하나를 고칠 때도 입력 토큰이 많이 들어가요. 17,155줄짜리 Rust 파일을 19개로 나눈 실험에서는 같은 변경에 필요한 입력 토큰이 159,564개에서 27,360개로 줄었어요. 코드 총량을 크게 줄이지 않아도 구조를 바꾸면 반복 비용을 낮출 수 있다는 사례예요. 1

핵심 요약

구분	핵심	왜 볼만한가요
측정 결과	입력 토큰이 159,564개에서 27,360개로 83% 줄었어요	AI 코딩 비용과 코드 구조의 관계를 실제 수치로 비교했어요
구조 변화	데이터 접근 계층을 19개 Rust 파일로 나눴어요	필요한 파일만 읽도록 경계를 만들었어요
한계	출력 토큰과 작업 시간은 뚜렷하게 줄지 않았어요	리팩터링이 모든 비용을 자동으로 낮추는 건 아니에요
운영 판단	사람의 계획과 단계별 지시가 필요했어요	AI 코딩 도구에 구조 개선을 맡겨 두는 것만으로는 부족했어요

1. 큰 파일을 나누자 읽어야 할 코드가 줄었어요

실험 대상은 약 15만 줄 규모의 업무용 애플리케이션이에요. Rust 코드가 약 12만 줄이었고, 데이터 접근 계층의 한 파일은 기능이 쌓이면서 17,155줄까지 커졌어요. HTTP 요청 설정과 JSON 변환 같은 코드가 여러 쿼리에서 반복됐고, 함수와 책임의 경계도 충분히 나뉘지 않았어요. 작성자는 이 파일을 단계적으로 정리한 뒤 매 단계에서 똑같은 기능 변경을 다시 시켜 입력량과 출력량, 실행 시간을 비교했어요. 2

최종 단계에서 데이터 접근 계층은 19개 Rust 파일로 나뉘었어요. 가장 큰 파일은 17,155줄에서 3,695줄로 작아졌고, 같은 변경의 입력 토큰은 159,564개에서 27,360개로 감소했어요. 절약한 입력은 132,204 토큰이에요. 전체 데이터 접근 계층의 코드양은 17,155줄에서 16,608줄로 소폭 줄었을 뿐이에요. 관련 코드의 응집도와 파일 경계가 입력 감소에 더 큰 영향을 줬어요.

728x90

토큰은 파일을 조금 나눴다고 바로 줄지 않았어요. 최대 파일이 15,670줄일 때 입력은 151,850 토큰이었고, 13,845줄일 때 132,558 토큰으로 내려갔어요. 최대 파일을 9,269줄로 줄인 단계에서는 104,080 토큰이 필요했어요. 마지막에 최대 파일이 3,695줄이 되자 입력이 27,360 토큰까지 크게 떨어졌어요. AI 코딩 도구가 변경에 필요한 최소 파일 집합만 찾을 수 있을 정도로 경계가 선명해져야 절감 폭도 커졌다는 설명이에요.

파일 수보다 책임 경계가 중요해요

큰 파일을 무작정 여러 조각으로 자르는 방식은 같은 결과를 보장하지 않아요. 관련 코드가 여러 파일에 흩어지면 AI 코딩 도구는 다시 많은 파일을 탐색해야 해요. 이번 실험에서는 중복 코드를 먼저 정리하고, 공통 구조를 드러낸 다음, 함께 바뀌는 코드를 가까운 파일로 묶었어요. 이 순서 덕분에 기능 하나를 수정할 때 확인할 범위가 작아졌어요.

개발팀에서 확인할 지점도 분명해요. 파일 줄 수만 세기보다 기능 변경 한 건이 몇 개 파일을 건드리는지 봐야 해요. 자주 함께 수정하는 코드가 멀리 떨어져 있거나, 하나의 파일이 여러 책임을 갖고 있다면 컨텍스트가 커져요. 모듈 경계와 인터페이스가 분명하면 사람의 탐색 시간뿐 아니라 AI 코딩 도구의 입력 비용도 줄일 수 있어요.

83%라는 숫자에는 조건이 붙어요

이번 토큰 수치는 공급사가 제공한 정확한 사용량이 아니에요. 도구가 보고한 송수신 문자 수를 바탕으로 tiktoken을 사용해 문자 4개당 토큰 1개로 근사했어요. 실험마다 새 작업 환경에서 같은 변경을 요청해 이전 작업의 영향을 줄였지만, 생성 결과에는 비결정성이 남아요. 따라서 83%를 모든 저장소에 그대로 적용할 평균값으로 보면 안 돼요.

출력 토큰은 1,705개에서 2,113개로 오히려 조금 늘었어요. 실행 시간도 342초에서 454초로 줄지 않았어요. 리팩터링은 기능 구현량 자체를 줄인 게 아니라, 기능을 만들기 전에 읽어야 할 코드 범위를 줄였어요. 작성 당시 Sonnet 5 입력 가격을 100만 토큰당 3달러로 계산하면 한 번의 변경에서 아낀 금액은 약 39.7센트였어요. 한 번의 절감액은 작지만 같은 영역을 자주 바꾸면 누적 효과를 따져볼 수 있어요.

AI가 구조 개선을 알아서 해 주지는 않았어요

코드를 작성한 도구는 17,155줄짜리 파일을 스스로 충분히 개선하지 못했어요. 리팩터링 계획도 사람이 비교하고 보완해야 했고, 실제 분리 작업에는 단계별 지시가 필요했어요. 가장 효과가 컸던 파일 분리도 첫 계획에서 빠져 후속 단계로 적용됐어요. AI 코딩 도구를 쓰더라도 모듈 경계, 중복 제거 순서, 보존할 인터페이스는 개발자가 결정해야 한다는 사례예요.

이 결과는 코드 리뷰를 생략해도 된다는 근거가 아니에요. 오히려 AI가 만든 코드가 빠르게 커질수록 사람이 구조를 점검할 시점을 정해야 해요. 큰 파일, 반복되는 전송 코드, 여러 책임이 섞인 모듈을 초기에 발견하면 이후 변경마다 불필요한 컨텍스트를 다시 읽는 일을 줄일 수 있어요.

왜 중요한가요

AI 코딩 비용은 모델 가격과 요청 횟수만으로 정해지지 않아요. 같은 기능을 바꿀 때 저장소에서 얼마나 많은 코드를 읽어야 하는지도 입력 비용에 직접 연결돼요. 이번 실험은 소프트웨어 설계가 유지보수성과 함께 토큰 소비에도 영향을 줄 수 있다는 측정 사례를 보여줘요. 2

팀에서는 리팩터링 효과를 코드 줄 수 감소만으로 평가하지 않아도 돼요. 대표적인 기능 변경을 정하고, 변경 전후에 읽은 파일 수와 입력 토큰, 실행 시간, 테스트 결과를 함께 비교해 볼 수 있어요. 다만 작은 코드베이스나 변경 빈도가 낮은 영역은 리팩터링 비용을 회수하기 어려울 수 있어요. 자주 수정하는 핵심 모듈부터 측정하면 투자 순서를 정하기 쉬워요.

참고 자료

1. 리팩터링이 만드는 경제적 이점 — GeekNews
2. The Economic Benefit of Refactoring — Martin Fowler