AIP-C01 — 생성형 AI 시스템 설계와 운영

• 대상 시험: AWS Certified 생성형 AI(generative AI, GenAI) Developer - Professional, AIP-C01.
• 확인일: 2026-09-20, Asia/Seoul.
• 기준: 공식 한국어 가이드. 확인 본문에 별도 버전·개정일 미표시. AIF의 버전 1.1을 AIP 버전으로 옮기지 않는다.
• 공식 작업·기술 번호는 시험 가이드의 범위를 찾아보기 위한 표기다. 서비스별 조건은 연결된 공식 문서를, 적용 판단은 이 교재의 독립 해설을 참고한다.

먼저 구분할 두 가지 운영 상태

• 대화 보존 기한과 실제 삭제: DynamoDB TTL은 만료 시각이 지난 항목을 나중에 삭제한다. 앱은 삭제를 기다리는 동안에도 만료 이력을 사용하지 않아야 한다. 강좌 관련 항목의 90일 보존은 사례 정책이지 제품의 기본값이나 정확한 삭제 보장이 아니다. 정확한 삭제 기한과 준수 요건은 별도 설계·검증 대상이다.
• 프롬프트 버전과 승인: 프롬프트 버전 관리는 특정 구성을 고정하는 기능이다. 품질 평가, 조직 승인, 프로덕션 참조 변경은 각각 다른 상태이며 승인 시스템별 구현을 확인해야 한다.

기술별 심화 본문

기술별 설계 판단은 공식 기술 98개를 개별 행으로 정리하고 해당 해설과 연결한다. 먼저 이 개요에서 전체 흐름을 읽은 뒤, 특정 기술의 선택 조건·예외·제품별 확인 항목을 찾아볼 때 사용한다.

대상 역할과 선수 지식

공식 인증 페이지에서 180분·75 문항·300 USD·한국어 제공을 확인했다. 가이드에는 채점 65 문항·비채점 10 문항, 변환 점수 750점이 명시되어 있다. 750점을 정답률 75%로 해석하지 않는다. 대상 경험 설명은 프로덕션급 애플리케이션 2년 이상과 GenAI 구현 1년 이상의 실무 경험을 포함한다. 이는 가이드의 대상 응시자 설명이며 이 노트가 경험을 대체하거나 합격을 보장하지 않는다.

AIF가 서비스와 기법을 선택하는 이유를 이해하는 단계라면, AIP는 데이터가 어디로 이동하고 누가 어떤 작업을 실행하는지 정한 뒤, 권한·오류 처리·배포 검증·비용·지연을 함께 설계하는 단계다. 자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM), 컴퓨팅·스토리지·네트워크, 코드형 인프라(infrastructure as code, IaC)/지속적 통합·전달(continuous integration /continuous delivery, CI/CD), 관찰성(observability)과 비용 관리 원칙도 선수 지식이다. 가이드가 모델 개발·훈련 및 고급 기계 학습(machine learning, ML)을 범위 밖으로 설명한다고 해서 데이터 검증·검색용 임베딩(embedding)·튜닝된 모델 배포까지 제외되는 것은 아니다. ‘파운데이션 모델(foundation model, FM)을 개발하는 일’과 ‘모델을 통합하고 운영하는 일’을 구분한다.

영역 1 — 파운데이션 모델 통합, 데이터 관리 및 규정 준수

근거: 공식 출처 안내 작업 1.1~1.6. 보충 Bedrock 역할과 최신 기능 경계 ·Knowledge Bases 선택 ·RAG 내부 흐름 ·프롬프트 관리.

1.1 요구 사항을 측정 가능한 제약으로 바꾸기

관련 해설: 공식 출처 AIP D1 → AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계. 구체 구현과 실행 검증은 별도로 확인한다.

시작은 모델 이름이 아니라 업무 성공 조건이다. 답변 품질, 첫 응답 지연, 전체 완료 시간, 사용자·테넌트별 데이터 권한, 보존 기간, 허용 리전, 예상 호출량, 장애 시 허용 기능을 정한다. 개념 증명(proof of concept, PoC)는 작은 입력에 멋진 답변이 나오는지보다 제약을 실제로 충족할 수 있는지 검증한다. 재사용할 표준 구성 요소를 만들어 배포마다 인증·로깅·오류 처리 방식이 제각각이 되지 않도록 한다.

자체 예시: 계약서 QA의 성공은 ‘답이 생성됨’이 아니라 ‘권한 있는 최신 계약 조항으로 답하고, 근거가 없으면 모름을 알리며, 지연과 비용 예산을 충족함’으로 정의한다. 계약 변경 실행은 조회와 분리한다. Well-Architected/Generative AI Lens는 가이드에서 명시하지만 해당 공식 한국어 본문 심층 읽기는 남아 있다.

1.2 모델 선택·라우팅·복원력·수명 주기

관련 해설: 공식 출처 AIP D1 → AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계. 구체 구현과 실행 검증은 별도로 확인한다.

모달리티, 언어, 문맥 길이, 구조화 출력, 도구 연계, 요구 품질, 지연과 비용을 실제 평가 세트로 비교한다. Amazon Bedrock의 관리형 FM 활용과 Amazon SageMaker AI의 모델 배포 제어는 운영 책임의 차이로 비교한다. 모델 인터페이스를 추상화하고 설정·라우팅 계층을 분리하면 모델을 바꿀 때 모든 업무 코드를 수정하는 부담이 줄어든다.

가이드는 저순위 적응(low-rank adaptation, LoRA)/어댑터, Model Registry, 배포 파이프라인과 롤백을 명시한다. 하지만 이 예비판에서는 해당 도구별 구현·호환성의 공식 한국어 문서를 아직 읽지 않았다. ‘범위에 있다’와 ‘구현 숙련 완료’를 분리한다.

1.3 데이터 검증과 입력 계약

관련 해설: 공식 출처 AIP D1 → AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계. 구체 구현과 실행 검증은 별도로 확인한다.

원천 데이터 → 검증 → 형식·품질 처리 → 모델 입력의 각 단계에서 무엇이 유효한지 정의한다. 텍스트·이미지·오디오·표 데이터는 준비 과정이 다르며 오디오의 전사 오류가 이후 요약 오류로 전파될 수 있다. 모델이 지원하는 JSON/대화·멀티모달 형식을 정확하게 맞추고 길이·필수 필드·인코딩·누락값을 점검한다.

가이드는 Glue Data Quality, Data Wrangler, Processing, Amazon Transcribe, Amazon Comprehend, Lambda를 예시로 든다. 이름만으로 모든 입력 문제가 자동 해결된다고 보지 않는다. 데이터 품질 지표와 모델 응답 지표를 연결해야 ‘답이 나쁘다’는 현상을 어디에서 고칠지 결정할 수 있다. 각 제품의 지원 형식·한도·한국어 정확도 상세는 추가 조사 대상이다.

1.4 벡터 저장소·메타데이터·동기화

관련 해설: 공식 출처 AIP D1 → AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계. 구체 구현과 실행 검증은 별도로 확인한다.

RAG 내부 흐름에서는 문서를 청킹(chunking)으로 나누고 임베딩(embedding)을 만든 뒤 원문과 연결된 색인(index)에 저장한다. 벡터(vector)뿐 아니라 문서 ID·버전·출처·소유권·시각·도메인 같은 메타데이터(metadata)도 저장한다. 이 정보가 있어야 검색 결과를 권한·최신성·업무 범위에 맞게 해석하고 감사할 수 있다.

데이터 갱신은 신규 문서 추가만의 문제가 아니다. 수정·삭제·권한 변경을 색인에도 반영해야 오래된 내용이나 접근 불가 문서가 계속 검색되는 일을 줄일 수 있다. 증분 갱신·변경 감지·주기 동기화는 가이드에 명시된 접근이다. 실제 동기화 스케줄을 생성한 것은 아니다.

Knowledge Bases 선택의 현재 제품 문서는 관리형과 고객 관리형 지식 기반을 구분한다. 운영 부담 감소와 세부 제어 사이에서 선택한다. 커넥터별 문서 접근 제어 목록(access control list, ACL) 제공 범위에는 예외가 있어 모든 검색이 자동으로 권한 안전하다고 가정하지 않는다. 사용자 지정 벡터(vector) 스토어의 샤딩·다중 인덱스·계층 구조는 검색 규모와 운영 복잡도를 함께 고려해야 한다.

1.5 검색 품질은 청크부터 최종 문맥까지 결정된다

관련 해설: 공식 출처 AIP D1 → AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계. 구체 구현과 실행 검증은 별도로 확인한다.

청크가 너무 작으면 맥락이 끊기고 너무 크면 불필요한 내용과 토큰 비용이 늘 수 있다. 문서 구조에 맞는 분할, 겹침, 제목·절 정보, 원문 대응을 평가한다. 임베딩은 언어·도메인·벡터 차원·형식·저장소 호환성을 고려한다. float32 와 binary는 저장 효율·표현 품질의 절충이며 양쪽 지원이 필요하다(RAG 내부 흐름).

이 표는 가이드의 검색 기법을 연결한 설계 해설이다. 해당 제품의 실제 매개변수 실습은 수행하지 않았다. OpenSearch/Aurora pgvector의 세부 인덱스 선택·성능 수치, 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 검색 인터페이스 구현은 공식 한국어 심화 공백으로 남는다.

1.6 프롬프트를 코드처럼 통제하기

프롬프트 관리의 설계 조건은 대화·버전·승인 해설에서 이어진다. 모델·API별 지원과 구현 숙련은 개념 이해와 별도로 검증해야 한다.

프롬프트 관리에 근거해 템플릿·변수·모델·추론(inference) 설정·변형·버전을 함께 관리한다. 대화 기록은 무한히 추가하는 대신 필요한 문맥과 개인정보를 고려한다. 템플릿에 데이터를 삽입할 때 신뢰된 지시와 외부 자료의 경계를 유지한다.

품질 관리는 정상 입력뿐 아니라 정보 부족, 형식 오류, 악의적 입력, 긴 문서, 언어 혼합을 포함한다. 후보 버전을 고정된 테스트 입력으로 비교하고 채택·롤백 기준을 둔다. 프롬프트 체인(prompt chain)은 복잡한 작업을 여러 단계로 나눈다. 앞 단계의 오류가 다음 단계로 전파될 수 있으므로 단계마다 출력 스키마(output schema)와 필수 내용을 검사해야 한다.

영역 복습: 요구사항 → 모델 → 문서 권한·색인 → 검색 → 프롬프트 버전까지 하나의 요청을 추적할 수 있는가? 모든 세부 구현 완료 판정은 보류다.

영역 2 — 구현 및 통합

영역별 해설: 공식 출처 AIP D2과 AIP-C01 영역 2 — 에이전트·배포·기업 시스템 통합을 연결했다.

근거: 공식 출처 안내 작업 2.1~2.5. 보충 에이전트와 도구 ·관찰성 — 지표·감사·호출 로그의 차이. 영역별 해설에서 구체 선택 조건을 확인할 수 있다.

2.1 에이전트가 행동할 때의 안전 경계

Bedrock Agents는 FM·지식 기반·작업 그룹·대화를 조정한다. 사용자 요청을 작은 단계로 나누고 필요한 정보를 추가 질문하거나 도구로 실행한다(에이전트와 도구). 작업을 수행하는 시스템은 좋은 답변뿐 아니라 올바른 대상에게 허용된 행동만 하는지 검증해야 한다.

안전한 도구 호출의 자체 설계 순서: 요청 의도 확인 → 허용 도구 선택 → 인자·사용자 권한 검증 → 필요 시 인간 승인 → 호출 → 결과 검증 → 상태 기록 → 종료 조건 확인. 가이드는 중지 조건·타임아웃·서킷 브레이커·IAM 경계·사람 검토를 명시한다. 모델이 반복해서 같은 실패 도구를 호출하도록 무한 루프를 두지 않는다.

메모리(memory)를 설계할 때는 대화 내용과 실행 상태(execution state)를 구별한다. ‘승인을 요청함’과 ‘승인됨’, ‘호출함’과 ‘성공 확정’은 서로 다른 상태다. 재시도로 결제나 변경이 중복되지 않도록 업무 API의 멱등성·상태 확인이 필요하다(설계 해설; 세부 SDK 근거 대조는 남음).

Strands/Agent Squad/MCP는 공식 가이드에 명시되어 있다. MCP는 도구 연결을 표준화하는 관점으로 이해하되, 사용한다는 사실만으로 인증·인가(authorization)·데이터 보호가 자동 해결되지는 않는다. Lambda의 경량·스테이트리스 도구 서버와 ECS의 복잡한 도구 서버는 가이드 예시이며 구체 구현 문서는 추가 확인이 필요하다.

2.2 배포 전략과 모델 자원

관리형 API 호출과 자체·특화 엔드포인트 배포는 자원 관리 책임이 다르다. 자체 대규모 언어 모델(large language model, LLM) 배포에서는 모델 로딩·메모리·GPU·토큰 처리량(throughput)이 운영 제약이 된다. 온디맨드와 프로비저닝된 처리량(Provisioned Throughput)은 수요 패턴·가용성·사용률·비용을 함께 비교한다. 작은 모델에 일상 요청을 맡기고 어려운 요청을 상위 모델로 보내는 방식도 전체 호출 수와 실패 비용까지 평가해야 한다.

모델 버전과 배포 구성을 보존하고 이전 버전으로 돌아갈 기준을 둔다. Bedrock Agents의 버전·별칭 구조는 배포된 구성을 안정적으로 참조하는 개념을 보여준다(에이전트와 도구). 이는 SageMaker의 모든 배포 세부 기능을 확인했다는 뜻은 아니다.

2.3 기업 통합은 데이터와 권한의 연결이다

동기 API(synchronous API)는 호출자가 결과를 기다리는 방식이다. 이벤트(event)·큐(queue) 기반 통합은 호출자가 접수 후 기다리지 않아도 처리와 결과 전달을 이어갈 수 있도록 구성한다. 즉시 답변이 필요한 화면과 긴 문서 분석은 요구가 다르다. EventBridge/SQS/Step Functions/API Gateway/Lambda는 가이드가 제시한 통합 구성 요소다.

역할 기반 접근, 페더레이션, 최소 권한 API 접근을 모델·데이터·기존 시스템 전반에 적용한다. 하이브리드 환경에서는 온프레미스 자료 이동, 레지던시, 라우팅과 정책을 함께 판단한다. AWS Outposts/Wavelength가 가이드에 등장하지만 이 자료에서는 상세 배포 설계까지 완료하지 않았다.

CI/CD에서는 프롬프트와 모델 구성도 변경 대상에 넣고 테스트·보안 검사·롤백을 결합한다. 중앙 GenAI 게이트웨이는 인터페이스와 통제를 모으는 수단이지 무제한 권한의 공유 계정을 만드는 이유가 아니다(설계 해설).

2.4 API 계약·스트리밍·재시도

가이드는 지수 백오프·속도 제한·폴백·X-Ray 관찰성을 명시한다. 구체 재시도 횟수·시간을 임의의 공식 기본값으로 만들지 않는다. 스트리밍은 사용자가 빨리 내용을 받게 하지만 전체 처리 비용·시간이 반드시 줄어드는 것은 아니다.

2.5 개발 도구와 통합 패턴

선언형 UI/OpenAPI/Flows는 통합 인터페이스를 정리하는 도구 관점, CodePipeline/CodeBuild는 변경을 검증해 전달하는 관점, Q Developer는 개발 보조 관점으로 구분한다. 도구의 이름을 나열하는 대신 요구되는 계약·테스트·관찰성을 설명할 수 있어야 한다.

자체 예시: 고객 관계 관리(customer relationship management, CRM) 상담 보조에서는 고객 자료 조회, 요약, 사람이 승인한 수정 저장을 분리한다. 문서 처리 자동화에서는 실패 문서 격리와 재처리 기준을 둔다. 실제 기업 시스템 연결·배포는 수행하지 않았다.

영역 복습: 도구 실패·타임아웃·사람 승인·부분 완료·재시도 중복을 어떻게 구분할 것인가? 공식 한국어 구현 문서 보충이 많이 남은 영역이다.

2.5 독립 상세노트로 이어지는 여섯 질문

예제 구현의 구현 검토: Claude에 대한 cl100k_base 계수 보장 없음·출력예산 포함, CRM 로그는 모의 성공, invoke_agent는 Strands SDK 검증 아님, 상태 머신·SNS 계약·쿼리·대기 처리·불완전 X-Ray 코드 검증 잔여. 강좌 관련 항목의 월 5 만건·20분 연결·8,000 토큰·4 실패 차단은 가상 사례이지 현행 상한이 아니다.

기업 통합에서 특히 주의할 네 가지 조건

• API 키·사용량 계획은 인증·인가와 엄격한 비용 상한이 아니다: API 키는 인증·인가를 대신하지 않으며 best-effort quota는 엄격한 비용 차단이 아니다(2.3/2.4).
• Verified Permissions의 정책 평가와 애플리케이션의 집행 책임: 인증된 주체의 정책판정과 앱 집행/IAM 실행권한을 분리한다(2.3). 개요 일부·토큰·API·감사 세부는 잔여다.
• Bedrock 프로비저닝된 처리량과 용량 변경 조건: MU와 토큰 방식, 약정·수정 조건을 구별한다(2.2). 교육의 10 → 25 자동확장 예시를 현재 내장 기능으로 확정하지 않는다.
• Outposts 로컬 실행과 리전 서비스 연결을 구분하기: 로컬 서비스 일부와 리전 연결, 로컬 앱과 모델 연산 위치를 구별한다(2.3). 주개요 설명확인·부자료 부분이며 RDS 상충·특정 FM/GPU/단절운영 잔여다.

모두 제품 조건의 이해 보충이고 정확 SDK·지원표는 선택 심화로 남긴다.

영역 3 — AI 안전, 보안 및 거버넌스

영역별 해설: 공식 출처 AIP D3 → AIP-C01 영역 3 — 안전·프라이버시·거버넌스.

근거: 공식 출처 안내 작업 3.1~3.4. 보충 Guardrails의 역할과 경계 ·Bedrock 데이터 보호 ·모델 카드와 설명 가능성 ·모델 평가와 RAG 평가 ·모델 호출 로깅.

3.1 입력·출력·도구 단계별 방어

입력에서 위험한 지시·민감 정보를 탐지하고, 검색 자료를 신뢰된 시스템 지시로 승격하지 않으며, 출력은 형식·내용·근거를 확인하고, 실제 실행은 권한·정책으로 제어한다. 이는 한 개의 금칙어 필터만 적용하는 것과 다르다.

Guardrails는 콘텐츠 필터(content filters), 거부된 주제(denied topics), 단어 필터(word filters), 민감 정보 필터(sensitive information filters), 컨텍스트 근거 검사(contextual grounding checks), 자동 추론 검사(Automated Reasoning checks)를 제공한다. 근거 검사는 응답의 소스 부합성과 질문 관련성(Relevance)을 살피고, 자동 추론 검사는 정의한 논리 규칙과의 일치를 살핀다. IAM은 작업 권한을 통제한다. JSON Schema는 구조를 검증한다. 구조가 맞는 JSON이나 SQL이라고 사실적 정확성(factual accuracy)과 실행 안전까지 보증되지는 않는다.

가이드의 텍스트-SQL 관련 예시를 ‘생성 SQL은 항상 결정적으로 올바르다’로 읽지 않는다. 모델이 만든 쿼리를 실행할 때는 읽기·쓰기 권한·허용 테이블·실행 비용·업무 승인 같은 독립 통제가 필요하다(설계 해설). Guardrails의 SDK/콘솔·모델·언어·블록별 지원 차이는 전용 문서 검증이 남았다.

3.2 데이터 흐름 전체의 프라이버시

자료 원본·청크·임베딩·검색 메타데이터·프롬프트·응답·로그·캐시를 각각 보호 대상으로 본다. 가상 프라이빗 클라우드(Amazon Virtual Private Cloud, VPC) 경로, IAM, 암호화, 데이터 마스킹, 보존 기간은 다른 통제다. 개인 식별 정보(personally identifiable information, PII)를 가리는 처리와 재식별 위험이 없는 익명화도 동의어로 취급하지 않는다.

Bedrock 데이터 보호는 고객 설정 책임, 태그·이름의 민감정보 위험, URL 인증정보 금지 등을 설명한다. 모델 호출 로깅는 모델 호출 로깅이 기본 비활성이고 입력·출력을 포함할 수 있음을 보여준다. 로그를 활성화하면 분석 자료는 좋아지지만 새로운 민감정보 저장소가 생기므로 접근·보존·삭제 정책이 필요하다.

Bedrock 공급자 접근 경계에 대한 설명을 무보존 보장으로 확대하지 않는다. 고객 로그와 데이터 보존·침해 탐지 조건은 별도다. 보존조건과 PII/PHI언어를 추가 통합했다. 모델별 침해 탐지·법률·전체 API는 잔여다.

3.3 계보·감사·변경 통제

문서 ID/버전·출처·변환 과정·모델·프롬프트 버전·평가 결과·배포 승인·운영 사건을 연결하면 응답이 어떤 근거와 구성에서 나왔는지 조사할 수 있다. Model Cards는 용도·제한·위험·평가를 문서화하는 역할이다(모델 카드와 설명 가능성). CloudTrail 활동 감사와 프롬프트·응답 로깅은 다른 축이다.

가이드는 Glue 계보/Data Catalog, 메타데이터, 정책 프레임워크, 드리프트·오용·편향 모니터링을 명시한다. 실제 구현은 어떤 증거를 누가 얼마나 보관하고 어떤 기준으로 수정할지까지 정해야 한다. 도구를 도입했다는 사실만으로 규정 준수가 자동 완료되지는 않는다.

3.4 책임 있는 AI를 운영 기준으로 바꾸기

사용자에게 근거·한계·불확실성을 설명하고, 하위집단·업무유형별 공정성 지표를 평가한다. LLM 평가자(LLM-as-a-judge)와 사람 검토를 조합하되 심사 기준 자체도 검증한다. 정책 위반·위험한 출력·오용에 대응하는 검토·중지 절차를 정한다.

자체 예시: 보험 상담 모델은 평균 만족도가 높아도 특정 고객군에 불리한 안내를 반복할 수 있다. 평균 점수와 하위집단 오류율을 나눠 보고, 사용 제한과 인간 이관 조건을 모델 카드(model card)·정책에 함께 반영한다. 내부 비밀이나 원시 추론을 모두 공개하는 것이 투명성의 필수 조건은 아니다.

영역 복습: 필터·스키마·근거·인가·암호화·감사 각각의 실패를 독립적으로 시험할 수 있는가?

영역 4 — 운영 효율성 및 최적화

영역별 해설: 공식 출처 AIP D4 → AIP-C01 영역 4 — 비용·성능·관찰성 최적화.

근거: 공식 출처 안내 작업 4.1~4.3. 보충 관찰성 — 지표·감사·호출 로그의 차이 ·프롬프트 캐싱의 조건 ·모델 호출 로깅. 현재 제품의 세부 조건은 연결된 공식 문서에서 확인한다.

4.1 토큰·모델·캐시·용량의 비용

호출당 비용만이 아니라 성공한 업무당 비용을 본다. 입력·출력 길이, 검색·리랭킹, 도구·재시도, 평가, 로깅, 캐시 쓰기까지 포함하면 작은 모델을 여러 번 호출하는 방식이 단일 호출보다 비싸질 수 있다. 문맥 압축(context compression)과 불필요한 부분을 덜어내는 프루닝(pruning)은 비용을 줄일 수 있지만, 필수 근거까지 제거하지 않는지 검사한다.

프롬프트 캐싱의 조건에서 확인한 프롬프트 캐싱은 암시적·명시적 방식이 있고, 지원된다는 사실만으로 적중을 보장하지 않는다. 접두사를 안정적으로 두고 가변 입력을 뒤로 배치한다. 캐시 쓰기 요금이 더 높을 수 있으므로 실제 읽기·쓰기 사용량을 측정해야 한다. 온디맨드 엔드포인트 지원과 배치 API 비지원 조건을 구별한다. 모델별 TTL/가격 수치는 가변이며 이 노트는 일부 구간만 확인했다.

자체 예시: 거의 재사용하지 않는 긴 문서를 매번 캐시에 쓰면 기대한 절감이 나오지 않을 수 있다. 반복 패턴을 측정한 뒤 도입 여부를 결정한다. 이 예시는 실측 결과가 아니다.

4.2 지연 시간과 처리량은 다른 지표

첫 토큰까지 걸린 시간(time to first token, TTFT), 전체 완료 시간, 검색·도구 실행 시간, 큐 대기 시간(queueing time), 초당·분당 처리량(throughput)을 따로 측정한다. 스트리밍은 첫 피드백을 빠르게 할 수 있으나 전체 생성시간을 반드시 줄이지는 않는다. 병렬 호출은 지연을 줄일 수 있어도 비용·동시성 한도를 늘린다. 사전 계산은 예측 가능한 요청에 유리하지만 결과 최신성과 낭비 비용이 있다.

검색 최적화에서는 인덱스·쿼리·리랭킹·청크 구성을 함께 본다. 모델 파라미터를 바꿀 때는 출력 다양성뿐 아니라 품질·일관성·비용을 A/B 평가한다. 온도/top-k/top-p의 유효 범위는 모델별 문서가 필요하며 하나의 공통값을 정답처럼 외우지 않는다.

용량은 요청 수뿐 아니라 입력·출력 토큰 분포와 버스트를 고려한다. 프로비저닝된 처리량을 늘리는 선택은 실제 사용률과 업무 피크를 확인한 뒤 평가한다. 본 노트에서는 유료 성능 실험이나 리소스 변경을 하지 않았다.

4.3 관찰성: 운영·품질·비즈니스 연결

관찰성 — 지표·감사·호출 로그의 차이은 CloudWatch 지표, CloudTrail, 호출 로깅을 구분한다. 모델 호출 로깅는 동일 계정·리전 대상, 기본 비활성화, 입출력·메타데이터 저장, 대용량 S3 분리 조건을 설명한다. 응답이 없다는 신고를 조사할 때 requestId·modelId·작업·호출 주체·시각·토큰 수와 애플리케이션 상태를 연결한다.

100KB 초과 JSON/바이너리의 S3 별도 저장은 확인일 기준 문서 조건이다. CloudWatch 한 이벤트만 확인해서 전체 입력이 없다고 결론내리지 않는다. 서비스 주체·SourceAccount/SourceArn·지정 경로·역할 신뢰·권한의 구분을 심화 본문에 반영했다. 실제 계정에 정책을 적용하거나 시험하지는 않았다.

영역 복습: 빠른 답변·많은 처리·낮은 토큰 비용·높은 업무 성공이 언제 충돌하는지 설명할 수 있는가?

영역 5 — 테스트, 검증 및 문제 해결

영역별 해설: 공식 출처 AIP D5 → AIP-C01 영역 5 — 평가·검증·문제 해결.

근거: 공식 출처 안내 작업 5.1~5.2. 보충 RAG 내부 흐름 ·모델 평가와 RAG 평가 ·프롬프트 관리 ·모델 호출 로깅.

5.1 평가 세트와 품질 게이트

평가 기준에는 관련성(relevance), 사실적 정확성(factual accuracy), 일관성(consistency), 유창성(fluency)이 포함된다. 검색 품질, 에이전트의 작업 완료(task completion)와 도구 사용 효율, 비용과 지연 시간(latency)도 함께 평가한다. 제품 문서의 평가 방식은 프로그램 평가·사람 평가·다른 LLM 판단·검색 증강 생성(Retrieval Augmented Generation, RAG) 평가로 나뉜다(모델 평가와 RAG 평가). 질문만 모으지 말고 필요한 근거·기대 답변·채점 기준을 함께 준비한다.

RAG는 검색-only 평가와 검색+생성 평가를 분리해야 한다. 정답 근거가 검색 결과에 없으면 생성 모델이 사실을 맞히기를 기대하기보다 수집·청킹·임베딩·검색을 고친다. 정답 근거는 있는데 틀리면 프롬프트·문맥 배치·생성·검증을 조사한다.

이 표는 가이드 명시 방식의 해설이다. 서비스별 평가 설정 문서·실습은 미완료다. 품질 게이트는 배포 전 통과 기준이며, 운영 모니터링은 배포 후 변화 탐지다. 에이전트는 최종 답변이 아니라 실제 도구 작업 결과와 중지·승인 준수까지 평가한다.

5.2 증상에서 원인을 추측하지 않고 증거로 좁히기

자체 사례: 문서의 반품 기한이 바뀌었는데 옛 기한을 답한다. 먼저 색인에 새 버전이 있는지, 질문이 새 문서를 검색했는지, 최종 프롬프트에 어떤 청크가 포함됐는지 순서대로 확인한다. 새로운 문서가 미수집이면 재수집·동기화 문제다. 검색했는데 프롬프트에서 잘렸다면 문맥 구성 문제다. 근거를 전달했는데 틀렸다면 생성·지시·검증을 비교한다. 실패 원인을 무조건 ‘모델이 나쁘다’고 단정하지 않는다.

프롬프트 관리(프롬프트 관리)는 버전 비교, 호출 로깅(모델 호출 로깅)은 실제 요청·응답 증거에 도움을 준다. 다만 민감한 입력을 무제한 저장하는 것이 해결책은 아니다. 관찰성과 프라이버시를 함께 설계한다.

영역 복습: 검색과 생성 실패를 구분할 수 있는 평가 데이터를 만들고, 품질 게이트와 롤백 기준을 설명할 수 있는가?

시험 전 핵심 비교와 범위 주의

• 가이드 범위 밖 모델 개발·훈련 vs 범위 안 모델 통합·배포를 구별한다.
• 동기·비동기·스트리밍은 기다리는 방식과 응답 전달 방식의 차이다.
• RAG 검색 품질 vs 생성 품질 vs 업무 완료는 다른 성공 축이다.
• 프롬프트 캐시 vs 결과·시맨틱 캐시는 재사용 대상이 다르다.
• 안전 필터 vs IAM vs 스키마 검증 vs 암호화는 서로 대체하지 않는다.
• 버전·별칭·롤백·평가 세트는 변경을 추적하고 안전하게 되돌리기 위한 연결이다.
• AIF 범위 외 목록의 AWS AppConfig/X-Ray는 AIP 범위 내에 보인다. 반대로 AIF에서 다루는 Budgets/Trusted Advisor는 AIP 범위 외 목록에 보인다. 시험별 범위를 섞지 않는다. 범위 내·외 목록은 완전 목록이 아니며 변할 수 있다.

추가 확인이 필요한 구현 주제

Strands/Agent Squad 별 구현, LoRA 호스팅, 엔진별 인덱스 튜닝, 서비스별 CI/CD·IaC·하이브리드 구성, 보존·침해 탐지, 평가 지표 세부 변형은 추가 검증이 필요합니다. 정확한 SDK 설정과 한도를 일반 개념만으로 추정하지 않습니다.