AIF-C01 영역 2 — 생성형 AI의 원리와 활용

생성형 AI(generative AI, GenAI)를 이해하는 출발점은 모델이 데이터를 표현하고 출력을 선택하는 과정이다. 토큰(token)·임베딩(embedding)·생성 구조를 구분한 뒤 프롬프트와 훈련의 차이, 전체 시스템의 품질·비용·보안을 연결해 보자.

A 모델이 문자열을 처리하는 경로

텍스트 모델은 먼저 문자열을 토큰(token)으로 나누고 각 토큰을 식별자(ID)로 바꾼다. 이어서 토큰을 임베딩(embedding) 벡터로 표현하고, 주변 문맥을 반영해 다음 토큰의 점수와 확률을 계산한 뒤 출력할 토큰을 선택한다. 토큰 ID는 어휘 항목을 구분하는 번호일 뿐이다. 예를 들어 가상의 어휘 목록에서 ‘책’의 ID가 17이고 ‘서점’의 ID가 200이어도, 두 번호의 차이인 183이 의미상 거리를 나타내지는 않는다. 반면 임베딩은 학습된 수치 벡터(vector)이며, 같은 표현 공간 안에서 의미적 관계를 비교하는 데 사용한다. 문서 검색용 임베딩과 모델 내부의 토큰 표현은 목적과 모델이 다르므로 같은 것으로 취급하지 않는다.

셀프 어텐션(self-attention)은 입력의 각 요소가 다른 요소를 얼마나 참고할지 계산하는 방법이다. 쿼리(Query)와 키(Key)의 관계로 가중치를 구하고, 그 가중치에 따라 값(Value)을 조합해 새로운 표현을 만든다. 위치 정보(positional information)는 단어의 순서도 표현에 반영한다. 같은 단어를 사용해도 순서에 따라 문장의 뜻이 달라질 수 있기 때문이다. 모델은 여러 층을 거치며 표현을 갱신하고, 마지막에 계산한 점수인 로짓(logits)을 확률 분포로 바꾼다. 이때 높은 확률은 모델이 그 출력을 더 그럴듯하게 예측했다는 뜻이지, 외부 자료로 사실 여부를 검증했다는 뜻은 아니다.

트랜스포머(Transformer)가 반드시 인코더(encoder)와 디코더(decoder)를 모두 포함하는 것은 아니다. 용도에 따라 인코더 중심 또는 디코더 중심 등으로 구성할 수 있다. 또한 훈련(training) 중 계산을 병렬로 수행하는 것과, 자기회귀 생성(autoregressive generation)에서 다음 토큰을 차례로 출력하는 것은 구분해야 한다. 모델 파라미터 수(parameter count), 컨텍스트 한도(context limit), 실제 업무 품질도 서로 다른 지표다. 파라미터가 더 많은 모델이라고 모든 업무에서 품질이나 비용 효율이 더 좋은 것은 아니다.

출처: AIF 영역 2 출처, 트랜스포머 구성요소, FM과 과업별 ML 선택. 강좌의 임베딩=입력 ID 집합이라는 단순화를 그대로 채택하지 않았다.

B 생성 방식과 입출력 모달리티의 분리

한 모델이 텍스트로 이미지를 설명한다고 해서 이미지 생성도 지원하는 것은 아니다. 임베딩 모델은 유사도 검색에 쓸 벡터를 만들 수 있지만 대화 답변을 생성하는 API와 다르다. 잠재 공간에서 작동하는 확산은 원본 픽셀 전체에서 계산하는 방식과 효율이 다를 수 있다. 합성 데이터는 실제 데이터의 대체 후보이지 원본 분포·희귀 사건·개인정보 안전을 자동 보장하지 않는다.

자체 사례: 창고 제품 사진에서 손상 설명을 생성하려면 이미지 입력과 텍스트 출력을 지원하는 모델이 필요하다. 새 포장 디자인 이미지를 만들려면 이미지 출력 모델이 필요하다. 제품명을 입력해 카탈로그 사진을 찾는 과업은 검색 임베딩과 색인이 우선일 수 있다. 세 과업에 같은 모델을 강제하지 않는다.

출처: AIF 영역 2 출처, GAN 구조와 생성 모델 구분, 파운데이션 모델의 선택과 AIF-C01 영역 2 시험 가이드. VAE 상세 구현은 공식 한국어 전용 근거 보강 전의 개념 수준으로 남긴다. 강좌에서 Whisper·AudioLM을 확산 예로 묶는 설명은 구조 검증이 필요한 항목이며, 본 표의 확정 예시로 채택하지 않았다. 강좌의 데이터 정제 후 사용 비율 1~3%도 일반 규칙으로 쓰지 않는다.

C 프롬프트와 학습과 기억은 다르다

인컨텍스트 학습(in-context learning)은 프롬프트(prompt)에 담긴 지침과 예시를 모델이 이번 응답에 활용하는 방식이다. 모델의 가중치(weights)를 바꾸는 훈련은 아니다. 제로샷(zero-shot)은 명시적인 예시 없이 작업을 지시하고, 원샷(one-shot)은 예시 하나를, 퓨샷(few-shot)은 소수의 예시를 제공한다. 예시를 늘리면 컨텍스트 길이와 비용도 늘어날 수 있다. 한쪽으로 치우친 예시를 반복하면 모델의 판단도 그 방향으로 쏠릴 수 있으므로, 별도의 평가 세트(evaluation set)로 프롬프트 변경이 실제 성능을 높였는지 확인한다.

지도 미세 조정(supervised fine-tuning, SFT)은 좋은 입력-출력 쌍 등을 통해 행동을 학습시키는 접근이다. 선호 정렬은 사람의 평가·비교·보상 신호를 이용해 유용성·안전성 등을 개선하려는 목적이며 사실 오류가 사라진다는 보증은 아니다. 최신 정책을 알려주는 문제라면 먼저 검색·컨텍스트 갱신을 검토하고, 반복 출력 형식의 문제라면 프롬프트·스키마·필요시 튜닝을 비교한다.

모델은 보통 각 요청에 포함된 컨텍스트(context)를 바탕으로 응답한다. 대화 앱이 이전 내용을 기억하는 것처럼 보인다면, 앱이 대화 이력·요약·저장된 메모리(memory)를 다음 요청에 다시 넣는지 살펴보자. 장기 기억(long-term memory)을 구현하기 위해 반드시 미세 조정(fine-tuning)을 해야 하는 것은 아니다. 저장 기능을 만들 때는 누구의 정보인지 식별하고, 얼마나 보관할지와 언제 삭제할지를 정해야 한다. 오래되거나 잘못된 정보를 갱신·정정하는 방법도 필요하다. 민감한 정보를 무제한으로 저장해서는 안 된다.

출처: AIF 영역 2 출처, 프롬프트 구성과 퓨샷, 모델 사용자 지정, AgentCore 메모리. 메모리 구현 상세는 공식 보충이며 강좌가 AgentCore를 직접 설명했다고 표시하지 않는다.

D 품질·비용·보안을 함께 평가하기

모델을 평가할 때는 업무별 성공 기준부터 정한다. 요약에서는 원문의 근거를 유지했는지, 내용을 빠뜨리거나 왜곡하지 않았는지를 확인한다. 코드 생성에서는 코드의 동작, 테스트 통과 여부, 보안을 살핀다. 분류(classification)에서는 정확도(accuracy)와 소수 집단에서 발생하는 오류를 함께 보고, 고객 지원에서는 업무 해결 여부, 재문의 비율, 응답 지연, 검토 비용을 측정한다. ROUGE와 BLEU는 참조 답변(reference answer)과 표현이 얼마나 겹치는지 활용하는 지표이므로 부정어·숫자·날짜가 사실에 맞는지까지 보장하지 않는다. 사람이 평가하거나 대규모 언어 모델(large language model, LLM)을 평가자로 사용하더라도 평가 기준과 평가 세트를 정하고, 편향 여부와 반복 평가의 일관성을 확인해야 한다.

자체 예시로 두 반품 사유 요약 모델을 비교해 보자. 모델 A는 문장이 자연스럽지만 주문번호를 바꾸고, 모델 B는 표현이 단순하지만 필수 항목을 그대로 유지한다. 자연스러움만 평가하면 업무에 필요한 정보를 틀리게 쓴 A가 더 높은 점수를 받을 수 있다. 따라서 충실도(Faithfulness), 식별자 보존 여부, 출력 스키마(schema) 준수 여부, 미응답 여부를 각각 평가해야 한다. 응답하지 못한 사례를 제외한 채 평균 점수만 계산해서는 안 된다.

토큰 과금에서는 입력과 출력의 단가·단위가 다를 수 있다. 이미지·음성 과금이 항상 픽셀 하나=토큰 하나라는 뜻은 아니다. 자체 호스팅은 인스턴스 유휴 시간, 메모리, 모델 라이선스, 운영·패치·확장 비용을 포함한다. 관리형 호출에서도 검색·캐시·로그·평가 비용이 남는다. 고정 트래픽인지 변동이 큰지에 따라 경제성이 바뀐다. 특정 모델·가속기/GPU가 늘 최저가라는 규칙은 없다.

서비스를 출시할 때는 모델 품질뿐 아니라 데이터를 사용할 권리가 있는지, 허용된 리전(Region)에서 처리하는지, 보관 조건을 지키는지도 확인한다. 접근 통제(access control)와 최소 권한(least privilege)을 적용하고, 위험한 출력이나 도구 실행을 차단하는 방법과 장애 복구 절차를 마련한다. Nitro, 암호화(encryption), 사설 네트워크(private network)를 사용한다고 프롬프트 인젝션(prompt injection)이 자동으로 방지되지는 않는다. 정당한 접근 권한을 가진 앱이 필요 이상의 정보를 조회하는 문제도 별도로 통제해야 한다. 관리형 서비스가 제공하는 보안 기능과 고객이 책임져야 하는 설정·업무 절차를 구분하자.

출처: AIF 영역 2 출처, 모델 평가와 RAG 평가, 평가자 지표의 의미, Bedrock 데이터 보호, IAM 인증과 인가, 프롬프트 캐싱의 조건. 세부 ROUGE/BLEU 변형은 영역 3 대조에서 보강할 잔여다.

강좌와 현행 자료의 차이 기록

• 강좌의 ‘세금 생성’ 표현을 상품 기능으로 채택하지 않는다. 문맥상 텍스트 생성과 혼동되는 번역 표현이며 원문을 임의 교정 저장하지 않았다.
• 강좌에 있는 GPT-4/과거 서비스 목록·무료 조건·GPU 필수 표현은 현재 모든 모델 지원 규칙이 아니다. 최신 제품별 가격·지원표 확인 없이 도입 지침으로 쓰지 않는다.

에이전트·문맥·워크플로를 한 요청으로 이해하기

에이전트형 AI(agentic AI)는 모델의 답변을 만드는 데서 멈추지 않고, 목표를 이루기 위해 허용된 도구를 선택하고 결과를 확인하며 다음 행동을 정하는 시스템이다. 생성형 AI가 항상 에이전트인 것은 아니다. 정해진 단계로 문서를 요약하는 프로그램은 생성형 AI를 쓰더라도 동적으로 행동을 고르는 에이전트와 다르다.

자체 예시로 출장 지원 앱을 생각해 보자. 출발 날짜가 없으면 사용자에게 묻고, 일정이 정해지면 조회 도구로 항공편을 찾는다. 조회 결과를 바탕으로 후보를 제시하되 실제 결제는 권한 검사와 승인을 거쳐야 한다. 프롬프트는 모델에게 할 일을 지시하는 부분이고, 컨텍스트 엔지니어링(context engineering)은 그 지시와 함께 이번 판단에 필요한 이력·정책·도구 설명·검색 결과를 골라 제공하는 일이다. 긴 이력을 전부 넣기보다 날짜·예산·승인 여부 같은 필수 사실을 보존해야 한다.

단일 에이전트는 상태와 종료 조건을 관리하기 쉽다. 전문 역할을 여러 에이전트로 나누면 복잡한 업무를 분담할 수 있지만, 중복 예약이나 서로 모순된 결정을 막을 조정자가 필요해진다. 역할을 늘리는 것 자체가 품질 향상은 아니다. 메모리는 사용자 선호와 이전 정보를 보관하고, 업무 상태는 예약이 접수·승인·완료 중 어디에 있는지 기록한다. ‘예약할 예정’이라는 메모리를 실제 예약 완료로 취급해서는 안 된다.

모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 외부 도구와 연결하는 공통 규약이다. 업무 흐름을 조정하는 워크플로 오케스트레이션(workflow orchestration)은 단계·분기·실패·대기를 관리한다. MCP 연결이 있다고 결제 권한이나 무한 실행 권한이 생기지는 않는다. 실행 시간·호출 횟수·비용 한도와 사람에게 넘길 조건을 둔다.

근거: AIF 공식 영역 2 가이드, 에이전트의 실행·상태·도구 상세. AIF에서는 개념과 선택 이유를 이해하고 AIP의 SDK 구현 깊이까지 필수 범위로 확대하지 않는다.

모델 API·개발 도구·에이전트 플랫폼을 구분하기

서비스 이름을 외우기 전에 내가 어떤 계층을 만들고 운영할지 정한다. Bedrock은 지원되는 파운데이션 모델을 관리형 API로 활용하는 출발점이다. SageMaker AI는 자체 데이터·모델·컨테이너와 훈련·배포를 더 세밀하게 제어할 때 비교한다. JumpStart는 사전 훈련 모델과 솔루션을 탐색하고 활용하는 경로다. 이 선택은 ‘어느 서비스가 항상 더 좋은가’가 아니라 필요한 제어와 운영 책임의 차이다.

Amazon Quick은 업무 자료를 바탕으로 조사·분석·산출물 작성과 업무 자동화를 돕는 사용자용 도구로 구분한다. Kiro는 에이전트형 코딩과 개발 작업을 돕는 도구다. 이 둘을 직접 호출할 범용 모델 API나 데이터베이스로 외우지 않는다. 개발 도구가 코드를 만들어도 권한·테스트·검토·배포 책임은 개발팀에 남는다.

Strands Agents는 모델·도구를 조합해 에이전트 로직을 만드는 프레임워크 관점이고, Amazon Bedrock AgentCore는 에이전트를 실행하고 외부 시스템과 연결하며 메모리·보안·관찰 기능을 운영하는 플랫폼 관점이다. 프레임워크로 만든 에이전트를 운영 플랫폼에 배치할 수 있지만 두 이름은 같은 기능이 아니다. 일반 상담 문장을 생성하는 데 모든 에이전트 구성요소가 필요한 것도 아니다.

자체 선택 사례: 지원 모델을 간단히 비교하려면 관리형 모델 API에서 시작할 수 있다. 기존 코드의 리팩터링 초안을 얻는 요구는 개발 보조 도구에 가깝다. 고객의 허가 아래 여러 업무 도구를 호출하고 상태를 이어가야 한다면 에이전트 로직과 운영 플랫폼을 함께 검토한다. 어느 경우든 데이터 전달 허가·품질·호출 비용과 사용 조건을 확인한다.

근거: AIF 공식 영역 2, Amazon Quick의 공개 기능 소개, AgentCore 공식 소개, Q Developer 문서의 Kiro 안내와 개발 보조 역할. 기능 계층의 설명이며 각 도구의 요금·IDE·리전·모든 SDK 지원을 검증한 목록은 아니다.

상황형 자기점검

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

1. 대화 기억과 가중치

상담 앱이 이전 두 대화와 승인된 고객 선호를 매 호출에 다시 넣는다. 모델 훈련 작업은 실행하지 않았다. 이 동작의 가장 정확한 설명은?

• A. 새 대화마다 모델의 모든 가중치를 미세 조정했다
• B. 스트리밍을 켰으므로 영구 기억이 자동 생성됐다
• C. 토큰 ID가 가까운 선호끼리 같은 사용자로 판단한다
• D. 앱이 문맥을 구성하는 것이며 모델 가중치를 재훈련한 것은 아니다

2. 말을 길게 하는 상담 모델

새 상담 모델은 평균 대화 길이와 체류 시간을 늘렸지만 해결률은 떨어졌다. 사업 목적은 정확한 해결과 상담 비용 감소다. 가장 타당한 평가 방법은?

• A. 해결률·오류·재문의·건당 총비용을 함께 비교한다
• B. 대화가 길어졌으므로 사업 가치가 개선됐다고 확정한다
• C. 유창한 표현 점수만 측정한다
• D. 출력 토큰이 많을수록 정확하다고 평가한다

3. 어느 계층을 관리할 것인가

팀은 지원되는 여러 파운데이션 모델을 API로 평가하고 싶다. 자체 가중치·GPU 서버를 운영할 필요는 없으며 해당 서비스의 데이터 처리 조건도 충족한다. 시작점으로 적합한 것은?

• A. IAM 정책만 만들면 모델 응답이 생성된다
• B. Amazon Bedrock의 관리형 모델 API
• C. 반드시 자체 EC2 GPU 서버부터 구성한다
• D. AgentCore 메모리를 모델 훈련·추론 엔진으로 사용한다

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