생성형 AI(generative AI, GenAI)의 품질은 모델 하나로 결정되지 않는다. 이 장에서는 토큰(token)과 검색 근거가 답변으로 이어지는 과정, 모델 적응 방법의 선택, 책임 있는 활용과 보안 통제를 차례로 살펴본다. AI·ML 기초를 이해한 뒤 읽으면 각 선택의 이유를 연결하기 쉽다.
영역 2: 생성형 모델의 원리와 전체 시스템
토큰·임베딩·청크는 같은 단위가 아니다
토큰(token)은 모델이 입력과 출력을 처리하는 단위다. 단어 하나가 여러 토큰으로 나뉠 수 있으므로 글자 수·단어 수·토큰 수를 같게 계산하지 않는다. 컨텍스트 창(context window)에 넣을 수 있는 분량을 정할 때는 지침·대화 이력·검색 결과·사용자 질문뿐 아니라 모델별 출력 예산도 고려한다. 긴 문서를 모두 넣으면 비용이 늘고 중요한 근거가 다른 내용에 묻힐 수 있다.
임베딩(embedding)은 텍스트 등의 의미적 특징을 수치 벡터(vector)로 표현한다. 검색에서는 질의와 문서 표현을 비교해 관련 후보를 찾는다. 임베딩이 같거나 가까운 것은 사실이 참이라는 증명이 아니라 해당 표현 공간에서 유사하다는 신호다. 청크(chunk)는 검색하거나 처리하기 위해 문서를 나눈 조각이다. 청크 크기를 토큰으로 제한할 수 있지만 청크 한 개가 토큰 한 개가 아니다. RAG 내부 흐름 ·청킹의 설계 절충
트랜스포머(Transformer) 계열 언어 모델은 문맥 안의 관계를 활용해 토큰의 확률 분포를 계산하고 출력을 생성한다. 확산 모델(diffusion model)은 노이즈를 제거해 이미지의 구조를 만들어 간다. 멀티모달 모델(multimodal model)은 텍스트 외에 이미지·음성 등도 입력받거나 출력하지만, 지원 형식은 모델마다 다르다. 이 개념 설명은 공식 파운데이션 모델(foundation model, FM) 개요와 가이드에 근거하며 모든 구조의 상세 수학이나 현재 모델별 성능을 보장하지 않는다. FM과 과업별 ML 선택, AIF-C01 영역 2 시험 가이드
FM 수명 주기와 비용의 위치
파운데이션 모델(foundation model, FM)을 활용하는 과정은 데이터 선택, 사전 훈련(pre-training) 또는 기존 모델 선택, 필요한 적응(adaptation), 평가(evaluation), 배포(deployment), 피드백(feedback) 순으로 살펴볼 수 있다. 기존 FM을 이용하면 사용자가 대규모 사전 훈련 비용을 직접 부담하지 않아도 된다. 다만 추론(inference) 요청·검색 저장소·운영·평가·검토 비용은 여전히 발생한다. 개발팀은 사용하는 데이터의 권리와 품질을 확인하고 접근 통제(access control)를 적용해야 한다.
추론(inference) 비용은 대략 입력 토큰 비용+출력 토큰 비용+기능별 추가 비용으로 나누어 계산할 수 있다. 예를 들어 자체 고객상담 앱에서 대화 이력을 매번 전부 보내면 사용자가 입력한 새 문장은 짧아도 전체 입력은 커진다. 대화 요약은 토큰을 줄이지만 날짜·합의·금액을 잘못 요약하면 품질 손실이 발생하므로 반드시 보존할 필드를 구조화한다. 프롬프트 캐시(prompt cache)는 반복되는 접두사(prefix)의 계산을 재사용해 처리 부담을 줄일 수 있다. 이를 처리량(throughput) 자체를 줄이는 기능으로 이해해서는 안 된다. 캐시를 사용해도 호출이 무료가 되거나 정답이 보장되는 것은 아니다. 프롬프트 캐싱의 조건 ·모델 사용자 지정 ·프롬프트 구성과 퓨샷
컨텍스트와 에이전트의 차이
프롬프트 엔지니어링(prompt engineering)은 지시의 표현과 예시를 설계한다. 컨텍스트 엔지니어링(context engineering)은 그보다 넓게, 앱이 지시·검색 근거·대화 기억·도구 결과를 어떤 순서로 얼마나 모델에 전달할지 정한다. 문서 속 ‘이전 규칙을 무시하라’는 문장을 명령으로 승격하면 검색이 새로운 공격 경로가 된다. 문서 내용은 근거 데이터이며 도구 실행 권한을 부여하는 정책이 아니다.
에이전트(agent)는 모델이 선택한 도구를 호출하고, 도구가 반환한 결과를 다음 판단에 사용한다. 복잡한 일을 여러 에이전트에 나누면 전문화는 쉬워질 수 있지만 중복 호출·서로 다른 상태·무한 위임·오류 전파가 늘 수 있다. 공유 메모리의 소유자와 보존 기간, 작업 완료·중단 조건, 사람 승인 지점을 명확히 둔다. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 외부 도구 접근을 표준화하는 연결 방식이고 AgentCore Gateway는 API/Lambda 등을 MCP 도구로 노출하는 선택지다. 연결 규약이 같아도 모든 호출을 허용하는 것은 아니다. AgentCore 구성요소와 MCP
| 구성요소 | 맡기는 책임 | 여전히 앱이 정해야 하는 것 |
|---|---|---|
| 모델/FM API | 모델을 실행해 생성·추론(inference) 결과를 반환한다. | 모델 선택 기준, 평가 방법, 정보 접근 범위를 정한다. |
| 에이전트 프레임워크(agent framework) | 모델의 도구 선택과 실행 결과 전달을 반복하고 상태를 조정한다. | 언제 중지·재시도(retry)하고 사람 승인을 받을지, 실패를 어떻게 처리할지 정한다. |
| AgentCore Runtime | 에이전트를 실행하고 실행 환경을 격리(isolation)한다. | 앱의 처리 절차와 허용 행동을 정한다. |
| Memory | 단기·장기 메모리(short-term/long-term memory)를 보존한다. | 누구의 정보인지 구분하고 삭제 방법과 정확성 확인 절차를 정한다. |
| Identity /Policy | 인증(authentication)을 연결하고 실행 전에 정책(policy)을 적용한다. | 최소 권한(least privilege)과 업무별 허용 조건을 정한다. |
| Observability | 실행 경로와 지표(metrics)를 수집해 동작을 살펴보게 한다. | 민감 데이터의 수집 최소화·보존 기간·경보 조건을 정한다. |
Amazon Bedrock은 관리형 FM 활용, SageMaker AI는 훈련·호스팅 제어가 중요한 경우, JumpStart는 사전 훈련 모델 탐색·활용에 연결된다. AgentCore는 에이전트 운영 플랫폼이며 이 세 가지를 같은 ‘모델’로 취급하지 않는다. Quick/Kiro/Strands의 구체 기능은 가이드에 등장하나 이 문서에서 별도 공식 개발자 본문을 충분히 검증하지 않았으므로 세부 지원 조건은 남은 항목이다.
영역 3: 어떤 문제에 어떤 개선 수단을 쓰는가
모델 적응 방법 선택
| 방법 | 바꾸는 것 | 적합한 요구 | 비용·제약 |
|---|---|---|---|
| 제로샷·퓨샷 프롬프트(zero-shot/few-shot prompting) | 추론 시 지침·예시 | 형식·분류 기준을 명확히 전달 | 입력 토큰 증가; 가중치 변경 아님 |
| 검색 증강 생성(Retrieval Augmented Generation, RAG) | 요청 시 제공하는 외부 근거 | 최신 사내 정책·출처 기반 답변 | 검색 품질·문서 권한·동기화 책임 |
| 지도 미세 조정(supervised fine-tuning, SFT) | 학습된 파라미터·행동 | 반복되는 도메인 형식·응답 습관 | 고품질 입력-출력 데이터·평가·배포 비용 |
| 지속 사전 훈련(continued pre-training) | 도메인 데이터의 표현 학습 | 도메인 적응 검토 | 서비스·모델 지원 확인 필요; 최신 요금·지원 미확정 |
| 강화 미세 조정(reinforcement fine-tuning, RFT) | 보상에 맞춘 출력 행동 | 정답 쌍보다 평가 신호를 정의하기 쉬운 과업 | 보상 편법·편향·안전성 검증 |
| 증류(distillation) | 큰 교사의 행동을 작은 학생에 이전 | 특정 과업의 비용·지연 절감 | 교사 오류 전달·일반 능력 손실·별도 평가 |
모델 사용자 지정 ·프롬프트 구성과 퓨샷, AIF-C01 영역 3 시험 가이드. 지속 사전 훈련은 가이드 요구 개념이며 참고한 Bedrock 사용자 지정 개요가 열거한 지원 방법과 동일시하지 않는다. 문서에 나열되지 않았다는 이유만으로 모든 서비스에서 폐지됐다고 주장하지 않는다.
자체 판단 예시: ‘휴가 규정이 바뀔 때마다 모델 답이 틀린다’면 최신 문서의 동기화·검색을 먼저 본다. ‘정보는 정확하지만 항상 회사 응답 형식을 어긴다’면 템플릿·검증·퓨샷을 먼저 시험하고 반복적인 행동 적응이 필요하면 미세 조정(fine-tuning)을 평가한다. ‘작은 모델이 특정 반복 업무만 잘하면 된다’면 증류를 검토한다. 가장 비싼 훈련부터 시작하는 것이 정답은 아니다.
검색을 개선하는 순서
청킹(chunking)은 문서 구조에 맞춰 선택한다. 작은 청크는 특정 문장 검색에 유리할 수 있지만 예외 조건과 본문이 분리될 수 있다. 큰 청크는 맥락을 보존하지만 무관한 내용과 비용을 늘린다. 계층형 청킹(hierarchical chunking)은 작은 조각으로 검색한 뒤 더 큰 문맥을 제공한다. 시맨틱 청킹(semantic chunking)은 의미가 바뀌는 지점을 활용해 문서를 나누므로 추가 처리 비용도 비교해야 한다. 청킹의 설계 절충
검색 후보에 정답 문서가 없다면 생성 모델만 바꾸기보다 데이터 수집·임베딩·필터·검색 방식을 점검한다. 고유 제품 코드가 중요한 질의는 키워드와 의미 검색의 결합을 검토할 수 있다. 리랭킹(reranking)은 검색된 후보의 순위를 다시 매기는 단계이므로 애초 누락된 정답 문서를 만들어주지 않는다. 지원 저장소·엔진·메타데이터 타입은 제품 조건이다. 권한 필터는 서버가 확인한 사용자·테넌트에서 구성한다. 대규모 언어 모델(large language model, LLM)이 생성한 편의 필터로 보안 경계를 대신하지 않는다. 검색 필터·리랭킹·질의 분해
파라미터와 프롬프트
온도(temperature)를 낮추면 모델이 높은 확률의 토큰을 더 선호하게 된다. Top K는 후보 개수를, Top P는 누적 확률 질량을 기준으로 후보를 제한한다. 낮은 온도는 일관성을 높이는 방향이지만 정답 보장·보안 필터·완전한 결정성을 의미하지 않는다. 최대 출력 토큰(maximum output tokens)과 중지 시퀀스(stop sequence)는 응답을 끝내는 조건이므로 중간에 답이 잘리는 문제에서 먼저 확인한다. 추론 파라미터
자체 프롬프트 설계 예시: ‘잘 요약해’ 대신 대상 독자, 분량, 필수 항목, 근거 없을 때의 응답, 출력 형식을 분리해 적는다. 제로샷으로 충분한지 확인하고 경계가 모호하면 서로 다른 분류 예시를 몇 개 넣는다. 한 예시만 반복하면 그 표현에 과적응할 수 있으므로 평가 세트를 다양하게 구성한다. 템플릿 버전·모델 버전·추론 설정·검색 구성을 함께 기록해야 회귀를 재현할 수 있다. 프롬프트 구성과 퓨샷 ·프롬프트 관리
FM 평가와 업무 성공
표현이 달라도 의미가 맞는 생성 과업은 분류 정확도 하나로 판단하기 어렵다. ROUGE/BLEU는 참조 문장과의 겹침을 활용하고 BERTScore는 표현의 의미적 유사성을 활용하는 지표 계열로 구분한다. 지표별 세부 정의와 변형은 아래 평가 보고서 절 및 연결 문서를 함께 읽어야 한다. 이 장만으로 모든 지표의 공식을 설명하지는 않는다. LLM 평가자(LLM-as-a-judge)는 평가 기준과 모델 버전·판정 일관성을 확인하며 사람 표본 검토로 보완한다. AIF-C01 영역 3 시험 가이드, 모델 평가와 RAG 평가
검색 증강 생성(RAG)에서는 검색 관련성(Relevance), 정답 문서를 찾았는지 여부, 답변의 충실도(Faithfulness)를 따로 평가한다. 에이전트(agent)는 문장의 자연스러움뿐 아니라 도구 선택과 인수가 맞는지, 필요한 승인을 받았는지, 업무를 실제로 끝냈는지도 확인한다. 사용자 만족도(user satisfaction)·작업 완료율(task completion rate)·상호 작용당 비용(cost per interaction)을 함께 보면 길고 설득력 있게 쓴 답변만 높게 평가하는 오류를 줄일 수 있다.
영역 4: 책임 있는 AI를 측정 가능한 질문으로 바꾸기
공정성과 정확도는 독립적으로 확인한다
대표성이 부족한 데이터, 과거 의사결정의 편향된 레이블, 특정 집단에서 약한 측정 장치는 모두 결과 격차를 만들 수 있다. 훈련 전에는 그룹별 표본과 레이블 분포를 보고, 훈련 후에는 그룹별 정밀도(Precision)·재현율(Recall)·오류율을 비교하며, 배포 후에는 기준에서 벗어나는 변화를 감시한다. 공정성 정의는 과업과 법적 맥락에 따라 다르므로 전체 정확도 한 숫자로 ‘공정하다’고 결론 내리지 않는다. 훈련 전 편향
자체 예시: 전체 인식률이 높아도 특정 억양에서 전사 누락이 반복되면 사용자군별 평가 세트를 보강한다. 특정 그룹 표본이 매우 적다면 오류율 차이의 안정성도 검토한다. 성별 열을 삭제해도 다른 특징이 대리변수로 작동할 수 있으므로 민감 속성 삭제만으로 공정성을 보장하지 않는다. 이 마지막 판단은 데이터·모델 평가 원리에 따른 자체 해설이다.
설명과 투명성
투명성(transparency)은 시스템의 목적, 사용 데이터, 한계, 평가 결과와 책임 주체를 사용자에게 알리는 것이다. 모델 카드(model card)는 이런 정보를 정리하는 문서다. 설명 가능성(explainability)은 어떤 특징이 특정 예측에 영향을 미쳤는지 등 모델 동작을 분석하는 능력이다. 섀플리 값 기반 특징 기여도(SHapley Additive exPlanations, SHAP)는 선택한 기준 대비 특징의 기여를, 부분 의존도 도표(partial dependence plot, PDP)는 특징 변화와 평균적 응답 관계를 분석하는 방법이다. LLM이 작성한 이유가 실제 의사결정 원인이라는 보장은 없다. 모델 카드와 설명 가능성 ·설명 가능성과 SHAP
원문 현재 고지에 따르면 SageMaker Clarify는 신규 고객 이용이 제한된다. 개념 학습에는 유용하지만 신규 프로젝트에 곧바로 도입 가능하다고 권하지 않는다. 최신 서비스 상태와 과거·현재 시험 가이드의 이름을 분리해야 한다. 설명을 제공한다고 예측이 올바르거나 차별이 없는 것은 아니므로 성능·공정성 검증을 함께 한다.
안전·권리·지속 가능성
유해 출력 필터는 위험을 줄이는 수단이지 법적 면책이나 완전 안전 보장이 아니다. 데이터 권리·저작권·보존 목적·사용자 고지를 확인하고, 중요한 판단에는 사람 검토와 이의제기 경로를 둔다. 출처가 있어도 원문 사용 권한과 인용의 정확성은 별도 문제다. 작은 모델·적절한 출력 길이·불필요한 반복 호출 감소는 자원 사용을 줄이는 설계지만 이 자료에서 탄소 배출 감소량을 계산하거나 보장하지 않는다. AIF-C01 영역 4 시험 가이드, Guardrails의 역할과 경계 ·모델 사용자 지정
영역 5: 보안은 서로 다른 통제의 조합
인증·인가·네트워크·암호화·내용 검증
| 통제 | 해결하는 질문 | 해결하지 못하는 것 |
|---|---|---|
| 인증(authentication) | 누가 요청하는가? | 그 사용자가 특정 문서를 읽을 권한이 있는가? |
| 자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM)/리소스 정책 | 어떤 주체가 어떤 작업·리소스에 접근하는가? | 모델 답변의 사실성 |
| PrivateLink | 가상 프라이빗 클라우드(Amazon Virtual Private Cloud, VPC)와 서비스 간 사설 접근 경로 | 문서별 업무 권한·프롬프트 공격 |
| 전송 중·저장 시 암호화(encryption in transit/at rest) | 데이터가 전송되거나 저장될 때 노출될 위험을 줄인다. | 이미 허용된 주체의 과도한 정보 사용 |
| Guardrails/출력 검증 | 유해 내용·일부 개인정보·형식·근거 문제 | 모든 위협·법적 준수·최소 권한 |
| AgentCore Policy | 도구 실행 전에 정책(policy)에 따라 해당 업무를 허용할지 판단한다. | 모델 훈련 데이터의 공정성 |
Guardrails의 역할과 경계 ·Bedrock 데이터 보호 ·IAM 인증과 인가 ·PrivateLink와 네트워크 경계 ·AgentCore 구성요소와 MCP. 정책의 Action·Resource·Condition을 좁히고 사람·서비스 역할을 구분한다. 서비스 제어 정책(service control policy, SCP)와 권한 경계는 최대 허용 범위를 제한하는 것이며 자체적으로 접근권한을 부여하지 않는다. 사설 엔드포인트가 있어도 DNS·엔드포인트 정책·역할 권한이 틀리면 호출은 실패한다.
데이터 계보와 로그
문서 ID·버전·수집 시각·소유권·변환 규칙·임베딩 모델을 연결하면 어떤 자료가 어떤 답변에 영향을 줬는지 추적하기 쉬워진다. 원문을 삭제하거나 접근권한을 회수했는데 벡터 색인·캐시에 남아 있으면 삭제가 끝난 것이 아니다. 데이터 수명 주기는 원문·청크·임베딩·로그·백업까지 이어진다. RAG 내부 흐름 ·검색 필터·리랭킹·질의 분해 및 자체 설계 해설
CloudTrail은 API 활동을 감사(audit)하는 데 쓰인다. CloudWatch는 지표(metrics)와 로그(logs)를 수집하고 경보(alarms)를 제공한다. 모델 호출 로깅(model invocation logging)은 지원되는 호출의 입력과 출력을 분석하기 위한 기록이다. 호출 로깅은 기본 비활성화이며 활성화 시 민감한 프롬프트도 기록할 수 있다. 해당 문서에서 대상은 동일 계정·리전이고, 큰 본문·바이너리는 S3 별도 객체와 연결될 수 있다. 서비스 로그의 주체 정보와 호출자가 임의 제공한 태그를 같은 신뢰도로 취급하지 않는다. 관찰성 — 지표·감사·호출 로그의 차이 ·모델 호출 로깅
가이드에 있는 Config·Inspector·Artifact·Trusted Advisor는 각각 구성 준수·취약성·감사 자료·권고라는 서로 다른 목적을 갖는다. 이 문서는 기존 통합 노트의 개요와 연결하며 제품별 모든 규칙·지원 범위를 검증했다고 하지 않는다. 보존 기간·검토 주기·담당자·사고 대응·교육을 정해야 도구만 도입하고 운영 책임이 비는 문제를 피할 수 있다.
판단 연습
- 최신 정책을 못 찾는다 → RAG 수집·필터·색인을 먼저 확인. 온도만 낮추기 X.
- 응답 형식이 매번 다르다 → 지침·예시·스키마 검증·버전 회귀 확인. 곧바로 사전 훈련 X.
- 정상 사용자가 다른 부서 자료를 본다 → 인증 성공 여부가 아니라 문서 권한 필터·서비스 역할·캐시 키 확인.
- 전체 정확도만 좋다 → 하위 그룹 오류·표본 수·사용자 피해 검토.
- 캐시 활성화했는데 비용이 늘었다 → 쓰기·읽기 토큰·적중률·접두사 변경·유효 기간(time to live, TTL)·라우팅 확인.
후속 확인: 학습 파라미터와 평가 보고서
미세 조정과 하이퍼파라미터 에서 미세 조정은 가중치를 바꾸는 추가 훈련임을 확인했다. 학습률(learning rate)·에포크(epoch)·배치 크기·입력 길이·검증 분할은 학습과 평가 과정의 조건이다. 이들을 추론 시 temperature/top-p와 구분한다. 작은 데이터에서 반복 횟수만 늘리면 실제 업무 성능이 좋아진다고 가정하지 않고 검증 세트를 함께 본다.
자동 평가 과업과 지표 ·텍스트 요약 평가 ·자동 평가 보고서 해석 에서 BERTScore가 사전 훈련 문맥 임베딩을 사용해 후보·참조 문장의 단어를 코사인 유사도로 대응시키는 지표임을 확인했다. 표현이 달라도 의미를 비교할 수 있지만 날짜·수량·의무 조항의 사실 검증을 대체하지는 않는다. 변형한 프롬프트에서 점수가 얼마나 바뀌는지로 견고성을 평가할 수 있다. 지표마다 좋은 방향이 다르므로 모든 숫자가 높을수록 좋다고 외우지 않는다.
평가 보고서에서 입력 수와 응답 수를 따로 확인한다. 오류로 응답하지 못한 프롬프트는 성공 응답 지표에 포함되지 않을 수 있으므로 좋은 평균값만으로 전체 성공을 주장하지 않는다. 평가자 지표의 의미의 정확성(Correctness)·완전성(Completeness)·충실도(Faithfulness)는 각각 정확성·질문 전체 대응·주어진 문맥에 대한 충실도다. 자체 예시에서 규정의 첫 질문에만 정확히 답하면 정확성은 좋아도 완전성이 부족하고, 문서에 없는 예외를 지어내면 충실성이 부족하다.
BERTScore의 기본 원리는 위 설명과 연결된 한국어 문서에서 확인할 수 있다. ROUGE/BLEU의 세부 변형·공식은 여전히 이 노트의 근거 범위 밖이다. 문서의 잘못된 F1 점수(F1 score) 표현을 복제하지 않고 영역1의 공식 대조 수식을 사용한다.
더 확인할 주제
ROUGE/BLEU 심층 정의, Quick/Kiro/Strands의 공식 한국어 상세, Scoping Matrix의 현행 법률 적용, 보안 서비스별 심층 지원 조건은 남은 범위입니다.
서비스 계층 비교와 생성형 AI의 보안 책임 범위에 공개 공식 자료로 보강한 설명이 있다. 제품별 한국어 SDK 상세와 모든 지원표를 검증한 것은 아니다.