Fleet-wide computer vision lifecycle at the edge with SageMaker SDK v3
Quick Summary
AWS는 SageMaker SDK v3 기반으로 카메라별 이상 탐지·결함 분류 모델의 학습, 품질 검증, Neo 최적화, 버전 등록을 자동화하고 Step Functions로 대규모 재학습의 동시 실행을 제어하는 구성을 제시한다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
AWS는 SageMaker SDK v3 기반으로 카메라별 이상 탐지·결함 분류 모델의 학습, 품질 검증, Neo 최적화, 버전 등록을 자동화하고 Step Functions로 대규모 재학습의 동시 실행을 제어하는 구성을 제시한다.
📌 핵심 요약
- 생산 현장에서는 카메라별 각도·반사광·주변 조명 차이로 통합 데이터로 학습한 단일 모델의 성능이 일부 카메라에서 부족해질 수 있어, 카메라별 미세 조정 모델 수천 개의 수명주기 관리가 과제로 제시된다.
- 카메라별로 매개변수화한 단일 SageMaker Pipeline은 실행당 13단계로 구성되며, 소형 합성곱 오토인코더와 ResNet18 분류기를 학습한다. 각 분기는 해당 카메라의 최신 승인 모델을 가져오고, ONNX 내보내기·평가·품질 관문·SageMaker Neo 컴파일을 거쳐 Model Registry에 등록한다.
- 품질 관문은 이상 탐지 모델에 AUROC 0.8 이상, 분류기에 균형 정확도 0.6 이상과 결함 재현율 0.5 이상을 요구한다. 약 90%가 정상 이미지인 데이터의 불균형을 고려한 기준이며, 분기별로 독립 적용되어 실패한 모델의 등록을 차단하고 해당 카메라의 기존 승인 모델 제공을 유지한다.
- Amazon SQS FIFO, AWS Lambda, Step Functions, DynamoDB 세마포어가 재학습 요청을 조율하며 기본 동시 실행 상한은 파이프라인 5개다. Model Registry는 ONNX를, S3는 DLR 런타임으로 로드하는 Neo 컴파일 공유 라이브러리를 보관하고, 완료와 운영 실패는 Amazon SNS로 전달한다.
- 샘플은 AWS CDK로 배포하며 합성 데이터의 전체 파이프라인 실행에 드는 컴퓨팅 비용은 약 0.07달러다. SDK v3의 합성 시점 IAM 검증 때문에 2단계 배포와 구체적인 역할 ARN이 필요하고, ECR 권한 검증 특성에 따른 더 넓은 권한 부여, AWS CDK CLI 2.1131.0 이상 사용, 세 가지 리전 환경 변수의 일치도 요구된다.
🧩 주요 포인트
- 카메라별 환경 차이 → 카메라 ID에 연결된 승인 모델 이력과 개별 미세 조정으로 재학습의 연속성을 확보한다.
- ONNX 평가와 결함 재현율을 포함한 복수 품질 기준 → 내보내기 오류나 다수 정상 클래스에 치우친 모델이 등록되는 위험을 줄인다.
- 기본 동시 실행 상한 5개와 Neo 컴파일 후 등록 → 학습 요청의 집중을 제어하면서 장치에 맞게 최적화된 버전별 산출물을 확보하되, 실제 전달은 현장의 배포 방식에 맡긴다.
🧠 상세 정리
1. 단일 카메라 실증에서 대규모 모델 운영으로
글은 품질 검사 개념 검증이 성공한 뒤 곧바로 드러나는 카메라별 모델 수명주기 관리 문제에서 출발한다. 카메라 하나와 모델 하나로 얻은 결과를 카메라가 여러 대씩 설치된 40개 생산 라인에 확장하면, 촬영 각도와 같은 스테인리스 표면의 반사광, 출입문 개방에 따른 주변 조명까지 카메라마다 달라진다. 저자들이 참여한 운영 배포에서는 통합 영상으로 학습한 단일 모델이 일부 개별 카메라에서 충분한 성능을 내지 못해 각 카메라에 맞춘 미세 조정 모델이 필요했다. 따라서 핵심 과제는 모델 하나를 잘 학습하는 데서 수천 개 모델을 각각 사람이 개입하지 않고 학습·평가·버전 관리·전달하는 것으로 이동한다. 이 글은 2023년의 엣지 시각 품질 검사 MLOps 패턴을 현재의 SageMaker Python SDK v3에 맞게 갱신하고, 지원이 중단된 SageMaker Edge Manager를 대신해 SageMaker Neo로 엣지 최적화를 수행하는 구성을 제시한다.
2. 카메라별 두 모델을 만드는 13단계 파이프라인
학습 부분은 카메라를 매개변수로 받는 하나의 SageMaker Pipeline이며, 실행마다 13단계를 수행한다. 시작 시 Preprocess, Fetch Latest Anomaly, Fetch Latest Classifier가 병렬로 실행되어 해당 카메라의 이미지를 전처리하고 두 분기의 최신 승인 모델을 각각 가져온다. 이상 탐지 분기는 정상 제품의 모습을 학습하고 재구성 오차로 이상을 찾는 소형 합성곱 오토인코더를 사용하며, 분류 분기는 결함을 확인하도록 미세 조정한 ResNet18을 사용한다. 각 분기는 모델을 ONNX로 내보낸 뒤 별도로 확보한 평가 데이터로 검증하고, 품질 관문을 통과한 모델만 지정된 엣지 대상에 맞춰 SageMaker Neo로 컴파일한 다음 Model Registry에 등록한다. 모델 패키지는 카메라 ID를 메타데이터로 가지며 이전 모델 검색도 이 ID로 필터링하므로, 재학습은 항상 해당 카메라 자신의 승인 이력에서 출발한다.
3. 재학습 요청 조율과 장치용 산출물
오케스트레이션 계층은 재학습 요청이 한꺼번에 들어와도 전체 학습 작업이 동시에 시작되지 않도록 처리 속도를 조절한다. 요청은 Amazon SQS FIFO 큐에 쌓이고, AWS Lambda가 요청마다 Step Functions 실행을 시작한다. 각 실행은 DynamoDB 세마포어에서 슬롯을 획득한 뒤 파이프라인을 시작하므로, 요청 급증 시에도 대기열이 일정한 속도로 소진된다. 완료 알림은 Amazon SNS로 전송되며 운영 실패도 Amazon EventBridge 규칙을 통해 원래 오류를 보존한 상태로 같은 주제에 전달된다. 최종 결과는 카메라별로 버전이 부여되고 품질 관문을 통과한 모델 산출물이며, Model Registry에는 이식 가능한 ONNX가, S3에는 Neo로 컴파일한 장치 최적화 공유 라이브러리가 저장된다. 이 공유 라이브러리는 ONNX 자체가 아니라 DLR 런타임이 로드하는 형식이고, 실제 장치 전달은 각 생산 현장이 사용하는 방식에 연결하도록 되어 있다.
4. 배포 준비 조건과 리전 설정
샘플 배포에는 IAM 역할 생성 권한을 가진 AWS 계정, S3 버킷, ECR 저장소와 함께 SageMaker AI, Step Functions, Lambda, SQS, SNS, EventBridge, DynamoDB 리소스가 필요하다. 개발 환경은 Python 3.10·3.11·3.12 중 하나와 Docker를 요구하며, AWS CDK CLI는 2.1131.0 이상이어야 최근 aws-cdk-lib와 클라우드 어셈블리 스키마가 맞지 않아 발생하는 실패를 피할 수 있다. 기본 구성은 파이프라인 동시 실행을 최대 5개로 제한해 동시 SageMaker 학습 작업을 표준 계정 할당량 안에 유지하므로 서비스 할당량 증가는 필요하지 않다고 설명한다. CLI 기본값과 다른 리전에 배포할 때는 배포 명령 자체에 AWS_REGION, AWS_DEFAULT_REGION, CDK_DEFAULT_REGION 세 변수를 모두 설정해야 한다. CDK CLI, Boto3, AWS CLI가 리전을 결정할 때 참조하는 변수 집합이 완전히 같지 않아 불일치 시 일부만 배포되는 혼란이 생길 수 있으며, 명령 앞에 변수를 지정하면 기존 기본 리전은 유지된다. 샘플 전체는 AWS CDK로 배포하며, 합성 데이터로 전체 파이프라인을 한 번 실행하는 컴퓨팅 비용은 약 0.07달러로 제시된다.
5. SDK v3의 모듈화와 학습 설정
SDK v3는 SageMaker Python SDK를 모듈식 패키지로 재구성했으며, sagemaker>=3.0.0,<4를 설치하면 sagemaker-core, sagemaker-train, sagemaker-serve, sagemaker-mlops가 별도 패키지로 설치된다. v2에서 Estimator 생성자의 여러 인수에 분산되어 있던 학습 설정은 이제 ModelTrainer에 전달하는 타입 지정 설정 객체로 표현된다. 제시된 오토인코더 학습 예시는 인스턴스 1개를 사용하고 이미지 크기 256, 학습 3회, 배치 크기 16, 학습률 0.001을 지정하며, 로그에서 image_auroc 지표를 추출한다. 입력은 train, validation, test, pretrained_model의 네 채널을 상위 단계의 속성과 연결하고, 모든 S3 경로를 파이프라인 실행 ID 범위로 나누어 동시 실행 간 충돌을 방지한다. 또한 PipelineSession의 default_bucket을 자체 버킷으로 지정하면 단계 코드처럼 SDK가 관리하는 업로드도 같은 버킷으로 모아 실행 역할의 버킷 접근 권한을 한곳에 맞출 수 있다. 이 코드는 독립 실행 스크립트가 아니라 저장소의 CDK 애플리케이션에서 발췌한 것으로, cdk deploy 과정에서 파이프라인 정의를 합성할 때 실행된다.
6. 합성 시점 IAM 검증이 만드는 2단계 배포
SDK v3는 파이프라인 정의를 만들 때 실행 역할을 실제 IAM에 조회해 검증하므로, 검증이 파이프라인 실행 시점이 아니라 CDK 합성 시점에 발생한다. 따라서 같은 배포에서 역할과 파이프라인을 함께 만들려고 하면 검증할 역할이 아직 존재하지 않는 문제가 생긴다. 샘플은 첫 번째 배포에 -c bootstrap=true를 전달해 역할·버킷·ECR 저장소를 만든 뒤, 두 번째 배포에서 이미 존재하는 역할을 기준으로 파이프라인을 합성한다. 이 문맥 플래그는 이름만 같을 뿐 계정과 리전별 CDK 도구 리소스를 준비하는 cdk bootstrap과는 별개이며, 파이프라인에 넣는 역할 ARN도 해석되지 않은 CDK 토큰이 아닌 구체적인 문자열이어야 한다. 또 다른 제약은 v3 역할 검증기가 리소스 ARN 없이 ECR 이미지 가져오기 권한을 시뮬레이션한다는 점으로, 단일 ECR 저장소로 제한한 역할은 실제 실행에 충분하더라도 검증에 실패한다. 샘플이 더 넓은 ECR 권한을 부여하는 이유는 이 검증 동작을 통과하기 위해서라고 설명한다.
7. ONNX 평가와 불균형 데이터에 맞춘 품질 기준
모든 학습 모델은 등록 전에 평가되며, 평가 대상은 메모리에 있는 PyTorch 모델이 아니라 내보낸 ONNX 산출물이다. 이는 학습 중 지표가 양호해도 내보내기 과정에서 생긴 오류로 손상된 모델이 품질 관문을 통과하는 일을 막기 위한 선택이다. 이상 탐지 분기는 AUROC 0.8 이상을 요구하고, 분류 분기는 데이터의 약 90%가 정상 이미지라는 불균형을 고려해 단순 정확도 대신 균형 정확도와 결함 재현율을 함께 사용한다. 모든 이미지를 정상으로 예측해도 정확도가 약 0.9가 되지만 결함은 하나도 잡지 못하므로, 단순 정확도만으로는 결함 탐지 성능을 판단하기 어렵다. 클래스별 재현율의 평균인 균형 정확도 역시 정상 재현율 1.0과 결함 재현율 0.2의 조합에서 0.6을 기록하는 한계가 있다. 이에 분류기 품질 관문은 균형 정확도 0.6 이상과 결함 재현율 0.5 이상을 동시에 요구한다.
8. 분기별 실패 처리와 기존 승인 모델 유지
분류기 품질 관문을 구현하는 ConditionStep은 조건들을 AND로 결합하므로 균형 정확도와 결함 재현율 기준을 모두 충족해야 통과한다. 임계값은 파이프라인 매개변수이기 때문에 시스템을 다시 배포하지 않고도 실행마다 조정할 수 있다. 품질 관문에 실패하면 FailStep이 실행을 실패로 표시하고 해당 분기의 모델은 Model Registry에 도달하지 못하지만, 두 분기는 독립적으로 판정하므로 다른 분기의 모델은 등록될 수 있다. 이때 현장의 카메라는 기존 승인 모델을 계속 제공하므로 재학습 결과가 나빠졌다는 이유로 그 모델을 곧바로 교체하지 않는다. 학습 측면에서도 불균형을 다루며, 분류기는 ImageNet 가중치와 2개 클래스 출력부를 사용하는 resnet18을 미세 조정하고, 글은 카메라별 규모의 데이터에서 사전 학습 가중치가 다수 클래스로 예측이 쏠리는 현상을 막는 데 중요하다고 설명한다. 제공된 본문은 이어지는 학습 데이터 균형화 설명 도중에 끝나므로, 그 구체적인 구현 방식은 확인할 수 없다.
🧾 핵심 주장 / 시사점
- 카메라별 모델 운영의 핵심은 개별 학습 자체뿐 아니라 카메라 ID, 승인 이력, 실행별 저장 경로를 일관되게 연결해 많은 재학습이 서로 섞이지 않게 하는 데 있다.
- 품질 기준은 데이터 분포와 실제 결함 탐지 목적을 함께 반영해야 한다. 균형 정확도만으로도 결함 재현율이 낮은 모델을 통과시킬 수 있다는 예시가 복수 지표의 필요성을 보여준다.
- SDK v3 전환은 학습 API 변경에 그치지 않는다. 합성 시점 IAM 검증과 ECR 권한 시뮬레이션 방식이 배포 순서와 실행 역할의 권한 범위에도 영향을 준다.
✅ 액션 아이템
- 카메라별 환경 차이와 기존 승인 모델 이력을 바탕으로 개별 미세 조정 모델의 적용 필요성을 검토한다.
- AUROC 0.8 이상, 균형 정확도 0.6 이상, 결함 재현율 0.5 이상을 기준으로 품질 관문의 적용 적합성을 검토한다.
- SDK v3 배포에 필요한 2단계 배포, 구체적인 역할 ARN, ECR 권한 검증 제약과 기본 동시 실행 상한 5개를 반영한다.
❓ 열린 질문
- 카메라별 각도·반사광·주변 조명 차이가 개별 미세 조정 모델의 필요성과 성능에 어느 정도 영향을 주는가?
- 약 90%가 정상 이미지인 데이터에서 균형 정확도 0.6 이상과 결함 재현율 0.5 이상은 현장의 품질 요구를 충족하는가?
- S3에 저장된 Neo 컴파일 공유 라이브러리를 현장의 배포 방식으로 전달하고 DLR 런타임에서 로드하는 과정은 어떻게 연결할 것인가?