AWS, Bedrock 비용 관리 5단계 제시… 귀속·로그 이후 예산 통제와 최적화

AWS는 10월 30일 Amazon Bedrock 비용 관리를 위한 다섯 단계 운영법을 공개했다. 귀속, 관찰, 예산 집행, 기본 설정 최적화, 정기 운영이다. 11월 1일은 이 사이트의 기술호 날짜이며 원 발표일을 바꾸지 않는다. 이는 플랫폼과 FinOps 담당자에게 제시한 업체의 방법이지 이 사이트가 비용 절감을 실제 측정한 결과는 아니다. 에이전트 작업 한 건에는 여러 모델 호출과 커지는 문맥이 들어갈 수 있으므로 사용자 대화 횟수만으로 토큰 비용을 추정하면 틀리기 쉽다.

첫 단계는 지출의 책임자를 찾는 일이다. AWS에 따르면 Bedrock 추론 비용은 CUR 2.0의 `line_item_iam_principal` 열에서 호출한 IAM 주체에 귀속된다. 주체 데이터 내보내기를 켜고 팀·앱 태그를 붙여 비용 배분 태그로 활성화한 뒤 분석한다. Cost Explorer에 표시되는 데는 활성화 후 24~48시간이 걸릴 수 있다. 모두가 단일 게이트웨이 IAM 역할로 호출하면 비용이 그 역할에 모여 개인별 가시성이 사라진다. AWS는 사용자별로 역할을 맡고 세션 이름과 태그를 전달해 자격 정보를 잠시 재사용하는 방식을 제시한다. 알맞은 IAM 권한과 세션 설계가 필요하다.

둘째 단계는 요청 단위의 관찰이다. CUR은 누가 비용을 냈는지 보여 주지만 한 요청이 왜 토큰을 많이 썼는지는 설명하지 못한다. AWS는 모델 호출 로그를 설정하고 전달, 보존 기간, 암호화를 확인하라고 권한다. 로그는 CloudWatch Logs나 S3로 보낼 수 있다. 앱, 워크플로, 테넌트 같은 공통 metadata를 요청에 넣는 것도 중요하다. Bedrock은 앱이 metadata를 채우도록 강제하지 않으므로 공유 SDK나 게이트웨이에서 중앙 주입하고 누락률을 측정할 수 있다. 로그에는 민감한 요청 내용이 포함될 수 있어 별도 보호가 필요하다. CUR은 약 하루 늦지만 운영 로그는 더 빠른 추정치를 줄 수 있다.

셋째 단계의 예산 통제는 세 층이다. Tier 1은 AWS Budgets 경고로 호출을 막지 않는다. Tier 2는 사용량을 집계해 IAM 거부 규칙을 갱신하거나 다음 자격 정보 발급 때 막는다. 실제 제한은 가능하지만 비동기라서 정책은 초과 요청 뒤 수초에서 수분, 자격 정보 방식은 다음 갱신까지 늦을 수 있다. Tier 3은 추론 경로에 게이트웨이를 놓고 한도 초과 시 즉시 HTTP 429를 반환한다. 대신 배포, 확장, 보안 심사가 필요한 구성 요소가 늘어난다. Bedrock에 직접 연결하는 클라이언트는 경로를 바꾸지 않고 게이트웨이의 동기 차단을 얻을 수 없다.

넷째 단계는 모델 라우팅, 토큰 제한, 프롬프트 캐시의 기본값을 조정한다. 저렴한 모델로 보내기 전에 실제 업무의 품질을 시험해야 한다. 캐시는 안정된 공통 접두부를 다시 읽을 때 도움이 된다. AWS가 든 2026년 10월 미국 동부 일부 Claude 모델 예시에서는 5분 캐시 쓰기가 기본 입력 요율의 1.25배이고 읽기는 모델에 따라 0.1배 또는 0.05배다. 1시간 쓰기는 2배다. 이는 시기·리전·모델에 따라 바뀌는 예시이지 영구적인 전 세계 요금이 아니다. 다시 읽지 않는 캐시를 쓰면 오히려 비용이 늘 수 있다.

다섯째 단계는 모델 구성, 실패와 재시도, 캐시 읽기 비율, 완전한 metadata가 있는 요청 비율을 정기적으로 살피는 것이다. 클라이언트가 포기한 요청이 서비스 쪽에서 완료되고 재시도까지 이어지면 비용이 중복될 수 있다. AWS의 예시 점수표는 개발자 하루 지출을 100달러 미만, 100~300달러, 300달러 초과로 나누지만 보편적 의무 기준이 아니라 자체 데이터에 맞출 출발점이라고 한다. 토큰 단가만이 아니라 성공한 결과당 비용을 봐야 품질과 재시도를 함께 평가할 수 있다.

먼저 귀속과 로그를 갖춰야 초과의 원인과 최적화 효과를 알 수 있다는 것이 다섯 단계 순서의 근거다. 팀은 신원과 로그의 포괄성을 검증하고 허용 가능한 차단 지연에 따라 통제 층을 고른 뒤 모델 교체 전 품질을 측정해야 한다. 이 기사는 이 체계를 운영하거나 비용 절감 효과를 재현하지 않았다. 확인된 것은 AWS가 제시한 방법과 각 수단의 조건이다.

AWS의 별도 CloudTrail 문서는 감사에 필요한 조건을 분명히 한다. 추적과 이벤트 데이터 저장소는 기본적으로 데이터 이벤트를 기록하지 않으며 Event history에는 관리 이벤트만 표시된다. Bedrock 데이터 작업을 CloudTrail에서 확인하려면 해당 데이터 이벤트 선택기를 명시적으로 설정해야 한다. 모델 호출 로그는 별도로 활성화하는 자료이며 민감한 입력과 응답이 포함될 수 있다. 접근 기록, 요청 기록, 최종 청구와 애플리케이션 결과를 신뢰할 수 있는 요청 식별자로 연결하고 한 종류의 로그만으로 완전한 감사를 주장해서는 안 된다.