플랫폼 비교 — 지연 시간, 컴플라이언스, 비용

플랫폼 선택은 세 가지 축에서 심사를 받습니다 — 지연 시간, 컴플라이언스, 비용. 먼저 지연 시간부터 봅니다. 지연 시간은 플랫폼이 고객으로부터 얼마나 가까이에서 운영되는지, 그리고 새 기능에 대한 접근이 어떻게 연결되는지에 따라 달라집니다.

고객이 쓰는 클라우드 리전 안에서 운영되는 플랫폼은, 멀리 떨어진 퍼스트파티 엔드포인트보다 왕복 시간을 줄일 수 있습니다. 대신 맞바꾸는 것이 하나 있습니다. 새 기능이 도달하는 시점입니다. Anthropic이 직접 운영하는 퍼스트파티 API는 보통 다른 플랫폼보다 새 기능을 먼저 받습니다.

여기서 중요한 것은 측정하는 위치입니다. 이 지연 시간 숫자는 고객의 실제 리전에서, 고객이 실제로 보내는 크기의 데이터로 재 봐야 정확합니다. 개발자 노트북에서 잰 값은, 작업이 고객이 있는 곳에서 실제로 실행될 때 생기는 왕복 지연을 감춥니다.

특히 Bedrock에서는 글로벌 엔드포인트와 리전 엔드포인트 중 무엇을 쓰는지가 데이터 소재지를 정하는 주된 장치이기도 하고, 비용에도 영향을 줍니다. 그래서 확정하기 전에 두 옵션 모두를 고객의 실제 리전에서 측정해 보는 것이 좋습니다.

컴플라이언스는 논의를 끝내는 축인 경우가 많습니다. 한 클라우드에서 이미 인증을 받아 둔 고객은, 다른 클라우드에서 다시 인증을 받으려 하지 않는 편입니다.

데이터 소재지(data residency)는 고객의 데이터가 특정 국가나 지역 안에서만 처리돼야 한다는 규칙입니다. 어떤 컴플라이언스 인증을 쓸 수 있는지, 그리고 접근 기록을 누가 감사할 수 있는지는 플랫폼마다 다릅니다. 금융이나 의료처럼 규제를 받는 고객은 이것들을 저울질할 트레이드오프가 아니라 통과 아니면 탈락(pass-or-fail)의 문제로 다룹니다.

구체적인 예를 보겠습니다. 퍼스트파티 Claude API는 EU 데이터 소재지를 제공하지 않을 수 있으므로, 현재 어떤 리전을 지원하는지 platform.claude.com에서 확인해야 합니다. EU 지역만으로 처리를 한정해야 한다면 보통 Bedrock이나 Vertex AI가 필요합니다. Microsoft Foundry 같은 서드파티 플랫폼에서는 호스팅이 모델별로 갈립니다. Azure에 호스팅된 Foundry 모델은 추론 전 과정을 Azure 인프라에서 처리하지만, Anthropic이 호스팅하는 Foundry 모델은 EU 리전 소재지 요건을 충족하지 못합니다. 그래서 소재지는 모델과 배포 방식별로 Microsoft에 확인해 둘 필요가 있습니다.

이 제약은 범위를 잡는 단계scoping — 프로젝트에서 무엇을 어디까지 할지, 어떤 요건을 만족해야 하는지 앞단에서 정하는 단계.에서 미리 꺼내 두는 것이 좋습니다. 그러지 않으면 작업이 다 끝난 뒤 계약 검토 단계에서 드러납니다.

토큰 단가는 플랫폼 사이에 대체로 비슷하게 맞춰져 있습니다. 총비용을 움직이는 것은 단가가 아니라 이그레스(데이터를 클라우드 밖으로 내보내는 전송 비용), 플랫폼 수수료, 그리고 연동에 드는 노력입니다.

토큰 값이 더 싼 플랫폼이, 데이터 전송과 연동 비용까지 더하고 나면 총액에서 오히려 더 비싸질 수 있습니다. 그래서 플랫폼마다 호출 한 번당 비용을 실제로 재 보고, 최신 요금표는 범위를 잡는 단계에서 확인해 두는 것이 좋습니다.

지금까지 본 세 축을, 플랫폼을 고를 때 그대로 대 볼 수 있게 한 표로 정리하면 다음과 같습니다.

LATENCY · COMPLIANCE · COST — 교차 플랫폼 비교 기준

세 축을 플랫폼마다 실제로 측정해 두면, 무엇을 얻고 무엇을 치르는지, 그리고 언제 이 비교 자체를 건너뛰어도 되는지가 정리됩니다.

WHEN IT FITS · WHAT IT ADDS · WHEN TO SKIP — 판단 기준

마감이 다가오는데 마이그레이션이 쉬워 보여서, 팀이 이미 익숙한 플랫폼을 골랐습니다. 빌드 자체는 문제없이 됐습니다. 문제는 ‘빌드하기 쉬운 것’과 ‘출시해도 되는 것’이 서로 다른 기준이라는 데 있었습니다.

아래는 검토가 어긋난 뒤 개발자가 동료에게 들려줄 법한 이야기입니다. 누가 그것을 실수라고 짚기 전에, 친숙한 플랫폼의 함정을 먼저 보게 해 줍니다.

규제를 받는 고객을 상대로 개발하던 한 개발자가, 팀이 전에 출시해 본 적 있는 플랫폼을 골랐습니다. 팀이 그 도구와 리소스를 잘 알고 있었기 때문에 연동은 빠르게 완성됐고, 기능 테스트도 통과했습니다. 그런데 고객의 보안 검토에서 검토자가 데이터가 어디에서 처리되는지를 물었습니다. 선택한 플랫폼은 고객의 데이터 소재지 요건을 충족하지 못했습니다. 팀이 덜 익숙했던 다른 플랫폼이라면, 고객이 이미 승인해 둔 리전 배포 옵션으로 그 요건을 충족했을 것입니다. 결국 그 배치는 반려됐고, 연동은 소재지 요건을 만족하는 플랫폼 위에서 처음부터 다시 만들어야 했습니다.

친숙함을 기준으로 고른 것이 엉뚱한 시험에 맞춘 선택이었습니다. 쉬운 마이그레이션은 ‘팀이 빠르게 빌드할 수 있는가’라는 질문에는 답했지만, ‘이 배포가 고객의 소재지 검토를 통과할 수 있는가’라는 질문에는 답하지 못했습니다. 그런데 출시 여부를 실제로 가른 것은 뒤쪽 질문이었습니다. 컴플라이언스 요건을 범위 잡는 단계에서 확인하지 않은 탓에, 그 문제가 출시 여부를 판단하는 검토go/no-go — 빌드한 결과를 실제로 출시할지 말지 최종 판단하는 검토 단계.에서야 드러났습니다. 빌드가 이미 끝난 뒤라, 이곳은 그 문제를 발견하기에 가장 비싼 자리입니다.

직접 진단해 볼 차례입니다. 아래 비교 기록은 친숙하다는 이유로 고른 배포 플랫폼이 고객 요건에서 막힌 상황을 보여 줍니다. 어디에서 어긋났는지 짚어 본 다음, 세 보기 중 맞는 처방을 골라 보세요.

THE TRACE — 비교 기록

platform_selected = "team_default"   # 친숙하다는 이유로 선택
latency_test: measured from dev laptop -> 180ms (문제없어 보임)
customer_region: eu-west, payload 12 KB
compliance_check: data residency = EU-only required
result: REJECTED  reason="data processed outside EU on selected platform"

정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.