AIP-C01 영역 4 — 비용·성능·관찰성 최적화

비용을 낮추고 응답을 빠르게 만들더라도 필요한 정보나 안전 검사를 빼서는 안 된다. 이 장에서는 토큰(token) 예산, 캐시(cache), 처리량(throughput)과 응답 지연(latency)을 실제 업무의 품질과 함께 비교한다. 관찰성(observability)은 지표와 로그, 요청의 처리 경로를 통해 시스템 내부에서 어떤 일이 일어나는지 파악할 수 있는 능력이다. 따라서 비용이 왜 늘었는지, 응답이 어느 단계에서 느려졌는지를 알아내는 데도 필요하다. 계산 예시는 설계 원리를 설명하기 위한 가정이며 특정 모델의 실제 성능이나 가격이 아니다.

4.1 비용 최적화는 품질·안전 하한 안에서 수행한다

근거: 공식 출처 AIP D4. 4.1.1~4의 핵심 조건을 대조한다. 비디오의 고객지원 모델 계층화·야간 배치 예시는 가상 설계이며 실측 절감률이 아니다.

4.1.1 토큰 예산과 정보 보존

입력 예산은 시스템 지침·도구 정의·대화 이력·검색 근거·사용자 질문에 나누고 출력 여유를 확보한다. 토큰은 문자나 단어와 동일하지 않다. 같은 문장도 모델·언어·구조화 필드에 따라 수가 다르며 문자수/4로 한국어 비용을 확정할 수 없다. 입력 토큰 계산의 정확도와 지원 경계의 공식 CountTokens는 지정 모델의 동일 입력 토큰을 계산한다. 아직 생성하지 않은 출력은 정확 예측 대상이 아니며 상한·예상 분포·실제 사용량을 분리한다. runtime과 mantle의 지원 모델·입력·권한·오류 구조도 다르다.

프루닝(pruning)은 모델에 보낼 문맥에서 관련 없는 정보와 중복을 덜어내는 작업이다. 오래된 메시지라고 해서 필수 지침, 승인 내용이나 ‘하면 안 되는’ 조건까지 지워서는 안 된다. 도구 요청과 결과가 서로 대응하는지, 누가 언제 말했는지, 질문에 답하는 데 필요한 예외가 남아 있는지 확인한다. 최근 두 번의 대화만 남겨도 토큰 예산을 넘는다면 그대로 모델에 보내지 않는다. 입력을 나누거나 정해진 기준으로 요약하고, 필요하면 사용자에게 추가 정보를 묻는다. 중요한 정보를 컨텍스트(context) 앞부분에 배치하는 것만으로 모델이 전체 내용을 올바르게 이해한다고 보장할 수는 없다.

재귀 요약(recursive summarization)은 큰 문서를 단계적으로 줄일 수 있지만 각 단계에서 조건·단위·부정이 사라질 위험이 누적된다. 원문 ID와 해당 구간을 유지하고 질문별 정답·근거 평가를 한다. 자체 예: ‘일부 고객만 환불 불가’를 ‘환불 불가’로 줄이면 토큰 절감이 정책 오답이 된다. 예제 구현의 probably 제거·중간 문장 전체 삭제는 의미 보존을 보장하지 않는다. 압축률만 아니라 핵심 조건 보존율·답 품질·재질문 비용을 측정해야 한다.

maxTokens/max_tokens 등의 필드는 API별 계약이고 최대 출력 상한이지 항상 그 길이까지 생성한다는 뜻이 아니다. 상한에 걸린 결과·중지 시퀀스·정상 종료를 나누고 잘린 JSON/코드를 완료 결과로 사용하지 않는다. 온도 감소는 정확성 검사가 아니다. 추론 파라미터, Converse 요청과 스트림를 재사용한다.

4.1.2 가격표보다 성공한 업무당 총비용

비교 후보는 언어·모달리티·데이터 위치·권한·안전·품질의 필수 조건을 먼저 통과해야 한다. 이후 같은 대표 평가 세트에서 입력·출력 토큰, 검색·필터·라우터·재시도·검토 비용, 지연과 업무 성공을 비교한다. 저렴한 모델이 자주 실패해 비싼 모델을 다시 호출하면 처음부터 적절한 모델을 쓰는 것보다 비쌀 수 있다.

모델 캐스케이드(model cascade)는 먼저 한 모델을 호출하고, 결과가 기준을 충족하지 못하면 더 큰 모델로 요청을 넘기는 방식이다. 순차 호출을 가정한 이 교재의 평균 비용식은 ‘첫 모델 비용 C1 + 상위 모델 호출 확률 p × C2 + 라우팅·검사 비용’이다. 지연 시간에도 첫 호출과 재호출에 걸린 시간이 누적된다. 상위 모델로 넘길지는 모델의 자신감 표현만으로 정하지 않는다. 결과의 품질, 출력 형식, 근거와 위험 수준을 평가해 전환 기준을 정해야 한다. 장애 때 다른 모델로 대체하는 폴백(fallback)도 필수 정책과 지원 기능을 충족해야 하며, 단지 더 저렴하다는 이유로 기준을 낮춰서는 안 된다.

질의가 짧아도 고위험일 수 있고 영어 키워드가 없다고 쉬운 질문은 아니다. 자체 라우터와 Amazon Bedrock Intelligent Prompt Routing을 구별한다. 지능형 모델 라우팅의 관리형 기능은 같은 패밀리 지원 모델·영어 최적화·앱별 실적 자동 적응 불가 등 확인 당시 조건이 있다. 일반 계층 라우터 설명을 모든 모델 간 관리형 라우팅 지원으로 확대하지 않는다.

성공한 업무당 비용 = 실패·재시도를 포함한 총비용 / 품질·안전·업무 조건을 충족한 건수로 정의할 수 있다(자체 지표). ‘추가 질문을 안 했다’는 성공의 충분조건이 아니다. 사용자 이탈·오답·결측이 있을 수 있고 적절한 명확화 질문은 품질 개선이다. 유형별 비용은 그 유형의 비용과 성공 수를 사용해야 한다. 가격·리전·모델 버전·할인 단위를 기록하고 과거 강좌의 고정 가격을 현재 견적으로 쓰지 않는다.

4.1.3 처리량·이용률·대기시간의 교환

처리량(throughput)은 단위 시간에 완료하는 요청 수나 처리하는 토큰 수이며, 동시성(concurrency)은 같은 시점에 처리 중인 작업 수다. 요청마다 길이가 다르면 요청 수가 같아도 필요한 계산량은 달라진다. 따라서 용량은 요청 도착률(arrival rate), 입력과 출력 길이의 분포, 요청이 한꺼번에 몰리는 버스트(burst), 허용 대기시간을 기준으로 계획한다. 이용률(utilization)을 높이면 자원 낭비를 줄일 수 있지만, 자원이 포화에 가까워지면 대기열이 길어지고 일부 요청이 매우 늦게 끝나는 꼬리 지연(tail latency)이 커질 수 있다.

배치는 실시간 응답이 필요 없는 업무에 적합하다. 야간 제품 설명 생성도 완료 시한·오류 재처리·부분 성공·중복 방지·데이터 최신성을 관리해야 한다. SQS는 부하를 흡수하지만 모델 처리 용량을 늘리지는 않는다. 메시지 만료·재시도·실패 메시지 대기열(dead-letter queue, DLQ)·멱등성을 설계하고 큐 깊이와 오래된 메시지 나이를 함께 본다.

Lambda 앱 동시성과 Bedrock 모델 처리량, SageMaker 호스팅 용량은 서로 다른 자원이다. Lambda를 늘려도 모델 할당량에서 throttling이 증가할 수 있다. 프로비저닝 용량은 유휴 비용·약정·지원 모델을 고려하고, 온디맨드·교차 리전 경로의 지원 차이를 확인한다. 교차 리전 추론은 교차 리전 추론 프로파일의 프로비저닝된 처리량(Provisioned Throughput) 미지원 조건을 보존한다. 템플릿 작성은 용량이 적절하다는 실험 증거가 아니다. 대규모 모델 호스팅의 다운로드·초기화·추론 지연도 분리한다.

4.1.4 캐시는 재사용 대상·권한·무효화가 핵심

요청 해시는 동일 입력을 식별하는 수단이다. 임의 공백 정리나 소문자화로 서로 다른 의미를 합치지 않고 직렬화 규칙을 고정한다. 시맨틱 유사도 임계값은 사실일 확률이 아니므로 재사용 가능 조건을 별도로 검사한다. 자체 예: ‘A 고객 잔액’과 ‘B 고객 잔액’은 표현이 닮아도 공유해서는 안 된다. 권한 회수·문서 삭제·정책 변경은 TTL 이전에도 캐시 무효화가 필요할 수 있다.

프롬프트 캐싱의 조건의 프롬프트 캐시는 완성 답을 반환하는 응답 캐시가 아니다. 호출은 남고 반복 접두사 처리 비용·지연을 줄인다. 캐시 쓰기 비용이 일반 입력보다 높을 수 있어 적중 횟수·쓰기·만료를 함께 계산한다. 온디맨드 지원과 배치 추론 API 미지원, 모델별 TTL/최소 토큰의 차이를 유지한다. inputTokens와 cacheRead/WriteInputTokens의 합산 조건도 API별로 확인한다. 적중률을 높이기 위해 오래되거나 권한 없는 답을 재사용하지 않는다.

예제 구현의 주의점 및 충분성 경계

예제 코드가 끝까지 제공돼 있어도 아키텍처 그림의 캐시·라우터가 모두 구현된 것은 아니다. 문자 근사, 시스템 지침이 빠질 수 있는 프루닝 조기 반환, 상한 초과 최근 턴, 역순 문맥, 확률 표현 삭제·중간조건 누락을 주의한다. 비용 추정의 예상 출력이 모델 컨텍스트 상한으로 채워진 점은 견적을 왜곡한다. 유형별 분석에 전체 비용·성공률을 사용하는 계산, 성공률 0 나눗셈, 결측 명확화 플래그를 성공으로 처리하는 로직도 검증해야 한다.

모델 선택·프루닝·캐시·용량의 원리와 조건은 설명했지만 제품별 자동 스케일링 API·CloudFront 정책·캐시 구현·부하 실측은 잔여다.

4.2 애플리케이션 성능 — 병목·품질·부하를 같은 조건으로 비교

근거: 공식 출처 AIP D4, SageMaker 호스팅 모델 오토 스케일링의 제어 대상. 여섯 기술을 아래에 구분한다. 수치 사례는 자체 설명이며 강좌 가상 금융시장의 실제 성능을 주장하지 않는다.

4.2.1 첫 토큰 생성, 사용자에게 표시, 전체 완료까지의 시간을 구분한다

사용자가 요청한 뒤 결과를 모두 받기까지는 대기열 처리, 검색, 모델 준비와 추론, 도구 실행, 안전 검사, 네트워크 전송과 화면 표시가 필요하다. 스트리밍(streaming)을 사용하면 전체 생성이 끝나기 전에 일부 응답을 보여줄 수 있지만, 모델의 계산 시간 자체가 반드시 줄어드는 것은 아니다. 첫 토큰까지의 시간(time to first token, TTFT)과 안전 검사를 마친 내용을 사용자에게 처음 표시하기까지의 시간은 따로 측정한다. 개인정보가 든 조각을 먼저 보낸 뒤 취소해도 이미 노출된 정보는 회수할 수 없기 때문이다. 전체 응답 완료 시간도 측정하며, 중앙값인 p50뿐 아니라 느린 요청을 보여 주는 p95와 p99, 오류율과 완료율을 함께 본다. 실패한 요청을 통계에서 제외해 응답 속도가 좋아진 것처럼 보이게 해서는 안 된다.

독립 작업은 병렬화하면 이상적으로 가장 긴 경로에 가까워질 수 있지만 의존 작업을 무작정 동시에 시작해서는 안 된다. 동시 호출은 토큰 할당량·연결 풀·하위 API·비용을 함께 소모하므로 최대 동시성과 전체 시간 예산을 둔다. 중간 실패 시 취소·부분 응답·재시도 조건과 중복 부작용을 관리한다. AWS Step Functions는 조정 수단이지 무제한 병렬 용량 보장이 아니다.

사전 계산은 반복 가능한 질문에 효과적이지만 문서·정책·권한 변화 때 갱신해야 한다. DynamoDB/DAX와 ElastiCache는 접근 패턴·일관성·자료 수명·운영비가 다르다. 서비스의 sub-ms 설명이나 예제 모델 0.5/1.2/2.5초를 전체 앱 서비스 수준 목표(service level objective, SLO)로 복제하지 않는다. Converse 요청과 스트림, 프롬프트 캐싱의 조건 참조.

4.2.2 검색은 빨리 찾는 것과 올바르게 찾는 것을 함께 본다

계층형 탐색 그래프(Hierarchical Navigable Small World, HNSW)는 그래프 기반 근사 최근접 검색, 역파일 인덱스(inverted file index, IVF)는 벡터(vector) 공간을 구획해 탐색 범위를 줄이는 계열이다. 탐색 후보를 늘리면 재현율(Recall)이 좋아질 수 있지만 지연·메모리·인덱스 구축 비용이 늘어난다. m/ef_construction 같은 구축 파라미터와 검색 시 탐색량을 구분하고 엔진·버전별 지원을 확인한다. 임베딩(embedding) 모델·차원·거리 함수·정규화가 서로 맞아야 하며 모델 변경은 재색인이 필요할 수 있다.

키워드 검색은 제품 코드·정확한 명칭, 시맨틱 검색은 의미 표현을 보완한다. 하이브리드 점수는 서로 다른 척도의 점수를 무조건 더하지 않고 정규화·결합 방식을 평가한다. 최신성 점수를 높여도 오래된 유효 계약을 잘못 배제할 수 있다. 권한 필터는 품질 튜닝보다 먼저 적용하며 권한 없는 후보를 모델에 전달한 뒤 출력에서 숨기는 것으로 대체하지 않는다.

전처리·질의 확장은 오탈자와 표현 차이를 줄일 수 있지만 부정·버전·숫자·코드 기호를 없애면 의도를 바꾼다. 원본 질의와 변환본을 추적하고 필요한 경우 정확 일치 경로를 보존한다. 검색 지연과 Recall@k·순위·정답 근거 포함률을 함께 측정한다. 인덱스 계층은 일반·상세 분리의 앱 설계이고 모든 제품의 자동 계층 인덱스 기능이 아니다. 청킹의 설계 절충, 검색 필터·리랭킹·질의 분해, Knowledge Bases 동기화의 기존 조건을 재사용한다.

4.2.3 처리량: 요청 수와 토큰 부하의 상한을 함께 관리

입력과 출력의 길이 분포가 달라지면 동일 초당 요청 수(requests per second, RPS)에서도 처리량이 달라진다. 큐·세마포어·토큰 예산으로 하위 서비스 용량 안에 요청을 유지한다. 속도 제한기(rate limiter)는 요청 도착률을 제한하고, 동시성 제한기(concurrency limiter)는 같은 시점에 진행 중인 요청 수를 제한한다. 고정 sleep 하나는 여러 워커의 합산 부하를 제어하지 못한다. 재시도는 재시도 가능한 오류에 한정하고 지수 백오프·지터·최대 횟수·전체 기한을 둔다.

배치는 비대화형 작업에 적합하며 대화형 긴급 요청과 분리하면 지연 간섭을 줄일 수 있다. 우선순위는 업무 중요도와 기한을 반영하되 낮은 우선순위가 영원히 굶지 않도록 관리한다. SQS는 과부하를 완화하지만 큐 용량·메시지 수명·처리 기한 때문에 무한히 요청 거절을 없애지는 못한다. Step Functions 오류 처리, CountTokens를 연결한다.

4.2.4 모델 설정: 같은 평가 세트에서 유효한 파라미터만 비교

온도(temperature)·top-k·top-p는 샘플링(sampling) 분포를 조절한다. 출력 상한(maximum output tokens)과 중지 시퀀스(stop sequence)는 응답을 언제 끝낼지 제어한다. 낮은 온도는 사실 정답이나 실행 결정성을 보장하지 않는다. 모델이 지원하지 않는 필드를 공통 어댑터가 그대로 전달하면 오류가 나거나 의도와 다른 동작이 될 수 있다. 모델·프롬프트·검색·정책 버전을 고정한 뒤 대표·경계·안전 사례로 비교한다.

A/B 테스트에서는 사용자·요청 배정과 데이터 분포를 통제하고 동일 기간·부하·성공 기준으로 평가한다. p95 지연을 달러로 나눈 값 하나는 비용이 증가하면 오히려 낮아지는 등 해석 문제가 생길 수 있다. 지연 SLO와 비용 예산을 별도 제약으로 두고 품질·비용·지연의 Pareto 비교를 사용한다.

교육 자료에 등장하는 CloudWatch Evidently의 현재 이용 가능성은 이 교재에서 확인하지 않았다. A/B 테스트의 원리와 특정 제품의 도입 가능성을 분리한다. 비교에는 무작위 배정, 충분한 표본, 동일 평가 기준과 안전한 중지 조건이 필요하다. 추론 파라미터와 함께 설정 변경의 영향을 평가한다.

4.2.5 자원 할당: 관리형 endpoint와 EC2 자가 호스팅을 구분

강좌 관련 항목에는 SageMaker 추론 엔드포인트와 로드밸런서 뒤 EC2 오토 스케일링 그룹(Auto Scaling group, ASG)를 함께 설명하는 부분이 있다. SageMaker 호스팅 모델 오토 스케일링의 제어 대상의 현행 공식 한국어는 SageMaker 프로덕션 변형에 Application Auto Scaling의 대상 추적·단계·예약 정책을 적용하는 경로를 설명한다. EC2에 직접 모델 서버를 호스팅하는 ASG 아키텍처와 동일하지 않다. Bedrock 프로비저닝된 처리량과 교차 리전 프로파일도 지원 경로가 다르며 한 설정으로 묶지 않는다.

토큰 부하·콜드 스타트·모델 로딩 시간·최소·최대 용량·휴지기간·예상 시장 개장 같은 버스트를 고려한다. 예측 가능한 시각에는 사전 용량 확보가 도움이 되지만 예측 실패의 유휴 비용을 계산한다. 인스턴스를 요청한 상태와 실제 준비·SLO 회복을 분리한다. 정책 개요의 300 초/70 호출은 기본·예시 문맥이며 모든 모델 권장값이 아니다. 0 인스턴스는 별도 지원 조건이 있으므로 보편화하지 않는다.

4.2.6 전체 경로 프로파일링과 예제 구현의 주의점

동일 요청 ID로 게이트웨이·검색·추론·검사·도구·저장을 연결하면 병목이 모델인지 검색인지 확인할 수 있다. 각 서비스 p95의 합은 전체 p95 와 일반적으로 같지 않다. 같은 조건의 전후 측정에서 비용·오류·품질도 함께 비교하고, 개인정보 원문 대신 필요한 메타데이터를 우선 계측한다. X-Ray/CloudWatch는 실제 계측이 있어야 자료가 생긴다.

예제 구현의 async 함수 안에서 future.result()를 즉시 호출하는 방식은 이벤트 루프를 차단할 수 있어 asyncio.gather가 있다고 진짜 병렬 성능을 보장하지 않는다. 단계별 소요시간의 합은 실제 직렬 실행을 측정한 결과가 아니며, 중복 step_id는 결과를 덮어쓸 수 있다. 모델별 스트림을 content0 하나로 처리하는 가정과 오류문자열을 일반 청크로 내보내는 로직도 수정 검증이 필요하다.

캐시키에 질의만 있으면 테넌트·권한·모델·프롬프트·근거 버전이 섞인다. ISO 만료시각을 앱이 검사하는 것과 DynamoDB TTL로 물리 삭제하는 것은 다르다. 영문 NLTK 전처리는 한국어 지원을 보장하지 않고 부정어·기호 제거로 의미를 바꿀 수 있다. 마지막 동의어 함수는 docstring 중간에서 끝나므로 실행 가능한 완성본이 아니다.

4.3 관찰성 — 수집된 데이터가 어떤 판단을 뒷받침하는가

근거: 공식 출처 AIP D4. 도메인 소개는 4.3을 두 항목으로 압축했지만 실제 태스크 개요·기술은 6개를 제시한다. 아래 여섯 기술을 모두 분리해 대조한다. 원문 순차 대체본이 아니라 설계 판단 설명이다.

4.3.1 전체 관측: 지표·로그·트레이스·업무 결과 연결

지표(metrics)는 호출 수나 지연 시간처럼 시간에 따른 수치 변화를 보여 준다. 로그(logs)는 오류 메시지와 처리 결과 등 개별 사건의 내용을 기록하며, 트레이스(traces)는 한 요청이 여러 서비스를 거치는 경로와 단계별 소요 시간을 연결한다. 이 세 정보를 함께 사용해 시스템 내부 상태와 문제 원인을 파악하는 것이 관찰성(observability)의 핵심이다. 같은 요청 ID에 모델, 프롬프트, 검색 인덱스와 정책의 버전을 연결하면 어느 단계가 느려졌는지, 어떤 변경 뒤 품질이 달라졌는지 조사할 수 있다. 사용자 경험에는 처음 응답을 보는 시간뿐 아니라 전체 완료, 취소, 오류 처리와 접근성(accessibility)도 포함된다. 모델의 추론 시간만으로 전체 경험을 평가해서는 안 된다.

Amazon Bedrock AgentCore와 Amazon CloudWatch에서 통합 화면을 사용하려면 프레임워크의 계측(instrumentation), 지원 버전과 데이터 수집 경로를 맞춰야 한다. 대시보드가 보인다고 모든 구성 요소의 데이터가 수집되는 것은 아니다. 일부 요청만 수집하는 샘플링(sampling), 누락, 시스템 간 시계 차이, 비동기 작업에서 부모 요청과 자식 작업의 연결을 확인한다. 프레임워크를 연동할 때는 정확한 제품명과 해당 버전의 API를 확인한다. 관찰성 — 지표·감사·호출 로그의 차이와 AgentCore 구성요소와 MCP에서 수집 범위를 비교한다.

4.3.2 토큰·품질·비용 이상은 다른 신호

토큰 급증은 긴 문서·재시도·루프·정상 수요 증가·공격 등 여러 원인이 있다. 모델·작업·기간·입출력 토큰을 나누고 요청량 대비 값을 함께 본다. 입력 토큰이 0개일 때 출력/입력 토큰 비율은 정의되지 않으므로 0으로 채워 정상 처리하지 않는다. 프롬프트 캐시 토큰의 집계 계약도 포함한다. Cost Explorer/Budgets의 청구 관찰과 요청 단위 추정은 시점·단위가 달라 즉시 차단의 유일한 근거로 쓰지 않는다.

할루시네이션(hallucination)률은 CloudWatch를 켜면 저절로 생기는 기본 사실 판정값이 아니다. 검증된 골든 데이터세트·근거·사람 또는 교정된 평가자, 실패 분류와 분모가 필요하다. 문장이 유창해도 거짓일 수 있고, 문구가 달라도 정답일 수 있다. 관련성(Relevance)·충실도(Faithfulness)·완전성(Completeness)·정확성·유해성을 분리하고 평가 불능·미검사도 보고한다. 평가자 지표의 의미, LLM 평가자, 모델 호출 로깅를 재사용한다.

4.3.3 통합 보고: 운영·사업·준수의 독자와 권한

운영자는 오류·지연·용량·큐, 사업 담당자는 해결률·전환·만족도·처리 시간, 준수 담당자는 승인·접근·정책 위반·감사 누락을 본다. 같은 요청을 연결하되 모든 독자에게 원문 대화를 공개하지 않는다. CloudTrail의 API 활동과 앱 결정 로그·모델 호출 로그·RUM 사용자 경험 수집은 범위와 설정이 다르다. RUM/피드백에는 개인정보 최소화와 수집 목적·보존을 적용한다.

만족도는 응답한 사람의 편향이 있을 수 있고, 클릭·참여 증가는 업무 해결이 아닐 수 있다. 자체 예로 긴 대화를 유도하면 참여시간은 늘지만 해결시간이 나빠질 수 있다. 지표 소유자·산식·관측 기간·분모·변경 이력을 관리한다. 평균뿐 아니라 세그먼트별 실패와 미해결 사안을 보고하고 상관관계를 인과 효과로 단정하지 않는다. 근거는 강좌의 설명과 관찰성 — 지표·감사·호출 로그의 차이이다.

4.3.4 도구와 다중 에이전트는 실제 실행 결과로 평가

도구 선택, 인수 생성, 인가(authorization)·승인, 실제 호출, 반환 스키마, 업무 상태 반영을 각각 기록한다. HTTP 200과 업무 성공은 다르고, 도구를 호출했다고 올바른 도구를 골랐다는 뜻도 아니다. 도구별 성공률·p95 지연·취소·재시도·불필요 호출·중복 부작용·승인 준수를 측정한다. 에이전트 간 인계(handoff)에서는 누가 작업을 맡는지, 어떤 문맥(context)을 전달하는지, 누가 최종 결과를 확정하는지 명시한다.

다중 에이전트가 서로 같은 작업을 반복하거나 오류를 성공으로 전달하면 비용이 증가하고 감사가 어려워진다. parent/child 실행 ID, 반복·토큰·시간 예산, 종료 조건, 상태 확인을 둔다. 이상 기준은 도구·업무별로 설정하고 정상 급증과 오용을 구별한다. AgentCore 구성요소와 MCP, 도구 실행 책임, Step Functions 오류 처리 참조. 본 자료 작업에서 에이전트나 도구 부하실험을 실행한 것은 아니다.

4.3.5 벡터 저장소는 검색 속도 외에 수집·삭제·품질을 감시

쿼리 지연·처리량·오류와 함께 문서 동기화 지연·실패 문서·삭제 미반영·인덱스 크기·자원 포화·검색 관련성을 본다. 인덱스가 건강해도 원문이 오래됐으면 잘못된 답이 나올 수 있다. 청킹(chunking)·임베딩·메타데이터·권한 필터 버전과 실제 인제스트 완료를 연결한다. Glue/Data Wrangler의 입력 품질 검사는 정의한 규칙을 검사하는 것이지 문서 사실 전체의 진위를 검증하지 않는다.

자동 인덱스 최적화는 근거 없이 재색인·샤드 변경을 반복하는 작업이 아니다. 백업·복원 테스트·롤백·호환성·피크 부하를 고려하고 사용자 승인 범위 안에서 변경한다. 삭제된 원문이 복원 시 다시 나타나지 않도록 최신 삭제·권한 정책을 함께 적용한다. Knowledge Bases 동기화, 검색 필터·리랭킹·질의 분해, Glue Data Quality 참조. 엔진별 자동 최적화 API는 잔여다.

4.3.6 GenAI 실패를 재현 가능한 회귀 사례로 전환

골든 데이터세트(golden dataset)에는 질문, 기준 시점, 정답, 허용 범위, 근거, 난이도, 위험과 평가 버전(evaluation version)을 기록한다. 답이 달라졌다는 이유만으로 실패는 아니며 새로운 사실이나 의도 차이일 수 있다. 동일 의미 질문 변형과 실제 다른 조건을 구별하고 부정·수치·관할·시간 변화에 대한 테스트를 한다. 시맨틱 유사도는 두 답이 사실상 동등하다는 증명이 아니다.

논리 검증은 계산·형식 규칙·근거 함의를 분리한다. 생성된 CoT를 내부 계산의 사실 기록으로 보지 않고 공개 가능한 근거 요약·도구 실행 경로·계산 결과로 검증한다. 기호 검사도 전제와 적용 범위가 맞아야 유효하다. 실패를 환각·검색 누락·문맥 손실·스키마·도구·정책·운영 오류로 분류한 뒤 심각도·빈도·영향에 따라 수정하고 동일 사례와 정상 회귀를 재평가한다. RAG 평가, LLM 평가자, 평가자 지표의 의미를 연결한다.

예제 구현의 주의점: 모니터링 자체의 비용·누락·개인정보

RequestId/ConversationId를 모든 지표의 차원으로 넣으면 고유 시계열 수와 비용이 급증한다. 개별 ID는 제한된 로그/trace에, 지표는 안정된 집계 차원에 두는 설계를 검토한다. 오류 때만 1을 발행하면 무오류 0·데이터누락을 구분해야 하며 오류율의 전체 요청 분모가 필요하다. 임의 메타데이터를 차원으로 복제하지 않는다.

프롬프트·응답 첫 500 자만 기록해도 개인정보는 남을 수 있다. 길이 절단은 익명화가 아니며 로그·trace의 권한·암호화·보존을 설정한다. time.sleep 시뮬레이션과 0.85/120/1200.5 예제값은 실측이 아니다. 단어수는 모델 토큰수가 아니다. X-Ray 루트 컨텍스트·중복 capture·SDK 지원도 검증해야 한다.

메모리의 최근 100건은 프로세스 재시작·분산 워커·긴 계절성을 대표하지 못한다. 현재 값을 평균에 먼저 넣으면 이상치가 기준을 움직이고,2 표준편차 기준은 모든 분포에서 같은 오탐률을 보장하지 않는다. 마지막 통계 함수는 total_tokens=history에서 끝나 반환값이 없어 코드 자체 미완이다.

상황형 자기점검

다음 문항은 이 교재에서 직접 만든 학습 문제다. AWS 공식 문제·실제 기출·시험 복원 문제가 아니며 합격을 보장하지 않는다. 각 문항은 제시된 조건에서 가장 적절한 답 하나를 고른다. 정답을 보기 전에 다른 선택지가 요구 조건을 충족하지 못하는 이유도 설명해 보자.

1. 승격이 잦은 저가 모델

자체 비용 가정으로 작은 모델 호출은 1단위, 큰 모델은 5단위다. 작은 모델을 먼저 부른 요청의 80%가 큰 모델로 승격되고, 검사에는 요청당 0.5단위가 든다. 큰 모델을 바로 호출하는 5단위 경로와 비교하면?

• A. 80%를 성공률로 보고 승격 비용을 뺀다
• B. 캐스케이드는 평균 5.5단위로 더 비싸며 품질·지연까지 함께 비교해야 한다
• C. 작은 모델은 1단위이므로 전체도 1단위다
• D. 두 모델 비용을 평균 내어 항상 3단위다

2. 높은 GPU 이용률과 긴 대기

모델 서버의 GPU 이용률은 높지만 대화 요청의 p95 완료 시간이 악화됐다. 긴 배치 작업과 실시간 요청이 같은 대기열을 쓴다. 먼저 검토할 개선은?

• A. 평균 지연만 보고 p95를 없앤다
• B. 필수 안전 검사를 제거해 빠르게 만든다
• C. 업무별 대기열·우선순위·동시성·배치 대기 한도를 조정하고 품질과 지연을 함께 측정한다
• D. GPU 이용률만 최대화하면 사용자 SLO도 자동 달성된다

3. 토큰 급증의 원인

월요일 토큰 비용이 급증했다. 요청 수 증가는 작았고 모델 호출이 같은 요청 ID 아래 반복된다. 원인 분석에 가장 유용한 것은?

• A. CloudWatch를 켰으므로 환각률도 자동으로 정확히 측정됐다고 본다
• B. 청구 총액만으로 어떤 도구가 반복됐는지 확정한다
• C. 원인 확인 없이 모든 요청의 권한을 확대한다
• D. 요청별 추적에서 도구 실패·재시도·에이전트 반복·입출력 토큰·버전을 연결한다

전체 학습 목표와 영역별 자기점검

용어 확인: 처리량(throughput).