Amazon Bedrock tokenomics data lake

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock 호출 로그를 중앙 데이터 레이크로 통합해 프롬프트·응답·토큰 사용량을 분석하고, CUR 2.0과 연결해 호출별 비용 가시성과 토크노믹스 운영 기반을 마련하는 AWS 구현 사례다.

📌 핵심 요약

• Amazon Bedrock의 모델 호출 로깅은 요청·응답을 Amazon S3 또는 Amazon CloudWatch에 기록하며, 이 솔루션은 계정별 로그를 중앙으로 모아 프롬프트, 응답, 입출력 토큰 수, 모델, 종료 사유, 계정, 타임스탬프, IAM 역할을 조회하게 한다.
• 중앙 파이프라인은 CloudWatch 구독 필터와 중앙 계정의 로그 목적지, AWS Lambda, Amazon Data Firehose, Amazon S3, AWS Glue, Amazon Athena로 구성된다. 두 개의 AWS CloudFormation 템플릿으로 배포하며, Lambda가 로그를 정리하고 Firehose가 JSON을 Parquet으로 변환한다.
• 중앙 스택을 먼저 배포한 뒤 소스 계정 스택을 배포해야 한다. 스택 배포만으로 Amazon Bedrock 로깅이 시작되지는 않으므로 계정별로 CloudWatch 전송을 활성화하고, 저장된 Athena 쿼리도 한 번 실행해 평탄화 뷰를 생성해야 한다.
• 처리된 호출 데이터를 IAM ARN을 키로 CUR 2.0과 결합하면 프롬프트 비용과 팀·계정별 일일 비용을 분석할 수 있다. 입출력 토큰 수, 모델 선택, stop_reason = max_tokens는 비효율적인 호출과 개선 대상을 찾는 근거가 된다.
• 원문은 토크노믹스가 2026 FinOps Foundation 콘퍼런스에서 공식 FinOps 영역으로 발표됐으며 See, Save, Run, Plan을 따른다고 설명한다. AWS Quick Sight로 사용량을 시각화할 수 있고, 중앙에 모인 전체 프롬프트·응답은 AWS KMS 기반 저장 시 암호화와 IAM 접근 정책으로 보호한다.

🧩 주요 포인트

1. 계정·IAM 역할까지 연결된 호출 기록 → 총청구액만으로 파악하기 어려운 개별 호출의 원인과 사용 주체를 추적하는 기반.
2. 반복 가능한 CloudFormation 배포와 별도 로깅·뷰 활성화 → 인프라 생성 이후에도 수집과 조회가 실제로 작동하는지 확인이 필요한 구조.
3. 토큰·모델·종료 사유와 CUR 2.0 비용의 결합 → 워크로드에 맞는 모델 선택과 프롬프트 개선을 경제적 영향까지 연결해 검토할 수 있는 기반.

🧠 상세 정리

1. 총청구액에서 개별 호출의 내용으로 가시성 확대

여러 계정에서 하루 수천 건의 Amazon Bedrock 호출을 운영하면 총청구액은 확인할 수 있어도 각 요청 안에서 무슨 일이 일어났는지 파악하기 어렵다는 문제가 출발점이다. 플랫폼·ML 엔지니어는 어떤 프롬프트가 전송됐는지, 어떤 응답이 돌아왔는지, 토큰을 얼마나 썼는지, 어떤 모델이 처리했는지와 응답이 적절했는지를 알고 싶어 한다. Amazon Bedrock의 기본 모델 호출 로깅은 요청과 응답의 전체 기록을 Amazon S3 또는 Amazon CloudWatch로 전달하지만, 원문은 계정별로 나뉜 데이터를 조직 전체에서 빠르게 조회하기 어렵다는 한계를 짚는다. 중앙 데이터 레이크는 프롬프트와 응답, 입출력 토큰 수, 모델, 종료 사유, 계정과 타임스탬프, IAM 역할을 함께 조회하도록 구성된다. 이를 통해 사용량 급증의 원인을 조사하고 낭비적인 프롬프트를 찾으며 팀별 사용을 구분할 수 있는 호출 단위의 관측 기반을 제공한다.

2. 연결 계정의 로그를 중앙 계정으로 전달하는 구조

솔루션은 Amazon Bedrock을 사용하는 연결 계정의 호출 로그를 CloudWatch에 모은 다음, 구독 필터를 통해 중앙 계정의 CloudWatch Logs 목적지로 전달한다. 각 소스 계정의 구독 필터는 새 로그 이벤트를 지정한 목적지로 계속 보내는 전달 규칙으로 작동하며, 중앙 계정은 이후 처리 파이프라인을 소유한다. 소스 계정에 중앙 파이프라인 자체의 권한을 주는 방식이 아니라, 소스 계정이 목적지로 이벤트를 넘기면 중앙 계정의 역할이 처리를 이어받는 구조다. Amazon Bedrock 로깅은 계정마다 한 번 설정하며, 기록할 CloudWatch 로그 그룹과 그곳에 쓸 수 있는 역할을 지정한다. 전체 구성은 두 개의 AWS CloudFormation 템플릿으로 제공되어 조직의 여러 계정에 반복 배포할 수 있고, 템플릿과 Lambda 코드, SQL은 AWS Sample Bedrock Invocation Data Lake GitHub 저장소에 포함돼 있다.

3. Lambda 정제와 Firehose 변환으로 조회 가능한 데이터 생성

CloudWatch가 전달하는 데이터는 개별 호출의 깨끗한 JSON이 아니라 여러 이벤트를 묶어 압축하고 인코딩한 배치이므로, 후속 분석 전에 이를 풀어야 한다. 작은 AWS Lambda 함수가 배치를 개별 로그 레코드로 복원하고, 호출 데이터가 아닌 관리 메시지와 권한 설정 안내 같은 일반 텍스트를 제거한다. 이러한 메시지를 그대로 통과시키면 다음 처리 단계가 깨질 수 있다는 것이 원문이 제시하는 정제의 이유다. Lambda는 한 단계 안쪽에 중첩된 호출자 신원 필드도 최상위로 올려 이후 쿼리를 쉽게 만든다. Amazon Data Firehose는 정리된 레코드를 버퍼링하면서 JSON을 Parquet으로 변환해 Amazon S3에 저장하고, year=2026/month=08/day=27/ 같은 날짜 경로로 객체를 배치한다. AWS Glue 테이블은 Athena가 이 파일들을 읽는 방식을 정의해 일반 SQL로 사용자별 토큰 사용량, 모델 선택과 프롬프트를 조회할 수 있게 한다.

4. 배포 전제조건과 중앙·소스 계정의 설정 순서

배포 전에는 각 계정의 자격 증명으로 설정한 AWS CLI, CloudFormation의 CAPABILITY_IAM 및 CAPABILITY_NAMED_IAM 권한, 최소 하나의 연결 계정과 하나의 중앙 계정이 필요하며 두 계정은 같아도 된다. 종단 간 테스트 스크립트에는 Python 3와 Boto3가 필요하고, 관련 리소스가 담긴 저장소도 복제해 두어야 한다. 중앙 CloudFormation 스택을 먼저 배포해야 소스 계정 스택이 이를 참조할 수 있으며, 출력값 중 CloudWatch Logs 목적지 ARN과 선택적 대시보드 배포에 필요한 AWS Quick Sight 역할 ARN을 기록한다. 이후 Amazon Bedrock 워크로드를 실행하는 각 계정에 연결 계정 스택을 배포하고, 중앙 스택에서 얻은 목적지 ARN을 입력한다. 스택 생성만으로 로깅이 시작되지는 않는데, Amazon Bedrock 호출 로깅은 CloudFormation 리소스가 아닌 계정 수준 설정이기 때문이다. 따라서 소스 계정마다 해당 로그 그룹과 로깅 역할을 지정해 호출 로깅을 활성화하고, 이 솔루션에서는 CloudWatch 전송만 켠다.

5. 데이터 도착 확인과 Athena 평탄화 뷰 활성화

수집 확인은 소스 계정에서 테스트 호출을 실행한 뒤 Amazon Data Firehose가 버퍼를 비울 때까지 기다리는 방식으로 진행한다. 원문은 이 대기 시간을 대략 1분으로 설명하지만 더 오래 걸릴 수도 있다고 명시하며, 이후 데이터 레이크의 data/ 접두사 아래에 Parquet 객체가 생겼는지 Amazon S3에서 확인하도록 한다. 중앙 스택은 평탄화 뷰의 정의를 Athena의 저장된 쿼리로 등록하지만 그 쿼리를 자동으로 실행하지 않으므로, 사용자가 한 번 실행해 뷰를 생성해야 한다. 조회는 전용 Athena 워크그룹에서 원시 테이블이나 평탄화 뷰를 대상으로 수행한다. 평탄화 뷰에는 토큰 수, 캐시 토큰, 종료 사유, 프롬프트와 응답 미리보기가 이미 열로 정리되어 있어 분석 시 중첩 구조를 반복해서 풀 필요가 줄어든다. 이 과정은 배포 성공 여부와 별개로 실제 로그 수집 및 SQL 조회까지 이어지는지를 확인하는 단계다.

6. CUR 2.0 비용 연결과 토크노믹스의 운영 기반

호출 데이터에 금액을 연결하려면 처리된 테이블과 CUR 2.0 데이터를 IAM ARN을 키로 결합하며, 예제 쿼리는 저장소의 Bedrock Data Lake SQL 파일에 제공된다. 원문은 이 결합으로 비용이 큰 프롬프트, 팀·계정별 일일 비용, 비효율적인 호출의 비용을 분석할 수 있다고 설명하면서도 비용 연결 전부터 데이터 레이크 자체가 유용하다고 강조한다. 토크노믹스는 AI 토큰 소비의 경제성을 관리하는 활동으로 소개되며, 원문에 따르면 2026 FinOps Foundation 콘퍼런스에서 공식 FinOps 영역으로 발표됐다. 이 활동은 Cloud Financial Management와 같은 See, Save, Run, Plan의 네 축을 토큰에 적용한다. 조직이 어떤 팀에서 토큰을 많이 쓰는지와 어떤 프롬프트가 낭비적인지 판단하려면 세밀한 측정 데이터가 필요하며, 호출별 토큰·비용 가시성은 워크로드에 맞는 모델을 고르는 근거가 된다. 따라서 이 솔루션은 Amazon Bedrock 청구액 추적을 넘어 토크노믹스를 운영하기 위한 데이터 기반으로 제시된다.

7. AWS Quick Sight 시각화와 호출 로그의 활용

원문은 토큰 사용량을 시간에 따라 시각화하고 조직의 이해관계자와 공유할 수 있는 AWS Quick Sight 대시보드도 제공한다. 사용자는 대시보드를 수정하거나 팀 정보 같은 조직 메타데이터를 더할 수 있으며, 배포에는 cid-cmd deploy CLI 명령을 사용하고 역할 구성과 데이터 소스 설정의 상세 절차는 저장소 README를 따른다. 중앙 테이블에서는 특정 계정의 호출에 해당하는 정확한 프롬프트와 응답을 찾아 디버깅과 감사를 수행할 수 있다. input_tokens와 output_tokens를 모델 선택 및 팀별 사용과 비교하면 토큰 비효율을 살펴볼 수 있고, stop_reason = max_tokens인 요청은 프롬프트나 설정의 개선 필요성을 검토할 신호로 제시된다. 또한 호출 패턴별로 어떤 모델이 사용되는지 확인해 워크로드와의 적합성을 검토하고, 계정에 연결된 호출 기록으로 팀별 사용을 관리할 수 있다. 다만 종료 사유나 토큰 수는 개선 대상을 찾는 근거로 설명되며, 그것만으로 응답 품질이 자동 판정된다고 서술되지는 않는다.

8. 전체 프롬프트·응답 중앙화에 따른 데이터 거버넌스

이 솔루션은 모든 팀의 전체 프롬프트와 응답을 하나의 Amazon S3 버킷으로 모으므로, 원문은 보안과 거버넌스가 처음부터 아키텍처에 포함된다고 설명한다. 버킷은 AWS Key Management Service인 AWS KMS를 사용하는 서버 측 암호화로 보호되며, 저장 데이터는 기본적으로 암호화된다. 버킷과 Amazon Athena 쿼리 결과에 대한 접근은 AWS Identity and Access Management인 IAM 정책으로 제어하고, 필요한 팀과 역할을 대상으로 권한 범위를 설정할 수 있다. 이는 호출별 내용을 상세히 조회하는 관측 기능과 함께, 중앙에 모인 원문 데이터와 조회 결과의 접근 범위도 다뤄야 한다는 맥락이다. 다만 제공된 source_body는 데이터 거버넌스 단락의 'Prompts'라는 단어에서 끝나므로, 그 뒤에 이어질 수 있는 추가 보호 조치나 운영 정책은 확인할 수 없다. 따라서 확인 가능한 거버넌스 설명은 AWS KMS 기반 저장 시 암호화와 IAM을 통한 접근 제어 범위까지다.

🧾 핵심 주장 / 시사점

• 호출 내용과 사용 주체가 함께 기록되어야 사용량 급증이나 비효율을 특정 프롬프트·모델·계정과 연결할 수 있다. 중앙 데이터 레이크의 핵심 가치는 조직 전체의 호출을 같은 방식으로 조회하는 데 있다.
• CloudFormation 배포, 계정별 로깅 활성화, Athena 뷰 생성은 각각 별도 단계다. 인프라가 생성됐다는 사실만으로 분석 가능한 데이터가 준비됐다고 판단할 수 없다.
• 비용 연결은 토큰 사용량 분석의 경제적 의미를 넓히지만, 전체 프롬프트·응답의 중앙화도 함께 수반한다. 원문은 분석 기능과 함께 AWS KMS 암호화 및 IAM 접근 제어를 구성 요소로 제시한다.

✅ 액션 아이템

• Amazon Bedrock 계정별 CloudWatch 로깅 활성화와 Athena 평탄화 뷰 생성 여부 확인.
• IAM ARN을 통한 CUR 2.0 결합으로 프롬프트 및 팀·계정별 일일 비용 분석.
• 입출력 토큰 수, 모델 선택, stop_reason = max_tokens를 바탕으로 비효율적인 호출과 프롬프트 개선 대상 검토.

❓ 열린 질문

• 중앙 분석에 포함할 Amazon Bedrock 계정마다 CloudWatch 로깅이 활성화되어 있고 Athena 평탄화 뷰가 생성되어 있는가?
• IAM ARN을 키로 CUR 2.0과 결합했을 때 프롬프트 및 팀·계정별 일일 비용은 어떻게 나타나는가?
• 입출력 토큰 수, 모델 선택, stop_reason = max_tokens를 함께 살펴보면 어떤 호출이 우선적인 개선 대상으로 드러나는가?