블로그로 돌아가기
LLMRAG파인튜닝RLHF프롬프트 엔지니어링증류AI 전략
튜닝할 것인가, 말 것인가: LLM에 내 데이터를 연결하는 완전 가이드
프롬프트 엔지니어링, RAG, SFT, RLHF, 증류 — LLM에 내 데이터를 연결하는 5가지 방법의 역사부터 2026년 현재의 활용법까지. 셰익스피어의 질문을 빌려, AI 시대의 가장 실용적인 선택지를 정리한다.
코어닷투데이2026-04-0760분
"To tune, or not to tune" — AI 시대의 햄릿
"To be, or not to be, that is the question." — 윌리엄 셰익스피어, 《햄릿》 3막 1장
셰익스피어의 햄릿이 존재의 본질을 고민했다면, 2026년의 AI 엔지니어들은 다른 종류의 실존적 질문과 씨름한다.
"이 모델을 튜닝해야 하나, 말아야 하나?"
ChatGPT가 세상에 등장한 지 3년. 이제 대부분의 기업이 "LLM을 써야 한다"는 데는 동의한다. 진짜 어려운 질문은 그다음이다 — 어떻게 우리 데이터를 LLM에 연결할 것인가?
Google Cloud의 AI/ML 스페셜리스트인 Kamilla Kurta와 Filipe Gracio 박사는 이 질문에 대한 명쾌한 의사결정 프레임워크를 제시했다. 이 글에서는 그들의 가이드를 바탕으로, 역사적 맥락부터 2026년의 최신 트렌드까지 — 각 방법이 왜 탄생했고, 언제 써야 하며, 어떻게 조합하는지를 풍부한 사례와 함께 깊이 파헤쳐 본다.
1장: 여기까지 오는 데 걸린 시간 — AI 데이터 활용의 역사
LLM에 데이터를 연결하는 오늘날의 기법들은 하루아침에 나온 것이 아니다. 수십 년간의 연구가 하나의 흐름으로 수렴한 결과다.
1986
역전파 알고리즘의 대중화
Rumelhart, Hinton, Williams의 역전파(backpropagation) 논문. 신경망을 학습시키는 기본 원리가 확립된다. 이후 모든 "튜닝"의 수학적 기반.
2006
딥러닝 르네상스 시작
Geoffrey Hinton이 Deep Belief Networks 논문 발표. "딥러닝"이라는 용어가 부활하고, 대규모 신경망 학습의 가능성이 열린다.
2015
지식 증류의 등장
Hinton, Vinyals, Dean이 "Distilling the Knowledge in a Neural Network" 발표. 큰 모델의 지식을 작은 모델로 옮기는 개념이 처음 체계화된다.
2017
Transformer — "Attention Is All You Need"
Vaswani et al.의 혁명적 논문. Self-attention 메커니즘이 NLP의 패러다임을 바꾸고, 이후 모든 LLM의 기반이 된다.
2018
BERT — Pre-train & Fine-tune 패러다임
Google의 Devlin et al. "사전학습 후 파인튜닝(pre-train then fine-tune)" 패러다임을 대중화. 모든 NLP 태스크의 접근법이 바뀐다.
2020
GPT-3 — 프롬프트 엔지니어링의 탄생
Brown et al. "Language Models are Few-Shot Learners." 1,750억 파라미터 모델이 별도 학습 없이도 프롬프트만으로 다양한 태스크를 수행할 수 있음을 증명. In-Context Learning 시대 개막.
2020
RAG의 탄생
Lewis et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." 모델이 모든 것을 기억할 필요 없이, 필요할 때 외부 지식을 검색해서 사용하는 개념을 제시.
2021
LoRA — 효율적 파인튜닝
Hu et al. "LoRA: Low-Rank Adaptation of Large Language Models." 전체 모델을 다시 학습시키지 않고도 소수의 파라미터만 조정하여 파인튜닝하는 방법. 비용 혁명의 시작.
2022
InstructGPT & RLHF
Ouyang et al. "Training language models to follow instructions with human feedback." 인간 피드백을 통한 강화학습(RLHF)으로 모델을 사용자 의도에 맞게 정렬하는 기법. ChatGPT의 핵심 기술.
2024–2026
방법들의 융합 시대
RAG + 파인튜닝 + 에이전트의 결합. 100만 토큰 이상의 컨텍스트 윈도우. 특화형 소형 모델의 부상. "어떤 방법 하나"가 아닌 "방법들의 조합"이 정답이 되는 시대.
이 타임라인에서 주목할 점이 있다. 2020년을 기점으로 패러다임이 완전히 바뀌었다는 것이다. 이전에는 "데이터로 모델을 학습시킨다"가 유일한 방법이었다. 하지만 GPT-3 이후, 학습 없이도 모델을 활용하는 방법이 등장했다. 이것이 바로 오늘의 이야기가 시작되는 지점이다.
2장: 다섯 가지 무기 — 각각 언제, 왜 쓰는가
LLM에 데이터를 연결하는 방법은 크게 튜닝하지 않는 방법과 튜닝하는 방법으로 나뉜다.
LLM 데이터 연결 방법 분류
비(非)튜닝 방법
모델을 바꾸지 않는다
튜닝 방법
모델 자체를 변경한다
프롬프트 엔지니어링
Prompt Engineering
지시문에 데이터를 포함
RAG
Retrieval-Augmented Generation
실시간 검색 후 전달
SFT / PEFT
Supervised Fine-Tuning
입출력 쌍으로 학습
RLHF
Reinforcement Learning
인간 피드백으로 정렬
증류
Distillation
큰 모델 → 작은 모델
하나씩 깊이 들어가 보자.
2-1. 프롬프트 엔지니어링: "메모를 건네주는 것"
개념
프롬프트 엔지니어링은 가장 단순하고 강력한 방법이다. 모델을 바꾸지 않고, 지시문(프롬프트)에 데이터를 직접 넣어주는 것이다.
비유하자면 이렇다. 당신이 변호사에게 법률 상담을 받으러 갔다고 하자. 변호사는 이미 법에 대한 깊은 지식이 있다(= LLM의 사전학습된 지식). 하지만 당신의 구체적인 상황은 모른다. 그래서 당신은 관련 서류를 건네주며 설명한다(= 프롬프트에 데이터를 포함). 변호사는 자신의 법률 지식과 당신이 건넨 서류를 결합하여 답변을 준다.
역사적 배경
프롬프트 엔지니어링의 위력이 처음 증명된 것은 GPT-3 논문(Brown et al., 2020)이다. OpenAI 연구진은 1,750억 개의 파라미터를 가진 모델이 별도의 학습 없이도 프롬프트에 몇 가지 예시를 넣어주기만 하면(few-shot learning) 다양한 태스크를 수행할 수 있음을 보였다.
이것은 혁명적이었다. 그 이전까지 AI를 새로운 태스크에 적용하려면 반드시 학습 데이터를 모아 모델을 재학습시켜야 했다. GPT-3는 "학습 없이도 된다"는 가능성을 처음 보여준 것이다.
실전 사례
사례 1: 고객센터 FAQ 봇
회사 FAQ 50개를 시스템 프롬프트에 넣고 "이 FAQ를 참고해서 답변해줘"라고 지시. 별도 개발 없이 30분 만에 프로토타입 완성.
사례 2: 이메일 분류
"다음 이메일을 [긴급/일반/스팸] 중 하나로 분류해줘. 예시: ..." 프롬프트에 10개의 예시만 넣으면 90% 이상의 정확도.
한계: 실시간 데이터에는 약하다
항공권 가격, 주가, 날씨처럼 실시간으로 변하는 데이터는 프롬프트에 미리 넣어둘 수 없다. 이때 RAG가 필요하다.
2026년 현재
컨텍스트 윈도우가 폭발적으로 커졌다. Gemini 2.5는 100만 토큰, Claude 4는 100만+ 토큰을 처리한다. 이것은 프롬프트 엔지니어링의 범위를 극적으로 넓혔다. 예전에는 프롬프트에 문서 2~3페이지밖에 못 넣었지만, 지금은 책 한 권 전체를 넣을 수 있다.
하지만 컨텍스트 윈도우가 커졌다고 해서 프롬프트 엔지니어링이 만능이 된 것은 아니다. 컨텍스트에 너무 많은 정보를 넣으면 "건초 더미에서 바늘 찾기(Needle in a Haystack)" 문제가 발생한다 — 모델이 중요한 정보를 놓치거나, 비용이 폭증할 수 있다.
2-2. RAG: "실시간으로 도서관에서 책을 찾아오는 것"
개념
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 질문이 들어올 때마다 관련 데이터를 실시간으로 검색해서 프롬프트에 넣어주는 방법이다.
비유하자면 이렇다. 시험을 볼 때 오픈 북(open-book) 시험과 같다. 학생(= LLM)이 모든 것을 암기할 필요 없이, 시험 중에 교과서(= 데이터베이스)를 펼쳐서 관련 내용을 찾아 답안을 작성한다. 핵심은 얼마나 빠르고 정확하게 관련 페이지를 찾느냐이다.
역사적 배경
RAG라는 개념을 처음 공식화한 것은 Meta AI(당시 Facebook AI Research)의 Patrick Lewis et al. 논문 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020)이다.
이 논문의 핵심 통찰은 명쾌했다:
"LLM이 세상의 모든 지식을 파라미터에 저장할 필요는 없다. 필요할 때 외부에서 가져오면 된다."
이 아이디어가 왜 혁명적이었을까? 당시까지 LLM의 지식은 모두 파라미터에 암기된 것(parametric knowledge)이었다. 학습 데이터에 없는 정보는 알 수 없었고, 학습 후에 세상이 바뀌어도 모델의 지식은 갱신되지 않았다. RAG는 이 근본적 한계를 외부 검색으로 해결했다.
작동 방식
Step 1
색인(Indexing) — 문서를 작은 조각(청크)으로 나누고, 각 조각을 벡터 임베딩으로 변환하여 벡터 DB에 저장한다.
Step 2
검색(Retrieval) — 사용자 질문도 벡터로 변환하고, 벡터 DB에서 가장 유사한 문서 조각을 찾는다.
Step 3
증강(Augmentation) — 찾은 문서 조각을 프롬프트에 "참고 자료"로 첨부한다.
Step 4
생성(Generation) — LLM이 원본 질문 + 참고 자료를 보고 답변을 생성한다. 출처도 함께 제공할 수 있다.
실전 사례
문제: 법률 AI 챗봇이 할루시네이션을 생성
한 로펌이 GPT-4로 법률 상담 챗봇을 만들었다. 그런데 챗봇이 존재하지 않는 판례를 인용하는 문제가 발생. 실제로 2023년 미국에서 변호사가 ChatGPT가 만들어낸 가짜 판례를 법원에 제출하여 징계를 받은 사건이 있었다.
해결: RAG로 실제 판례 DB에서 검색
실제 판례 데이터베이스를 벡터 DB로 구축하고, 답변 시 반드시 검색된 실제 판례만 인용하도록 RAG 파이프라인을 구성. 출처 링크도 함께 제공하여 검증 가능하게 함.
결과: 할루시네이션 95% 감소
답변의 근거가 명확해지면서 변호사들의 신뢰도가 올라가고, 리뷰 시간이 70% 단축됨.
RAG가 빛나는 순간
| RAG를 써야 할 때 | RAG가 불필요할 때 |
|---|---|
| 답변에 출처/인용이 필요할 때 | 일반적인 지식만 필요할 때 |
| 데이터가 자주 업데이트될 때 | 데이터가 정적이고 양이 적을 때 |
| 사용자별 접근 권한이 다를 때 | 모든 사용자에게 같은 정보일 때 |
| 할루시네이션이 치명적인 도메인 | 창작/브레인스토밍 용도 |
2-3. 지도 파인튜닝 (SFT): "특수 훈련을 받는 것"
개념
지도 파인튜닝(Supervised Fine-Tuning, SFT)은 모델에게 "이런 입력이 들어오면 이런 출력을 내놔"라는 입출력 쌍을 직접 가르치는 것이다.
비유하자면, 인턴 교육이다. 인턴(= 사전학습된 LLM)은 대학에서 기본 지식을 배웠지만, 회사의 구체적인 업무 방식은 모른다. 선임(= 학습 데이터)이 "이런 이메일이 오면 이렇게 분류해", "이런 보고서는 이 형식으로 작성해"라고 구체적인 사례를 보여주며 가르친다.
역사적 배경
파인튜닝은 사실 딥러닝의 가장 오래된 테크닉 중 하나다. 2018년 BERT 논문(Devlin et al.)이 확립한 "사전학습 → 파인튜닝(pre-train → fine-tune)" 패러다임은 NLP의 표준이 되었다.
하지만 GPT-3 이후 모델 크기가 수십억~수천억 파라미터로 커지면서, 전체 파인튜닝(Full Fine-tuning)은 엄청난 비용이 드는 작업이 되었다. 이에 따라 PEFT(Parameter-Efficient Fine-Tuning) 방법론이 등장했다.
가장 대표적인 것이 LoRA(Low-Rank Adaptation)다(Hu et al., 2021). 핵심 아이디어는 간단하다:
"모델의 전체 가중치를 바꾸지 말고, 작은 행렬 두 개를 추가해서 그것만 학습시키자."
LoRA를 쓰면 학습해야 할 파라미터가 전체의 0.1~1% 수준으로 줄어든다. GPU 비용이 10~100배 절감되면서도 성능은 거의 비슷하다.
학습 파라미터 비율 비교 — LoRA는 전체의 1% 미만만 학습
실전 사례
사례 1: 의료 기록 구조화
의사가 자유롭게 작성한 진료 기록에서 [진단명, 처방약, 용량, 투여 기간]을 자동 추출. 5,000건의 입출력 쌍으로 SFT한 모델이 수작업 대비 95%의 정확도 달성.
사례 2: 회의록 자동 분류
Google Cloud 블로그에서 소개한 사례. 회의 녹취록을 "마케팅", "법무", "고객지원" 등으로 자동 분류. 수천 건의 분류 예시를 학습 데이터로 제공하여 SFT 수행.
사례 3: 코드 리뷰 자동화
사내 코딩 컨벤션에 맞게 코드 리뷰 코멘트를 생성하는 모델. [코드 diff → 리뷰 코멘트] 쌍 10,000건으로 SFT. 시니어 개발자의 리뷰 스타일을 모델이 학습.
2-4. RLHF: "인간의 취향을 학습하는 것"
개념
RLHF(Reinforcement Learning from Human Feedback)는 "정답"을 명확히 정의하기 어려운 경우에 사용한다. 인간의 선호도를 학습시키는 것이다.
비유하자면, 와인 소믈리에 교육이다. "좋은 와인"의 정확한 공식은 없다. 하지만 경험 많은 소믈리에가 두 와인을 비교하며 "이게 더 나아"라고 말해주면, 그 선호도 패턴을 학습할 수 있다. RLHF도 마찬가지다 — 두 개의 답변을 보여주고 "이게 더 좋아"라고 인간이 피드백을 주면, 그 선호도를 모델이 학습한다.
역사적 배경
RLHF의 근간이 되는 아이디어는 OpenAI의 InstructGPT 논문(Ouyang et al., 2022)에서 대중화되었다.
알고리즘의 핵심은 세 단계다:
Phase 1
SFT 모델 준비 — 먼저 지도 파인튜닝으로 기본적인 지시 따르기를 학습시킨다.
Phase 2
보상 모델(Reward Model) 학습 — 같은 프롬프트에 대해 두 가지 답변을 생성하고, 인간 평가자가 "이게 더 낫다"고 선택. 이 선호도 데이터로 보상 모델을 학습.
Phase 3
PPO로 최적화 — 보상 모델의 점수를 높이는 방향으로, 강화학습(PPO 알고리즘)을 통해 LLM을 최적화.
이 기법이 바로 ChatGPT를 ChatGPT답게 만든 핵심 기술이다. 같은 GPT-3.5 모델도 RLHF 전후로 사용자 경험이 완전히 달랐다.
왜 SFT만으로는 부족한가?
SFT는 "정답이 하나인 문제"에 강하다. 하지만 현실 세계의 많은 문제는 "정답"이 여럿이거나, 정답의 기준이 주관적이다.
| 측면 | SFT가 잘하는 것 | RLHF가 필요한 것 |
|---|---|---|
| 출력 형태 | 정해진 형식 (JSON, 분류 라벨) | 자연스러운 대화, 설명 |
| 정답 기준 | 객관적 (맞다/틀리다) | 주관적 (더 자연스럽다/덜 자연스럽다) |
| 학습 데이터 | 입출력 쌍 (input → output) | 선호도 쌍 (A vs B, A가 더 좋음) |
| 대표 사례 | 분류, 요약, 구조화 | 브랜드 톤, 안전성, 스타일 |
실전 사례
사례: 브랜드 보이스 학습
한 글로벌 패션 브랜드가 고객 응대 챗봇에 "럭셔리하면서도 친근한" 톤을 원했다. 같은 질문에 대해 두 가지 스타일의 답변을 비교하는 선호도 데이터 3,000쌍을 만들고 RLHF를 적용. "안녕하세요, 고객님" 대신 "반갑습니다 ✨ 무엇을 도와드릴까요?"라는 브랜드 특유의 톤을 학습.
2026년의 트렌드: RLHF의 비용과 복잡성을 줄이기 위해 DPO(Direct Preference Optimization)(Rafailov et al., 2023)가 빠르게 대안으로 부상했다. DPO는 보상 모델 없이 선호도 데이터만으로 직접 최적화하여, RLHF와 비슷한 성능을 훨씬 간단하게 달성한다.
2-5. 증류 (Distillation): "대가(大家)의 기술을 제자에게 전수하는 것"
개념
증류(Distillation)는 두 가지 목표를 동시에 달성하는 영리한 기법이다:
- 더 작고 빠른 모델을 만든다.
- 그 모델을 특정 태스크에 특화시킨다.
비유하자면, 장인과 도제의 관계다. 대장장이(= 대형 모델)가 수십 년간 쌓은 기술을 도제(= 소형 모델)에게 전수한다. 도제는 대장장이의 모든 기술을 배울 필요는 없고, 칼 만드는 기술(= 특정 태스크)만 집중적으로 배운다. 결과적으로 도제는 칼을 만드는 데에 있어서는 대장장이에 거의 근접한 실력을 갖추게 된다.
역사적 배경
지식 증류의 개념은 Geoffrey Hinton이 2015년에 발표한 "Distilling the Knowledge in a Neural Network" 에서 체계화되었다.
핵심 아이디어는 "소프트 타겟(soft target)"이다:
지식 증류의 핵심: Hard vs Soft Target
Hard target (정답 라벨)
고양이: 100%
Soft target (교사 모델 출력)
고양이: 70%
호랑이: 20%
개: 10%
Hard target은 "이건 고양이다"라는 단순한 정답만 알려준다. 하지만 Soft target은 "고양이일 확률 70%, 호랑이일 확률 20%, 개일 확률 10%"라는 풍부한 정보를 전달한다. "고양이와 호랑이는 비슷하다"는 관계까지 학습할 수 있는 것이다. 이것이 큰 모델에서 작은 모델로 "지식을 증류하는" 핵심 메커니즘이다.
실전 사례
문제: API 비용이 월 $50,000
한 이커머스 회사가 GPT-4로 상품 설명을 자동 생성 중. 하루 10만 건 처리에 월 API 비용만 5만 달러. 모델을 바꾸면 품질이 떨어짐.
해결: GPT-4 → 소형 모델 증류
GPT-4로 10만 건의 고품질 상품 설명을 생성. 이 데이터(입력: 상품 정보, 출력: GPT-4의 설명)로 30억 파라미터급 소형 모델을 학습시킴.
결과: 비용 95% 절감, 품질 90% 유지
소형 모델을 자체 서버에서 운영. 월 비용 2,500. 응답 속도도 3배 빨라짐. 상품 설명이라는 특정 태스크에서는 GPT-4의 90% 수준 품질 달성.
3장: 의사결정 트리 — 어떤 방법을 선택할 것인가
이제 다섯 가지 무기를 모두 알게 되었다. 그렇다면 내 상황에는 어떤 방법을 써야 할까? Google Cloud의 Kurta와 Gracio 박사가 제시한 의사결정 프레임워크를 확장하여 정리했다.
출력에 출처/인용이 필요한가?
Yes → RAG
|
No ↓
데이터가 안정적이고 대량인가?
No → 프롬프트 엔지니어링
|
Yes ↓
원하는 출력을 정의하기 어려운가?
Yes → RLHF / DPO
|
No ↓
커스터마이징 정도 / 예산 / 속도 트레이드오프
높은 커스텀, 높은 비용
Full Fine-tuning 중간 수준
증류(Distillation) 낮은 비용, 빠른 속도
SFT / PEFT (LoRA)
Full Fine-tuning 중간 수준
증류(Distillation) 낮은 비용, 빠른 속도
SFT / PEFT (LoRA)
비용-성능 트레이드오프 한눈에 보기
| 방법 | 구현 난이도 | 비용 | 속도 | 학습 데이터 필요량 |
|---|---|---|---|---|
| 프롬프트 엔지니어링 | ⭐ 매우 쉬움 | $ 낮음 | 즉시 | 없음 |
| RAG | ⭐⭐ 보통 | $$ 중간 | 수 일 | 문서 DB만 필요 |
| SFT (LoRA) | ⭐⭐⭐ 중상 | $$ 중간 | 수 일~주 | 수백~수천 쌍 |
| RLHF | ⭐⭐⭐⭐ 어려움 | $$$ 높음 | 수 주 | 수천 선호도 쌍 |
| 증류 | ⭐⭐⭐ 중상 | $$$ 높음 (초기) | 수 주 | 수만 건 (교사 출력) |
| Full Fine-tuning | ⭐⭐⭐⭐⭐ 매우 어려움 | $$$$ 매우 높음 | 수 주~월 | 수만~수십만 |
4장: 진짜 파워는 조합에 있다
Google Cloud 블로그의 Kurta와 Gracio 박사가 강조하는 핵심 메시지가 있다:
"왜 방법들을 조합하면 안 되나요? 조합이 가능하고, 종종 최선의 선택입니다!"
현실의 프로덕션 시스템에서는 단일 방법을 쓰는 경우가 오히려 드물다. 가장 강력한 시스템들은 여러 기법을 레이어처럼 쌓는다.
실전 조합 패턴
실전에서 자주 쓰이는 조합 패턴
패턴 1: RAG + 프롬프트 엔지니어링
가장 흔한 조합. 검색 결과를 잘 구조화된 프롬프트에 넣어 품질 향상
패턴 2: SFT + RAG
파인튜닝으로 도메인 언어/형식을 학습한 뒤, RAG로 최신 데이터를 공급
패턴 3: 증류 + RAG + 프롬프트
대형 모델로 소형 전용 모델을 만들고, RAG와 프롬프트로 보강. 비용 최적화의 끝판왕
사례: 의료 AI 어시스턴트의 풀스택 구성
의료 AI 시스템 아키텍처
Layer 1
RLHF — 환자에게 공감적이고 안전한 톤으로 응답하도록 정렬
Layer 2
SFT — 의학 용어를 정확하게 사용하고, 진료 기록 형식에 맞게 출력
Layer 3
RAG — 최신 의학 논문, 약물 정보, 가이드라인을 실시간 검색
Layer 4
프롬프트 — "반드시 출처를 인용하고, 불확실한 경우 전문의 상담을 권유하라"
5장: 2026년, 그리고 앞으로
2024년 구글 블로그가 작성된 시점과 지금(2026년)은 불과 2년 차이지만, 변화는 극적이다.
변화 1: 컨텍스트 윈도우의 폭발
2024년의 "큰 컨텍스트"는 128K 토큰이었다. 2026년에는 100만 토큰이 표준이 되었다. 이것은 프롬프트 엔지니어링의 경계를 크게 넓혔다. 예전에는 RAG가 필수였던 시나리오가 이제는 프롬프트 엔지니어링만으로 해결되기도 한다.
하지만 RAG가 불필요해진 것은 아니다. 100만 토큰이면 책 2~3권 분량이지만, 기업의 지식 베이스는 그보다 훨씬 크다. 또한 RAG의 핵심 가치인 출처 추적과 접근 권한 제어는 컨텍스트 윈도우와 무관하게 필요하다.
변화 2: 에이전트 시대의 도래
2026년의 가장 큰 변화는 에이전트(Agent)의 부상이다. 에이전트는 LLM이 스스로 판단하여 도구를 사용하고, 다단계 작업을 자율적으로 수행하는 시스템이다.
에이전트 시대에서 이 글의 기법들은 새로운 역할을 맡게 된다:
| 기법 | 기존 역할 (2024) | 에이전트 시대 역할 (2026) |
|---|---|---|
| 프롬프트 엔지니어링 | 사용자 질문에 맥락 추가 | 에이전트의 시스템 프롬프트 설계, 도구 사용 지침 정의 |
| RAG | 질문-답변 시 관련 문서 검색 | 에이전트가 자율적으로 지식 검색, 멀티-소스 RAG |
| SFT | 특정 태스크에 모델 특화 | 에이전트의 도구 호출 능력 강화, 출력 형식 특화 |
| RLHF | 톤/스타일 정렬 | 에이전트의 의사결정 품질과 안전성 정렬 |
| 증류 | 비용 절감 | 에이전트 내 경량 서브 모델 운영, 엣지 디바이스 배포 |
변화 3: "시작은 단순하게" 원칙의 강화
Google Cloud 블로그의 마지막 조언은 2026년에도 여전히 유효하다:
"Start simple." 단순하게 시작하라. 그것이 속도를 높여줄 뿐 아니라, 실험하고 테스트할 기준선(baseline)을 만들어 준다.
실제로 2026년의 베스트 프랙티스는 이렇다:
Step 1
프롬프트 엔지니어링으로 시작 — 비용 0, 구현 시간 최소. 이것만으로 충분한지 먼저 확인한다.
Step 2
부족하면 RAG 추가 — 출처가 필요하거나, 최신 데이터가 필요하거나, 데이터가 너무 많으면 RAG를 붙인다.
Step 3
그래도 부족하면 SFT — 특정 형식이나 도메인 언어가 필요하면 LoRA 기반 파인튜닝을 시도한다.
Step 4
비용 최적화가 필요하면 증류 — 트래픽이 커지면 대형 모델 → 소형 전용 모델로 증류하여 비용을 절감한다.
6장: 핵심 개념 총정리
마지막으로, 이 글에서 다룬 모든 개념을 한 페이지에 정리한다.
5
핵심 방법
프롬프트 · RAG · SFT · RLHF · 증류
2
비(非)튜닝 방법
모델을 바꾸지 않는다
3+
튜닝 방법
모델 파라미터를 변경한다
∞
조합 가능성
방법들을 자유롭게 결합
핵심 논문 레퍼런스
| 연도 | 논문 | 핵심 기여 |
|---|---|---|
| 2015 | Hinton et al. "Distilling the Knowledge in a Neural Network" | 지식 증류 개념 확립 |
| 2017 | Vaswani et al. "Attention Is All You Need" | Transformer 아키텍처 |
| 2018 | Devlin et al. "BERT: Pre-training of Deep Bidirectional Transformers" | Pre-train → Fine-tune 패러다임 |
| 2020 | Brown et al. "Language Models are Few-Shot Learners" (GPT-3) | In-Context Learning, 프롬프트 엔지니어링 |
| 2020 | Lewis et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" | RAG 개념 정립 |
| 2021 | Hu et al. "LoRA: Low-Rank Adaptation of Large Language Models" | 효율적 파인튜닝 |
| 2022 | Ouyang et al. "Training language models to follow instructions with human feedback" | RLHF, InstructGPT |
| 2023 | Rafailov et al. "Direct Preference Optimization" | RLHF의 간소화 대안 (DPO) |
결론: 셰익스피어의 대답
"To tune, or not to tune?" — 이 질문에 대한 답은 사실 "둘 다"이다.
2026년의 AI 엔지니어에게 필요한 것은 하나의 정답이 아니라, 상황에 맞는 판단력이다. 프롬프트 엔지니어링으로 시작하고, 필요하면 RAG를 붙이고, 더 필요하면 파인튜닝을 하고, 비용이 부담되면 증류를 한다. 중요한 것은 단순하게 시작하되, 필요에 따라 조합하는 것이다.
햄릿은 고민에 빠져 비극으로 끝났지만, AI 엔지니어에게는 모든 선택지를 조합할 수 있는 행복한 결말이 기다리고 있다. 시작은 단순하게. 그리고 점진적으로 강화하라.
더 읽어보기: 이 글에서 다룬 RAG를 더 깊이 파고들고 싶다면, RAG 완전 가이드와 Advanced RAG: 실전 개선 기법 7가지를 참고하세요.
원문 출처: Kamilla Kurta & Filipe Gracio, "To tune or not to tune? A guide to leveraging your data with LLMs", Google Cloud Blog, 2024.05.17.
