애플리케이션 추론 프로파일은 모델 ARN을 감싼 태그 달린 래퍼이며, 회사 전체를 하나의 숫자로 보여주는 Bedrock 청구서와 당신 사이를 가로막는 유일한 것이다. 모델을 가리키는 프로파일을 만들고, 비용 배분 태그를 붙인 다음, 모델 ID 대신 프로파일 ARN을 호출한다. 태그는 Cost Explorer와 Cost and Usage Report까지 함께 따라간다. 메커니즘은 이것이 전부이며, 반나절이면 끝난다.

반나절이 문제가 아니다. 문제는 태깅 체계가 조직적 약속이라는 점이고, 대부분의 팀은 10분 만에 하나를 정하고 2년을 그것과 함께 산다. 그래서 이 글에서 API는 20분어치이고 태그 설계가 나머지 전부다.

이것이 해결하는 문제

프로파일이 없으면 Bedrock 사용량은 그냥 Bedrock 사용량으로 나타난다. 모델별, 리전별 지출을 볼 수 있는데, 지난달 Claude Sonnet에 큰돈이 나갔다는 것은 알려줘도 아홉 개 애플리케이션 중 어느 것이 원인인지는 전혀 알려주지 않는다. 기본 리포트는 재무팀이 늘 묻는 유일한 질문, 즉 이것이 누구의 예산에서 나가는지에 답하지 못한다. 이 문제의 더 넓은 형태는 Your LLM Bill Is an Observability Problem에서 다뤘다. 프로파일은 귀속 문제 절반을 위한 구체적인 통제 수단이다.

작동 방식

파운데이션 모델이나 시스템이 정의한 크로스 리전 프로파일을 가리키는 프로파일을 태그와 함께 생성한다.

aws bedrock create-inference-profile \
  --inference-profile-name "support-assistant-prod" \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --tags key=team,value=support key=app,value=assistant key=env,value=prod

그런 다음 모델 ID를 넘기던 자리에 프로파일 ARN을 넘기면 된다.

response = client.converse(
    modelId="arn:aws:bedrock:eu-central-1:123456789012:application-inference-profile/abc123",
    messages=messages,
)

놓치기 쉬운 운영상의 세부사항 세 가지.

  • 프로파일은 모델별로 특정된다. 프로파일 하나는 모델 하나를 감싼다. 앱 여섯 개 곱하기 모델 네 개면 프로파일 스물네 개다. 이 곱셈이 바로 태그 설계가 보이는 것보다 훨씬 중요한 이유다. 당신은 리소스에 이름을 붙이는 것이 아니라 격자를 정의하는 것이다.
  • 태그는 소급 적용되지 않는다. 청구 콘솔에서 비용 배분 태그를 활성화하면 그 시점 이후의 지출부터 태그가 붙는다. 지난달에 한 일은 아무것도 라벨링되지 않는다. 데이터가 필요할 때가 아니라 필요해지기 전에 태그 키를 활성화하라.
  • 세분화 단위는 사용 유형별 일 단위다. 프로파일은 Cost Explorer와 CUR에서 일 단위로 청구된 금액을 알려준다. 요청 단위 비용은 알려주지 않는다. 요청 단위 경제성을 원한다면 그것은 애플리케이션 측의 토큰 로깅이며, 소유자가 다른 별개의 시스템이다.

태그 체계 설계하기

함정은 조치 가능한 것 대신 보기 쉬운 것에 태그를 다는 것이다. 모든 태그 키는 실제 회의에서 실제 사람이 던지는 질문에 답할 수 있어야 한다.

대부분의 조직에서는 네 개의 키로 충분하다.

  • team: 누가 지불하는가. 기존 비용 센터 분류 체계와 정확히 맞춰라. 재무팀이 cc-4471이라고 부른다면 platform-eng이라는 이름을 새로 만들지 마라. 아무도 신뢰하지 않는 변환표를 1년 내내 유지보수하게 될 것이다.
  • app: 어떤 워크로드인가. 실제로 끌 수 있는 단위.
  • env: prod, staging, dev. 이것이 가장 빨리 본전을 뽑는 키다. 대부분의 Bedrock 청구서에서 처음으로 정말 놀라게 되는 숫자가 dev 비용이 얼마나 큰지이기 때문이다.
  • feature: 선택 사항으로, 특정 기능 하나가 지출을 지배하는 앱에 사용한다. 아껴서 써라. 키를 하나 추가할 때마다 프로파일 개수가 곱으로 늘어난다.

의도적으로 목록에서 뺀 것: 사용자별 태그. 사용자마다 프로파일을 만들지 마라. 리소스 한도에 부딪힐 것이고, 유지보수는 끝이 없어진다. 아이덴티티 수준의 귀속이 필요하면, Bedrock은 IAM 프린시펄 기반 비용 배분을 지원한다. 이는 인당 프로파일 없이도 지출을 호출한 아이덴티티에 귀속시킨다. 팀과 앱 단위의 세분화에는 프로파일을 쓰고, 어떤 사람이나 서비스 역할이 급증을 유발했는지 알아야 할 때는 IAM 프린시펄 귀속을 써라. 둘은 함께 조합해서 쓸 수 있다.

구조적으로 만들어라

규율에 의존하는 태깅 체계는 무너진다. 두 가지 통제가 이것을 지탱해준다.

첫째, 프로파일을 IaC 안에, 그것을 사용하는 앱 바로 옆에 만들고, 태그 값은 해당 앱의 다른 리소스에 태그를 다는 것과 똑같은 변수에서 가져와라. 콘솔에서 손으로 만든 프로파일은 영원히 test라고 태그된 채로 남을 프로파일이다.

둘째, 우회 경로를 막아라. 프로파일이 존재하는데도 원시 모델 ID를 호출하는 앱은 태그 없는 지출을 만들어내는데, 태그 없는 지출은 정확히 아무도 자기 것이라고 주장하지 않는 항목이 된다. 파운데이션 모델 ARN에 대해서는 bedrock:InvokeModel과 bedrock:Converse를 거부하고 애플리케이션 추론 프로파일 ARN에 대해서만 허용하는 IAM 정책을 두면, 태그가 붙은 경로만 유일한 경로가 된다. 이것은 역할을 작업 범위로 한정하는 것과 같은 본능이다. IAM for LLM Apps: Least Privilege When the Caller Is a Model의 논증을 반복하지는 않겠지만, 이것이 폭발 반경뿐 아니라 청구서에도 똑같이 적용된다는 점만 짚어둔다.

이것은 첫날에 해두어라. 이미 모델 ID를 직접 호출하고 있는 여섯 개 앱에 나중에 거부 정책을 소급 적용하는 것은 변경 동결이 딸린 마이그레이션이 된다.

얻게 되는 것, 그래도 여전히 얻지 못하는 것

태그된 데이터가 한 달 쌓이면 Cost Explorer를 team으로 그룹화해 분배 현황을 볼 수 있고, env=dev로 필터링해서 누군가 켜둔 채 방치한 배치 작업을 찾을 수 있고, CUR을 조회해 앱별, 일별 비용을 요청량 옆에 대시보드로 띄울 수 있다. 이상 탐지도 유용해진다. 전체 Bedrock 지출에 대한 알림은 잡음이지만 앱 하나에 대한 예산 알림은 신호이기 때문이다.

여전히 얻지 못하는 것: 요청 단위 비용, 멀티테넌트 앱에서의 고객별 비용, 그리고 그 지출이 가치가 있었는지에 대한 판단. 첫 번째는 토큰 로깅의 영역이다. 두 번째는 청구 시스템이 절대 보지 못하는 테넌트 컨텍스트가 필요한데, 그래서 멀티테넌트 귀속은 계속 애플리케이션 차원의 문제로 남는다. 세 번째는 애초에 청구 문제가 아니다. 프로파일은 돈이 어디로 갔는지 알려준다. 그 돈이 그럴 만한 가치가 있었는지에 대해서는 아무 의견도 없다.

핵심 정리

애플리케이션 추론 프로파일은 모델 ARN을 감싸는 비용만으로 귀속 불가능한 Bedrock 청구서를 팀별, 앱별 항목으로 바꿔준다. 이력이 필요해지기 전에 태그 키를 활성화하고, 체계는 당신 조직이 실제로 예산을 편성하는 방식과 맞는 몇 개의 키로 유지하고, 프로파일은 IaC 안에서 만들고, 귀속이 누군가의 기억에 의존하지 않도록 IAM으로 태그 없는 경로를 막아라. API는 반나절이면 끝난다. 태그 설계는 그것을 선택한 사람보다 오래 살아남는다.

다음으로 읽을 글

이 글이 빌려온 더 일반적인 비용 배분 원칙, 즉 AWS 자산 전반의 태깅 전략은 ercan.cloud의 필드 노트에 있다. 허브는 ercanermis.com이다.