FM 배포 전략: Bedrock vs SageMaker
AWS에서 파운데이션 모델(FM)을 애플리케이션에 통합할 때 첫 번째 결정은 Amazon Bedrock과 Amazon SageMaker 중 어느 경로를 선택하느냐입니다. 이 선택은 모델 커스터마이징 필요성, 운영 복잡도 허용 수준, 비용 구조 선호도에 따라 달라집니다.
| 기준 | Amazon Bedrock | Amazon SageMaker | |------|--------------|----------------| | 인프라 관리 | 완전 관리형 (서버리스) | 인스턴스 유형·수 직접 선택 | | 지원 모델 | AWS 파트너 모델 (Claude, Titan, Llama 등) | 오픈소스 모델, 커스텀 모델 모두 지원 | | 파인튜닝 | Bedrock Fine-tuning (제한적) | 전체 학습·파인튜닝 파이프라인 | | 과금 방식 | 토큰 단위 종량제 | 인스턴스 가동 시간 | | 적합한 시나리오 | API 호출로 즉시 사용, 프로토타이핑~프로덕션 | 커스텀 모델, 고성능 특화 워크로드 |
AIP-C01 시험에서 핵심 판단 기준은 다음과 같습니다. 사전 학습된 FM을 그대로 또는 약간의 파인튜닝으로 사용할 수 있다면 Bedrock가 먼저입니다. 완전히 커스텀 모델을 학습하거나 특정 GPU 인스턴스가 필요하다면 SageMaker입니다.
SageMaker 추론 엔드포인트 유형
SageMaker는 워크로드 특성에 따라 네 가지 추론 엔드포인트를 제공합니다. 시험에서 어떤 시나리오에 어떤 유형을 선택해야 하는지 자주 출제됩니다.
실시간 엔드포인트(Real-time Inference)는 항상 가동 중인 인스턴스로 즉각적인 응답을 제공합니다. 초지연(p50 < 100ms) 요구사항이나 24/7 트래픽이 예상되는 프로덕션 서비스에 적합합니다. 오토스케일링 설정으로 트래픽 변동에 대응합니다. 단, 유휴 시간에도 인스턴스 비용이 발생합니다.
서버리스 추론(Serverless Inference)은 요청이 없을 때 인스턴스가 없으며, 요청 시 자동으로 컴퓨팅을 프로비저닝합니다. 메모리 크기와 동시성 설정만 필요합니다. 콜드 스타트 지연(수 초)이 있으므로 초저지연이 요구되는 서비스에는 부적합합니다. 예측 불가능한 트래픽이나 낮은 평균 트래픽의 서비스에 비용 효율적입니다.
비동기 추론(Asynchronous Inference)은 요청을 S3에 대기열로 넣고 처리가 완료되면 결과를 S3에 저장합니다. 응답 시간이 길거나(1분~15분) 대용량 페이로드(최대 1GB)를 처리할 때 사용합니다. SNS 또는 S3 이벤트로 완료 알림을 받습니다. 대규모 문서 처리, 동영상 분석처럼 긴 처리 시간이 필요한 GenAI 파이프라인에 적합합니다.
배치 변환(Batch Transform)은 S3의 대용량 데이터셋에 일괄 추론을 실행합니다. 엔드포인트 없이 잡 실행 후 종료됩니다. 전체 카탈로그 임베딩 생성, 대규모 분류 작업 등 주기적 배치 처리에 비용 효율적입니다.
Bedrock InvokeModel API vs Converse API
Bedrock에서 모델을 호출하는 방법은 두 가지입니다. 각각의 사용 목적과 차이를 정확히 이해하는 것이 실무와 시험 모두에서 중요합니다.
API는 특정 모델의 네이티브 요청/응답 형식을 그대로 사용합니다. Claude, Titan, Llama 각각이 서로 다른 요청 스키마를 가집니다. 모델 고유 기능(예: Claude의 system prompt 형식)을 세밀하게 제어하거나, 특정 모델의 최신 파라미터를 사용할 때 선택합니다.
API는 모든 Bedrock 모델에 대해 통일된 인터페이스를 제공합니다. 멀티턴 대화, 시스템 프롬프트, 이미지 입력, tool use를 표준화된 형식으로 처리합니다. 여러 모델을 실험하거나 나중에 모델을 교체할 가능성이 있을 때 API를 쓰면 모델 교체 시 코드 변경이 최소화됩니다.
실무 권장 사항은 명확합니다. 신규 프로젝트에서는 API를 먼저 고려하고, 모델 특화 기능이 필요할 때만 로 내려갑니다.
스트리밍 응답 구현
LLM 응답을 사용자에게 실시간으로 스트리밍하면 사용자 경험이 크게 향상됩니다. 전체 응답이 생성될 때까지 기다리는 것보다 토큰이 생성되는 즉시 화면에 표시되는 것이 훨씬 자연스럽습니다.
Bedrock에서 스트리밍은 API와 API로 구현합니다. 두 API 모두 서버-전송 이벤트(SSE, Server-Sent Events) 스트림을 반환합니다. Boto3에서는 다음처럼 처리합니다.
프론트엔드에서 스트리밍을 표시할 때는 API Gateway WebSocket 또는 HTTP API의 청크 응답 기능을 사용합니다. Lambda에서 스트리밍을 활성화하려면 를 설정하고 Lambda Web Adapter를 사용합니다. AWS AppSync GraphQL의 실시간 구독도 GenAI 스트리밍 패턴으로 활용할 수 있습니다.
중요한 운영 고려사항이 있습니다. API Gateway의 기본 통합 타임아웃은 29초입니다. 스트리밍 응답이 30초를 초과할 수 있다면 WebSocket API나 Lambda 직접 호출을 고려해야 합니다.
AWS SDK 통합: Boto3와 JavaScript SDK
Bedrock API는 AWS SDK를 통해 모든 주요 언어에서 사용 가능합니다. 실무에서 가장 많이 쓰이는 두 SDK의 핵심 사용 패턴을 살펴봅니다.
Boto3(Python)에서 Bedrock Runtime 클라이언트를 생성하고 메서드를 호출하는 기본 패턴은 다음과 같습니다.
JavaScript SDK v3에서는 패키지를 사용합니다. 모듈형 임포트로 번들 크기를 최소화할 수 있어 Lambda 콜드 스타트 시간에 유리합니다.
SDK 사용 시 재시도 로직에 주의가 필요합니다. Bedrock API는 처리량 초과(ThrottlingException) 오류를 반환할 수 있습니다. AWS SDK는 기본적으로 지수 백오프(exponential backoff)로 재시도하지만, 재시도 횟수와 대기 시간을 애플리케이션 요구사항에 맞게 조정하는 것이 중요합니다.
API Gateway + Lambda 패턴으로 GenAI API 구축
내부 FM 호출을 외부에 안전하게 노출하는 표준 패턴은 API Gateway + Lambda 조합입니다.
HTTP API의 경우 REST API보다 지연 시간이 낮고 비용이 저렴합니다. 대부분의 GenAI API에는 HTTP API로 충분합니다. Lambda 통합 시 Lambda가 Bedrock를 호출하고 결과를 반환합니다. Lambda 실행 역할에 권한을 부여하는 것을 잊지 마세요.
API Gateway에 인증을 추가할 때는 세 가지 방법이 있습니다.
Cognito User Pool: 사용자 로그인 기반 JWT 토큰 인증 Lambda Authorizer: 커스텀 토큰 검증 로직 (API 키, 외부 IdP) IAM Authorization: AWS 서비스 간 통신 (SigV4 서명)
외부 사용자가 접근하는 API라면 Cognito + API Gateway 조합이 표준입니다. 내부 서비스 간 통신이라면 IAM Authorization이 더 적합합니다.
스로틀링과 사용량 계획(Usage Plan)도 중요합니다. API Gateway의 Usage Plan으로 API 키별 요청 한도를 설정하면 특정 사용자의 과다 호출이 전체 서비스에 미치는 영향을 제한할 수 있습니다. Bedrock API 자체의 계정 수준 처리량 한도도 있으므로, 고트래픽 서비스는 Bedrock 처리량 증가를 AWS에 요청해야 합니다.
이벤트 기반 아키텍처
모든 AI 처리가 실시간 응답을 필요로 하지는 않습니다. 이메일 요약, 대용량 문서 분류, 야간 배치 분석처럼 비동기 처리가 적합한 워크로드에는 이벤트 기반 아키텍처가 효과적입니다.
가장 일반적인 패턴은 다음과 같습니다. 사용자가 S3에 파일을 업로드하면 S3 이벤트 알림이 SNS 토픽으로 전달됩니다. SNS가 SQS 큐에 메시지를 전달하고, Lambda가 SQS 큐를 폴링하여 Bedrock 처리를 수행합니다. 처리 결과는 S3에 저장하고 SNS를 통해 완료 알림을 발송합니다.
SQS를 중간에 두는 이유는 중요합니다. Lambda가 직접 S3 이벤트에 반응하면 대량 파일 업로드 시 Lambda 동시성 한도에 도달할 수 있습니다. SQS 큐가 버퍼 역할을 하여 Lambda 함수의 동시성을 제어하고(배치 크기, 동시성 한도 설정), Bedrock API 스로틀링에도 유연하게 대응합니다.
EventBridge는 다양한 AWS 서비스와 SaaS 파트너의 이벤트를 수신하여 규칙 기반으로 Lambda, SQS, SNS 등으로 라우팅합니다. 예를 들어 Salesforce에 새 고객 케이스가 생성될 때 자동으로 Bedrock 기반 답변 초안을 생성하는 파이프라인을 EventBridge + Lambda + Bedrock 조합으로 구축할 수 있습니다.
DLQ(Dead Letter Queue) 설정도 필수입니다. Bedrock 처리 실패 메시지가 SQS에서 계속 재처리되는 것을 방지하고, 실패 메시지를 별도 큐에 보관하여 나중에 분석하고 재처리합니다.
!이벤트 기반 GenAI 처리 파이프라인
마이크로서비스와 서킷 브레이커 패턴
GenAI 기능을 마이크로서비스로 설계할 때 서킷 브레이커 패턴은 안정성에 필수입니다. Bedrock API가 일시적으로 과부하 상태일 때, 계속 실패하는 요청을 반복하지 않고 일정 시간 동안 "회로를 차단"하여 오류가 전체 서비스로 전파되는 것을 막습니다.
AWS에서 서킷 브레이커를 구현하는 방법은 여러 가지입니다. AWS App Mesh와 Envoy 프록시를 사용하면 마이크로서비스 레벨에서 서킷 브레이커를 설정할 수 있습니다. Lambda에서는 AWS SDK의 재시도 설정을 제어하고, ElastiCache에 실패 횟수를 캐시하여 직접 구현할 수 있습니다. AWS Resilience Hub는 이러한 복원력 패턴을 평가하고 개선 권고를 제공합니다.
Bedrock의 처리량 한도(분당 토큰 한도, 분당 요청 한도)를 모니터링하는 것도 중요합니다. CloudWatch 메트릭의 와 를 대시보드에 추가하고 알람을 설정하세요.
Amazon Q Developer와 개발자 생산성
Amazon Q Developer(구 CodeWhisperer)는 IDE에 직접 통합되는 AI 코딩 어시스턴트입니다. AIP-C01 시험에서 "개발자 생산성 향상을 위한 AI 도구"로 자주 등장합니다.
주요 기능은 다음과 같습니다.
코드 자동 완성: 주석이나 함수 시그니처를 기반으로 완전한 코드 블록 제안 보안 취약점 스캔: AWS 보안 모범 사례 기반으로 코드의 취약점 감지 및 수정 제안 참조 추적: 오픈소스 코드와 유사한 제안 시 라이선스 정보 표시 자연어 → 코드: "S3에서 파일을 읽어서 DynamoDB에 저장하는 Lambda"라고 설명하면 완성 코드 생성
Amazon Q Developer는 개인 무료 플랜과 Pro 플랜이 있습니다. Pro 플랜에서는 조직 코드베이스를 기반으로 커스터마이징된 제안을 받을 수 있습니다(Amazon Q Developer customization). 이 기능은 기업 내부 라이브러리나 코딩 컨벤션을 AI가 학습하여 더 관련성 높은 코드를 제안하게 합니다.
시험에서 "개발자가 AWS SDK를 사용하는 코드 작성 시간을 줄이는 방법"이나 "코드 보안 취약점 자동 탐지 도구"로 Amazon Q Developer가 등장합니다.
에러 핸들링과 재시도 전략