🧠 ML 추론 파이프라인

왜 이걸 만들까? — 수천 건의 데이터를 AI가 자동 처리해야 할 때

여러분이 이커머스 회사의 데이터 엔지니어라고 상상해 보세요.

매일 고객 리뷰가 500건씩 올라옵니다. 마케팅팀은 "리뷰의 감성(긍정/부정)을 분석해 주세요"라고 요청하지만, 500건을 사람이 일일이 읽고 분류하는 건 불가능합니다.

AI 챗봇(이전 실습)에서는 1건씩 실시간으로 처리했습니다. 하지만 이번에는 다릅니다:

• 500건을 한꺼번에 자동으로 처리해야 합니다
• 처리 중 일부가 실패하더라도 나머지는 계속 진행해야 합니다
• 모든 결과를 S3에 저장하고, 완료 시 알림을 보내야 합니다
• 매일 같은 시간에 자동으로 실행되면 좋겠습니다

이런 요구사항은 단순 Lambda 하나로는 해결할 수 없습니다. AWS Step Functions이 필요한 순간입니다.

Step Functions는 여러 Lambda 함수를 워크플로(Workflow)로 연결하는 오케스트레이션 서비스입니다. 특히 Map 상태를 사용하면, 입력 배열의 각 항목을 병렬로 처리할 수 있습니다.

이 실습에서는:

• S3: 입력 데이터(리뷰 목록)와 추론 결과를 저장
• Lambda: 각 리뷰를 Bedrock Claude에 보내 감성 분석 수행
• Step Functions: Map 상태로 리뷰 배열을 병렬 처리, 에러 처리/재시도 내장
• SNS: 파이프라인 완료 시 이메일 알림 발송

완성하면 JSON 파일 하나를 Step Functions에 넣으면, 각 항목이 자동으로 AI 분석되고 결과가 S3에 저장되며, 완료 알림 이메일이 도착합니다.

이 프로젝트를 통해 배우게 되는 것:

• Step Functions 워크플로 설계: Map 상태를 사용한 병렬 배치 처리
• 에러 복원력: Retry/Catch로 개별 실패가 전체 파이프라인을 중단시키지 않는 설계
• Bedrock 배치 추론: API 쿼터를 고려한 동시 실행 수 제어
• 이벤트 기반 알림: SNS를 활용한 파이프라인 완료 알림
• 추론 vs 학습: Lambda가 ML에서 어떤 역할을 하는지 이해

아키텍처 개요

파이프라인 실행 흐름

비용 예측

Step 1: Bedrock 모델 접근 활성화

이전 실습(AI 챗봇 with Bedrock)에서 이미 활성화했다면 이 단계를 건너뛰어도 됩니다. 하지만 반드시 us-east-1 리전에서 Claude 3 Haiku 모델 상태가 "접근 허용됨"인지 확인하세요.

aws bedrock list-foundation-models \
  --query "modelSummaries[?modelId=='anthropic.claude-3-haiku-20240307-v1:0'].{id:modelId,status:modelLifecycle.status}" \
  --output table

Step 2: Lambda 추론 함수 생성

이 Lambda 함수는 단일 리뷰 텍스트를 받아 Bedrock Claude에게 감성 분석을 요청하고, 결과를 S3에 JSON으로 저장합니다. Step Functions의 Map 상태가 이 함수를 배열의 각 항목마다 호출합니다. 따라서 이 함수는 1건만 처리하는 단순한 구조로 설계합니다.

중간 점검: Lambda 단건 테스트

Step Functions 워크플로를 구성하기 전에, Lambda 함수가 단독으로 정상 작동하는지 반드시 확인합니다. 복잡한 파이프라인에서 문제가 생기면 원인 추적이 어렵기 때문에, 가장 작은 단위부터 검증하는 것이 핵심입니다.

테스트 이벤트 JSON:

{
  "item_id": "test_001",
  "input_text": "배송이 빨라서 매우 만족합니다.",
  "output_bucket": "ml-pipeline-lab-계정ID"
}

Lambda 콘솔에서 테스트 버튼을 클릭하고, S3 results/test_001.json 파일이 생성되었는지, 내용에 감성 분석 결과가 포함되어 있는지 확인합니다. 이 단계에서 문제가 없어야 다음으로 진행합니다.

Step 3: Step Functions 워크플로 구성

Step Functions는 이 파이프라인의 지휘자(Conductor) 역할을 합니다. 입력 배열을 받아 각 항목을 Lambda로 분배(Map 상태)하고, 모든 처리가 끝나면 결과를 집계하여 SNS로 알림을 보냅니다. 개별 항목이 실패해도 나머지는 계속 처리됩니다(Retry/Catch 설정).

aws stepfunctions create-state-machine \
  --name ml-inference-pipeline \
  --definition file://pipeline-definition.json \
  --role-arn arn:aws:iam::ACCOUNT_ID:role/StepFunctionsMLPipelineRole

Step 4: S3 입출력 및 파이프라인 실행

실제 데이터를 준비하고 파이프라인을 실행합니다. 고객 리뷰 3~5건을 JSON 형식으로 작성하여 입력으로 사용합니다. Step Functions 콘솔에서 실행 상태를 실시간으로 모니터링할 수 있습니다.

Step 5: 결과 집계 및 SNS 완료 알림

파이프라인이 완료되면 팀에게 자동으로 이메일 알림을 보내도록 SNS를 설정합니다. 이메일에는 처리 건수, 성공/실패 건수, S3 결과 경로가 포함됩니다.

핵심 개념 확인

트러블슈팅 가이드

완성 후 테스트 가이드

전체 파이프라인을 체계적으로 검증하세요:

1. 단건 테스트: Lambda 함수를 직접 테스트 이벤트로 호출 → S3에 결과 JSON 생성 확인
2. 파이프라인 실행: 3건 입력 → Step Functions 그래프 뷰에서 모든 항목 녹색(성공) 확인
3. 결과 검증: S3 results/ 폴더에 3개의 JSON 파일 존재 확인 → 감성, 키워드, 신뢰도 포함 여부
4. 에러 핸들링: 의도적으로 빈 input_text 항목 추가 → Retry 후 Catch에서 처리되는지 확인
5. SNS 알림: 파이프라인 완료 후 이메일 수신 확인
6. 성능 측정: 5건 처리 시간 vs 10건 처리 시간 비교 → MaxConcurrency 효과 확인
7. 비용 확인: Bedrock 콘솔에서 토큰 사용량 확인, Step Functions 콘솔에서 상태 전환 수 확인
8. 재실행 테스트: 동일 입력으로 파이프라인을 다시 실행 → S3 결과가 덮어쓰기/중복 없이 처리되는지 확인

확장 아이디어

1. EventBridge 자동 트리거: S3에 새 파일 업로드 시 자동으로 Step Functions가 시작되도록 EventBridge 규칙 설정
2. 멀티 모델 비교: 동일 리뷰를 Claude Haiku, Claude Sonnet, Titan으로 각각 처리하여 결과 품질/비용 비교
3. 결과 대시보드: DynamoDB에 분석 결과를 저장하고, API Gateway + Lambda로 대시보드 조회 API 구축
4. 스케줄 실행: EventBridge Scheduler로 매일 오전 9시에 자동 실행되는 일일 배치 파이프라인 구성
5. Bedrock Batch Inference: Bedrock의 네이티브 배치 추론 API를 활용하면 Lambda 없이도 대량 처리가 가능 — 비용 50% 절감

Step Functions ASL(Amazon States Language) 핵심 구조

Step Functions의 워크플로를 정의하는 JSON 구조를 이해하면 커스터마이징이 훨씬 수월합니다:

{
  "Comment": "ML Inference Pipeline",
  "StartAt": "ProcessItems",
  "States": {
    "ProcessItems": {
      "Type": "Map",
      "ItemsPath": "$.items",
      "MaxConcurrency": 5,
      "Iterator": {
        "StartAt": "InvokeInference",
        "States": {
          "InvokeInference": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:ACCOUNT:function:bedrock-inference-fn",
            "Retry": [
              {
                "ErrorEquals": ["States.TaskFailed"],
                "IntervalSeconds": 5,
                "MaxAttempts": 2,
                "BackoffRate": 2.0
              }
            ],
            "End": true
          }
        }
      },
      "Next": "SendNotification"
    },
    "SendNotification": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sns:publish",
      "Parameters": {
        "TopicArn": "arn:aws:sns:us-east-1:ACCOUNT:ml-pipeline-complete",
        "Message": "ML 추론 파이프라인이 완료되었습니다."
      },
      "End": true
    }
  }
}

실습 후 사고 실험

실습에서는 3건의 리뷰를 처리했습니다. 실제 운영 환경에서는 어떻게 확장할까요?

일 500건 처리 시나리오:

• MaxConcurrency=10으로 설정하면, 50배치 x 각 30초 ≈ 약 25분 소요
• Bedrock 비용: 500건 x 평균 500토큰 = 250K 입력토큰 ≈ 약 $0.06/일
• Step Functions 비용: 500 상태전환 x $0.000025 = $0.0125/일

에러 복원력 시나리오:

• 500건 중 3건이 Bedrock 타임아웃 → Retry로 자동 재시도 후 2건 성공, 1건 최종 실패
• Catch 블록이 실패 항목을 별도 에러 리스트에 기록 → 나중에 재처리 가능
• 나머지 497건은 정상 처리 — 전체 파이프라인은 성공으로 완료

학습 정리

리소스 정리