Amazon Bedrock 청구서가 갑자기 뛰었는데 아무도 어떤 기능 때문인지 말할 수 없다면, 그것은 가격 문제가 아니다. 관측 가능성 문제다. 인보이스는 계정이 토큰에 더 많은 돈을 썼다는 사실만 알려준다. 어떤 에이전트, 어떤 테넌트, 어떤 코드 경로가 그 돈을 썼는지는 알려주지 않으며, 그 귀속 정보가 없으면 비용에 관한 모든 대화는 추측일 뿐이다. 측정할 수 없는 것은 최적화할 수 없는데, 대부분의 팀은 합계만 측정하고 그 아래는 아무것도 측정하지 않는다.

토큰 지출에는 이를 일반적인 클라우드 비용보다 더 까다롭게 만드는 특성이 있다. 비결정적 시스템에 의해 생성된다는 점이다. 프롬프트 변경, 재시도 루프, 수다스러운 에이전트, 혹은 모델을 더 열심히 생각하게 만드는 방법을 찾아낸 사용자, 이 모두가 청구서를 움직일 수 있지만 그 어느 것도 인보이스에 새로운 리소스로 나타나지 않는다. 지출은 단일 Bedrock 항목 안에 숨어 있다. 여러분의 일은 그것이 예상치 못한 방식으로 나타나기 전에 그 항목을 뜯어보는 것이지, 그 이후가 아니다.

귀속이 전부다

중요한 질문은 절대 "Bedrock에 얼마를 썼는가"가 아니다. "이것이 얼마를 썼고, 그럴 가치가 있었는가"이다. 이 질문에 답하려면 모든 단위의 토큰 지출에 차원이 필요하다. 최소한 각 호출에 다음을 태깅해야 한다.

  • 기능 또는 제품 영역, 요약기와 채팅 어시스턴트 중 어느 쪽이 비용 동인인지 물을 수 있도록.
  • 테넌트 또는 고객, 한 계정이 나머지에 의해 보조되고 있는지, 요금제가 서비스 제공 비용을 충당하는지 볼 수 있도록.
  • 에이전트 또는 워크플로, 다단계 파이프라인의 비용이 하나의 불투명한 합계가 아니라 단계별로 보이도록.
  • 모델, 더 저렴한 모델로도 처리할 수 있었던 비싼 트래픽이 프론티어 모델로 흘러가고 있을 때 알 수 있도록.

이런 차원이 없으면 비용 최적화는 모두를 일괄 제한하거나 기능을 꺼서 어떤 불만이 들어오는지 지켜보는 식의 뭉뚱그린 조치로 전락한다. 이런 차원이 있으면 어느 경로가 커졌는지 정확히 짚고, 그 성장이 값어치를 했는지 판단할 수 있다.

두 계층의 계측

인보이스를 위한 비용 할당 태그

AWS 비용 할당 태그는 거친 계층이다. Bedrock 사용을 유발하는 리소스와 요청에 태그를 붙여서 청구 데이터 자체가 여러분의 차원을 담게 하고, 비용 보고서가 하나의 미분화된 Bedrock 수치를 보여주는 대신 기능이나 환경별로 그룹화할 수 있게 하라. 이것이 재무 담당자와 플랫폼 소유자가 사는 뷰다. 월 단위로 세분화되어 있어서 "돈이 어디로 가고 있는가" 대화에는 적합하지만, 순간적인 급증을 잡아내는 데는 적합하지 않다.

실시간 파악을 위한 CloudWatch 지표

인보이스는 후행 지표다. 선행 지표는 토큰 처리량이며, 이는 CloudWatch에 속한다. Bedrock은 사용량 지표를 방출하며, 애플리케이션에서 직접 에이전트별, 테넌트별, 기능별로 차원이 지정된 커스텀 지표를 게시할 수 있다.

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

이제 지출은 알람을 걸 수 있는 그래프가 된다. 하룻밤 사이에 세 배로 뛴 에이전트별 토큰 지표는 월말의 재무 질문 대신 화요일에 경보를 울린다. 입력과 출력을 따로 읽어라. 출력이 더 비싸게 가격 매겨져 있어서 폭주하는 생성은 거기에서 가장 먼저 드러나기 때문이다.

가시성이 가능하게 하는 것

모든 토큰이 귀속되고 나면 최적화는 더 이상 뭉툭하지 않게 된다. 에이전트별 지표가 드러내는 저렴하고 기계적인 호출을 더 작은 모델로 라우팅하고, 그럴 만한 가치가 있는 추론에는 프론티어 모델을 남겨 둘 수 있다. 서비스 제공 비용이 요금제를 초과하는 테넌트를 찾아내 가격이나 사용량을 고칠 수 있다. 프롬프트 변경이 유발한 재시도 루프를, 요청 수는 그대로인데 토큰 수만 급증한 것으로 잡아낼 수 있다. 이 모든 조치는 청구서의 어느 조각을 잘라내야 하는지 아는 것을 필요로 하며, 그것이 바로 계측이 주는 것이고 원시 인보이스는 절대 주지 못하는 것이다.

결론

분해할 수 없는 Bedrock 청구서는 관리할 수 없는 청구서다. 토큰 지출을 단순한 인보이스 항목이 아니라 텔레메트리로 취급하라. 청구 뷰를 위해 비용 할당 태그를 붙이고, 실시간 뷰를 위해 에이전트별, 테넌트별 토큰 지표를 CloudWatch로 보내고, 급증이 사후 부검이 아니라 페이지 알림이 되도록 선행 지표에 알람을 걸어라. LLM 비용을 통제 아래에 두는 팀은 가격을 가장 잘 협상한 팀이 아니다. 언제든 정확히 어떤 기능, 테넌트, 에이전트가 돈을 쓰고 있는지 볼 수 있는 팀이다.

다음으로 읽을 글

LLM을 넘어선 FinOps 및 클라우드 비용 가시성 플레이북은 ercan.cloud의 클라우드 필드 노트에서, 허브는 ercanermis.com에서 확인할 수 있다.