SageMaker와 Bedrock의 비교는 기술적인 비교가 아니다. 이것은 당신의 조직이 모델을 소유하는 일을 담당하는 사람들을 고용하고 있는지에 대한 질문이다. 모델 아티팩트를 훈련하고, 평가하고, 페이저 당직을 서는 팀이 있다면 SageMaker는 그 팀이 이미 하고 있는 일을 그대로 설명한다. 그런 팀이 없다면, 그리고 AI 기능을 출시하는 대부분의 회사는 그런 팀이 없는데, Bedrock은 타협안이 아니다. 그것은 당신의 조직도를 정확하게 읽어낸 결과다.

이 비교는 보통 기능 매트릭스로 진행된다. 통제권, 토큰당 비용, 모델 선택, 파인튜닝, 지연 시간. 이 항목들은 실재하지만 결국 부차적이다. 이 항목들 각각은 새벽 3시에 누가 그것을 떠맡을지에 따라 다르게 결론이 나는데, 이는 기술적 사실이 아니라 조직적 사실이다.

각 서비스가 실제로 당신에게 요구하는 것

마케팅을 걷어내고 보면 두 서비스가 요구하는 것은 매우 다르다.

Bedrock은 호출을 소유하라고 요구한다. API, 모델 ID, 그리고 청구서를 받는다. 프롬프트, 검색, 출력 평가, 비용에 대한 책임은 당신에게 있다. 용량, 하드웨어, 모델 업데이트, 가중치 배포에 대한 책임은 당신에게 없다. 작업의 단위는 요청이다.

SageMaker는 아티팩트를 소유하라고 요구한다. 당신이 책임지는 모델을 훈련하고, 튜닝하고, 호스팅하고, 모니터링할 인프라를 받는다. 훈련 데이터 계보, 릴리스를 게이트하는 평가 하네스, 엔드포인트의 인스턴스 플릿, 오토스케일링 정책, 드리프트 탐지, 그리고 새 버전을 롤아웃할지 여부를 결정하는 것까지 당신 소유다. 작업의 단위는 모델 버전이며, 모델 버전에는 소유자와 변경 이력과 롤백이 따라온다.

두 번째 목록은 하나의 직무다. 일회성 작업이 아니라 온콜이 딸린 상시 직무다. 질문은 그 직무가 오늘 당신의 회사에 실제로 존재하는가이다.

팀 토폴로지 논증

실제 조직을 세 가지 형태로 분류해 보자.

지능을 소비하는 제품 팀

이 팀은 기능을 출시한다. 누구의 직함에도 "모델"이라는 단어가 들어있지 않다. 로드맵에서 AI에 해당하는 부분은 "티켓 요약하기"와 "이 필드들 추출하기"다. 이런 형태의 팀에게는 Bedrock이 답이며, 그것도 압도적으로 그렇다. 이 팀에게 SageMaker 엔드포인트를 쥐여주는 것은 그들이 유지보수하지 않을 운영 표면을 쥐여주는 것과 같다. 아무도 읽지 않는 드리프트 모니터, 출시 시점에 사이징된 뒤 다시는 검토되지 않는 엔드포인트, 이해하던 유일한 사람이 팀을 옮기면 깨져버리는 훈련 파이프라인. 제품 팀에서 SageMaker가 실패하는 방식은 나쁜 모델이 아니다. 주인 없는 모델이다.

제품 팀에 서비스를 제공하는 플랫폼 팀

여기서는 플랫폼 팀이 게이트웨이, 쿼터, 평가 인프라, 비용 배분을 소유하고, 제품 팀은 프롬프트와 기능을 소유한다. 플랫폼 팀의 본능은 모델 소유가 자연스러운 다음 단계라고 생각하는 것이다. 대개는 그렇지 않다. 이들이 제공하는 진짜 가치는 제품 팀과 추론 사이의 이음매다. 라우팅, 키, 예산, 평가, 감사. 그 이음매는 Bedrock 위에 구축할 가치가 있으며, 이는 LLM Gateways: Why Every Platform Team Builds One Eventually에서 설명한 형태와 정확히 일치한다. SageMaker를 추가한다는 것은 이미 다른 여섯 팀의 병목인 팀에게 "우리가 모델도 운영한다"는 일을 하나 더 얹는 것이다.

이미 모델을 소유하고 있는 ML 팀

이 팀은 훈련 파이프라인, 피처 스토어, 모델 레지스트리, 그리고 이미 당직을 서고 있는 엔드포인트를 갖고 있다. 이들에게 SageMaker는 새로운 부담이 아니라 이미 짊어지고 있던 부담에 도구가 갖춰진 것뿐이다. 여기서 흥미로운 결정은 대개 둘 중 하나를 고르는 것이 아니라, 둘 다 운영하겠다고 인정하는 것이다. 제품 그 자체인 모델은 SageMaker로, 그 주변의 범용 언어 작업은 Bedrock으로. 실제 랭킹 모델을 운영하는 회사에서 커밋 요약문을 쓰기 위해 모델을 파인튜닝하는 사람이 있어서는 안 된다.

실제로 SageMaker를 강제하는 이유들

내 경험상 세 가지이며, 모두 구체적이다.

  • 모델 자체가 제품이거나 차별화 요소인 경우. 사기 스코어링, 랭킹, 예측 등, 당신의 가중치가 경쟁사가 살 수 없는 무언가를 담고 있는 모든 경우. 당신이 파는 것을 아웃소싱할 수는 없다.
  • 가중치나 데이터가 관리형 추론 API로는 충족할 수 없는 방식으로 당신이 통제하는 경계를 벗어날 수 없는 경우, 그리고 그 요구사항을 그저 되풀이한 게 아니라 실제로 읽어본 경우. 이 이유는 검증을 통과하는 경우보다 훨씬 자주 주장된다.
  • 아무도 대신 서빙해주지 않는 모델이 필요한 경우, 특정 오픈 가중치 체크포인트나 도메인에 맞춰 조정된 변형 모델이 필요하고, 가정이 아니라 호스팅된 옵션 대비 실제 격차를 측정해본 경우.

목록에 없는 것을 눈여겨보라. 비용이다. 셀프 호스팅은 높고 안정적인 활용률에서는 토큰당 비용이 더 저렴하고, 그 외 모든 경우에는 상당히 더 비싸다. 트래픽을 처리하든 안 하든 인스턴스 비용을 지불해야 하고, 이제는 용량 계획을 위한 인건비까지 지불해야 하기 때문이다. 비용 논거는 사실 활용률 논거가 변장한 것이며, 숫자가 붙기 전까지는 유효하지 않다.

이 결정이 보통 어떻게 잘못되는가

흔한 실패는 열망적인 조직을 위해 선택된 아키텍처다. 로드맵 슬라이드에 내년에 자체 모델을 만들 것이라고 적혀 있어서 팀이 SageMaker를 선택한다. 파이프라인을 만들고, 파인튜닝 하나를 출시하고, ML 팀의 인원은 끝내 채워지지 않고, 2년 뒤 어느 제품 엔지니어가 아무도 설명할 수 없는 엔드포인트의 인스턴스 타입을 조마조마하게 조정하고 있다. 기술에는 문제가 없었다. 그 기술이 전제로 삼았던 조직이 끝내 나타나지 않았을 뿐이다.

반대 방향의 실패도 존재하지만 더 가볍고 고치기 쉽다. Bedrock을 쓰던 팀이 자신들이 소유해야 하는 모델에 대한 진짜 필요를 발견하고, 그 워크로드 하나를 이전한다. 관리형 API에서 소유한 아티팩트로 워크로드 하나를 옮기는 것은 하나의 프로젝트다. 주인 없는 ML 플랫폼을 은퇴시키는 것은 고고학 발굴이다.

테스트

디자인 리뷰에서 질문 하나만 던져보라. 이 모델의 품질이 저하되면 누구에게 페이지가 가고, 그 사람은 무엇을 하는가?

답이 특정한 사람의 이름을 대고, 롤백을 게이트하는 평가 스위트를 설명하고, 그 사람의 매니저도 동의한다면, SageMaker는 당신에게 가능한 선택지다. 답이 "알아보겠습니다"이거나 아직 존재하지 않는 팀 이름을 댄다면, 당신은 방금 당신의 조직이 지능을 생산하는 게 아니라 소비한다는 사실을 발견한 것이다. 그것에 맞춰 지어라. 이것은 더 작은 야망이 아니라 더 정확한 야망이며, 이런 팀들을 묶는 제약은 거의 언제나 모델 소유권이 아니다. 그것은 평가이며, 어느 경로를 택하든 필요한 규율이고, 사실 두 경로 모두의 진짜 전제조건이라고 나는 주장하고 싶다.

핵심 정리

팀이 온콜과 평가 스위트를 갖추고 상시 책임으로 모델 아티팩트를 소유하고 있다면 SageMaker를 선택하라. 당신의 조직이 기능을 만들기 위해 모델 출력을 소비한다면, 즉 대부분의 조직이 대부분의 경우 그렇다면, Bedrock을 선택하라. 이 결정을 잘못 내렸을 때의 실패 양상은 나쁜 벤치마크가 아니다. 주인 없는 인프라이며, 이는 조용히 썩어가다가 요란하게 무너진다. 당신이 가진 조직도에 맞춰 선택하라.

다음으로 읽을 글

모델이 아니라 클러스터와 파이프라인을 누가 소유하는지를 다루는, 이 논증의 플랫폼 팀 버전은 ercan.cloud에 있다. 허브는 ercanermis.com이다.