목차
전제와 판단 기준
파인튜닝 vs RAG vs 프롬프트 엔지니어링은 셋 중 무엇이 더 나은가의 문제가 아니라, 지금 겪는 문제가 어느 쪽에 속하는가의 문제입니다. 이 글은 AI 언어 모델 API를 활용하는 실무자를 전제로 합니다. 세 방법은 해결하려는 문제가 다르므로, 먼저 바꾸려는 대상이 지식인지 행동 방식인지 답변 형식인지 구분합니다. 여기에 호출마다 드는 프롬프트 비용을 더한 네 가지가 이 글에서 쓰는 판단 축입니다.
최신 사내 문서나 상품 정보처럼 자주 바뀌는 지식은 RAG가 적합합니다. 모델의 말투와 출력 형식을 일정하게 만들려면 프롬프트 엔지니어링을 먼저 적용하고, 충분한 예시를 학습시켜 특정 작업의 형식·스타일·행동 패턴을 모델 쪽에 고정하려면 파인튜닝을 검토합니다. 다만 파인튜닝은 최신 지식을 담아 두는 저장소의 대체재가 아닙니다.
비용과 운영 부담 비교
| 비교 항목 | 프롬프트 엔지니어링 | RAG | 파인튜닝 |
|---|---|---|---|
| 주된 해결 문제 | 지시·형식 개선 | 외부 지식 연결 | 행동·스타일 고정 |
| 초기 비용 | 낮음 | 중간 | 높음 |
| 운영 부담 | 낮음 | 중간~높음 | 높음 |
| 최신 정보 반영 | 입력·프롬프트 수정 | 문서·인덱스 갱신 | 학습 데이터 갱신 후 재학습 |
| 필요한 구성 | 프롬프트·평가셋 | 청킹·임베딩·벡터DB | 학습 데이터·학습 환경 |
| 주요 위험 | 지시 충돌·출력 흔들림 | 검색 실패·잘못된 문맥 | 과적합·버전 관리 |
프롬프트 엔지니어링은 코드와 지시문을 바꾸는 방식이라 실험을 시작하기 쉽습니다. 다만 입력 유형이 많아지면 조건문과 예외 지시가 늘어나 유지보수가 어려워질 수 있습니다.
RAG는 문서 수집, 청킹, 임베딩, 벡터DB, 검색 결과 검증이 필요합니다. 파인튜닝은 데이터 정제와 학습·평가·배포 과정이 추가되고, 원본 지식이 변경될 때 다시 관리해야 하므로 장기 운영 비용을 함께 계산해야 합니다.
RAG 검색 결과가 비어 있거나 관련성이 낮으면, 모델이 충분한 근거 없이 답하거나 답변을 거부할 가능성이 있습니다. 특히 문서가 갱신됐는데 인덱스를 다시 만들지 않은 경우 이런 현상이 나타나므로, 질문·검색 문서·최종 답변의 근거를 로그로 확인하고 청킹 크기와 검색 조건을 조정해야 합니다.
상황별 선택 기준
고객지원 답변이 최신 약관을 근거로 해야 한다면 RAG부터 검토합니다. 반대로 JSON 형식을 자주 어기거나 특정 분류·요약 스타일을 반복적으로 요구한다면 좋은 예시를 포함한 프롬프트를 먼저 만들고, 충분한 평가 데이터에서도 편차가 계속될 때 파인튜닝으로 넘어가는 순서가 안전합니다.
문서가 적고 질문 유형도 단순한 데다 그 내용을 매 호출에 넣어도 입력 길이와 비용이 감당할 수준이라면, 프롬프트에 관련 내용을 직접 넣는 편이 빠릅니다. 문서가 많거나 계속 바뀌면 RAG가 유리하고, 정해진 작업을 대량 처리하면서 호출 때마다 긴 지시와 예시를 보내는 비용이 커진다면 파인튜닝의 경제성을 계산할 수 있습니다.
세 방법을 섞어 쓰는 방법과 코드 예시
실무에서는 조합이 흔합니다. RAG로 최신 근거를 가져오고, 프롬프트로 답변 규칙과 금지 표현을 지정하며, 파인튜닝한 모델이 있다면 일정한 분류나 문체를 담당하게 할 수 있습니다.
아래 코드는 어디서 시작할지만 가려내는 예시입니다. 조건이 여러 개 겹치면 앞에서 본 것처럼 조합이 답이므로, 이 함수의 반환값은 최종 결론이 아니라 첫 번째 후보로 봅니다. 실제 도입 전에는 대표 입력을 모은 평가셋으로 정확도, 근거성, 형식 준수율을 따로 비교하세요.
def recommend_first_step(changing_knowledge, fixed_style, repeated_behavior,
long_prompt_cost):
"""가장 먼저 손댈 곳 하나만 고른다. 조합이 필요한 경우까지 판정하지 않는다."""
if changing_knowledge:
return "RAG: 문서를 검색해 최신 근거를 주입"
if repeated_behavior and long_prompt_cost:
return "파인튜닝 검토: 학습 데이터와 평가셋 준비"
if fixed_style or repeated_behavior:
return "프롬프트 엔지니어링: 예시와 출력 형식 고정"
return "프롬프트 엔지니어링부터 시작하고 평가 결과로 확장"
print(recommend_first_step(True, False, False, False))
자주 묻는 질문
파인튜닝을 하면 최신 문서도 알게 되나요?
그렇지 않습니다. 학습 시점의 내용을 반영할 수는 있지만, 변경되는 정보의 조회 창구로는 RAG가 더 적합합니다.
프롬프트만으로 해결되지 않으면 바로 파인튜닝해야 하나요?
먼저 실패 유형을 분리해야 합니다. 지시 해석 문제인지, 지식 부족인지, 검색 실패인지 평가셋으로 확인한 뒤 각각 프롬프트, RAG, 파인튜닝을 선택합니다.
RAG와 파인튜닝을 함께 써도 되나요?
가능합니다. 변하지 않는 작업 패턴은 파인튜닝으로 줄이고, 최신 사실과 근거는 RAG로 제공하는 식으로 역할을 나누면 됩니다.
결론
변경되는 지식은 RAG, 출력 지시와 형식은 프롬프트 엔지니어링, 반복 행동의 고정은 파인튜닝이 출발점입니다. 먼저 작은 평가셋으로 프롬프트와 직접 주입 방식이 충분한지 확인하고, 문서 규모와 변경 빈도, 검색 필요성, 운영 비용을 기준으로 RAG나 파인튜닝으로 확장하세요.