AWS Certified Generative AI Developer - Professional 시험 대비 치트 시트 ─ 유사 서비스의 용도

AWS Certified Generative AI Developer - Professional 시험 대비, 의외로 만만치 않다. 대비 과정에서 배운 내용을 정리한다.

(※ 주의) 개인적인 학습 중의 메모이며, 합격을 보장하는 것은 아니다. 표 중의 서비스 선정은 AWS의 공식 문서 및 공개 블로그에서 다루는 베스트 프랙티스(Best Practices)를 자신을 위해 다시 정리한 것이며, 특정 시험 문제의 정답을 나타내는 것은 아니다.

원칙 1: AWS의 도구 상자를 먼저 열어본 뒤에 작성한다

원칙 2: 서비스의 특화 영역과 워크로드(Workload)를 일치시킨다

원칙 3: 부품 간의 의존성과 순서를 읽는다

원칙 1은, 직접 코드를 작성하기 전에 내장된 기능을 찾는다. Lambda로 래핑(Wrap)하여 공통 처리를 넣고 싶어지는 상황에서, IAM 조건 키(Condition Key)나 서비스의 파라미터(Parameter)를 통해 AWS 측에서 동일한 작업을 수행하게 하는 메커니즘이 있다.

원칙 2는, 서비스를 '캐치프레이즈'만 보고 선택하지 않는다. 기능뿐만 아니라 과금 모델과 워크로드의 정합성까지 확인하지 않으면, 저빈도 워크로드나 특수한 요구사항에서 어긋나게 된다.

원칙 3은, 컴포넌트(Component) 간의 관계를 읽는다. 순서, 버퍼(Buffer), 의존성. 검증 단계는 생성(Generation) 다음에 온다. 서비스 이름으로 역할을 연상하면 틀리기 쉽다.

요구사항 카테고리	주요 후보	분기 로직
벡터 스토어 (Vector Store)	OpenSearch / Amazon S3 Vectors (2025 GA) / RDS pgvector	상시 고 QPS라면 OpenSearch, 저빈도·대규모라면 S3 Vectors, 메타데이터를 통한 SQL 조인이 필요하다면 pgvector
...	가드레일(Guardrail)을 경유한 호출을 강제하려면 GuardrailIdentifier, 이용 가능한 모델을 한정하려면 FoundationModelIdentifier
로그·감사 + 장기 보관	CloudTrail / CloudWatch Logs / Bedrock 모델 호출 로그 + S3 Object Lock	API 메타데이터는 CloudTrail, 처리 내부 정보는 CloudWatch Logs, 프롬프트와 응답의 실제 내용은 모델 호출 로그. N년 보관·변조 방지는 S3 Object Lock의 컴플라이언스 모드(Compliance Mode) 병용 (출력 대상 버킷의 버전 관리 활성화 및 Bedrock으로부터의 쓰기 권한 확인)
PII 처리	Macie / Comprehend / Bedrock Guardrails	저장된 데이터의 탐지·통지는 Macie, 데이터 레이크(Data Lake) 수집 전의 배치(Batch) 변환·마스킹은 Comprehend, 추론 시(입출력)의 실시간 탐지·마스킹·차단은 Guardrails
프롬프트 관리	Bedrock Prompt Management / Git + 자체 관리	버전 관리와 승인 플로우(Approval Flow)를 내장 기능으로 원한다면 Prompt Management, 가볍게 사용하려면 Git
에이전트 구현	Amazon Bedrock Agents / Bedrock AgentCore Runtime / 자체 컨테이너 (ECS 등)	사전 정의된 액션(Action)·지식 베이스(Knowledge Base) 호출 등 Bedrock 내에서 완결된다면 Agents, HTTP 서버 설정이나 컨테이너화까지 매니지드(Managed)로 하고 싶다면 AgentCore Runtime, 기존 인프라 통합이나 자유도 중시라면 자체 컨테이너

유사한 서비스의 혼동으로 틀리는 경우가 많다. 세 가지만 적어둔다.

Macie와 Comprehend와 Guardrails: 처리 타이밍으로 구분

Macie는 S3 내의 PII(개인 식별 정보)를 탐지하여 통지하는 감사용이다. 데이터를 수정하는 기능은 없다. Comprehend는 배치·전처리 단계에서 PII를 마스킹(Masking)하는 변환용이다 (데이터 레이크 수집 전 등). Bedrock Guardrails는 추론 시의 입출력에 대해 실시간으로 마스킹(Anonymize) 또는 차단을 수행한다. "저장된 데이터의 감사 / 수집 전의 변환 / 추론 시의 실시간 제어" 중 어느 타이밍이 요구사항인지에 따라 구분하여 사용한다.

OpenSearch와 S3 Vectors: 가동 패턴으로 결정

OpenSearch는 OCU의 상시 과금 방식으로, 고 QPS 워크로드에서는 성능과 비용 양면에서 유리하다. 검색 빈도가 낮은 대규모 벡터라면 비용이 높아지므로, 종량제인 S3 Vectors가 유리하다. "벡터 검색"을 어떤 가동 패턴으로 사용할지에 따라 갈린다.

CloudTrail과 서비스 고유 로그: 입도(Granularity)를 구분하여 읽기

CloudTrail은 API 메타데이터를 감사하며, "지식 기반(Knowledge Base)이 호출되었다"는 사실은 알 수 있지만 "어떤 문서가 가져오기(Ingestion)에 실패했는지"는 기록하지 않는다. 처리의 내부 상태가 필요하다면, 서비스가 CloudWatch Logs에 남기는 로그를 확인한다. 프롬프트(Prompt)와 모델 응답(Model Response)의 실제 내용을 남기고 싶다면, Bedrock의 모델 호출 로그를 사용한다. "감사(Audit)"가 지칭하는 입도(Granularity)를 가장 먼저 확인한다.

원칙의 번호 순서대로 그대로 적용한다.

• 선택지에 "직접 구현(Self-implement)", "Lambda로 래핑(Wrap with Lambda)", "정기적인 스케줄로 ~"가 포함되어 있다면 → 원칙 1로 걸러낸다.
• 남은 후보가 요구사항의 워크로드 특성(빈도·크기·지연 시간(Latency))과 맞는지 → 원칙 2로 확인한다.
• 순서나 연결이 얽힌 문제 → 원칙 3으로 데이터의 흐름을 추적한다.