파인튜닝 vs RAG vs 프롬프팅: 선택 가이드

언어 모델이 원하는 대로 동작하지 않을 때 당길 수 있는 큰 레버는 세 가지입니다. 프롬프트를 바꾸거나, 모델이 읽을 알맞은 자료를 주거나, 모델의 가중치를 바꾸는 것. 이것이 각각 프롬프팅, 검색 증강 생성(RAG), 파인튜닝입니다. 흔히 경쟁 관계처럼 논의되지만, 이들은 서로 다른 질문에 답하며, 대부분의 팀은 가벼운 것으로 충분했을 상황에서도 가장 무겁고 비싼 것부터 손을 뻗습니다.

이 가이드는 올바른 순서로 고르는 법에 관한 것입니다. 순서가 중요한 까닭은 각 레버가 서로 다른 비용, 서로 다른 실패 양상, 그리고 실제로 해결하는 서로 다른 문제를 갖기 때문입니다. 진단을 제대로 하면 선택은 대개 저절로 정해집니다.

각 레버가 실제로 바꾸는 것

무엇을 수정하고 있는지 정확히 짚어 두는 편이 도움이 됩니다.

• 프롬프팅은 요청 시점에 보내는 지시와 컨텍스트를 바꿉니다. 모델은 손대지 않으며, 고정된 시스템을 말과 예시로 조종하는 것입니다.
• RAG는 요청 시점에 모델이 이용할 수 있는 지식을 바꿉니다. 관련 문서를 가져와 답하기 전에 모델의 컨텍스트에 넣어 줍니다. 모델은 여전히 손대지 않으며, 모델이 읽을 수 있는 것을 바꾼 것입니다.
• 파인튜닝은 모델 자체를 바꿉니다. 직접 준비한 예시로 학습을 이어 가, 원하는 동작 쪽으로 가중치가 이동하게 합니다. 이것이 모델을 실제로 변경하는 유일한 레버입니다.

세 가지 중 둘은 모델을 그대로 둔다는 점에 주목하세요. 그것이 핵심 통찰입니다. 대부분의 문제는 모델의 문제가 아닙니다. 무엇을 요청했는지, 또는 무엇을 제공했는지의 문제입니다.

프롬프팅: 위안거리가 아니라 기본값

프롬프팅에는 "진짜" 작업을 하기 전에 쓰는 값싼 선택지라는 평판이 따라붙습니다. 그 틀은 본말이 전도된 것입니다. 프롬프팅을 가장 먼저 시도해야 하는 이유는 그것이 빠르고, 되돌릴 수 있으며, 놀라울 만큼 강력하기 때문입니다. 명확한 지시, 한두 개의 잘 다듬은 예시, 정의된 출력 형식, 그리고 확신이 없을 때 어떻게 할지에 대한 분명한 명시 — 이것들이 "모델이 이상하게 군다"는 불만의 상당 부분을 해소합니다.

프롬프팅은 모델이 이미 역량과 지식을 갖추었고, 그저 그것을 안정적으로 끌어내기만 하면 될 때 알맞은 도구입니다. 한계도 분명합니다. 한 번도 배운 적 없는 사실을 모델에 가르칠 수는 없고, 지시가 길고 깨지기 쉬우면 수천 가지 다양한 입력에 걸쳐 동작을 안정적으로 강제하지도 못합니다. 프롬프트가 방대한 규칙집으로 불어났는데도 여전히 예외 사례를 흘린다면, 그것은 다른 레버가 필요하다는 신호일 수 있습니다. 다만 그 결론에는 프롬프팅을 건너뛰어서가 아니라 끝까지 소진한 뒤에 도달해야 합니다.

RAG: 문제가 지식일 때

모델의 실패가 무엇을 아는가에 관한 것이라면 — 당신의 비공개 문서가 없고, 최신 정보를 보지 못하며, 받은 적 없는 세부 사항을 지어낸다면 — 문제는 지식이고, 답은 보통 파인튜닝이 아니라 RAG입니다. 이것이 이 분야에서 가장 흔한 오진입니다. 팀들은 모델이 "우리 도메인을 모른다"고 느끼고는 모델을 재학습해야 한다고 가정하지만, 사실은 읽을 알맞은 페이지를 건네주기만 하면 됩니다.

RAG가 빛나는 이유는, 검색 가능한 문서 안에 사는 지식은 최신 상태를 유지하고, 감사 가능하며, 고치기 쉽기 때문입니다. 문서를 갱신하면 모델의 답도 함께 갱신됩니다. 어떤 구절이 사용되었는지 보여 주면 사람이 답을 검증할 수 있습니다. 반면 파인튜닝은 지식을 가중치 속에 구워 넣는데, 그곳은 들여다보기 어렵고, 갱신하기 어렵고, 시간이 지나면 낡아 버리기 쉽습니다. 원칙으로 삼자면 이렇습니다. 문서가 바뀔 때 답도 바뀌어야 한다면, 학습이 아니라 검색을 쓰세요.

파인튜닝: 문제가 사실이 아니라 동작일 때

파인튜닝은 프롬프팅으로는 안정적으로 도달할 수 없는 방식으로 모델이 어떻게 동작하는지를 바꿔야 할 때 제 몫을 합니다. 막대한 양에 걸친 일관된 어조나 형식, 베이스 모델이 어설프게 처리하는 좁은 전문 작업, 명확한 지시에도 자꾸 어긋나는 구조화된 출력 같은 경우죠. 파인튜닝의 신호는 많은 예시로는 보여 줄 수 있지만 짧은 지시로는 담아낼 수 없는 동작입니다.

파인튜닝이 가장 무거운 레버인 데는 그만한 이유가 있습니다. 엄선된 학습 데이터, 학습 실행, 평가, 그리고 유지보수에 대한 약속이 필요합니다. 파인튜닝된 모델은 이제 당신이 소유한 것이고, 필요가 변해 감에 따라 계속 정렬을 맞춰 줘야 하기 때문입니다. 결정적으로, 파인튜닝은 사실을 가르치는 데 서툽니다. 지식 베이스를 심는 것보다 경향과 스타일을 옮기는 일을 훨씬 안정적으로 해냅니다. 지식의 공백을 메우려고 파인튜닝에 손을 뻗는 것은, 비싼 값을 치르고 부서지기 쉬운 결과를 얻는 길입니다.

순서대로 본 의사 결정

가장 값싸고 가장 되돌리기 쉬운 것부터, 실용적인 순서는 이렇습니다.

1. 프롬프팅부터 시작하세요. 쓸 수 있는 가장 명확한 지시를 적고, 예시를 몇 개 더하고, 출력을 정의하고, 모델이 확신하지 못할 때의 대안을 명시하세요. 실제 사례로 측정하세요.
2. 실패가 지식에 관한 것이라면, RAG를 더하세요. 빠진 사실, 낡은 정보, 비공개 문서, 지어낸 세부 사항 — 모델에 읽을 알맞은 자료를 주세요.
3. 실패가 일관된 동작에 관한 것이라면, 파인튜닝을 고려하세요. 지시로 압축할 수 없으면서 대규모로 반복되는, 입증 가능한 패턴 말입니다.
4. 정당할 때는 결합하세요. 이것들은 상호 배타적이지 않습니다. 성숙한 구성의 흔한 형태는 파인튜닝된 모델 과 RAG 와 정성껏 만든 프롬프트를 함께 쓰는 것입니다. 각자가 가장 잘하는 일을 맡는 것이죠.

대부분의 팀은 이 목록을 따라 내려가야지, 맨 아래로 건너뛰어서는 안 됩니다. 이 순서는 비용의 기울기입니다. 한 단계 올라갈 때마다 더 많은 노력, 더 많은 데이터, 더 많은 지속적 유지보수를 요구합니다.

어떤 문제인지 가려내는 법

가장 빠른 선택법은 실패를 솔직하게 진단하는 것입니다. 나쁜 답을 두고 물어보세요. 알맞은 문서가 있었다면 이게 고쳐졌을까? 그렇다면 지식 문제이고, RAG가 당신의 레버입니다. 물어보세요. 더 명확한 지시나 예시가 있었다면 고쳐졌을까? 그렇다면 프롬프팅 문제입니다. 물어보세요. 이것은 모델이 일관되게 틀리는 패턴, 많은 예시로는 보여 줄 수 있지만 한 문장으로는 말할 수 없는 패턴인가? 그렇다면 파인튜닝이 선택지에 올라옵니다.

둘 이상이 참이라면, 가장 값싼 것부터 고치고 다시 측정하세요. 더 값싼 수정이 문제의 충분한 부분을 해소해서, 비싼 쪽이 불필요해지는 경우가 많습니다. 고전하는 팀은 보통, 실패가 실제로 무엇으로 이루어졌는지가 아니라 어느 쪽이 가장 진지하게 들리는지에 근거해 레버를 고른 팀들입니다.

어느 것도 고치지 못하는 것

어떤 레버도 모델을 본래 아닌 무언가로 바꿔 주지 않습니다. 프롬프팅은 애초에 존재하지 않던 지식을 불러낼 수 없습니다. RAG는 답을 제공된 텍스트에 근거하게 하지만 모델을 더 잘 추론하게 만들지는 않으며, 당신 문서의 오류를 그대로 물려받습니다. 파인튜닝은 동작을 옮기지만 사실을 안정적으로 설치하지 못하고, 바탕 모델이 근본적으로 못 하는 작업을 구해 주지도 못합니다. 셋 다 끌어내기(elicitation), 근거 부여(grounding), 또는 경향을 개선할 뿐 — 어느 것도 무에서 역량을 만들어 내지 않습니다. 각각의 천장을 아는 것이, 엉뚱한 곳에 몇 주를 쏟는 일을 막아 줍니다.

정리

프롬프팅, RAG, 파인튜닝은 라이벌이 아닙니다. 서로 다른 세 가지 질문에 대한 답입니다. 프롬프팅은 어떻게 물었는가를 고칩니다. RAG는 모델이 무엇을 읽을 수 있는가를 고칩니다. 파인튜닝은 모델이 어떻게 동작하는가를 고칩니다. 실패를 진단한 다음, 문제가 요구하는 만큼만 비용의 기울기를 올라가세요. 프롬프트로 시작하고, 공백이 지식일 때 검색을 더하고, 보여 줄 수는 있지만 말할 수는 없는 동작을 위해 파인튜닝을 아껴 두세요. 당신의 문제를 해결하는 가장 값싼 레버가 곧 올바른 레버입니다.