비슷해 보이는 기술도 바꾸는 대상과 맡는 역할이 다르면 서로 대신할 수 없다. 이 장에서는 AIF-C01의 기초 개념부터 AIP-C01의 검색, 도구 실행과 운영 설계까지 비교한다. 각 표를 읽을 때는 ‘무엇을 해결하는가’와 ‘무엇은 별도로 확인해야 하는가’를 함께 살핀다. 영어 명칭과 번역 차이는 한영 용어 사전에서도 확인할 수 있다. 아래 내용은 개념 비교이며 전체 제품 사양이나 가격표는 아니다.
D3~D5 최종 혼동 방지
| 비교 | 구별 조건·상세 근거 |
|---|---|
| 개인 식별 정보(personally identifiable information, PII) 탐지, 보호 대상 건강 정보(protected health information, PHI) 탐지와 익명화(anonymization) | 정보의 위치와 유형을 찾는 것과 개인을 다시 식별하지 못하도록 바꾸는 것은 다르다. 지원 언어, 반환 위치와 레이블, 법적 판단 요건을 각각 확인한다. 3.2 |
훈련에 사용하지 않음, 데이터 미보존과 store=false | 모델 훈련에 사용하지 않는다는 조건이 모든 저장을 금지한다는 뜻은 아니다. 모델, 프로젝트 모드, 안전 검토와 애플리케이션 로그의 데이터 보존(data retention) 조건을 따로 확인한다. 보존 조건 |
| 사용자 설명, 에이전트 추적(agent trace)과 인과관계의 증거 | 설명문이 실제 내부 계산을 그대로 보여 주는 것은 아니다. 공개 가능한 근거와 실제 실행 기록을 확인하며, 추적 기록도 원인과 결과를 자동으로 입증하지는 않는다. 3.4 |
입력 토큰 계산(CountTokens)과 출력 토큰 예산(output token budget) | 같은 모델에 보낼 입력의 토큰 수를 계산하는 것과 앞으로 생성할 출력 길이를 예측하는 것은 다르다. 출력에는 예상량과 상한을 따로 정한다. 4.1 |
| 프롬프트 캐싱(prompt caching)과 응답 캐시(response cache) | 프롬프트 캐싱은 반복 입력 접두사를 처리한 계산을 재사용하며 모델 호출은 남는다. 응답 캐시는 완성된 답을 재사용하므로 호출을 생략할 수 있지만 권한과 최신성을 다시 확인해야 한다. 4.1 |
| SageMaker 자동 확장(auto scaling)과 EC2 Auto Scaling group(ASG) | SageMaker의 관리형 프로덕션 변형(production variant)은 Application Auto Scaling으로 조절한다. EC2에 직접 모델 서버를 호스팅하고 ASG로 인스턴스를 늘리는 설계와 구분한다. 4.2 |
| 골든 데이터세트(golden dataset), LLM 평가자(LLM-as-a-judge)와 업무 성공 | 평가 데이터의 기준 시점과 평가자 판정의 신뢰성을 확인한다. 좋은 답변 점수를 받았더라도 실제 작업이 승인대로 실행됐는지, 원치 않는 변경이 발생하지 않았는지는 별도로 검증한다. 5.1 |
| JSON 스키마 유효성(schema validity), 정답 여부와 접근 권한 | JSON이 스키마를 통과했다는 것은 정해진 구조를 갖췄다는 뜻이다. 내용이 사실인지, 사용자에게 공개해도 되는지는 별도 검사다. 5.2 |
AIF에서 먼저 구별할 용어
| 비교 | 구별 기준 | 흔한 혼동 |
|---|---|---|
| 인공 지능(artificial intelligence, AI), 기계 학습(machine learning, ML), 딥 러닝(deep learning) | AI는 지적 과업을 수행하는 기술을 넓게 가리킨다. ML은 데이터에서 패턴을 학습하며, 딥 러닝은 여러 층의 신경망을 사용하는 ML 방법이다. | 모든 AI가 대규모 언어 모델(large language model, LLM)인 것은 아니다. |
| 모델(model)과 알고리즘(algorithm) | 모델은 학습으로 얻은 구조와 파라미터를 이용해 결과를 내고, 알고리즘은 학습하거나 처리하는 방법을 정한다. | 이미 준비된 모델의 API를 호출하는 것은 모델을 훈련하는 것과 다르다. |
| 지도 학습(supervised learning), 비지도 학습(unsupervised learning), 강화 학습(reinforcement learning) | 각각 정답 레이블, 데이터의 구조, 행동에 따른 보상을 이용한다. | 데이터가 표인지 이미지인지는 학습 방법과 별도로 구분한다. |
| 분류(classification), 회귀(regression), 군집화(clustering) | 분류는 범주, 회귀는 수치를 예측하고 군집화는 비슷한 집단을 찾는다. | 목표와 함께 정답 레이블이 필요한지도 비교한다. |
| 파운데이션 모델(foundation model, FM), LLM과 에이전트(agent) | FM은 여러 과업에 활용하는 기반 모델이고, LLM은 언어를 중심으로 처리한다. 에이전트는 모델을 이용하면서 도구, 상태와 작업 순서를 관리한다. | 답변이 길다는 이유만으로 에이전트가 되는 것은 아니다. |
| 토큰(token), 청크(chunk), 임베딩(embedding) | 토큰은 모델의 입력·출력 처리 단위, 청크는 청킹(chunking)으로 나눈 문서 조각, 임베딩은 의미를 수치로 표현한 벡터다. | 하나의 청크에 여러 토큰이 들어갈 수 있으므로 청크 수와 토큰 수는 다르다. |
| 훈련(training)과 추론(inference) | 훈련은 모델을 학습하거나 조정하고, 추론은 그 모델을 새 입력에 적용한다. | 검색 증강 생성(Retrieval Augmented Generation, RAG)은 검색 결과를 입력에 넣는 방식이지 질문마다 재훈련하는 방식이 아니다. |
| 정밀도(Precision)와 재현율(Recall) | 정밀도는 양성으로 예측한 것 중 실제 양성의 비율, 재현율은 실제 양성 중 모델이 찾아낸 비율이다. | 드문 사건을 탐지할 때는 전체 정확도(Accuracy)만으로 평가하지 않는다. |
출처: 공식 출처 안내, ML 수명 주기, RAG 내부 흐름, 에이전트와 도구. 분류 지표의 정의와 수식은 혼동 행렬과 임계값, 평가 지표와 교차 검증, 영역 1 심화에서 계산 예제와 함께 공부한다. 여기서는 기본 지표를 비교하며 모든 변형을 다루지는 않는다.
추론 방식
| 방식 | 사용 조건 | 반대 조건 |
|---|---|---|
| 실시간 추론(real-time inference) | 대화처럼 짧은 지연으로 개별 요청에 답해야 할 때 사용한다. | 급하지 않은 대량 작업에는 다른 방식이 더 적합할 수 있다. |
| 서버리스 추론(serverless inference) | 요청이 없을 때가 많고 인프라 관리 부담을 줄이려는 경우 검토한다. | 콜드 스타트(cold start)의 지연을 허용할 수 있는지 확인한다. |
| 비동기 추론(asynchronous inference) | 입력이 크거나 처리에 오래 걸리고 결과를 나중에 받아도 될 때 사용한다. | 즉시 완성된 답을 돌려줘야 하는 요구와 맞지 않을 수 있다. |
| 배치 추론(batch inference) | 미리 모은 대량 데이터를 처리할 때 사용한다. | 상시 온라인 요청에 응답하는 서비스와는 처리 방식이 다르다. |
출처: 추론 방식 선택 ·배치 변환. 서버리스(serverless)는 누가 인프라를 관리하는지에 관한 구분이고, 비동기(asynchronous)는 요청을 접수하고 결과를 전달하는 방식에 관한 구분이다. 따라서 같은 기준으로 나눈 선택지는 아니다. 서비스별 실제 제공 옵션에서 조건을 확인한다.
모델 활용과 사용자 지정
| 선택 | 변경 대상 | 필요한 검증 |
|---|---|---|
| 프롬프트(prompt) | 모델에 전달하는 지시, 예시와 입력 문맥을 바꾼다. | 버전과 변수, 요구하는 출력 형식을 관리하고 회귀 테스트(regression testing)를 수행한다. |
| 검색 증강 생성(Retrieval Augmented Generation, RAG) | 검색한 근거를 모델의 입력에 추가한다. | 원문 접근 권한, 최신성, 청킹(chunking), 검색과 답변의 근거 활용을 확인한다. |
| 미세 조정(fine-tuning) | 추가 학습으로 모델 가중치를 바꾸어 동작을 조정한다. | 대표성 있는 데이터와 사용 권리를 확보하고 품질, 안전성과 비용을 평가한다. |
| 지속 사전 훈련(continued pre-training) | 추가 데이터로 모델을 더 학습시킨다. | 특정 분야에 대한 적응(domain adaptation) 효과와 학습 비용, 품질을 비교한다. |
| 증류(distillation) | 교사 모델(teacher model)의 출력을 이용해 학생 모델(student model)을 학습한다. | 작은 모델이 수행하기 어려운 과제와 전체 비용, 지연을 확인한다. |
| 모델 교체와 라우팅(routing) | 요청을 처리할 모델을 바꾼다. | 요청·응답 형식, 권한과 리전 제한을 유지하고 폴백(fallback) 모델의 품질도 확인한다. |
출처: 공식 출처 안내, Knowledge Bases 선택, RAG 내부 흐름, 프롬프트 관리. 지원 모델과 구체적인 구현 방법은 제품 문서에서 별도로 확인한다.
서비스 선택
| 서비스·기능 | 주된 질문 | 대체하지 못하는 것 |
|---|---|---|
| Amazon Bedrock | 관리형 파운데이션 모델(foundation model, FM)을 어떻게 통합할까? | 고객은 데이터·권한·평가에 대한 책임을 계속 진다. |
| Amazon SageMaker AI | 모델 개발·배포(deployment)·운영을 얼마나 세밀하게 제어할까? | 먼저 업무 요구사항을 정의해야 한다. |
| JumpStart | 사전 훈련 모델(pre-trained model)을 어떻게 빠르게 활용할까? | 모든 사용자 지정 요구를 자동 충족하지는 않는다. |
| Knowledge Bases | 검색 증강 생성(RAG)을 위해 검색 근거를 모델에 어떻게 전달할까? | 검색을 붙여도 모든 응답의 사실성이 보장되지는 않는다. |
| Agents | 에이전트(agent)가 도구(tool)를 사용해 여러 단계의 업무를 어떻게 수행할까? | 업무 승인(approval)과 최소 권한(least privilege)을 별도로 설계해야 한다. |
| Prompt Management | 프롬프트(prompt)의 변수(variable)·변형(variant)·버전(version)을 어떻게 관리할까? | 관리 기능만으로 품질이나 정책 준수가 자동 보장되지는 않는다. |
| Guardrails | 원치 않는 입력·출력을 콘텐츠 필터(content filter) 등으로 어떻게 검사할까? | 자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM)의 인가(authorization)나 전체 사실 검증을 대신하지 않는다. |
| Model Cards | 모델 카드(model card)에 용도·한계·위험·평가를 어떻게 기록할까? | 문서를 작성해도 편향(bias)이 제거되거나 내부 계산이 설명되는 것은 아니다. |
출처: Bedrock 역할과 최신 기능 경계 ·Knowledge Bases 선택 ·RAG 내부 흐름 ·Guardrails의 역할과 경계 ·Bedrock 데이터 보호 ·모델 카드와 설명 가능성 ·모델 평가와 RAG 평가 ·프롬프트 관리 ·에이전트와 도구, 추론 방식 선택.
보안·관찰성
| 개념 | 통제·관찰 대상 | 주의 |
|---|---|---|
| AWS Identity and Access Management(IAM) | 어떤 주체가 어떤 AWS 리소스에서 어떤 작업을 할 수 있는지 정한다. | 콘텐츠 안전(content safety)을 검사하는 기능과 다르다. |
| 암호화(encryption) | 저장 중인 데이터(data at rest)와 전송 중인 데이터(data in transit)를 보호한다. | 암호화만으로 부적절한 접근을 모두 막을 수는 없으므로 인가(authorization)도 필요하다. |
| AWS PrivateLink와 가상 프라이빗 클라우드(Amazon Virtual Private Cloud, VPC) | 서비스에 접근하는 네트워크 경로를 제어한다. | 데이터의 내용이 안전한지, 사용자가 업무를 수행할 권한이 있는지는 따로 검사한다. |
| Amazon Macie | Amazon S3에서 민감한 정보를 찾는 데 사용한다. | 모든 데이터 소스의 개인 식별 정보(personally identifiable information, PII)를 자동으로 보호하는 기능은 아니다. |
| Amazon CloudWatch | 운영 지표(metrics)와 로그(logs)를 수집하고 분석한다. | 답변 품질은 평가 방법과 지표를 별도로 설계해야 한다. |
| AWS CloudTrail | API 활동을 기록해 감사(audit)에 사용한다. | 모든 프롬프트와 응답 내용을 남기는 모델 호출 로그와는 다르다. |
| 모델 호출 로깅(model invocation logging) | 모델 요청, 응답과 메타데이터(metadata)를 기록한다. | 기본적으로 비활성화되어 있으므로 지원 범위와 활성화 설정, 보존 기간과 접근 권한을 확인한다. |
출처: 공식 출처 안내, Bedrock 데이터 보호, 관찰성 — 지표·감사·호출 로그의 차이, 모델 호출 로깅.
AIP에서 더 깊게 볼 비교
- 검색 실패와 생성 실패: 관련 문서가 없으면 수집·검색, 문서가 있는데 틀리면 문맥·생성·검증을 우선 조사한다.
- 스키마 유효성과 사실적 정확성(factual accuracy): JSON이 파싱된다고 값이 옳거나 실행이 안전한 것은 아니다.
- 스트리밍과 완료: 첫 토큰 수신은 응답 전체 또는 도구 업무 완료가 아니다.
- 프롬프트 캐시와 결과 캐시: 반복 입력 처리 재사용과 답변 재사용은 권한·최신성·비용 조건이 다르다.
- 품질 게이트와 모니터링: 배포 전 통과 기준과 배포 후 변화 탐지를 함께 설계한다.
- 비용·호출과 비용·성공 업무: 재시도·검토·실패 복구까지 포함하면 순위가 바뀔 수 있다.
출처: 공식 출처 안내, 모델 평가와 RAG 평가, 프롬프트 캐싱의 조건, 모델 호출 로깅. 비교 내용은 설계 원리이며 실제 성능 측정 결과가 아니다.
D1 1.6에서 구분할 경계
| 구분 | 판단과 근거 | 읽기 한계 |
|---|---|---|
| 유효 기간(time to live, TTL) 만료 /실제 삭제 /앱 세션 사용 금지 | TTL은 만료 즉시 물리 삭제를 보장하지 않는다. 남아 있는 만료 이력도 앱이 다시 사용하지 않도록 검사한다. TTL 상세 | 정확한 삭제 시한·저장소별 구현과 법적 보존 조건 확인 |
| 프롬프트 초안(draft) /버전(version) /조직 승인(approval) /배포 참조(deployment reference) | 버전 생성만으로 검토·승인·프로덕션 전환이 완료되지 않는다. 버전과 승인 | 하위 API·조직 승인 시스템·역할별 권한 확인 |
| 시스템 지침 /Guardrails /JSON 검증 /IAM·업무 인가 | 각각 행동 지시, 설정된 위험 통제, 구조 검증, 실제 접근 권한을 담당한다. 한 기능이 다른 통제를 대신하지 않는다. | 정책 버전·검사 범위·실제 집행을 각각 확인 |
강좌 관련 항목의 90 일 TTL·7년로그와 성능 수치는 가상조직 예시이지 법률의 보편적 요구·서비스 기본값·실고객 성과가 아니다.
시험 범위 혼합 금지
현재 공식 부록에서 AWS AppConfig/X-Ray는 AIF 범위 외, AIP 범위 내에 표시된다. Budgets/Trusted Advisor는 AIF 범위 내, AIP 범위 외 목록에 표시된다. 한 시험의 범위를 다른 시험에 복사하지 않는다. 목록은 완전하지 않고 변경될 수 있다.
D2 통합 패턴의 혼동 방지
| 비교 | 책임과 경계 | 실제 근거·해설 |
|---|---|---|
| Server-Sent Events(SSE)와 서버 측 암호화(server-side encryption, SSE) | 이 절의 SSE는 서버가 클라이언트에 이벤트를 보내는 통신 방식이다. 저장 데이터를 암호화하는 SSE와 약어가 같지만 기능은 다르다. | 2.5 API |
| WebSocket, Server-Sent Events(SSE)와 모델 스트리밍(model streaming) | WebSocket은 양방향 연결을, SSE는 서버에서 클라이언트로의 이벤트 전달을 지원한다. 모델 스트림의 델타(delta)와 종료 이벤트를 화면에 전달하려면 해당 형식에 맞추어 처리해야 하며 자동 변환된다고 가정하지 않는다. | API와 UI |
| AWS Amplify, OpenAPI와 Amazon Bedrock Flows | Amplify는 선언형 앱 개발을 돕고, OpenAPI는 API의 요청과 응답 형식을 기술한다. Flows는 처리 노드를 연결한다. 어떤 도구를 쓰든 접근성(accessibility)과 오류 처리는 따로 검증한다. | 2.5.2 |
| Amazon Q Business와 Amazon Q Developer | Q Business는 기업 지식 검색에서 커넥터(connector), 인덱스(index)와 접근 제어 목록(access control list, ACL)을 다룬다. Q Developer는 코드 작성, 테스트와 검토를 돕는다. 두 서비스의 기능과 권한이 같다고 가정하지 않는다. | 업무 활용·개발 생산성 |
| Amazon Bedrock Data Automation(BDA)의 정보 추출과 업무 확정 | BDA는 원문에서 필드와 정보를 추출한다. 애플리케이션은 추출 결과를 규칙과 원문 근거로 검증하고, 필요하면 사람의 검토(human review)를 거친 뒤 실제 업무 데이터로 저장한다. | 2.5.3 |
| Strands와 Agent Squad, Amazon Bedrock Agents와 AgentCore | Strands와 Agent Squad는 에이전트 프레임워크(agent framework), Bedrock Agents는 관리형 에이전트 기능, AgentCore는 실행 플랫폼이다. invoke_agent를 호출하는 코드와 Strands SDK로 에이전트를 구현하는 코드는 같지 않다. | 2.5.5 |
| CloudWatch Logs Insights, AWS X-Ray와 모델 호출 로깅(model invocation logging) | 각각 로그 질의, 분산 추적(distributed tracing), 모델 입력·출력 기록을 맡는다. 수집 범위, 정보 보호와 비용을 개별적으로 확인한다. | 2.5.6 |
| API 키(API key)와 사용량 계획(usage plan), 인증(authentication)과 인가(authorization) | API 키와 사용량 계획은 사용량을 식별하고 best-effort 방식으로 제한한다. 호출자의 신원을 검증하거나 업무 리소스에 대한 권한을 판단하는 수단과 구분한다. | API 키와 사용량 계획의 한계 |
| IAM과 Amazon Verified Permissions | IAM은 AWS 리소스에 대한 실행 주체의 권한을 관리한다. Verified Permissions는 앱의 주체(principal), 작업(action), 리소스(resource), 문맥(context)에 따라 정책을 평가하며, 앱이 그 판단을 실제 요청 처리에 적용해야 한다. | 정책 평가와 애플리케이션의 집행 책임 |
| 모델 단위(Model Unit, MU), 용량 변경과 자동 확장(auto scaling) | 모드별 용량이 무엇을 의미하는지, 토큰 처리량과 용량을 어떤 조건에서 변경할 수 있는지 확인한다. 수동 용량 변경이 정책 기반 자동 확장을 뜻하는 것은 아니다. | 프로비저닝된 처리량과 용량 변경 |
| AWS Outposts의 로컬 앱과 로컬 파운데이션 모델(foundation model, FM) | 앱이 온프레미스(on-premises)에 있다는 것과 모델 계산도 그곳에서 실행된다는 것은 다르다. 로컬에서 제공하는 서비스와 AWS 리전에 연결해야 하는 서비스를 구분한다. | Outposts와 리전 서비스 연결 |
위 비교는 공식 가이드와 서비스 문서에 따른 독립 설명이다. 교육 토큰·시간·임계값을 제품 상한·기본값으로 암기하지 않으며 정확 제품/SDK·커넥터·BDA·X-Ray 세부는 학습 범위와 한계에 남긴다.
용어 확인: 인증(authentication) · 대규모 언어 모델(large language model, LLM) · 개인 식별 정보(personally identifiable information, PII).