토큰 사용량 37.91%를 감소시킨 단 한줄의 프롬프트
(modgo.org)요약
- 코드 구조(전략·팩토리 패턴, 파일 분리, .cursorrules 정리)를 한 줄 프롬프트로 리팩터링한 뒤, 동일한 기능 추가 프롬프트를 실행했더니 AI 토큰 사용량이 크게 감소했다는 실험 보고(Zero-context, N=5). 실험에 쓴 프롬프트·소스가 공개되어 재현 가능.
핵심 데이터
-
Claude-4 Sonnet: 평균 390,159 → 242,265 tokens (−37.91%)
-
GPT-5: 평균 315,839 → 233,634 tokens (−26.03%)
-
기준: Cursor가 표기한 Total Tokens. 모델 간 절대치 비교는 의미 없음(모델별 집계 차이).
세팅(요약)
-
IDE Cursor 1.6.6, 모델 GPT-5 / Claude-4 Sonnet
-
모든 프롬프트 Zero-context, 매 라운드 에디터 완전 재시작
-
성공 판정: 단일 프롬프트로 요구사항 구현 시 성공으로 집계
왜 중요한가
-
“좋은 코드 구조”는 사람이 읽기 좋을 뿐 아니라 AI의 토큰·비용·시간에도 영향을 준다는 정량 근거
-
프롬프트·리포지토리 공개로 재현성 확보 (실무 적용·후속 실험에 바로 활용 가능)
개인 평
- Cursor 사용자로서, 비용 절약에 핵심 방법론을 제공하는 훌륭한 방법론을 제안 합니다.
- 본문에도 나와 있지만, 충분치 못한 샘플링이 다소 아쉽습니다.
저도 너무 이 소개글과 원문이 너무 장황하고 글을 잘 못 쓰는 사람이 쓴것처럼 느껴져서 읽는과정이 어려웠는데요,
요지는
"토큰을 줄이는 구조적 제약을 담은 한 줄 지시를 추가하라"
정도로 할수있겠네요
이 글은 '실험' 연구에 가까운 성격인 관계로,
이 글에 포함된 모든 수치는, 이 글을 읽는 모든 사람들이 '재연'을 할 수 있게 하는데 집중이 되어 있습니다.
이에, 사용된 원본 소스 코드와, 테스트에 사용 된 모든 절차를 모두 기록하여,
모든 실험자가 동일한 결과를 얻을 수 있도록 정보를 제공하는데 내용이 집중 되어 있습니다.
댓글들의 분위기를 보고 느끼건데,
이후로는 3줄 요약 성향의 글 하나와,
디테일을 알고자 하는 사람을 위한 글을 분리하여 두개로 작성을 해야할까 생각도 듭니다.
이 글의 어느 부분이 과하게 복잡하게 느껴졌는지, 그리고 장황한지 내용을 알려주시면,
이후 글 작성 하는데 큰 도움이 될 것 같습니다.
저도 비슷하게 느껴졌습니다.
글쓰신분 의도는 뭔지 알겠으나 하신것 대비 글이 과도하게 복잡한 것 같습니다.
최대한 실험에 사용된 디테일을 글에 녹이고 싶어 이렇게 작성하신것 같은데
핵심만 간략하게 추리셔도 이런 주제에 관심있는 분들이라면 아마 이해하실 것 같습니다.
과감하게 디테일은 쳐내고 핵심만 간추리신다면 더 낫지 않을까 싶습니다.
저는 글쓴분 의도나 결과 자체는 재밌다고 느꼈습니다.
더 좋은 소스코드가 더 적은 토큰 소모로 이어진다는게 주요 논지인것이고
그에 관련된 실험 설계를 하시고 수행을 하신 것 같습니다.
실험에 대해 제가 이해한 부분만 나열한다면
- AI에게 질의할 소스코드, 그 소스 코드를 프롬프트로 전처리(?) 한 소스코드 2개를 준비
- GPT5, Sonnet에 각각 5회씩 두 소스코드를 실행시키고 토큰 소모량을 비교
인것 같네요.
그리고 제가 이해한 바가 맞다면 프롬프트로 전처리 한 소스코드가 대체적으로 토큰 소모량이 적다는 결론인 것 같습니다.
재밌는 결론이긴 하나, 실험에 대한 제 의견은 다음과 같습니다.
-
공평한 비교가 아님
수치상으로는 낮아진 것으로 보이나 소스코드를 처리하기 위한 전체 토큰 숫자로 비교하는게 맞을 것 같습니다.
다시말해 전처리하기 위해 사용된 토큰 숫자 역시 고려되어야 할 듯 합니다.
전처리하기 위해 사용된 토큰숫자가 과도하게 크다면 사실상 토큰을 더 많이 소모해 무의미한것이 되고, 적다고 해도 실제 토큰 소모량 차이는 글보다 현저하게 적을 듯 싶습니다. -
전처리 전후 소스코드를 비교할 필요 있음.
전처리에 사용된 토큰을 제외한다면 질의시 토큰 소모량은 유의미하게 감소된 듯 보입니다.
다만 소스코드의 정확히 어떤 차이로 인해 이러한 차이가 나오는지 분석한다면 좀 더 글의 의미가 커질 것 같습니다.
그러한 차이를 극대화 하기위한 전처리 프롬프트 최적화가 가능하단 소리니까요.
글쓴분은 코드 구조 리팩터링이 이러한 결과를 불러왔다고 말씀하시나 저는 동의하지는 않고 아직 알 수 없다고 생각합니다.
AI에게 리팩터링 말고 다른부분을 개선시켰을때도 토큰소모량 감소가 있을 수 있을테니까요. -
좀 더 다양한 실험 필요
현재 코드 말고 다른 코드베이스에서도 동일한 실험을 돌려봐야한다고 생각합니다.
이게 일관적으로 좋게 나오는것인지 아닌지에 대한 판단을 해야하니까요.
다만 현실적으로 이건 테스트가 힘들 수 있다는 것은 이해하므로 그냥 참고만 하시는게 좋을 것 같습니다.
- 좀 더 다양한 실험 필요
전적으로 동의 합니다. 이런 형태의 비판은 크게 환영합니다.
세상은 혼자 살아가지 않고, 개개인의 능력 혹은 상황이 다릅니다.
저 또한 일개 개발자에 불과하며, 개인 비용을 들여 모든 테스트를 수행 할 수 없습니다.
이 글이 씨앗이 되어 많은 이들에게 좋은 영향, 그리고 이어지는 많은 연구에 시발점이 되었으면 하는 바램입니다.
- 전처리 전후 소스코드를 비교할 필요 있음.
서브타이틀이 내용과 맞지는 않네요. 재정리를 하면 '토큰 감소를 일으키는 더 명확한 요소 분석이 필요하다' 가 서브타이틀로 어울려 보입니다.
이 내용은 동의 되는 부분이 많습니다. 다만, 본 글의 성격에는 '이 글을 보는 사람들에게 현실적인 적용 방법을 제안한다'는 요소를 담고 있습니다.
이미, 이 글에 달린 댓글들만 보더라도 분위기를 알 수 있는데요, 저도 최근에 알게 된 사실이지만, AI 사용자 중에는 비개발자 바이브코더분들도 많은 것으로 추정이 되고 있습니다.
AI를 통하지 않은 저자가 직접 조정한 코드로부터 대단한 결과를 만들게 될 경우,
이는 저자가 개발실력을 자랑하는, AI 능력을 폄하하는 결과로 비추어지기 쉽습니다.
이에, 여느 바이브코더들이 활용 할 수 있는 '프롬프트'라는 요소로서 그 결과를 누구나 체감 할 수 있는 예제를 다루게 되었습니다.
이 연구에 이어, AI 토큰 사용량에 영향을 주는 요소들이 세분화 될 수 있는 연구가 이어지면 좋을 것 같습니다.
- 공평한 비교와 관련하여
- 바이브 코딩은 1번의 프롬프트로 출력물이 완성되지 않습니다.
1회의 구조수정을 통하여 n회의 프롬프트의 토큰 소모율을 낮추는 효과를 가져오게 될 경우, 토큰 감소량은 동일하게 수행 될 n회에 걸쳐 반영 됩니다.
n은 프로젝트의 목적과 기능 수, 그리고 이를 위한 코드의 양과 복잡성에 의해 결정되는 수치이며,
또한 최근 cursor / claude code agent들은 무한 반복 수행 혹은 AI의 무분별한 토큰 사용 문제를 해결하기 위해 수행 단위를 작게 가져가는 업데이트들이 일어나고 있는 관계로,
프로젝트 복잡도와 관련한 n 수치 연구는 별도로 이루어 지는것이 옳다 생각합니다.
- 최대한의 이해를 돕기 위하여, 별도의 주문이 없을 시 AI가 작성하는 구조적 문제가 있는 코드로부터 코드 개선의 예를 들었습니다.
이 부분에서 놓치지 말아야 하는 부분은, 구조의 개선은 절대적으로 코드의 개발과 독립적으로 일어나는 행위가 아니라는 점입니다.
최초의 프롬프트, 혹은 AI ruleset(.cursorrules)와 같은 제약을 통하여 base context로서 영향을 줄 수 있는 부분이며,
프로젝트 개발 사이클 도중 1회의 구조개선이 만사형통을 이루어 낼 수 없습니다.
즉, 일정 주기로 코드개선을 계획하기 보단 base context 로서 올바른 구조 유도가 더 좋은 방향입니다.
또한, base context로서 구조 유도 주문 규칙이 있는 경우와 없는 경우에 대한 연구는 별도로 이루어 지는것이 옳다 보입니다.
1번 항목에 대하여 정리하면,
- base context로서 구조 유도 주문 규칙이 있을 때 전체 토큰 사용량이 감소 할 가능성도 있으며,
- n회의 프롬프트 명령을 통한 최종 출력물 획득 변수가 있으므로,
1회의 구조 개선 프롬프트 명령의 토큰 사용량을 가산 하여 계산해야 한다는 주장은 어폐가 있습니다.
댓글로 말씀하시는게 무엇인지 잘 이해는 못하겠습니다. 저는 두 방법을 공평히 비교하려면 소모되는 총 토큰 숫자를 비교해야하지 않냐는게 제 코멘트 였습니다. 리팩토링 역시 토큰을 소모하지 않나요?
추가로 답변주신건 글에 적혀있지도 않고 실험 역시 진행되지 않은 내용인것 같습니다. 1회 질의당 토큰 비교가 아니라 여러번 질의시 리팩토링 오버헤드는 낮아지며 각 질의당 기대 토큰 숫자 줄기 때문에 총 토큰 숫자에서 이득이 날거란 말이신 것 같습니다. 이는 여러번 질의시 작성자분 생각대로 코스트다운이 유지될때나 말씀인거같은데 매우 이상적인 상황을 상정할 때 할 수 있는 이야기인듯 합니다. 리팩토링에 의한 코스트 다운이 그 다음 질의 숫자와 무관하게 유지될 거란 보장은 할수도 없고 실험없이 가정할 수도 없습니다. 의도된 말씀을 주장하시려면 1회 이상의 질의에 대한 코스트 다운을 실험으로 보여주시면 될 것 같습니다. 하지만 실험은 1회만 하시고 비교하신게 아닌가요?
덧붙여 그냥 제 가정일 뿐이지만 동일 목표(이상적인 최종 출력물)를 위해 질의를 무한히 반복해 나간다면 이상적인 상황에서 리팩토링 유무에 상관없이 코드는 동일한 형태로 수렴해 나가야 할 듯 합니다. (이상적인 최종 출력물은 유일)
이게 합리적인 가정이라면 질의가 반복될수록 리팩토링 유무의 차이가 적어지므로 토큰 코스트다운 이득이 점차 낮아질 것 같구요. 해서 거시적으로 생각했을때 이 코스트 다운에 대한 이득이 충분히 지속되지 않는다면 질의에 사용되는 총 토큰 숫자 차이는 유의미 하지 않을 수도 있지 않을까요
그리고, 프롬프트 연계 횟수 실험 와 관련한 내용도 문의 해 주셨는데요,
사실 이는 역으로 저자가 속된말로 사기를 치기에 좋은 요소입니다.
개발이라는 행위 자체가 진행하는 방향에 매우 많은 선택지들이 존재하고, 토큰 사용량이 더 크게 벌어지는 방향으로 프롬프트를 누적해버리면, 저 수치는 눈덩이마냥 더 크게 불어나 버릴겁니다.
연구에는 'Cumulative Science' 라는 철학이 있습니다.
아직 1회 명령에 대한 토큰 사용량 관련 연구를 적어도 제 기준에서는 한번도 찾은적이 없기에,
즉시 N회 연구를 하는것이 아닌, 확실한 1회에 대한 테스트와 결론을 다루는데 집중 한 것이고,
N회 연구는 이 실험에 이어 연구가 이어지면 되겠죠.
또한, 다른 글로서, 코드베이스의 차이에 따른 AI의 동작 차이를 다룬적이 있습니다.
(이 또한 이 GeekNews에 소개 된 적이 있구요 : https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
짧게 설명하면, AI에게 입력되는 코드 베이스에 따라 출력물의 품질이 달라진다는 테스트와 결과를 다루고 있습니다.
초기 코드베이스의 품질 및 방향성에 따라, 이어지는 코드 품질이 유지가 될 수도, 계속하여 나빠질 수 있다는 의미입니다.
즉, 프로젝트 초기 단계에서의 리팩토링 비용과, 한참 진행 된 프로젝트의 리팩토링 비용이 크게 다를 수 있다는 뜻입니다.
만약 질문자 분께서 개발자라면, '돛단배 위의 항공모함' 이라는 말을 한번쯤 들어봤을 수도 있을 것 같은데요,
리팩토링은 어느 시점에 수행 되어야 할 지, 혹은 프로젝트 초기 발라지는 사상 및 설계에 따라 비용이 어마어마하게 달라지는 심오한 주제 입니다.
이를 변수로 포함하여 결론을 불안정하게 가져가는것보다,
'아, 코드베이스 품질이 좋으면 토큰사용량이 줄어드는구나' 만큼은 확실하게 설명 가능 한 테스트를 진행 한 것이구요.
다시 설명 드려 보겠습니다.
바이브코딩 수행자는 비개발자부터 숙련된 개발자까지 그 범위가 넓습니다. 그들이 보유한 지식 상태에 따라, 이 글 내용과 전혀 무관하게 출력물의 품질은 천차만별입니다.
누군가는 자연스레 cursor 사용 전제 하 .cursorrules에 기본 OOP 규약과 클래스/메서드 분리 규칙을 담아 리팩토링이 거의 필요하지 않은 형태로 운용이 될 수도 있지만,
누군가로부터는 너무나도 기본적인 주요 내용 파악 부재로 인한 저수준 코드 양산이 일어나고 있을 수 있습니다.
심지어는, 기본적으로 프로젝트 룰 설정을 통해 코드 품질을 좋게 유지하라는 글과 경험들은 앞서 예시가 많습니다.
- 파일 크기를 작게 유지하라 : https://medium.com/realworld-ai-use-cases/…
- 코드베이스 실행 속도를 빠르게 유지하는 방법 : https://forum.cursor.com/t/…
- 윈드서프 모범 사례 및 가이드 라인 : https://gist.github.com/muratkeremozcan/…
이는 누군가는 명시적 리팩토링 없이도 토큰 사용량 측면에서 이익을 보고 있을 수 있다는 가능성을 시사 합니다.
단, 위 케이스들은, 해당 룰 정의를 통해 실행 단위 당 명확한 토큰 사용량 감소를 정리하고 있지는 않습니다. 이에 이 글을 통해 코드베이스 품질에 따른 토큰 사용량 차이를 테스트하고 그 결과를 정리 한 것이구요.
즉, 사용자에 따라, 명시적 리팩토링 횟수는 그 자체가 다시금 0~n회로 변수가 되며,
이 글의 본질적 의도는, '왜 좋은 품질의 코드 베이스를 신경 쓰는것이 좋은가?' 를 설명하고 있다고 보면 좋을 것 같습니다.
이 글에 많은 관심 가져주심에 감사 드립니다. 아무래도 해외 배포 목적이 크다보니 영문으로 글이 작성되었는데, 이로인해 이런저런 문제들이 발생 되는듯 합니다.
이에 한글로 정리한 포스트를 공유 드립니다.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
추가로 사용된 프롬프트와 관련된 내용 정리 드립니다.
아무래도 개발자 분들이 구조 개선용 프롬프트 작성에 유리합니다. 프로그램마다 성질이 다르므로, 효율 높은 개선을 위해서는 개발 지식이 어느정도 필요합니다.
그렇다고 비개발자 바이브코더분들이 이 방법을 사용 할 수 없다는 의미는 아닙니다. 효율에 차이는 있겠으나, "프로젝트 코드 정리좀 해줘. 사용하지 않는 코드들은 제거해." 와 같은 단순한 명령을 통해서도 AI가 파일 및 클래스를 분리하고 정리하는 행동을 합니다.
단, 구조 개선 디테일의 차이가 효율의 차이는 만들어 낼 수 있는 부분은 자료 참고에 주의가 필요합니다.
프롬프트에 핵심만 논리적으로 달아야 한다. 즉 프롬프트에 이것저것 많이 달수록 노이즈가 많아져 결과로 나오는 코드도 복잡해지고 노이즈가 많아진다 이건가요?
AI에게 코드 구조 리팩토링을 지시한 이후에 소모되는 토큰량이 줄어들었다는 내용이 핵심입니다.
반대로는, 코드 구조적 결함이 있는 상태에서 명령을 이어가면 토큰 사용량이 늘어난다 라고 설명 할 수도 있을 것 같습니다.
정리하면, 소스코드의 구조 개선이 일어나야 한다는 내용이며, 프롬프트를 핵심만 논리적으로 담아야 한다는 의미는 아닙니다.
Refactor the falling objects’ behaviors to use the Strategy pattern and their creation to use the Factory pattern, split the implementation into separate files, and update .cursorrules to reflect the new file structure.
이 프롬프트를 같이 넣었더니 비용이 줄어들었다는 건가요? 제가 요지를 맞게 이해한건지 잘 모르겠네요
참고로, 입력되는 소스 크기가 작아질수록 소모되는 토큰량이 줄어든다는것은 잘 알려진 명백한 사실 입니다. .cursorignore 파일이 이것때문에 만들어졌으니까요.
대체적으로 AI에게 구조 개선을 시키면, 거의 대부분 소스 코드 량이 감소되는 경향이 있어서, 어떤 이유에서든 정리를 시키면 비용이 줄어든다는 말은 신빙성 있는 주장 같습니다.
이 글은 좋은 구조 유도를 통해 추가적인 토큰 사용량 감소를 이루어 낼 수 있다는 주장이 더해진것이구요.
맞습니다. 본문에도 나와 있지만, 코드 개선 이후 프로젝트 코드 크기가 줄어든것은 사실입니다.
다만, 이 예제에서 캐릭터 개수 기준 약 10% 정도의 감소가 일어났는데, 이것만으로 토큰 사용량 감소 37.91%를 설명 할 수는 없습니다.
본문에 소스 저장소 링크가 있으며 어느 누구든 재연하여 테스트 해볼 수 있습니다.
첨언 드리자면, 코드의 구조는 해당 프로젝트에 맞는 모형으로 구조 개선이 일아나야 합니다. 아래 답변에 있는 내용처럼, AI에게 구조 개선을 질의 하면 해당 프로젝트에 맞는 적절한 구조 개선 방법을 알려줍니다.
개인적인 추천 방식은, AI에게 바로 구조 개선 명령을 넣지 말고, 제안 해보라 시키면 응답을 주는데, 대화를 하며 충분히 효율적인 제안까지 도달 후 적용 해 달라는 형태로 흐름을 가져가시면 좋습니다.
부가적인 팁 하나는, 가급적 컨텍스트 서머리제이션 (문맥 버퍼 초기화)가 일어나기 전 작업을 완료하는것이 좋고, 문맥 버퍼 초기화가 불가피한 경우, 사전에 .cursorrules 에 개선 규칙 추가해 달라 해주는것이 좋습니다. 작업중에 문맥 초기화가 일어나면 AI가 실수 할 가능성이 높아집니다.
제가 직접 이렇게 테스트를 해보지는 않았지만,
'현재 코드를 분석하고, 네가 관리하기 좋은 형태로 구조 개선을 해줘'
라는 프롬프트도 동작 하지 않을까 싶습니다.
정확한 요지는, AI에게 기능 요구사항만 전달 할 것이 아니라, 적절하고 올바른 구조를 잘 유도하는것이 비용 절감에 도움이 될 수 있다 라는 뜻으로 생각 됩니다.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
이 딥락갤 모드 직접 만드신 건가요?
이것도 바이브 코딩으로 하셨을까요?
안녕하세요. 블로그 주인입니다.
딥락갤 모드 직접 제작 한 것이 맞고, 현재 개인 서버 통해 서비스중에 있습니다. (치지직 OAuth 인증 때문에 필요합니다)
해당 모드는 언리얼 엔진을 통한 개발이 포함 되는데, 아쉽게도 언리얼 엔진쪽은 바이브 코딩이 어렵습니다.
대신, 모드 개발 방법 자체가 어렵지는 않기 때문에, 관심 이 있으시면 모드 개발 가이드 (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/) 통해 쉽게 배우실 수 있습니다.
다른 커뮤니티에서 모드 올리신 걸 봤는데, 정말 그 모드를 만든 분이 쓴 글이 맞았군요
블루프린트 모드 강좌 글까지 쓰셨을 줄은 몰랐는데 감사합니다.
원래도 개발을 잘 하는 분이셨네요!