AWS Bedrock에서의 Claude Code 및 Anthropic 모델 사용: 학습된 교훈

Claude Code는 현재 주요한 코딩 AI 하네스 (harness) 중 하나이며, 어쩌면 가장 주요한 도구일 수도 있습니다. 많은 조직들이 Anthropic 플랜을 통하지 않고, 제3자 클라우드 제공업체에 호스팅된 Anthropic 모델을 통해 Claude Code를 사용하는 것을 선택합니다. AWS Bedrock은 Opus, Sonnet, Haiku와 같은 최신 Anthropic 모델을 포함하여 다양한 LLM의 방대한 카탈로그를 제공하는 서비스의 한 예입니다.

최근 기사들에 따르면 Claude 구독이 경제적으로 훨씬 더 효율적이라는 사실이 밝혀졌습니다 (예시 1, 예시 2). 그렇다면 왜 누군가는 API 과금에 더 많은 비용을 지불하는 것을 선호할까요? 여기에는 몇 가지 이유가 있습니다:

신뢰성 (Reliability): Anthropic 서비스는 여전히 중요한 운영 워크플로우에 영향을 미칠 정도로 변동성이 큽니다. 이 글을 쓰는 시점에, 공개된 Claude 상태 페이지는 Opus 4.8 장애 동안 Claude API 및 Claude Code에 대해 저하된 성능을 보여주고 있었습니다. 동일한 상태 스냅샷에 따르면 지난 90일 동안 claude.ai의 가동 시간은 98.96%, Claude Console의 가동 시간은 99.45%였습니다. 저희의 경험상, Bedrock은 훨씬 더 신뢰할 수 있습니다. Bedrock의 교차 리전 추론 (cross-Region inference)은 요청을 다른 AWS 리전으로 자동 라우팅하고, 계획되지 않은 트래픽 급증을 처리하기 위해 리전 간의 컴퓨팅 자원을 사용할 수 있습니다. 이는 지연 시간(latency)에 민감한 애플리케이션에 매우 중요할 수 있습니다.

준수 사항 및 보안 (Compliance and security): 제3자 데이터 처리와 관련된 준수 사항(GDPR)이 있는 조직은 사용자 또는 고객 정보를 제3자 서비스로 전송하지 않도록 주의해야 합니다. 이미 AWS를 사용 중이라면, Bedrock에서 Opus를 사용함으로써 데이터가 클라우드 경계를 벗어나지 않습니다. 최소한의 설정만으로 LLM 트래픽 또한 클라우드를 벗어나지 않게 할 수 있습니다.
로깅 및 관찰 가능성 (Logging and observability) — 요청에 사전 정의된 태그 세트를 주석으로 다는 특정 모델에 대한 포인터인 _애플리케이션 추론 프로필 (application inference profiles)_을 사용하면, 모델 사용량을 쉽게 추적하고 내부 사용자별로 그룹화하는 등의 작업을 수행할 수 있습니다. 또한 모델 호출 로깅 (model invocation logging)을 사용하여 보안 감사 및 분석을 위해 모든 Bedrock 모델 호출에 대한 로깅을 활성화할 수 있는 방법도 있습니다.

애플리케이션 추론 프로필 (Application inference profile)

Bedrock 호출자(AWS SDK, AWS CLI, HTTP)가 LLM을 사용하고자 할 때, 다음 중 하나를 지정합니다:

AWS가 정의한 추론 프로필 (예: arn:aws:bedrock:<source-region>:<account-id>:inference-profile/global.anthropic.claude-opus-4-8)
사용자가 생성한 사용자 정의 추론 프로필 (예: arn:aws:bedrock:<region>:<account-id>:application-inference-profile/<application-profile-id>)

사용자 정의 애플리케이션 추론 프로필은 사전 정의된 태그 세트로 모델 사용을 "래핑 (wrap)"하는 데 사용됩니다. 일반적인 CloudFormation 리소스는 다음과 같습니다 (docs)

Resources:
  ServiceAOpusProfile:
    Type: AWS::Bedrock::ApplicationInferenceProfile
...

여기에서 설명(description), 사용될 모델(본 예제에서는 Opus 4.8), 그리고 태그(tags) 목록을 지정합니다. 프로필이 생성되는 즉시, Claude Code 또는 Bedrock 호출(invocation) 시 해당 ARN을 지정하면 됩니다.

권한 (Permissions)

호출자(caller)가 모델을 호출할 때 반드시 추론 프로필 (inference profile)만을 사용하도록 100% 보장하려면, 권한을 적절하게 설정해야 합니다.

# 우리의 추론 프로필 호출을 허용
- Effect: Allow
  Action: 
...

이를 통해 호출자는 모델을 호출할 때 반드시 추론 프로필을 사용해야 하며, 결과적으로 태그 (tags)가 제대로 전파됩니다.

팁 (Tip): 개발자 환경에서 Bedrock 권한을 디버깅하기 위해 다음 AWS CLI 명령어를 사용할 수 있습니다 (Opus 4.7에게 인사를 건넵니다):

aws bedrock-runtime converse \
    --region us-east-1 \
    --model-id global.anthropic.claude-opus-4-7 \
...

교훈 1: 사람이 아닌 서비스를 위해 애플리케이션 추론 프로필 (application inference profiles)을 사용하세요

만약 COO(최고 운영 책임자)가 이러한 Bedrock 사용 보고서를 보게 된다면 질문을 던질 것입니다. 따라서 조직 내의 모든 워크로드 (workloads)에 애플리케이션 추론 프로필을 사용하여 지출을 투명하게 만드세요. 이전 (Before):

이후 (After):

교훈 2: 사람의 사용을 위해 커스텀 추론 프로필 (custom inference profiles)을 사용하지 마세요

AWS Bedrock과 Claude Code의 통합은 커스텀 애플리케이션 추론 프로필 (custom application inference profiles)을 지원합니다:

export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_DEFAULT_OPUS_MODEL="arn:aws:bedrock:<region>:<account_id>:application-inference-profile/..."
export ANTHROPIC_DEFAULT_SONNET_MODEL="arn:aws:bedrock:<region>:<account_id>:application-inference-profile/..."
...

하지만 모델이 급격히 진화하는 시대에 이를 관리하는 것은 매우 번거로운 일입니다. 그 이유는 다음과 같습니다:

빈번한 업데이트 (Frequent updates): 모델이 빈번하게 출시되므로, 정기적으로 추론 프로필 (inference profiles)을 생성해야 합니다. 사람들은 최신 모델로 빠르게 전환하는 것을 선호하는 경향이 있습니다.
다양한 차원 (Multiple dimensions): 조직 내에 여러 팀이 있을 수 있습니다. 이 경우 각 LLM 모델에 대해 하나가 아닌 X개의 추론 프로필을 생성 및 관리하고, 이를 어떤 방식으로든 배포해야 합니다.
기술적 숙련도 (Technical savviness): 조직 구성원들의 기술적 숙련도는 제각각일 수 있습니다. 엔지니어링 업무를 정기적으로 수행하지 않는 사람들에게 추론 프로필 환경 변수 (environment variables)나 설정 (configs)을 구성하는 것은 어려울 수 있습니다.

그렇다면 지출은 어떻게 추적할까요? 다음과 같은 옵션들이 있습니다:

제3자 LLM 게이트웨이 (LLM gateway) 사용: 몇 가지 예로 LiteLLM, Portkey, Bifrost 등이 있습니다. 이러한 서비스들은 호출자 (caller)와 Bedrock 사이에서 프록시 (proxy) 역할을 수행하며, 인증 (authentication), MCP 관리 (MCP management)를 단순화하고 사용자당 예산을 설정할 수 있게 해줍니다. 추가적인 비용을 지불할 여유가 있다면 이 방법을 선택하세요!
- 장점 (Pros): 이러한 서비스들은 모든 기능을 즉시 사용할 수 있도록 제공하며, 구체적인 예산을 지정하고 이를 실시간으로 강제할 수 있습니다.
- 단점 (Cons): 일반적으로 보안 기능(예: OAuth 통합)이 필요한 경우 이러한 서비스들은 무료가 아닙니다.
AWS Cost Explorer에서 CUR 2.0 내보내기 (export)를 설정하고 내보내기 시 호출자 식별 정보 (caller identity)를 활성화하세요. 그렇게 하면 내보내기 데이터에서 IAM 세션 단위의 세분성 (granularity)을 얻을 수 있어 사용자별 지출을 계산할 수 있습니다.
- 장점 (Pros): 수치가 100% 정확하며 클라우드 청구서와 일치합니다.
- 단점 (Cons): 24시간의 지연 시간 (latency)이 발생합니다.

Bedrock 호출 로깅 (invocation logging)을 활성화하고 실시간으로 사용량을 추적하세요.
- 장점 (Pros): 정확한 토큰 수 (token counts) 및 사용자 식별 정보와 함께 거의 실시간에 가까운 로그 전달이 가능합니다.
- 단점 (Cons): 이는 매우 민감한 데이터입니다! 액세스 권한을 제한해야 하며, AWS Lambda 및 데이터베이스를 사용하여 처리 로직을 직접 구현해야 합니다.

Lesson 3: 호출 로그 (invocation logs) 활성화

사용량 추적을 목적으로, 저는 로그에 저장된 정보의 상당 부분을 제거했습니다. 형태는 다음과 같습니다:

{
  "timestamp": "2026-06-16T12:00:56Z",
  "accountId": "...",
...

cacheRead, cacheWrite, input 및 output 토큰 수(token counts)가 포함되어 있는지, 그리고 identity.arn이 요청을 수행한 사용자를 식별하는지 확인하십시오. 이 수치들에 가격 책정(pricing)을 곱하면 최종 비용을 계산할 수 있습니다. 이 방식은 사용자가 Claude Code뿐만 아니라 어떤 AI 하네스(AI harness)를 사용하더라도 유효한데, 결국 모든 도구가 최종적으로는 AWS Bedrock을 호출하기 때문입니다.

이에 더해, 로그에는 요청의 전체 페이로드(payload)가 저장되므로 다음과 같은 사항들을 추적할 수 있습니다.

엔지니어들이 어떤 모델을 사용하는지
어떤 MCP 서버와 스킬(Skills)이 인기 있는지
첫 번째 메시지의 전형적인 컨텍스트 크기(context size)는 어느 정도인지 (이는 비효율성을 파악하는 데 도움이 됩니다)
세션당 메시지가 몇 개인지 (이는 누군가가 개발 에이전트(development agent)를 남용하는지 판단하는 데 도움이 됩니다)
Slack으로 전송되는 실시간 지출 알림

등의 다양한 정보를 확인할 수 있습니다.

결론

조직을 위해 Anthropic 모델의 제공자로 AWS Bedrock을 사용하는 것은 비용이 저렴하지는 않지만, 지출, 권한, 보안 및 분석 기능에 대해 더 많은 제어권을 제공합니다.