얼마 전, AWS의 새로운 프로페셔널 인증 자격인 「AWS Certified Generative AI Developer - Professional (AIP-C01)」을 응시하여 850점으로 합격했습니다.

시험 시간은 3시간의 장기전이지만, 실제로는 1시간 정도 만에 문제를 다 풀었으며, 시간에 쫓기지 않고 검토까지 완료할 수 있었습니다. 본 기사에서는 합격까지 준비한 내용과 시험에서 빈출되는 「실무 직결 초중요 기술 테마 17선」을 체계화하여 해설합니다.

합격 수기와 AIP-C01의 시험 경향

실제로 응시하며 느낀 경향과 대책 포인트를 정리합니다.

문제문은 짧은 편 (SAP만큼 길지 않음)

AWS의 프로페셔널 시험이라고 하면, SAP (Solutions Architect - Professional)와 같은 「읽기만 해도 지치는 장문 시나리오」를 상상할 수도 있겠지만, AIP-C01은 그 정도로 길지 않습니다.

문제문의 상황 설정이 비교적 심플하기 때문에, 독해에 시간을 빼앗길 걱정은 적은 편입니다. 차분하게 문제를 읽고 최적의 선택지를 고를 여유가 있습니다.

시험의 전체적인 경향과 요구되는 지식

단순한 생성형 AI (Generative AI) 용어 암기가 아니라, 「AWS 서비스와 어떻게 조합할 것인가」라는 구현·운영 중심의 지식이 중시됩니다. 특히 다음의 세 가지 관점이 많이 출제되었습니다.

매니지드 기능 우선: Bedrock나 Kendra 등의 네이티브 기능을 우선시하여, 가급적 자체 개발이나 운영 (오버헤드)을 줄이는 구성이 정답이 되기 쉽습니다. -
보안 통합 설계: VPC나 IAM을 통한 액세스 제한, Guardrails를 통한 유해 출력 대책, Comprehend를 이용한 기밀 데이터 마스킹 등, 보안 및 컴플라이언스 관련 설계가 큰 비중을 차지합니다. -
머신러닝의 기본 원칙: 데이터 전처리나 평가 방법 (모델 평가), 과적합 (Overfitting) 대책 등, 생성형 AI 이전의 기본적인 ML 컨셉도 직설적으로 출제됩니다.

그럼, 합격을 위해 파악해 두어야 할 최중요 테마 17선을 살펴보겠습니다.

카테고리 A: 생성형 AI 모델의 평가와 안전성 (Model Evaluation & Safety)

1. LLM/챗봇의 자동 평가와 정밀도 측정

대규모 언어 모델 (LLM)이나 챗봇의 응답 품질을 평가할 때, 수동 평가에는 한계가 있습니다. AWS에서 권장하는 자동 평가 프로세스는 다음과 같은 흐름입니다.

Amazon Bedrock Model Evaluations를 사용하여 자동 평가 작업을 실행한다. -
사실 지식이나 현실 세계의 정확성을 평가하기 위해 특별히 설계된 T-REx (TREX) 등의 평가 데이터셋을 사용한다. -
산출된 RWK (Real World Knowledge) 스코어를 사용하여, 모델이 현실 세계의 지식에 의존하는 응답을 얼마나 정확하게 생성할 수 있는지 정량적으로 평가한다.

[!WARNING]

시험 대비 함정

A/B 테스트: 사용자의 반응이나 모델 간의 상대적 비교에 사용하는 것으로, 「사실의 정확성」을 측정하는 데는 적합하지 않습니다. SageMaker Nova의 모델 평가: 모델의 출력이나 성능 비교용이며, RWK와 같이 사실 정확성에 특화된 스코어 측정용은 아닙니다. WikiText-2 데이터셋: 언어 모델링 (유창성이나 일관성) 평가용이며, 특정 사실 지식을 평가하기에는 적합하지 않습니다.

2. 생성형 AI의 안전성과 가드레일 (Bedrock Guardrails)

금융이나 의료 등 규제가 엄격한 업계에서 대화형 AI를 배포할 경우, 유해 출력 방지나 기밀 데이터 보호가 필수적입니다. 이를 **최소한의 운영 오버헤드 (노코드/로코드)**로 충족하려면 Amazon Bedrock Guardrails가 최적입니다.

콘텐츠 필터 (Content filters)

혐오 (Hate), 모욕 (Insults), 성적 (Sexual), 폭력 (Violence), 불법 행위 (Misconduct) 등의 카테고리를 단계적으로 차단합니다. -
워드 필터 (Word filters)

일반적인 비속어 필터 외에도, 커스텀 정의한 금지 단어 (경쟁사 이름 등)를 최대 10,000건까지 완전 일치로 차단할 수 있습니다. -
컨텍스트 그라운딩 체크 (Contextual grounding checks)

모델의 출력이 제공된 참조 소스(Knowledge Base 등의 사실)에 근거하고 있는지(할루시네이션 (Hallucination)이 없는지)를 검증하여, 사실에 기반하지 않은 정보나 기밀 정보의 유출을 동적으로 탐지하고 차단합니다.

카테고리 B: RAG (Retrieval-Augmented Generation) 및 검색 인프라

3. RAG에서의 벡터 데이터베이스 선정 (Aurora PostgreSQL)

RAG 시스템을 구축할 때, 임베딩 벡터 (Vector Embeddings)의 저장소로 적절한 데이터베이스를 선택해야 합니다. 특히 **「구조화된 메타데이터 (설비 유형, 날짜, 중요도 등)와의 결합」**이 요구되는 시나리오에서는 다음 구성이 최적입니다.

Amazon Aurora (PostgreSQL Compatible) + pgvector 확장 기능-
HNSW (Hierarchical Navigable Small World) 인덱스를 구축함으로써 고속의 근사 최근접 이웃 (ANN, Approximate Nearest Neighbor) 검색을 실현합니다. - 관계형 데이터베이스의 강점을 활용하여, 메타데이터 테이블과 벡터 데이터를 SQL의 JOIN 절로 직접적이고 효율적으로 결합하여 고도화된 필터링을 수행할 수 있습니다. - Aurora PostgreSQL은 Amazon Bedrock의 Knowledge Bases 벡터 스토어로 통합 가능합니다.

[!NOTE]

타 서비스와의 차이점

Amazon OpenSearch Service: 벡터 검색은 강력하지만, 관계형 데이터(복잡한 결합이나 트랜잭션)를 다루는 메타데이터 필터링에 있어서는 Aurora PostgreSQL의 SQL 결합이 표현력과 성능 면에서 더 우수합니다. UDF (사용자 정의 함수)를 통한 코사인 유사도 계산: 풀 스캔 (Full Scan)이 발생하기 때문에 데이터 수가 수백만 건 규모가 되면 성능이 현저히 저하되어 확장(Scale)이 어렵습니다. SageMaker Feature Store: 벡터 유사도 검색이나 메타데이터 결합에 특화되어 있지 않으며, 검색을 위한 실시간 엔드포인트 호출은 레이턴시(Latency)와 구성의 복잡성을 증가시킵니다.

4. RAG의 검색 정밀도 향상 (Reranking)

RAG 파이프라인을 운영하다 보면, "요약의 질이 실제 문서와 일치하지 않게 되었다"는 할루시네이션 문제가 발생할 수 있습니다. 임베딩 모델이나 청크 분할(Chunking) 기법이 적절함에도 문제가 발생한다면, **「취득한 정보의 랭킹 (Reranking)」**이 병목 구간이 되고 있는 것입니다.

Bedrock Knowledge Bases에서의 Reranking 활성화- 벡터 유사도 검색으로 상위(top-k)에 선택된 청크에 대해, 생성 모델로 전달하기 전 관련성이 높은 순으로 재정렬합니다.

Bedrock에서 호스팅되는 Reranker 모델 적용- 단순한 벡터 거리(표면적인 단어의 유사성)뿐만 아니라, 쿼리와 문서의 "의미적 관계"를 깊이 있게 재평가합니다. - LLM 자체의 재학습이나 파인튜닝 (Fine-tuning)을 수행하지 않고도 컨텍스트의 품질을 대폭 향상시킬 수 있습니다.

5. Kendra를 통한 대규모 시맨틱 검색과 S3 통합

S3 버킷 내에 저장된 수 테라바이트 규모의 비구조화 문서(기술 매뉴얼이나 지원 로그 등)로부터 고성능 및 고정밀의 시맨틱 검색 (Semantic Search)을 수행해야 하는 경우, Amazon Kendra가 최적입니다.

Amazon Kendra S3 커넥터를 활용하여 S3 버킷 내의 문서를 원활하게 가져오며, 키워드 일치를 넘어선 문맥 검색 (시맨틱 검색)을 제공합니다. - 기존의 키워드 검색과 달리 질문의 "의미"를 이해하여 정확한 답변을 반환합니다. - DynamoDB + QuickSight 등의 커스텀 구성과 비교하여 인프라 구축 및 관리의 수고를 최소화할 수 있습니다.

6. 풀 매니지드(Fully Managed) RAG 구축 (Bedrock Knowledge Bases)

독자적인 데이터를 활용하여 LLM의 답변을 보강하고 싶다면, RAG 파이프라인 전체를 자동화할 수 있는 Amazon Bedrock Knowledge Bases를 사용하는 것이 최우선 선택지입니다.

• S3 버킷을 데이터 소스로 연결하는 것만으로, Bedrock이 자동으로 **문서 분석 (Document Analysis), 청킹 (Chunking), 임베딩 생성 (Embedding Generation), 벡터 스토어 등록 (Registration to Vector Store)**을 실행합니다. - 새로운 문서가 S3에 추가되면 자동으로 동기화되므로 항상 최신 정보를 참조할 수 있으며, 환각 (Hallucination)을 줄일 수 있습니다.
• 독자적으로 벡터 DB나 임베딩 생성 파이프라인을 커스텀 구축하는 경우에 비해 운영 부하를 압도적으로 줄일 수 있습니다.

7. 서드파티 벡터 DB (Pinecone)와의 RAG 통합

엔터프라이즈 구성에서 매니지드 벡터 데이터베이스로서 실적이 있는 Pinecone과 AWS를 통합하는 구성도 빈번하게 출제됩니다.

• Pinecone을 벡터 스토어로 사용하여 제품 문서를 인덱싱하고, 쿼리에 기반하여 관련 정보를 고속으로 취득합니다. - 취득한 컨텍스트에 대해 Amazon Comprehend를 거치게 함으로써, 감성 분석 (Sentiment Analysis)이나 주요 엔티티 추출 (Entity Extraction)을 전처리로서 실행합니다. - 그 후, 정교화된 컨텍스트를 Amazon SageMaker AI Studio를 통해 Llama 2 등의 파운데이션 모델 (Foundation Model)로 전달하여 응답 생성을 수행합니다.

카테고리 C: API 설계·가용성·부하 대책 (API, High Availability & Throttling)

8. API 스로틀링 (ThrottlingException) 및 레이턴시 대책

고트래픽 시 Amazon Bedrock API를 호출하면 동시 요청 수의 상한에 도달하여 ThrottlingException 에러가 발생할 수 있습니다. 이를 방지하기 위한 베스트 프랙티스는 다음 두 가지입니다.

• AWS SDK에서의 「Jitter(지터)를 포함한 Exponential Backoff(지수 백오프)」 구현 - 단순한 지수 백오프만으로는 여러 클라이언트가 동시에 재시도하는 「Retry Storm(재시도 폭풍)」이 발생합니다.

• 재시도 간격에 랜덤한 값(Jitter)을 더함으로써 요청의 충돌을 평활화하고, API 스로틀링을 회피합니다.

• Amazon API Gateway에서의 클라이언트별 Throttling 설정 - Token Bucket 알고리즘을 이용하여 API 키 (Usage Plan)마다 호출 속도(Rate)와 버스트 크기(Burst Size)의 상한을 설정하여, 백엔드로의 요청 급증을 사전에 방지합니다.

9. 스로틀링·가용성 대책 (Bedrock Cross-Region Inference)

글로벌로 전개하는 애플리케이션에서 단일 리전의 API 스로틀링이나 가용성 저하를 방지해야 하는 경우, 클라이언트 측의 라우팅을 수정하지 않고 해결하는 접근 방식이 요구됩니다.

• **Amazon Bedrock의 교차 리전 추론 (Cross-Region Inference)**을 활성화합니다. - 애플리케이션은 동일한 모델 ID (Inference Profile ID)를 계속 사용하며, Bedrock 측에서 동일한 지리적 영역 내(예: US 내, EU 내)의 건전한 리전으로 자동적이고 투명하게 요청을 분산 및 페일오버 (Failover)합니다.
• 데이터 거주성 (Compliance)을 유지하면서 높은 가용성과 처리량 (Throughput)을 실현할 수 있습니다.

카테고리 D: 머신러닝 (ML) 인프라 및 예측 모델 (ML Infrastructure & Predictive Modeling)

10. 콜드 스타트 수요 예측 (SageMaker DeepAR)

신제품 도입 등으로 인해 「과거 판매 이력이 거의 없거나 전혀 없는 제품 변체 (Cold Start)」에 대한 수요 예측이 요구되는 경우가 있습니다.

• Amazon SageMaker AI의 내장 DeepAR 알고리즘을 사용합니다. - 기존의 ARIMA나 ETS (지수 평활법) 모델은 시계열별로 개별 적합하기 때문에 이력이 없는 신제품에는 작동하지 않습니다.
• DeepAR은 **재귀 신경망 (RNN)**을 사용하여 여러 유사한 시계열 전체 (모든 SKU, 색상, 사이즈 변체 등)에 걸쳐 단일 모델을 공동으로 학습합니다. 이를 통해 기존 SKU로부터 공유 패턴을 학습하여 신상품에 대해서도 정밀도가 높은 확률적 예측을 수행할 수 있습니다.

11. 독자 환경에서의 모델 배포 (SageMaker BYOC)

이미 R 언어 나 Julia 등의 커스텀 라이브러리(Custom Library)·독자 프레임워크로 구축된 고도화된 모델을 SageMaker에서 배포(Deploy)·모니터링(Monitoring)하고 싶은 경우, 기존의 내장 컨테이너나 JumpStart로는 대응할 수 없습니다.

Bring Your Own Container (BYOC) 접근 방식을 채택합니다. -
Dockerfile을 사용하여 모델 동작에 필요한 라이브러리나 의존성(R 실행 환경 등)을 모두 포함한 커스텀 Docker 컨테이너를 구축하고, Amazon ECR (Elastic Container Registry)에 등록합니다. - SageMaker AI 엔드포인트(Endpoint) 생성 시 이 커스텀 컨테이너 이미지를 지정하여 배포함으로써, 운영 부하를 줄이면서 확장 가능한(Scalable) 운영 추론·모니터링을 실현합니다.

12. 장시간·대용량 추론 처리 (SageMaker Asynchronous Inference)

추론 실행 시간이 1822분으로 길고, 페이로드(Payload) 크기가 6MB11MB로 큰 요청을 VPC 내에서 보안을 유지하며 비용 효율적으로 처리하는 구성이 요구됩니다.

**SageMaker Asynchronous Inference (비동기 엔드포인트)**를 프라이빗 서브넷(Private Subnet) 내에 배포합니다. - 비동기 추론은 수신된 요청을 내부 큐잉(Queuing)하여 비동기적으로 처리합니다.
최대 1시간의 실행 시간, 최대 1GB의 페이로드 크기에 대응합니다. -
비용 절감: 요청이 없는 시간대에는 인스턴스 수를 제로까지 오토스케일링 (0-scale) 할 수 있으므로 비용 효율이 매우 높습니다.

[!IMPORTANT]

다른 추론 옵션과의 차이점

실시간 엔드포인트 (Real-time endpoints): 통상 60초의 하드 타임아웃(Hard Timeout) 제한이 있으므로 장시간 처리는 대응할 수 없습니다. 배치 변환 (Batch Transform): 오프라인 일괄 처리용이므로 대화형의 실시간 상호작용에는 적합하지 않습니다.

13. 머신러닝 모델의 과적합 (Overfitting) 대책

모델이 훈련 데이터(Training Data) 내의 노이즈까지 과도하게 학습하여, 새로운 데이터에 대한 정확도(일반화 성능)가 저하되는 문제에 대한 대처법입니다.

L1 / L2 정규화 (Regularization) 도입: 가중치 (Weights)가 극단적으로 커지는 것을 방지하는 페널티 항을 추가합니다. -
Dropout (드롭아웃) 레이어 추가: 뉴럴 네트워크 (Neural Network) 학습 중, 무작위로 일부 뉴런을 비활성화함으로써 특정 특징에 대한 과도한 의존을 방지합니다. -
네트워크 아키텍처 (Network Architecture) 단순화: 레이어의 수나 뉴런 수를 의도적으로 적절한 수준까지 줄임으로써 모델의 데이터 기억 용량을 억제합니다. -
XGBoost 고유 파라미터 조정: max_depth (최대 깊이)를 낮추거나, eta (학습률)를 낮추고, subsample (데이터 샘플링 비율)을 낮추는 등의 조정이 유효합니다.

14. 최소 개발로 구현하는 실시간 이상 탐지 (Firehose + QuickSight)

호텔 객실 수요 등의 실시간 스트리밍 데이터로부터 수요의 급증(이상 징후)을 탐지하고, 대시보드에서 거의 실시간으로 자동 시각화하고 싶지만, 개발 시간을 최소한으로 억제하고 싶다는 요구사항입니다.

Amazon Data Firehose를 사용하여 예약 데이터를 Amazon S3에 직접적이고 지속적으로 스트리밍합니다. -
Amazon QuickSight를 S3 데이터 소스에 연결하고, 내장된 QuickSight ML Insights를 활성화합니다. - QuickSight ML Insights에는 커스텀 머신러닝 모델을 직접 제작·배포하지 않고도 자동으로 이상 징후나 경향을 탐지할 수 있는 내장 기능이 있습니다. 이를 통해 최소한의 개발 공수로 실시간 시각화 대시보드를 완성할 수 있습니다.

카테고리 E: 보안·데이터 보호·컴플라이언스 (Security & Data Protection)

15. SageMaker 노트북의 VPC 내 보안 액세스 제한

사내 보안 정책으로서 인터넷을 통한 노트북 액세스를 일절 금지하고, 인가된 VPC 내에서만 액세스하도록 설정하는 구성입니다.

• SageMaker 노트북이 배치된 VPC와 SageMaker API 사이에 **VPC 인터페이스 엔드포인트 (PrivateLink)**를 설정합니다.
• IAM 정책에서 sagemaker:CreatePresignedNotebookInstanceUrl 및 sagemaker:DescribeNotebookInstance 액션에 대해, "요청이 특정 VPC 엔드포인트로부터 전송된 경우에만 허용"하는 조건(aws:sourceVpce)을 설정합니다.
• 이를 통해 인터넷을 통한 Presigned URL 생성 및 노트북 액세스를 완전히 차단할 수 있습니다.

16. 민감 정보 (PII/PHI) 자동 탐지 및 보호

RAG용 데이터 수집 또는 모델 학습 전에, 데이터 프라이버시 기준 (GDPR, HIPAA 등)을 충족하기 위해 민감 정보를 식별하고 삭제하는 기법입니다.

• Amazon Comprehend를 사용하여 성명, 전화번호, 주소, SSN, 신용카드 번호와 같은 일반적인 개인 정보를 자동으로 탐지하여 마스킹 또는 삭제합니다.
• 의료 분야에 특화된 데이터에는 Amazon Comprehend Medical을 적용합니다. 보호 대상 보건 정보 (PHI)를 확실히 보호하면서도, 의료 코드, 약물명, 병명, 치료 계획 등 실무에 필요한 임상 데이터를 유지한 상태로 추출할 수 있습니다.

17. 고급 데이터 보호 및 민감 정보 삭제 (AWS KMS, AWS Glue)

부정 거래 식별 모델 등을 구축하기 전 단계에서, 데이터 암호화와 신용카드 번호와 같은 PII 삭제를 확실하게 파이프라인화하는 구성입니다.

• 데이터를 SageMaker로 가져오기 전에, **Amazon S3에서 AWS KMS (Key Management Service)**를 사용하여 서버 측 암호화 (Server-side encryption)를 적용합니다.
• 암호화된 원천 데이터에서 **AWS Glue Studio의 "Detect PII transform"**을 이용하여 신용카드 번호를 자동으로 식별 및 삭제(마스킹)한 후, 정제된 데이터를 모델 학습용으로 S3에 재저장합니다.
• AWS Glue의 Detect PII transform은 사전 정의된 엔티티 유형 (신용카드, 주소, 전화번호 등)을 안전하게 마스킹할 수 있어 개발의 복잡성을 제거할 수 있습니다.

시험 합격을 위한 조언

AIP-C01 시험에서 고득점을 노리는 가장 큰 비결은 **"가급적 코드를 작성하거나 모델을 직접 구현하지 않고, AWS의 네이티브 기능으로 해결하는 최단 경로"**를 빠르게 파악하는 것입니다.

시험에서는 다음과 같은 과제에 대해 특정 구성이 전형적인 정답 패턴으로 등장합니다.

• 코드를 거의 작성하지 않고 해결하고 싶은 경우
  QuickSight ML Insights, Bedrock Guardrails, AWS Glue의 Detect PII와 같은 내장 기능을 우선적으로 선택합니다.
• RAG의 할루시네이션 (Hallucination)을 억제하면서 데이터를 항상 최신 상태로 동기화하고 싶은 경우
  Bedrock Knowledge Bases를 사용하는 구성이 정석입니다.
• 모델은 변경하지 않으면서 도메인 지식에 관한 할루시네이션을 방지하고 싶은 경우
  Bedrock Reranker를 적용하고, 추가로 Bedrock Guardrails의 Contextual Grounding (컨텍스트 그라운딩) 체크를 결합하는 접근 방식이 유효합니다.
• API 호출 시 동시 호출 상한 오류 (ThrottlingException)가 빈번하게 발생하는 경우
  클라이언트 측에서 Jitter가 포함된 지수 백오프 (Exponential Backoff)를 구현하고, 추가로 API Gateway를 통한 스로틀링 (Throttling) 제한을 설정합니다.
• 추론 처리가 비정상적으로 길거나 페이로드 (Payload)가 너무 큰 경우
  SageMaker Asynchronous Inference (비동기 추론)를 사용하여, 요청이 없을 때는 0으로 스케일링하여 비용을 절감하는 구성이 최적해입니다.

이러한 "과제와 해결책의 세트"를 정리해 두는 것만으로도 시험 본문의 시나리오 문제를 상당히 수월하게 풀 수 있습니다. 본 기사의 테마를 참고하여 꼭 합격을 거머쥐시길 바랍니다!

Discussion