Claude Code를 Amazon Bedrock을 통해 사용해 보기: 주의할 점과 실무 적용 시 고려사항

지난 기사에서는 Amazon Bedrock에서 Claude를 업무에 이용할 경우, IAM, SCP, Guardrails, 로그 감사(Log Audit) 등을 어떻게 조합할지를 정리했습니다.

이번에는 그 후속으로, 조금 더 실전적인 관점에서 Claude Code를 Amazon Bedrock을 통해 사용해 보기라는 주제로 글을 씁니다.

Claude Code는 터미널이나 VSCode 확장 프로그램(Extension) 등에서 사용할 수 있는 AI 코딩 에이전트(AI Coding Agent)입니다.

코드를 작성하게 하거나, 기존 코드를 읽게 하거나, 에러 원인을 조사하게 하는 등 폭넓은 용도로 이용할 수 있습니다.

다만, 업무 이용을 고려하면 다음과 같은 불안함이 있지 않을까요?

• 개인의 API 키를 사용하게 해도 되는가
• 회사의 AWS 환경 하에서 관리할 수 있는가
• Claude Code가 어떤 모델을 사용하고 있는지 알 수 있는가
• Bedrock을 경유하면 무엇이 좋은가
• 실제로 설정할 때 어디에서 막히기 쉬운가
• 팀 단위로 모델이나 이용량을 관리할 수 있는가

개인적으로 Claude Code를 업무에서 사용한다면, Amazon Bedrock을 경유하는 선택지는 상당히 유력하다고 생각합니다.

이유는 간단합니다. Claude Code를 AWS의 인증(Authentication)・권한(Authorization)・과금(Billing)・감사(Audit) 프레임워크에 태우기 쉬워지기 때문입니다.

이 기사에서는 지난번과 같은 통제 설계 그 자체에는 너무 깊게 들어가지 않고, 실제로 Claude Code를 Amazon Bedrock을 통해 사용하는 경우의 구성, 설정 방법, 주의할 점, 팀 이용 시 고려해야 할 사항을 정리합니다.

또한, 보충 설명으로 LiteLLM을 사이에 두어 LLM 이용을 관리하는 구성에 대해서도 조금 다룹니다.

LiteLLM에 대해서는 이 기사에서 "이러한 선택지도 있다" 정도의 위치로만 다루겠습니다. 별도로 LiteLLM에 관한 기사도 게시할 예정입니다.

지난 기사와 내용이 겹치지 않도록, 이 기사에서는 다음 내용에 집중합니다.

• Claude Code를 Bedrock 경유로 사용하는 구성

• 처음에 설정하는 환경 변수(Environment Variable)

• AWS 인증 관련하여 막히기 쉬운 점

• 모델 ID / inference profile에 대한 생각

• LiteLLM을 사용한 모델 이용 관리 방식

• 실제로 어떤 방식의 사용이 편리했는지

• 팀 전개 시 결정해 두어야 할 사항

• SCP를 통한 조직 전체의 강제 제어

• Guardrails의 상세 설계

• CloudTrail이나 Model invocation logging의 상세한 감사 설계

• Bedrock 전체의 거버넌스(Governance) 설계

• LiteLLM Proxy의 상세한 구축 절차

이러한 부분은 지난 기사나 다른 기사의 범위에 가깝기 때문에, 이번에는 필요한 부분만 다룹니다.

먼저, Claude Code를 Bedrock 경유로 사용하는 구성은 대략 다음과 같은 이미지입니다.

일반적으로 Claude Code를 사용하는 경우에는 Anthropic의 API 키를 사용하는 구성도 있습니다.

반면 Bedrock을 경유하면, Claude Code의 요청이 AWS 측의 Bedrock Runtime으로 향하게 됩니다.

즉, 개발자 입장에서는 Claude Code를 사용하고 있을 뿐이지만, 뒷단에서는 AWS 인증 정보를 사용하여 Bedrock을 호출하는 형태가 됩니다.

이 점이 상당히 중요하다고 생각합니다.

Claude Code를 단순히 "편리한 AI 도구"로만 보는 것이 아니라, AWS 상의 생성형 AI 이용의 일부로 다룰 수 있게 됩니다.

Claude Code를 Bedrock 경유로 사용할 때의 장점은 개인적으로 다음과 같다고 생각합니다.

특히 큰 점은 AWS 인증에 맞출 수 있다는 것입니다.

개인의 API 키를 각 개발자에게 배포하여 관리하는 것보다, AWS SSO나 IAM Role을 사용하는 것이 조직 이용 측면에서는 다루기 쉬운 경우가 많다고 생각합니다.

예를 들어, 퇴직자·이동자의 권한 정지, 이용자별 권한 차이, 검증용 계정과 운영 계정의 분리 등은 AWS의 기존 운영 방식에 태우기 쉽습니다.

Claude Code에서 Bedrock을 사용하려면 먼저 다음과 같은 환경 변수를 설정합니다.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1

공식 문서에서도 Bedrock 연동을 활성화하기 위해 CLAUDE_CODE_USE_BEDROCK=1과 AWS_REGION을 설정하도록 안내하고 있습니다.

개인적으로는 AWS Profile도 명시해 두는 것이 더 이해하기 쉽다고 생각합니다.

export AWS_PROFILE=bedrock-dev
export AWS_REGION=us-east-1
export CLAUDE_CODE_USE_BEDROCK=1

AWS SSO를 사용하는 경우에는 먼저 로그인을 합니다.

aws sso login --profile bedrock-dev

그 후에 Claude Code를 실행합니다.

claude

Claude Code 안에서 상태 확인을 하고 싶을 때는 다음을 사용합니다.

/status

여기서 Bedrock을 통해 동작하고 있는지, 어떤 모델을 사용하고 있는지 확인합니다.

실제로 설정해 보면 Claude Code 자체보다는 AWS 측 설정에서 막히는 경우가 많을 것이라고 생각합니다.

기초적이지만 주의해야 할 포인트는 다음과 같습니다.

먼저 확인하고 싶은 것은 AWS CLI로 인증이 되고 있는지 여부입니다.

aws sts get-caller-identity --profile bedrock-dev

이 명령이 실패한다면 Claude Code 이전에 AWS 인증이 되지 않은 상태입니다.

SSO를 사용하고 있는 경우에는 다음을 실행합니다.

aws sso login --profile bedrock-dev

회사 단말기나 프록시(Proxy) 환경에서는 SSO 로그인 관련 문제로 은근히 막히는 일이 어느 회사에나 흔히 있는 일이 아닐까 싶습니다.

이 경우, Claude Code를 실행하기 전에 수동으로 aws sso login을 완료해 두는 것이 좋다고 생각합니다.

AWS CLI의 config에 리전(Region)을 적어두었으니 괜찮을 것이라고 생각하기 쉽지만, Claude Code의 Bedrock 연동에서는 AWS_REGION을 명시하는 편이 안전합니다.

echo $AWS_REGION

비어 있다면 다음과 같이 설정합니다.

export AWS_REGION=us-east-1

이 부분은 의외로 놓치기 쉽습니다.

Bedrock에서는 사용하려는 모델에 대한 액세스(Access)를 활성화해 두어야 합니다.

예를 들어 Claude Sonnet을 사용하고 싶다면, Amazon Bedrock의 Model access / Model catalog 측에서 대상 모델이 이용 가능한 상태인지 확인합니다.

AWS 계정을 생성했다고 해서 모든 모델을 처음부터 바로 사용할 수 있는 것은 아닙니다.

여기서 활성화하지 않으면 IAM 권한이 올바르더라도 호출에 실패합니다.

Claude Code에서 Bedrock을 호출하려면 Bedrock의 모델 호출 권한이 필요합니다.

검증용으로는 우선 다음과 같은 액션(Action)이 필요합니다.

{
"Version": "2012-10-17",
"Statement": [
...

물론 실무 이용이나 팀 단위 전개 시에는 Resource: "*" 상태로 두는 것이 아니라, 사용하는 모델이나 인퍼런스 프로파일(Inference profile)로 범위를 좁히는 것이 좋습니다.

다만 처음부터 너무 범위를 좁히면 원인 파악(Troubleshooting)이 어려워질 수 있습니다.

개인적으로는 우선 검증 환경에서 넓게 허용하여 통신 확인을 한 뒤, 그 다음에 범위를 좁혀 나가는 방식이 현실적이라고 생각합니다.

Claude Code를 Bedrock을 통해 사용할 때 상당히 헷갈리기 쉬운 부분이 바로 **모델 ID (Model ID)**와 **인퍼런스 프로파일 (Inference profile)**입니다.

Bedrock에서는 모델을 직접 지정하는 경우도 있고, 인퍼런스 프로파일을 지정하는 경우도 있습니다.

특히 새로운 Claude 모델의 경우, 온디맨드(On-demand) 호출이 아니라 인퍼런스 프로파일 지정이 필요할 수 있습니다.

이 경우 다음과 같이 모델을 명시합니다.

export ANTHROPIC_MODEL='us.anthropic.claude-sonnet-4-5-20250929-v1:0'

실제 모델 ID는 이용하는 리전이나 시기에 따라 달라지므로, Bedrock 콘솔 또는 공식 문서를 통해 확인하시기 바랍니다.

개인적으로는 팀에서 사용할 경우 sonnet과 같이 대략적으로 지정하는 것보다, 이용할 모델 ID를 명시적으로 고정하는 것이 좋다고 생각합니다.

이유는 간단합니다. 어느 날 갑자기 모델의 해결 대상(Resolution target)이 바뀌어 버리면, 사용자나 환경에 따라 '되는 사람'과 '안 되는 사람'이 나뉠 가능성이 있기 때문입니다.

다만, 최근에는 모델의 변화 속도가 상당히 빠르기 때문에, 어느샌가 사용하던 모델이 레거시 모델 (Legacy Model) 취급을 받고 있는 상황도 흔히 발생할 수 있습니다.

따라서 모델 ID를 고정하는 것으로 끝낼 것이 아니라, 조금 번거롭더라도 AWS Health의 이벤트 알림 등을 통해 모델의 제공 상황이나 변경 예정 공지를 정기적으로 확인하는 것이 좋다고 생각합니다.

지금까지 Claude Code에서 Amazon Bedrock을 직접 호출하는 구성에 대해 설명해 드렸습니다.

반면, 팀이나 조직에서 여러 개의 LLM을 사용하는 경우에는 Claude Code와 Bedrock 사이에 LiteLLM을 끼워 넣는 방식도 있습니다.

LiteLLM은 OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI 등 여러 LLM 프로바이더 (Provider)를 통일된 인터페이스로 다루기 위한 AI Gateway / Proxy입니다.

대략적인 구성은 다음과 같은 이미지입니다.

Bedrock을 직접 호출하는 구성에서는 Claude Code가 AWS 인증 정보를 사용하여 Bedrock에 액세스합니다.

반면 LiteLLM을 끼워 넣는 경우에는 Claude Code가 LiteLLM Proxy를 호출하고, LiteLLM 측에서 백엔드의 Bedrock이나 기타 LLM 프로바이더로 라우팅(Routing)하는 형태가 됩니다.

Claude Code 공식 문서에서도 LLM Gateway를 사용하는 구성에 대해 설명되어 있으며, Gateway 측에서는 Anthropic Messages 형식, Bedrock InvokeModel 형식, Vertex rawPredict 형식 등 Claude Code가 이용하는 API 형식을 올바르게 처리해야 합니다.

LiteLLM을 끼워 넣으면 예를 들어 다음과 같은 관리가 용이해집니다.

• 이용자별로 가상 키 (Virtual Key)를 발행
• 팀별로 이용 가능한 모델을 분리
• 모델별 이용량 확인
• 이용자·팀 단위로 예산 상한 설정
• 관리자 UI (Admin UI)에서 이용 상황 확인
• Bedrock 이외의 LLM 프로바이더도 통합 관리

비교하면 다음과 같은 이미지입니다.

관점	Bedrock 직접 이용	LiteLLM 경유
인증	AWS 인증 정보 이용	LiteLLM의 Virtual Key 등을 이용
...

개인적으로는 첫 검증 단계에서는 Bedrock 직접 이용만으로도 충분하다고 생각합니다.

다만, 다음과 같은 요구사항이 나온다면 LiteLLM을 끼워 넣는 구성도 검토할 가치가 있습니다.

• Claude Code 외에도 Cline이나 자체 앱에서 LLM을 사용하고 싶다
• Bedrock, Azure OpenAI, 온프레미스 (On-premise) 환경에 구축한 LLM 이용 등을 통합 관리하고 싶다
• 이용자별로 API 키를 나누고 싶다
• 팀별로 사용할 수 있는 모델을 바꾸고 싶다
• 예산이나 이용량을 LiteLLM 측에서도 확인하고 싶다
• 향후 모델의 라우팅이나 폴백 (Fallback)도 고려하고 싶다

하지만 LiteLLM을 끼워 넣으면 편리해지는 반면, LiteLLM Proxy 자체의 운영, 인증, 가용성, 로그 관리도 고려해야 합니다.

따라서 이 기사의 범위에서는 "Claude Code에서 Bedrock을 직접 사용"하는 구성을 기본으로 하되, 조직적으로 LLM 이용을 확장하는 단계에서는 LiteLLM과 같은 AI Gateway를 검토하는 정도의 위치 설정이 적절하다고 생각합니다.

Bedrock의 Claude 모델을 사용하다 보면, us.

나 apac.

와 같은 접두사 (Prefix)가 붙은 추론 프로필 (Inference Profile)을 볼 수 있습니다.

이는 교차 리전 추론 (Cross-region Inference)과 관련이 있습니다.

교차 리전 추론에서는 요청을 보낸 리전에서, 추론 프로필로 정의된 여러 대상 리전 중 하나로 요청이 라우팅됩니다.

대략적인 도식은 다음과 같은 이미지입니다.

여기서 주의해야 할 점은 AWS Organizations의 SCP 등으로 리전 제한을 걸어둔 경우입니다.

이전 기사의 테마와 가까우므로 상세히 파고들지는 않겠지만, Bedrock의 교차 리전 추론을 사용할 경우 어느 리전으로 요청이 라우팅될 가능성이 있는지는 사전에 확인하는 것이 좋습니다.

개인적인 검증에서는 솔직히 크게 신경 쓰지 않는 부분이지만, 데이터 레지던시 (Data Residency) 관점에서는 기업 이용 시 중요한 논점이 될 수 있습니다.

여기서부터는 약간 경험담에 가까운 이야기입니다.

Claude Code를 사용하면서 편리하다고 느낀 점은, 단순히 "코드를 작성해 주는 것"은 물론이고, 기존 코드를 읽거나 조사의 입구를 만들거나, 문서화(Documentation)하는 용도로도 상당히 강력하다는 점입니다.

특히 역사가 깊은 프로젝트의 경우, 리포지토리(Repository)가 여러 개로 나뉘어 있거나 디렉토리 계층이 깊어서 전체상을 파악하는 것만으로도 상당히 힘든 경우가 많습니다.

그런 점에서 Claude Code는 멀티 리포지토리(Multi-repository) 구조를 살펴보며 어디에 무엇이 있을지, 어떤 처리가 어디로 연결되어 있을지 등을 정리해 주기 때문에, 이해를 위한 입구를 만드는 데 매우 편리하며 업무에서도 매일 도움을 받고 있습니다.

처음 보는 리포지토리에서는 우선 다음과 같이 질문하면 편리합니다.

이 리포지토리의 구성을 설명해 주세요.
주요 처리 흐름과 가장 먼저 읽어야 할 파일을 알려주세요.

직접 갑자기 모든 파일을 쫓기보다는, 처음에 전체상을 잡아달라고 하는 것이 도움이 됩니다.

특히 Lambda, CloudFormation, CDK, Terraform, CI/CD 정의 등이 혼재되어 있는 리포지토리에서는 입구를 찾는 것만으로도 시간이 걸립니다.

Claude Code에게 먼저 지도를 만들게 하면, 그 이후의 조사가 상당히 수월해집니다.

에러 로그를 붙여넣고 관련 있어 보이는 파일을 찾아달라고 하는 방식도 편리합니다.

이 에러의 원인을 조사해 주세요.
관련되어 보이는 파일을 확인하여 원인 후보를 여러 개 제시해 주세요.
수정안은 영향 범위(Impact scope)를 포함하여 설명해 주세요.

이때, 바로 수정을 시키기보다는 우선 원인 후보를 뽑아내도록 하는 것이 좋다고 생각합니다.

Claude Code도 완벽하지 않기 때문에, 제 경우에는 하나의 예시일 뿐이지만 다음과 같이 단계별(Step-by-step)로 진행하는 것이 좋다고 생각합니다.

Claude Code에게 "변경해 줘"라고 부탁하기 전에, 먼저 "조사해 줘", "후보를 내줘"라고 요청하는 것이 포인트입니다.

테스트 코드 작성도 궁합이 좋습니다.

이 함수의 단위 테스트(Unit test)를 작성해 주세요.
정상계, 이상계, 경계값(Boundary value)을 포함해 주세요.
기존 테스트 코드의 작성 방식에 맞춰 주세요.

직접 처음부터 테스트 관점을 생각하는 것보다, 첫 번째 초안(Draft)을 만들어 주는 것이 편리합니다.

단, 생성된 테스트 코드가 정말 의미 있는 검증을 수행하고 있는지는 확인이 필요합니다.

특히 모의 객체(Mock)의 사용법이나 이상계의 기대값은, 분위기상 그럴듯해 보이는 코드가 나올 수도 있으므로 주의하는 것이 좋습니다. 커버리지(Coverage)를 망라하고 있는지, 정해진 테스트 도구를 사용한 구현인지 등, 각 프로젝트에서 정한 개발 규칙에 부합하는 테스트인지 주의 깊게 살펴볼 필요가 있습니다.

이 또한 상당히 편리하다고 느낀 점은 문서화입니다.

이 처리의 개요를 README용으로 정리해 주세요.
운영 담당자가 읽는다는 전제하에 전문 용어는 최소한으로 사용해 주세요.

또한 개발자용으로는 다음과 같이 요청할 수 있습니다.

이 Lambda 함수의 처리 흐름을 개발자용 설계 메모로 정리해 주세요.
입력, 주요 처리, 출력, 예외 처리로 나누어 주세요.

Claude Code는 코드를 읽은 뒤 설명을 만드는 데 능숙하므로, README, 설계 메모, 운영 메모의 초안 작성에는 상당히 적합하다고 생각합니다.

편리한 한편, 무엇이든 다 맡기는 것은 위험합니다.

특히 다음 사항은 신중하게 다루어야 한다고 생각합니다.

Claude Code는 IAM 정책(Policy)도 그럴듯하게 생성해 줍니다.

하지만 IAM은 아주 작은 기술적 실수만으로도 과도한 권한(Over-privileged)이 부여되거나, 반대로 필요한 처리가 동작하지 않게 될 수 있습니다.

따라서 IAM이나 인증 관련 사항은 Claude Code에게 초안을 만들게 하는 것은 좋더라도, 이 부분만큼은 특히 사람이 꼼꼼하게 확인해야 한다고 생각합니다.

Claude Code는 리포지토리 내의 정보를 읽어주지만, 프로젝트의 배경이나 사내 사정까지 완전히 이해하고 있는 것은 아닙니다.

예를 들어, 다음과 같은 암묵지(Tacit knowledge)에는 취약합니다.

• 왜 해당 방식으로 구현되었는가
• 과거 장애 대응 과정에서 들어간 임시 조치인가
• 고객 요구사항 때문에 의도적으로 그렇게 하고 있는가
• 운영 팀과의 약속 때문에 변경할 수 없는 부분인가

따라서 Claude Code의 제안이 기술적으로는 올바르게 보일지라도, 업무적으로는 변경해서는 안 되는 경우가 있습니다.

이 부분은 인간 측의 리뷰가 필요합니다. 베테랑 멤버가 없으면 힘든 부분이긴 합니다만...

Bedrock을 경유한다고 해서 무엇이든 입력해도 된다는 뜻은 아닙니다.

Claude Code에서는 리포지토리(Repository) 내의 파일, 로그, 설정값 등을 다루게 됩니다.

따라서 다음과 같은 정보가 포함되지 않도록 주의가 필요합니다.

• API 키
• 시크릿 (Secrets)
• 비밀번호 (Passwords)
• 개인정보 (PII)
• 고객명
• 운영 환경 (Production) 설정값
• 미공개 설계 정보

이는 도구의 문제라기보다 이용 규칙의 문제라고 생각합니다.

팀 단위로 도입할 경우에는 Claude Code에 입력해도 되는 정보와 피해야 할 정보를 미리 정해두는 것이 좋습니다.

특히 고객 기밀 정보를 다루는 경우에는 고객으로부터 AI 이용에 대한 합의 및 Bedrock으로의 데이터 입력에 대한 승인을 받아야 할 수도 있으므로, 이 점은 특히 주의해야 할 포인트입니다.

개인적으로 이용한다면 각자가 환경 변수 (Environment Variables)를 설정하면 됩니다.

하지만 팀 단위로 이용할 때는 각자가 제각각 설정하면 관리가 어려워집니다.

예를 들어, 어떤 사람은 Sonnet을 사용하고, 어떤 사람은 Haiku를 사용하며, 어떤 사람은 다른 리전 (Region)을 사용하는 상태가 되면 트러블슈팅 (Troubleshooting)이 번거로워집니다.

팀 이용 시에는 다음과 같은 항목을 통일해 두는 것이 좋다고 생각합니다.

항목	결정해 두어야 할 사항
AWS 계정	Claude Code용 계정을 분리할 것인지
...

개인적으로는 팀 이용 시 다음과 같은 구성이 다루기 쉽다고 생각합니다.

업무 시스템의 운영 계정과 Claude Code 이용 계정은 분리하는 것이 비용 및 권한 관리 관점에서 운영하기 수월할 것입니다.

한편, 여러 AI 도구와 여러 LLM 프로바이더 (Provider)를 횡단적으로 관리하고 싶다면, 다음과 같이 LiteLLM을 중간에 두는 구성도 고려할 수 있습니다.

물론 처음부터 이렇게까지 구축할 필요는 없다고 생각합니다.

우선 Bedrock을 직접 이용하며 작게 검증해 보고, 팀 도입이나 다중 도구 대응이 필요해진 단계에서 LiteLLM과 같은 게이트웨이 (Gateway) 구성을 검토하는 것이 현실적입니다.

마지막으로, 최소 구성으로 테스트하는 절차를 정리합니다.

Amazon Bedrock 콘솔에서 사용하고자 하는 Claude 모델을 활성화합니다.

aws sts get-caller-identity --profile bedrock-dev

SSO를 사용하는 경우, 필요에 따라 로그인합니다.

aws sso login --profile bedrock-dev

export AWS_PROFILE=bedrock-dev
export AWS_REGION=us-east-1
export CLAUDE_CODE_USE_BEDROCK=1

export ANTHROPIC_MODEL='us.anthropic.claude-sonnet-4-5-20250929-v1:0'

모델 ID는 환경에 따라 다르므로, 실제로 사용 가능한 값을 확인하십시오.

claude

/status

IAM 권한이 부족할 가능성이 있습니다.

확인해야 할 포인트는 다음과 같습니다.

• bedrock:InvokeModel이 허용되어 있는지
• bedrock:InvokeModelWithResponseStream이 허용되어 있는지
• 대상 모델 또는 추론 프로필 (Inference Profile)의 리소스 (Resource)가 허용되어 있는지
• SCP나 권한 경계 (Permission Boundary)에서 명시적으로 거부 (Deny)되어 있지 않은지

Bedrock 측에서 대상 모델이 활성화되지 않았을 가능성이 있습니다.

확인해야 할 포인트는 다음과 같습니다.

• Bedrock의 모델 액세스 (Model access)에서 대상 Claude 모델이 활성화되어 있는지
• 이용 중인 리전에서 대상 모델을 사용할 수 있는지
• 지정한 모델 ID가 올바른지
• 추론 프로필 (Inference Profile)이 필요한 모델은 아닌지

모델을 직접 지정했을 때 발생할 수 있습니다.

이 경우에는 추론 프로필 ID (Inference Profile ID)를 지정하면 해결될 가능성이 있습니다.

export ANTHROPIC_MODEL='us.anthropic.claude-sonnet-4-5-20250929-v1:0'

기업용 단말기나 프록시 (Proxy) 환경에서는 SSO 인증이 잘 되지 않을 수 있습니다.

그 경우에는 Claude Code를 실행하기 전에 수동으로 로그인합니다.

aws sso login --profile bedrock-dev

그 후, 동일한 프로필을 사용하여 Claude Code를 실행합니다.

export AWS_PROFILE=bedrock-dev
claude

LiteLLM과 같은 LLM Gateway를 사이에 두는 경우에는 Bedrock을 직접 이용할 때보다 확인해야 할 포인트가 늘어납니다.

예를 들어, 다음과 같은 관점입니다.

• Claude Code에서 LiteLLM Proxy에 도달할 수 있는가
• Claude Code가 기대하는 API 형식을 LiteLLM 측에서 처리할 수 있는가
• 인증 헤더(Authentication Header)나 요청 본문(Request Body)이 올바르게 중계되는가
• LiteLLM 측에 대상 모델이 정의되어 있는가
• LiteLLM에서 Bedrock을 호출하는 AWS 인증 정보가 올바른가
• 사용자의 Virtual Key에 대상 모델 이용 권한이 있는가

참고로, 이 부분은 별도의 기사로 정리할 계획입니다.

따라서 처음부터 LiteLLM을 도입하기보다는, 먼저 Bedrock 직접 이용을 통해 Claude Code가 작동하는 것을 확인한 후, 그 다음에 Gateway 구성으로 확장해 나가는 것이 문제 분리(Troubleshooting)를 하기 더 쉽다고 생각합니다.

Claude Code를 Amazon Bedrock을 통해 사용하면, 단순히 편리한 AI 코딩 에이전트를 사용할 수 있을 뿐만 아니라, AWS의 인증 및 권한 관리 체계로 통합할 수 있다는 점이 큰 장점입니다.

특히 업무용으로 사용할 때는 다음과 같은 관점이 중요합니다.

• 개인 API 키가 아닌 AWS 인증을 사용한다
• 사용할 리전(Region)을 명확히 한다
• 모델 ID나 추론 프로필(Inference Profile)을 명시한다
• 우선 작게 검증하고, 나중에 권한을 제한한다
• 팀 단위 이용 시에는 설정을 통일한다
• Claude Code에 입력해도 되는 정보의 규칙을 정한다
• 생성된 변경 사항은 반드시 사람이 리뷰한다
• 여러 LLM이나 여러 도구를 관리하고 싶다면 LiteLLM도 선택지에 넣는다

Claude Code는 코드를 작성하는 도구로서도 편리하지만, 개인적으로는 코드를 읽게 하거나, 조사 내용을 바탕으로 대화(Wall-hitting)를 나누거나, 문서화하는 등의 활용도가 매우 높다고 느끼고 있습니다.

반면, IAM, 인증, CI/CD, IaC와 같이 영향 범위가 큰 변경은 Claude Code의 제안을 그대로 적용하기보다, 사람이 차이점(Diff)을 확인한 후 반영하는 것이 좋다고 생각합니다.

Bedrock을 경유함으로써 Claude Code를 AWS의 관리 하에 사용하기 쉬워집니다.

우선 개인적인 검증부터 시작하여, 괜찮다고 판단되면 팀 이용을 위해 인증, 모델, 리전, 로그, 입력 규칙을 정리해 나가는 것이 현실적인 방법이 아닐까 합니다.

또한, Claude Code 이외의 AI 도구나 여러 LLM 프로바이더를 포함하여 관리하고 싶다면, LiteLLM과 같은 AI Gateway를 사이에 두는 구성도 검토할 수 있습니다.

다만, 그만큼 구성 요소가 늘어나므로 우선 Bedrock 직접 이용으로 작게 시도해 보고, 필요에 따라 Gateway 구성으로 확장하는 것이 좋다고 생각합니다.

Claude Code를 Amazon Bedrock을 통해 사용하기 위한 공식 문서입니다.

환경 변수, IAM 권한, 모델 지정, 트러블슈팅 등이 정리되어 있습니다.

Claude Code에서 LLM Gateway를 이용할 경우의 공식 문서입니다.

Gateway 요구 사항, 인증 설정, 모델 선택, 프로바이더별 엔드포인트 설정 등이 설명되어 있습니다.

LiteLLM의 공식 문서입니다.

LiteLLM Proxy, Python SDK, 여러 LLM 프로바이더의 통합 인터페이스에 대해 확인할 수 있습니다.

LiteLLM Proxy에서 Virtual Key를 사용하여 사용자별 지출(Spend) 및 모델 액세스를 관리하기 위한 공식 문서입니다.

LiteLLM에서 Amazon Bedrock을 호출하는 경우의 공식 문서입니다.

Amazon Bedrock의 추론 프로필(Inference Profile)에 관한 공식 문서입니다.

교차 리전 추론(Cross-region inference) 및 애플리케이션 추론 프로필(Application inference profile)에 관한 개념을 확인할 수 있습니다.

Amazon Bedrock의 추론 프로필에서 지원되는 리전 및 모델을 확인할 수 있습니다.

US, EU, APAC 등 지리적 경계를 의식한 교차 리전 추론에 관한 공식 문서입니다.

Qiita에서 Mermaid를 사용하여 도표를 표현하기 위한 참고 기사입니다.