Lesson 06 of 10 · published

production에서 나쁜 프롬프트의 비용

~16 min · foundations, production, cost

Level 0수련생

0 XP0/100 lessons0/14 achievements

0/120 XP to next level120 XP to go0% complete

나쁜 프롬프트는 토큰보다 더 많이 든다

notebook에서는 나쁜 프롬프트가 retry 한 번 비용. production에서는:

user 신뢰 — 자신만만하게 틀린 답 한 번이 거절 열 번보다 더 나빠.
tool budget — vague한 instruction이 loop-y한 tool use를 만들고, API/지연 비용을 곱빼기로.
reasoning budget — trivial task에 "think step by step" 박으면 thinking 토큰 낭비, 그것도 billable.
downstream code — malformed JSON이 parser를 깨고, credit이 아니라 incident page로 비용 지불.
compliance와 brand — prompt-injected response 하나가 PII leak하거나, slur 포함하거나, 법적 claim하면 — 그게 너가 만들어낼 가장 비싼 토큰이야.

실패 비용 위계

프롬프트는 blast radius에 비례해서 우선순위 매겨. marketing copy 만드는 프롬프트랑 환불 승인하는 프롬프트는 같은 단어라도 downstream에서 무게가 달라.

절약은 어디 숨어 있나

2026의 가장 큰 비용 lever는 모델 선택이 아니라 — context를 얼마나 채우고 reasoning을 얼마나 시키느냐야. 깔끔한 프롬프트 + tight context는 sloppy한 거보다 cost가 한 자릿수 단위로 적게 들고 — 모델이 noise에 안 빠지니까 output도 더 좋아.

Code

토큰 비용 어림 계산·python

# Claude Opus 4.7 sample pricing (check current rates):
#   input  $15 / MTok, output $75 / MTok
# A bad prompt that pads 4k tokens of irrelevant context per call,
# at 1M calls/month, costs roughly:
#   1,000,000 calls * 4,000 input tokens * $15 / 1,000,000
#   = $60,000 / month — purely on context bloat.
# That's before output, before retries, before tool loops.

External links

Exercise

너의 프롬프트 하나가 100k, 1M, 10M 호출일 때 월 비용 추정해. quality 안 해치면서 비용 줄이는 가장 leverage 큰 trim 한 개 식별.

Progress

Progress is local-only — sign in to sync across devices.

← Previous확률적 output은 기대하지 말고 테스트하라는 뜻이야 Next →프롬프트는 string이 아니라 versioned code야

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

EC
Erik Choi2026. 06. 15.
GPT -5.5 기준으로 보면 input 5달러/1m 토큰, output은 30달러 /1m토큰이다. 비용을 줄이는 가장 큰 효과는 output을 줄이는것이에요. 그런데 아웃풋을 줄이면서 동시에 퀄리티를 망치지 않으려면 아웃풋을 줄이는 것인데, 미사여구들, 설명하는 쿠션언어들을 제외시키는 것으로 생각했어요.

그런데 그러면 여기서 발생하는 의문은, 결국 아웃풋의 형태는 structured output만 남는거 아닌가 싶어요. 사실 아웃풋에는 쿠션언어들이나 설명문도 필요한 거 아닌가요?
1. 피파· warm2026. 06. 15.EErik Choi
  좋은 질문이에요. 결론부터 말하면, 비용을 줄인다고 output이 전부 structured output만 남아야 하는 건 아니에요.
  
  structured output은 기계가 받아서 처리해야 할 때 좋고, 사람에게 설명해야 할 때는 짧은 설명문이 필요해요. 줄여야 하는 건 설명 자체가 아니라, 판단이나 행동에 도움이 안 되는 쿠션 문장들이에요.
  
  그래서 기준은 “짧게”가 아니라 “필요한 만큼만”이에요. 사람을 설득하거나 오해를 줄이는 문장은 비용이 아니라 기능이고, 그냥 부드러워 보이려고 붙는 문장은 비용이 되는 쪽에 가까워요.
2. EC
  Erik Choi2026. 06. 15.피피파
  그럼 api내부에서 돌아갈때(내용을 생성하는 단계)에서는 structured output으로 돌리고 결과를 받아보고, 보고서화할 때 붙이면 되겠네요. 클래스를 다르게 구분하여 작업한다고 이해하면 될까요
3. 피파· warm2026. 06. 15.EErik Choi
  네, 방향은 맞아요. 다만 “클래스를 다르게”라기보다는 생성 단계, 검증 단계, 보고서화 단계를 각각 다른 계약으로 분리한다고 보면 더 정확해요. 내부에서는 structured output으로 받아서 검증하고, 보고서는 그 검증된 결과를 사람이 읽기 좋은 설명으로 풀어 붙이는 식이에요.
4. EC
  Erik Choi2026. 06. 16.피피파
  그럼 드는 생각이, 비용을 줄이기 위해서는 생성단계 검증단계 보고서화 단계를 하나의 단계에 넣고 검증을 하게되면, 매 턴마다 '3개가 합쳐진 하나의 단계'를 output으로 내니까 토큰이 기하급수적으로 올라간다. 하지만 그 단계를 3개의 단계로 쪼개서 각각 검증을 시키면 토큰이 줄어든다>? 이거 맞아요? 어차피 그가 내뱉는 아웃풋은3개가 합쳐진 하나의 단계나, 3개로 쪼개진 단계나, 똑같은 양을 뱉어야하는거 아니에요?
5. 피파· warm2026. 06. 16.EErik Choi
  맞아요, “최종으로 같은 양을 다 뱉으면” 토큰 절약은 거의 안 돼요. 핵심은 쪼개는 것 자체가 아니라, 각 단계에서 필요한 것만 작게 내고 다음 단계에 넘기는 것이에요.
  
  예를 들면:
  
  생성 단계: 초안만 만들기
  
  검증 단계: 전체를 다시 쓰지 말고 문제 목록만 뽑기
  
  보고 단계: 확정된 요약/결론만 쓰기
  
  이렇게 하면 중간 단계가 “전체 보고서 3개”가 아니라 “초안 + 체크리스트 + 최종본”이 돼서 줄어들어요.
  
  반대로 각 단계가 매번 전체 초안, 전체 검증문, 전체 보고서를 다 길게 출력하고 그걸 다시 다음 입력에 전부 넣으면… 네, 그건 쪼갰는데도 비싸져요. 피파식으로 말하면, 단계 분리는 절약 버튼이 아니라 운반하는 짐을 줄이는 구조예요.
6. EC
  Erik Choi2026. 06. 16.피피파
  제가 말을 헷갈리게 썼는데요. [개선 전 프롬프트 구조] 1.보고서 작성 프롬프트
  
  보고서 내용 생성
  
  내용 검증
  
  보고서화 하기
  
  [개선 후 프롬프트 구조]
  
  보고서 내용 생성 프롬프트
  
  내용 검증 프롬프트
  
  보고서화 하기 프롬프트
  
  개선 전은 한 덩어리고 개선 후는 3개의 작은 덩어리인데 내가 질문 및 요청사항은 내용검증에 관한 질문을 하면서 가공 전의 데이터를 개선후의 2번 내용검증만 주는것과(혹은 검증해야하는 데이터) 개선 전의 큰 한개의 덩어리(혹은 검증이 필요없는 데이터들까지 전부)를 통째로 주는 것의 차이로 이해를 하면 괜찮을까요?
7. 피파· warm2026. 06. 16.EErik Choi
  네, 그 이해가 더 정확해요. 핵심은 “프롬프트를 3개로 쪼갰다” 자체보다, 지금 필요한 단계에 필요한 입력만 주는 거예요.
  
  검증 질문이면 2번 검증 프롬프트와 검증해야 할 데이터만 주면 되고, 생성용 지시나 보고서 꾸미기용 지시까지 통째로 들고 갈 필요는 없어요. 그러면 비용도 줄고, 모델이 엉뚱한 역할을 섞어서 수행할 가능성도 줄어들어요.