AIP-C01 영역 2 — 에이전트·배포·기업 시스템 통합

모델이 답을 만드는 단계와 외부 시스템에서 실제 업무가 완료되는 단계는 다르다. 에이전트의 도구 호출, 모델 배포, 기업 시스템 연결, API와 사용자 화면을 이 구분에 따라 설계한다. 각 예제는 실행 권한·상태·실패 처리의 책임이 어디에 있는지 설명하기 위한 것이다.

2.1 에이전트의 자율성보다 실행 계약을 먼저 설계하기

단일 에이전트와 다중 에이전트의 선택

단일 에이전트는 한 요청의 문맥·도구·종료를 한 곳에서 관리하기 쉽다. 다중 에이전트는 서로 다른 전문 역할·데이터 경계를 나눌 수 있지만 통신·위임·중복 호출·상태 충돌·비용이 늘어난다. 단순 업무에 역할을 늘린다고 정확도가 자동 상승하지 않는다. Amazon Bedrock Agents는 관리형 에이전트 구성·작업 그룹, Strands/Agent Squad는 프레임워크와 조정 관점, AgentCore는 실행·메모리·연결·관측 등 플랫폼 관점으로 구별한다. 강좌의 Stand/Stands/Strand 표기를 새 제품명으로 등록하지 않는다. 근거: 공식 출처 AIP D2, 에이전트와 도구, AgentCore 구성요소와 MCP.

자체 예시: 공장 정비 도우미가 진단·부품 조회·정비 예약을 맡는다고 하자. 세 역할이 각각 예약을 생성하면 같은 정비가 중복 등록될 수 있다. 실제 변경은 하나의 조정 경로에서 수행하고 다른 역할은 조회와 제안만 하도록 나눌 수 있다. 작업을 위임할 때는 업무 ID, 맡길 범위, 허용 도구, 기한, 반환할 결과의 형식(output schema), 완료 조건(completion criteria)을 전달한다. 여러 에이전트(agent)가 같은 문서를 읽더라도 서로의 실행 권한까지 공유하는 것은 아니다.

메모리와 업무 상태

단기 대화 문맥(short-term context), 장기 메모리(long-term memory)에 저장하는 선호·지식, 현재 업무의 실행 상태(execution state)를 구분한다. 메모리에는 출처·사용자·테넌트(tenant)·유효 기간·수정 권한을 함께 기록한다. 도구 응답에 섞인 명령을 다음 대화의 신뢰된 지침으로 저장해서는 안 된다. DynamoDB·ElastiCache·S3는 데이터 유지 방식(persistence), 지연 시간(latency), 저장 형태가 서로 다르므로 요구에 맞게 선택한다. 모델에 파일 경로만 전달했다고 앱이 파일 본문을 읽어 문맥에 넣은 것은 아니다. 근거: 공식 출처 AIP D2, AgentCore 메모리, TTL보충.

자체 상태 설계에서는 계획, 요청, 실행 중, 검토 대기, 성공, 실패, 결과 불명을 구분한다. 메모리의 “완료할 예정”은 실행 성공이 아니다. 실제 도구 결과와 대상 시스템의 상태를 멱등성 키에 연결해 완료를 확정한다. 보존 기한이 지난 항목은 물리 삭제를 기다리는 동안에도 조회에서 제외한다.

ReAct와 반복의 종료

ReAct는 다음 행동을 선택하고 도구 관찰 결과를 바탕으로 진행 방향을 수정하는 반복 패턴이다. AWS Step Functions는 이 상태 전환을 명시하는 선택지이지 필수 유일한 구현은 아니다. 문제 분해 → 필요한 정보 조회 → 결과 검증 → 다음 행동·종료를 구분하고 최대 호출·최대 시간·비용·동일 실패 반복·안전 중지 조건을 별도로 둔다. 상태를 저장하는 것만으로 추론의 정확성이 보장되지 않으며 검증 가능한 중간 산출물과 최종 결과를 평가한다. 내부 추론 전문을 사용자에게 전부 노출할 필요는 없다. 근거: 공식 출처 AIP D2, Step Functions 오류 처리, 도구 실행 책임.

자체 예시: 부품 검색이 0건이면 동일 요청을 무한 반복하지 않고 호환 부품 조회라는 허용된 대안 또는 사람 검토로 전환한다. 타임아웃은 호출자의 대기 종료일 수 있으므로 원격 부품 발주가 실패했다고 단정하지 않는다. 실제 부작용 조회 후 재시도 여부를 결정한다.

회로 차단과 권한과 안전 모드

경보(alarm)는 문제를 알리고, 재시도(retry)는 일시적인 실패가 난 요청을 제한된 횟수만 다시 보낸다. 회로 차단기(circuit breaker)는 장애가 누적된 대상에 대한 호출을 잠시 막는다. 정상 호출을 허용하는 closed, 호출을 차단하는 open, 제한적으로 회복을 시험하는 half-open 상태를 구분한다. 실패율을 집계할 시간 구간과 최소 표본 수, 회복 시험 방법, 동시성 제어(concurrency control)를 정해야 한다. CloudWatch 알람을 만들기만 해서는 트래픽이 자동 차단되지 않는다. 대체 모델·사람 인계·안전한 정적 안내로 전환해도 기존 리전·권한·품질 제약을 유지해야 한다. 근거: 공식 출처 AIP D2, Step Functions 오류 처리, D1 복원력.

자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM)은 실행 주체의 허용 행동을 통제하고 앱 인가(authorization)는 최종 사용자의 업무 대상 권한을 검사한다. 프롬프트(prompt)에 ‘읽기만’이라고 쓰는 것과 실제로 쓰기 권한을 제거하는 것은 다르다. 낮은 temperature도 접근 통제나 정확성 보장은 아니다. IAM 인증과 인가과 Guardrails의 역할과 경계를 함께 적용한다.

모델 조정과 앙상블의 조건

라우팅(routing)은 한 요청을 적절한 모델 후보로 보내고, 앙상블(ensemble)은 여러 모델의 출력을 결합한다. 공통 스키마·단위·의미가 맞는 분류나 수치에 대한 집계와 자유 문장의 합의는 다르다. 독립적 오류를 가정할 수 없는 모델들이 같이 틀리면 다수결도 틀린다. 가중치는 검증 데이터에서 정하고 현재 요청의 언어·모달리티·품질·지연·허용 리전 조건을 먼저 검사한다. 여러 호출의 비용과 꼬리 지연도 포함한다. 근거: 공식 출처 AIP D2, 교차 리전 추론, 평가자 지표의 의미.

강좌의 특정 모델 이름은 교육 예시이며 현재 최선의 모델 추천이 아니다. 강좌 관련 항목에 DALL-E가 Bedrock 모델 맥락으로 등장하지만 이 문장만으로 현재 Bedrock 지원 모델로 판정하지 않는다. 공급자·모델별 현재 지원은 공식 목록 대조가 남아 있다.

인간 승인과 도구 계약

고위험 행동은 모델 자신감이 높아도 필수 검토를 건너뛰지 않는다. 승인 대상에는 실행할 정확한 대상·변경 내용·영향·유효 기간·요청 ID를 묶고, 거절·만료·보류·취소를 명시한다. 검토 완료와 변경 승인은 다른 상태다. 피드백을 API Gateway로 받았다고 그 데이터가 자동 학습에 사용되거나 모델이 즉시 개선되는 것은 아니다. 평가·검토·데이터 허가·훈련·배포 절차는 별도다. 근거: 공식 출처 AIP D2, IAM 인증과 인가, 도구 실행 책임.

도구를 등록할 때는 어떤 일을 하는지, 어떤 입력을 받는지, 성공과 오류를 어떻게 돌려주는지 설명한다. 주문이나 삭제처럼 외부 상태를 바꾸는지도 명시해야 한다. 호출을 받으면 인수의 형식과 범위를 확인한 뒤 사용자의 권한을 검사한다. 사람 승인이 필요한 작업은 승인을 기다리고, 이미 실행한 요청인지 확인한 후 실행한다. 마지막에는 반환값뿐 아니라 실제 업무 결과도 검증한다.

OpenAPI는 API 인터페이스를 기술하는 사양이다. 이름이 비슷한 OpenAI는 별개의 제공자 이름이므로 혼동하지 않는다. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 클라이언트가 도구를 찾아 호출할 때 사용하는 규약이다. API Gateway에 일반 HTTP API를 만들었다고 MCP 서버가 되는 것은 아니다. MCP 요청과 응답을 처리하는 서버나 지원되는 변환 계층이 필요하다.

실행 환경은 연결의 수명과 상태를 기준으로 고른다. 짧고 상태를 유지하지 않는 작업은 Lambda를 검토할 수 있다. 오래 연결을 유지하거나 별도 런타임·자원이 필요한 서버는 ECS 같은 컨테이너 환경과 비교한다. 어느 쪽을 선택해도 지원되는 전송 방식, 인증, 세션 상태와 오류 처리를 확인해야 한다. AgentCore Gateway, AgentCore 구성요소와 MCP.

예제 구현의 주의점

회로 차단 상태를 DynamoDB 처럼 공유 저장소에 둘 수도 있지만, 상태 전이·동시성·읽기 실패 정책을 함께 설계해야 한다. 하지만 코드 그대로 운영 가능한 것도 아니다. 상태 쓰기의 put_item은 기존 호출 기록을 덮을 수 있고, half-open 전환 뒤 로컬 상태가 갱신되지 않는 경로, 상태 읽기 오류를 closed로 취급하는 정책, 제한 없는 호출 리스트 증가, 동시 시험 요청 경쟁을 검토해야 한다. 리스트를 +연산으로 붙이는 UpdateExpression도 공식 문법 대조가 필요하다. 오류율 50%/5분·timeout10 초는 샘플 조건이지 보편 권장값이 아니다.

ReAct 예제의 문자열 포함 검사는’additional action needed’라는 구절만 보므로 부정문도 행동 필요로 잘못 분류할 수 있다. 구조화된 판정과 검증을 사용한다. 인간 검토 Choice는 높은 자신감 분기가 민감도 검사보다 앞서면 민감 요청을 검토 없이 전달할 수 있다. 검토 대기 루프의 종료·만료와 Lambda 결과 래핑도 명시되어야 한다. IAM의 토큰(token)/temperature 조건 키와 모델 ARN은 지원 여부를 확인하기 전 보안 경계로 믿지 않는다. 마지막 코드는 import 중간에 비코드 문구가 섞인 불완전 표시다. 공식 출처 AIP D2. 코드를 실행하거나 수정본을 저장하지 않았다.

2.2 모델 배포는 메모리·지연·수요를 함께 맞추는 일

호출용 컴퓨팅과 모델 호스팅의 구분

Lambda가 Bedrock API를 호출하는 설계와 Lambda 안에서 모델 가중치를 직접 로드하는 설계는 다르다. 전자는 앱의 인증·검증·라우팅·요청을 실행하고 모델 연산은 관리형 서비스가 맡는다. 후자는 런타임·패키지·메모리·CPU·실행 시간의 실제 제약 안에 모델이 들어가야 한다. 예제 구현의 온디맨드 예제는 외부 Bedrock 호출이며 대형 모델의 Lambda 호스팅 증거가 아니다. 근거: 공식 출처 AIP D2, Bedrock 역할과 최신 기능 경계, Converse 요청과 스트림.

관리형 온디맨드는 간헐적인 사용에서 유휴 호스팅 비용을 줄이는 선택지다. 프로비저닝된 처리량은 지원 모델의 예약 용량·약정·단위·비용과 수요 지속성을 검토해야 한다. SageMaker AI의 컨테이너·엔드포인트는 자체 모델과 전·후처리·런타임 제어를 제공하지만 로딩·메모리·인스턴스·확장·보안의 운영 책임이 늘어난다. Custom Model Import는 지원 아키텍처·모델·파일 조건을 충족하는 선택지이지 임의의 SageMaker 모델 전부를 그대로 가져오는 보장은 아니다.

자체 예시: 주간 회의 때만 쓰는 문서 요약은 관리형 호출로 시작할 수 있고, 고유 가중치와 특수 토크나이저가 필요한 내부 분석은 컨테이너 호스팅을 검토할 수 있다. 최종 선택은 수요뿐 아니라 언어·모델 권리·민감 데이터·지연·품질 요구에 따른다. 하루 100회라는 교육 예제의 예시를 보편 비용 분기점으로 사용하지 않는다.

대형 모델의 메모리 예산

가중치 메모리, 실행 중 활성값·작업 버퍼, KV 캐시, 런타임 오버헤드, 동시 요청 증가분을 따로 계산한다. 가중치의 대략적 하한은 파라미터 수 × 파라미터당 바이트이지만 이것만으로 호스팅 메모리를 정하면 부족하다. 자체 산술 예:65B 파라미터를 2 바이트로 단순 표현하면 가중치만 약 130GB(십진 기준)이고 캐시·버퍼는 추가다. 이는 강좌의 실측 인스턴스 요구량이 아니다. 양자화는 가중치 표현을 줄일 수 있지만 품질·지원 커널·변환 비용을 검증한다. 근거: 공식 출처 AIP D2, 대규모 모델 호스팅.

GPU 메모리와 컨테이너 CPU 메모리와 디스크/EBS는 서로 다르다. 디스크 500GB가 있다고 500GB 모델이 GPU에 적재되는 것은 아니다. 모델 병렬화는 여러 장치에 모델을 분할하는 전략이고 데이터 병렬 복제는 모델 사본으로 요청을 나누는 전략이다. 통신 비용·인터커넥트·프레임워크 호환성을 검토해야 한다. 서빙 제품·모델·컨테이너별 지원 조건 없이 특정 라이브러리 이름을 붙여 확장된다고 가정하지 않는다.

로딩과 첫 응답과 정상 처리량

모델 다운로드 시간, 컨테이너 초기화 시간, 첫 요청의 가중치 적재, 추론(inference) 중 첫 토큰 시간, 전체 생성 시간을 분리한다. 상태 검사 시간 초과를 늘리면 느린 초기화가 실패하지 않도록 기다릴 수 있지만 실제로 로딩이 빨라진 것은 아니다. 지연 로딩은 초기 준비 부담을 첫 사용 시점으로 옮길 수 있어 첫 사용자 지연을 악화시킬 수도 있다. 엄격한 첫 응답 서비스 수준 목표(service level objective, SLO)가 있으면 준비 상태 검사와 필요한 예열·용량 전략을 설계한다. 근거: 공식 출처 AIP D2, 대규모 모델 호스팅.

배칭은 여러 요청을 함께 처리하여 장치 사용률을 개선할 수 있지만 배치를 모으는 대기 시간과 긴 출력에 의한 지연을 추가한다. 최대 배치 대기 시간·토큰량·입출력 길이·동시성·KV 캐시를 함께 측정한다. GPU 사용률이 높다고 사용자 지연이나 업무 처리량이 좋다는 뜻은 아니다. 긴 문맥과 긴 출력의 상한을 품질 요구와 함께 정하고, 필수 근거를 지우는 압축은 피한다.

용량 제어와 네트워크의 실제 범위

초당 요청 수(requests per second, RPS)/초당 질의 수(queries per second, QPS)는 요청 수이고 초당 토큰 수(tokens per second, TPS)는 토큰 처리량이며 동시 세션 수도 별개다. 평균 응답 길이만으로 피크 용량을 정하지 말고 입출력 분포·긴 요청·재시도·대기 열을 포함한다. 큐는 일시 급증을 완충하지만 처리 능력을 초과한 부하가 계속되면 대기가 누적된다. 최대 대기·만료·거절·dead-letter·멱등성을 정해야 한다. 근거: 공식 출처 AIP D2, Step Functions 오류 처리, 관찰성 — 지표·감사·호출 로그의 차이.

강좌의 Bedrock 프로비저닝 단위를 경보로 10 → 25 자동 확장한다는 사례는 현재 기본 제공 AutoScaling을 검증한 증거가 아니다. SageMaker 엔드포인트 확장을 일반 EC2AutoScaling 그룹·로드밸런서 구성과 동일하게 취급하지 않고 지원 리소스·정책/API를 확인한다. 다중 컨테이너 엔드포인트가 여러 리전에 자동 배치되는 것도 아니다. PrivateLink는 사설 연결 선택지이며 더 빠른 응답·데이터 레지던시·모든 내용 보호를 자동 보장하는 기능은 아니다. 리전별 모델·원문·캐시·로그와 실제 호출 경로를 함께 통제한다. PrivateLink와 네트워크 경계, 교차 리전 추론.

캐스케이드와 캐시의 성공 조건

작은 모델의 결과가 업무의 품질·형식·안전 기준을 충족할 때만 채택하고, 부족하면 큰 모델이나 사람에게 넘긴다. 입력의 복잡성에 따라 처음부터 한 모델을 고르는 라우팅(routing)과, 결과를 검사한 뒤 추가 모델을 호출하는 캐스케이드(cascade)는 다르다. 예제 구현의 문자열·영어 규칙 기반 복잡도는 다국어·짧지만 고위험인 요청을 충분히 판정하지 못할 수 있다. 총비용에는 작은 모델·에스컬레이션·검증·실패 재시도 비용을 모두 넣는다. 근거: 공식 출처 AIP D2, 지능형 모델 라우팅, 평가자 지표의 의미.

응답 캐시는 문서·정책 버전·언어·권한·개인화 변수에 맞아야 한다. 임베딩(embedding) 캐시는 원문 버전과 임베딩 모델 버전을 키에 포함한다. 프롬프트 캐싱(prompt caching)과 별개이고 어떤 캐시도 변경·권한 회수를 영원히 무시해서는 안 된다. 프롬프트 캐싱의 조건, Knowledge Bases 동기화.

예제 코드에서 확인한 운영 공백

SageMaker 예제의 ping이 모델 로드 이전에도 성공하고 첫 invocations에서 실제로 가중치를 로드하므로 서비스 준비 완료와 첫 추론 준비 완료가 다르다. 제3자 모델의 접근·라이선스·컨테이너 네트워크·다운로드 실패·양자화 지원도 필요하다. 입력 max_tokens의 범위검사·동시초기화·GPU 메모리·오류 정보 노출을 검토해야 한다. 모델을 온디맨드로 호출하는 예제와 경량 모델을 Lambda 내에 로드한다는 영상 표현을 같은 구현으로 혼동하지 않는다.

CloudFormation의 API 인증 NONE,광범위한 모델 권한, 주석뿐인 Lambda 코드, 마지막 권한 문자열 중단은 완성 프로덕션 구성의 증거가 아니다. Proxy 이벤트의 body와 event.query 파싱 계약, 모델 버전별 요청 형식, 응답 전체를 읽기 전의 시간 측정도 검토 대상이다. 코드의 메모리 256MB/30초·인스턴스·모델 ID는 교육 예시이며 현재 권장값이 아니다. 공식 출처 AIP D2, Converse 요청과 스트림, 대규모 모델 호스팅. 코드 실행·클라우드 배포·로그 설정은 전혀 하지 않았다.

2.3 기업 통합은 데이터·권한·업무 상태의 연결

레거시 어댑터의 입력과 출력

기존 시스템의 프로토콜·문자 인코딩·스키마·타임아웃·인증·오류 코드를 먼저 조사한다. API Gateway는 외부 요청을 받을 형식과 연결 대상을 정한다. Lambda 어댑터(adapter)는 요청 형식을 변환하고 업무 규칙을 검사하며, Step Functions는 여러 단계의 실행 상태를 조정할 수 있다. REST/HTTP API의 기능 차이와 통합 모드를 확인하고, 브랜드 도메인이나 요청 매핑이 존재한다는 이유로 모델의 업무 정확성을 보장하지 않는다. 입력은 검증한 업무 요청이고 출력은 기존 시스템이 해석할 수 있는 성공·실패·보류 상태와 근거여야 한다. 근거: 공식 출처 AIP D2, Converse 요청과 스트림, Step Functions 오류 처리.

자체 예시: 발주 내역 CSV의 일부 행만 모델에 보내고 전체 행의 이상 여부를 분석했다고 반환하면 계약 위반이다. 실제 처리 행·누락 범위·원본 위치·검증 결과를 표시한다. 신규 AI 경로를 모의 서비스·제한 트래픽에서 검증하고 기존 경로로 되돌아갈 수 있도록 배포한다. 문서 요약의 품질과 기존 시스템의 거래 정합성은 별도로 평가한다.

이벤트와 웹훅의 신뢰성

EventBridge는 규칙에 맞는 이벤트(event)를 지정한 대상으로 전달한다. 웹훅(webhook)은 외부 시스템이 보내는 호출을 받는 방식이다. 요청 원천 검증·서명·시간 창·재전송 방지·스키마 검사 후 업무 ID를 확정한다. 동일 이벤트 재수신은 같은 작업인지 확인하고 이미 실행한 부작용을 반복하지 않는다. 이벤트 수신 성공과 모델 처리 완료와 외부 시스템 변경 완료는 다른 상태다. 근거: 공식 출처 AIP D2, Step Functions 오류 처리, Knowledge Bases 동기화.

실패한 이벤트는 원인·재시도 횟수·처리 버전을 기록하고 복구 가능한 경우만 제한 재시도한다. 실패 메시지 대기열(dead-letter queue, DLQ)이 있어도 원인을 수정하고 안전하게 재처리하는 절차가 필요하다. FIFO 그룹의 순서 요구와 병렬성 절충을 정하고, 모든 업무를 단일 그룹에 넣어 병목을 만들지 않는다. 동기 웹훅의 제공자 제한 시간보다 생성이 길어질 수 있으면 접수 응답 → 비동기 상태·결과 전달 계약을 검토한다. 배치가 항상 나쁘거나 이벤트가 항상 빠르다는 일반 규칙은 없다.

동기화가 필요하지 않은 데이터도 구별하기

Glue/AppFlow/추출·변환·적재(extract, transform, load, ETL)은 선정한 소스·변환·증분 상태를 관리하는 수단이다. 북마크를 켰다고 모든 수정·삭제·업무 중복·모델 색인 정합성이 해결되는 것은 아니다. 데이터 소유자·원본 버전·변환 버전·삭제 전파·권한 변경을 추적한다. 양방향 통합은 어떤 시스템이 진실의 원천인지, 충돌 시 누가 우선하는지, 자기 갱신이 재이벤트를 만드는 루프를 어떻게 막는지 정의해야 한다. 근거: 공식 출처 AIP D2, Knowledge Bases 동기화, Glue Data Quality.

민감 정보를’특징’으로 변환했다고 반드시 비민감·익명 정보가 되는 것은 아니다. 희소 속성이나 결합 정보로 재식별될 수 있고 임베딩·요약·로그도 보호 대상이다. 데이터 경계 밖으로 나갈 수 있는지 업무·법률 기준으로 확인하고 필요한 최소 정보만 전달한다. 암호화 전송은 전송 허가를 새로 만드는 수단이 아니다.

인증·인가·사용량 제어의 층

기업 ID 페더레이션은 기존 사용자를 AWS 역할·클레임에 연결하는 과정이고 최소 권한 IAM은 클라우드 행동을 제약한다. Cedar/Verified Permissions는 앱의 principal/action/resource/context에 대한 정책 판정을 구현하는 선택지이며 앱이 판정 결과를 실제로 집행해야 한다. JSON 웹 토큰(JSON Web Token, JWT)에 부서가 있더라도 검증된 발급자·서명·유효 기간·대상 클레임과 서버 측 권한 규칙을 확인한다. API 키·사용 계획의 사용량 식별과 강한 사용자·리소스 인가는 혼동하지 않는다. 근거: 공식 출처 AIP D2, IAM 인증과 인가. 제품별 공식 한국어 지원 조건은 보강 조사 중이다.

보안 그룹·네트워크 접근 제어 목록(access control list, ACL)/사설 엔드포인트는 연결 경로, ACM/TLS는 전송 보호, 키 관리 서비스(AWS Key Management Service, KMS)는 키와 암호화 권한, 로그는 관측·감사에 관계한다. WAF가 연결된 지원 진입점의 검사를 모든 Bedrock 직접 호출의 보편 필터로 가정하지 않는다. 다중 리전 KMS 키를 사용해도 데이터가 모든 리전에 허용되는 것은 아니다. RAM이나 조건 키도 지원 리소스·서비스의 실제 범위를 확인해야 한다. PrivateLink와 네트워크 경계, Bedrock 데이터 보호.

온프레미스와 리전과 엣지를 나누기

AWS Outposts는 온프레미스 AWS 인프라, Local Zones는 특정 지역 가까이의 배치, Wavelength는 통신사 엣지와 관련된 선택지다. 어느 쪽도 모든 리전 서비스·모든 파운데이션 모델(foundation model, FM)이 그 위치에서 실행된다는 의미가 아니다. 모델 런타임·가속기·스토리지·제어플레인의 리전 의존성·장애 시 작동·라이선스를 확인해야 한다. Direct Connect/VPN/Transit Gateway는 연결 선택지이며 연결이 존재한다고 데이터 처리 위치가 온프레미스가 되지는 않는다. 근거: 공식 출처 AIP D2, PrivateLink와 네트워크 경계, 교차 리전 추론.

자체 예시: 원문이 시설 밖으로 나가면 안 되는 정비 기밀은 로컬 추론과 로그·캐시의 실제 위치를 함께 설계한다. 클라우드 FM을 VPN으로 호출하면서’온프레미스 처리’라고 표시해서는 안 된다. 리전 장애 시에도 허용되지 않은 지역으로 데이터를 보내는 폴백을 사용하지 않는다. 제품별 가용 인스턴스·로컬 서비스 전체 표는 미검증 잔여다.

CI/CD와 중앙 게이트웨이의 책임

코드·프롬프트·모델·어댑터·검색 색인·정책의 버전 조합을 아티팩트로 관리한다. 소스 → 빌드 → 보안·품질 시험 → 승인 → 제한 배포 → 운영 관찰 단계를 분리한다. 모델 품질 회귀와 배포 건강 검사를 같은 지표로 취급하지 않는다. 롤백은 앱 코드뿐 아니라 그 코드와 호환되는 모델·프롬프트·스키마까지 검토한다. 근거: 공식 출처 AIP D2, Model Registry, AWS AppConfig 구성 배포, 평가자 지표의 의미.

중앙생성형 AI(generative AI, GenAI)게이트웨이는 모델 추상화·인가·할당량·로그 마스킹·비용 계측·라우팅을 일관되게 적용하는 장점이 있지만 단일 장애점·권한 집중 위험도 생긴다. 테넌트 경계와 정책 실패 시 동작을 정하고, 사용자 원문을 무조건 집중 로그로 수집하지 않는다. X-Ray 샘플링은 비용·관측 절충이므로 전체 요청 감사를 대체하지 않는다. 자동 시정은 사전 정의된 안전 범위에 한정하고 불명·고위험 변경은 승인으로 넘긴다. 관찰성 — 지표·감사·호출 로그의 차이, 모델 호출 로깅.

예제 구현 지침의 실제 범위

아키텍처 목록은 5 구성 요소지만 실제 표시된 상세 코드는 API와 이벤트 처리 두 영역이고 마지막 CFN은 중간에 끝난다. 보안·환경 간 처리/CI-CD 전체 구현 완료 예제로 표시하지 않는다. API 입력의 model/department를 클라이언트 값 그대로 신뢰하거나 검증 전 원문 전체를 저장하는 것, 매 호출 무작위 ID/현재 시각을 멱등성 키처럼 쓰는 것, context.timestamp 같은 가정 필드, 원시 예외 반환을 검토해야 한다.

레거시 시뮬레이터는 API를 실제 호출하지 않고 요청 로그만 남긴다. 분석 예제도 원천 데이터를 조회하지 않고 소스 이름과 파라미터만 프롬프트에 넣으며 일부 문서 본문만 잘라 사용한다. 이를 완전한 분석 결과로 제공하면 안 된다. 이벤트 Lambda가 예외를 잡아 상태 500 문자열로 반환하면 호출 방식에 따라 플랫폼은 실행 성공으로 볼 수 있으므로 비동기 재시도/실패 메시지 대기열(dead-letter queue, DLQ) 계약을 따로 검증한다. CFN의 S3 알림 타입·필터·주석뿐인 코드·인가 리소스 미구현도 현행 스키마 대조가 필요하다. 공식 출처 AIP D2, Step Functions 오류 처리. 실습이나 수정 코드 실행은 하지 않았다.

추가 공식 한국어 조건 대조

API 키·사용량 계획은 인증·인가와 엄격한 비용 상한이 아니다은 REST API의 키가 인증·인가 대체가 아니며 사용 계획의 quota/throttle이 best-effort 라 초과될 수 있음을 직접 확인했다. 비용 상한을 절대로 지키는 차단 기능으로 사용하지 않는다. 키는 민감 정보를 담지 않고 실제 사용자·업무 리소스 인가는 별도로 구성한다. 이 조건은 2.4의 API 속도 제한 설명에도 적용한다.

Amazon Verified Permissions의 정책 평가와 애플리케이션의 집행 책임은 Verified Permissions의 Cedar 정책 스토어·스키마·인가 평가를 확인했다. 인증된 주체의 작업·리소스·컨텍스트에 대한 허용·거부를 앱 또는 미들웨어가 집행하며, 스키마 검증은 실제 요청 허용과 다르다. 지원 토큰·API의 상세 조건과 감사 로그 보존 범위는 별도 확인이 필요하다. IAM 실행 권한과 앱 역할의 분리를 유지한다.

Bedrock 프로비저닝된 처리량과 용량 변경 조건은 2.2 예약 용량 공백을 보강했다. 모델 단위(Model Unit, MU)는 모델별 입력·출력 토큰 처리 수준이지 공통 GPU 개수/RPS가 아니다. MU 방식 수정 설명과 토큰 방식의 입출력 토큰 수정 설명은 서로 다르며 10 → 25 자동 확장 사례를 현재 기본 제공 기능으로 채택하지 않는다. 동시에 모든 방식의 자동 확장이 절대 미지원이라고 단정하지 않는다. 약정 만료와 과금 종료는 같지 않고 지원 모델·리전·사용자 지정 모델 교체 조건을 확인해야 한다. 선택 탭·일부 정책 코드/API는 일부 미확인 범위다.

Outposts의 실행 위치에서는 일부 서비스의 로컬 실행과 더 넓은 리전 서비스 연결을 구분한다. 랙·서버, 세대, 리전에 따른 조건을 함께 확인한다. 로컬 앱이 리전의 모델을 호출하는 것과 모델 가중치를 로컬 컴퓨팅에 배치하는 것은 다르다. 특정 모델·GPU·통신 단절 시 운영은 확인이 더 필요하며, RDS 지원 표와 목록의 불일치도 남아 있다. 이 네 제품의 세부 조건 전체를 시험 필수 항목으로 확대하지 않는다.

2.4 API의 연결 성공과 업무 완료를 구별하기

동기·비동기·스트리밍은 다른 축이다

동기(synchronous) 방식에서는 호출자가 최종 결과를 기다린다. 비동기(asynchronous) 방식에서는 작업 접수와 완료 결과 전달을 분리한다. 스트리밍(streaming)은 생성되는 응답을 나누어 보내는 방식으로, 대화 기억이나 비동기 업무 상태를 자동으로 제공하지는 않는다. 요청의 시간 예산, 클라이언트 연결, 출력 검증과 실패 처리 요구를 기준으로 이 방식을 조합한다. 긴 문서는 먼저 접수 ID를 반환하고 처리 상태·저장된 결과를 권한 있는 사용자에게 전달할 수 있다. 짧은 질의는 검증된 응답을 바로 반환하는 방식과 비교한다. 근거: 공식 출처 AIP D2, Converse 요청과 스트림, Step Functions 오류 처리.

앱 계약은 request_id·사용자·테넌트·입력·메타데이터·허용 모델·기한을 받고 접수·진행·완료·실패·불명 상태를 돌려준다(자체 예). HTTP 202는 작업 접수이지 결과 품질 확인이 아니다. SQS 메시지 ID·업무 ID·Lambda 실행 ID를 같은 것처럼 사용하지 않고 레코드별 결과와 연결한다. 실패 시 일부 결과가 저장됐는지 확인하기 전에 전체 배치를 재시도하지 않는다.

스트림 조립과 사용자 표시

스트림은 청크 경계가 문장·문자·JSON 객체 경계와 일치한다고 보장하지 않는다. 프로토콜의 content block/델타·종료 이벤트와 사용량 메타데이터를 조립하고 최종 stopReason을 확인한다. 부분 도구 인수를 파싱 완료로 오인해 실행하지 않는다. 화면에는 생성 중·부분·검증 완료를 구별하고 사용자 취소·연결 끊김·최종 전달 실패를 처리한다. 근거: 공식 출처 AIP D2, Converse 요청과 스트림.

WebSocket은 양방향 연결, SSE는 서버에서 클라이언트로 이벤트 전송하는 선택지다. 연결 ID와 사용자 권한을 묶고 재연결 이후 남의 세션 결과를 받지 않도록 한다. SSE 이벤트 ID가 있다고 서버 측 재생 버퍼나 모델의 생성 재개 기능이 자동으로 생기는 것은 아니다. 중간 실패 후 다시 전체 생성하면 문장이 중복되거나 기존 내용과 충돌할 수 있으므로 새 응답 버전·재시작을 명확히 표시한다. API Gateway의 청크 전송은 정확 API 유형·통합 모드·지원 조건을 확인하고 헤더 하나 추가로 모든 API가 스트리밍된다고 가정하지 않는다.

의료 가상 사례의 부분 출력만 보고 임상 행동을 실행해서는 안 된다. 고위험 업무에는 최종 검증, 근거 대조, 권한 있는 전문가의 검토를 별도 승인 조건으로 둔다.

재시도는 시간·호출 예산 안에서만

연결·읽기·전체 요청 시간 초과를 구분하고 전체 기한에서 재시도·백오프·후처리 예산을 배분한다. SDK 재시도와 앱 재시도가 겹치면 시도 횟수가 곱으로 늘 수 있다. 일시적 429/서비스 오류라도 서비스가 제시한 대기 조건과 멱등성·부작용 가능성을 확인하고, 형식·권한 오류는 원인을 고치지 않은 채 반복하지 않는다. 근거: 공식 출처 AIP D2, Step Functions 오류 처리, API사용계획보충.

자체 산술 예: 전체 허용 시간 6초인데 각 시도 timeout5 초를 3 번 주면 백오프를 빼도 최악 경로 15초로 예산을 넘는다. 동기 기한을 넘는 업무는 비동기로 넘기거나 안전하게 거부하는 정책이 필요하다. 가시성 시간 초과는 SQS 메시지 숨김 시간이고 원격 모델 호출의 취소 시간이 아니다. 처리 실패를 잡아 로그만 남기면 이벤트 소스가 성공으로 인식할 수 있으므로 재처리·부분 배치 응답 계약을 검증한다.

강좌 수치의 해석과 관측

강좌 관련 항목에는 timeout 최대 120초·간단요청 1530초, 백오프 100ms와 35회, 연결풀 1020개, 대기열가시성 515분, 검증토큰 4096,버퍼 520 청크/100500ms, 회로표본 10회·실패 50%같은 설계 예시가 등장한다. 강좌 관련 항목에는 별도로 동기 45초·가시성 10분이 등장한다. 서로 다른 시나리오의 값이며 현재 AWS 전체의 기본 값·상한·모든 업무 추천 값으로 암기하지 않는다. 신뢰도 0.50.9 같은 값은 검증한 확률 보정과 오류 비용 없이 안전성 게이트가 될 수 없다. 필요조건은 실제 서비스/API·모델·SLO·부하에 맞춰 정한다. 근거: 공식 출처 AIP D2.

관찰성(observability)을 확보하려면 요청 수·토큰(token) 수·p50/p90/p99 지연 시간(latency)을 각각 측정한다. 최초 청크가 도착한 시간과 최종 완료 시간, 완료되지 않은 스트림(stream), 재시도(retry)·폴백(fallback) 비율, 비용, 실제 성공한 업무 수도 구분한다. 추적 주석(trace annotation)에 환자 정보나 프롬프트 전문을 무조건 넣지 않는다. 필요한 민감 정보만 수집하고 보존 기간과 읽기 권한을 정한다. 모델 호출 로깅, 관찰성 — 지표·감사·호출 로그의 차이.

라우터는 허용 목록을 먼저 적용한다

정적 설정은 허용 모델·기본 경로를 고정하고 동적 라우팅은 콘텐츠·부하·품질·비용 지표를 이용해 후보를 고른다. AppConfig와 Systems Manager Parameter Store는 각각의 구성 서비스이며 Parameter Store를 AppConfig의 기능으로 설명하지 않는다. 사용자 헤더의 model-preference는 선호일 뿐 권한 확대 요청을 자동 승인하는 수단이 아니다. 허용 리전·모달리티·데이터 등급을 먼저 제약하고 지표 최적화를 적용한다. 근거: 공식 출처 AIP D2, AppConfig 구성 배포, 지능형 모델 라우팅.

A/B 비율 5~10%는 교육 예시이고 통계적 유의성·표본 구성·위험을 보장하지 않는다. 모델 폴백은 업무를 정당하게 완료할 수 있는 경로만 허용한다. 의료 전용 모델이 실패했다고 범용 모델을 무조건 쓰는 것은 안전한 기능 축소가 아닐 수 있다. 품질 기준이 충족되지 않으면 정적 안내·보류·사람 인계가 적절하다.

예제의 프로토타입 공백

동기예제는 Anthropic과 Titan을 선택하면서 동일 요청·응답 스키마를 사용하므로 모델별 어댑터가 필요하다. 비동기 생산자는 작은 문서 분기가 pass이고 job_id를 큐 메시지와 연결하지 않는다. 소비자는 배치 전체의 context.aws_request_id로 결과키를 만들어 레코드별 결과가 덮일 수 있으며 예외를 삼키는 것만으로 실패 메시지 재전달이 보장되지 않는다. callback_url을 SNS 내용에 넣는 것은 실제 웹 훅 전달 구현이 아니다.

WebSocket 예제는연결 ID 저장만 보이며 사용자인가·메시지 상관관계·중도 취소를 추가 검증해야 한다. 프론트의 오류 문자열 HTML 삽입은 신뢰 경계를 점검한다. 회로 클라이언트 코드는 while 조건 중간에서 끝나며 분류 기의 고정 0.85는 실측 신뢰도가 아니다. 문자열 부분 일치·앞 1000 자만 분류한 결과를 전체 문서 정확도 보장으로 쓰지 않는다. 공식 출처 AIP D2, Step Functions 오류 처리. 코드실행·HTML 파일 작성·리소스 생성은 하지 않았다.

2.5 통합 패턴은 화면에서 업무 확정까지의 계약이다

2.5.1 API가 반환해야 하는 것은 문장만이 아니다

생성형 AI(generative AI) API는 입력 스키마(input schema)와 출력 문자열 외에도 생성 상태·소요 시간·토큰(token) 사용량·오류를 어떻게 반환할지 정해야 한다. 일반적인 CRUD 응답처럼 성공 코드 하나만 보고 업무가 끝났다고 판단하면 부분 생성, 사용자 취소, 원격 업무 변경 후 응답 유실을 놓친다. OpenAPI는 앱 인터페이스의 명세다. 명세가 존재한다고 모델의 사실성이나 백엔드 구현의 일치를 보장하지 않는다.

자체 설계 흐름은 ① 신원·대상 권한·입력 형식 확인 ② 모델과 토큰·시간 예산 결정 ③ 업무 ID와 요청 버전 부여 ④ 호출 및 스트림 조립 ⑤ 결과 스키마·근거 검사 ⑥ 상태와 사용량 반환이다. 입력은 질문·허용된 첨부·세션·업무 참조이고, 출력은 생성중·검토 대기·완료·실패·결과불명 등의 상태, 텍스트·구조화 결과, 오류 코드, 사용량 및 출처다. 이 필드 목록은 자체 앱 계약 예이지 모든 AWS API의 실제 필드명이 아니다. 권한 거부와 형식 오류, 일시적 제한과 타임아웃을 서로 다른 복구 경로로 표현한다.

토큰 예산에는 시스템 지침·대화·검색 근거·도구 스키마 등 입력과 예약할 출력이 모두 들어간다. 앱이 글자 수나 다른 모델의 토크나이저로 계산한 값을 정확한 모델 사용량으로 표시해서는 안 된다. 결과 메타데이터의 실제 사용량과 사전 추정값을 구분하고, 최종 모델/API의 지원 계수 방법을 별도로 확인한다. 입력만 한도까지 채우면 출력 여유가 없어질 수 있다. 컨텍스트 길이, 최대 출력, 속도 할당량, 앱의 비용 제한은 서로 다른 제한이다.

WebSocket은 양방향 메시지 연결이고, 이 문맥의 SSE는 Server-Sent Events다. 서버 측 암호화(Server-Side Encryption)와 약자가 같아도 기능은 전혀 다르다. 강좌의 혼동 표현을 용어 정의로 채택하지 않는다. 전송 프로토콜과 Bedrock의 모델 이벤트 스트림도 같은 층이 아니다. 중계 앱은 content block 별 델타·종료·오류·사용량을 해석해 화면 프로토콜로 전달한다. 연결이 살아 있다는 ping과 모델이 실제 진전하고 있다는 증거도 다르다.

429에 즉시 재시도를 반복하는 것은 보편 권고가 아니다. 제공되는 Retry-After 등 대기 조건, 전체 기한, 백오프·지터·최대 횟수·멱등성 및 이미 소비한 비용을 고려한다. 실패 응답을 받지 못했어도 원격 작업은 성공했을 수 있어 상태 조회 없이 쓰기 도구를 반복하면 안 된다. Lambda 권한 부여자로 토큰 한도를 검사한다는 강좌 언급은 정확 API 유형·입력 가용성·캐시와 집행 위치의 공식 검증이 남아 있다. 여기서는 권한 부여자가 임의 본문 토큰을 항상 검사할 수 있다고 보증하지 않는다. 근거: 강좌 관련 항목, Converse 요청과 스트림 ·Step Functions 오류 처리, 사용계획의 별도 한계.

2.5.2 접근 가능한 화면과 시각적 흐름도에도 검증이 필요하다

Amplify의 선언형 접근은 원하는 화면·연결 구조를 표현하는 개발 관점이다. OpenAPI는 서비스 간 계약, Bedrock Flows는 모델·검색·함수 등의 처리 노드를 연결하는 관점이다. 세 도구를 같은 UI 생성 기능으로 묶지 않는다. Flows의 출력 스키마가 다음 노드 입력과 일치하는지 검증하고 오류 분기와 사용자 피드백 수집 위치를 정한다. 초안 테스트, 고정된 게시 버전, 앱이 호출하는 별칭은 다른 상태다. 별칭을 바꿨다는 사실만으로 새 버전의 품질 승인이 완료되는 것은 아니다(Flows 버전과 별칭).

멀티모달 입력은 파일 형식·크기·권한·필요한 전처리·모델 지원을 확인한 뒤 보낸다. 원본 참조와 변환 결과를 묶어 광학 문자 인식(optical character recognition, OCR) 누락이나 이미지 전처리 손실을 추적한다. 텍스트 일부만 추출했으면 전체 첨부를 이해했다고 표시하지 않는다. 업로드 완료, 전처리 완료, 생성 완료, 사람 확인을 별도로 보여 주면 사용자가 어디에서 기다리는지 알 수 있다.

점진 렌더링(progressive rendering)은 도착한 내용을 작은 단위로 표시해 사용자가 느끼는 대기 시간을 줄이는 방법이다. 너무 잦은 갱신은 레이아웃·보조기술 알림 부담을 늘리고, 너무 큰 버퍼는 최초 표시를 늦춘다. 시작 응답·청크 간격·최종 완료를 각각 측정하고 사용자 취소와 재연결 이후 중복 표시를 처리한다. 화면에 보인 부분 문장은 아직 검증 완료된 답이 아니므로 고위험 업무의 실행 버튼과 분리한다. 렌더링이 빨라졌다고 모델 추론 비용이나 총 생성 시간이 반드시 줄어드는 것은 아니다.

접근성은 ARIA 속성 한 개를 넣는 것으로 끝나지 않는다. 키보드로 입력·첨부·취소·재시도에 도달할 수 있는지, 초점이 뜻밖에 이동하지 않는지, 스크린리더가 진행·실패·완료를 구분하는지 확인해야 한다. 스트림의 모든 글자를 매번 읽게 만들기보다 상태와 의미 단위 알림을 설계한다. 색상만으로 오류를 표현하지 않고, 출처·검토 여부·불확실성은 화면과 보조기술 모두에 전달한다. ARIA/키보드 상세 구현을 실제 렌더러에서 시험한 것은 아니다.

응답 캐시는 동일 질문이라는 조건만으로 공유하지 않는다. 사용자·테넌트·문서 ACL·정책·원문 버전·언어·개인화가 맞아야 하고 권한 회수와 문서 수정 시 무효화가 필요하다. 의미 유사도가 높아도 다른 계약이나 날짜의 답변이면 재사용하면 안 된다. 자체 예: 사용자가 최근 변경된 보상 규정을 묻는데 오래된 답을 빠르게 표시하는 화면은 지연 지표는 좋아도 업무 품질은 나빠진다. 근거: 강좌 관련 항목, Converse 요청과 스트림 ·Flows 버전과 별칭 및 2.4 스트림 설명.

2.5.3 업무 자동화는 추출·제안·확정을 분리한다

고객 관계 관리(customer relationship management, CRM) 이벤트 → Lambda → 감정 분석·기록 개선은 이벤트를 받아 필요한 고객 자료를 조회하고 분석 또는 수정 초안을 만드는 연결 패턴이다. 감정은 고객 의도의 확정 사실이나 자동 불이익 결정 근거가 아니다. 입력은 검증된 이벤트 ID·대상 기록·변경 버전이고, 출력은 분석 결과·근거·수정 제안·저장 상태다. 로그에 ‘CRM 업데이트’라고 기록한 것과 CRM API의 실제 저장 결과를 검증한 것은 다르다.

문서가 여러 개면 Step Functions가 병렬 분석과 집계를 조정할 수 있다. 문서마다 원본 ID·버전·처리 범위·성공·실패·추출 결과를 보존하고 집계 게이트에서 누락과 모순을 검사한다. 일부 분기의 성공만으로 전체 사건을 완료 처리하지 않는다. 실패 분기만 안전하게 재처리할 수 있도록 부작용을 멱등하게 만들고, 재시도가 불가능하거나 결과가 불명확하면 검토 대기로 보낸다. Map/Parallel 등 정확 상태별 입력·출력 형식과 크기 제한은 별도 제품 문서 검증 대상이다(Step Functions 오류 처리).

Q Business의 커넥터는 원천 문서를 가져오는 연결, 인덱스는 검색 가능하게 만든 표현, ACL은 누가 문서를 볼 수 있는지에 관한 제약, 새로고침은 변경을 반영하는 운영 주기다. 커넥터를 설정했다고 모든 변경·삭제·권한 회수가 즉시 반영되지는 않는다. 사용자 신원과 문서 접근권한의 연결을 확인하고 검색·답변·캐시 경로에서 같은 경계를 유지해야 한다. 권한이 없는 근거를 가져온 다음 답변에서 가리는 설계를 충분한 보호로 보지 않는다. 개별 커넥터의 ACL/증분·삭제·동기화 기능표는 미검증이다.

Amazon Bedrock Data Automation(BDA)의 추출은 문서 등 비정형 자료를 업무에 사용할 수 있는 결과로 바꾸는 처리다. 원본 → 전처리·추출 → 형식·필수 필드 검사 → 업무 규칙·다른 근거 대조 → 필요한 인간 검토 → 업무 저장의 경계를 둔다. 추출 신뢰 점수와 법률적 타당성, 보험의 지급 가능성은 다른 질문이다. 불명 필드를 임의로 채우지 않고 원본 위치를 연결한다. 현재 지원 형식·blueprint/API·언어·리전·한도는 강좌 개요만으로 확정하지 않는다.

양방향 동기화에는 원본의 소유 시스템, 수정 버전, 충돌 정책과 감사가 필요하다. AI가 CRM을 갱신해 다시 이벤트가 발생하면 자기 결과를 반복 처리하는 루프가 생길 수 있다. 상관 ID·변경 원인·이미 처리한 버전을 구분하고 동시 수정 시 덮어쓸지 병합할지 사람에게 보낼지 정한다. 감사에는 누가 어떤 근거와 승인으로 무엇을 바꿨는지와 실제 결과를 남긴다. 처리량(throughput) 증가만이 성공 기준은 아니므로 도입 전 기준선 대비 처리 시간·재작업·오탐·검토 부담·완료 사건당 비용을 비교한다. 같은 사건 난이도·관측 기간인지, 표본 변동과 통계적 불확실성을 고려했는지 확인한다. 근거: 강좌 관련 항목, Step Functions 오류 처리 ·평가자 지표의 의미.

자체 예: 수리비 증빙에 두 통화가 섞이면 문서 추출값을 단순 합산하지 않고 통화·계약 적용일을 검토한다. 누락된 영수증이 있으면 완료 보고 대신 ‘자료 보완 대기’를 반환한다. 이는 실제 보험사 운영 결과나 강좌의 추가 사실이 아닌 설명용 사례다.

2.5.4 Q Developer의 산출물과 검증 증거를 나눈다

Q Developer는 코드 작성·리팩터링·API 통합 패턴·테스트 초안·프로파일링 해석·코드 검토·개발 지식 탐색을 돕는 개발 보조로 다룬다. Q Business의 기업 문서 검색·업무 지식과 역할이 다르다. 이름에 Q가 들어간다고 동일한 데이터 연결이나 권한 모델을 가진다고 가정하지 않는다. 세부 지원 IDE/언어·기능·요금·자동수정 권한은 이 노트에서 검증하지 않았다.

입력은 필요한 코드와 요구사항, 재현 가능한 오류·성능 증거, 허용된 개발 문맥이다. 출력은 제안된 변경과 근거이며 ‘검증된 수정’이 아니다. 개발자는 요구와 인터페이스를 고정 → 변경 diff 검토 → 독립적인 기대 결과·테스트 → 보안·종속성·계약 검사 → 성능 측정 → 승인된 배포 순으로 검증한다. 테스트도 같은 생성기가 만들었다면 구현과 같은 오해를 공유할 수 있어 정상 경로 외에 잘못된 형식·권한 거부·경계 길이·부분 실패·중복 요청을 별도 설계한다.

리팩터링은 구조를 개선하면서 외부 동작을 유지하는 목표다. 모델 호출 패턴을 짧게 고치는 과정에서 오류나 스트림 처리를 생략하면 동작이 달라진다. 프로파일링 제안 역시 측정된 병목과 대조해야 한다. 네트워크 대기가 원인인데 문자열 처리만 최적화하면 체감 개선이 없다. 생산성은 생성 줄 수가 아니라 검토·재작업을 포함한 전달시간·결함률·유지보수성으로 평가한다.

소스·로그를 도구에 제공할 때 비밀키·고객 원문·내부 규정의 전달 허가와 최소화를 확인한다. 생성 코드의 라이선스·취약한 의존성·과도한 권한·하드코딩을 검토하며 개발 보조의 설명을 배포 승인으로 간주하지 않는다. 자체 예: SDK 호출 예제에 존재하지 않는 필드가 있으면 문법 통과와 무관하게 계약 검증에서 막아야 한다. 근거: 강좌 관련 항목의 개발 생산성 범위와 도구 실행 책임의 실제 실행 책임; 운영 적합성 판정은 독립 해설이다.

2.5.5 프레임워크·상태 머신·체인을 목적에 맞게 조합한다

Strands/Agent Squad는 에이전트 역할·도구 사용·조정의 프레임워크 관점, Bedrock Agents는 관리형 에이전트 호출·구성 관점, AgentCore는 실행·메모리·연결·정책·관측의 플랫폼 관점이다. Step Functions는 명시적인 업무 상태·분기·실패를 조정한다. 이름을 함께 쓰는 것과 각 SDK를 실제 사용한 것은 다르다. 예제 구현의 invoke_agent는 그 자체로 Strands SDK 검증 증거가 아니다(AgentCore 구성요소와 MCP ·도구 실행 책임).

자체 처리 예는 사건 접수 → 허용 자료 검색 → 전문 역할별 의견 → 근거·충돌 검사 → 권한 있는 최종 판단 → 업무 반영이다. 위임 입력에는 사건 ID·허용 범위·도구·기한·출력 계약을 넣고, 출력에는 검토 범위·근거·미해결 쟁점·권고와 실패 상태를 담는다. 핸드오프 때 원문 전체를 무조건 복제하지 말고 필요한 문맥과 검증 가능한 참조를 전달한다. 서로 다른 에이전트의 의견이 일치해도 같은 잘못된 원천을 썼다면 독립 검증이 아니다.

프롬프트 체인(prompt chain)은 앞 단계의 결과를 다음 단계에 입력하는 구조다. 각 단계에서 입력 형식과 필수 정보를 검사하고 원문·출처·버전·미해결 조건을 보존해야 한다. 이를 생략하면 요약 단계에서 빠진 사실을 뒤 단계가 확정 사실로 취급한다. 각 단계가 짧아졌다는 이유로 총비용이 줄었다고 단정하지 않는다. 반복 호출·문맥 중복·재검색·실패 재실행 비용과 전체 지연을 합산한다. 모델이 다음 도구를 동적으로 고르는 루프에는 호출 수·시간·비용·반복 실패 종료 조건을 추가한다.

동적 검색 증강 생성(Retrieval Augmented Generation, RAG)은 현재 질문·중간 결과에 맞춰 다시 검색하고, 리랭킹은 후보 근거의 우선순위를 다시 정한다. 둘 다 권한·최신성·문서 버전을 먼저 제한해야 한다. 리랭크 점수가 높다고 사실이 참이거나 답변 전체가 충분한 것은 아니다. 정보가 부족하면 재질문 또는 검토로 넘어가며 답을 만들기 위해 검색 경계를 넓히지 않는다. A/B 피드백은 같은 기준으로 정확성·완전성(Completeness)·충실도(Faithfulness)·업무 결과·비용을 비교해야 한다(평가자 지표의 의미). 사용자 만족과 근거 충실도는 서로 다른 지표다.

EventBridge로 새 정보 도착·검토 결과 이벤트를 받아 흐름을 재개할 수 있지만 중복·순서 지연·만료 사건을 처리해야 한다. 이벤트 수신은 판단 완료나 외부 변경 성공이 아니다. 상태 머신의 사건 버전을 확인한 뒤 재개하고 이미 확정된 사건을 다시 실행하지 않는다. 회복은 정확한 체크포인트부터 검증하여 진행하고 불명 결과는 사람에게 확인한다. 구체 SDK 핸드오프·메모리 일관성·이벤트 전달 옵션은 공식 세부 검증 잔여다.

2.5.6 문제 해결은 동일 요청의 증거를 연결하는 작업이다

Logs Insights는 로그를 필터·집계하여 실패 패턴과 지연을 찾는 도구이고 X-Ray는 요청 경로의 구간을 연결해 어디에서 시간을 썼는지 좁히는 관점이다. CloudWatch 수치 지표·CloudTrail API 감사·모델 호출 본문 로깅도 서로 다르다. 하나의 설정이 모든 프롬프트·업무 변경·추적 구간을 자동 보존해 준다고 가정하지 않는다(관찰성 — 지표·감사·호출 로그의 차이 ·모델 호출 로깅).

조사 입력은 사용자 증상과 시간창·요청 ID·배포·프롬프트·모델 버전이다. 관련 로그를 필터 → 오류 코드·재시도·도구·검색 지연 분리 → X-Ray 구간·주석과 연결 → 변경 전후 비교 → 안전한 재현 → 수정과 회귀 검증 순으로 좁힌다. 출력은 확인된 원인과 아직 가설인 항목, 영향을 받은 범위, 재현·수정 증거다. Q Developer 제안은 가설이나 패치 후보이지 운영 로그의 사실을 대신하지 않는다. 샘플링된 추적에 기록이 없다는 이유로 사건이 없었다고 판단하지 않는다.

프롬프트 버전 레지스트리는 어떤 모델·변수·설정 조합이 호출됐는지 연결하는 기준이다. 버전 고정은 재현에 필요한 조건이지 같은 응답이 항상 나오는 보장은 아니다. 검색 원문·색인·도구 결과·앱 버전·정책도 함께 기록해야 한다(프롬프트 관리). 로그의 상관 ID에는 신뢰 가능한 서버 발급값을 사용하고, 사용자가 넣은 requestMetadata를 인증된 주체의 증거와 혼동하지 않는다.

합성 모니터링(synthetic monitoring)은 통제된 테스트 요청으로 핵심 처리 경로를 주기적으로 확인하는 방식이다. 비민감 고정 자료와 쓰기 없는 경로로 시작하고, 실제 업무 부작용이 필요한 시험은 격리·허가·정리 절차를 별도로 둔다. 지연·오류만 감시하면 잘못된 근거를 유창하게 답하는 문제를 놓칠 수 있어 기대 결과와 거부 조건도 검사한다.

엔드투엔드 로깅은 모든 원문을 무조건 수집한다는 뜻이 아니다. 프롬프트·고객자료·출력·도구 결과가 민감할 수 있어 수집 범위·마스킹·암호화·접근권한·보존·삭제·감사 책임을 먼저 정한다. 검색 가능한 X-Ray 주석에 고객 본문이나 자격정보를 넣지 않는다. 운영 탐색용 지표와 필요한 감사증거를 구분하고 저장·조회·추적량 비용도 관리한다. 로그를 꺼도 이미 저장된 데이터가 삭제되는 것은 아니다(모델 호출 로깅).

교육 수치와 보험청구 가상 사례를 해석하는 법

보험청구에서는 자료 조회와 사실 추출을 자동화하더라도 지급 같은 고위험 판단은 계약·근거·권한 있는 사람의 판단과 분리할 수 없다. 월간 사건 수만으로 순간 트래픽이나 필요한 연결 수를 정할 수도 없다. 사건당 문서량·재검토·피크 분포·토큰 및 완료시간이 추가로 필요하다. 위 수치로 현재 가격이나 용량을 역산하지 않았고 성능 실측으로 보고하지 않는다.

예제 구현의 주의점과 연습의 미완료 경계

위 구현 주의점은 실행된 실습의 결과가 아니다. 실제 적용 전에 API 계약, 권한, 오류 처리와 결과를 검증해야 한다.

구현 범위와 구체적인 추가 검증

문서 자동화와 개발 보조에서 검증 책임 찾기

Amazon Bedrock Data Automation(BDA)은 문서·이미지·영상·음성 같은 비정형 자료에서 업무에 사용할 구조화된 정보를 얻는 관리형 선택지다. 여러 모달리티를 각기 다른 분석 서비스로 연결하는 부담을 줄일 수 있다. 다만 ‘추출됨’과 ‘업무상 유효함’은 다르다. 원문 위치·근거와 불확실성을 남기고, 필수 항목·통화·기간·다른 기록과의 일치를 확인한 뒤 업무 시스템에 반영한다.

자체 예시로 사진과 영수증이 함께 들어오는 수리 신청은 자료를 사건 ID로 묶고 추출 결과를 검증한다. BDA 같은 통합 경로와 Textract·Transcribe 등을 따로 조합하는 경로는 필요한 출력, 지원 입력, 제어 수준과 운영 부담으로 비교한다. 자료가 없는데 모델이 채운 금액은 추출값으로 받아들이지 않는다. 지원되는 입력·출력 구성과 제품별 한도는 도입 시 확인한다.

Amazon Q Developer의 공개 문서는 코드 설명·완성·생성·개선·보안 취약점 검사 등을 개발 보조 기능으로 설명한다. 이 기능은 운영 중인 앱의 인증·인가를 대신하지 않는다. 리팩터링으로 오류 처리나 권한 검사가 사라지지 않았는지 독립 테스트로 확인한다. 검토·재작업을 포함한 전달 시간과 결함률이 생산성 지표이며 생성 코드 줄 수만으로 성과를 판단하지 않는다. 해당 문서에는 IDE 플러그인 지원 종료 안내와 Kiro 안내가 있으므로 개념 학습을 특정 플러그인의 현재 도입 권고로 읽지 않는다.

근거: BDA 공식 개요, Q Developer 공식 개요. 기존 업무 통합 해설의 제품 근거를 보강했으며 실제 API 실행·클라우드 배포를 검증한 것은 아니다.

상황형 자기점검

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

1. 응답이 끊긴 부품 주문

에이전트가 주문 도구를 호출한 뒤 타임아웃이 났다. 공급자 시스템에서 주문이 생성됐는지는 아직 모른다. 중복 발주를 막는 다음 행동은?

• A. 멱등성 키와 공급자 상태를 조회해 결과를 확인한 뒤 재시도 여부를 정한다
• B. 다른 주문 ID로 즉시 재호출한다
• C. 모델이 성공이라고 말하면 완료로 기록한다
• D. 실패로 단정하고 아무 이력도 남기지 않는다

2. 가중치가 들어가도 부족한 메모리

모델 가중치는 GPU 메모리에 들어가지만 긴 대화의 동시 요청이 늘면 메모리 오류가 난다. 가장 타당한 원인과 조치는?

• A. 상태 검사 제한 시간만 늘려 메모리 부족을 해결한다
• B. KV 캐시·버퍼·동시 요청 메모리를 포함해 예산을 다시 잡고 길이·동시성을 제어한다
• C. 가중치가 적재됐으므로 GPU 메모리 원인은 배제한다
• D. 디스크 용량만 늘리면 GPU 메모리가 같은 만큼 늘어난다

3. 비동기 이벤트의 중복

외부 CRM이 같은 계약 변경 이벤트를 재전송할 수 있다. AI 요약과 내부 업무 상태 갱신은 수십 초 걸린다. 적절한 통합은?

• A. 이벤트마다 새 ID를 만들어 무조건 갱신한다
• B. 웹훅에 적힌 부서명을 곧바로 권한으로 사용한다
• C. 원천·스키마를 검증하고 이벤트 ID로 중복을 통제하며 접수와 완료 상태를 분리한다
• D. HTTP 접수 응답을 업무 갱신 성공으로 기록한다

4. 아직 완성되지 않은 도구 인수

스트림에 도구 호출 JSON의 일부가 도착했다. 주문 대상과 수량 필드는 아직 완성되지 않았다. 올바른 API 처리 방식은?

• A. 첫 청크에 도구 이름이 있으므로 즉시 실행한다
• B. 연결이 끊겨도 부분 응답을 성공으로 저장한다
• C. 스트리밍을 사용하면 비동기 작업 조회가 필요 없다고 일반화한다
• D. 이벤트를 올바르게 조합하고 종료·스키마·권한을 확인한 뒤 도구를 실행한다

5. AI가 제안한 코드 변경

개발 보조 도구가 기존 서비스를 수정하는 코드를 제안했다. 컴파일은 되지만 인증 분기와 예외 처리를 바꿨다. 병합 전에 필요한 것은?

• A. 변경 의도를 검토하고 단위·통합·보안 테스트로 권한과 실패 경로를 확인한다
• B. AI가 만들었으므로 사람 리뷰를 생략한다
• C. 개발 도구의 생산성 기능을 운영 API 인증 대신 사용한다
• D. 테스트를 지워 빌드만 통과시킨다

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