같은 LLM을 우리 자리에 맞게 쓰는 길이 세 갈래입니다. 사람이 시키는 대로(prompting), 외부 데이터를 검색해서 보여주는 대로(RAG), 모델 자체를 우리 데이터로 다시 학습시켜서(fine-tuning). 비용·속도·정확도가 모두 다르고, 어느 자리에 어느 도구가 맞는지가 운영의 핵심 결정입니다. 마케터·운영자가 LLM 도입 첫 결정에서 가장 자주 부딪히는 분기를 정리합니다.
1. 세 도구의 한 줄 정의
세 도구를 한 줄씩으로:
- Prompting — 모델은 그대로, 입력에 지시·예시를 넣어 동작 변경
- RAG — 모델은 그대로, 외부 데이터를 검색해 컨텍스트에 추가
- Fine-tuning — 모델 자체를 우리 데이터로 다시 학습
세 도구는 한 자리에 같이 안 들어옵니다 — 다른 자리에 적합. 운영의 첫 결정은 "내 자리는 어느 쪽인가".
prompting은 입력만 만지고, RAG는 외부 데이터를 컨텍스트에 추가하고, fine-tuning은 모델 자체를 변경. 비용·속도·정확도의 trade-off가 다 다르다.
📌 이 글에서 다루는 것
이 글은 세 도구의 운영적 trade-off에 집중합니다. 각 도구의 디테일은 huny.log의 다른 글들 — RAG 평가, LLM 카피 파이프라인, 프롬프트 자동 최적화 — 에서.
2. Prompting — 가장 가벼운 도구
Prompting의 한 줄 직관:
모델은 그대로 두고 입력 텍스트로 모델 동작을 바꾼다.
운영적 세부:
- 시스템 프롬프트 — "당신은 마케팅 카피 전문가입니다. 30자 이내로 답하세요."
- few-shot 예시 — 입력에 몇 개 정답 예시
- chain-of-thought — "단계별로 추론한 뒤 답하세요"
장점:
- 0 학습 비용 — 모델 학습 없음
- 즉시 적용 — 코드 한 줄로 변경
- 유연 — 자리마다 다른 프롬프트
단점:
- 일관성 한계 — 모델이 매번 약간 다른 답
- 비용 누적 — 매 호출에 시스템 프롬프트 토큰
- 도메인 한계 — 모델이 본 적 없는 도메인 정확도 낮음
운영 표준 자리:
- 광고 카피 생성·변형
- 일반적 챗봇 응답
- 텍스트 요약·번역
- 분류·태깅
3. RAG — 외부 지식을 모델에 잇는다
RAG의 한 줄 직관:
질문과 관련된 외부 문서를 검색해 모델 컨텍스트에 넣어 답을 만든다.
운영 흐름:
- 외부 문서를 임베딩으로 인덱싱
- 사용자 질문을 임베딩으로 변환
- 질문 임베딩과 가장 가까운 문서 top-k 검색
- 검색된 문서를 모델 컨텍스트에 추가
- 모델이 그 컨텍스트로 답 생성
장점:
- 최신 정보 — 모델 학습 시점 이후 데이터도 반영
- 도메인 특화 — 회사 내부 문서·FAQ 그대로 활용
- 출처 명시 — 답의 근거 문서 보여줄 수 있음
- 인덱스 업데이트 — 학습 없이 데이터만 추가
단점:
- 검색 정확도 의존 — 잘못된 문서를 검색하면 답도 잘못
- 인프라 비용 — 벡터 DB·임베딩 모델·검색
- 컨텍스트 길이 제한 — top-k가 너무 많으면 컨텍스트 폭발
운영 표준 자리:
- 회사 내부 위키 검색 챗봇
- FAQ 자동 응답
- 도메인 특화 답변(법률·의료·고객 응대)
- 최신 정보 필요한 자리(뉴스·정책 변경)
4. Fine-tuning — 모델 자체를 변경
Fine-tuning의 한 줄 직관:
우리 데이터로 모델을 다시 학습시켜 동작을 영구적으로 변경.
운영 세부:
- 입력·출력 쌍 1,000~100,000개 준비 (학습 데이터)
- OpenAI·Anthropic·오픈소스 모델 fine-tuning API로 학습
- 학습된 새 모델을 호출
장점:
- 일관성 — 매번 같은 톤·구조
- 도메인 특화 — 우리 도메인 패턴 모델에 영구 학습
- 토큰 절약 — 시스템 프롬프트·few-shot 예시 없이도 같은 동작
- latency 감소 — 짧은 입력으로 같은 답
단점:
- 학습 비용·시간 — 1,000~100,000건 데이터 + 학습 1~24시간 + 학습 비용
- 유연성 부족 — 동작 변경하려면 다시 학습
- 데이터 품질 의존 — 학습 데이터 나쁘면 결과 나쁨
- 최신 정보 안 됨 — 학습 이후 데이터 반영 못 함
운영 표준 자리:
- 회사 톤·브랜드 보이스 적용
- 매우 일관된 형식의 출력(JSON 구조·고정 템플릿)
- 대량 호출이 필요한 자리(비용 절감)
- 보안·프라이버시 — 외부 API 못 쓸 때
5. 결정 트리 — 어디 쓸까
순서대로 묻는 결정:
| 질문 | Yes | No |
|---|---|---|
| 외부 정보(회사 내부·최신)가 필요? | RAG | 다음 |
| 같은 도구로 매번 정확히 같은 형식? | Fine-tuning | 다음 |
| 자리마다 다른 동작이 필요? | Prompting | 다음 |
| 대량 호출로 비용이 큰 자리? | Fine-tuning | Prompting |
대부분의 운영 자리는 다음 세 패턴:
- 일반적 — Prompting (90% 자리)
- 지식 기반 — Prompting + RAG (회사 도메인 챗봇)
- 고정 형식 — Fine-tuning (대량 카피·태깅)
세 가지를 결합해 쓰는 자리도 흔합니다 — fine-tuning된 모델 + RAG로 컨텍스트 + 명시적 prompting의 결합.
6. 비용·속도 비교
| 항목 | Prompting | RAG | Fine-tuning |
|---|---|---|---|
| 초기 비용 | 0 | 10k (인프라) | 10k (학습) |
| 운영 비용 (호출당) | 보통 | 보통 + 검색 비용 | 적음 (짧은 입력) |
| 시작까지 시간 | 즉시 | 1~4주 | 1주~1개월 |
| 정확도 변경 | 프롬프트 수정 | 인덱스 업데이트 | 재학습 |
| 인프라 부담 | 작음 | 중간 (벡터 DB) | 작음 (호스팅 필요) |
운영 결정 기준:
- 속도 우선·작은 규모 — Prompting
- 도메인 지식 중요 — RAG
- 대량·일관성 우선 — Fine-tuning
from openai import OpenAI
client = OpenAI()
# Prompting
r1 = client.chat.completions.create(
model='gpt-4o',
messages=[{'role': 'system', 'content': '광고 카피 전문가입니다.'},
{'role': 'user', 'content': '신상품 카피'}]
)
# Fine-tuning된 모델 호출
r2 = client.chat.completions.create(
model='ft:gpt-4o:my-org:copy-style:abc',
messages=[{'role': 'user', 'content': '신상품 카피'}]
)
이게 본문에 박는 유일한 코드입니다. 같은 SDK 호출 — model 이름만 다름. fine-tuning은 모델 ID, prompting은 시스템 메시지로 동작 결정.
💡 대부분 자리는 prompting + RAG로 충분
Fine-tuning이 빛나는 자리는 한정적입니다. 대량 호출·고정 형식·외부 API 못 씀의 셋 중 하나라도 만족 안 하면 prompting + RAG로 충분. 첫 운영은 prompting → 부족하면 RAG → 정말 필요하면 fine-tuning 순.
7. 마케팅 실무 케이스 3개
7-1. 광고 카피 생성 — Prompting
신상품·시즌마다 다른 톤·포맷 필요. 자리마다 다른 prompting + temperature 0.8. fine-tuning은 유연성 부족, RAG는 외부 지식 불필요.
7-2. FAQ 챗봇 — Prompting + RAG
회사 정책·정책 변경 정보가 필요. RAG로 내부 위키 검색 + prompting으로 답 톤 통제. fine-tuning은 정책 변경 때마다 재학습 부담.
7-3. 대량 상품 설명 자동 생성 — Fine-tuning
수만 개 상품에 같은 형식·같은 톤. fine-tuning으로 짧은 입력으로 일관 출력 — 토큰 비용 50%+ 절감.
{/* TODO_HUNY: huny가 운영 중인 LLM 자리에서 prompting → RAG → fine-tuning의 단계 변화를 경험한 자리 한 가지 추가해주세요. 어떤 자리에서 도구 변경이 필요했는지. */}
8. 도구 결합의 표준 패턴
운영 환경에서는 하나의 도구만 쓰는 게 아닙니다. 결합이 표준:
8-1. RAG + Prompting
- 가장 흔한 결합. RAG로 컨텍스트 + 정교한 prompting으로 답 통제
- 예: 회사 챗봇
8-2. Fine-tuning + RAG
- 톤은 fine-tuning, 정보는 RAG
- 예: 브랜드 톤의 도메인 챗봇
8-3. Fine-tuning + Prompting
- fine-tuned 모델 + 자리별 prompting 변형
- 예: 같은 톤이지만 자리마다 약간 다른 출력
세 도구가 모두 들어가는 자리는 가장 정교한 운영 — 인프라 부담 큼.
9. 도구 선택이 깨질 때 — 흔한 함정 3가지
9-1. Fine-tuning 너무 일찍 시도
운영 첫 주에 "정확도 향상하려면 fine-tuning"으로 직진. 사실 prompting · RAG로 충분한 자리가 대부분. fine-tuning의 학습 비용·시간 부담이 가치보다 크면 잘못된 선택.
9-2. RAG 인덱스 검증 부족
RAG는 검색 정확도가 답 정확도를 좌우. 인덱스 만들고 검증 없이 운영하면 잘못된 문서 검색이 환각으로 누적. RAG 평가 글 참조.
9-3. Prompting의 한계 무시
prompting만으로 풀 수 없는 자리(매우 일관된 형식·외부 지식 필요)에 prompting만 고집하면 실패가 누적. 도구 결정의 재검토 필요.
⚠️ 도구 결정은 운영 변화에 따라 다시
처음 prompting으로 시작했어도, 운영 6개월 후 데이터·요구가 변하면 RAG·fine-tuning으로 옮길 자리가 됩니다. 분기 단위로 도구 결정 재검토하는 운영 패턴이 표준.
10. 마치며 — 첫 결정의 무게
LLM 도입의 첫 결정은 "어떤 LLM을 쓰나"가 아니라 "어떻게 쓰나"입니다. 세 도구의 분기점에서 잘못된 선택은 운영 비용·시간을 몇 배로 늘립니다.
90%의 자리는 prompting으로 시작. 5%는 RAG로. 1%만 fine-tuning이 진짜 필요.
이 분포의 직관을 잡고 있으면 첫 결정의 함정 대부분을 피합니다.
다음 글이자 AI 기초 5편 마지막 글에서는 환각(hallucination)이 일어나는 이유를 다룹니다. LLM이 왜 자신 있게 틀린 답을 하는지의 자리.
참고
- Lewis et al. (2020), Retrieval-Augmented Generation, NeurIPS — RAG 원전
- Houlsby et al. (2019), Parameter-Efficient Transfer Learning for NLP, ICML — fine-tuning 효율 표준
- Brown et al. (2020), Language Models are Few-Shot Learners, NeurIPS — prompting 시대를 연 GPT-3 논문
- OpenAI Fine-tuning 가이드 — 운영 표준 적용
- LangChain·LlamaIndex — RAG 표준 인프라
- huny.log 내부 글: LLM 기초, 임베딩 기초, 트랜스포머 직관, RAG 비용·latency, 프롬프트 자동 최적화, LLM 카피 파이프라인
