Govern models with MLflow and Amazon SageMaker AI Model Registry sync: Part 2

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

MLflow와 Amazon SageMaker AI Model Registry의 자동 등록을 다중 계정으로 확장하는 중앙 거버넌스 및 하이브리드 거버넌스 구조와 각 구조의 접근 권한·승인·모델 배포 흐름을 설명한다.

📌 핵심 요약

• Part 1의 단일 계정 자동 모델 등록과 IAM 조건 키 기반 역할 분리를 바탕으로, 개발 계정과 거버넌스 허브 계정을 분리하는 두 가지 구조를 제시한다.
• 중앙 거버넌스 구조는 AWS RAM으로 허브의 MLflow 앱을 개발 계정에 공유한다. 개발 계정의 등록 호출과 동시에 허브의 Model Registry에 모델 버전이 생성되며, 허브의 중앙 승인 후 CI/CD를 통해 개발 계정의 엔드포인트에 배포한다.
• 중앙 거버넌스에서는 허브 아티팩트 버킷의 교차 계정 S3 권한과 Model Package Group의 AllowDeploy 공유가 필요하다. 그룹 이름에는 짧은 해시 접미사가 붙으며, 허브에 기록된 계보 정보는 AWS RAM으로 개발 계정에 자동 공유되지 않는다.
• 하이브리드 거버넌스에서는 데이터 과학자가 개발 계정의 MLflow와 Model Registry만 사용한다. 모델 소유자의 로컬 승인이 복사 흐름을 촉발하고, 이 흐름은 아티팩트를 허브 소유 버킷으로 복제하고 추론 명세를 수정해 허브에 모델 패키지를 등록한다.
• 하이브리드 구조의 허브 패키지는 원본 패키지 ARN과 계정을 출처 메타데이터로 기록하고 개발 계정에 대한 런타임 의존성을 제거한다. 허브 거버넌스 담당자는 이를 독립적으로 재검증·승인하며, 개발 계정에서는 로컬 승인 모델을 교차 계정 아티팩트 없이 배포한다.

🧩 주요 포인트

1. 허브 MLflow 공유 → 등록과 중앙 심사를 한곳에 모으지만, 교차 계정 S3 접근과 계보 정보의 공유 범위를 함께 고려해야 한다.
2. 개발 계정의 로컬 승인 후 허브 복사 → 데이터 과학자의 허브 쓰기를 피하면서 로컬 승인과 중앙 재검증을 분리한다.
3. 허브 소유 아티팩트와 출처 메타데이터 → 중앙 기록의 런타임 독립성을 확보하고, 개발 계정의 로컬 배포와 별도의 승인 흐름을 구성한다.

🧠 상세 정리

1. 단일 계정에서 다중 계정 거버넌스로 확장

Part 1은 Amazon SageMaker AI의 관리형 MLflow에 등록한 모델을 SageMaker AI Model Registry로 자동 동기화하고, 단일 계정에서 IAM 조건 키로 데이터 과학자와 거버넌스 담당자의 권한을 구분하는 방식을 소개했다. 이번 글은 여러 개발 계정과 중앙 거버넌스 기능을 운영하는 조직을 대상으로 이 구조를 계정 간 모델 관리로 확장한다. 특히 규제 환경에서는 개발 워크로드가 운영 수준의 계정에 쓰기를 수행하지 못하도록 요구할 수 있다는 점이 구조 선택의 주요 배경이다. 데이터 과학자는 Jupyter 노트북에서 MLflow를 사용하고, 거버넌스 담당자는 Amazon SageMaker Studio의 Models UI에서 심사한다. 여기에 AWS RAM 공유·버킷 정책·대상 그룹을 준비하는 관리자와, 하이브리드 구조에서 허브로 보내기 전 모델을 로컬 승인하는 개발 계정의 모델 소유자가 추가된다.

2. 사전 준비와 계정별 환경 구성

실습을 시작하려면 Part 1을 완료하고 자동 모델 등록, 수명주기 단계 구성, IAM 조건 키를 통한 권한 통제에 익숙해야 한다. 개발용 스포크 계정과 거버넌스용 허브 계정이라는 두 AWS 계정이 필요하며, 각각 mlops-spoke와 mlops-hub 같은 이름의 AWS CLI 프로필을 구성한다. 두 계정에는 동봉된 AWS CloudFormation 스택을 각각 하나씩 배포해야 한다. cfn/sagemaker-studio-mlflow.yaml 템플릿은 SageMaker AI Studio 도메인, 사용자 프로필, 실행 역할과 AutoModelRegistrationEnabled가 활성화된 관리형 MLflow 앱을 생성한다. 원문은 계정·프로필 설정, 정확한 배포 명령, 스택 출력 확인과 환경 변수 설정의 세부 절차를 동봉된 GitHub 저장소와 README에서 확인하도록 안내한다.

3. 중앙 거버넌스 구조의 전체 흐름

첫 번째 구조는 개발 워크로드를 각 개발 계정에 분리하면서, MLflow 앱과 중앙 Model Registry를 허브 계정에 두는 허브 앤드 스포크 방식이다. 허브가 AWS RAM으로 MLflow 앱을 공유하고 스포크가 초대를 수락하며, 외부 보안 주체를 허용하면 동일한 조직에 속하지 않은 계정 사이에서도 공유할 수 있다. 스포크의 데이터 과학자가 공유 앱에 모델을 등록하면 등록 호출과 동시에 허브에 Model Package Group과 모델 버전이 생성된다. 허브는 생성된 그룹에 리소스 정책을 연결하고 AllowDeploy 관리형 권한으로 스포크에 다시 공유해 모델 조회와 배포를 허용한다. 거버넌스 담당자가 허브에서 지표와 계보를 검증해 승인하면 승인 이벤트가 CI/CD 파이프라인을 촉발하고, ML 엔지니어가 승인 모델을 스포크 계정의 Amazon SageMaker 엔드포인트에 배포한다.

4. 중앙 구조의 교차 계정 접근 권한

중앙 구조에서는 모델 아티팩트가 허브 계정의 MLflow 아티팩트 저장소인 S3 버킷에 있으므로, 리소스 측과 자격 증명 측의 교차 계정 접근 권한을 모두 준비해야 한다. 허브 버킷 정책은 스포크 계정에 s3:GetObject, s3:PutObject, s3:ListBucket, s3:GetBucketLocation을 허용해야 하며, 이 정책이 없으면 데이터 과학자의 log_model 호출이 등록 전에 S3 접근 오류로 실패한다. 스포크 실행 역할에는 배포 시 아티팩트를 읽을 수 있도록 허브 버킷에 대한 s3:GetObject 권한이 필요하다. AmazonSageMakerFullAccess는 이름에 sagemaker가 포함된 버킷을 지원하므로, 실행 역할의 권한을 더 좁게 설정했다면 허브 버킷을 명시적으로 추가해야 한다. 관리자는 이러한 전제조건을 갖춘 뒤 MLflow 앱을 공유하고, 첫 등록 후 동기화된 Model Package Group에 리소스 정책과 AllowDeploy 공유를 설정한다.

5. 중앙 등록·심사와 이름·계보의 제약

데이터 과학자의 작업은 Part 1과 같지만, 노트북의 MLflow 추적 URI가 허브 앱의 Amazon Resource Name인 ARN을 가리킨다는 차이가 있다. 자동 등록은 허브에 모델 그룹과 버전을 동기적으로 생성하며, 승인 대기 후보에는 스포크 실행에서 나온 지표, 평가 카드와 계보가 함께 표시된다. 그룹 이름에는 짧은 해시 접미사가 붙어 my-model이 my-model-<hash> 형태가 되므로, list_model_package_groups(NameContains=...)로 그룹을 찾고 교차 계정에서는 이름 대신 전체 ARN으로 참조해야 한다. 동기화가 허브에서 실행되기 때문에 계보도 허브에 기록되며, AWS RAM의 그룹 공유만으로 계보 엔터티가 스포크에 자동 공유되지는 않는다. 거버넌스 담당자는 허브 Studio의 Models 화면에서 여러 스포크의 후보를 검토하고, 운영 단계로 승격한 뒤 승인 상태를 Approved로 설정한다.

6. 하이브리드 구조의 로컬 승인과 배포

두 번째 구조는 허브를 운영 수준의 계정으로 취급해 데이터 과학자의 직접 또는 간접 쓰기를 허용하지 않으려는 규제 조직을 위한 하이브리드 방식이다. 데이터 과학자는 개발 계정 자체의 MLflow 앱에 모델을 등록하고, 자동 동기화도 해당 개발 계정의 Model Registry 안에서만 이루어지므로 이 단계에서는 허브가 영향을 받지 않는다. 개발 계정의 모델 소유자가 후보를 검토해 로컬 승인하면 허브로 모델을 복사하는 흐름이 시작되고, 허브의 거버넌스 담당자는 복사된 모델을 다시 검증해 중앙 거버넌스 기록으로 승인한다. 이 구조는 데이터 과학자의 등록 작업과 허브로의 승격 작업을 분리하며, 로컬 승인과 중앙 승인을 서로 다른 단계로 둔다. 개발 계정의 ML 엔지니어는 일반적으로 CI/CD를 통해 로컬 승인 모델을 해당 계정의 엔드포인트에 배포하며, 이 배포에는 교차 계정 아티팩트가 필요하지 않다.

7. 하이브리드 구조의 대상 그룹과 아티팩트 준비

하이브리드 구조의 허브 관리자는 대상 Model Package Group을 생성하고, 개발 계정이 그 그룹에 CreateModelPackage를 수행할 수 있도록 리소스 정책을 연결한다. 이어서 AWS RAM의 AllowRegister 관리형 권한으로 대상 그룹을 공유해 승인된 모델의 허브 등록 경로를 마련한다. 관리자는 복사 흐름이 모델 아티팩트를 저장할 허브 소유 버킷도 생성하거나 지정해야 하며, 개발 계정 역할로 복사를 수행할 수 있도록 버킷 정책에 s3:PutObject와 s3:ListBucket을 허용한다. 원문에서 사용하는 AWS 관리형 프레임워크 이미지는 리전별 공개 이미지이므로 컨테이너 이미지 복제가 필요하지 않다. 반면 컨테이너 이미지가 개발 계정의 비공개 저장소에 있다면 이미지를 허브로 복제하거나 Amazon Elastic Container Registry인 Amazon ECR의 저장소 정책을 추가해야 한다.

8. 승인 후 복사와 출처를 보존한 중앙 재검증

로컬 승인 후의 복사 흐름은 운영 환경에서 Model Package 상태 변경을 감지하는 Amazon EventBridge 규칙으로 촉발하는 방식으로 설명된다. 복사 단계는 개발 버킷의 모델 아티팩트를 허브 소유 버킷에 복제하고, 추론 명세가 허브의 복사본을 가리키도록 수정한 뒤 허브 대상 그룹에 패키지를 다시 등록한다. 등록 시 CustomerMetadataProperties에 원본 패키지 ARN과 계정을 기록해 출처를 보존하며, 완성된 허브 패키지는 개발 계정에 대한 런타임 의존성이 없는 자체 완결 형태가 된다. 허브 거버넌스 담당자는 Studio에서 원본을 가리키는 출처 메타데이터를 확인하고, 복사된 패키지를 재검증해 독립적으로 승인한다. 구체적인 복사 구현은 저장소를 참조하도록 안내되어 있으며, 제공된 source_body는 그림 8 설명 도중 끝나므로 도입부에서 예고한 승인 후 배포의 상세 절차와 두 구조의 최종 비교 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 두 구조의 선택 기준은 중앙화 자체보다 허브 쓰기를 누가 어떤 단계에서 수행할 수 있는지에 있다. 중앙 구조는 공유 MLflow 등록을 허용하고, 하이브리드 구조는 로컬 승인 이후의 복사 흐름으로 허브 등록을 분리한다.
• AWS RAM으로 Model Package Group을 공유해도 S3 아티팩트 접근이나 계보 공유가 모두 해결되지는 않는다. 중앙 구조에서는 모델 배포 권한, 버킷 접근 권한과 계보 가시성을 각각 고려해야 한다.
• 하이브리드 구조는 허브 소유 아티팩트로 런타임 의존성을 제거하면서 출처 메타데이터를 남긴다. 이에 따라 중앙 재검증과 개발 계정의 로컬 배포가 별도의 승인 흐름으로 구성된다.

✅ 액션 아이템

• 데이터 과학자의 허브 쓰기 허용 여부를 기준으로 중앙 거버넌스와 하이브리드 거버넌스의 적용 적합성 검토.
• 중앙 거버넌스 적용 시 교차 계정 S3 권한, AllowDeploy 공유 및 계보 정보의 자동 공유 제약 확인.
• 하이브리드 거버넌스 적용 시 로컬 승인, 허브 소유 버킷 복제, 추론 명세 수정과 허브의 독립적 재검증 흐름 점검.

❓ 열린 질문

• 데이터 과학자의 허브 쓰기를 허용할 수 있는가, 아니면 하이브리드 거버넌스의 로컬 승인 후 복사가 필요한가?
• 중앙 거버넌스에서 교차 계정 S3 권한과 AllowDeploy 공유는 충족되며, 계보 정보가 자동 공유되지 않는 제약은 수용 가능한가?
• 하이브리드 거버넌스에서 허브의 독립적 재검증·승인과 개발 계정의 로컬 승인 모델 배포는 어떤 관계로 운영할 것인가?