AWS Certified Generative AI Developer - Professional (AIP-C01)

청중 기반 임계값 튜닝과 내부 관리 API는 Bedrock Guardrails의 기능이 아닌 자체 발명입니다. 이를 구축하려면 맞춤 관리 레이어를 작성하고 유지해야 하므로 오케스트레이션 오버헤드가 줄어드는 게 아니라 늘어납니다.

API 호출에 지침을 주입하고, Step Functions로 응답을 검증하고, Comprehend로 후처리 필터링하는 것은 사업부별로 유지해야 하는 움직이는 부품들의 파이프라인(DynamoDB 규칙, Step Functions, Comprehend)을 만듭니다. 추론 호출의 Bedrock Guardrails는 이미 별도 오케스트레이션 없이 카테고리 필터링을 처리합니다.

DynamoDB에 사업부별 prompt를 두고 두 개의 Lambda(선택용·후처리용)를 두는 것은 정확히 문제가 피하려는 맞춤 오케스트레이션입니다. Comprehend는 범용 NLP이며, Guardrails가 기본 제공하는 유해 콘텐츠 카테고리에 특화되어 있지 않습니다.

pgvector를 적용한 Aurora PostgreSQL은 1,000만 임베딩 규모에서는 인스턴스 사이징·인덱스 튜닝·유지보수/패칭을 직접 해야 할 만큼 자체 관리 부담이 큽니다 — 서버리스보다 운영 오버헤드가 낮은 게 아니라 높습니다. 맞춤 SQL 유사도도 Bedrock Knowledge Base와의 자연스러운 통합을 놓칩니다.

S3 Vectors의 필터링이 안 되는 메타데이터 필드는 게시일, 규제 기관, 문서 유형으로 필터링해야 한다는 명시 요구를 충족할 수 없습니다. 필터링이 유스 케이스의 핵심이므로 필터링이 안 되는 저장소는 후보에서 제외됩니다.

Amazon Neptune Analytics는 그래프 데이터베이스입니다. 벡터 인덱싱을 지원하지만 운영 모델이 그래프 워크로드와 다중 hop 관계 분석에 맞춰져 있어, 독립 문서에 대한 단순 의미 유사도에는 과합니다 — LEAST 오버헤드 옵션이 아닙니다.

임베딩 차원을 384에서 1,536으로 늘리면 인덱스 저장소와 유사도 계산이 모두 비싸지면서, 정작 문제(정확한 용어 매칭 부재)에는 영향이 없습니다. 검색 후 Lambda 필터를 추가하는 것은 검색 자체를 고치지 않고 증상만 재정렬하는 볼트온 로직입니다.

OpenSearch를 Amazon Kendra로 교체하는 것은 검색 백엔드 전체 마이그레이션 — 최소 운영 오버헤드와는 거리가 멉니다. 쿼리 확장이 약어를 처리하긴 하지만, 팀이 이미 구축한 벡터 검색 자산을 잃습니다.

검색 후 재랭킹의 2단계 파이프라인은 운영해야 할 새 컴포넌트(SageMaker 엔드포인트와 그 주변 오케스트레이션) 둘을 추가하고 지연을 늘립니다. 더 강력하지만 LEAST 운영 오버헤드 옵션은 아닙니다.

Bedrock 트래픽을 NAT 게이트웨이로 라우팅하면 공용 인터넷을 거치게 되어 사설 전용 요구를 위반합니다. S3 ACL은 거친 입자 단위라 컬럼 수준 부여가 불가능하며, 주간 CloudTrail 검토는 강제 가능한 통제로는 빈도가 너무 낮습니다.

S3 게이트웨이 엔드포인트는 Bedrock에 대한 사설 연결을 제공하지 않습니다 — S3에만 적용됩니다. Bedrock을 공용 엔드포인트로 호출하는 것은 요구 위반이고, 데이터베이스 수준 부여로는 컬럼 수준 액세스를 강제할 수 없습니다.

두 서비스에 대한 VPC 엔드포인트는 사설 연결을 다루지만, IAM 경로 기반 정책은 세분화된 컬럼 수준 액세스를 제공할 수 없습니다 — 그것은 Lake Formation LF-tag가 필요합니다. 메트릭 필터나 알람 없이 CloudTrail을 CloudWatch Logs로만 보내는 것도 감사 태세를 약화시킵니다.

EventBridge로 트리거되는 Lambda 함수에서 후처리 분석으로 공정성 메트릭을 계산하는 것은 정확히 문제가 최소화하라고 한 맞춤 개발입니다. 네이티브 공정성 측정이 없어 팀이 메트릭 파이프라인을 직접 작성·유지해야 합니다.

Bedrock Guardrails 콘텐츠 필터는 유해 콘텐츠 카테고리(hate, insults 등)를 대상으로 합니다 — 인구통계 공정성을 측정하지 않습니다. InvocationsIntervened 메트릭은 가드레일 개입을 카운트하며 인구통계 그룹 간 공정성과는 무관합니다.

Bedrock 모델 평가 작업은 배치 평가이며 실시간으로 실행되지 않습니다. InvocationsIntervened는 다시 가드레일 메트릭이지 공정성 메트릭이 아닙니다 — 인구통계 차원으로 태그를 달아도 편향 측정을 만들어내지 않습니다.

Lambda 타임아웃을 늘리고 지수 백오프 재시도를 더하는 것은 증상을 다루는 것이지 원인이 아닙니다. 사용자는 여전히 복잡한 쿼리의 전체 처리 시간 동안 아무 출력도 보지 못하며, 동기 resolver에서의 재시도는 지연을 줄이는 게 아니라 더합니다.

비동기 처리를 위해 SQS 큐로 라우팅하면 채팅 스타일 어시스턴트에 기대되는 동기 클라이언트 UX가 깨집니다. 사용자는 더 이상 스트리밍 응답을 받지 못하고 결국 응답만 받게 되므로, 팀이 고치려는 경험에 더 나쁩니다.

AppSync에서 별도의 API Gateway WebSocket API로 마이그레이션하는 것은 기존 GraphQL 스택을 버리고 전송 계층 전체를 재구축하는 것이므로, 이미 가지고 있는 resolver에서 Amplify AI Kit 스트리밍을 활성화하는 것보다 훨씬 침습적입니다.

Lambda 환경 변수를 콘솔에서 업데이트하는 것 자체가 배포 이벤트(함수 구성 업데이트)이므로, 운영 등급 롤아웃에서는 'FM을 새 코드 배포 없이 전환'을 충족하지 못합니다. 네이티브 검증·롤백·단계적 배포도 없습니다.

stage 변수가 있는 API Gateway 요청 변환 템플릿은 API 요청 라우팅용으로 설계되었으며, 사용자 등급·거래 금액 같은 요청별 규칙을 평가하는 데는 적합하지 않습니다. stage 변수도 배포 단계 변경이지 실시간 구성이 아닙니다.

Lambda 권한 부여자는 통합 대상이 선택되기 전에 실행되므로 요청별 모델 라우팅 결정을 내리기에 올바른 위치가 아닙니다. 모델별 Lambda로 라우팅하면 아키텍처가 분기되고 단일 Lambda에서 라우팅을 다루는 것보다 FM 간 A/B 테스트도 어렵습니다.

평탄한 벡터 저장소 위에서 Lambda 함수 체이닝으로 다중 hop 관계를 다루는 것은 Graph RAG가 이미 제공하는 그래프 순회를 다시 만드는 것이며, 지연과 운영 표면(함수 코드, 에러 처리, 시퀀싱) 모두 배가됩니다.

OpenSearch Serverless k-NN은 벡터 유사도는 처리하지만 관계 모델링은 하지 않습니다. 관계 계층을 EC2 Auto Scaling에 두는 것은 Graph RAG가 네이티브로 처리할 애플리케이션 계층을 팀이 운영한다는 뜻입니다.

DynamoDB에는 네이티브 의미 검색이나 그래프 검색이 없습니다. DynamoDB 위 맞춤 인덱싱 시스템과 SageMaker 응답 생성을 결합하는 것은 Bedrock이 제공하는 관리형 그래프 RAG 기본 요소를 무시한 from-scratch 빌드입니다.

맞춤 Lambda + SQS 승인 워크플로는 정확히 .waitForTaskToken이 대체하기 위해 설계된 종류의 맞춤 오케스트레이션입니다: 팀이 Step Functions가 이미 제공하는 상태·재시도·타임아웃 처리를 다시 구현해야 합니다.

AWS Glue는 데이터 통합/ETL 서비스이지 사람 승인을 위한 워크플로 엔진이 아닙니다 — 기술자 검토를 게이트하기 위해 Glue 워크플로를 사용하는 것은 서비스 오용이고, 장기 실행 task-token 패턴이 빠져 있습니다.

EventBridge는 이벤트를 라우팅할 수 있지만 사람의 결정을 위해 일시 정지하는 네이티브 개념이 없으며, Glue 작업과 ElastiCache는 감사 결정을 저장하는 데 잘못된 도구(캐시는 본질적으로 휘발성)입니다.

트래픽이 애초에 프로비저닝된 용량에 도달하지 않는데 모델 단위를 더 늘려도 도움이 되지 않습니다. 프로비저닝 풀은 사용되지 않은 상태이지 부족한 상태가 아닙니다.

지수 백오프는 on-demand 경로의 throttling을 가리지만, 애플리케이션이 이미 비용을 지불한 프로비저닝된 처리량을 절대 사용하지 못하게 만듭니다. 또한 throttling 원인을 제거하는 게 아니라 지연을 더할 뿐입니다.

InvokeModelWithResponseStream으로 전환하는 것은 응답 형태(스트리밍 vs 단일)를 바꾸지만 여전히 같은 modelId에 대해 라우팅되므로, 프로비저닝된 용량은 그대로 손대지 않은 채입니다.

Bedrock Guardrails에는 토큰 쿼터 정책이 없습니다 — 그 관심사는 콘텐츠 모더레이션, denied topics, PII 처리입니다. 가드레일 메트릭 위에 토큰 알림을 구축하는 것은 서비스를 오용하는 것이며 선제적 알림 요구를 충족하지 못합니다.

SQS 데드 레터 큐는 사실 후 실패한 요청을 캡처합니다 — 반응적이며, 문제는 명시적으로 토큰 한도에 도달하기 전에 선제적 알림을 요구합니다. Logs Insights 기반 분석도 요청별 CloudWatch 메트릭보다 느립니다.

API Gateway 사용 계획은 토큰이 아니라 요청을 카운트합니다. 토큰 사용량은 콘텐츠 의존적이고 같은 사용 계획 내에서도 요청마다 다르므로, 요청 카운트 throttling으로는 토큰 수준 한도를 정확히 강제할 수 없습니다.

제품 카테고리별 모델 미세 조정은 무겁고 비싸며, 주문 관리 API 통합도 제공하지 않고, 매일 업데이트 요구와 충돌합니다(매번 미세 조정 후 카탈로그가 모델에서 어긋남).

Continued pre-training은 미세 조정보다 더 무겁고, 다시 API 도구 사용이나 매일 문서 변경에서의 유지보수성을 다루지 못합니다. 위에 얹는 맞춤 Lambda + REST API는 Bedrock 에이전트가 이미 제공하는 손수 만든 오케스트레이션입니다.

SageMaker AI 컨테이너, Kendra, Step Functions는 동작 가능하지만 맞춤 대안입니다 — 팀이 모델 컨테이너를 운영하고 Bedrock 에이전트가 기본 처리하는 오케스트레이션을 직접 엮어야 합니다.

맞춤 분석기를 사용하는 순수 키워드 검색으로는 '복잡한 자연어 쿼리'를 충족할 수 없습니다 — 의미 유사도가 중요한 영역인데 어휘 매칭은 부족합니다.

Aurora가 아닌 PostgresQL + pgvector는 수억 벡터 규모에서 인덱스 빌드 시간, 쿼리 지연, 운영 튜닝이 모두 부담이 되며, 항상 켜진 인스턴스 비용도 부담합니다.

Bedrock Knowledge Base와 맞춤 ingestion 파이프라인은 필요 이상으로 무겁습니다: KB는 ingestion·문서 수에 실용적 한계가 있어 2억+ 항목을 다루기 어색하며, Retrieve API는 맞춤 검색 튜닝을 위해 벡터 인덱스를 노출하지 않습니다.

Bedrock Guardrails는 임의의 '환각 패턴'을 매칭할 수 없습니다 — 가드레일은 유해 카테고리, denied topics, PII, 그라운딩 점수에서 동작합니다. 환각 콘텐츠를 필터로 패턴 매칭하는 것은 지원되는 기능이 아닙니다.

temperature 매개변수를 늘리면 모델이 더 다양한(덜 결정적인) 출력을 만드는데, 이는 환각을 줄이는 게 아니라 경험적으로 늘립니다. 방향이 반대입니다.

긴 기술 문서에서 이미 실패하고 있는 단일 패스 전체 문서 요약을 계속하는 것은 실패 모드를 그대로 반복하는 것입니다 — 아무것도 바뀌지 않습니다.

Lake Formation은 Catalog 테이블 위에서 권한을 중앙화하지만, 문제가 기술하는 방식의 소스 수준에서 이종 데이터 소스를 등록하거나 메타데이터를 적용하지 않습니다. S3에 직접 객체를 태깅하는 것도 S3에만 한정되며 다른 소스로 확장되지 않습니다.

CloudWatch Logs는 애플리케이션·운영 로깅용이지 감사용이 아닙니다. Glue Catalog와 짝지어도 CloudWatch의 보존, 변경 불가능성, API별 세분화가 CloudTrail보다 약하기 때문에 감사 추적 요구가 충족되지 않습니다.

S3 객체 태깅은 S3 객체에 한정된 귀속만 다루며, Glue Data Catalog가 스키마를 관리하고 CloudTrail이 S3 액세스만 처리하는 구조는 cross-service 감사(Bedrock, Lambda, Glue 등)를 범위 밖에 둡니다. 감사 그림이 불완전합니다.