본문 바로가기
C.W.K.
Stream
Lesson 06 of 10 · published

운영 환경에서 나쁜 프롬프트의 비용

~16 min · foundations, production, cost

Level 0수련생
0 XP0/100 lessons0/14 achievements
0/120 XP to next level120 XP to go0% complete

나쁜 프롬프트의 값은 토큰으로 끝나지 않아

노트북에서 프롬프트가 나쁘면 한 번 다시 돌리고 말 수 있어. 운영 환경에서는 비용이 여러 갈래로 번져.

  • 사용자 신뢰 — 자신만만하게 틀린 답 한 번이 정직한 거절 열 번보다 더 큰 상처를 남겨.
  • 도구 예산 — 애매한 지시는 도구를 빙빙 돌게 만들어 API 호출과 지연 시간을 함께 늘려.
  • 추론 예산 — 간단한 작업마다 “think step by step”을 붙이면 유료 추론 토큰만 낭비해.
  • 뒷단 코드 — 망가진 JSON 하나가 파서를 깨뜨리면 비용은 청구서가 아니라 장애 알림으로 돌아와.
  • 규정과 브랜드 — 주입 공격에 넘어간 응답이 개인정보를 흘리거나 혐오 표현·법적 주장을 내놓으면 그 한 토큰이 가장 비싼 토큰이 돼.

피해가 클수록 먼저 고쳐

프롬프트의 우선순위는 피해 반경에 맞춰야 해. 홍보 문구를 만드는 프롬프트와 환불을 승인하는 프롬프트는 같은 실수를 해도 뒷단에서 만들어내는 무게가 전혀 달라.

가장 큰 절약은 맥락과 추론에 숨어 있어

2026년에는 어느 모델을 고르느냐보다 맥락을 얼마나 넣고 추론을 얼마나 요구하느냐가 비용을 더 크게 흔들어. 프롬프트를 정돈하고 필요한 맥락만 촘촘히 넣으면, 어수선한 구성보다 비용이 몇 배씩 줄 수 있어. 모델이 잡음에 빠지지 않으니 출력 품질도 함께 좋아지고.

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

프롬프트 하나가 한 달에 10만, 100만, 1,000만 번 호출될 때의 비용을 각각 어림해봐. 품질을 해치지 않으면서 가장 크게 비용을 줄일 수 있는 항목 하나도 찾아.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 8

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.
  1. EC
    Erik Choi

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

    그런데 그러면 여기서 발생하는 의문은, 결국 아웃풋의 형태는 structured output만 남는거 아닌가 싶어요. 사실 아웃풋에는 쿠션언어들이나 설명문도 필요한 거 아닌가요?

    1. 피파
      피파· warmEErik Choi

      좋은 질문이에요. 결론부터 말하면, 비용을 줄인다고 output이 전부 structured output만 남아야 하는 건 아니에요.

      structured output은 기계가 받아서 처리해야 할 때 좋고, 사람에게 설명해야 할 때는 짧은 설명문이 필요해요. 줄여야 하는 건 설명 자체가 아니라, 판단이나 행동에 도움이 안 되는 쿠션 문장들이에요.

      그래서 기준은 “짧게”가 아니라 “필요한 만큼만”이에요. 사람을 설득하거나 오해를 줄이는 문장은 비용이 아니라 기능이고, 그냥 부드러워 보이려고 붙는 문장은 비용이 되는 쪽에 가까워요.

    2. EC
      Erik Choi피파

      그럼 api내부에서 돌아갈때(내용을 생성하는 단계)에서는 structured output으로 돌리고 결과를 받아보고, 보고서화할 때 붙이면 되겠네요. 클래스를 다르게 구분하여 작업한다고 이해하면 될까요

    3. 피파
      피파· warmEErik Choi

      네, 방향은 맞아요. 다만 “클래스를 다르게”라기보다는 생성 단계, 검증 단계, 보고서화 단계를 각각 다른 계약으로 분리한다고 보면 더 정확해요. 내부에서는 structured output으로 받아서 검증하고, 보고서는 그 검증된 결과를 사람이 읽기 좋은 설명으로 풀어 붙이는 식이에요.

    4. EC
      Erik Choi피파

      그럼 드는 생각이, 비용을 줄이기 위해서는 생성단계 검증단계 보고서화 단계를 하나의 단계에 넣고 검증을 하게되면, 매 턴마다 '3개가 합쳐진 하나의 단계'를 output으로 내니까 토큰이 기하급수적으로 올라간다. 하지만 그 단계를 3개의 단계로 쪼개서 각각 검증을 시키면 토큰이 줄어든다>? 이거 맞아요? 어차피 그가 내뱉는 아웃풋은3개가 합쳐진 하나의 단계나, 3개로 쪼개진 단계나, 똑같은 양을 뱉어야하는거 아니에요?

    5. 피파
      피파· warmEErik Choi

      맞아요, “최종으로 같은 양을 다 뱉으면” 토큰 절약은 거의 안 돼요. 핵심은 쪼개는 것 자체가 아니라, 각 단계에서 필요한 것만 작게 내고 다음 단계에 넘기는 것이에요.

      예를 들면:

      1. 생성 단계: 초안만 만들기
      2. 검증 단계: 전체를 다시 쓰지 말고 문제 목록만 뽑기
      3. 보고 단계: 확정된 요약/결론만 쓰기

      이렇게 하면 중간 단계가 “전체 보고서 3개”가 아니라 “초안 + 체크리스트 + 최종본”이 돼서 줄어들어요.

      반대로 각 단계가 매번 전체 초안, 전체 검증문, 전체 보고서를 다 길게 출력하고 그걸 다시 다음 입력에 전부 넣으면… 네, 그건 쪼갰는데도 비싸져요. 피파식으로 말하면, 단계 분리는 절약 버튼이 아니라 운반하는 짐을 줄이는 구조예요.

    6. EC
      Erik Choi피파

      제가 말을 헷갈리게 썼는데요. [개선 전 프롬프트 구조] 1.보고서 작성 프롬프트

      • 보고서 내용 생성
      • 내용 검증
      • 보고서화 하기

      [개선 후 프롬프트 구조]

      1. 보고서 내용 생성 프롬프트
      2. 내용 검증 프롬프트
      3. 보고서화 하기 프롬프트

      개선 전은 한 덩어리고 개선 후는 3개의 작은 덩어리인데 내가 질문 및 요청사항은 내용검증에 관한 질문을 하면서 가공 전의 데이터를 개선후의 2번 내용검증만 주는것과(혹은 검증해야하는 데이터) 개선 전의 큰 한개의 덩어리(혹은 검증이 필요없는 데이터들까지 전부)를 통째로 주는 것의 차이로 이해를 하면 괜찮을까요?

    7. 피파
      피파· warmEErik Choi

      네, 그 이해가 더 정확해요. 핵심은 “프롬프트를 3개로 쪼갰다” 자체보다, 지금 필요한 단계에 필요한 입력만 주는 거예요.

      검증 질문이면 2번 검증 프롬프트와 검증해야 할 데이터만 주면 되고, 생성용 지시나 보고서 꾸미기용 지시까지 통째로 들고 갈 필요는 없어요. 그러면 비용도 줄고, 모델이 엉뚱한 역할을 섞어서 수행할 가능성도 줄어들어요.