SageMaker Pipelines 및 모니터링 완벽 가이드

AWS SageMaker에서 ML 파이프라인을 구축하고 모니터링하는 방법을 배웁니다. Step Functions 통합부터 Model Monitor, Debugger, CloudWatch까지 MLOps의 핵심을 다룹니다.

---

목차

1. SageMaker_Pipelines_구축
2. Step_Functions_통합
3. ML_워크플로우_자동화
4. Model_Monitor_설정
5. Debugger로_디버깅
6. CloudWatch_통합_모니터링

---

1. SageMaker Pipelines 구축

김개발 씨는 머신러닝 모델을 만들 때마다 같은 작업을 반복하고 있었습니다. 데이터 전처리, 학습, 평가, 배포까지 매번 수동으로 진행하다 보니 실수도 잦고 시간도 많이 걸렸습니다.

"이걸 자동화할 수는 없을까요?" 선배 박시니어 씨가 웃으며 대답했습니다. "SageMaker Pipelines를 써보세요."

SageMaker Pipelines는 ML 워크플로우를 코드로 정의하고 자동화하는 도구입니다. 마치 공장의 컨베이어 벨트처럼 데이터가 들어오면 정해진 순서대로 처리되어 최종 모델이 나옵니다.

이것을 사용하면 반복 작업을 줄이고 일관된 품질의 모델을 만들 수 있습니다.

다음 코드를 살펴봅시다.

from sagemaker.workflow.pipeline import Pipeline
from sagemaker.workflow.steps import ProcessingStep, TrainingStep
from sagemaker.processing import ScriptProcessor

# 전처리 스텝 정의
processor = ScriptProcessor(
    role=role,
    image_uri=image_uri,
    instance_type="ml.m5.xlarge"
)

# 파이프라인 스텝 구성
processing_step = ProcessingStep(
    name="PreprocessData",
    processor=processor,
    inputs=[ProcessingInput(source=input_data)],
    outputs=[ProcessingOutput(output_name="train")]
)

# 파이프라인 생성 및 실행
pipeline = Pipeline(
    name="ml-training-pipeline",
    steps=[processing_step, training_step, eval_step]
)
pipeline.upsert(role_arn=role)

김개발 씨는 입사 6개월 차 ML 엔지니어입니다. 오늘도 새로운 모델을 학습시키기 위해 주피터 노트북을 열었습니다.

데이터 다운로드, 전처리, 학습, 평가, 그리고 S3에 모델 저장까지. 이 모든 과정을 또다시 수동으로 진행해야 한다고 생각하니 한숨이 나왔습니다.

"김개발 씨, 왜 그렇게 한숨을 쉬어요?" 옆자리의 박시니어 씨가 물었습니다. "아, 매번 같은 작업을 반복하다 보니까요.

지난번에는 전처리 코드를 조금 바꿨는데 깜빡하고 예전 버전으로 학습시켜서 다시 해야 했어요." 박시니어 씨가 고개를 끄덕였습니다. "그래서 SageMaker Pipelines가 필요한 거예요.

ML 워크플로우 전체를 코드로 정의하면 그런 실수를 방지할 수 있거든요." 그렇다면 SageMaker Pipelines란 정확히 무엇일까요? 쉽게 비유하자면, SageMaker Pipelines는 마치 자동차 공장의 조립 라인과 같습니다.

부품이 컨베이어 벨트를 타고 들어오면 각 스테이션에서 정해진 작업을 수행합니다. 용접, 도색, 조립 순서가 정해져 있고, 한 단계가 끝나야 다음 단계로 넘어갑니다.

ML 파이프라인도 마찬가지입니다. 데이터가 들어오면 전처리, 학습, 평가, 배포 단계를 순서대로 거쳐 최종 모델이 만들어집니다.

파이프라인이 없던 시절에는 어땠을까요? 개발자들은 각 단계를 수동으로 실행해야 했습니다.

노트북 셀을 하나씩 실행하거나 스크립트를 순서대로 돌렸습니다. 문제는 사람이 하는 일이다 보니 실수가 발생한다는 것입니다.

더 심각한 문제는 재현성이었습니다. 지난달에 만든 모델을 다시 만들려고 해도 어떤 파라미터를 썼는지, 어떤 데이터를 사용했는지 기억하기 어려웠습니다.

바로 이런 문제를 해결하기 위해 SageMaker Pipelines가 등장했습니다. 파이프라인을 사용하면 모든 단계가 코드로 정의됩니다.

버전 관리가 가능하고, 언제든 같은 조건으로 파이프라인을 다시 실행할 수 있습니다. 또한 각 단계의 입력과 출력이 자동으로 연결됩니다.

전처리 결과가 학습 단계로, 학습 결과가 평가 단계로 자연스럽게 흘러갑니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 ScriptProcessor를 정의합니다. 이것은 전처리 작업을 수행할 컨테이너입니다.

어떤 인스턴스 타입을 사용할지, 어떤 이미지를 쓸지 지정합니다. 다음으로 ProcessingStep을 만듭니다.

이름을 지정하고, 입력 데이터와 출력 위치를 설정합니다. 마지막으로 Pipeline 객체를 생성하여 모든 스텝을 연결합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 추천 시스템을 개발한다고 가정해봅시다.

매일 새로운 사용자 행동 데이터가 들어옵니다. 파이프라인을 설정해두면 매일 자동으로 새 데이터로 모델을 재학습하고, 성능이 기준치를 넘으면 자동 배포까지 할 수 있습니다.

많은 기업에서 이런 방식으로 모델을 지속적으로 개선하고 있습니다. 하지만 주의할 점도 있습니다.

파이프라인의 각 스텝은 독립적인 컨테이너에서 실행됩니다. 따라서 스텝 간에 데이터를 전달하려면 S3 같은 외부 저장소를 거쳐야 합니다.

메모리에 있는 변수를 그대로 넘길 수 없다는 점을 기억해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝였습니다. "그러면 한번 설정해두면 계속 자동으로 돌아가는 거네요!" 이제 김개발 씨는 반복 작업에서 해방되어 더 중요한 일에 집중할 수 있게 되었습니다.

실전 팁

💡 - 파이프라인은 작은 단위로 나누어 설계하면 디버깅이 쉬워집니다

• 각 스텝에 명확한 이름을 붙여 나중에 로그를 추적하기 쉽게 만드세요

---

2. Step Functions 통합

김개발 씨의 파이프라인이 잘 돌아가기 시작했습니다. 그런데 새로운 요구사항이 생겼습니다.

"모델 학습이 끝나면 Slack으로 알림을 보내고, 성능이 좋으면 자동으로 엔드포인트를 업데이트해주세요." 단순한 순차 실행만으로는 부족해진 것입니다. 박시니어 씨가 말했습니다.

"이럴 때 Step Functions를 연동하면 됩니다."

AWS Step Functions는 복잡한 워크플로우를 시각적으로 설계하고 실행할 수 있는 서비스입니다. 마치 순서도를 그리듯이 조건 분기, 병렬 처리, 에러 핸들링을 정의할 수 있습니다.

SageMaker와 연동하면 ML 워크플로우를 더욱 유연하게 구성할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

# Step Functions 상태 머신 정의
definition = {
    "StartAt": "TrainModel",
    "States": {
        "TrainModel": {
            "Type": "Task",
            "Resource": "arn:aws:states:::sagemaker:createTrainingJob.sync",
            "Parameters": {
                "TrainingJobName.$": "$.job_name",
                "AlgorithmSpecification": {
                    "TrainingImage": image_uri
                }
            },
            "Next": "EvaluateModel"
        },
        "EvaluateModel": {
            "Type": "Choice",
            "Choices": [{
                "Variable": "$.accuracy",
                "NumericGreaterThan": 0.9,
                "Next": "DeployModel"
            }],
            "Default": "NotifyFailure"
        }
    }
}

sfn_client = boto3.client('stepfunctions')

김개발 씨는 파이프라인을 잘 구축했지만, 곧 한계에 부딪혔습니다. 비즈니스 팀에서 새로운 요구사항을 보내왔기 때문입니다.

"모델 정확도가 90% 이상이면 바로 배포하고, 그렇지 않으면 담당자에게 알림을 보내주세요. 그리고 학습이 실패하면 자동으로 재시도해주세요." 단순히 순서대로 실행되는 파이프라인으로는 이런 복잡한 로직을 처리하기 어려웠습니다.

김개발 씨가 고민하고 있을 때 박시니어 씨가 다가왔습니다. "Step Functions를 써보는 건 어때요?

복잡한 워크플로우를 깔끔하게 정리할 수 있어요." 그렇다면 Step Functions란 정확히 무엇일까요? 쉽게 비유하자면, Step Functions는 마치 회사의 결재 시스템과 같습니다.

기안서가 올라오면 팀장이 검토하고, 금액에 따라 부장이나 임원에게 올라갑니다. 조건에 따라 경로가 달라지고, 중간에 반려되면 다시 처음으로 돌아갑니다.

Step Functions도 마찬가지로 각 단계에서 조건에 따라 다른 경로로 분기할 수 있습니다. Step Functions가 없던 시절에는 어땠을까요?

개발자들은 복잡한 조건문을 코드 안에 직접 작성해야 했습니다. if-else가 중첩되고, 에러 처리 코드가 여기저기 흩어져 있었습니다.

워크플로우가 어떻게 흘러가는지 파악하려면 코드 전체를 읽어야 했습니다. 유지보수는 악몽이었습니다.

Step Functions는 이런 문제를 해결합니다. 워크플로우를 JSON으로 선언적으로 정의합니다.

AWS 콘솔에서 시각적으로 확인할 수 있어 전체 흐름을 한눈에 파악할 수 있습니다. 무엇보다 SageMaker와 네이티브 통합이 되어 있어서 학습 작업, 변환 작업, 엔드포인트 생성 등을 직접 호출할 수 있습니다.

위의 코드를 살펴보겠습니다. StartAt은 워크플로우의 시작점을 지정합니다.

States에는 각 단계가 정의되어 있습니다. TrainModel 상태는 SageMaker 학습 작업을 실행하고, .sync 접미사 덕분에 작업이 완료될 때까지 기다립니다.

EvaluateModel 상태는 Choice 타입으로, 정확도에 따라 다음 단계를 결정합니다. 실제 현업에서는 더 복잡한 패턴을 사용합니다.

예를 들어 Parallel 상태를 사용하면 여러 모델을 동시에 학습시킬 수 있습니다. XGBoost, LightGBM, 신경망을 병렬로 학습한 뒤 가장 성능이 좋은 모델을 선택하는 식입니다.

Retry 설정을 통해 일시적인 오류에 자동으로 재시도할 수도 있습니다. 하지만 주의할 점이 있습니다.

Step Functions 실행에는 상태 전환 비용이 발생합니다. 아주 잦은 상태 변경이 필요한 경우 비용이 늘어날 수 있습니다.

또한 실행 기록은 90일 후 삭제되므로 장기 보관이 필요하면 별도로 로그를 저장해야 합니다. 김개발 씨는 Step Functions를 도입한 후 복잡했던 조건 로직을 깔끔하게 정리할 수 있었습니다.

"이제 워크플로우가 어떻게 흘러가는지 그림으로 볼 수 있어서 좋네요!" 동료들도 더 쉽게 이해할 수 있게 되었습니다.

실전 팁

💡 - Express Workflow는 짧은 실행에 적합하고, Standard Workflow는 긴 실행에 적합합니다

• 각 상태에 TimeoutSeconds를 설정하여 무한 대기를 방지하세요

---

3. ML 워크플로우 자동화

김개발 씨의 시스템이 점점 정교해졌습니다. 하지만 여전히 파이프라인을 수동으로 시작해야 했습니다.

"매일 아침 9시에 새 데이터가 올라오는데, 그때마다 제가 직접 실행해야 하나요?" 박시니어 씨가 답했습니다. "이벤트 기반 트리거를 설정하면 완전 자동화가 가능해요."

ML 워크플로우 자동화는 사람의 개입 없이 파이프라인이 자동으로 실행되도록 만드는 것입니다. 마치 정해진 시간에 알람이 울리는 것처럼, 특정 이벤트나 스케줄에 따라 파이프라인을 트리거할 수 있습니다.

EventBridge, Lambda, S3 이벤트 등을 활용합니다.

다음 코드를 살펴봅시다.

import boto3
from sagemaker.workflow.pipeline import Pipeline

# EventBridge 규칙 생성 - 매일 아침 9시 실행
events_client = boto3.client('events')

events_client.put_rule(
    Name='daily-training-trigger',
    ScheduleExpression='cron(0 9 * * ? *)',
    State='ENABLED'
)

# Lambda를 통한 S3 이벤트 트리거
def lambda_handler(event, context):
    # S3에 새 데이터 업로드 시 파이프라인 실행
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    pipeline = Pipeline(name='ml-training-pipeline')
    execution = pipeline.start(
        parameters={'InputData': f's3://{bucket}/{key}'}
    )
    return {'executionArn': execution.arn}

김개발 씨는 매일 아침 출근하면 가장 먼저 하는 일이 있었습니다. 바로 파이프라인 실행 버튼을 누르는 것입니다.

새벽에 데이터 팀이 올려둔 새 데이터로 모델을 재학습시켜야 했기 때문입니다. "이것도 자동화할 수 없을까요?" 박시니어 씨가 커피를 건네며 말했습니다.

"당연히 가능하죠. 이벤트 기반 자동화를 설정하면 김개발 씨가 버튼을 누르지 않아도 알아서 돌아가요." 그렇다면 워크플로우 자동화란 무엇일까요?

쉽게 비유하자면, 마치 스마트 홈 시스템과 같습니다. 해가 지면 자동으로 조명이 켜지고, 온도가 올라가면 에어컨이 작동합니다.

누군가 일일이 스위치를 누르지 않아도 조건에 따라 자동으로 동작합니다. ML 워크플로우 자동화도 마찬가지입니다.

새 데이터가 올라오거나 정해진 시간이 되면 자동으로 파이프라인이 실행됩니다. 자동화가 없던 시절에는 어땠을까요?

개발자가 직접 모니터링하면서 실행 시점을 결정해야 했습니다. 휴가를 가면 대신 실행해줄 사람을 구해야 했고, 주말에도 긴급 상황에 대응해야 했습니다.

무엇보다 일관성이 떨어졌습니다. 어떤 날은 아침에, 어떤 날은 점심에 실행되다 보니 모델 업데이트 주기가 들쭉날쭉했습니다.

자동화를 구현하는 방법은 여러 가지가 있습니다. 첫째, 스케줄 기반 트리거입니다.

EventBridge에서 cron 표현식을 사용해 매일 아침 9시, 매주 월요일 등 정해진 시간에 파이프라인을 실행할 수 있습니다. 둘째, 이벤트 기반 트리거입니다.

S3에 새 파일이 업로드되면, 또는 특정 API가 호출되면 파이프라인이 시작됩니다. 위의 코드를 살펴보겠습니다.

put_rule 함수로 EventBridge 규칙을 생성합니다. cron 표현식 `0 9 * * ?

*`은 "매일 9시"를 의미합니다. Lambda 함수는 S3 이벤트를 받아서 어떤 파일이 업로드되었는지 확인하고, 해당 데이터를 파라미터로 넘겨 파이프라인을 시작합니다.

실제 현업에서는 여러 트리거를 조합해서 사용합니다. 예를 들어 기본적으로 매일 아침 스케줄 실행을 하되, 긴급하게 새 데이터가 들어오면 바로 실행되도록 설정할 수 있습니다.

또한 중복 실행 방지 로직을 추가해서 이미 실행 중인 파이프라인이 있으면 새 실행을 건너뛰도록 합니다. 하지만 주의할 점이 있습니다.

자동화된 시스템은 모니터링이 필수입니다. 사람이 보지 않는 사이에 문제가 발생하면 한동안 모를 수 있기 때문입니다.

실행 실패 시 알림을 보내는 설정을 반드시 해두어야 합니다. 또한 비용 관리도 중요합니다.

너무 자주 실행되면 비용이 급증할 수 있습니다. 김개발 씨는 자동화를 설정한 후 아침 루틴이 바뀌었습니다.

출근하면 파이프라인 실행 결과를 확인하는 것으로 시작합니다. 이미 새 모델이 학습되어 있고, 성능 지표도 깔끔하게 정리되어 있었습니다.

"이제 진짜 MLOps를 하는 것 같아요!"

실전 팁

💡 - 실행 실패 시 SNS나 Slack으로 알림을 받도록 설정하세요

• 동시 실행 수를 제한하여 리소스 과다 사용을 방지하세요

---

4. Model Monitor 설정

모델이 배포된 지 한 달이 지났습니다. 처음에는 잘 작동하던 모델의 예측 정확도가 점점 떨어지기 시작했습니다.

김개발 씨는 고객 불만이 들어오고 나서야 문제를 알게 되었습니다. "미리 알 수는 없었을까요?" 박시니어 씨가 말했습니다.

"Model Monitor를 설정했어야 했어요."

SageMaker Model Monitor는 배포된 모델의 품질을 지속적으로 감시하는 도구입니다. 마치 건강검진처럼 모델의 상태를 정기적으로 체크합니다.

입력 데이터의 분포 변화, 예측 결과의 이상 징후를 감지하여 문제가 커지기 전에 알려줍니다.

다음 코드를 살펴봅시다.

from sagemaker.model_monitor import DataCaptureConfig
from sagemaker.model_monitor import DefaultModelMonitor

# 데이터 캡처 설정 - 요청/응답 저장
data_capture = DataCaptureConfig(
    enable_capture=True,
    sampling_percentage=100,
    destination_s3_uri=f's3://{bucket}/data-capture'
)

# Model Monitor 생성
monitor = DefaultModelMonitor(
    role=role,
    instance_count=1,
    instance_type='ml.m5.xlarge'
)

# 베이스라인 생성 - 정상 데이터의 기준
monitor.suggest_baseline(
    baseline_dataset=training_data_uri,
    dataset_format=DatasetFormat.csv()
)

# 모니터링 스케줄 설정 - 매시간 체크
monitor.create_monitoring_schedule(
    monitor_schedule_name='hourly-monitor',
    schedule_cron_expression='cron(0 * * * ? *)'
)

김개발 씨가 만든 추천 모델은 처음 배포했을 때 훌륭한 성능을 보여주었습니다. 클릭률이 20%나 올랐고, 모두가 기뻐했습니다.

그런데 한 달 후, 마케팅 팀에서 연락이 왔습니다. "요즘 추천이 이상해요.

전혀 관련 없는 상품이 추천되고 있어요." 급하게 분석해보니 문제가 발견되었습니다. 최근 신규 카테고리 상품이 대거 추가되었는데, 모델은 이런 상품을 한 번도 본 적이 없었던 것입니다.

김개발 씨는 한숨을 쉬었습니다. "미리 알았으면 좋았을 텐데..." 박시니어 씨가 말했습니다.

"이런 현상을 데이터 드리프트라고 해요. 시간이 지나면서 실제 데이터가 학습 데이터와 달라지는 거죠.

Model Monitor를 설정해두면 이런 변화를 조기에 감지할 수 있어요." 그렇다면 Model Monitor란 정확히 무엇일까요? 쉽게 비유하자면, 마치 정기 건강검진과 같습니다.

몸에 이상이 없어 보여도 정기적으로 검사를 받으면 질병을 조기에 발견할 수 있습니다. 혈압, 콜레스테롤, 혈당 같은 수치를 기준과 비교해서 정상 범위를 벗어나면 경고를 줍니다.

Model Monitor도 모델에 들어오는 데이터와 나가는 예측 결과를 기준선과 비교하여 이상 징후를 감지합니다. 모니터링이 없으면 어떤 일이 벌어질까요?

모델 성능이 서서히 떨어지는 것을 모델 쇠퇴라고 합니다. 문제는 이것이 갑자기 일어나지 않고 천천히 진행된다는 것입니다.

어느 날 갑자기 정확도가 반 토막 나면 바로 알아차릴 수 있습니다. 하지만 매주 1%씩 떨어지면?

몇 달이 지나서야 심각성을 깨닫게 됩니다. Model Monitor는 크게 네 가지 유형의 모니터링을 제공합니다.

첫째, 데이터 품질 모니터링입니다. 입력 데이터의 통계적 특성을 감시합니다.

평균, 표준편차, 결측값 비율 등이 기준선에서 벗어나면 알립니다. 둘째, 모델 품질 모니터링입니다.

실제 레이블과 예측을 비교하여 정확도, 정밀도, 재현율 등을 추적합니다. 셋째, 바이어스 드리프트 모니터링입니다.

특정 그룹에 대한 편향이 생기는지 감시합니다. 넷째, 피처 중요도 드리프트입니다.

어떤 피처가 예측에 영향을 주는지 변화를 추적합니다. 위의 코드를 살펴보겠습니다.

먼저 DataCaptureConfig로 엔드포인트에 들어오는 요청과 응답을 S3에 저장합니다. sampling_percentage를 100으로 설정하면 모든 요청이 저장됩니다.

다음으로 suggest_baseline을 호출하여 학습 데이터를 기준으로 정상 범위를 계산합니다. 마지막으로 create_monitoring_schedule로 정기적인 체크 일정을 설정합니다.

하지만 주의할 점이 있습니다. 모든 요청을 캡처하면 저장 비용이 증가합니다.

트래픽이 많은 서비스라면 샘플링 비율을 낮추는 것이 좋습니다. 또한 모니터링 작업 자체도 컴퓨팅 비용이 발생합니다.

모니터링 주기를 너무 짧게 설정하면 비용이 급증할 수 있습니다. 김개발 씨는 Model Monitor를 설정한 후 마음이 놓였습니다.

이제 데이터 분포가 변하면 자동으로 알림을 받을 수 있습니다. "문제가 커지기 전에 알 수 있으니까 훨씬 안심이 되네요."

실전 팁

💡 - 베이스라인은 충분한 양의 정상 데이터로 생성해야 정확합니다

• 처음에는 알림 임계값을 느슨하게 설정하고 점차 조정하세요

---

5. Debugger로 디버깅

김개발 씨가 새 모델을 학습시키고 있었습니다. 그런데 손실값이 전혀 줄어들지 않았습니다.

학습률을 바꿔보고, 배치 크기도 조정해보았지만 소용이 없었습니다. "도대체 어디가 문제인 걸까요?" 박시니어 씨가 SageMaker Debugger 화면을 열었습니다.

"여기 보세요. 그래디언트가 사라지고 있네요."

SageMaker Debugger는 학습 과정을 실시간으로 분석하고 문제를 진단하는 도구입니다. 마치 자동차의 블랙박스처럼 학습 중 일어나는 모든 것을 기록합니다.

그래디언트 소실, 과적합, 리소스 병목 등을 자동으로 감지하여 디버깅 시간을 획기적으로 줄여줍니다.

다음 코드를 살펴봅시다.

from sagemaker.debugger import Rule, rule_configs
from sagemaker.debugger import DebuggerHookConfig
from sagemaker.debugger import CollectionConfig

# 디버거 훅 설정 - 텐서 저장
debugger_hook = DebuggerHookConfig(
    s3_output_path=f's3://{bucket}/debugger',
    collection_configs=[
        CollectionConfig(name="gradients", parameters={"save_interval": "100"}),
        CollectionConfig(name="losses"),
        CollectionConfig(name="weights")
    ]
)

# 내장 규칙 적용
rules = [
    Rule.sagemaker(rule_configs.vanishing_gradient()),
    Rule.sagemaker(rule_configs.exploding_tensor()),
    Rule.sagemaker(rule_configs.overfit()),
    Rule.sagemaker(rule_configs.loss_not_decreasing())
]

# 학습 작업에 디버거 연결
estimator = Estimator(
    debugger_hook_config=debugger_hook,
    rules=rules
)

김개발 씨는 새로운 딥러닝 모델을 학습시키고 있었습니다. 데이터도 충분하고, 아키텍처도 검증된 것을 사용했는데 이상하게 손실값이 줄어들지 않았습니다.

처음에는 학습률 문제인 줄 알고 여러 값을 시도해보았습니다. 그래도 안 되어서 배치 크기, 옵티마이저, 정규화 등 온갖 것을 바꿔보았습니다.

이틀을 삽질한 끝에 김개발 씨는 지쳐버렸습니다. 박시니어 씨가 다가와 물었습니다.

"Debugger는 써봤어요?" 김개발 씨는 고개를 저었습니다. "디버거요?

print문 찍어보는 것 말고요?" 박시니어 씨가 웃으며 설명했습니다. "SageMaker Debugger는 단순한 로깅이 아니에요.

학습 과정에서 일어나는 모든 텐서를 캡처하고 분석해서 문제를 자동으로 찾아줘요." 그렇다면 Debugger란 정확히 무엇일까요? 쉽게 비유하자면, 마치 비행기의 블랙박스와 같습니다.

비행기가 추락하면 블랙박스를 분석해서 원인을 파악합니다. 조종사의 음성, 계기 데이터, 비행 경로 등이 모두 기록되어 있기 때문입니다.

Debugger도 마찬가지로 학습 중 그래디언트, 가중치, 활성화 값 등을 저장합니다. 문제가 발생하면 이 기록을 분석해서 원인을 찾을 수 있습니다.

디버거가 없던 시절에는 어땠을까요? 텐서 값을 확인하려면 코드 곳곳에 print문을 넣어야 했습니다.

로그가 폭주해서 터미널이 감당할 수 없을 정도였습니다. 그래도 문제를 찾지 못하면 처음부터 다시 학습을 돌려야 했습니다.

시간과 비용이 엄청나게 낭비되었습니다. Debugger는 여러 가지 내장 규칙을 제공합니다.

vanishing_gradient는 그래디언트가 너무 작아져서 학습이 안 되는 현상을 감지합니다. 이것이 바로 김개발 씨의 문제였습니다.

exploding_tensor는 반대로 값이 너무 커지는 현상을 감지합니다. overfit은 학습 데이터에 과하게 맞춰져서 일반화 성능이 떨어지는 것을 알려줍니다.

loss_not_decreasing은 손실값이 정체되어 있을 때 경고합니다. 위의 코드를 살펴보겠습니다.

DebuggerHookConfig로 어떤 텐서를 저장할지 설정합니다. gradients는 100 스텝마다, losses와 weights는 기본 간격으로 저장합니다.

Rule.sagemaker로 내장 규칙을 적용합니다. 이 규칙들은 학습과 병렬로 실행되며, 문제가 감지되면 즉시 알립니다.

더 강력한 기능도 있습니다. Profiler를 사용하면 시스템 리소스 사용량도 분석할 수 있습니다.

CPU, GPU, 메모리 사용률을 추적하여 병목 지점을 찾아줍니다. GPU가 데이터를 기다리느라 놀고 있는지, I/O 때문에 느린지 등을 파악할 수 있습니다.

이 정보를 바탕으로 하드웨어 활용도를 최적화할 수 있습니다. 하지만 주의할 점이 있습니다.

텐서를 저장하는 것은 오버헤드를 발생시킵니다. 너무 자주 저장하면 학습 속도가 느려집니다.

프로덕션 학습에서는 저장 간격을 넓히거나 필요한 텐서만 선택적으로 저장하는 것이 좋습니다. 박시니어 씨가 Debugger 결과를 보여주었습니다.

"여기 보세요. 레이어가 너무 깊어서 앞쪽 레이어의 그래디언트가 거의 0이 되었네요." 김개발 씨는 무릎을 쳤습니다.

"아, Batch Normalization을 추가해야겠네요!" 문제의 원인을 알았으니 해결책은 명확했습니다.

실전 팁

💡 - 처음에는 모든 내장 규칙을 적용하고, 필요 없는 것은 나중에 제거하세요

• 저장 간격은 데이터 크기와 학습 속도를 고려하여 조정하세요

---

6. CloudWatch 통합 모니터링

김개발 씨의 ML 시스템이 완성되었습니다. 파이프라인, 자동화, 모델 모니터링까지 모두 갖췄습니다.

그런데 문제가 생겼습니다. 각 서비스의 상태를 확인하려면 여러 콘솔을 돌아다녀야 했습니다.

"한눈에 다 볼 수 있는 방법은 없을까요?" 박시니어 씨가 CloudWatch 대시보드를 열었습니다.

Amazon CloudWatch는 AWS 서비스의 메트릭, 로그, 알람을 통합 관리하는 모니터링 서비스입니다. 마치 비행기 조종석의 계기판처럼 시스템의 모든 상태를 한눈에 보여줍니다.

ML 시스템의 학습 시간, 엔드포인트 지연 시간, 에러율 등을 하나의 대시보드에서 확인할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch')

# 커스텀 메트릭 발행 - 모델 예측 지연 시간
cloudwatch.put_metric_data(
    Namespace='MLMonitoring',
    MetricData=[{
        'MetricName': 'PredictionLatency',
        'Value': latency_ms,
        'Unit': 'Milliseconds',
        'Dimensions': [{'Name': 'EndpointName', 'Value': endpoint_name}]
    }]
)

# 알람 설정 - 지연 시간이 100ms 초과시
cloudwatch.put_metric_alarm(
    AlarmName='HighLatencyAlarm',
    MetricName='PredictionLatency',
    Namespace='MLMonitoring',
    Threshold=100,
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=3,
    AlarmActions=[sns_topic_arn]
)

# 대시보드 생성
dashboard_body = {
    "widgets": [
        {"type": "metric", "properties": {
            "title": "Endpoint Latency",
            "metrics": [["MLMonitoring", "PredictionLatency"]]
        }}
    ]
}

김개발 씨의 ML 시스템은 이제 꽤 복잡해졌습니다. SageMaker 파이프라인, Step Functions, Lambda, 엔드포인트, Model Monitor까지.

각각의 상태를 확인하려면 콘솔을 계속 바꿔가며 들어가야 했습니다. 어느 날 장애가 발생했을 때, 문제의 원인을 찾는 데만 30분이 걸렸습니다.

"이러다가 큰일 나겠네요." 김개발 씨가 한숨을 쉬었습니다. 박시니어 씨가 말했습니다.

"CloudWatch로 모든 것을 한곳에 모아서 보면 어때요? 대시보드를 만들어두면 한눈에 시스템 상태를 파악할 수 있어요." 그렇다면 CloudWatch란 정확히 무엇일까요?

쉽게 비유하자면, 마치 비행기 조종석의 계기판과 같습니다. 조종사는 수백 개의 계기를 보면서 비행기의 상태를 파악합니다.

연료량, 고도, 속도, 엔진 온도 등이 모두 한 곳에 표시됩니다. 이상 수치가 나타나면 경고등이 켜집니다.

CloudWatch도 마찬가지로 모든 서비스의 상태를 한 곳에 모아서 보여주고, 문제가 생기면 알람을 보냅니다. CloudWatch가 없던 시절에는 어땠을까요?

각 서비스마다 별도의 모니터링 도구를 사용해야 했습니다. 데이터베이스는 A 도구, 서버는 B 도구, 애플리케이션은 C 도구.

장애가 발생하면 여러 도구를 돌아다니며 로그를 확인해야 했습니다. 연관 관계를 파악하기가 매우 어려웠습니다.

CloudWatch는 세 가지 핵심 기능을 제공합니다. 첫째, 메트릭입니다.

CPU 사용률, 메모리, 네트워크 트래픽 같은 수치 데이터를 수집합니다. SageMaker 엔드포인트의 호출 횟수, 지연 시간 등도 자동으로 수집됩니다.

둘째, 로그입니다. 애플리케이션 로그, 학습 로그, Lambda 실행 로그 등을 중앙 집중식으로 저장하고 검색할 수 있습니다.

셋째, 알람입니다. 특정 조건이 충족되면 이메일, SMS, Slack 등으로 알림을 보냅니다.

위의 코드를 살펴보겠습니다. put_metric_data로 커스텀 메트릭을 발행합니다.

SageMaker가 기본으로 제공하는 메트릭 외에도 비즈니스에 중요한 지표를 직접 추가할 수 있습니다. put_metric_alarm으로 알람을 설정합니다.

예측 지연 시간이 100ms를 3회 연속 초과하면 SNS로 알림이 갑니다. 대시보드를 만들면 여러 메트릭을 한 화면에서 볼 수 있습니다.

실제 현업에서는 운영 대시보드를 구성합니다. 상단에는 시스템 전체 상태를 보여주는 요약 위젯을 배치합니다.

녹색이면 정상, 빨간색이면 장애. 그 아래에는 각 서비스별 상세 메트릭이 표시됩니다.

엔드포인트 호출량, 평균 지연 시간, 에러율 등. 문제가 생기면 드릴다운하여 상세 로그를 확인할 수 있습니다.

하지만 주의할 점이 있습니다. 커스텀 메트릭을 너무 많이 발행하면 비용이 증가합니다.

필요한 메트릭만 선별하여 사용하세요. 또한 알람을 너무 민감하게 설정하면 알람 피로가 생깁니다.

중요하지 않은 알람이 자주 울리면 정작 중요한 알람을 놓칠 수 있습니다. 김개발 씨는 CloudWatch 대시보드를 만든 후 모니터링이 훨씬 편해졌습니다.

아침에 출근하면 대시보드를 한 번 확인하는 것으로 시스템 전체 상태를 파악할 수 있었습니다. "이제 진짜 MLOps 엔지니어가 된 것 같아요!" 박시니어 씨가 웃으며 말했습니다.

"이제 시작이에요. 갈 길이 멀어요."

실전 팁

💡 - 중요한 메트릭은 대시보드 상단에 배치하여 한눈에 보이게 하세요

• 알람 임계값은 과거 데이터를 분석하여 합리적으로 설정하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!