영역 1 — 모델·데이터·검색·프롬프트
요구사항에서 모델·배포·평가를 함께 결정
요구사항은 ‘좋은 답변’보다 구체적이어야 한다. 입력의 언어·모달리티, 출력 형식, 민감도, 응답 지연, 초당 요청과 토큰(token), 가용성, 데이터 처리 위치, 허용 오류, 사람 승인 여부를 먼저 정한다. 그다음 후보 모델·검색·도구·배포 방식을 선택한다. 서로 다른 모델을 비교할 때 동일한 대표 데이터와 동일한 품질 기준을 쓰고 비용은 토큰뿐 아니라 검색·도구·운영·검토까지 포함한다. 개념 증명(proof of concept, PoC)는 쉬운 질문의 데모가 아니라 경계·실패 사례와 예상 부하에서 요구를 충족하는지 확인하는 실험 설계다. 공식 출처 안내, 모델 평가와 RAG 평가/교차 리전 추론/Converse 요청과 스트림/평가자 지표의 의미
자체 사례: 한국어 계약 검토 앱은 ‘핵심 조항 추출 정확성, 원문 근거, 민감 문서 처리 위치, 시간 제한’을 동시에 만족해야 한다. 추출 정확도가 높은 모델이라도 승인되지 않은 지역으로 문서를 보내야 한다면 후보에서 제외한다. 공통 호출 어댑터는 입력·출력 계약을 통일하지만 모델의 모든 필드·도구 지원을 동일하게 만들지는 못한다. 정규화된 API와 모델별 기능 검증을 함께 둔다.
모델 교체·복원력·버전 수명 주기
라우팅은 허용 후보 중 비용·품질에 맞는 모델을 고르는 것이고, 폴백은 장애나 제약 때문에 다른 처리 경로로 전환하는 것이다. 규제상 금지된 모델·리전을 장애 시에만 허용해서는 안 된다. Amazon Bedrock CRIS는 추론(inference) 프로파일의 대상 지역 안에서 라우팅하며 지리적 프로파일과 글로벌 프로파일의 처리 위치가 다르다. 일반 앱 라우터와 Bedrock Intelligent Prompt Routing은 별개다. 후자는 같은 패밀리의 지원 모델·영어 최적화·앱별 성능 데이터 적응 불가 등 현재 조건을 가진다. 교차 리전 추론/지능형 모델 라우팅
사용자 지정 모델은 학습 데이터·코드·파운데이션 모델(foundation model, FM)·어댑터·전처리·평가를 버전으로 연결한다. Model Registry는 모델 그룹·버전·지표·승인 상태를 추적한다. 등록·승인·배포·운영 검증은 별도 상태다. 롤백은 이전 모델 이름 하나만 되돌리는 것이 아니라 호환되는 프롬프트·어댑터·입력 형식까지 복구하는 설계다. 저순위 적응(low-rank adaptation, LoRA)는 모든 파라미터를 갱신하는 대신 저순위 적응 파라미터로 학습 비용을 줄이는 개념이며, 이번 자료에서는 모델별 LoRA 호스팅 세부를 검증하지 않았다. 모델 사용자 지정/Model Registry, 공식 출처 안내
입력 데이터 계약과 품질 검사
원문 수집 → 형식 검증 → 정규화·중복 제거 → 민감정보 처리 → 변환 → 모델 입력이라는 경로를 명확히 한다. 문서 ID·버전·소유권·언어·수집 시각을 유지해야 오류를 원문으로 추적할 수 있다. Glue Data Quality는 DQDL 규칙으로 품질을 검사하며 카탈로그 검사와 추출·변환·적재(extract, transform, load, ETL) 중 검사에는 기능 차이가 있다. 규칙 통과율은 모든 사실의 참 여부가 아니라 정의한 규칙의 통과 비율이다. 이미지·오디오에 텍스트 전용 규칙을 그대로 쓰지 않는다. Glue Data Quality, Amazon Transcribe 입력·출력과 운영 방식 ·Amazon Comprehend 분석과 사용자 지정
자체 예시: 계약 문서의 금액이 광학 문자 인식(optical character recognition, OCR) 과정에서 누락되면 대규모 언어 모델(large language model, LLM)이 추측해 채우게 하지 않는다. 원문 위치와 파싱 오류를 남겨 재처리·검토로 보낸다. UTF-8·JSON 파싱 성공과 필수 본문 존재·적절한 MIME·문서 권한은 서로 다른 검사다. Converse의 user/assistant role과 content block을 구조에 맞게 작성하고 지원되지 않는 모달리티는 전송 전에 거른다. Converse 요청과 스트림
벡터 저장소·메타데이터·동기화
벡터(vector) 저장소의 핵심 계약은 문서·청크 ID, 임베딩(embedding) 모델과 차원, 원문 매핑, 필터 메타데이터, 삭제·갱신 경로다. 관련성(Relevance)이 높은 결과도 권한이 없으면 검색 컨텍스트에 들어가면 안 된다. 메타데이터 타입·필드가 수집과 질의 사이에서 바뀌면 필터가 무시되거나 결과가 비게 될 수 있다. 색인은 검색과 필터 패턴에 맞춰 설계하고, 샤딩·다중 인덱스는 분산과 운영 격리를 주지만 조회 분산·핫스팟·관리 비용을 늘린다. 제품별 적정 샤드 수는 데이터 규모와 실제 부하를 확인하지 않고 고정하지 않는다. RAG 내부 흐름/검색 필터·리랭킹·질의 분해/Knowledge Bases 동기화, 공식 출처 안내
원본 추가·수정·삭제 후 동기화가 필요하며, 연결만 했다고 최신 정보가 자동 반영됐다고 가정하지 않는다. 현재 Knowledge Bases 문서는 증분 갱신, 삭제 제거, 조건부 메타데이터-only 최적화를 설명한다. CSV나 사용자 지정 변환(custom transformation)이 있으면 같은 최적화를 가정하지 않는다. 자체 예시에서 부서 이동으로 권한이 바뀐 문서는 원문 접근 제어 목록(access control list, ACL)뿐 아니라 검색 메타데이터·캐시도 함께 갱신해야 한다. 이 행위 원칙은 앱 설계 해설이며 모든 커넥터의 ACL 전파가 검증됐다는 뜻은 아니다.
검색·청킹·리랭킹·질의 분해
고정 크기 청킹(chunking)은 단순하지만 조건·예외가 경계에서 끊길 수 있다. 겹침은 경계 정보를 보완하지만 저장량과 중복 컨텍스트를 늘린다. 계층형은 하위 청크로 찾은 뒤 상위 맥락을 제공하므로 반환 건수가 요청 수보다 작아질 수 있다. 시맨틱 분할은 의미 경계를 활용하며 추가 비용이 든다. 모델을 바꾸면 임베딩 차원과 표현 공간의 호환성을 확인하고 기존 색인과 새 질의를 무분별하게 혼합하지 않는다. 청킹의 설계 절충/검색 필터·리랭킹·질의 분해
시맨틱 검색은 표현의 의미, 키워드 검색은 정확한 코드·문구에 강점이 있다. 하이브리드 지원은 저장소·텍스트 필드 조건을 확인한다. 리랭킹은 가져온 후보의 순서를 개선할 뿐 누락된 문서를 복원하지 않는다. 질의 분해는 ‘두 계약의 해지 조건 비교’를 각 계약 검색으로 나누되 비용·지연·권한 검사를 하위 질의마다 유지한다. 표준 검색 도구 인터페이스에는 query/filter/top-k의 타입과 결과의 출처·버전을 명확히 둔다. 검색 필터·리랭킹·질의 분해/AgentCore Gateway
프롬프트·대화·변경 통제
실제 공식 출처 AIP D1과 AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계을 여섯 기술에 대조했다.
대화 보존에서 유효 기간(time to live, TTL) 만료와 물리 삭제는 다르다. 만료 항목이 저장소에 남아 있더라도 앱은 다시 사용하지 않도록 검사해야 한다. TTL의 동작과 비용과 대화 상태 설계를 함께 읽는다. 정확한 삭제 시한과 저장소별 구현은 별도로 검증한다.
프롬프트 버전 고정, 품질 검토, 조직 승인, 배포 참조 변경은 서로 다른 단계다. 버전과 승인 구분을 바탕으로 변경 관리 흐름을 설계한다. 하위 API와 조직별 승인 시스템의 실제 구현은 별도 확인이 필요하다.
명령·문맥·예시·입력을 구분하고, 외부 데이터가 지시로 해석되지 않게 신뢰 경계를 둔다. 대화 기록은 자동 기억이 아니므로 저장·조회·요약·필터링 경로가 필요하다. 단기 대화 맥락과 장기 선호는 따로 관리하고 모델의 요약을 거래 완료 원장으로 사용하지 않는다. 프롬프트·모델·추론 설정·검색 구성의 버전을 묶어 평가해야 변경 원인을 알 수 있다. 프롬프트 관리/프롬프트 구성과 퓨샷/Converse 요청과 스트림/AgentCore 메모리
자체 계약 검토 앱의 체인은 ‘문서 검증 → 조항 추출 → 근거 확인 → 사용자 표시’로 분해할 수 있다. 각 단계의 출력 스키마와 실패·불확실성 분기를 둔다. 템플릿이 바뀌면 정상·빈 문서·상충 조항·악성 삽입·다국어 사례를 회귀 테스트한다. 모델이 긴 추론 설명을 했다는 것보다 검증 가능한 근거·중간 산출물·최종 조건 충족을 본다. 프롬프트 구성과 퓨샷/AWS Step Functions 오류 처리/평가자 지표의 의미
공식 작업 1.1의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 1.1.1 | 기능 요구사항(functional requirements)과 비기능 요구사항(non-functional requirements), 배포 제약을 함께 만족하는 설계를 고른다. 가장 큰 모델부터 선택하지 않는다. | 요구사항에서 모델·배포·평가를 함께 결정 /교차 리전 추론,Converse 요청과 스트림 |
| 1.1.2 | 개념 증명(PoC)에 대표 입력·실패 입력, 성공 기준, 비용·지연 시간(latency) 측정을 포함한다. 시연 성공과 사업 가치는 따로 판단한다. | 요구사항에서 모델·배포·평가를 함께 결정 /모델 평가와 RAG 평가,평가자 지표의 의미 |
| 1.1.3 | 인증(authentication)·호출·로그(logging)·검증에 쓰는 공통 구성요소를 표준화한다. 구현 시 확인: 생성형 AI(generative AI, GenAI) Lens 세부 심화 확인 필요. | 요구사항에서 모델·배포·평가를 함께 결정 /IAM 인증과 인가,Converse 요청과 스트림 |
공식 작업 1.2의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 1.2.1 | 동일한 평가 세트(evaluation set)에서 모델별 품질·지연 시간(latency)·비용과 제약을 비교한다. | 요구사항에서 모델·배포·평가를 함께 결정 /모델 평가와 RAG 평가,평가자 지표의 의미 |
| 1.2.2 | 라우팅(routing) 설정과 호출 어댑터(adapter)를 업무 코드에서 분리하고 요청·응답 스키마(schema)의 호환성을 확인한다. 구현 시 확인: 구성 배포 API별 세부 확인 필요. | 모델 교체·복원력·버전 수명주기 /Converse 요청과 스트림,지능형 모델 라우팅,AWS AppConfig 구성 배포 |
| 1.2.3 | 장애 감지, 제한된 재시도(retry), 회로 차단(circuit breaking), 허용된 대체 경로(fallback)의 역할을 구분한다. | 모델 교체·복원력·버전 수명주기 /교차 리전 추론,Step Functions 오류 처리 |
| 1.2.4 | 모델·어댑터(adapter)·평가·승인·배포 버전을 추적하고 호환되는 이전 구성으로 되돌릴 롤백(rollback) 방법을 정한다. 구현 시 확인: LoRA/훈련 설정 모델별 호스팅 확인 필요. | 모델 교체·복원력·버전 수명주기 /모델 사용자 지정,Model Registry,미세 조정과 하이퍼파라미터 |
공식 작업 1.3의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 1.3.1 | 데이터 누락·중복·스키마(schema)·최신성 검사를 정의하고 검사에 실패한 데이터를 격리한다. | 입력 데이터 계약과 품질 검사 /Glue Data Quality |
| 1.3.2 | 텍스트·음성·영상의 변환(transformation) 오류를 기록하고 변환 결과가 원문의 어느 부분인지 연결한다. 구현 시 확인: Processing 세부 확인 필요. | 입력 데이터 계약과 품질 검사 /Transcribe 입력·출력과 운영 방식,청킹의 설계 절충 |
| 1.3.3 | 모델별 요청에서 역할(role), 콘텐츠(content), MIME 유형과 필수 필드를 검증한다. | 입력 데이터 계약과 품질 검사 /Converse 요청과 스트림 |
| 1.3.4 | 정규화(normalization)와 개체 추출(entity extraction)로 입력을 정리하되 원래 의미와 수치를 보존한다. | 입력 데이터 계약과 품질 검사 /Comprehend 분석과 사용자 지정,Glue Data Quality |
공식 작업 1.4의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 1.4.1 | 벡터(vector)·문서·메타데이터(metadata)를 어떤 형식으로 연결해 저장할지 정하고 실제 접근 패턴에 맞춘다. 구현 시 확인: DB 별 엔진 구조 심화 확인 필요. | 벡터 저장소·메타데이터·동기화 /RAG 내부 흐름,검색 필터·리랭킹·질의 분해 |
| 1.4.2 | 문서 버전·소유자·시각·도메인의 메타데이터(metadata)를 일관된 자료형(data type)으로 수집한다. | 벡터 저장소·메타데이터·동기화 /검색 필터·리랭킹·질의 분해,Knowledge Bases 동기화 |
| 1.4.3 | 샤딩(sharding)과 다중 인덱스(multiple indexes)는 규모 확장·격리에 유용하지만 질의 비용도 늘 수 있으므로 함께 비교한다. 구현 시 확인: 샤드 선택 공식 근거 부하별 최적값은 미확정. | 벡터 저장소·메타데이터·동기화 /OpenSearch 샤드 선택 |
| 1.4.4 | 커넥터(connector)가 데이터를 가져올 때 인증(authentication), 입력 형식, 원문 ID, 접근 권한과 오류 처리 방법을 명확히 정한다. 구현 시 확인: 커넥터별 ACL 확인 필요. | 벡터 저장소·메타데이터·동기화 /Knowledge Bases 동기화 |
| 1.4.5 | 증분 갱신(incremental update), 삭제, 메타데이터(metadata) 변경이 실제 색인(index)에 반영됐는지 추적한다. | 벡터 저장소·메타데이터·동기화 /Knowledge Bases 동기화 |
공식 작업 1.5의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 1.5.1 | 고정 크기·계층형·시맨틱 청킹(fixed-size/hierarchical/semantic chunking)을 비교해 예외 조건과 문맥을 보존하고 정확성·비용 요구에 맞춘다. | 검색·청킹·리랭킹·질의 분해 /청킹의 설계 절충 |
| 1.5.2 | 임베딩(embedding)의 언어·도메인·차원(dimension)·색인 호환성과 비용을 확인한다. 구현 시 확인: 모델별 벤치마크 확인 필요. | 검색·청킹·리랭킹·질의 분해 /RAG 내부 흐름,청킹의 설계 절충 |
| 1.5.3 | 벡터(vector) 엔진·차원·거리 척도(distance metric)·메타데이터 조건을 검색 구성과 일치시킨다. 구현 시 확인: pgvector 구체 튜닝 확인 필요. | 벡터 저장소·메타데이터·동기화 ·검색 품질 /검색 필터·리랭킹·질의 분해 |
| 1.5.4 | 하이브리드 검색(hybrid search)으로 후보를 찾고 리랭커(reranker)로 순서를 다시 매긴다. 검색과 재정렬의 성능을 따로 측정한다. | 검색·청킹·리랭킹·질의 분해 /검색 필터·리랭킹·질의 분해 |
| 1.5.5 | 질의 분해(query decomposition)로 복합 질문을 나누되 원래 의미가 달라지거나 호출이 늘어나는 영향을 평가한다. | 검색·청킹·리랭킹·질의 분해 /검색 필터·리랭킹·질의 분해 |
| 1.5.6 | 함수 또는 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)의 검색 입출력을 표준화하고 인가(authorization)는 별도로 적용한다. | 검색·청킹·리랭킹·질의 분해 /AgentCore Gateway,도구 실행 책임 |
공식 작업 1.6의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 1.6.1 | 프롬프트(prompt)에 역할·출력 형식·금지 행동을 명시하고 정해진 규칙으로 확인하는 결정적 검증(deterministic validation)을 함께 설계한다. | 프롬프트·대화·변경 통제 /프롬프트 구성과 퓨샷,AgentCore 정책 |
| 1.6.2 | 대화 이력(conversation history)·요약(summary)·영속 상태(persistent state)를 구분하고 세션(session)을 격리한다. 구현 시 확인: TTL 하위본문·구현 확인 필요. | 프롬프트·대화·변경 통제 /Converse 요청과 스트림,AgentCore 메모리,DynamoDB TTL과 실제 삭제 시점 |
| 1.6.3 | 프롬프트(prompt)의 저장·승인·배포·사용 로그(logs)를 버전(version)으로 연결한다. 구현 시 확인: 승인 시스템별 세부 확인 필요; 버전·배포 개요 보충만. | 프롬프트·대화·변경 통제 /프롬프트 관리,모델 호출 로깅,프롬프트 버전과 배포 승인 구분 |
| 1.6.4 | 스키마(schema), 경계 사례(edge case), 회귀(regression)를 자동 평가의 검사 항목으로 정한다. | 프롬프트·대화·변경 통제 /Step Functions 오류 처리,평가자 지표의 의미 |
| 1.6.5 | 실패 유형에 맞춰 지침(instruction)·예시(example)·문맥(context)을 수정하고 동일한 테스트로 개선 여부를 비교한다. | 프롬프트·대화·변경 통제 /프롬프트 구성과 퓨샷,평가자 지표의 의미 |
| 1.6.6 | 프롬프트 체인(prompt chain)의 단계별 입출력, 조건 분기, 오류 전파와 재사용 방법을 정한다. 구현 시 확인: 버전·별칭 개별 노드 스키마 확인 필요. | 프롬프트·대화·변경 통제 /Step Functions 오류 처리,Flows 버전과 별칭 |
영역 2 — 에이전트 실행·배포·기업 연계
에이전트의 행동과 상태를 통제
에이전트(agent)의 실행 과정은 공식 출처 AIP D2와 AIP-C01 영역 2 — 에이전트·배포·기업 시스템 통합에서 이어서 읽는다. 프레임워크(framework)별 SDK 구현에서 추가로 확인할 조건은 각 기술 행에 표시했다.
모델이 도구 호출을 제안하는 것과 도구가 실제로 성공한 것은 다르다. 클라이언트 측 도구 사용에서는 앱이 함수명·인수 스키마·권한·허용값을 검증하고 실행한 결과를 다시 모델에 전달한다. 서버 측 모드는 해당 API/모델 및 등록 방식 조건을 확인한다. MCP 도구를 추가했다고 검증·승인 책임이 사라지지 않는다. 입력으로 받은 외부 문서·도구 결과를 실행 지시로 승격하지 않는다. AgentCore Gateway/도구 실행 책임/AgentCore 정책
자체 환불 에이전트는 ‘주문 조회 → 자격 확인 → 사용자 확인 → 환불 실행 → 결과 확인’ 단계로 구성한다. 승인 대기·실행 중·성공·실패·결과 불명 상태를 구분하고 최대 반복·시간·토큰·도구 범위를 제한한다. 네트워크 시간 초과 후 같은 환불을 무조건 재실행하면 중복 부작용이 생길 수 있으므로 멱등 키나 상태 조회를 설계한다. 여러 에이전트가 참여할 때는 실행 권한자와 상태 기록 주체를 분명히 둔다. 이는 공식 도구·워크플로 원리에 따른 자체 설계이며 완성된 특정 프레임워크 코드가 아니다. Step Functions 오류 처리/도구 실행 책임/AgentCore 메모리
배포·메모리·용량의 선택
실제 공식 출처 AIP D2와 AIP-C01 영역 2 — 에이전트·배포·기업 시스템 통합 대조. Bedrock 프로비저닝된 처리량과 용량 변경 조건의 모델 단위(Model Unit, MU)/토큰 방식·약정·변경 조건을 통합하되 자동확장 현행 지원은 미확정이다.
Bedrock 호출 앱과 모델 가중치를 직접 호스팅하는 서버는 다른 시스템이다. 모델 자체를 Lambda에 올린다는 뜻으로 ‘Lambda를 통한 온디맨드 호출’을 해석하지 않는다. 직접 호스팅에서는 가중치 로딩·디스크·GPU 메모리·동시 요청·토큰 생성 부하를 분리해 본다. 대형 모델 다운로드 시간 초과와 컨테이너 시작 상태검사 시간 초과에는 다른 설정이 있다. 디스크를 늘려도 추론 시 GPU 메모리 부족이 해결되는 것은 아니다. 대규모 모델 호스팅, 공식 출처 안내
작은 모델·캐스케이드·프로비저닝 용량은 품질 하한과 이용률을 기준으로 선택한다. 트래픽이 일정하면 고정 용량을 검토할 수 있지만 낮은 이용률이면 낭비가 된다. 복잡한 요청을 큰 모델로 올리는 구조는 라우팅 오판과 두 번 호출하는 비용도 측정한다. 평균 요청 수만이 아니라 입력·출력 토큰 분포와 긴 요청의 꼬리 지연을 봐야 한다. 모델 사용자 지정/교차 리전 추론/지능형 모델 라우팅
API·기업 통합·장애 경계
실제 D2 2.3~2.5 강좌의 설명을 AIP-C01 영역 2 — 에이전트·배포·기업 시스템 통합에 연결했다. API 키·사용량 계획은 인증·인가와 엄격한 비용 상한이 아니다·Amazon Verified Permissions의 정책 평가와 애플리케이션의 집행 책임·AWS Outposts 로컬 실행과 리전 서비스 연결을 구분하기의 제품 경계를 통합한다. 2.5의 API/UI/업무·개발보조·고급에이전트·문제해결 6 기술은 아래 개별 앵커로 연결하며 SDK·지원표 잔여는 그대로다.
동기(synchronous) 방식은 호출자가 결과를 기다리고, 비동기(asynchronous) 방식은 먼저 접수 ID를 받은 뒤 결과를 조회하거나 통지받는다. 스트리밍(streaming)은 생성 중인 응답을 나누어 전달한다. 비동기와 스트리밍은 동의어가 아니다. ConverseStream에서는 블록 인덱스별 delta를 조합하고 messageStop의 이유 및 마지막 usage/metrics를 확인한다. 텍스트 일부가 도착한 뒤 연결이 끊긴 것을 완전한 성공으로 기록하지 않는다. 도구의 JSON 조각은 완결·검증 전에 실행하지 않는다. Converse 요청과 스트림
오류는 인증·인가, 잘못된 요청, 할당량·일시 장애, 시간 초과, 의미적 품질 실패로 나눈다. 형식 오류를 지수 백오프로 반복해도 고쳐지지 않는다. 재시도 횟수·지연 상한·지터를 정하고 실패 시 사용자가 알 수 있는 상태를 남긴다. 기업 연계에서는 API 계약·이벤트 ID·중복 처리·데이터 동기화·최소 권한이 필요하다. 지속적 통합·전달(continuous integration /continuous delivery, CI/CD)는 코드만이 아니라 모델·프롬프트·도구 스키마·평가 세트를 함께 검사하고 배포 게이트와 롤백을 둔다. IAM 인증과 인가/Step Functions 오류 처리/Model Registry
공식 작업 2.1의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 2.1.1 | 단기·장기 메모리(short-term/long-term memory)와 작업 상태(task state)를 구분하고 다중 에이전트(multi-agent)에서 누가 상태를 관리하는지 정한다. 구현 시 확인: Strands/Agent Squad 코드 심화 확인 필요. | 에이전트의 행동과 상태를 통제 /AgentCore 구성요소와 MCP,AgentCore 메모리 /D2 상세 |
| 2.1.2 | ReAct의 문제 분해·도구 실행(tool execution)·결과 관찰(observation)·다음 행동 선택을 각각 검증 가능한 단계로 만든다. 구현 시 확인: ReAct 프레임워크별 심화 확인 필요. | 에이전트의 행동과 상태를 통제 /Step Functions 오류 처리,도구 실행 책임 /D2 상세 |
| 2.1.3 | 에이전트(agent)의 반복 횟수·실행 시간·비용·도구 권한을 제한하고 오류가 나면 언제 중지할지 정한다. | 에이전트의 행동과 상태를 통제 /Step Functions 오류 처리,AgentCore 정책 /D2 상세 |
| 2.1.4 | 전문 모델(specialized model)의 역할, 결과 집계(aggregation)와 충돌 해결 방법을 정한다. 모두 병렬 호출하면 비용이 늘어난다. 구현 시 확인: 앙상블 상세 확인 필요. | 에이전트의 행동과 상태를 통제 ·모델 배포 /지능형 모델 라우팅 /D2 상세 |
| 2.1.5 | 고위험 행동 전에 사람 승인(human approval)을 받고, 승인 만료·거절과 실제 실행 결과를 구분해 관리한다. 구현 시 확인: 콜백 구현별 심화 확인 필요. | 에이전트의 행동과 상태를 통제 /Step Functions 오류 처리,AgentCore 정책 /D2 상세 |
| 2.1.6 | 도구(tool)의 함수 정의, 인수(arguments)의 형식과 범위, 오류를 검증하고 실행 결과를 모델에 반환한다. | 에이전트의 행동과 상태를 통제 /도구 실행 책임 /D2 상세 |
| 2.1.7 | MCP 도구의 입출력 명세와 인증(authentication)을 분리하고, 짧은 무상태(stateless) 작업과 장기 실행 서버의 배포 조건을 비교한다. 구현 시 확인: Lambda/ECS MCP 세부 확인 필요. | 에이전트의 행동과 상태를 통제 /AgentCore Gateway /D2 상세 |
공식 작업 2.2의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 2.2.1 | 관리형 호출(managed invocation)과 직접 호스팅(self-hosting)을 구분하고 변동 부하 및 고정 용량의 비용을 평가한다. | 배포·메모리·용량의 선택 /교차 리전 추론,대규모 모델 호스팅 /D2 상세 |
| 2.2.2 | 모델 다운로드·시작·GPU 메모리와 생성 처리량(throughput)의 병목(bottleneck)을 구분한다. 구현 시 확인: GPU 병렬화 세부 확인 필요. | 배포·메모리·용량의 선택 /대규모 모델 호스팅 /D2 상세 |
| 2.2.3 | 작은 모델과 캐스케이드(cascade)로 비용을 줄일 때도 최소 품질 기준을 유지하고 두 모델을 연속 호출하는 비용을 측정한다. | 배포·메모리·용량의 선택 /모델 사용자 지정,지능형 모델 라우팅 /D2 상세 |
공식 작업 2.3의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 2.3.1 | 기존 시스템(legacy system)의 API와 이벤트(event)를 느슨하게 연결하되 버전·중복 처리·재동기화를 관리한다. 구현 시 확인: 서비스별 이벤트 계약 확인 필요. | API·기업 통합·장애 경계 /Step Functions 오류 처리,Knowledge Bases 동기화 /D2 상세 |
| 2.3.2 | 웹훅(webhook)의 원천을 검증하고 이벤트 ID, 비동기 처리(asynchronous processing), 오류 후 복구 방법을 정한다. 구현 시 확인: EventBridge 상세 확인 필요. | API·기업 통합·장애 경계 /Step Functions 오류 처리 /D2 상세 |
| 2.3.3 | 사용자 인증(user authentication)과 도구 서비스의 인증을 분리하고 각 역할에 최소 권한(least privilege)을 적용한다. | API·기업 통합·장애 경계 /IAM 인증과 인가,AgentCore Gateway /D2 상세 |
| 2.3.4 | 허용된 데이터 처리 위치(data residency)를 유지하면서 환경 간 연결 경로·인증(authentication)·지연 시간(latency)을 설계한다. 구현 시 확인: Outposts/Wavelength 세부 확인 필요. | API·기업 통합·장애 경계 /PrivateLink와 네트워크 경계,교차 리전 추론 /D2 상세 |
| 2.3.5 | 배포 과정에 중앙 게이트웨이(gateway), 평가 통과 기준(evaluation gate), 승인(approval), 롤백(rollback)을 포함한다. 구현 시 확인: CodePipeline/Build 세부 확인 필요. | API·기업 통합·장애 경계 /AgentCore Gateway,Model Registry /D2 상세 |
공식 작업 2.4의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 2.4.1 | 동기(synchronous) 결과 반환과 비동기(asynchronous) 작업의 접수·상태 조회·결과 전달을 구분한다. | API·기업 통합·장애 경계 /Converse 요청과 스트림,Step Functions 오류 처리 /D2 상세 |
| 2.4.2 | 스트리밍(streaming)의 부분 토큰 전달, 취소와 최종 완료를 구분하고 스트림 이벤트를 순서대로 조합한다. 구현 시 확인: 프런트엔드 전송 구현 확인 필요. | API·기업 통합·장애 경계 /Converse 요청과 스트림 /D2 상세 |
| 2.4.3 | 재시도(retry) 가능한 오류에만 백오프(backoff)·지터(jitter)를 적용하고 대체 경로(fallback)와 관찰성(observability)을 함께 설계한다. | API·기업 통합·장애 경계 /Step Functions 오류 처리 /D2 상세 |
| 2.4.4 | 정적 라우팅(static routing), 내용 기반·지표 기반 라우팅을 구분하고 정책(policy)으로 허용 후보를 먼저 제한한다. | 모델 교체·복원력·버전 수명주기/API·기업 통합·장애 경계 /지능형 모델 라우팅 /D2 상세 |
공식 작업 2.5의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 2.5.1 | 토큰(token) 사용량, 타임아웃(timeout), 부분 응답을 API의 상태·반환 형식·오류 코드로 명확히 표현한다. 구현 시 확인: 정확 제품/API·실행 검증 확인 필요. | API·기업 통합·장애 경계 /Converse 요청과 스트림,Step Functions 오류 처리 /D2 상세 |
| 2.5.2 | OpenAPI와 스키마(schema)로 요청·응답 형식을 정하고 사용자 인터페이스(UI)는 진행·오류·완료를 구별해 보여 준다. 구현 시 확인: Amplify/Flows UI 세부 확인 필요; 정확 제품/API·실행 검증 확인 필요. | API·기업 통합·장애 경계 /AgentCore Gateway /D2 상세 |
| 2.5.3 | 문서 처리(document processing)에서 검증(validation)·변환(transformation)·추출(extraction)·업무 반영을 별도 단계로 다룬다. 구현 시 확인: Data Automation 전용 심화 확인 필요; 정확 제품/API·실행 검증 확인 필요. | 입력 데이터 계약과 품질 검사/API·기업 통합·장애 경계 /Glue Data Quality /D2 상세 |
| 2.5.4 | 생성 코드를 리뷰(code review)·테스트(testing)·보안 검사(security scanning)하며, 결과 검증의 책임은 개발 체계에 둔다. 구현 시 확인: Q Developer 전용 한국어 심화 확인 필요; 정확 제품/API·실행 검증 확인 필요. | API·기업 통합·장애 경계 /공식 출처 안내 /D2 상세 |
| 2.5.5 | 프롬프트 체인(prompt chain)과 동적 에이전트 루프(agent loop)가 상태를 관리하고 실패를 처리하는 방법을 구분한다. 구현 시 확인: 프레임워크별 API 확인 필요; 정확 제품/API·실행 검증 확인 필요. | 프롬프트·대화·변경 통제/에이전트의 행동과 상태를 통제 /Step Functions 오류 처리,도구 실행 책임 /D2 상세 |
| 2.5.6 | 요청 ID(request ID)로 모델·검색·도구 실행과 프롬프트 버전(prompt version)의 기록을 연결해 원인을 조사한다. 구현 시 확인: X-Ray 전용 계측 심화 확인 필요; 정확 제품/API·실행 검증 확인 필요. | API·기업 통합·장애 경계 /관찰성 — 지표·감사·호출 로그의 차이,모델 호출 로깅 /D2 상세 |
영역 3 — 안전·개인정보·감사·책임
심층 방어와 권한의 분리
입력 필터 → 모델·컨텍스트 통제 → 출력 검증 → 도구 실행 전 정책을 함께 둔다. 프롬프트 인젝션은 외부 콘텐츠가 지시로 취급될 때 발생할 수 있으므로 필터만이 아니라 역할·출처 구분과 최소 권한이 중요하다. JSON Schema가 통과해도 사실이 틀리거나 권한 없는 문서를 참조할 수 있다. text-to-SQL 또한 모델이 만든 SQL이므로 읽기 전용·허용 테이블·파라미터·결과 크기·검토 조건 없이 ‘결정적이고 안전’하다고 하지 않는다. Guardrails의 역할과 경계/IAM 인증과 인가/Converse 요청과 스트림/AgentCore 정책
자체 예시: 상담원이 ‘고객 계좌를 보여줘’라고 물으면 인증된 상담원인지, 해당 고객을 담당하는지, 어떤 필드가 필요한지 검증한다. 개인 식별 정보(personally identifiable information, PII) 마스킹은 필요한 식별 능력과 프라이버시의 절충이다. 익명화는 다른 정보와 재결합해 재식별될 가능성도 검토해야 한다. 네트워크 사설화·암호화·자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM)·문서 권한·콘텐츠 필터는 서로 대체하지 않는다. Bedrock 데이터 보호/IAM 인증과 인가/PrivateLink와 네트워크 경계, 공식 출처 안내
계보·로깅·설명·공정성
감사 체인은 주체 → 요청 → 프롬프트·모델 버전 → 검색 문서 버전 → 도구·승인 → 최종 결과를 연결한다. 모델 호출 로그의 identity.arn과 사용자가 입력한 requestMetadata는 신뢰 수준이 다르다. 로그 설정을 켜도 지원 엔드포인트·데이터 유형·목적지가 맞지 않으면 필요한 증거가 빠질 수 있다. S3/CloudWatch 대상 권한과 키 관리 서비스(AWS Key Management Service, KMS) 권한을 분리하고 보존·삭제를 설계한다. 관찰성 — 지표·감사·호출 로그의 차이/모델 호출 로깅/Model Registry/Knowledge Bases 동기화
정확성·충실도(Faithfulness)·공정성·설명은 각각 다른 질문이다. 출처가 있어도 그 출처 자체가 오래되거나 잘못됐을 수 있고, 설명이 자연스러워도 모델의 실제 원인 분석은 아닐 수 있다. 사용자에게 근거·한계·불확실성과 수정·이의제기 경로를 제시한다. 하위 그룹의 평가 세트·표본 수·오류율을 검토하고 모델 변경 뒤 같은 기준으로 회귀를 확인한다. 자동 경보는 검토·수정 담당자와 연결돼야 한다. 모델 카드와 설명 가능성/설명 가능성과 SHAP/훈련 전 편향/LLM 평가자/평가자 지표의 의미
공식 작업 3.1의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 3.1.1 | 모델 호출 전에 입력 안전(input safety) 검사로 유해·금지 내용과 데이터 구조를 확인한다. | 심층 방어와 권한의 분리 /Guardrails의 역할과 경계,Converse 요청과 스트림 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.1.2 | 사용자에게 보여 주기 전에 출력 필터(output filter)와 업무 검증을 적용한다. SQL 생성(Text-to-SQL)만으로 실행 안전이 보장되지는 않는다. 구현 시 확인: SQL 전용 통제 심화 확인 필요. | 심층 방어와 권한의 분리 /Guardrails의 역할과 경계,AgentCore 정책 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.1.3 | 스키마(schema), 근거 충실도(faithfulness), 사실적 정확성(factual accuracy)을 각각 검사한다. | 심층 방어와 권한의 분리 /검색 필터·리랭킹·질의 분해,평가자 지표의 의미 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.1.4 | 전처리(preprocessing)·모델 처리·후처리(postprocessing)·API 및 도구 정책을 조합해 다층 방어(defense in depth)를 구성한다. | 심층 방어와 권한의 분리 /Guardrails의 역할과 경계,IAM 인증과 인가,AgentCore 정책 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.1.5 | 평가 세트에 직접·간접 프롬프트 인젝션(direct/indirect prompt injection)과 탈옥(jailbreak) 시도를 포함한다. 구현 시 확인: 공격별 탐지 성능 확인 필요. | 심층 방어와 권한의 분리 /Guardrails의 역할과 경계,AgentCore 정책 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
공식 작업 3.2의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 3.2.1 | 가상 프라이빗 클라우드(Amazon Virtual Private Cloud, VPC)의 연결 경로, IAM 권한, 데이터 접근 권한을 각각 검증한다. 사설 경로 자체가 인가(authorization)를 부여하지는 않는다. 구현 시 확인: Lake Formation 기본은 기존 Lake Formation 접근 제어; 통합별 상세 확인 필요. | 심층 방어와 권한의 분리 /IAM 인증과 인가,PrivateLink와 네트워크 경계 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.2.2 | 개인 식별 정보(PII) 탐지, 데이터 보존 기간(retention period), 로그(logs)의 수집 목적과 삭제 대상을 정한다. 구현 시 확인: Amazon Macie/S3 기본은 기존 Macie의 발견 범위 ·S3 수명주기 전환 조건; 전수 상세 확인 필요. | 심층 방어와 권한의 분리 ·계보와 감사 /Bedrock 데이터 보호,모델 호출 로깅 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.2.3 | 마스킹(masking)·익명화(anonymization)의 보호 효과와 업무 효용을 비교하고 재식별(re-identification) 위험을 평가한다. 구현 시 확인: 기법별 공식 심화 확인 필요. | 심층 방어와 권한의 분리 /Bedrock 데이터 보호 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
공식 작업 3.3의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 3.3.1 | 모델 카드(model card), 훈련·평가 정보, 원문 계보(data lineage), 결정 로그(decision log)를 연결한다. 구현 시 확인: Glue 계보 세부 확인 필요. | 계보·로깅·설명·공정성 /모델 카드와 설명 가능성,Model Registry /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.3.2 | 문서 ID·버전(version), 인용(citation), 감사 ID(audit ID)를 이용해 생성 내용의 근거를 추적한다. | 계보·로깅·설명·공정성 /모델 호출 로깅,Knowledge Bases 동기화 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.3.3 | 정책 소유자(policy owner), 검토 주기, 승인(approval)·예외 처리, 사고 대응(incident response)을 정한다. 구현 시 확인: 조직별 규제는 별도 판단. | 계보·로깅·설명·공정성 /AgentCore 정책 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.3.4 | 오용(misuse), 드리프트(drift), 정책 위반 신호를 경보(alarm)와 수정 절차(workflow)에 연결한다. 구현 시 확인: 탐지 규칙별 심화 확인 필요. | 계보·로깅·설명·공정성 /관찰성 — 지표·감사·호출 로그의 차이,모델 호출 로깅,훈련 전 편향 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
공식 작업 3.4의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 3.4.1 | 답변의 근거와 불확실성(uncertainty)을 표시하되 생성된 설명(explanation)을 실제 인과관계의 증명으로 받아들이지 않는다. | 계보·로깅·설명·공정성 /설명 가능성과 SHAP,평가자 지표의 의미 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.4.2 | 하위 집단(subgroup)과 상황별 품질·피해를 동일한 평가 기준으로 비교해 공정성(fairness)을 살핀다. 구현 시 확인: 공정성 지표별 상세 확인 필요. | 계보·로깅·설명·공정성 /훈련 전 편향,LLM 평가자 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
| 3.4.3 | 정책 위반을 정해진 규칙에 따른 결정적 검증(deterministic validation)으로 제한하고 확인한 범위와 한계를 모델 카드(model card)에 남긴다. | 심층 방어와 권한의 분리 ·계보와 감사 /모델 카드와 설명 가능성,AgentCore 정책 /AIP-C01 영역 3 — 안전·프라이버시·거버넌스 |
영역 4 — 비용·성능·관찰성
토큰·캐시·처리량을 함께 최적화
비용은 입력·출력·캐시 읽기·쓰기·검색·도구·평가·실패 재시도로 분해한다. 프롬프트를 줄이면 비용과 지연이 줄 기회가 있지만 필수 근거·안전 지침까지 잘라내면 품질이 나빠진다. 고정 시스템·도구·참고 문서를 안정적인 접두사로 두고 변하는 질의를 뒤에 두면 프롬프트 캐싱(prompt caching) 재사용 기회가 늘어난다. 암시적·명시적 모두 적중 보장이 없고 최소 토큰·TTL·모델/API 조건을 확인한다. 프롬프트 캐싱의 조건/추론 파라미터/Converse 요청과 스트림
응답 캐시는 완성된 답을 재사용하고 프롬프트 캐시는 입력 처리 결과를 재사용한다. 시맨틱 응답 캐시는 질문 표현이 달라도 재사용하므로 비슷하지만 조건이 다른 질의를 잘못 합칠 위험이 있다. 자체 보험 약관 앱의 캐시 키에는 사용자 권한 범위·약관 버전·모델·프롬프트 버전을 고려해야 하며 개인정보 답변을 다른 사용자에게 재사용해서는 안 된다. 캐시 hit만 보지 말고 쓰기 증가와 오래된 답변 비율을 함께 본다.
성능을 개선할 때 전체 시간을 인증·검색·리랭크·모델·도구·전송으로 나눈다. 스트리밍은 첫 응답을 빨리 보여줄 수 있으나 전체 생성량을 줄이는 것은 아니다. 독립 검색은 병렬화할 수 있지만 선행 결과가 필요한 거래 작업은 무조건 병렬화하면 안 된다. 배치 처리·동시성·오토 스케일링은 요청 수보다 토큰과 긴 요청의 분포에 민감하다. 직접 호스팅의 로딩 문제는 정상 추론의 지연 문제와 구분한다. 청킹의 설계 절충/교차 리전 추론/Converse 요청과 스트림/대규모 모델 호스팅
운영 지표와 실제 품질을 연결
모니터링에는 요청 수·오류·지연·토큰·캐시뿐 아니라 검색 근거 품질·작업 완료율·사람 개입률·잘못된 답변의 심각도를 포함한다. CloudWatch에 로그가 있다는 사실만으로 할루시네이션(hallucination)률이 자동 측정되지는 않는다. 골든 데이터·사람 표본·평가자 판정으로 품질 레이블을 만들고 지표로 집계해야 한다. 평균 외 p95 등 꼬리 지연과 사용자군별 차이도 본다. 관찰성 — 지표·감사·호출 로그의 차이/모델 호출 로깅/LLM 평가자/평가자 지표의 의미
도구 실패는 모델 응답 실패와 다르다. 잘못된 함수 선택, 잘못된 인수, 권한 거부, 실행 실패, 결과 반환 누락을 구분한다. 벡터 저장소는 조회 지연과 함께 색인 최신성·실패 문서·메타데이터 타입·원문 삭제를 감시한다. 장애 조사에서 입력 데이터와 프롬프트 버전, 모델 버전, 검색 문서, 도구 결과를 같은 request/trace ID로 묶으면 원인을 좁힐 수 있다. 검색 필터·리랭킹·질의 분해/Step Functions 오류 처리/Knowledge Bases 동기화/도구 실행 책임
공식 작업 4.1의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 4.1.1 | 토큰 예산(token budget)을 지침·대화 이력·검색 근거·출력에 배분하고 필수 정보를 보존한다. | 토큰·캐시·처리량을 함께 최적화 /프롬프트 캐싱의 조건,추론 파라미터 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.1.2 | 최소 품질 기준(quality threshold)을 충족하는 모델을 대상으로 전체 비용(total cost)을 비교한다. | 토큰·캐시·처리량을 함께 최적화 /지능형 모델 라우팅 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.1.3 | 배치(batch)·동시성(concurrency)·확보 용량의 이용률(utilization)과 대기 시간을 함께 측정한다. 구현 시 확인: 서비스별 튜닝 확인 필요. | 토큰·캐시·처리량을 함께 최적화 /교차 리전 추론,대규모 모델 호스팅 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.1.4 | 프롬프트 캐시(prompt cache), 응답 캐시(response cache), 시맨틱 캐시(semantic cache)의 재사용 대상과 무효화(invalidation) 조건을 구분한다. 구현 시 확인: 응답 캐시 구현 상세 확인 필요. | 토큰·캐시·처리량을 함께 최적화 /프롬프트 캐싱의 조건 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
공식 작업 4.2의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 4.2.1 | 첫 토큰까지 걸린 시간(time to first token, TTFT)과 전체 완료 시간을 구분하고 서로 독립적인 단계만 병렬화(parallelization)한다. | 토큰·캐시·처리량을 함께 최적화 /Converse 요청과 스트림 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.2.2 | 검색과 리랭킹(reranking)의 지연 시간(latency), 검색 관련성(relevance)을 함께 측정한다. 구현 시 확인: 인덱스 엔진 튜닝 확인 필요. | 토큰·캐시·처리량을 함께 최적화 /검색 필터·리랭킹·질의 분해 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.2.3 | 토큰(token) 부하와 동시 호출 수(concurrency)를 제한하고 할당량(quota) 오류를 별도로 분류한다. | 토큰·캐시·처리량을 함께 최적화 /Step Functions 오류 처리,대규모 모델 호스팅 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.2.4 | 모델별 파라미터(parameter)를 동일한 평가 세트에서 비교한다. 낮은 온도(temperature)도 정답을 보장하지는 않는다. | 토큰·캐시·처리량을 함께 최적화 /추론 파라미터,Converse 요청과 스트림 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.2.5 | 입력·출력 길이, 순간 부하 증가(burst), 오래 걸리는 요청을 반영해 용량 계획(capacity planning)을 세운다. 구현 시 확인: 오토 스케일 공식 상세 확인 필요. | 토큰·캐시·처리량을 함께 최적화 /프롬프트 캐싱의 조건,대규모 모델 호스팅 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.2.6 | 전체 호출 경로를 측정하는 프로파일링(profiling)으로 실제 병목(bottleneck)을 찾고 같은 조건에서 최적화 전후를 비교한다. | 토큰·캐시·처리량을 함께 최적화 ·관찰성 /관찰성 — 지표·감사·호출 로그의 차이,Converse 요청과 스트림 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
공식 작업 4.3의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 4.3.1 | 시스템 성능(system performance)과 사용자 경험·업무 결과를 동일한 버전(version)을 기준으로 연결한다. | 운영 지표와 실제 품질을 연결 /관찰성 — 지표·감사·호출 로그의 차이,모델 호출 로깅 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.3.2 | 토큰(token)·비용·품질의 이상을 구분하고 환각률(hallucination rate)을 측정할 정답·근거와 평가 방법을 준비한다. | 운영 지표와 실제 품질을 연결 /모델 호출 로깅,평가자 지표의 의미 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.3.3 | 운영 보고(operational report), 사업 보고, 규정 준수 보고(compliance report)를 구분하되 요청 ID로 관련 기록을 연결한다. | 운영 지표와 실제 품질을 연결 /모델 호출 로깅,LLM 평가자 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.3.4 | 도구(tool) 선택·인수(arguments)·실행·결과 반환과 다중 에이전트 조정(multi-agent orchestration)의 실패를 구분한다. | 운영 지표와 실제 품질을 연결 /AgentCore 구성요소와 MCP,도구 실행 책임 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.3.5 | 검색 지연뿐 아니라 동기화(synchronization), 삭제, 처리 실패 문서와 색인(index)의 품질을 감시한다. 구현 시 확인: 자동 인덱스 최적화 확인 필요. | 운영 지표와 실제 품질을 연결 /검색 필터·리랭킹·질의 분해,Knowledge Bases 동기화 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
| 4.3.6 | 골든 데이터세트(golden dataset), 근거 문서, 도구 실행 경로를 대조해 환각(hallucination)·불일치·논리 오류를 구분한다. | 운영 지표와 실제 품질을 연결 /RAG 평가,평가자 지표의 의미 /AIP-C01 영역 4 — 비용·성능·관찰성 최적화 |
영역 5 — 평가와 문제 해결
평가 설계·배포 게이트·증상별 진단
평가 세트(evaluation set)에는 정상·금지·모호한 요청, 비어 있거나 오래되거나 상충하는 문서, 긴 입력과 도구 실패를 포함한다. 정확성(correctness), 완전성(Completeness), 충실도(faithfulness), 관련성(relevance), 유해성(harmfulness), 고정관념(stereotyping), 거부(refusal)는 각각 평가한다. 완전성은 질문 전체에 답했는지, 충실도는 제공된 근거 밖의 주장을 했는지, 관련성은 질문에 맞게 답했는지를 살핀다. ‘정중하게 거부’도 정상 질문에서는 실패이고 금지된 행동에서는 성공일 수 있다. 요약의 BERTScore 같은 지표와 분류 정확도(Accuracy)를 같은 수식으로 비교하지 않는다. RAG 평가/자동 평가 과업과 지표/LLM 평가자/텍스트 요약 평가/평가자 지표의 의미
사람 평가에는 채점 기준·예시·불일치 조정이 필요하고 LLM 평가자(LLM-as-a-judge)에도 버전·프롬프트·판정 편향 검증이 필요하다. A/B는 대안 비교, 카나리는 소규모 실제 트래픽 노출로 회귀 위험을 제한하는 배포 방식이다. 합성 사용자 흐름은 인증 → 검색 → 응답 → 도구의 연결을 검증하지만 실제 사용자 분포를 완전히 대체하지 않는다. 배포 게이트에는 최소 품질·안전·지연·비용과 실패 시 롤백 조건을 명시한다. Model Registry/LLM 평가자/평가자 지표의 의미 및 공식 시험 가이드 영역 5 기반 자체 설계
자체 진단 예제
| 증상 | 먼저 볼 증거 | 적절한 조치·피할 조치 |
|---|---|---|
| 답변 중간이 잘림 | stopReason, maxTokens, stop sequence, 스트림 종료 | 출력 예산·종료 조건 조정. 모델 장애로 단정하지 않음 |
| 오래된 규정 답변 | 원문 버전·동기화 기록·검색 후보·캐시 키 | 데이터·색인·캐시 갱신. 온도만 조정하지 않음 |
| 정답 문서가 있는데 검색 안 됨 | 파싱·청크·임베딩 모델·필터 타입·권한 | 수집·검색 단계부터 수정. 생성 모델만 교체하지 않음 |
| 검색은 맞는데 없는 조항 생성 | 실제 프롬프트·근거 충실도·템플릿 | 근거 사용 지시·검증 개선. 링크만 붙여 해결됐다고 하지 않음 |
| API 4xx | 요청 필드·모델 지원·권한·리전 | 구체 오류 수정. 무한 재시도 금지 |
| 간헐 시간 초과 | 단계별 지연·토큰·도구·할당량 | 한정 재시도·동시성·용량·폴백. 거래 중복 실행 방지 |
| 프롬프트 변경 후 회귀 | 이전·새 템플릿·모델·데이터세트·파라미터 | 한 번에 한 요인을 비교하고 승인 버전 복구 |
공식 작업 5.1의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 5.1.1 | 유창성(fluency), 사실적 정확성(factual accuracy), 관련성(relevance), 충실도(faithfulness)를 각각 평가한다. | 평가 설계·배포 게이트·증상별 진단 /평가자 지표의 의미 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.2 | 동일한 평가 세트(evaluation set)에서 모델·설정별 품질·비용·지연을 비교하고 트래픽을 단계적으로 노출해 검증한다. 구현 시 확인: 카나리 도구별 구현 확인 필요. | 평가 설계·배포 게이트·증상별 진단 /모델 평가와 RAG 평가,LLM 평가자 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.3 | 피드백(feedback)의 맥락·심각도·대표성을 보존하고 주석(annotation) 기준을 통일한다. | 평가 설계·배포 게이트·증상별 진단 /모델 평가와 RAG 평가,LLM 평가자 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.4 | 버전별 회귀 테스트(regression test), 품질·안전 통과 기준(quality/safety gate), 실패 처리 조건을 고정한다. | 평가 설계·배포 게이트·증상별 진단 /Model Registry,평가자 지표의 의미 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.5 | 검색(retrieval)·생성(generation) 평가에 사람 검토와 LLM 평가자(LLM-as-a-judge)를 조합하고 평가자 편향을 점검한다. | 평가 설계·배포 게이트·증상별 진단 /RAG 평가,LLM 평가자 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.6 | 관련 문서 포착률(recall), 후보 순위(ranking), 컨텍스트(context) 일치와 검색 지연을 각각 측정한다. | 평가 설계·배포 게이트·증상별 진단 /검색 필터·리랭킹·질의 분해,RAG 평가 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.7 | 답변의 표현보다 실제 작업 완료(task completion), 올바른 도구(tool) 선택, 효율과 승인(approval) 준수를 평가한다. 구현 시 확인: 에이전트 전용 지표 API 확인 필요. | 에이전트의 행동과 상태를 통제/평가 설계·배포 게이트·증상별 진단 /AgentCore 구성요소와 MCP,도구 실행 책임 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.8 | 평균값뿐 아니라 실패 사례, 점수 분포(distribution), 비용과 업무 영향을 평가 보고서(evaluation report)에 담는다. | 평가 설계·배포 게이트·증상별 진단 /LLM 평가자,평가자 지표의 의미 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.1.9 | 합성 사용자 흐름(synthetic user flow)과 회귀(regression) 데이터로 업데이트를 검증하고 롤백(rollback) 조건을 정한다. | 평가 설계·배포 게이트·증상별 진단 /Converse 요청과 스트림,Model Registry /AIP-C01 영역 5 — 평가·검증·문제 해결 |
공식 작업 5.2의 선택 조건
| 공식 기술 | 판단과 적용 조건 | 연결 해설 |
|---|---|---|
| 5.2.1 | 입력 길이 초과, 출력 한도(output limit), 중지 시퀀스(stop sequence), 스트림(stream) 단절을 구분한다. | 평가 설계·배포 게이트·증상별 진단 /추론 파라미터,Converse 요청과 스트림 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.2.2 | API 응답·오류를 권한(permission), 요청 스키마(schema), 모델 지원과 리전(Region)에 비추어 확인한다. | API·기업 통합·장애 경계/평가 설계·배포 게이트·증상별 진단 /IAM 인증과 인가,Converse 요청과 스트림,Step Functions 오류 처리 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.2.3 | 실패 유형별로 프롬프트 버전(prompt version)을 비교하고 동일한 평가 세트(evaluation set)에서 개선 여부를 확인한다. | 프롬프트·대화·변경 통제/평가 설계·배포 게이트·증상별 진단 /프롬프트 구성과 퓨샷,평가자 지표의 의미 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.2.4 | 색인(index)·임베딩(embedding)·청킹(chunking)·필터(filter)·갱신·드리프트(drift)를 단계별로 조사해 검색 실패 원인을 찾는다. 구현 시 확인: 엔진별 튜닝 확인 필요. | 벡터 저장소·메타데이터·동기화 ·검색 품질/평가 설계·배포 게이트·증상별 진단 /청킹의 설계 절충,검색 필터·리랭킹·질의 분해,Knowledge Bases 동기화 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
| 5.2.5 | 템플릿 변수(template variable), 출력 스키마(output schema), 로그(logs)와 트레이스(traces)를 연결해 응답이 어긋난 원인을 찾는다. 구현 시 확인: X-Ray 전용 세부 확인 필요. | 프롬프트·대화·변경 통제/평가 설계·배포 게이트·증상별 진단 /모델 호출 로깅,Converse 요청과 스트림 /AIP-C01 영역 5 — 평가·검증·문제 해결 |
구성 배포·모델 적응·검색 운영을 더 살펴보기
동적 구성과 Flows의 버전 경계
AppConfig는 모델 ID/라우팅 기준 같은 구성을 코드와 분리해 관리할 수 있는 수단이다. 배포 전 유효성 검사, 점진적 노출, CloudWatch 경보에 따른 롤백을 연결한다. 자체 예시에서 작은 모델의 트래픽 비중을 높일 때 비용은 줄어도 오류가 늘면 승인한 이전 구성으로 되돌린다. 모델 호출 스키마·리전·허용 도구를 확인하는 검증기를 함께 두어야 구성 변경이 보안 경계를 넓히지 않는다. 이는 API를 모두 구현하지 않고도 설명할 수 있는 설계 원리다. AppConfig 구성 배포; 기술 1.2.2/2.3.5/5.1.2
Bedrock Flows는 모델·지식 기반·Lambda 등의 노드 입출력을 연결한다. 앱은 별칭을 호출하며 별칭을 다른 버전으로 돌려 업그레이드·롤백할 수 있다. 자체 문서 심사 예시에서 전처리 노드 출력이 빈 값이면 생성 노드로 보내지 않고 오류로 분기한다. 노코드·시각적 구성이 스키마·권한·실패 검증을 없애는 것은 아니다. Flows 버전과 별칭; 기술 1.6.6/2.5.2/2.5.5
LoRA와 훈련 파라미터
미세 조정(fine-tuning)은 가중치를 바꾸는 과정이다. 학습률(learning rate)은 업데이트 크기, 에포크(epoch)는 데이터 반복 횟수, 배치 크기는 한 번의 학습 처리 단위에 영향을 준다. 입력 길이 한도를 넘는 훈련 예시의 잘림과 검증 데이터 분할을 확인한다. LoRA의 r/alpha/dropout, 8 비트 로딩, 완전 샤딩 데이터 병렬 처리(Fully Sharded Data Parallel, FSDP)는 각각 적응·메모리·분산 훈련과 관계되므로 추론의 temperature/top-p와 섞지 않는다. 작은 학습 집합에 과적합(overfitting)하면 훈련 지표가 좋아져도 업무 성능이 떨어질 수 있다. 새 모델·어댑터는 기존 프롬프트·스키마와 함께 평가하고 레지스트리 승인 후 배포한다. 미세 조정과 하이퍼파라미터/Model Registry; 기술 1.2.4
샤드 계획의 이유
OpenSearch에서 큰 샤드는 장애 복구와 재배치 부담이 커지고, 지나치게 많은 작은 샤드는 각 샤드의 CPU/메모리 오버헤드를 늘린다. 초기 계획은 원본 데이터와 증가분에 인덱싱 오버헤드를 고려해 목표 크기로 나누되, 공식 예시의 숫자를 모든 벡터 인덱스의 최적값으로 외우지 않는다. 복제본·벡터 차원·필터·질의 부하도 운영 자원에 영향을 준다. 기본 샤드 변경이 간단하지 않을 수 있으므로 재인덱싱·버전 교체 전략을 준비한다. OpenSearch 샤드 선택; 기술 1.4.3/4.2.2/4.3.5
평가 보고서의 분모와 의미 유사도
1,000개 프롬프트 중 800개만 응답을 얻었다면 성공 응답 800개의 좋은 점수만 보고 시스템 품질이 좋다고 결론 내리면 안 된다. 오류·미응답 200개의 비율과 유형도 보고한다. 이 수치는 자체 예시다. BERTScore는 문맥 임베딩의 코사인 유사도로 후보와 참조 문장의 단어를 대응시키므로 어휘가 다른 표현도 비교할 수 있지만 중요한 날짜·수치의 사실 검증을 대체하지 못한다. 입력을 의미 보존 방식으로 조금 바꾼 뒤 점수 변화가 큰지 확인하면 견고성을 평가할 수 있다. 자동 평가 보고서 해석; 기술 5.1.1/5.1.8/5.2.3
기술 표 읽는 방법
공식 기술 98개는 영역별로 28·25·15·16·14개다. 각 행은 고유한 판단과 관련 해설을 연결하고, 제품별로 더 확인해야 할 조건이 있으면 함께 적었다. 기술 번호는 시험 가이드의 위치를 찾기 위한 표기이며 교재 내부의 작업 상태가 아니다. 이 표의 설명이 실제 구현 숙련이나 모든 제품의 검증 완료를 뜻하지는 않는다.