무슨 이야기냐면요
요즘 코딩할 때 AI한테 도움 받는 분들 정말 많죠. ChatGPT, Claude, Copilot... 그런데 이런 LLM(Large Language Model, 사람 말을 이해하고 글이나 코드를 만들어내는 거대한 AI)을 API로 직접 불러서 쓰면 '토큰' 단위로 돈을 내거든요. 한 개발자가 실제로 자기 코드를 이런저런 스타일로 바꿔가며 LLM에 넣어봤는데, 똑같은 동작을 하는 코드인데도 스타일에 따라 토큰 수가 눈에 띄게 달라지더라는 거예요. 그게 곧 요금이고, 더 나아가 AI가 코드를 얼마나 잘 이해하는지에도 영향을 준다는 걸 발견한 거죠.
토큰이 대체 뭔데요
이게 뭐냐면요, LLM은 우리가 쓴 글을 통째로 읽는 게 아니라 잘게 쪼개서 읽어요. 이 쪼개진 조각 하나하나가 '토큰'이에요. 영어로 치면 보통 짧은 단어 하나나 긴 단어의 일부가 토큰 하나가 되거든요. 예를 들어 'tokenization' 같은 긴 단어는 'token' + 'ization'처럼 두세 조각으로 나뉘기도 해요. 한글은 더 잘게 쪼개지는 편이라 영어보다 토큰을 많이 먹어요.
코드도 똑같아요. getUserAccountBalance처럼 길고 친절한 변수 이름은 토큰을 여러 개 잡아먹지만, bal 같은 짧은 이름은 한두 개로 끝나죠. 들여쓰기에 쓰는 공백, 빈 줄, 주석, 중괄호 스타일까지 전부 토큰으로 환산돼요. 우리가 '사람이 읽기 좋으라고' 넣어둔 것들이 사실 AI한테는 전부 비용으로 잡히는 셈이에요.
그래서 얼마나 차이 나는데요
LLM 요금은 보통 '입력 토큰'과 '출력 토큰'을 따로 계산해요. 그런데 코드를 다룰 때는 입력이 정말 커지기 쉽거든요. 파일 하나만 넣는 게 아니라 관련 파일 여러 개, 에러 로그, 기존 코드 전체를 다 넣어주잖아요. 이때 코드가 장황하게 쓰여 있으면 같은 정보를 전달하는 데 토큰이 1.5배, 2배씩 더 들어요. 반복해서 호출하는 자동화 파이프라인이라면 이 차이가 매달 청구서에서 꽤 큰 숫자로 돌아오는 거죠.
그렇다고 무작정 코드를 압축(minify)하면 되느냐, 그건 또 아니에요. 여기서 재밌는 딜레마가 생기는데요. LLM은 사람이 짠 '읽기 좋은 코드'를 잔뜩 학습했거든요. 그래서 변수 이름이 의미를 담고 있고 구조가 깔끔하면 모델이 코드의 '의도'를 훨씬 잘 파악해요. 토큰 아끼겠다고 a, b, c로 다 줄여버리면 돈은 아껴도 AI가 엉뚱한 답을 내놓을 확률이 올라가요. 결국 '비용'과 '정확도' 사이에서 균형을 찾아야 하는 문제인 거예요.
업계에서는 어떤 흐름이냐면
사실 이 토큰 비용 문제는 LLM을 진지하게 제품에 붙이는 회사들에게는 핵심 고민이에요. 그래서 '프롬프트 캐싱(같은 내용을 반복해서 보낼 때 캐시해서 토큰값을 깎아주는 기능)'이나, 코드베이스에서 질문과 관련된 부분만 똑똑하게 골라 넣는 RAG(검색 기반 보강) 같은 기법이 빠르게 발전하고 있어요. 코드를 통째로 욱여넣는 시대에서, '필요한 만큼만 정제해서 넣는' 시대로 넘어가는 중이라고 보면 돼요.
한국 개발자에게는 어떤 의미일까요
혹시 사내에서 LLM API로 코드 리뷰 봇이나 문서 자동 생성기를 만들고 계신다면, 이건 그냥 '코딩 컨벤션' 문제가 아니라 '운영 비용' 문제가 돼요. 한번 측정해보세요. 자주 보내는 프롬프트 템플릿에서 불필요한 공백이나 장황한 예시를 걷어내는 것만으로도 토큰을 10~20% 줄이는 게 어렵지 않거든요. 다만 정확도가 떨어지지 않는 선까지만요. 또 OpenAI나 각 모델 제공사가 공개한 토크나이저(tiktoken 같은 도구)로 내 코드가 실제 몇 토큰인지 직접 찍어보는 습관을 들이면, 감으로 짐작하던 비용이 숫자로 보이기 시작해요.
한 줄 정리
사람이 읽기 좋은 코드와 AI가 읽기 좋은 코드, 그리고 지갑에 좋은 코드는 미묘하게 다르고, 그 균형점을 직접 측정해보는 게 LLM 시대 개발자의 새로운 감각이에요.
여러분은 LLM에 코드를 넣을 때 토큰 수를 의식해본 적 있으세요? 비용을 줄이려다 답변 품질이 떨어진 경험이 있다면 어떻게 균형을 맞추셨는지 궁금하네요.
🔗 출처: Hacker News