RAG·파인튜닝·프롬프트 — 자사 LLM 방식 3가지 비교

세 갈래를 회의 테이블에 올려두고

지난 글에서 자사 데이터 LLM의 세 갈래를 스치듯 짚었습니다. 이번엔 그 세 갈래를 결재 회의 테이블 위에 올려두는 심정으로 하나씩 뜯어봅니다.

얼마 전 어느 제조사의 DX 담당 부장님과 두 시간 정도 이야기를 나눴습니다. 그분이 마지막에 한 말이 기억에 남습니다. "어차피 다 좋다고 하는데, 우리 회사에는 뭐부터 손대라는 건지 판단이 안 섭니다." 솔직히 말하면 저도 이 질문 앞에서 매번 조금 망설입니다. 정답이 하나가 아니기 때문입니다. 다만 결재 직전에 헷갈리시는 분들을 위해, 저희가 최근 프로젝트에서 실제로 무엇을 어떻게 골랐는지 담담하게 풀어보려 합니다.

세 방식이 각각 무엇을 건드리는가

먼저 원리부터 짧게 정리합니다. 세 방식은 이름은 나란히 놓이지만, 사실 손대는 지점이 서로 다릅니다.

프롬프트 엔지니어링은 모델 자체는 그대로 두고, 들어가는 질문(프롬프트)만 정교하게 다듬어 원하는 답을 유도하는 방식입니다. 모델은 시중의 GPT나 Claude를 그대로 쓰고, "어떻게 물어볼까"만 설계합니다. 초기 실험이나 PoC 단계에서 가장 먼저 손을 대는 자리입니다.

RAG(Retrieval-Augmented Generation)는 자사 문서·매뉴얼·상품 DB를 미리 벡터로 색인해두고, 질문이 들어오면 관련 문서 몇 조각을 찾아와 LLM에게 참고 자료로 함께 넘겨주는 방식입니다. 쉽게 말하면 "모델에게 시험 볼 때 우리 회사 자료집을 챙겨주는 것"에 가깝습니다. 답변 아래에 어느 문서에서 나왔는지 근거를 붙일 수 있다는 점이 결재자 입장에서 특히 강력합니다.

파인튜닝(Fine-tuning)은 사전학습된 모델의 가중치 자체를 자사 데이터로 추가 학습시키는 방식입니다. 모델이 우리 회사 말투, 도메인 용어, 판단 패턴을 몸에 익히게 됩니다. 대신 GPU도 필요하고, 학습 데이터도 정성껏 다듬어야 합니다.

비용과 유지보수 감각

결재 회의에서 가장 자주 나오는 질문은 결국 두 가지입니다. 얼마 들고, 나중에 얼마나 손이 가느냐. 세 방식을 한 장에 정리하면 이런 그림입니다.

수치는 프로젝트 규모에 따라 편차가 큽니다. 다만 감각적으로 보면, 초기 문턱은 프롬프트 → RAG → 파인튜닝 순으로 올라간다고 이해하시면 됩니다. 반대로 "우리 회사만의 자산"이 남는 정도는 그 역순으로 커집니다.

대부분의 중소기업은 왜 RAG부터 검토하는가

결론부터 말씀드리면, 저희가 최근 1년 사이 진행한 한국·일본 중소기업 프로젝트의 상당수는 RAG로 시작했습니다. 자랑이 아니라, 다른 선택지가 그때그때 더 나빴기 때문입니다.

이유는 몇 가지가 겹칩니다. 첫째, 초기 비용이 낮습니다. 자사 문서를 정리해 벡터 DB에 넣고 검색 파이프라인을 얹는 작업은 파인튜닝만큼 GPU를 요구하지 않습니다. 둘째, 문서만 바꾸면 답변이 즉시 갱신됩니다. 규정이나 상품 카탈로그가 자주 바뀌는 회사라면, 이 유지보수 단순함이 실무 팀 입장에서 결정적입니다. 셋째, 답변에 근거 문서를 붙일 수 있습니다. 환각(hallucination) 리스크를 완전히 없애지는 못하지만, "이 답변은 어느 매뉴얼 3페이지에서 나왔습니다"라고 표시할 수 있다는 사실만으로도 사내 결재 문턱이 눈에 띄게 낮아집니다.

이런 이야기는 지난 회의 개념·로드맵 총정리에서 스치듯 언급했던 부분과도 연결됩니다. 로드맵 그림에서 "1단계 PoC"에 해당하는 자리가, 실제 프로젝트에서는 대부분 RAG로 채워집니다.

그렇다면 파인튜닝은 언제 하는가

물론 파인튜닝이 필요한 순간도 분명히 있습니다. 저희가 실제로 파인튜닝을 제안하는 경우는 대체로 이렇습니다.

라벨링된 학습 데이터가 5,000건 이상 쌓여 있고, 산업 특유의 말투나 문체 일관성이 서비스 품질을 좌우하는 상황. 예를 들어 법무 문서 요약, 특정 브랜드의 고객 응대 스크립트, 의료·바이오처럼 용어 정확도가 사업의 근간인 도메인. 또 하나는 대규모 반복 트래픽입니다. 하루 수십만 건의 단순 반복 작업을 API로 돌리면 토큰 비용이 무겁습니다. 이때는 작은 모델을 파인튜닝해 자체 호스팅하는 편이 장기적으로 훨씬 저렴할 수 있습니다. 케이스에 따라 API 대비 운영비를 80~90% 아꼈다는 보고도 심심찮게 나옵니다.

정말 자주 보게 되는 흔한 패턴은 하이브리드입니다. 처음엔 RAG로 빠르게 서비스를 띄우고, 6개월~1년쯤 운영 데이터가 쌓이고 톤에 대한 요구가 명확해진 뒤에 LoRA 같은 부분 파인튜닝을 얹는 흐름입니다. 처음부터 하이브리드를 그리려 하지 마시고, 운영 안에서 자연스럽게 필요가 드러나는 순서로 가는 편이 실패 확률이 낮습니다.

그럼 프롬프트 엔지니어링은 어디로 가는가

가끔 오해가 있어서 짚어둡니다. 프롬프트 엔지니어링은 RAG나 파인튜닝의 "아래 단계"가 아닙니다. 셋 다 병행되는 층위입니다. RAG를 하든 파인튜닝을 하든, 결국 모델에게 어떻게 물을지는 매번 설계해야 합니다. 어떤 팀은 프롬프트만 잘 다듬어도 6개월은 문제없이 굴러갑니다. 순서로 보자면 프롬프트 → RAG → (필요 시) 파인튜닝이라는 검토 순서가 자연스럽습니다. 반대로 파인튜닝부터 시작하는 회사는 대부분 몇 달 뒤 후회합니다.

결재 회의에서 던져볼 만한 질문

세 방식을 놓고 사내에서 논의하실 때, 다음 질문을 먼저 정리해두시면 결정이 훨씬 수월해집니다. 답이 준비되지 않은 상태로 벤더 견적서만 비교하면 대개 방향이 흔들립니다.

• 우리 회사가 LLM에게 참고시키고 싶은 지식은 얼마나 자주 바뀌는가
• 답변에 "어느 문서에서 나왔는지" 근거를 표시할 필요가 있는가
• 라벨링된 학습 데이터가 실제로 얼마나 쌓여 있는가 (희망이 아니라 실측)
• 일 사용량이 어느 수준인가 — 소량 정밀형인가, 대량 반복형인가

이 네 가지 질문에 답할 수 있으면, 세 방식 중 어느 쪽이 우선인지는 대체로 자연스럽게 좁혀집니다.

마무리 — 방식을 골랐다면, 그다음

방식을 골랐다고 프로젝트가 시작되는 건 아닙니다. 오히려 진짜 어려운 문제는 그다음입니다. "이걸로 뭐가 얼마나 좋아졌는지"를 3개월 뒤 경영진에게 어떤 언어로 보여드리느냐. 다음 회에서는 자사 LLM 도입 효과를 재는 ROI·KPI 설계를 다루려 합니다. 실제로 저희가 클라이언트와 함께 짜본 지표 프레임을 몇 개 공유할 예정입니다.

혹시 지금 사내에서 방식을 두고 논의가 오가는 중이시라면, 문서 종류·업무 성격·트래픽 감각만 알려주셔도 어느 쪽이 유리한지 대략적인 방향을 함께 정리해드릴 수 있습니다. 방식 선정 무료 상담은 부담 없이 이용해보시고, 저희가 진행해온 관련 사례가 궁금하시면 지난 회의 로드맵 정리도 함께 살펴보시길 권합니다.