“우리도 파인튜닝해야 하나요?”는 LLM 도입 팀이 가장 자주 던지는 질문입니다. 결론부터 말하면 대부분의 경우 프롬프트 엔지니어링과 RAG로 먼저 시도하고, 그래도 한계가 명확할 때 파인튜닝을 고려하는 것이 맞습니다. 이 글은 둘의 손익분기점을 실무 기준으로 비교합니다.
두 접근의 본질적 차이
프롬프트 엔지니어링은 모델은 그대로 두고 지시와 예시로 행동을 유도합니다. 파인튜닝은 모델의 가중치 자체를 추가 학습해 특정 작업에 맞춥니다. 전자는 즉시 바꿀 수 있고 비용이 낮은 대신 컨텍스트를 매번 소모하고, 후자는 일관된 스타일과 형식을 내재화하지만 데이터 준비와 재학습 비용이 듭니다.
파인튜닝이 유리한 경우
- 특정 출력 형식·말투를 매우 일관되게 유지해야 할 때
- 프롬프트에 예시를 많이 넣어야 해서 토큰 비용이 과한 때
- 충분한 양질의 학습 데이터(보통 수백~수천 건)가 있을 때
- 지연 시간을 줄이기 위해 프롬프트를 짧게 만들어야 할 때
프롬프트가 유리한 경우
요구사항이 자주 바뀌거나, 학습 데이터가 부족하거나, 빠르게 실험해야 하는 초기 단계라면 프롬프트가 압도적으로 유리합니다. 또한 “최신 정보”나 “회사 문서 기반 답변”이 필요한 경우는 파인튜닝이 아니라 RAG의 영역입니다. 지식 주입을 파인튜닝으로 해결하려는 것은 흔한 오해입니다.
기억하세요: 파인튜닝은 “어떻게 말할지(형식·스타일)”를 가르치는 데 강하고, RAG는 “무엇을 말할지(지식)”를 공급하는 데 강합니다. 둘은 경쟁이 아니라 보완 관계입니다.
비용 관점의 손익분기
파인튜닝은 초기 학습 비용이 들지만 프롬프트를 짧게 만들어 호출당 비용을 낮춥니다. 따라서 호출량이 매우 많은 서비스라면 누적 절감이 학습 비용을 넘어서는 지점이 생깁니다. 반대로 호출량이 적으면 학습 투자를 회수하기 어렵습니다. 일 호출 수, 절감되는 토큰, 학습 비용을 표로 계산해 손익분기 호출량을 직접 구해 보길 권합니다.
실무 권장 순서
현실적인 순서는 프롬프트 엔지니어링으로 빠르게 검증하고, 지식이 필요하면 RAG를 붙이고, 그래도 형식·말투의 일관성이나 비용 문제가 남으면 마지막에 파인튜닝을 도입하는 것입니다. 처음부터 파인튜닝으로 시작하면 데이터 준비에 시간을 쏟다가 정작 제품 검증이 늦어지기 쉽습니다.
정리
파인튜닝과 프롬프트는 양자택일이 아닙니다. 작업의 성격(형식 vs 지식), 데이터 보유량, 호출량 세 가지로 판단하고, 가장 싸고 빠른 방법부터 단계적으로 올라가는 것이 가장 합리적인 전략입니다.
