지난 글에서 RAG 파이프라인을 RAGAS로 체계적으로 평가하는 방법을 배웠다. RAG를 깊이 공부하다 보면 자연스럽게 「그냥 모델을 파인튜닝하면 안 되나」라는 의문이 생긴다. 둘은 자주 대안처럼 놓이지만 실제로는 서로 다른 문제를 푸는 도구이고, 그 사실을 모른 채 고르면 몇 달을 쓰고 나서야 방향이 틀렸다는 것을 알게 된다.
이 글은 둘을 나란히 늘어놓고 장단점을 세는 대신, 판단에 실제로 쓰이는 축과 숫자를 정리한다. 마지막에는 잘못 고른 두 사례를 놓고 무엇을 봤어야 했는지 되짚는다.
미리 말해 두면, 실무에서 나오는 답은 대개 「둘 중 하나」가 아니다. 하나를 고르는 질문으로 시작해 놓고 결국 둘을 다른 층에 붙이게 되는 경우가 많다. 그래서 이 글의 절반은 고르는 기준이고 나머지 절반은 겹치는 순서다.
지식의 위치
외부 저장소
RAG에서 지식은 모델 바깥의 검색 대상에 있다. 문서를 벡터로 바꿔 색인에 넣어 두고, 질문이 올 때마다 관련된 조각을 꺼내 프롬프트에 붙인다. 모델 자체는 아무것도 새로 배우지 않는다 — 읽고 답하는 능력만 쓰고, 무엇을 읽을지는 매번 바깥에서 정해 준다.
그래서 RAG에서 지식을 고치는 일은 파일을 고치는 일이다. 문서 한 줄을 바꾸고 그 문서만 다시 임베딩하면 다음 질문부터 새 내용으로 답한다. 배포도 학습도 없고, 바꾼 사람이 무엇을 바꿨는지 문서의 이력에 그대로 남는다.
모델 가중치
파인튜닝에서 지식은 모델 안의 숫자에 스며든다. 여기서 파라미터는 모델 안에 든 숫자이고, 파인튜닝은 이미 학습된 그 숫자를 우리 데이터로 조금 더 옮기는 절차다. 옮기고 나면 그 내용은 프롬프트에 없어도 답에 나타난다 — 대신 어느 데이터가 그 답을 만들었는지는 숫자 안에 녹아 되찾을 수 없다.
여기서 흔한 오해 하나를 짚어 둘 필요가 있다. 파인튜닝은 모델에 새 사실을 적어 넣는 일이 아니라, 이미 있는 경향을 우리 데이터 쪽으로 기울이는 일이다. 같은 문장을 천 번 보여 줘도 모델 안에 그 문장이 저장되지는 않는다. 저장되는 것은 「이런 질문에는 이런 모양의 답이 온다」는 경향이고, 그 경향이 우연히 사실을 담고 있을 뿐이다. 아래에서 다룰 문제들이 전부 이 지점에서 나온다.
이 한 가지 차이에서 나머지 모든 장단점이 나온다. 바깥에 있는 것은 갈아 끼울 수 있고 가리킬 수 있지만 매번 실어 날라야 한다. 안에 있는 것은 실어 나를 필요가 없지만 갈아 끼울 수도 가리킬 수도 없다.
세 축
고를 때 실제로 묻는 것은 셋이다. 셋 중 하나만 뚜렷해도 답이 거의 정해진다.
갱신 주기
바꾸려는 내용이 얼마나 자주 변하는가. 매일 바뀌는 것은 파인튜닝으로 못 따라간다. 학습을 돌리고 평가하고 배포하는 데 최소 며칠이 드는데 그 사이에 내용이 또 바뀌기 때문이다. 반대로 몇 년째 그대로인 도메인 규칙이라면 갱신 주기는 판단에 아무 정보를 주지 않으므로 다음 축으로 넘어간다.
경계는 대략 분기다. 분기보다 자주 바뀌면 RAG, 연 단위로 바뀌면 파인튜닝도 후보가 된다.
이 축을 볼 때는 「지금 얼마나 자주 바뀌는가」가 아니라 「앞으로 얼마나 자주 바뀔 수 있는가」를 본다. 지금은 안 바뀌지만 규제나 조직 개편으로 언제든 바뀔 수 있는 내용이라면, 바뀌는 날에 대응할 방법이 있는 쪽을 골라 두는 편이 안전하다. 안 바뀌는 지식을 RAG로 다루는 비용은 매달 조금씩 더 내는 토큰 값이지만, 바뀌는 지식을 파인튜닝으로 다룬 비용은 전면 재작업이다.
출처 표시
답의 근거를 대야 하는가. 법률·의료·금융처럼 「어느 조항에 따라」를 함께 내야 하는 자리에서 파인튜닝은 답이 될 수 없다. 모델은 자기가 왜 그렇게 답했는지 문서 단위로 되짚지 못하고, 그럴듯한 출처를 지어내는 쪽으로 망가진다. 출처가 필요하면 그 시점에 RAG는 선택지가 아니라 전제다.
출처가 하는 일은 신뢰를 주는 것만이 아니다. 사용자가 답을 검증할 수 있게 만드는 것이 더 큰 몫이다. 링크 하나를 누르면 원문이 뜨는 구조에서는 모델이 틀려도 사용자가 곧바로 발견하고, 그 발견이 다시 골든셋으로 돌아온다. 출처가 없는 시스템은 틀린 답이 그대로 지나가므로 고칠 기회 자체가 생기지 않는다.
지식인가 행동인가
바꾸려는 것이 내용인가 방식인가. 「무엇을 아는가」를 바꾸려면 RAG이고, 「어떻게 답하는가」를 바꾸려면 파인튜닝이다. 이 구분이 셋 중 가장 자주 흐려지는데, 판단하는 요령이 하나 있다 — 원하는 결과를 프롬프트에 예시 다섯 개로 적어 보는 것이다. 예시로 전달되는 것이면 행동이고, 예시로는 전달이 안 되고 사실 목록이 필요하면 지식이다.
한 요청 안에 둘이 섞여 있는 경우가 실무에서는 오히려 흔하다. 고객 상담 답변은 내용은 매뉴얼에서 와야 하고 말투는 우리 회사 것이어야 한다. 이때 둘 중 하나를 고르려 하면 어느 쪽을 골라도 반쪽이 남으므로, 축을 나눠 각각에 맞는 도구를 붙이는 것이 옳다. 아래 「시도 순서」가 그 붙이는 차례다.
비용의 역전점
세 축으로 갈리지 않는 회색 지대가 남는다. 그때 다음으로 보는 것이 비용이고, 여기서는 감이 아니라 계산이 필요하다.
파인튜닝의 비용 구조
파인튜닝은 앞에 큰 덩어리가 있고 뒤가 얇다. 학습 데이터를 만드는 사람 시간, 학습 자체의 GPU 시간, 그리고 평가와 재학습 몇 번이 초기 비용이다. 배포 후에는 요청마다 짧은 프롬프트만 처리하므로 요청당 비용이 낮다. 즉 고정비가 크고 변동비가 작다.
이 고정비에서 GPU 값은 생각보다 작은 몫이다. LoRA처럼 일부 파라미터만 학습하는 방식이 흔해지면서 학습 자체는 몇 시간에 끝나는 경우가 많고, 정작 크게 드는 것은 학습 데이터를 만들고 검수하는 사람 시간이다. 수천 건의 입력과 출력을 짝지어 만들고 품질을 확인하는 일은 자동화가 잘 안 되는 자리라, 견적을 낼 때 이 몫을 빼면 매번 크게 어긋난다.
RAG의 비용 구조
RAG는 반대다. 색인을 만드는 초기 비용은 상대적으로 작지만, 요청마다 임베딩 한 번과 검색 한 번이 돌고 무엇보다 프롬프트가 길어진다. 조각 다섯 개를 붙이면 입력 토큰이 몇 배가 되고, 그 몇 배가 모든 요청에 붙는다. 고정비가 작고 변동비가 크다.
변동비를 줄이는 수가 아예 없는 것은 아니다. 프롬프트 앞부분이 매번 같다면 캐싱으로 그 부분의 단가를 낮출 수 있고, 조각 수를 줄이고 리랭커로 질을 올리는 것도 같은 방향이다. 다만 이런 수들은 곱해지는 값을 조금 낮출 뿐 구조를 바꾸지는 못한다 — 요청이 늘면 비용이 따라 느는 성질은 그대로다.
역전 계산
구조가 반대이므로 어딘가에서 총비용이 뒤집힌다. 그 지점을 역전점이라 부르자. 파인튜닝의 초기 비용을 RAG가 요청마다 더 쓰는 비용으로 나누면 나온다 — 요청 수가 그 값을 넘어가면 파인튜닝이 싸진다.
숫자를 넣어 보면 감이 잡힌다. 파인튜닝 초기 비용이 300만 원이고, RAG가 요청마다 붙이는 추가 입력이 2,000토큰이며 그 토큰의 단가가 100만 토큰당 3달러라고 하자. 요청 하나에 더 드는 돈은 0.006달러, 대략 8원이다. 300만 원을 8원으로 나누면 37만 5천 건이다. 월 요청이 만 건인 서비스라면 역전까지 3년이 걸리므로 계산할 것도 없이 RAG이고, 하루 10만 건이 오는 서비스라면 넉 달이면 뒤집힌다.
이 계산에서 자주 빠뜨리는 항목이 둘 있다. 파인튜닝 쪽에서는 재학습이다 — 한 번 학습하고 끝나는 경우는 드물고, 데이터가 바뀔 때마다 초기 비용의 일부가 다시 든다. RAG 쪽에서는 사람 시간이다. 청크 전략과 리랭커를 손보는 일은 계속 있고, 그 시간은 토큰 값에 안 잡힌다.
그리고 역전점이 나왔다고 곧바로 갈아타는 것도 아니다. 역전은 비용에서만 일어나고, 위에서 본 갱신·출처·추적은 그대로 남기 때문이다. 요청이 아무리 많아도 출처를 대야 하는 서비스는 여전히 RAG다. 역전점 계산이 실제로 쓰이는 자리는 셋 중 어느 축으로도 안 갈린 회색 지대이고, 그 회색 지대가 생각보다 좁다는 것이 이 절의 결론이다.
지식을 가중치에 넣을 때
파인튜닝으로 지식을 넣는 시도는 늘 있고, 대개 처음에는 되는 것처럼 보인다. 학습 데이터에 있던 질문을 물으면 정확히 답하기 때문이다. 문제는 그다음에 온다.
자신 있는 환각
모델은 학습한 내용을 통째로 기억하지 않고 비슷한 것들과 섞어 기억한다. 그래서 학습 데이터와 조금 다른 질문이 오면 학습한 것과 원래 알던 것을 섞은 답을 내놓는데, 그 답의 어투는 학습 데이터를 따라 하므로 확신에 차 있다. RAG에서 근거를 못 찾은 모델은 대개 머뭇거리지만, 파인튜닝된 모델은 틀린 답을 자신 있게 낸다. 사용자가 걸러 내기 더 어려운 쪽이다.
평가에서도 이 실패는 잘 안 잡힌다. 학습 데이터에서 뽑은 질문으로 평가하면 점수가 높게 나오는데, 그 질문들은 모델이 실제로 본 것이라 정확히 답하기 때문이다. 파인튜닝한 모델을 평가할 때 학습에 쓰지 않은 질문을 따로 남겨 두는 것이 원칙인 이유가 여기 있고, 그마저도 도메인이 같으면 낙관적으로 나온다.
갱신 불가
한 문장을 고치려면 학습을 다시 돌려야 한다. 더 나쁜 것은 지우는 일이다 — 틀린 사실 하나를 모델에서 빼는 확실한 방법이 없어서, 실질적으로는 그 데이터를 제외하고 처음부터 다시 학습하는 것이 유일한 길이다. RAG라면 문서 한 줄을 고치고 그 문서만 다시 임베딩하면 끝나는 일이다.
추적 불가
답이 어느 데이터에서 나왔는지 물을 수 없다. 감사가 필요한 도메인에서 이것은 기능 하나가 없는 정도가 아니라 도입 자체를 막는 조건이 된다. 사고가 났을 때 「왜 그렇게 답했는가」에 답할 수 없는 시스템은 사고 뒤에 고칠 수도 없다.
개발하는 쪽에서도 같은 값을 치른다. RAG에서 틀린 답이 나오면 어느 조각이 들어갔는지 로그에서 바로 보이고, 문제가 검색인지 생성인지 그 자리에서 갈린다. 파인튜닝된 모델에서는 그 갈래가 없어서, 틀린 답 하나를 두고 학습 데이터를 뒤지는 일부터 시작해야 한다.
셋을 합치면 결론이 분명하다. 파인튜닝은 지식을 넣는 도구가 아니다. 지식처럼 보이는 것을 넣어 성능이 오른 사례들은 대개 지식이 아니라 그 도메인의 표현 방식을 배운 것이다. 같은 학습으로 답이 좋아졌더라도, 좋아진 이유가 사실을 외워서인지 그 분야의 말을 익혀서인지는 갈라 봐야 안다. 학습에 없던 사실을 묻는 질문 스무 개만 던져 보면 대개 후자라는 답이 나온다.
파인튜닝이 이기는 자리
출력 형식
정해진 구조로 답해야 하는데 프롬프트로는 가끔 어긋나는 자리다. 예시를 열 개 붙여도 백 번에 한두 번 틀리는 것을, 수천 건으로 학습시키면 거의 사라진다. 형식이 깨졌을 때 비용이 큰 파이프라인 — 뒤에서 파싱해 자동으로 흘려보내는 구조 — 에서는 이 차이가 크다.
다만 이 자리에는 파인튜닝 말고 다른 수도 있다. 디코딩 단계에서 스키마를 강제하는 제약 생성을 쓸 수 있으면 형식은 학습 없이도 100퍼센트 지켜진다. 그러니 형식 문제로 파인튜닝을 고민하기 전에 쓰는 모델이 그 기능을 제공하는지부터 확인한다.
도메인 말투
특정 직군의 문체나 사내 용어를 자연스럽게 쓰게 만드는 일이다. 이건 프롬프트로 설명하기가 유난히 어렵다. 「우리 회사 상담 톤으로」를 문장으로 적어 보면 누구도 만족스럽게 못 적는데, 지난 상담 기록 2천 건을 보여 주면 모델이 알아서 잡는다.
말투를 학습시킬 때 데이터의 품질이 곧 결과의 품질이 된다는 점은 미리 알아 둘 만하다. 지난 기록을 그대로 넣으면 좋은 답변뿐 아니라 나쁜 답변의 버릇까지 함께 배운다. 그래서 이 작업의 대부분은 학습이 아니라 고르기다 — 무엇이 우리가 원하는 답인지를 사람이 추려 내는 일이고, 그 기준이 흐리면 학습을 아무리 잘 돌려도 결과가 흐리다.
짧고 반복되는 작업
분류·추출처럼 입력이 짧고 출력이 정해진 작업이다. 여기서 파인튜닝은 품질보다 비용과 지연에서 이긴다. 긴 지시문과 예시를 매 요청에 실어 나르는 대신 작은 모델이 짧은 입력만 받고 처리하므로, 요청당 토큰이 몇 분의 일로 줄고 응답도 빨라진다. 위의 역전점 계산이 가장 극적으로 나오는 자리가 여기다.
품질에서도 밀리지 않는 경우가 많다. 작업이 좁을수록 큰 모델의 일반적인 능력이 덜 필요해지기 때문이다. 문서 분류처럼 정답 라벨이 정해진 작업이라면 학습 데이터를 모으기도 쉽다 — 이미 사람이 분류해 둔 기록이 그대로 학습 데이터가 된다.
시도 순서
셋 다 되는 것처럼 보일 때는 싼 것부터 한다. 이 순서를 건너뛰고 파인튜닝부터 잡는 것이 가장 흔한 낭비다.
프롬프트 먼저
가장 싸고 가장 자주 충분하다. 지시를 구체적으로 적고, 예시를 서너 개 넣고, 출력 형식을 못 박는 것만으로 풀리는 문제가 실제로 많다. 여기서 안 되는 이유를 정확히 적어 두는 것이 다음 단계의 입력이 된다 — 「형식이 가끔 깨진다」면 파인튜닝 쪽이고, 「모르는 내용을 지어낸다」면 RAG 쪽이다.
프롬프트로 안 되는 것을 확인할 때는 한 번만 해 보고 판단하지 않는다. 지시를 바꾸는 것, 예시를 늘리는 것, 예시를 실패 사례로 바꾸는 것은 서로 다른 수이고 효과도 다르다. 특히 원하는 것만 보여 주는 예시보다 틀린 답과 고친 답을 짝지어 보여 주는 예시가 잘 듣는 경우가 많다. 이 단계에서 쓰는 시간은 며칠이고, 파인튜닝은 몇 주다.
한 가지 더, 프롬프트로 안 되던 것이 모델을 바꾸면 되는 경우도 흔하다. 같은 지시를 더 큰 모델에 주면 그대로 풀리는 문제에 파인튜닝을 붙이는 것은 순서가 틀린 것이고, 반대로 작은 모델로 내려도 되는지를 확인하는 실험도 같은 자리에서 한다. 모델 교체는 프롬프트 다음으로 싼 수다.
임베딩 모델만 맞추기
RAG가 잘 안 될 때 생성 모델을 파인튜닝하기 전에 볼 자리다. 검색이 약한 것이 원인이라면 고칠 대상은 생성 모델이 아니라 검색이고, 검색을 도메인에 맞추는 가장 직접적인 수가 임베딩 모델을 우리 데이터로 조금 학습시키는 것이다. 질문과 정답 문서의 쌍만 있으면 되고, 생성 모델 파인튜닝보다 훨씬 작고 싸다.
효과가 특히 큰 경우가 사내 용어가 많은 도메인이다. 범용 임베딩 모델은 우리 회사에서만 쓰는 약어나 제품명을 아무 의미 없는 토막으로 보므로, 그 낱말이 들어간 질문에서 검색이 무너진다. 질문과 문서의 쌍 몇천 개로 학습하면 이 자리가 눈에 띄게 좋아진다. 다만 임베딩 모델을 바꾸면 색인을 통째로 다시 만들어야 하므로, 문서가 아주 많다면 재색인 시간을 미리 계산해 둔다.
검색을 쓰도록 학습시키기
둘을 겹치는 방식 중 가장 실용적인 것이 RAFT다. 검색 결과를 넣은 프롬프트로 학습시키되, 관련 없는 문서를 일부러 섞어 넣어 쓸 것과 안 쓸 것을 가리도록 가르친다. 여기서 모델이 배우는 것은 지식이 아니라 근거를 다루는 태도다 — 지식은 여전히 바깥에 있으므로 갱신도 출처 표시도 그대로 된다.
이 방식이 특히 값을 하는 자리는 검색이 완벽하지 않은 현실이다. 상위 다섯 조각 중 둘만 관련 있는 상황은 언제나 생기는데, 방해 문서에 흔들리지 않도록 학습한 모델은 그 상황에서 나머지 셋을 무시한다. 검색을 더 좋게 만들기 어려운 단계에 이르렀을 때, 같은 검색 결과로 더 나은 답을 얻는 방법이 이것이다.
순서를 그림으로 정리하면 이렇다.
| 단계 | 하는 일 | 다음으로 넘어가는 신호 |
|---|---|---|
| 1 | 프롬프트와 예시 | 형식이나 말투가 계속 어긋난다 |
| 2 | RAG 붙이기 | 근거는 맞는데 답이 안 맞는다 |
| 3 | 임베딩 모델 맞추기 | 검색이 계속 엉뚱한 것을 데려온다 |
| 4 | 생성 모델 파인튜닝 | 위 셋으로 안 풀리는 것이 남는다 |
잘못 고른 사례
매주 바뀌는 사내 규정
규정 문서를 학습 데이터로 만들어 파인튜닝한 경우다. 처음 한 달은 잘 돌았고, 규정이 개정되면서 무너졌다. 모델은 옛 규정을 여전히 자신 있게 답했고, 새 규정으로 다시 학습시키자 이번에는 두 버전이 섞인 답이 나왔다. 옛 내용을 빼는 방법이 없었기 때문이다. 결국 문서를 색인에 넣는 쪽으로 옮겼고, 그때 만들어 둔 학습 데이터는 버려졌다.
세 축 중 첫 번째만 봤어도 걸렸을 자리다. 갱신 주기가 주 단위인데 학습·평가·배포에 며칠이 드는 방법을 고른 것이므로, 도입하는 순간부터 뒤처지는 구조였다.
말투 통일을 RAG로
상담 답변의 톤을 맞추려고 좋은 답변 예시를 색인에 넣고 매번 검색해 프롬프트에 붙인 경우다. 답변은 조금 나아졌지만 불안정했다. 검색이 가져온 예시의 주제가 지금 질문과 다르면 모델이 그 예시의 내용까지 따라 했기 때문이다.
이건 세 번째 축을 거꾸로 읽은 자리다. 바꾸려던 것은 「어떻게 답하는가」인데 「무엇을 아는가」를 고치는 도구를 쓴 것이다. 예시 다섯 개로 전달되는 것이면 행동이고, 행동은 파인튜닝이거나 — 더 싸게는 — 고정된 예시를 프롬프트에 박는 것으로 끝난다. 검색으로 매번 다른 예시를 가져오는 구조는 오히려 톤을 흔든다.
이 사례가 특히 헷갈리는 이유는 중간에 잠깐 좋아졌기 때문이다. 검색이 우연히 비슷한 주제의 좋은 답변을 가져온 질문들에서는 결과가 훌륭했고, 그 인상이 판단을 미뤘다. 지표를 갈래별로 갈라 봤다면 주제가 겹치는 질문과 안 겹치는 질문의 점수 차가 크게 벌어져 있었을 것이다.
두 사례의 공통점은 도구를 먼저 고르고 문제를 거기 맞춘 것이다. 순서를 뒤집으면 대부분의 선택은 어렵지 않다 — 무엇이 얼마나 자주 바뀌는지, 근거를 대야 하는지, 바꾸려는 것이 내용인지 방식인지를 먼저 적고 나면, 남는 선택지가 대개 하나뿐이다.
읽어주셔서 감사합니다. 😊