SageMaker AI 트레이닝 세션, GPU 관리 없이 개발자에게 맞춤형 루프 제공

Amazon이 SageMaker AI 트레이닝 세션을 정식 출시했다. 이를 통해 개발자는 GPU 인프라를 선택하거나 운영하지 않고도 맞춤형 모델 학습 루프를 작성할 수 있다. 2026년 10월 22일 발표된 이 서비스는 알고리즘 설계와 하드웨어 관리를 분리한다. 개발자는 모델의 학습 방식을 계속 통제하고, AWS는 기반 컴퓨팅 실행을 담당한다.

이는 표준 미세 조정 방식으로는 실험 요구를 충족하기 어려워진 팀이 마주하는 선택지를 바꾼다. 이전에는 더 큰 통제권을 얻으려면 더 많은 인프라 작업을 감수해야 하는 경우가 많았다. Amazon은 이제 그 중간 경로를 제시한다. 개발자는 API, 즉 자신의 코드를 서비스에 연결하는 프로그래밍 인터페이스를 통해 개별 학습 작업을 조정한다. 실험의 주도권은 여전히 개발자에게 있다.

Thinking Machines Lab의 Tinker 역시 학습 로직과 관리형 컴퓨팅을 분리한다는 점에서 유용한 비교 대상이다. 더 큰 경쟁의 핵심은 플랫폼이 그 경계를 어디에 설정하느냐에 있다. 개발자에게 실질적인 질문은 서비스가 실제 워크로드에 필요한 통제권을 유지하면서 운영 작업을 덜어 주는지 여부다.

SageMaker AI 트레이닝 세션이 실제로 바꾸는 것

이번 출시는 관리형 서비스의 경계를 학습 레시피 아래 단계로 낮춰, 개발자가 개별 학습 작업을 통제할 수 있게 한다.

모델 맞춤화는 모델을 처음부터 구축하는 대신 특정 작업에 맞게 기존 모델을 변경하는 작업이다. 사후 학습은 초기 학습이 끝난 모델을 추가로 조정하는 것을 의미한다. 새 서비스는 이러한 조정 단계의 순서를 개발자가 직접 결정해야 하는 경우를 겨냥한다.

Amazon의 트레이닝 세션 출시 발표는 정식 출시를 기존 서버리스 모델 맞춤화 서비스의 확장으로 설명한다. 여기서 서버리스란 AWS가 컴퓨팅 리소스를 관리한다는 뜻이다. 고성능 모델 계산에 사용되는 프로세서인 GPU는 계속 사용되지만, 고객이 직접 선택하고 운영할 필요는 없다.

이 구분은 관리형 레시피와 관리형 트레이닝 세션이 서로 다른 형태의 통제권을 제공하기 때문에 중요하다. 레시피는 사용자가 지원되는 절차를 구성하도록 한다. 세션은 개발자가 그 절차를 이루는 작업을 조정할 수 있게 하며, 중간 결과를 바탕으로 한 결정도 포함한다.

불필요한 도구 호출에 대해 에이전트가 더 큰 페널티를 받아야 하는지 시험하는 팀을 생각해 보자. 에이전트는 모델을 사용해 행동을 선택하는 소프트웨어다. 이 팀은 해당 행동을 측정하고 그 결과를 학습으로 전환하는 방식을 통제해야 한다.

이 팀은 모델이 개선됨에 따라 학습 데이터도 바꿀 수 있다. 초기 사례에서는 올바른 도구 선택에 보상을 주고, 이후 사례에서는 더 긴 작업을 완료하는 데 중점을 둘 수 있다. 이는 보고된 고객 사례가 아니라 설명을 위한 실험 설계다. 절차 수준의 통제권이 왜 중요한지를 보여 준다.

실험 자체가 실행 중 바뀌면 고정된 워크플로는 제약이 될 수 있다. 그러면 개발자는 더 구성 가능한 환경으로 이동해야 한다는 압박을 받는다. 그에 따른 인프라 작업은 원래의 연구 질문에서 주의를 분산시킬 수 있다.

SageMaker AI 트레이닝 세션은 개발자가 직접 조합하는 더 작은 작업 단위를 통해 이 공백을 해결한다. 이는 자동적인 모델 개선보다 범위가 좁은 약속이다. AWS는 실행을 관리하지만, 학습 프로세스를 실행할 가치가 있는지는 고객이 판단한다.

이 분업은 이번 출시가 누구를 위한 것인지도 분명히 한다. 표준 맞춤화 워크플로에 만족하는 팀은 추가 책임을 떠안을 이유가 적다. 반면 독특한 목표, 변화하는 커리큘럼 또는 상호작용형 에이전트를 다루는 팀은 검토할 이유가 더 명확하다.

따라서 이번 발표는 기존의 모든 학습 옵션을 대체하기보다, 사용할 수 있는 운영 모델을 확장한다. 그 의미는 동일한 수준의 하드웨어 소유 부담 없이 맞춤형 절차에 접근할 수 있게 했다는 데 있다.

맞춤형 학습은 실험에 더 큰 책임을 부여한다

클러스터 관리가 사라지면 학습 목표의 품질이 프로젝트에서 더욱 핵심적인 요소가 된다.

강화 학습은 모델의 출력 또는 행동에 관한 피드백을 사용해 모델을 학습시키는 방식이다. 보상 신호는 학습 과정이 어떤 결과를 선호해야 하는지를 표현한다. 다른 기업이 모든 GPU 작업을 수행하더라도, 이 신호를 설계하는 책임은 고객에게 남는다.

이 책임은 에이전트가 평가를 받기 전 여러 차례 상호작용하는 다중 턴 강화 학습에서 특히 뚜렷해진다. 성공적인 중간 응답이 전체 작업의 성공을 반드시 의미하지는 않는다. 학습은 기업이 실제로 필요로 하는 결과를 반영해야 한다.

기록을 검색한 뒤 해결책을 제안하는 가상의 지원 에이전트를 예로 들어 보자. 답변 생성만을 기준으로 보상하면 성급한 응답을 조장할 수 있다. 실수 회피만을 기준으로 보상하면 불필요한 에스컬레이션을 조장할 수 있다.

인프라 접근성이 좋아진다고 해서 어느 문제도 사라지지는 않는다. 개발자는 정확한 답변, 적절한 불확실성 표현, 유용한 에스컬레이션 사이의 균형을 결정해야 한다. 이러한 결정은 기술적 선호만큼이나 제품 정책을 담아낸다.

따라서 즉각적인 부담은 머신러닝 팀과 성공 기준을 정의하는 사람들에게 돌아간다. 제품 책임자는 허용 가능한 행동을 설명해야 한다. 도메인 전문가는 의미 있는 실패를 식별해야 한다. 엔지니어는 이러한 판단을 반복 가능한 평가로 전환해야 한다.

이는 기술 출시와 함께 주목할 만한 조직적 결과를 낳는다. 기업은 컴퓨팅 운영을 외부에 맡길 수 있지만, 좋은 성능의 의미에 대한 합의까지 외주화할 수는 없다. 그 정의를 둘러싼 이견은 인프라가 더 이상 병목이 아닌 상황에서도 프로젝트를 멈추게 할 수 있다.

원하는 응답의 사례를 사용해 모델을 학습시키는 지도 미세 조정에도 같은 문제가 적용된다. 실행 환경이 개선되어도 일관되지 않은 행동을 가르치는 사례를 바로잡을 수는 없다. 맞춤형 루프는 팀에 개입할 기회를 더 많이 제공하지만, 동시에 일관성을 해칠 기회도 더 많이 제공한다.

정의된 기준에 따라 모델 행동을 측정하는 과정인 평가는 실험과 배포 결정 사이의 다리가 된다. 팀은 개선이 학습에 사용된 사례를 넘어선다는 증거를 필요로 한다. 그렇지 않으면 학습 점수의 상승은 제한적인 안심만 제공한다.

이 지점에서 엔지니어링 지식 관리도 관련성을 갖는다. 데이터세트 변경, 실패한 실험, 평가 결정을 검색 가능한 형태로 기록하면 팀은 행동이 왜 달라졌는지 이해할 수 있다. 엔지니어링 지식 기반에 관한 자료는 이러한 보조 워크플로를 다룬다.

문서화는 실험적 증거를 대체하지 않는다. 대신 그 증거를 해석하고 검토하기 쉽게 만든다. 명확한 이력이 없으면 팀은 새로운 것을 시험한다고 생각하면서도 실패한 접근법을 반복할 수 있다.

실질적인 기회는 특정 가설을 더 빠르게 검토하는 데 있다. 이에 상응하는 의무는 실패한 결과에서도 무언가를 배울 수 있을 만큼 그 가설을 명확히 정의하는 것이다.

이 메커니즘은 학습 결정과 GPU 실행을 분리한다

개발자가 학습 과정을 조정하고, 서비스는 모델을 변경하고 시험하는 계산 작업을 수행한다.

AWS의 학습 루프 아키텍처는 상태 유지형 세션을 설명한다. 이는 서비스가 호출 간 모델 상태를 보존한다는 의미다. 고객 코드가 연속된 작업을 조정하는 동안 모델은 로드된 상태로 유지된다. 따라서 각 학습 단계를 서로 무관한 작업으로 취급하지 않아도 된다.

이 아키텍처는 응답 생성과 모델 업데이트를 분리한다. 샘플링은 현재 모델에서 후보 출력을 생성하는 것을 의미한다. 고객 코드는 다음 학습 작업을 요청하기 전에 해당 출력을 평가할 수 있다.

손실 함수는 학습 행동을 최적화가 줄이려는 목표로 변환한다. 그래디언트는 그 목표를 개선하기 위해 모델 매개변수가 어떻게 바뀌어야 하는지를 나타낸다. 고객이 순전파 및 역전파 작업을 요청하면 서비스가 이러한 그래디언트를 계산한다.

그다음 옵티마이저는 누적된 그래디언트를 사용해 모델 가중치, 즉 모델 행동을 좌우하는 학습된 수치 값을 업데이트한다. 개발자는 이 업데이트가 발생할 시점을 결정한다. 또한 루프는 업데이트된 모델을 사용해 새 응답을 생성할 시점도 결정한다.

핵심은 이 순서에 있다. 팀은 출력을 검토하고, 자체 평가 로직을 적용하며, 다음에 일어날 일을 결정할 수 있다. 이제 플랫폼은 지원되는 모든 실험을 완전한 엔드투엔드 레시피로 패키징할 필요가 없다.

Amazon은 수학적 추론 및 프로그래밍 작업으로 이 접근법을 설명한다. 이러한 사례는 매력적인 특성을 지닌다. 소프트웨어가 답을 확인하거나 테스트를 실행할 수 있기 때문이다. 이는 생성된 출력과 측정 가능한 피드백 사이에 구체적인 연결을 제공한다.

비즈니스 작업은 그보다 편리한 채점 규칙을 갖지 못하는 경우가 많다. 응답은 형식 검사를 통과하면서도 오해를 불러일으키거나 도움이 되지 않을 수 있다. 이 메커니즘은 개발자가 그러한 차이를 표현할 수 있는 곳을 제공하지만, 어떤 차이가 옳은지는 결정하지 않는다.

운영상의 경계는 경제성에도 영향을 미친다. AWS는 GPU 의존 작업에 토큰 기반 과금이 적용된다고 설명하며, 토큰은 모델이 처리하거나 생성하는 텍스트 단위를 나타낸다. 로컬 보상 계산이 실행되는 동안에는 GPU 사용 요금이 발생하지 않는다.

이 구조는 모델 작업 사이에 상당한 작업이 필요한 실험에서 중요하다. 그러나 GPU 사용량 측정이 멈춘다고 해서 다른 프로젝트 비용까지 없어지는 것은 아니다. 고객이 운영하는 평가 시스템, 엔지니어링 시간, 저장된 아티팩트에도 여전히 주의가 필요하다.

따라서 유용한 비교 기준은 허용 가능한 수준으로 완료된 전체 실험이다. 학습 작업 하나만 보면 반복 샘플링, 실패한 실행 또는 비용이 큰 평가 작업을 놓칠 수 있다. 팀은 개별 서비스 작업이 아니라 동등한 결과를 비교해야 한다.

이후 복구를 위해 진행 상황을 저장하는 체크포인팅은 명시적인 선택이 여전히 필요함을 보여 준다. AWS의 학습 작업 참조 문서는 모델 가중치 내보내기와 학습 상태 저장을 구분한다. 이 아티팩트들은 서로 다른 목적을 수행한다.

참조 문서는 가중치만 복원하는 것과 옵티마이저 상태를 포함해 가중치를 복원하는 것도 구분한다. 이 차이는 팀이 중단된 실험을 이어서 진행하려 할 때 중요하다. 모델이 성공적으로 로드되었다고 해서 반드시 동일한 학습 프로세스가 재개된 것은 아니다.

구매자는 이 아키텍처를 더 정교한 역할 분담으로 해석해야 한다. AWS는 부담이 큰 실행 작업을 맡는다. 개발자는 순서 구성, 목표, 평가, 성공적인 결과의 의미에 대한 책임을 유지한다.

Tinker는 경쟁의 핵심이 통제 경계에 있음을 보여 준다

Amazon은 다른 기업이 운영하는 인프라를 기반으로 한 프로그래밍 가능한 학습이라는 익숙한 제품 범주에 진입하고 있다.

Thinking Machines Lab은 training API documentation에서 유사한 역할 분담을 설명합니다. 개발자는 학습 루프와 손실 함수를 작성하고, 서비스는 분산 컴퓨팅을 처리합니다. 따라서 Tinker는 이 범주를 이해하는 데 참고할 만한 비교 대상입니다.

분산 컴퓨팅은 많은 작업을 여러 프로세서나 머신에 나누어 처리합니다. 이를 직접 관리하려면 실험 자체와 별개로 조정과 복구 작업이 필요할 수 있습니다. 두 서비스 모두 학습 작업은 노출하면서 개발자를 그러한 운영 계층으로부터 보호하는 것을 목표로 합니다.

유사성이 상호 대체 가능성을 입증하는 것은 아닙니다. 비슷한 작업 명칭이 동일한 동작, 지원 모델, 아티팩트 형식 또는 장애 처리 방식을 보장하지는 않습니다. 이전을 고려하는 팀은 실제로 수행하려는 실험을 기준으로 이러한 세부 사항을 검토해야 합니다.

Tinker의 문서는 추가된 더 적은 수의 파라미터를 학습하는 저랭크 적응, 즉 LoRA 지원을 설명합니다. 또한 이 방식을 기본 모델의 파라미터를 더 폭넓게 업데이트하는 전체 파인튜닝과 구분합니다. 구매자는 워크플로 수준에서 문서화된 기능을 비교해야 합니다.

이는 특히 제품군이 특정 API 경로에서 제공하는 것보다 더 많은 기법을 지원할 때 중요합니다. 광범위한 커스터마이징 옵션에 관한 발표가 모든 조합이 모든 인터페이스에서 작동함을 입증하지는 않습니다. 조달 및 엔지니어링 검토는 그 경계에서 만나야 합니다.

기존 AWS 고객에게는 익숙한 운영 프로세스가 Amazon의 방식을 고려할 만한 그럴듯한 이유가 될 수 있습니다. 이는 더 우수한 학습 결과의 증거가 아니라 구매자 유인에 대한 평가입니다. 친숙함은 모델이 더 빠르게 개선된다는 증명 없이도 조직 내 마찰을 줄일 수 있습니다.

연구팀에는 다른 서비스의 모델 선택이나 프로그래밍 방식이 더 중요할 수 있습니다. 플랫폼은 실험을 지원할 때에만 유용합니다. 개발자가 연구하려던 동작을 포기하도록 단순화해야 한다면 편의성의 가치는 떨어집니다.

경쟁 압력은 내부 플랫폼 팀에도 미칩니다. 관리형 서비스가 필요한 절차를 지원한다면, 동등한 인프라를 계속 운영할 구체적인 이유가 필요합니다. 그 이유는 미지원 모델, 특수한 실행 방식 또는 환경에 대한 더 엄격한 제어와 관련될 수 있습니다.

반대로 관리형 플랫폼은 실제 운영 성능으로 그 가치를 입증해야 합니다. 복구 동작, 디버깅 또는 아티팩트 처리가 다른 곳에서 새로운 작업을 만든다면 깔끔한 인터페이스만으로는 충분하지 않습니다. 팀은 추상화를 자동적인 이점으로 간주하기보다 이러한 결과를 평가해야 합니다.

핵심 경쟁 구도는 여전히 맞춤형 알고리즘 제어와 인프라 책임 사이에 있습니다. 기업 간 비교는 가능한 경로를 밝히는 데 도움이 되지만, 그 결정을 대체해서는 안 됩니다. 적절한 경계는 팀이 자유가 필요한 지점과 위임의 이점을 얻는 지점에 따라 달라집니다.

여기서 검토한 자료에는 승자를 확정하는 검증된 정면 성능 비교 결과가 없습니다. 정당한 결론은 개발자에게 프로그래밍 가능한 학습을 위한 또 하나의 관리형 경로가 생겼다는 것입니다.

서버리스 학습에도 신중한 프로덕션 검토가 필요하다

관리형 학습 서비스는 운영 책임을 줄여 주지만, 모델 품질, 애플리케이션 안전성 또는 모든 워크로드 지원을 보장하지는 않습니다.

이용 가능한 출처는 서비스의 존재와 설계를 뒷받침합니다. 그러나 특정 고객이 더 높은 정확도, 더 낮은 총비용 또는 더 빠른 프로덕션 승인에 도달한다는 사실은 입증하지 않습니다. 이러한 결과는 워크로드와 평가 방법에 따라 달라집니다.

AWS는 의료 청구 거절 분류와 에이전트 도구 사용에 관한 고객 사례를 소개합니다. 이는 의도된 활용 사례를 설명하는 데 유용하지만, 여전히 공급업체가 게시한 추천 사례입니다. 독립적인 비교 평가로 취급해서는 안 됩니다.

의료 사례에서는 이 구분이 특히 중요합니다. 기술적으로 성공한 실험이 시스템이 중요한 의사결정에 적합함을 입증하지는 않습니다. 조직은 여전히 오류, 사람의 검토, 허용 가능한 사용에 대한 기준을 마련해야 합니다.

지식 그래프 에이전트는 다른 평가 문제를 제시합니다. 지식 그래프는 구조화된 질의를 위해 엔터티와 그 관계를 저장합니다. 학습 개선은 단지 그 구조에 대해 유효한 호출을 생성하는 데 그치지 않고, 유용한 작업 완료로 나타나야 합니다.

이러한 사례는 더 광범위한 검증 공백을 가리킵니다. 구매자는 보고된 개선이 모델이 학습 중 접하지 않은 사례에서도 유지되는지 알아야 합니다. 또한 핵심 지표가 개선된 뒤에도 어떤 실패가 남는지 이해해야 합니다.

가용성 역시 검증이 필요합니다. 검토 시점에 출시 발표와 AWS의 session availability documentation는 동일한 모델 목록을 제시하지 않았습니다. 이 불일치는 작업을 확정하기 전에 대상 모델과 리전을 확인해야 할 근거가 됩니다.

문서는 조정 가능한 동시성 할당량도 나열합니다. 따라서 서버리스 인터페이스가 무제한 동시 실험을 의미하지는 않습니다. 병렬 연구를 계획하는 팀은 사용 가능한 한도가 의도한 운영 패턴에 맞는지 확인해야 합니다.

운영상의 정확성은 여전히 또 다른 고객의 관심사입니다. AWS의 문제 해결 가이드는 샘플링 클라이언트를 적절히 새로 고치지 않으면 샘플링에 오래된 모델 가중치가 사용될 수 있다고 경고합니다. 따라서 서비스가 요청된 작업을 성공적으로 실행하더라도 실험은 잘못 동작할 수 있습니다.

이는 실제 환경에서 경계를 보여 주는 유용한 예입니다. 인프라 신뢰성은 플랫폼이 작업을 수행하는지에 관한 문제입니다. 실험의 정확성은 개발자가 올바른 상태에 대해 올바른 작업을 요청했는지에 관한 문제입니다.

보안도 유사한 구분을 따릅니다. AWS의 보안 가이드는 공동 책임 모델을 유지합니다. AWS는 자체 인프라를 보호하고, 고객은 데이터와 요구사항에 연계된 책임을 계속 집니다. 관리형 실행이 민감한 정보에 대한 포괄적 승인을 부여하지는 않습니다.

팀은 평가 중 사용되는 외부 도구도 검토해야 합니다. 학습 아티팩트가 승인된 환경에 남아 있더라도 보상 프로세스는 정보를 학습 서비스 외부로 전송할 수 있습니다. 단일 구성 요소의 위치보다 전체 데이터 경로가 더 중요합니다.

따라서 신중한 평가는 실패한 조건도 포함해야 합니다. 중단, 모호한 보상, 비정상적인 입력 및 내보내기 요구사항은 추상화가 프로젝트에 맞는지를 드러냅니다. 이는 프로그래밍 가능한 서비스를 평가하는 일반적인 요소입니다.

이 발표는 다른 운영 모델을 시험할 신뢰할 만한 이유를 제공합니다. 그러나 맞춤형 모델을 프로덕션으로 옮기는 데 필요한 증거를 건너뛸 근거는 되지 않습니다.

정식 출시 이후 주목할 점

가장 강력한 증거는 재현 가능한 고객 결과, 더 명확한 기능 문서, 그리고 데모를 넘어선 성공적인 운영에서 나올 것입니다.

첫 번째 신호는 프로덕션 지향 사용자의 상세한 보고입니다. 유용한 증거는 작업, 시작 모델, 평가 방법 및 커스터마이징 후의 동작을 식별해야 합니다. 개선 사항과 함께 실패도 설명하여 독자가 결과의 전이 가능성을 판단할 수 있어야 합니다.

설정이 더 쉬워졌다고만 보고하는 고객 사례는 운영상의 약속을 뒷받침할 수 있습니다. 지속적인 작업 성능 향상까지 문서화하는 사례는 더 폭넓은 도입 근거를 뒷받침할 수 있습니다. 이들은 별개의 주장이고 각각 별도의 증거가 필요합니다.

가장 유익한 비교는 작업과 평가 기준을 일정하게 유지합니다. 그렇지 않으면 데이터셋이나 성공 정의의 차이가 서비스 간 차이를 압도할 수 있습니다. 다른 워크로드에서 나온 유리한 결과는 구매자 자신의 결정을 확정할 수 없습니다.

두 번째 신호는 발표와 기능 문서 간의 더 명확한 정렬입니다. 구매자는 모델 지원, 지역별 가용성 및 학습 옵션을 함께 쉽게 확인할 수 있게 되는지를 지켜봐야 합니다. 더 나은 명확성은 실험 시작 전의 불확실성을 줄일 것입니다.

확장만이 유일하게 관련 있는 발전은 아닙니다. 더 작더라도 일관되게 문서화된 지원 워크플로 세트는 범위는 넓지만 모호한 제공 방식보다 도입하기 쉬울 수 있습니다. 가치는 팀이 무엇을 신뢰할 수 있는지 아는 데 있습니다.

프로그래밍 모델이 안정적으로 유지되는 가운데 지원이 확대된다면 재사용 가능한 실험 코드의 근거는 강화됩니다. 중요한 절차에 빈번한 특수 사례가 필요하다면 공통 인터페이스의 이점은 설득력이 약해집니다.

세 번째 신호는 일반적인 운영 압력 속에서도 복구 및 배포 워크플로가 견고하게 작동한다는 증거입니다. 성공적인 데모는 중단과 어색한 인계를 피할 수 있습니다. 프로덕션 지향 작업은 둘 모두를 마주하므로 이러한 전환은 중요한 증거가 됩니다.

팀은 저장된 실험이 의도대로 재개되는지, 그리고 생성된 아티팩트가 배포 프로세스에 통합되는지를 확인해야 합니다. 또한 장애를 설명하는 데 필요한 작업량도 검토해야 합니다. 문제 해결 노력은 운영 비용 절감 평가에 포함되어야 합니다.

이러한 영역에서 성공적인 결과가 나온다면 Amazon의 핵심 제안은 강화될 것입니다. 즉, 개발자는 의미 있는 알고리즘 자유도를 유지하면서 GPU 운영을 위임할 수 있습니다. 지속적인 공백은 서비스의 유용성을 현재의 경계에 맞는 워크로드로 제한할 것입니다.

SageMaker AI training sessions를 평가하는 독자에게 다음 단계는 맞춤형 제어가 필요한 구체적인 이유를 가진 범위가 정해진 실험입니다. 이미 신뢰하는 평가 방식을 갖춘 작업을 선택하세요. 시작 동작, 의도한 개선 사항, 그리고 배포를 수용할 수 없게 만드는 조건을 기록하세요.

그런 다음 평가, 복구 및 아티팩트 처리를 포함해 전체 워크플로를 기존 방식과 비교하세요. 비교 전반에 걸쳐 동일한 성공 기준을 유지하세요. 결정은 팀이 실제로 수행해야 하는 작업에 관한 증거를 따라야 합니다.

SageMaker AI training sessions를 도입하기 전에, 관리형 레시피가 팀이 내리지 못하게 하는 정확한 학습 결정을 식별해 보세요. 그 결정을 사용해 시험을 구성하세요. 새 인터페이스는 그 자유를 보존하면서 이를 실행하는 데 필요한 운영 작업을 줄여 주는가?