AIP-C01 영역 1 — 모델 통합·데이터·검색·프롬프트 설계

요구사항에서 모델 선택, 데이터 준비, 검색과 프롬프트 관리까지 하나의 요청 경로를 설계한다. 각 단계에서 입력·출력뿐 아니라 권한, 버전, 실패와 복구 조건을 정하는 것이 핵심이다. 기술별 설계 비교는 공식 기술 번호별로 이 장의 판단을 찾아볼 수 있게 연결한다.

1.1 요구사항을 실행 가능한 계약으로 바꾸기

먼저 시스템이 어떤 입력을 받아 어떤 결과를 내야 하는지 정한다. 이어서 데이터를 저장·처리할 수 있는 범위, 허용 응답 시간, 필요한 처리량(throughput), 품질 기준, 오류가 초래할 피해, 비용 한도, 사람의 승인이 필요한 작업, 업데이트 주기를 구체화한다. 시스템이 해야 할 일을 나타내는 기능 요구사항(functional requirements)과 성능·보안 같은 비기능 요구사항(non-functional requirements)을 나누고, 각 요구사항을 어떻게 검증할지 정해야 한다. 예를 들어 제조업 유지보수 문서 도우미라면 관련 설명을 생성하는지만 보면 안 된다. 올바른 문서 버전과 장비 모델을 사용했는지, 접근 권한을 지켰는지, 금지된 안전 지침을 생성하지 않았는지, 제한 시간 안에 응답했는지도 검증한다.

호출·검색·워크플로의 경계

동기식 호출(synchronous call)은 요청한 쪽이 결과를 기다리는 방식이다. 즉시 결과가 필요한 경우 이해하기 쉽지만, 작업이 길어지거나 부하가 급증하면 시간 초과(timeout)가 발생하고 호출한 시스템도 함께 지연될 수 있다. Amazon SQS는 작업을 대기열(queue)에 저장해 작업을 넣는 생산자(producer)와 처리하는 소비자(consumer)를 분리한다. Amazon EventBridge는 이벤트(event)를 규칙에 맞는 대상으로 전달한다. Kafka 계열은 이벤트 스트림(stream)을 저장하고 소비자가 읽어 처리하는 방식으로 이해할 수 있다. 전달 보장, 순서, 재시도(retry), 중복 처리 조건은 시스템마다 다르다. 대기열에 작업을 넣었다고 실제 처리가 성공한 것은 아니다.

AWS Step Functions 같은 오케스트레이션은 상태·분기·재시도·사람 대기·실패 경로를 명시하는 데 도움이 된다. 단순 API도 올바르게 설계하면 확장할 수 있으므로 ‘동기식은 항상 운영 불가’라고 외우지 않는다. AppSync의 GraphQL은 클라이언트가 필요한 데이터를 선택하는 API 계약을 구성하는 선택지이며, 인증·인가(authorization)·구독·캐싱의 구체 조건은 지원 API에 맞춰 확인한다. 검색 증강 생성(Retrieval Augmented Generation, RAG)은 근거를 찾는 역할이고 워크플로는 여러 작업의 상태를 관리하는 역할이다.

자체 인터페이스 예:

요청: request_id, tenant_id, 장비코드, 질문, 허용문서범위
검색결과: document_id, version, chunk_id, 본문, 권한검증결과
생성결과: 답변, 근거목록, 불확실성, 사람검토필요여부
작업상태: accepted / running / needs_review / succeeded / failed / unknown

이 예는 특정 AWS API 스키마가 아니라 앱의 자체 계약이다. 재시도 시 request_id로 이미 실행한 작업인지 확인하고, 정보 조회와 실제 작업 지시 발행을 분리한다. 불명 상태를 성공으로 바꾸지 않는다.

PoC는 축소된 검증 실험

개념 증명(proof of concept, PoC)은 전체 운영 시스템(production system)을 만들기 전에 핵심 위험과 가능성을 작은 범위에서 확인하는 실험이다. 검증할 모델, 언어, 문서 유형을 정하고 정상 입력뿐 아니라 경계 사례(edge case)와 악성 입력도 포함한다. 동일한 데이터로 후보 모델의 품질, 지연 시간, 토큰(token) 사용량, 오류율, 사람의 검토 비용을 비교한다. 쉬운 예시 2~3개는 연결이 작동하는지 확인하는 데는 도움이 되지만 전체 업무 성능을 보장하기에는 부족하다. 데이터가 적으면 결과의 불확실성과 아직 시험하지 않은 경우를 명시해야 한다.

문서 근거가 중요한 경우 Knowledge Bases로 관리형 검색을 시작할 수 있지만 색인 갱신·원문 권한·삭제·검색 실패를 검증해야 한다. 프롬프트와 모델 버전을 함께 기록하고, Flows/Agents를 사용해도 각 단계의 스키마와 실패 처리를 정의한다. 샘플 코드에서 JSON 형식으로 답하라는 지시만 있다고 검증된 JSON 객체를 얻은 것은 아니다. 파싱·필수 키·타입·근거 대조 후 다음 단계로 넘긴다.

표준화와 출시 판정

재사용할 구성요소는 인증(authentication)·인가, 모델 호출 어댑터, 프롬프트 버전 관리, 입력·출력 검증, 로그 마스킹, 재시도·시간 초과, 비용 계측, 평가·승인이다. 코드형 인프라(infrastructure as code, IaC)는 재현 가능한 배포를 돕지만 잘못된 권한도 일관되게 복제할 수 있으므로 변경 검토와 테스트가 필요하다. Well-Architected Framework/생성형 AI(generative AI, GenAI) Lens는 검토 질문과 개선 과제를 체계화하는 근거이지 자동 준수 인증이 아니다.

모니터링은 요청당 입력·출력 토큰, 성공률, 지연 분포, 검색 실패, 검토율, 테넌트별 비용을 관찰한다. 내용 로그는 개인정보를 포함할 수 있어 최소화·보존·접근 통제를 정한다. 응답 캐시는 문서 버전·권한·사용자 문맥을 키에 반영하고, 고정 30일처럼 근거 없는 보존 기간을 적용하지 않는다. 프롬프트 캐싱(prompt caching)과 응답 캐싱은 서로 다른 기능이다.

실제 강좌와 대조하면서 남긴 주의

• 강좌 관련 항목은 가정된 다국어 금융회사 예제다. 성능·비용·만족도 숫자를 실제 고객 사례나 달성 가능한 보장으로 복제하지 않는다.
• 교육 예제의 ‘회사 네트워크 경계 안, 외부 서비스 전송 금지’와 해설의 ‘Amazon Bedrock 사설 엔드포인트’는 경계 정의가 모호하다.

퍼블릭 인터넷을 거치지 않는 것과 고객 가상 프라이빗 클라우드(Amazon Virtual Private Cloud, VPC) 밖의 관리형 서비스가 데이터를 처리하지 않는 것은 다르다. 보안팀과 실제 데이터 처리 경계를 먼저 명세한다.

• 미세 조정(fine-tuning)이면 반드시 데이터가 공개되고 RAG라면 자동으로 프라이버시가 보장된다는 이분법은 잘못이다. 각 서비스의 계약·저장·훈련 사용·접근 통제를 확인한다.
• 보너스 코드의 구형 모델 ID/요청형식, 텍스트파일 가정, JSON 검증 부재, 비교코드의 시간측정 의존성 등을 그대로 현재 프로덕션 코드로 사용하지 않는다. 예제의 실제 실행 가능성은 별도 테스트로 확인해야 한다.
• 멀티리전 트래픽 라우팅만으로 데이터 레지던시가 자동 유지되는 것은 아니다. 허용 리전, 저장·로그·캐시, 검색·모델 호출의 위치를 함께 제약한다.

근거: AIP 영역 1 출처/예제 구현의 Converse 요청과 스트림, Step Functions 오류 처리, 평가자 지표의 의미, 프롬프트 캐싱의 조건, 모델 호출 로깅, IAM 인증과 인가, Flows 버전과 별칭. AppSync/GenAI Lens/MLflow 전용 공식 한국어 본문 깊이는 추가 확인할 잔여다.

1.2 모델 변경을 안전한 운영 변경으로 다루기

평가 계약과 선택

모델 선정표에는 업무별 품질, 입력 언어·문서 형식, 컨텍스트·출력 한도, 지연 분포, 처리량, 실패율, 토큰·운영비용, 안전성과 이용조건을 넣는다. 평균값 한 개로 합치기 전에 반드시 충족할 조건을 먼저 거른다. 치명적인 개인정보 노출을 낮은 가격 점수로 상쇄하지 않는다. 견고성 지표가 ‘변형에 따른 변화량’이면 낮을수록 좋을 수 있으므로 지표 이름만 보고 최대화하지 않는다. 교육 예제의 8.5% 같은 숫자는 해당 비교예시이지 모든 프로덕션의 합격선이 아니다.

라우터와 어댑터

앱의 업무 코드는 공통으로 정한 요청·응답 형식을 사용하고, 어댑터(adapter)가 이를 모델 공급자별 API 형식으로 변환하도록 설계할 수 있다. 어댑터는 입력 자료형, 파라미터와 오류 처리의 차이도 다룬다. 라우터(router)는 먼저 허용된 모델·리전·기능을 확인한 뒤 업무 품질과 비용 조건에 맞는 후보를 선택한다. AWS AppConfig는 설정을 코드와 분리해 관리하고 검증, 점진적 배포, 롤백(rollback)을 수행하도록 돕는다. 다만 새 모델이 기존 어댑터와 호환되지 않으면 설정만 바꿔서는 사용할 수 없다. 코드와 스키마(schema)도 수정하고 검증해야 한다.

자체 예시인 장비도면 검색에서 텍스트 전용 모델을 이미지 질의의 저가 폴백으로 선택하면 인터페이스가 같아도 기능이 충족되지 않는다. 모델 버전·어댑터 버전·프롬프트·출력 검증 규칙을 하나의 배포 조합으로 승인한다. 설정을 읽는 캐시의 갱신 시간과 장애 시 마지막 정상 구성 사용 정책도 명세한다.

재시도와 회로 차단과 재해 복구

재시도(retry)는 일시적인 실패에 적용하고, 최대 횟수와 전체 대기 시간을 제한한다. 요청 간 대기 시간을 늘리는 백오프(backoff)와 요청이 동시에 몰리지 않도록 대기 시간을 무작위로 조정하는 지터(jitter)도 고려한다. 회로 차단기(circuit breaker)는 실패가 누적되면 해당 대상의 호출을 잠시 막고, 소수의 시험 요청으로 회복 여부를 확인하는 방식이다. 정상 호출을 허용하는 closed, 호출을 차단하는 open, 제한적으로 시험하는 half-open 상태와 전환 조건을 정한다. 어느 모델·리전에 적용하고 어떤 요청들이 같은 상태를 공유할지도 명확히 해야 한다. Step Functions의 Choice는 현재 상태에 따라 분기할 뿐, 여러 실행의 실패 횟수를 자동으로 모으는 전역 저장소가 아니다. 여러 실행이 회로 차단 상태를 공유하려면 별도의 상태 저장과 동시성 제어(concurrency control)가 필요하다. 예제에서 DynamoDB가 부적절한 선택지였더라도 데이터베이스로 회로 차단 상태를 구현할 수 없다는 뜻은 아니다.

Bedrock 교차 리전 추론은 지원 프로파일의 모델 처리 위치·용량 선택과 관계하고, 전체 애플리케이션 재해 복구(disaster recovery, DR)은 입구 API·오케스트레이션·검색 데이터·상태·인증·설정까지 복원되어야 한다. Route53/GlobalAccelerator가 라우팅할 정상 대상이 실제 다중 리전에 존재해야 한다. 출발 리전 자체의 API가 불가하면 모델의 CRIS만으로 앱 전체가 계속 동작한다고 보장하지 않는다. 장애 때도 데이터 레지던시 제한을 풀지 않는다.

안전한 성능 저하와 배포

폴백(fallback)은 원래 처리 경로를 사용할 수 없을 때 선택하는 대안이다. 업무에 따라 작은 모델, 기능이 제한된 모델, 최신성과 권한이 확인된 캐시(cache), 미리 준비한 안전한 안내, 사람에게 인계하는 방법을 사용할 수 있다. 모든 질문을 임의의 캐시나 일반 모델로 보내면 품질과 보안 요건을 어길 수 있다. 요건을 만족하는 대안이 없다면 실패를 명확히 알리거나 대기·검토 상태로 전환한다. 장애 중에도 핵심 요건을 지키면서 제공 기능을 줄이는 점진적 기능 저하(graceful degradation)는, 어떤 상황에서도 답변을 만들어 내야 한다는 뜻이 아니다.

저순위 적응(low-rank adaptation, LoRA)는 적은 수의 학습 파라미터로 적응 비용을 줄일 수 있지만 동일 품질·망각 없음·적은 데이터로 성공을 보장하지 않는다. Registry의 등록·승인·배포는 별도 단계이며 코드 파이프라인도 승인 상태와 평가 결과를 실제로 검사해야 한다. 카나리는 일부 트래픽으로 검증하고 블루·그린은 이전·새 환경 간 전환을 준비한다. Lambda 별칭만 되돌려도 외부 모델·프롬프트·색인까지 같이 복구되는 것은 아니다.

보너스 코드에 대한 독립 점검

예제 구현은 그대로 실행 가능한 프로덕션 템플릿으로 보지 않는다. 단어 수로 토큰을 추정하고 단어 집합 겹침으로 품질을 계산하는 부분은 비용·정확성 평가에 불충분하다. 실패 응답이 평균 품질 집계에서 빠지면 생존 편향이 생긴다. 모든 Anthropic 모델에 동일 요청 스키마를 쓰는 가정, API 인증 NONE, 와일드카드 권한, 구형 런타임·구성 API, 실제 오류를 문자열 성공으로 반환하는 패턴은 재검토 대상이다. Retry/Catch가 있다고 전역 회로 차단이 완성되는 것도 아니다. 실제 마지막 훈련 코드는 표시 본문에서 중간에 끊겨 있으므로 완전한 학습 실행 코드가 아니다.

출처: AIP 영역 1 출처/예제 구현 설명, 교차 리전 추론, Converse 요청과 스트림, Step Functions 오류 처리, Model Registry, AppConfig 구성 배포, 미세 조정과 하이퍼파라미터, 자동 평가 보고서 해석.

1.3 데이터 파이프라인은 의미 보존 계약

유효한 형식과 유효한 사실

데이터 검증(data validation)에서는 스키마(schema), 타입(type), 길이와 값의 범위를 먼저 확인한다. 여기에 레코드 사이의 관계, 최신성, 중복, 출처와 접근 권한도 별도로 검사해야 한다. JSON을 파싱(parsing)할 수 있어도 날짜가 계약 유효기간을 벗어나거나 사진이 다른 사건의 것일 수 있다. AWS Glue Data Quality는 정의한 품질 규칙을 검사하고, Data Wrangler는 데이터를 탐색·시각화·변환하는 데 사용한다. 특수한 업무 규칙은 Lambda로 검사하고, 품질 지표의 변화는 CloudWatch로 추적할 수 있다. 규칙 통과율은 설정한 검사를 통과한 비율이지 데이터의 모든 사실이 맞다는 점수가 아니다.

자체 예시: 설비 정비 기록의 압력값은 숫자인지뿐 아니라 단위·센서 ID·측정시각·허용범위를 함께 검증한다. kPa와 bar를 변환할 때 원래 값·원래 단위·변환 규칙 버전을 남긴다. 알 수 없는 단위나 날짜를 대규모 언어 모델(large language model, LLM)이 그럴듯하게 고쳐 채우지 않게 한다. 실패 레코드는 사유 코드와 원문 위치를 가진 격리 경로로 보내고 검토·재처리를 지원한다.

멀티모달 정렬과 비동기 처리

텍스트·사진·음성·표를 각각 변환한 뒤 하나의 사건 ID·버전·시간 범위로 결합한다. 전사에는 화자·시간 매핑, 이미지에는 원본·크롭 좌표, 광학 문자 인식(optical character recognition, OCR)에는 페이지·박스, 표에는 행·열 의미를 남겨야 근거 추적이 가능하다. 병렬 처리에서 하나의 모달리티가 지연되거나 실패했을 때 전체 실패·부분 결과·사람 검토 중 어떤 정책을 적용할지 명시한다.

Amazon Transcribe는 발화를 텍스트로, Amazon Comprehend는 텍스트의 분석을, Amazon Textract는 문서 문자·구조 추출을, Amazon Rekognition은 시각 콘텐츠 분석을 맡는다. 관리형 API가 임의의 손상 등급·사기 여부·의료 판단까지 자동으로 제공한다고 가정하지 않는다. SageMaker Processing은 사용자 지정 전처리를 실행하는 선택지이며 컨테이너·입출력·권한·자원·실패 재시도 계약이 필요하다.

오래 걸리는 전사 작업을 Lambda 안의 무한 루프로 대기하면 시간·비용·재시도 문제가 생길 수 있다. 시작 → 작업 ID 기록 → 완료 이벤트·제한된 상태 확인 → 결과 검증으로 분리하고 중복 이벤트에 대한 멱등성을 정한다. S3 출력이 다시 같은 입력 트리거를 유발하지 않도록 입력·출력 접두사와 필터를 구분한다.

모델별 입력과 대화 상태

Bedrock InvokeModel의 본문은 모델·버전별로 다르다. Messages 형식, 구형 Completion 형식, Converse 공통 API를 섞지 않는다. 같은 공급자라도 지원 필드와 모달리티가 다르므로 API 계약으로 검사한다. 스트리밍은 응답 전송 방식이고 대화 기억은 앱 상태 문제다. 비스트리밍도 문맥을 전달하면 멀티 턴을 구현할 수 있고, 스트리밍만 켜서는 기억이 생기지 않는다.

대화 이력은 user/assistant 및 도구 결과의 의미를 보존하고 토큰 예산에 맞춰 구성한다. 단순 문자열 연결은 역할 경계를 잃을 수 있지만 구조화 요약도 검증과 필수 필드 보존을 갖추면 유용할 수 있다. 원문 숫자·부정·조건·인용문은 임의로 정규화해 의미를 바꾸지 않는다. LLM으로 입력 문장을 다듬을 경우에도 원본 보존·차이 검사·금지 변환을 두고 전처리 모델의 할루시네이션(hallucination)이 증폭되지 않게 한다.

구현 예제 검토

예제 구현은 설계 개념을 읽는 자료이지 복사 후 즉시 배포할 코드가 아니다. 마지막 형식 변환 코드가 else:에서 끊기고 보조 함수 일부가 없다. 데이터 품질용 가정 Python 클래스·S3 이벤트를 일반 event-source-mapping으로 연결하는 명령·영어 정규식만의 품질 판정·확장자 치환으로 원문 키 복구·duration에 MediaFormat을 넣는 부분은 실제 API/데이터 계약과 대조해야 한다. 파일 경로나 오류 상태를 문자열 추측으로 이어 붙이지 않고 명시적 메타데이터로 전달한다.

출처: AIP 영역 1 출처/예제 구현 설명, Glue Data Quality, Converse 요청과 스트림, Transcribe 입력·출력과 운영 방식, Comprehend 분석과 사용자 지정, Textract 문서 추출, Rekognition 이미지·영상 분석, Step Functions 오류 처리.

1.4 벡터 저장소 — 검색과 갱신의 일관성 계약

공식 출처 AIP D1의 강좌 관련 항목·예제 구현을 대조했다. 아래는 강좌 사례를 다시 쓰는 대체본이 아니라 설계 문제별 독립 설명이다.

검색 시스템을 설계할 때는 원문 ID와 버전, 청크(chunk) ID, 임베딩(embedding) 모델과 차원 수를 기록하는 방식을 정한다. 메타데이터(metadata)의 타입, 접근 권한, 갱신·삭제 절차도 정의해야 한다. Knowledge Bases의 관리형 파이프라인은 구성 부담을 줄여 주지만 모든 원본 시스템의 권한 변경과 데이터 수정이 자동으로 반영되는 것은 아니다. OpenSearch, 관계형 저장소의 벡터 확장, DynamoDB의 메타데이터와 별도 벡터 엔진을 결합한 방식은 검색 방법과 운영 책임이 다르다. Faiss는 벡터 검색 라이브러리(library)이며 완전관리형 데이터베이스와 같은 제품 유형이 아니다.

메타데이터는 검색 정확도뿐 아니라 통제를 위한 자료다. 저자·문서시각·도메인·유효기간·신뢰도·접근권한을 일관된 타입으로 수집하고, LLM이 생성한 편의 태그를 서버가 확인한 권한과 구별한다. 원천에서 사용 권한이 회수됐을 때 벡터 색인과 응답 캐시에도 반영해야 한다. 동기화 완료는 작업 시작이 아니라 색인 반영 및 삭제·갱신 검증까지 포함한다.

성능 최적화는 부하 측정부터 시작한다. 근사 최근접 이웃 검색(approximate nearest neighbor, ANN)은 일부 정확도를 절충해 후보 검색을 빠르게 할 수 있고, 샤딩·복제본은 용량·병렬성과 운영 비용에 영향을 준다. 다중 인덱스는 쿼리가 해당 도메인으로 좁혀질 때 검색 공간을 줄이지만 전체 도메인 검색이면 팬아웃과 관리비가 증가할 수 있다. ‘단일 인덱스는 언제나 느리다’거나 ‘샤드는 많을수록 좋다’는 규칙이 아니다. 벡터(vector) 양자화는 저장량·대역폭을 줄이는 대신 검색 품질 변화를 평가해야 한다.

자체 예시: 정비 문서를 장비군별 인덱스로 나누면 장비군이 확실한 요청의 검색을 줄일 수 있다. 하지만 공통 안전지침이 다른 인덱스에만 있으면 필요한 문서가 누락될 수 있으므로 공통 검색 경로와 합치기·재정렬 정책이 필요하다. 필터로 잘못 제외된 문서를 더 큰 생성 모델이 복구할 수는 없다.

출처: 강좌 관련 항목, 청킹의 설계 절충, 검색 필터·리랭킹·질의 분해, Knowledge Bases 동기화, OpenSearch 샤드 선택. 공식 기술 1.4.1~1.4.5에 실제 기술검토·영상·지침을 연결했다. 모든 제품별 API 구현의 검증 완료나 실습 수행을 뜻하지 않는다.

색인과 권한은 같은 시점의 상태여야 한다

문서 수집 권한은 최종 사용자의 열람 권한과 다르다. 커넥터가 문서를 읽을 수 있어도 그 문서가 모든 사용자 검색 결과에 들어가면 안 된다. 요청자의 검증된 신원 → 서버가 산출한 허용 범위 → 검색 필터 → 최종 근거 재검사로 연결한다. 클라이언트가 보낸 department 같은 문자열만으로 인가하지 않는다. 삭제·권한 회수는 문서·청크·검색색인·메타데이터·캐시를 함께 갱신하며, 지연 중인 요청은 안전하게 거부하거나 권한을 재확인한다. 근거: 공식 출처 AIP D1, IAM 인증과 인가, Knowledge Bases 동기화.

S3 객체 메타데이터가 저절로 수정 이력 전체를 보관하는 것은 아니다. 버전 식별·원본 위치·변환 버전·유효기간을 별도 계약으로 유지한다. 메타데이터 저장소, 원문 저장소, 벡터 엔진을 나누면 조인과 부분 실패 책임도 생긴다. DynamoDB와 벡터 라이브러리의 조합은 역할 분담이며 DynamoDB의 일반 키 조회를 곧바로 ANN 검색으로 해석하지 않는다. 자체 예: 문서 ID+버전으로 처리 작업을 고정하고 청크별 준비 상태가 검증된 뒤 검색 가능한 버전을 전환하면 중복 이벤트·불완전한 색인 문제를 줄일 수 있다.

실시간은 지연 예산이지 무지연 보장이 아니다

웹후크 수신 → 원문 확인 → 변경 판정 → 청킹(chunking)·임베딩 → 색인 쓰기 → 검색 반영까지 시간이 걸린다. 이벤트 유실·중복·역순·재시도·할당량 제한을 고려하고, 증분 갱신 외에 주기적인 대조 작업으로 누락을 찾는다. 원천 수정 시각과 실제 검색 가능 시각의 차이가 동기화 지연이며, 큐가 비었다는 사실만으로 최신성이 보장되지는 않는다. 이벤트 방식이 ‘항상 최신’이고 내보내기는 ‘항상 불안전’이라는 일반화는 하지 않는다. 안전한 배치·내보내기도 원천 허용조건과 암호화·인가·삭제를 충족하면 선택지가 된다. 근거: 공식 출처 AIP D1, Knowledge Bases 동기화, Step Functions 오류 처리.

성능 지표와 제품 경계

검색 지연 p95, 동시 요청 처리량, 후보 재현율(Recall), 상위 결과 관련성(Relevance), 색인 갱신 지연, 비용·성공 질의를 따로 측정한다. ANN 후보 수·필터 선택도·샤드 팬아웃·복제·캐시 적중을 바꾸면 품질과 비용이 같이 변한다. 다른 색인에서 나온 점수는 그대로 비교 가능한 척도라고 가정하지 말고 정규화·순위 결합·리랭킹을 평가한다. X-Ray는 요청 추적 도구이지 데이터 일관성을 자동 유지하는 시스템이 아니다. ElastiCache는 캐시 역할이며 벡터 압축 기능 자체를 자동 제공한다고 강좌 관련 항목의 인접 문장만으로 해석하지 않는다. 근거: 공식 출처 AIP D1, 검색 필터·리랭킹·질의 분해, OpenSearch 샤드 선택.

예제 코드와 실제 구현을 구별하기

예제 구현의 문서 저장함수는 pass이고 위키 커넥터는 문자열 중간에서 끝나므로 완성된 실행 예제가 아니다. 매 처리마다 무작위 문서 ID를 만들면 같은 원문 재처리에서 중복을 방지하기 어렵다. 벡터 쓰기 전에 completed 메타데이터를 저장하면 실제 저장 실패를 성공으로 남길 수 있다. 문자 길이 한도와 단어 수 중첩을 섞는 청킹은 토큰 한도를 보장하지 않는다. metadata 접두사만 검사하는 필터는 인가 검증이 아니다. KB 관리 클라이언트·모델 ARN·청킹 필드, 온디맨드와 GSI 처리량 설정, CloudFormation 플러그인 필드는 현행 공식 API와 별도 대조해야 한다. 강좌 코드의 숫자(차원·샤드·k 등)를 모든 모델·엔진의 권장값으로 복제하지 않는다. 근거: 공식 출처 AIP D1, 청킹의 설계 절충, Converse 요청과 스트림. 정확한 실행 코드는 API 계약과 테스트로 별도 검증해야 한다.

1.5 검색 품질을 단계별로 진단하기

청크는 저장 단위이면서 근거 단위다

입력 문서를 구조화하고 제목·절·표·부정 조건·예외 조항의 관계를 보존한 뒤 청크를 만든다. 고정 크기는 구현과 상한 통제가 단순하지만 의미 경계를 끊을 수 있다. 구조 기반은 문서 마크업 품질에 의존하고, 계층적 청킹은 작은 청크로 찾은 뒤 상위 문맥을 회수하는 선택지를 준다. 시맨틱 분할은 의미상 경계를 이용하지만 추가 처리 비용·불안정한 분할을 평가해야 한다. 어떤 방식을 택해도 원문 ID/버전·위치·부모 청크와 연결한다. 근거: 공식 출처 AIP D1, 청킹의 설계 절충.

자체 예시: 장비 정비 지침의 ‘압력이 낮으면 밸브를 연다’만 분리하고 ‘고온일 때 제외’를 다른 청크로 밀어내면 높은 유사도라도 위험한 근거가 된다. 청크 중첩은 경계 누락을 줄일 수 있으나 중복 검색·토큰 증가도 유발한다. 최종 문맥을 구성할 때 중복을 제거하면서 예외 문장을 잃지 않는지 평가한다. 문자·단어·모델 토큰은 다른 단위이므로 문자 1000이 토큰 1000이라는 보장은 없다.

임베딩의 차원과 희소성을 혼동하지 않기

임베딩은 문서와 질의를 비교 가능한 수치 공간으로 옮긴 표현이다. 모델·버전·정규화·출력 차원·벡터 형식·거리 척도가 저장소와 일치해야 한다. 문서 모델과 질의 모델을 임의로 섞으면 차원이 같아도 의미 공간이 다를 수 있다. 검색 전용 모델이 문서·질의별 입력 유형을 요구하면 각 경로에 맞춰 설정한다. 숫자가 더 큰 차원이나 최신 모델이라는 이유만으로 업무 품질이 높다고 결정하지 않는다. 도메인·언어·긴 문서·드문 고유명사별 대표 질의로 후보를 비교한다. 근거: 공식 출처 AIP D1, RAG 내부 흐름, 검색 필터·리랭킹·질의 분해.

강좌 관련 항목의 밀집=높은 차원·희소=낮은 차원이라는 표현은 정의로 채택하지 않는다.

밀집·희소는 0이 아닌 성분의 분포에 관한 구분이고 차원 수와 별개다. 희소 벡터도 아주 높은 차원을 가질 수 있다. Titan1536 차원이라는 강의 예시는 모든 Titan 버전의 고정값이 아니다. 강좌 관련 항목의 Bedrock 경유 사용자 지정 임베딩 미세 조정도 모든 모델의 현재 지원으로 확장하지 않는다. 모델별 튜닝·가져오기·호스팅 조건은 별도 확인할 제품 범위다.

벡터 검색을 배치할 때는 먼저 기존 데이터와 질의 패턴을 보고 엔진을 고른다. 관계형 데이터와 함께 벡터를 조회해야 한다면 Aurora의 지원되는 pgvector 구성을, 키워드와 벡터 검색을 함께 운영하려면 OpenSearch를, 수집·검색 연결의 관리 부담을 줄이려면 Knowledge Bases와 지원 저장소를 비교한다. 어느 선택도 모든 입력과 검색 기능을 자동 지원하지는 않는다. 인덱스의 차원·거리 함수·메타데이터 타입을 임베딩 출력과 맞춘 뒤, 문서와 질의를 같은 계약으로 처리한다. 대표 질의에서 필요한 근거가 검색되는지, 다른 사용자의 문서가 제외되는지, 수정·삭제가 반영되는지를 확인해야 배치가 끝난 것이다. 근거: AIP 공식 영역 1, Knowledge Bases 선택, 검색·필터의 조건.

하이브리드와 리랭킹은 서로 다른 단계다

키워드 검색(keyword search)은 정확한 제품 코드, 고유명사, 법조문 번호를 찾는 데 유용하다. 의미 검색(semantic search)은 표현이 달라도 관련된 내용을 찾는 데 유용하다. 하이브리드 검색(hybrid search)은 두 방식의 검색 후보나 점수를 결합한다. BM25 점수와 벡터 유사도(vector similarity)는 척도가 다를 수 있으므로 단순히 더하면 된다고 가정하지 않는다. 후보를 찾은 뒤에는 리랭커(reranker)가 질문과 후보 문서를 함께 평가해 순서를 다시 정할 수 있다. 이 리랭킹(reranking) 단계는 이미 찾은 후보를 재정렬하므로, 처음부터 검색되지 않은 원문을 되살리지는 못한다. 근거: 공식 출처 AIP D1, 검색 필터·리랭킹·질의 분해.

관리형 Knowledge Bases의 검색 유형 옵션은 저장소·텍스트 필드·지원 모델 조건을 갖는다. 단순히 ‘하이브리드’라고 지정했다고 모든 저장소에서 같은 방식이 실행되는 것은 아니다. 테넌트·권한·시점 필터는 관련성 선호와 분리하고 필수 통제로 적용한다. 자기 조직에 허용되지 않은 문서를 먼저 생성 문맥에 넣고 나중에 가리는 설계는 피한다. IAM 인증과 인가와 공식 출처 AIP D1을 함께 적용한다.

확장·분해·표준 인터페이스

확장은 원래 질의의 의미를 유지하며 동의어나 표현을 추가하고, 분해는 복합 요구를 여러 하위 질문으로 나눈다. 독립적인 하위 검색은 병렬화할 수 있지만 앞선 결과가 필요한 하위 질문은 순서를 지켜야 한다. 부정·관할권·날짜·대상 코드를 변형 과정에서 잃지 않도록 원래 질의를 보존하고 구조 검증을 적용한다. 추가 질의 수·전체 시간·토큰·호출 비용에 상한을 둔다. 일부 하위 검색 실패를 전체 성공으로 뭉개지 말고 어떤 근거가 빠졌는지 기록한다. 근거: 공식 출처 AIP D1, Step Functions 오류 처리, AgentCore Gateway.

자체 검색 API 예시에서는 질문, 허용 필터(filter), 최대 결과 수와 지연 시간(latency)을 입력으로 받는다. 응답에는 문서 ID·버전(version)·근거 위치·조회 시각·검색 방식·처리 상태를 포함한다. 함수 호출/모델 컨텍스트 프로토콜(Model Context Protocol, MCP)는 이 접점을 일관되게 만드는 수단이지 인증·권한을 대신하는 기능이 아니다. 입력 스키마를 등록한 것과 실제 검색 함수 구현·인가·검증이 완료된 것은 다르다.

검색 지표가 답하는 질문

정밀도(Precision)@k는 반환된 상위 k 개 중 관련 근거의 비율, 재현율(Recall)@k는 기준 집합의 관련 근거 중 상위 k 개가 회수한 비율이다. 기준 집합을 모르면 재현율을 정확히 산출했다고 주장할 수 없다. 평균 역순위(mean reciprocal rank, MRR)은 각 질의에서 첫 관련 결과의 순위 역수를 평균하며, 관련 결과가 없으면 그 질의 기여를 0으로 두는 등 집계 규칙을 명시한다. 첫 정답을 빨리 찾는 품질에 민감하지만 뒤쪽 관련 결과 전체를 충분히 평가하지 않는다. 정규화 할인 누적 이득(normalized discounted cumulative gain, NDCG)는 관련도 등급에 위치 할인값을 적용한 이득을 이상적인 순위의 이득으로 정규화한다. 관련도 등급·할인 식·k·정답 없는 질의 처리 규칙을 함께 고정해야 비교할 수 있다. 이는 예제 구현이 지표 이름으로 요구한 것을 풀어 쓴 이해 보충이며 강좌에 완전한 수식 구현이 있었다는 뜻은 아니다. 근거: 공식 출처 AIP D1, LLM 평가자, 평가자 지표의 의미.

자체 예시: 세 질의의 첫 관련 결과가 1위·2위·없음이면 MRR=(1+1/2+0)/3=0.5 다. 이 숫자가 정답률 50%나 사실적 정확성(factual accuracy) 50%라는 뜻은 아니다. 질의 집합과 k를 바꾼 전후 점수를 같은 실험처럼 비교하지 않는다. 비용은 성공 질의당 검색·리랭킹·생성·재시도 비용으로, 지연은 평균뿐 아니라 꼬리 지연으로 평가한다.

예제 코드를 그대로 실행하지 않는 이유

고정 크기 청킹의 마지막 구간에서 start=end-overlap만 반복하면 끝에 도달해도 루프가 전진하지 않을 수 있다. 시맨틱 청킹은 앞부분만 전달하고 생성 결과를 청크로 파싱하지 않은 채 미정의 변수를 반환한다. 주석에 적힌 75/25 비율은 쿼리의 실제 가중치 구현 증거가 아니다. 리랭커 모델명/API, CloudFormation 리소스 타입, KB 관리 클라이언트·필드, Step Functions의 JSONPath 동적 필드와 Lambda 결과 래핑도 검증이 필요하다. 보안 비활성 옵션이나 원시 예외를 호출자에게 돌려주는 패턴은 그대로 채택하지 않는다. 마지막 함수 정의에는 중간 종료와 비코드 문구가 있어 완전한 코드가 아니다. 이 점검은 공식 출처 AIP D1의 정적 독해이며 실행 테스트가 아니다.

1.6 프롬프트를 통제 가능한 애플리케이션 구성으로 만들기

지시, 필터, 형식, 권한의 네 가지 경계

역할·행동 범위·필수 질문·응답 스타일을 시스템 지침과 버전 관리된 템플릿으로 정한다. Guardrails는 설정한 위험 범주·거부 주제·민감정보 등에 대한 별도 통제다. JSON Schema는 구조·타입을 검사하고 자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM)과 업무 인가는 실제 접근·행동 권한을 제한한다. 어떤 한 기능도 다른 세 기능을 대신하지 않는다. JSON이 파싱된다고 사실이 맞거나 안전한 업무 지시라는 보장은 없다. 전문적인 어조만으로 금융 조언의 적법성·정확성을 증명할 수 없다. 근거: 공식 출처 AIP D1, Guardrails의 역할과 경계, 프롬프트 관리, IAM 인증과 인가.

자체 예시: 고객지원 도우미는 ‘향후 기능을 약속하지 않는다’는 지침과 함께 확인된 공개 문서만 검색하고, 근거 없는 출시일은 답하지 않으며, 계정 변경은 별도 승인 API로 제한한다. 사용자가 삽입한 문서·대화·도구 응답은 신뢰된 지침으로 승격하지 않는다. 필터 강도를 높인다고 모든 유해 출력이 차단되는 것은 아니므로 정상 요청 오차단과 위험 요청 누락을 모두 평가한다.

대화 상태와 명확화 루프

대화 요청에는 검증된 사용자 신원, 세션 ID, 질문과 허용된 문맥을 묶는다. 처리 결과는 답변만이 아니다. 정보가 부족하면 추가 질문을 돌려주고, 도구가 필요하면 실행 요청을 만들며, 해결할 수 없으면 사람에게 인계할 상태를 남긴다. Comprehend 사용자 지정 분류는 학습한 의도 범주를 라우팅하는 수단이고 감정 분석은 의도 자체와 다르다. 낮은 의도 확신, 누락된 필수 필드, 서로 모순되는 대상이 있으면 명확화한다. 반복 질문 횟수·총 시간을 제한하고 해결되지 않으면 사람에게 인계한다. 자체 예시: ‘그 계좌를 닫아 줘’에서 계좌 대상을 추측하지 않고 먼저 확인한다. 조회 대화와 폐쇄 실행은 분리한다. 근거: 공식 출처 AIP D1, AgentCore 메모리, Step Functions 오류 처리.

DynamoDB에 기록을 저장하는 것만으로 파운데이션 모델(foundation model, FM)이 문맥을 기억하는 것은 아니다. 앱이 요청 시 필요한 이력을 읽어 올바른 역할 구조로 전달해야 한다. 사용자 ID만 키로 쓸 때 여러 세션·동시 요청이 섞일 위험이 있고, 저장 시 버전 조건·멱등성·쓰기 충돌을 고려한다. 필요한 대화만 남기고 민감한 로그·캐시·요약의 보존을 함께 통제한다.

유효 기간(time to live, TTL) 만료와 실제 삭제는 다르다. 신규 DynamoDB TTL과 실제 삭제 시점의 공식 한국어 본문은 만료 후 일반적으로 며칠 내 삭제를 설명한다. 따라서 강좌 관련 항목의 90일은 사례 정책일 뿐, TTL만으로 정확한 시각의 삭제·준수를 보장한다고 쓰지 않는다. 만료 항목이 남아 있더라도 앱은 만료 시각을 검사해 다시 사용하지 않아야 한다. 글로벌 테이블 복제 삭제 비용도 별도다.

버전 생성과 승인과 배포를 나누기

프롬프트(prompt)를 바꿀 때는 텍스트뿐 아니라 변수(variable)의 형식, 모델, 추론(inference) 설정, 평가 세트(evaluation set), 검증 규칙을 함께 관리한다. 초안(draft)을 수정한 뒤 후보 버전(version)을 고정하고 동일한 평가를 수행한다. 권한 있는 담당자가 검토·승인하면 앱이 참조하는 버전을 변경해 배포(deployment)하고 운영 결과를 관찰한다. 문제가 생길 때 되돌릴 롤백(rollback)도 준비한다. 버전이 존재한다는 사실만으로 검토가 끝났거나 운영 앱이 그 버전을 사용한다고 판단해서는 안 된다. 근거: 공식 출처 AIP D1, 프롬프트 관리, 신규 프롬프트 버전과 배포 승인 구분.

강좌의 3 역할/3 단계 승인은 거버넌스 설계 요구로 이해한다. 공식 개요·배포 본문에서는 이 조직 승인 전체를 자동 제공하는 전용 UI를 확인하지 못했으므로 제품 내장 기능으로 확정하지 않는다. CloudTrail API 감사와 모델 호출 입력·출력 로깅도 구분한다. 모든 API·모든 내용이 기본적으로 영구 저장되는 것이 아니며 지원 이벤트·로깅 설정·권한·보존 위치를 확인해야 한다. 7년 보존은 강좌 가정 조직의 예시이지 보편 법정 기간이 아니다. 모델 호출 로깅의 기본 비활성·민감 내용 조건을 함께 적용한다.

품질 회귀와 운영 피드백

평가에는 정상 요청뿐 아니라 뜻이 모호한 질문, 정보가 빠진 입력, 악성 지시, 긴 문서, 여러 언어와 권한 없는 요청을 포함한다. 먼저 문법과 필수 필드를 검사하고, 답이 근거와 일치하는지와 정책을 위반하는지를 따로 확인한다. 사람의 판단이 필요한 경우에는 검토 경로로 넘긴다. CloudWatch가 자동으로 정확성의 정답을 생성하는 것은 아니며 평가 루브릭·검증 시스템이 계산한 지표를 내보내야 한다. 만족도가 높아졌어도 사실 오류나 민감 정보 노출이 증가할 수 있으므로 위험 지표를 평균 만족도로 상쇄하지 않는다. 근거: 공식 출처 AIP D1, 평가자 지표의 의미, 자동 평가 보고서 해석.

프롬프트(prompt)를 반복해서 개선하는 것은 모델 가중치(weights)를 추가 학습하는 미세 조정(fine-tuning)과 다르다. 구조화 입력·명시 출력·예시·검증 가능한 중간 산출물을 개선한다. 단계적 풀이를 요청하는 기법도 모든 모델에서 정확도를 보장하지 않으며 내부 추론을 전부 노출해야 하는 것은 아니다. 사용자에게는 확인 가능한 근거와 간결한 설명을 제공하고 민감한 내용의 로그 확산을 피한다. 가상 사례의 위반 감소율·만족도·절감액을 실 고객 실적이나 합격선으로 쓰지 않는다.

복합 프롬프트 흐름의 실패 경계

전처리(preprocessing), 정보 추출(extraction), 분류(classification), 요약(summarization), 근거 기반 응답으로 이어지는 흐름에서는 단계마다 입력·출력 스키마(schema)와 근거 ID를 정한다. 실패 시 처리 방법과 재시도(retry) 예산도 단계별로 명시한다. 분기 조건은 검증한 필드에 기반하고 모델의 임의 자신감 값만으로 위험한 행동을 승인하지 않는다. Flows는 모델·프롬프트·도구를 연결하는 수단이고 Step Functions는 더 넓은 업무 상태 오케스트레이션에 사용할 수 있다. 어느 쪽도 노드가 있다는 사실만으로 관측·검증·인가가 완성되지는 않는다. 근거: 공식 출처 AIP D1, Flows 버전과 별칭, Step Functions 오류 처리.

예제 구현의 0.7의도 임계값은 설명용 숫자이며 보편 추천 값이 아니다. 표시된 코드는 후속 상태를 생략한 상위 구조이고 JSON 주석·정의되지 않은 상태를 포함하므로 배포 가능 파일이 아니다. 실습·리소스·코드 실행은 하지 않았다.

상황형 자기점검

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

1. PoC의 통과 기준

정비 도우미 PoC가 쉬운 문서 세 건에 답했다. 실제 서비스에는 구형·신형 장비, 손상 문서, 권한이 다른 직원이 있다. 확대 전에 무엇을 해야 하는가?

• A. 가장 비싼 모델로 고정하면 별도 기준이 필요 없다
• B. 실패 입력을 제외하고 성공 응답만 보고한다
• C. 대표·경계·실패 입력과 품질·지연·비용·권한 기준으로 작은 비교 실험을 한다
• D. 세 건이 성공했으므로 모든 장비에서 정확하다고 발표한다

2. 장애 시에도 남는 리전 조건

모델 호출이 일시 중단됐다. 대체 리전의 모델은 사용 가능하지만 고객 계약이 그 리전으로의 데이터 전송을 금지한다. 올바른 폴백은?

• A. 장애 동안만 리전 제한을 해제한다
• B. 앱에 아무 경고 없이 오래된 답을 항상 반환한다
• C. 권한 오류도 같은 요청으로 무제한 재시도한다
• D. 허용 경계 안의 검증된 대안 또는 대기·사람 인계·명시적 실패를 사용한다

3. 단위 없는 센서 값

모델 입력 파이프라인이 압력값을 받았지만 일부 레코드에 단위가 없다. 단위 추정이 틀리면 안전 지침이 달라진다. 적절한 처리는?

• A. 원문과 실패 사유를 보존해 격리·검토하고 확인된 단위만 명시적 규칙으로 변환한다
• B. LLM에게 가장 그럴듯한 단위를 만들어 넣게 한다
• C. JSON 파싱이 성공하면 단위 검증 없이 전달한다
• D. 모든 값을 같은 수치로 치환한다

4. 원문 권한 회수와 검색

직원의 문서 권한이 회수됐지만 벡터 색인과 응답 캐시는 아직 갱신되지 않았다. 수집 커넥터는 계속 문서를 읽을 수 있다. 안전한 대응은?

• A. 임베딩 차원만 늘린다
• B. 현재 사용자 권한으로 검색·근거를 재검사하고 색인·캐시의 회수 전파를 처리한다
• C. 커넥터가 읽을 수 있으니 직원도 읽게 한다
• D. 캐시 TTL이 끝날 때까지 무조건 허용한다

5. 제품 코드와 자연어를 함께 찾기

사용자는 정확한 부품 코드와 자연어 증상을 섞어 묻는다. 의미 검색은 코드가 비슷한 다른 부품을, 키워드 검색은 표현이 다른 관련 문서를 놓친다. 평가할 개선안은?

• A. 리랭커가 검색되지 않은 문서도 만들어낸다고 가정한다
• B. 생성 모델을 크게 바꾸고 검색은 그대로 둔다
• C. 키워드·벡터 후보를 결합하고 필요시 리랭킹하며 코드·권한·근거 포함률을 검사한다
• D. 제품 코드의 숫자를 모두 제거한다

6. 버전 생성과 출시 승인

새 프롬프트 버전을 저장했다. 형식은 좋아졌지만 민감한 예외 입력의 회귀검사는 아직 실행하지 않았다. 다음 단계는?

• A. 새 버전 번호가 있으므로 즉시 모든 트래픽을 전환한다
• B. 평가 실패를 0점이 아닌 누락으로 숨긴다
• C. 프롬프트만 되돌리면 모델·도구 변경도 자동 복구된다고 가정한다
• D. 고정된 정상·경계·안전 평가와 승인 후 배포 대상을 전환한다

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