LLM 비용 줄이는 법: 간단 목업부터?
제목: Claude/LLM 쓸 때 “간단한 목업부터”가 진짜 비용을 줄여줄까?
“일단 **아주 간단한 mock(목업)**부터 해줘. 토큰 아끼게.”
LLM을 자주 쓰다 보면 이런 말을 습관처럼 하게 되는데요, 과연 이게 나만의 ‘토큰 짠돌이’ 습관일까요? 아니면 실제로 생산성을 높이는 꽤 합리적인 전략일까요?
1) 토큰이 아까운 순간은 “정답”이 아니라 “방향”을 못 잡을 때예요
요약부터 말하면, 토큰(모델 입력/출력 텍스트 단위)을 쓰는 게 아까운 지점은 모델이 틀려서라기보다 내가 뭘 원하는지 불명확한 상태에서 길게 왕복할 때예요.
처음부터 완성본을 요구하면 모델은 ‘그럴듯한 완성본’을 길게 뽑아내고, 사용자는 그걸 보고 “아 이건 아니고…”를 반복하게 됩니다.
이때 낭비되는 건 출력 토큰만이 아니라, 재지시를 위한 입력 토큰도 함께 늘어난다는 점이 핵심이에요.
그래서 “간단한 목업부터”라는 문장은 사실 요구사항을 먼저 좁히는 장치로 꽤 좋은 편입니다.
2) “아주 간단한 mock”은 비용 절감이라기보다 ‘리스크 관리’에 가까워요
간단 목업을 먼저 받는 방식은 단순히 토큰을 아끼는 행위라기보다, 큰 출력이 빗나갈 확률을 줄이는 전략이에요.
LLM은 긴 글을 만들수록 구조·톤·범위가 한 번에 굳어져 버리기 때문에, 초반에 방향이 틀어지면 이후 수정비용이 커져요.
반대로 5~10줄짜리 목업을 먼저 만들면, “이 방향 맞아/아냐”를 빠르게 확인하고 다음 단계로 넘어갈 수 있습니다.
특히 문서, 기획서, 코드 구조처럼 초기 설계가 중요한 작업일수록 이 방식이 유용해요.
3) 실제로 효과 좋은 사용 시나리오 3가지
목업 요청이 특히 빛나는 상황은 대체로 “큰 걸 만들기 전에 기준을 맞춰야 하는 작업”이에요. 아래처럼 써보면 체감이 큽니다.
- 블로그/문서 작성: “목차(섹션 제목) + 각 섹션 2문장 요약만”을 먼저 받으면, 이후 전체 글을 요청할 때 흔들림이 줄어요. 최종 출력 토큰도 ‘헛발’이 덜합니다.
- 코딩 작업: “전체 코드 말고 함수 시그니처/폴더 구조/데이터 흐름만” 먼저 받으면, 나중에 생기는 리팩터링 비용이 확 줄어요. 특히 API 설계에서 효과가 큽니다.
- 프롬프트 설계: “내 요구를 만족하는 프롬프트 초안만 5줄로” 부탁하고, 그걸 다듬어 최종 프롬프트로 키우면 반복 횟수가 줄어듭니다.
핵심은 완성품이 아니라 ‘검증 가능한 뼈대’를 먼저 얻는 거예요.
4) “간단하게”의 기준을 명확히 해야 진짜로 아껴져요
여기서 자주 실패하는 포인트가 “간단하게 해줘”가 너무 추상적이라는 거예요.
모델은 간단함을 짧게 이해할 수도, 내용은 풍부하게 유지한 채 표현만 줄이는 식으로 해석할 수도 있어요.
그래서 아래처럼 출력 형식 제한을 같이 걸면 더 잘 먹힙니다.
- “10줄 이내로”
- “불릿 6개만”
- “섹션은 4개 소제목만”
- “코드는 말고 **의사코드(pseudocode, 코드처럼 보이지만 실행 목적이 아닌 설계용)**로”
즉, ‘간단함’은 감각이 아니라 제약 조건으로 주는 게 좋아요.
5) 토큰 아끼려다 오히려 손해 보는 케이스도 있어요
반대로 목업 전략이 항상 이득인 건 아닙니다.
예를 들어, 당신이 원하는 산출물이 매우 명확하고(예: 특정 형식의 이메일, 이미 확정된 스펙의 코드), 수정 가능성이 낮다면 처음부터 완성본을 받는 게 더 빠르고 쌀 수 있어요.
또 “목업 → 확장 → 재확장”을 너무 잘게 쪼개면, 왕복 횟수가 늘면서 입력 토큰이 누적돼 생각보다 비용이 커질 수 있습니다.
따라서 “목업”은 남발하기보다, 방향 불확실성이 큰 작업에서만 쓰는 게 가장 효율적이에요.
마무리: “토큰 짠돌이”가 아니라, 좋은 작업 습관일 수 있어요
“간단한 mock부터”는 단순 절약이 아니라 초기 정렬(alignment)을 빠르게 끝내는 방법이에요.
특히 문서/기획/코드 설계처럼 초반 결정이 결과물 전체를 좌우하는 작업에서, 이 습관은 비용과 시간을 동시에 줄여줍니다.
오늘부터는 이렇게 한 번 써보세요:
“완성본 말고, 10줄 이내 목업 + 내가 확인할 체크포인트 3개만 줘.”
이 한 줄이 생각보다 많은 토큰과 시행착오를 줄여줄 거예요.
