어디에 배포하고, 어떤 버전을 고정할까

배포 플랫폼은 Claude 워크로드가 실제로 실행되는 환경입니다. 같은 모델이 여러 환경에서 실행될 수 있는데, 그중 어디를 고를지는 대개 고객이 이미 쓰는 클라우드가 정합니다. 이 결정은 기술적 우열만으로 정해지는 경우가 드뭅니다. 실무에서는 고객이 이미 클라우드 인프라·인증 관리·컴플라이언스(규제 준수) 계약을 어디에 갖추고 있는지가 더 크게 작용합니다.

그래서 첫 질문은 대개 "고객이 이미 신뢰하고 운영하는 플랫폼이 어디인가"입니다. 실행 환경은 크게 다음과 같이 나뉩니다.

• First-party Claude API — Anthropic의 자체 환경입니다. 새 기능이 보통 이곳에 가장 먼저 들어옵니다.
• Claude Platform on AWS — 고객의 AWS 계정을 통해 접근하지만, Anthropic의 모델 ID와 수명주기를 그대로 씁니다. 추론은 AWS 경계 밖에서 Anthropic이 운영합니다.
• Amazon Bedrock — 두 가지 연동이 있습니다. Claude in Amazon Bedrock/anthropic/v1/messages의 Messages API를 쓰는 최신 연동. first-party와 기능이 폭넓게 같다.은 /anthropic/v1/messages의 Messages API로 폭넓은 기능 동등성을 제공합니다. Claude on Amazon Bedrock(legacy)은 InvokeModel/Converse API에 ARN 버전 식별자를 씁니다.
• Google Vertex AI — Google Cloud 안에서 같은 역할을 합니다.
• 서드파티 플랫폼 — 고객이 이미 쓰는 제품 안에 Claude를 품는 형태입니다(예: Microsoft Foundry). Foundry는 Azure 호스팅(현재 Opus 4.8 · Sonnet 5 · Haiku 4.5, 추론이 전 구간 Azure에서 실행)과 Anthropic 호스팅(그 외 Foundry Claude 모델) 두 형태가 있습니다. 규제 고객의 레지던시는 어느 호스팅 형태를 쓰는 모델이냐에 따라 달라지므로, 호스팅 형태와 현재 모델 구성은 게시 시점에 Microsoft와 확인해 보는 것이 좋습니다.

누가 접근할 수 있고 데이터가 어디에 머무는지는 우리 코드가 아니라 플랫폼이 답합니다. 이 부분을 플랫폼에 맡길 수 있다는 점이, 규제가 있는 고객에게는 특히 중요합니다.

• Bedrock은 AWS 인증을 쓰고, 데이터를 고객의 AWS 경계 안에 유지합니다.
• Vertex는 Google Cloud 인증과 경계를 씁니다.
• 두 곳 모두 레지던시가 제약일 때 지역 라우팅(요청을 특정 지역으로 보내는 설정)을 제공합니다.

플랫폼을 고객이 이미 맺어 둔 컴플라이언스 계약에 맞추면, 데이터 레지던시 검토를 처음부터 다시 하지 않아도 됩니다. 이미 통과시킨 경계 안에서 실행하는 셈이라, 승인 절차가 크게 줄어듭니다.

여섯 환경을 한눈에 비교하면 선택 기준이 또렷해집니다. 아래 표는 각 플랫폼의 인증·데이터 모델, 언제 고르면 좋은지, 그리고 버전을 어떻게 고정하는지를 정리한 것입니다.

DEPLOYMENT PLATFORMS — 여섯 실행 환경 비교

플랫폼을 정했다면, 이 방식이 언제 잘 맞고 언제 부담이 되는지도 함께 가늠해 보면 좋습니다.

TRADE-OFFS — 언제 알맞고, 언제 부담이 되나

버전 관리는, 모델이나 프롬프트 변경이 모르는 사이에 프로덕션 동작을 바꾸는 일을 막아 줍니다. 모든 Claude 모델 ID는 특정 시점의 모델 스냅샷 하나를 가리킵니다.

Opus·Sonnet 같은 별칭은 쓰기 편하지만, 시간이 지나면 가리키는 실제 버전이 바뀌고 배포 플랫폼마다 다른 버전으로 풀리기도 합니다. 반면 전체 모델 버전을 적어 두면 고정된 스냅샷 하나로 풀립니다. 그래서 별칭 대신 구체적인 모델 버전을 고정해 두면, 상위 모델 쪽에서 업데이트가 올라올 때 그 변경을 직접 선택해 반영하게 됩니다. 고정하지 않으면 같은 업데이트가 우리 출력에 기록 없이 반영되어, 어느 순간 결과가 달라져 있는 상황을 만나기 쉽습니다.

ALIAS vs PINNED — 앞줄은 움직이는 별칭, 뒷줄은 고정된 스냅샷

# Pre-4.6 example: a convenience alias can resolve to a new
# version without you knowing
model = "claude-haiku-4-5"

# Pre-4.6 pinned snapshot: the version is fixed until you change this line
model = "claude-haiku-4-5-20251001"

Claude 4.6 이상에서는 모델 ID만으로 특정 스냅샷에 고정되고, 그 이전 모델은 ID에 날짜 접미사를 함께 붙입니다. 현재 규칙은 platform.claude.com에서 게시 시점에 확인해 보세요.

버전을 고정한 다음에는 프롬프트와 자산도 코드와 함께 버전으로 관리합니다. 그리고 이전 버전을 보관해 두면, 문제가 생겼을 때 롤백rollback — 문제가 생긴 버전을 이전의 정상 버전으로 되돌리는 것.으로 되돌릴 수 있습니다.

승격은 eval(평가 세트) 통과를 조건으로 겁니다. 새 버전을 트래픽 일부에 먼저 보내, 고정된 기준선(baseline)과 비교해 봅니다.

그 결과를 근거로 승격하거나 롤백합니다. 이 지점에서 eval은 한 번 실행하고 끝나는 시험이 아니라 배포 게이트(통과 관문)가 됩니다. 새 버전이 기준을 넘지 못하면 프로덕션에 올라가지 않으므로, 출력이 달라지는 변화를 사용자가 아니라 시험 단계에서 먼저 만나게 됩니다.

권장 버전을 가리키는 별칭에 맞춰 출시하면, 편리한 기본값으로 최신 모델을 공짜로 얻는 셈입니다. 한동안은 잘 동작합니다. 그러다 별칭이 다음 버전으로 넘어가면, 공짜였던 편의에 값이 붙습니다.

아래는 사고가 난 뒤 되짚어 볼 법한 프로덕션 로그의 일부입니다. 출력 형태가 바뀐 날과, 되돌릴 대상이 없었던 이유를 함께 보여 줍니다.

PRODUCTION LOG — 사고 직후 되짚어 보는 흔적

--: deploy: model="opus" status=ok
--: alias advanced -> new opus version (no app change)
--: parser: KeyError "summary" in response payload
--: Error: output shape changed; downstream parse failed
--: rollback attempted -> no pinned version retained
--: incident: hotfix parser; root cause = unpinned deployment

애플리케이션은 그대로였는데 별칭이 바뀌었습니다. 고정해 둔 이전 버전이 없어서 되돌릴 대상이 없었고, 핫픽스는 파서를 고쳤지만 고정하지 않은 배포는 그대로 남았습니다. 다음번 별칭이 또 움직이면 같은 사고가 반복될 수 있는 상태입니다.

한 고객이 AWS를 쓰고, 데이터 레지던시 요건이 있으며, 모델 업데이트를 롤백할 수 있어야 합니다. 이 두 조건을 만족하는 최소 구성을 조각별로 맞춰 봅니다. 필요 없는 조각은 빼면 됩니다.

원문은 네 그룹에서 조각을 하나씩 골라 맞추는 과제입니다. 여기서는 그룹별로 나눠 물어봅니다. 정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.