프롬프트로 풀까 RAG로 풀까 파인튜닝까지 갈까 — 판단 기준

1편에서 던진 질문

이 연재는 질문 하나로 시작했다. 어떤 문제를 만났을 때 그것을 프롬프트로 풀 수 있는지, RAG가 필요한지, 파인튜닝까지 가야 하는지를 무엇으로 가르는가.

이 질문이 어려운 이유는 셋이 서로 다른 층위에 있기 때문이다. 프롬프트는 입력을 바꾸는 일이고, RAG는 입력에 들어갈 재료를 찾아 오는 일이고, 파인튜닝은 모델 자체를 바꾸는 일이다.

앞의 다섯 편에서 그 구조를 다 봤다. 이제 각각이 어디에 작용하는지로 기준을 세울 수 있다.

기본값은 프롬프트다

결론부터 말하면 실무에서 만나는 문제의 대부분은 프롬프트와 지침으로 풀린다. 이것이 기본값이고, 나머지 둘은 특정 조건이 붙었을 때 추가하는 것이다.

이유는 5편에서 봤다. 프롬프트는 후보 목록의 모양을 바꾸는 일이다. '우리 점심 메뉴는' 앞에 '집 앞에 일식집이 개업했다'를 붙이면 후보 위쪽이 통째로 바뀌었다. 모델 내부를 건드리지 않고도 출력이 크게 달라진다.

그리고 프롬프트는 즉시 고칠 수 있다. 배포도 재학습도 필요 없고, 틀렸으면 문장을 바꿔 다시 돌리면 된다. 이 회전 속도가 다른 둘과 비교가 안 된다.

덧붙이면, 요즘 말하는 에이전트나 스킬 설계도 원리는 여기에 속한다. 그냥 문장을 치는 것과 흐름과 도구를 설계하는 것은 난이도가 다르지만, 모델 내부를 바꾸지 않고 입력으로 행동을 규정한다는 점에서 같은 층위다.

RAG를 얹어야 하는 조건

RAG는 Retrieval Augmented Generation의 약자다. 필요한 자료를 찾아 와서 프롬프트에 넣어 주고 그 상태로 답을 만들게 하는 방식이다.

동작은 4편의 임베딩과 이어진다. 문서를 잘라 각 조각을 의미를 담은 숫자 묶음으로 바꿔 저장해 둔다. 질문이 들어오면 질문도 같은 방식으로 바꿔서, 저장된 것들 중 의미가 가까운 조각을 찾는다. 그 조각을 프롬프트에 끼워 넣는다.

여기서 중요한 것은 RAG가 결국 프롬프트에 재료를 넣는 일이라는 점이다. 모델은 바뀌지 않는다. 5편에서 본 '맥락이 후보를 좁힌다'를 자동화한 것에 가깝다.

얹어야 하는 조건은 둘이다. 첫째, 답의 근거가 되는 자료가 컨텍스트 한도보다 크다. 사내 규정 전체를 매번 넣을 수는 없다. 둘째, 자료가 자주 바뀐다. 문서가 갱신될 때마다 모델을 다시 학습시키는 것은 비용이 성립하지 않는다.

덧붙여 다 넣을 수 있다 해도 다 넣는 것이 늘 낫지는 않다. 4편에서 봤듯 어텐션은 모든 토큰 쌍의 관계를 재므로 입력이 길어질수록 계산이 커지고 초점도 흐려진다. 필요한 것만 골라 넣는 편이 나은 경우가 많다.

파인튜닝으로 내려가는 조건

파인튜닝은 3편에서 본 대로 모델의 파라미터를 조정하는 일이다. 셋 중 유일하게 모델 자체를 바꾼다.

그래서 가장 무겁고, 그만큼 조건이 좁다. 정리하면 셋이 겹칠 때다. 형식이 정해진 같은 행동의 반복, 특화된 한 가지 과제, 그리고 규모.

핵심은 세 번째다. 그리고 그 이유가 이 연재를 읽은 사람에게만 정확히 보인다.

예를 들어 정해진 형식의 결과만 뱉게 하는 일이 있다고 하자. 프롬프트로 시키려면 형식을 설명하는 지침이 매번 입력에 붙는다. 한 번 호출에 몇백 토큰이 늘 따라붙는 셈이다. 호출이 하루 몇 건이면 아무 문제가 없다. 그런데 월 수십만, 수백만 건이면 그 지침 토큰만으로 큰 금액이 된다.

파인튜닝을 하면 그 지침을 통째로 뺄 수 있다. 모델이 애초에 그렇게 답하도록 바뀌었기 때문이다. 입력 길이가 몇 분의 일로 줄고, 그 차이가 호출 수만큼 곱해진다. 즉 파인튜닝의 실질적인 값어치는 성능보다 비용 구조에 있을 때가 많다.

뒤집으면 규모가 작으면 파인튜닝은 손해다. 학습 비용과 관리 부담이 절감액보다 크다.

파인튜닝의 자리가 좁아진 이유

예전에는 파인튜닝이 더 자주 선택됐다. 베이스 모델의 기본 성능이 지금만 못했고, 프롬프트를 다루는 방법론도 덜 정리돼 있었기 때문이다.

그 둘이 올라오면서 파인튜닝으로만 되던 일의 상당 부분이 프롬프트로 넘어왔다. 그래서 지금은 파인튜닝의 자리가 예전보다 특수하다.

실무에서 이 오해가 자주 나타난다. '우리 데이터로 학습시키자'는 요구가 대개 그렇다. 2편에서 본 대로 학습은 모델 내부 값을 바꾸는 일이고, 사내 문서를 답변에 반영하고 싶다는 요구와는 결이 다르다. 그 요구는 거의 항상 RAG의 영역이다.

다만 알아 두는 것과 쓰는 것은 다르다. 실습 환경이 저렴해져서 직접 해 보기는 어렵지 않으니, 판단 근거로 갖고 있으면 된다.

정리하면 순서다

셋을 두고 고르는 것이 아니라 순서대로 내려간다고 보는 편이 정확하다.

먼저 프롬프트로 시도한다. 대부분 여기서 끝난다. 답의 근거가 될 자료가 많고 자주 바뀌면 RAG를 얹는다. 실무에서 가장 흔한 조합이 프롬프트 더하기 RAG다. 그러고도 같은 형식의 대량 반복 때문에 비용이 문제가 되면 그때 파인튜닝을 검토한다.

이 순서를 거꾸로 밟는 것이 흔한 실패다. 파인튜닝부터 검토하면 시간과 비용을 쓰고도 프롬프트로 됐을 일을 확인하게 된다.

모델은 무엇으로 고르나

방식을 정했으면 모델을 고르는데, 여기서 순서를 잘못 잡는 경우가 많다. 성능 비교표부터 펴는 것이다.

실무에서 먼저 오는 것은 제약이다. 사내망에서만 돌려야 하는지, 클라우드로 올려도 되는지. 이것이 API를 쓸지 모델을 직접 띄울지를 가른다. 그리고 고객사나 회사의 거버넌스와 컴플라이언스에 이미 제약이 걸려 있는 경우가 많다. 특정 제공자만 쓸 수 있는 곳도 흔하다.

그 제약 안에서 남는 선택지를 두고 비용을 최적화하는 것이 실제 순서다. 그리고 여기서 1편의 내용이 다시 걸린다. 비용은 단가만으로 정해지지 않는다. 토크나이저가 한국어를 얼마나 잘게 쪼개는지에 따라 같은 글도 토큰 수가 달라진다. 단가와 토큰 수를 함께 봐야 한다.

마지막으로, 모델은 고정하는 것이 아니다. 더 나은 것이 나오면 바꿔 끼우고, 작업 종류에 따라 여러 모델을 나눠 쓰기도 한다. 그래서 설계할 때 모델을 갈아 끼울 수 있게 만들어 두는 편이 낫다.

여섯 편을 마치며

토큰에서 시작해 학습과 추론을 지나 실무 판단까지 왔다. 정리하면 이렇다. 글은 토큰이 되고, 다음 토큰 맞히기로 파라미터가 다듬어지고, 포스트트레인으로 형식을 익히고, 추론에서는 어텐션으로 관계를 재고, 마지막에 확률로 하나를 뽑는다.

이 그림을 갖고 있으면 달라지는 것이 있다. LLM에 관한 이야기를 들었을 때 그것이 어느 단계의 이야기인지 알 수 있고, 말이 되는지 안 되는지가 걸러진다. '학습시키자'와 '문서를 참고하게 하자'가 다른 말이라는 것이 바로 보인다.

AX에서 정작 어려운 것은 기술이 아니라 문제를 정확히 정의하는 일이다. 다만 문제를 정의하려면 무엇이 가능하고 무엇이 비싼지를 알아야 하고, 이 여섯 편이 그 판단의 바닥을 깔아 준다.