"모델이 우리 회사 업무를 잘 모른다"는 문제를 해결하는 방법은 프롬프트 엔지니어링, RAG, 파인튜닝, 지속 사전학습까지 여러 가지입니다. AIP-C01에서 파인튜닝은 보기에 자주 등장하지만, 정답보다 오답 보기로 나오는 경우가 훨씬 많습니다. 비용과 시간이 많이 드는 방법을 고르기 전에 더 가벼운 방법으로 해결되는지를 먼저 묻기 때문입니다. 이번 포스팅에서는 요구사항별로 커스터마이징 방법을 고르는 기준, 파인튜닝이 오답이 되는 전형적인 시나리오, Bedrock과 SageMaker AI에서 커스텀 모델을 배포하고 관리하는 방법(공식 가이드 1.2.4)을 정리합니다.
먼저 결론: 가벼운 방법부터 검토한다
| 요구사항 | 선택 | |----------|------| | 응답 형식·말투를 바꾸고 싶고, 예시 몇 개면 충분 | 프롬프트 엔지니어링 (시스템 프롬프트, few-shot) | | 자주 바뀌는 사내 문서로 답하고, 출처를 보여줘야 함 | RAG (Bedrock Knowledge Bases) | | 수천 건의 예시로 특정 작업의 형식과 품질을 일관되게 | 파인튜닝 | | 전문 용어로 가득한 대량의 문서로 도메인 언어 자체를 익혀야 함 | 지속 사전학습 (지원 모델 제한) | | 큰 모델의 품질을 작은 모델의 비용·속도로 | 증류(distillation) | | 다른 곳에서 학습한 오픈 모델을 Bedrock API로 서빙 | Custom Model Import |
핵심은 "지식"과 "행동"을 구분하는 것입니다. 모델이 모르는 사실(제품 사양, 정책, 재고)을 알려줘야 한다면 RAG가 맞고, 모델의 행동 방식(출력 형식, 말투, 특정 작업 수행 능력)을 바꿔야 한다면 파인튜닝이 맞습니다. 둘은 배타적이지 않아서, 사내 보고서 양식으로 답하도록 파인튜닝한 모델에 RAG로 최신 문서를 붙이는 조합도 흔합니다.
!커스터마이징 스펙트럼: 왼쪽부터 검토
파인튜닝이 오답이 되는 전형적인 시나리오
시험 보기에서 파인튜닝을 지울 수 있는 신호들입니다.
"가격·재고·정책이 매일 바뀐다": 바뀔 때마다 다시 학습할 수 없으므로 RAG입니다. "답변의 근거 문서를 함께 보여줘야 한다": 학습된 가중치는 출처를 알려주지 못합니다. RAG의 인용 기능을 씁니다. "사용자 권한에 따라 볼 수 있는 문서가 다르다": 가중치에 들어간 지식은 사용자별로 나눌 수 없습니다. RAG와 메타데이터 필터로 권한을 나눕니다. "운영 부담을 최소화하고 빨리 출시해야 한다": 학습 데이터 준비와 학습 작업이 필요 없는 프롬프트나 관리형 RAG가 먼저입니다. "레이블된 데이터가 수십 건뿐이다": 파인튜닝하기에는 부족하므로 few-shot 프롬프트로 시작합니다. "할루시네이션을 줄이고 싶다": 파인튜닝보다 RAG로 근거를 주고 contextual grounding check로 검증하는 쪽이 정답입니다.
반대로 파인튜닝이 정답인 신호도 있습니다. 특정 JSON 구조나 보고서 양식을 항상 지켜야 할 때, 브랜드 고유의 말투가 필요할 때, 분류나 정보 추출처럼 좁은 작업의 정확도를 높여야 할 때, 그리고 긴 few-shot 예시를 매번 보내느라 토큰 비용과 지연이 커졌을 때입니다. 마지막 경우는 예시를 학습으로 옮기면 프롬프트가 짧아져 운영 비용이 줄어듭니다.
비용과 운영 부담 비교
시험 보기에 "가장 비용 효율적인", "운영 오버헤드가 가장 적은"이라는 표현이 붙으면 아래 표의 차이를 떠올리면 됩니다.
| 구분 | 프롬프트 엔지니어링 | RAG | 파인튜닝 | 지속 사전학습 | |------|-------------------|-----|---------|--------------| | 준비물 | 지시문과 예시 몇 개 | 문서 + 벡터 저장소 | 레이블 데이터 수백~수천 건 | 대량의 도메인 문서 | | 초기 비용 | 거의 없음 | 임베딩·인덱싱 | 학습 작업 | 대규모 학습 작업 | | 지식 업데이트 | 프롬프트 수정 | 문서 재동기화 | 재학습 | 재학습 | | 추론 비용 영향 | 프롬프트가 길어지면 증가 | 검색 결과만큼 입력 토큰 증가 | 프롬프트가 짧아져 감소 가능 | 기본 모델과 비슷 | | 출처 제시 | 불가 | 가능 | 불가 | 불가 |
Amazon Bedrock의 커스터마이징 방법
| 방법 | 필요한 데이터 | 용도 | |------|--------------|------| | 지도 파인튜닝 | 레이블된 입력-출력 쌍 | 특정 작업·형식·말투 특화 | | 강화 파인튜닝 | 프롬프트 + Lambda 보상 함수 | 정답 예시 대신 품질 점수로 학습 | | 증류 | 사용 사례 프롬프트 (교사 모델이 응답 생성) | 작은 학생 모델로 비용·지연 절감 | | 지속 사전학습 | 레이블 없는 도메인 텍스트 | 도메인 언어 습득 (지원 모델 제한) | | Custom Model Import | 외부에서 학습한 오픈 모델 가중치 | Bedrock API로 서빙 |
지도 파인튜닝 데이터는 S3에 JSONL로 준비합니다. 모델에 따라 입력-출력 쌍 형식이나 대화(messages) 형식을 쓰며, 입력-출력 형식은 다음과 같습니다.
학습은 으로 시작하며, Step Functions의 통합으로 학습 완료까지 기다리는 파이프라인을 만들 수도 있습니다. 학습 비용은 학습 데이터 토큰 수에 에포크 수를 곱해 계산되고, 커스텀 모델 보관 비용이 매달 붙습니다. 학습된 모델은 Provisioned Throughput을 구매하거나, 지원 모델의 경우 커스텀 모델 배포(on-demand)로 사용한 만큼만 내고 호출할 수 있습니다.
증류는 "큰 모델 수준의 품질이 필요하지만 비용과 지연을 줄여야 한다"는 시나리오의 답입니다. 교사 모델이 사용 사례 프롬프트에 대한 응답을 만들고, 그 응답으로 학생 모델을 학습시키는 과정을 Bedrock이 자동화합니다.
파인튜닝을 고른 뒤: 데이터·보안·평가
학습 데이터의 질이 결과를 좌우합니다. 실제 서비스에서 나올 입력과 같은 분포의 예시를 모으고, 중복과 잘못된 레이블을 정리하고, 학습용과 검증용 데이터를 나눕니다. 에포크 수, 배치 크기, 학습률 같은 하이퍼파라미터를 지정할 수 있으며, 학습 손실은 계속 줄어드는데 검증 손실이 다시 오르면 과적합 신호이므로 에포크를 줄이거나 데이터를 늘립니다.
보안 요구사항도 시험에 나옵니다. 학습 데이터와 결과 모델은 고객 계정의 S3와 KMS 키로 암호화할 수 있고, 학습 작업이 VPC를 통해 S3에 접근하도록 설정할 수 있습니다. 파인튜닝은 기본 모델의 비공개 사본을 만드는 것이며, 고객의 데이터가 기본 모델 학습에 쓰이지 않습니다. 개인정보가 섞인 데이터라면 학습 전에 Amazon Comprehend나 Macie로 PII를 찾아 제거하거나 마스킹합니다.
학습이 끝나면 바로 운영에 넣지 말고 같은 평가 데이터셋으로 기본 모델과 커스텀 모델을 Bedrock Evaluations에서 비교합니다. 개선 폭이 크지 않다면 Provisioned Throughput 비용을 들일 이유가 없으므로, 평가 결과가 "파인튜닝을 계속할지"를 결정하는 근거가 됩니다.
SageMaker AI로 커스텀 모델 배포·관리하기
공식 가이드 1.2.4는 Bedrock 밖에서 학습한 모델의 배포와 수명 주기 관리도 다룹니다.
LoRA(low-rank adaptation)는 기본 모델 가중치는 그대로 두고 작은 어댑터 행렬만 학습하는 방법입니다. 어댑터 파일이 작아 도메인별·고객별로 여러 개를 만들기 쉽고, SageMaker AI의 추론 컴포넌트를 쓰면 기본 모델 하나를 올린 엔드포인트에서 여러 LoRA 어댑터를 바꿔 가며 서빙할 수 있습니다. 어댑터를 기본 모델과 분리해 버전별로 저장하면 어댑터만 교체하거나 되돌릴 수 있습니다.
SageMaker Model Registry는 모델 버전을 모델 패키지 그룹으로 관리하고, 각 버전에 승인 상태(, , )를 붙입니다. 평가를 통과한 버전을 승인하면 EventBridge 이벤트로 배포 파이프라인이 실행되도록 연결하는 것이 일반적입니다.
배포할 때는 블루/그린 배포의 트래픽 전환 방식(한 번에 전환, 카나리, 선형)을 고르고 CloudWatch 알람을 연결해, 오류율이나 지연이 기준을 넘으면 자동으로 이전 버전으로 롤백합니다.
대형 모델은 일반 ML 모델과 배포 방식이 다릅니다(공식 가이드 2.2.2). GPU 메모리에 맞추기 위해 여러 GPU에 모델을 나눠 올리는 텐서 병렬화, LLM 전용 추론 컨테이너, 그리고 모델 다운로드와 로딩에 시간이 걸리므로 , 같은 시간 제한을 늘리는 설정이 필요합니다.
임베딩 모델 커스터마이징은 따로 생각한다
RAG 검색 품질이 낮을 때 임베딩 모델을 도메인 데이터로 파인튜닝하거나 다른 모델로 바꾸는 방법도 있습니다. 다만 임베딩 모델이 바뀌면 기존에 저장된 벡터와 새 질문의 벡터가 같은 공간에 있지 않으므로, 전체 문서를 다시 임베딩하고 인덱스를 다시 만들어야 합니다. 그래서 시험에서는 임베딩 교체보다 청킹 조정, 메타데이터 필터, 하이브리드 검색, 리랭킹처럼 재인덱싱 없이 적용할 수 있는 방법이 먼저 정답이 되는 경우가 많습니다.
시나리오로 연습하기
보험사가 약관 문서 2,000개를 근거로 상담원 질문에 답하고 답변마다 해당 조항을 표시해야 하며, 약관은 분기마다 개정된다. 정답은 RAG입니다. 출처 표시와 잦은 개정 두 조건 모두 파인튜닝으로는 해결되지 않습니다. 쇼핑몰이 상품 정보를 정해진 6개 항목의 JSON 설명으로 바꾸는데, few-shot 예시 20개를 넣느라 요청당 입력 토큰이 4,000개를 넘고, 승인된 과거 설명이 5,000건 있다. 정답은 파인튜닝입니다. 형식을 일관되게 지키면서 프롬프트를 줄여 비용과 지연을 낮출 수 있습니다. 대형 모델로 만든 문의 분류 품질은 만족스럽지만 하루 수백만 건이라 비용과 지연이 부담이다. 정답은 증류입니다. ML 팀이 SageMaker AI에서 파인튜닝한 오픈 모델을 다른 Bedrock 모델과 같은 API로 서버리스 호출하고 싶다. 정답은 Custom Model Import입니다.
시험 핵심 정리
"자주 바뀌는 정보로 답하고 출처를 표시" -- RAG (Bedrock Knowledge Bases) "사용자 권한별로 볼 수 있는 지식이 다름" -- RAG + 메타데이터 필터 (파인튜닝 아님) "레이블 데이터가 적고 빨리 적용" -- 프롬프트 엔지니어링 (few-shot) "항상 같은 출력 형식·브랜드 말투" -- 지도 파인튜닝 "정답 예시 대신 품질 기준으로 학습" -- 강화 파인튜닝 (Lambda 보상 함수) "큰 모델 품질을 작은 모델 비용으로" -- 모델 증류 (distillation) "외부에서 학습한 오픈 모델을 Bedrock에서 서버리스로" -- Custom Model Import "레이블 없는 도메인 문서로 언어 습득" -- 지속 사전학습 "기본 모델 하나로 여러 도메인 특화 모델 서빙" -- LoRA 어댑터 + SageMaker 추론 컴포넌트 "모델 버전 관리와 승인 후 배포" -- SageMaker Model Registry "새 모델 배포 중 오류 시 자동 되돌리기" -- 블루/그린 배포 + CloudWatch 알람 롤백 "임베딩 모델 교체 시 필수 작업" -- 전체 문서 재임베딩·재인덱싱