LLM이 원하는 대로 답하지 않을 때 손댈 수 있는 자리는 셋이다. 요청하는 방식을 고치거나(프롬프트 엔지니어링), 답하는 데 필요한 자료를 찾아서 같이 넣어 주거나(RAG), 모델의 가중치 자체를 우리 데이터로 다시 학습시키는 것(파인튜닝)이다.
셋 중 무엇을 고를지가 늘 논쟁거리인 이유는 셋이 서로 대체재가 아니기 때문이다. 셋은 각각 다른 고장을 고친다. 그래서 "어느 쪽이 성능이 좋은가"는 질문이 성립하지 않고, 답해야 하는 질문은 언제나 "지금 이 답이 왜 틀렸는가"다. 진단이 먼저고 처방은 그다음이다.
이 글은 그 진단의 순서를 정리한다. 먼저 증상으로 고장을 가르고, 같은 고장 안에서 선택을 가르는 기준 넷을 보고, 그 기준이 실제로 뒤집히는 경계를 짚은 다음, 셋을 섞을 때 어느 층에 무엇을 두는지와 나중에 걷어낼 때 무엇이 남는지까지 본다.
세 전략이 고치는 것
세 가지 고장
모델이 낸 답이 마음에 안 드는 경우는 대체로 셋 중 하나다.
| 증상 | 고장난 것 | 고치는 자리 |
|---|---|---|
| 사내 규정·최신 정보를 모른다, 없는 사실을 지어낸다 | 모델이 그 사실을 본 적 없다 | RAG |
| 형식이 매번 다르다, 지시를 절반만 따른다 | 무엇을 원하는지가 덜 적혔다 | 프롬프트 |
| 형식을 열 번 중 아홉 번만 지킨다, 말투가 우리 것이 아니다 | 요구하는 행동이 모델의 기본값과 멀다 | 파인튜닝 |
첫 줄과 셋째 줄을 헷갈리면 처방이 통째로 어긋난다. 모르는 것을 파인튜닝으로 넣으려 하면 모델은 그 사실을 배우는 대신 그럴듯하게 말하는 법을 배워 더 확신에 차서 틀린다. 반대로 말투 문제를 RAG로 풀려 하면 문서를 아무리 잘 찾아 줘도 답의 모양은 그대로다.
둘째 줄과 셋째 줄의 경계는 더 미묘하다. 둘 다 「형식이 안 맞는다」로 보이지만, 프롬프트가 고치는 것은 덜 적힌 요구이고 파인튜닝이 고치는 것은 다 적었는데도 안 지켜지는 잔여분이다. 그래서 순서가 정해진다 — 요구를 다 적어 본 적이 없으면 잔여분이 얼마인지 알 수 없고, 얼마인지 모르면 파인튜닝이 값을 할지도 모른다.
지식과 행동을 가르는 질문
둘을 가르는 질문은 하나다 — 그 답에 필요한 사실을 프롬프트에 붙여 주면 모델이 맞히는가. 맞힌다면 지식 문제이고 RAG로 간다. 사실을 다 주었는데도 형식이나 말투가 안 맞는다면 행동 문제이고, 그때 비로소 프롬프트와 파인튜닝을 견준다.
이 질문은 실제로 한 번 돌려 보는 것이 좋다. 틀린 답 스무 건을 뽑아 필요한 문서를 손으로 붙여 넣고 다시 물어보면 대개 십 분 안에 답이 나온다. 이 열 몇 분을 안 쓰고 몇 주짜리 파인튜닝을 시작하는 팀이 생각보다 많다.
결과는 대체로 셋 중 하나로 갈린다. 문서를 붙여 주니 스무 건 중 열여덟이 맞으면 지식 문제이고 할 일은 검색을 붙이는 것이다. 문서를 붙여도 그대로 틀리면 모델이 그 문서를 읽고도 원하는 판단을 못 하는 것이라, 이건 지식도 형식도 아닌 능력 문제여서 더 큰 모델을 써야 하는 자리일 수 있다. 사실은 맞는데 모양이 매번 다르면 행동 문제다.
이 분류를 한 번 해 두면 그 뒤의 논의가 짧아진다. 전략 선택이 길어지는 회의는 대부분 사람마다 다른 증상을 머릿속에 두고 말하는 자리다.
프롬프트와 파인튜닝의 경계
행동 문제로 판정됐다면 다음 질문은 지금 프롬프트가 그 행동을 실제로 요구하고 있는가다. 「전문가답게 답하라」는 요구가 아니라 바람이다. 출력 형식을 예시로 못 박고 금지 사항을 적고 나서도 준수율이 안 오를 때, 그 자리가 파인튜닝의 자리다.
아래 두 프롬프트의 차이는 길이가 아니라 검사할 수 있는가다. 앞쪽은 지켰는지 사람이 판정할 수 없고, 뒤쪽은 항목이 셋인지, 조항이 세 개 이내인지, 밖의 문장이 있는지를 기계로 셀 수 있다. 검사할 수 있게 적고 나면 준수율이라는 수가 생기고, 그 수가 있어야 파인튜닝이 그것을 얼마나 올렸는지 말할 수 있다.
# 요구가 덜 적힌 프롬프트
system = "당신은 법률 문서 분석 전문가입니다."
# 행동을 실제로 요구하는 프롬프트
system = """계약서를 분석해 아래 세 항목만 순서대로 출력한다.
1. 핵심 조항 — 3개 이내, 각 한 문장
2. 위험 요소 — 없으면 '없음'
3. 놓치기 쉬운 조항 — 조항 번호를 함께 적는다
세 항목 밖의 문장은 쓰지 않는다."""결정 기준 넷
진단이 끝났어도 처방이 바로 나오지는 않는다. 같은 행동 문제라도 팀의 사정에 따라 답이 갈리고, 그 사정은 넷으로 정리된다.
손에 있는 데이터 양
파인튜닝에는 「이렇게 답해야 한다」의 실제 예시가 필요하다. 수십 건으로는 모델이 형식만 흉내 내다 말고, 수백 건쯤부터 준수율이 눈에 띄게 오르며, 수천 건이면 말투까지 따라온다. 중요한 것은 개수가 아니라 그 예시들이 서로 일관된가다. 두 사람이 다른 기준으로 만든 예시가 섞이면 모델은 두 기준의 평균을 배우고, 그 평균은 어느 쪽 기준도 만족하지 않는다.
양보다 일관성이 먼저라는 말은 검수 방식으로 옮겨진다. 예시를 만들기 전에 판정 기준을 문서로 적고, 애매한 경우를 몇 개 골라 먼저 합의해 두고, 만든 뒤에는 표본을 뽑아 두 사람이 따로 판정해 얼마나 일치하는지 본다. 이 일치율이 낮으면 데이터를 더 모을 것이 아니라 기준을 다시 적어야 한다.
예시가 아직 없다면 그것을 만드는 일이 곧 프롬프트 작업이다. 프롬프트로 답을 만들고 사람이 고쳐 쌓으면 그 자체가 학습 데이터가 되므로, 순서는 자연히 프롬프트가 먼저다.
쌓는 동안 지켜야 하는 것이 하나 있다. 고친 답만 모으지 말고 고치기 전의 답도 같이 남기는 것이다. 무엇을 왜 고쳤는지가 남으면 나중에 그것이 선호 데이터가 되고, 형식 규칙을 사람이 읽을 수 있게 정리하는 재료도 된다. 고친 결과만 쌓아 두면 몇 달 뒤에 「우리 형식이 정확히 뭐였지」를 아무도 답하지 못한다.
지연 예산
RAG는 검색 단계가 앞에 붙는다. 벡터 검색과 재순위에 드는 시간이 그대로 응답 시간에 더해지고, 찾아온 문서가 입력에 붙으므로 프리필 토큰도 늘어난다. 대화형 서비스에서 이 몫이 예산을 먹어 버리면 선택이 뒤집힌다 — 답해야 할 사실이 몇십 개로 고정돼 있고 자주 안 바뀐다면, 그것을 프롬프트에 박아 두거나 파인튜닝으로 넣고 검색을 걷어내는 편이 빠르다.
파인튜닝은 반대다. 학습 시간은 오래 걸리지만 서비스 시점의 추가 지연이 없고, 오히려 긴 지시문을 걷어낼 수 있어 입력이 짧아진다.
지연을 잴 때는 평균이 아니라 꼬리를 본다. RAG의 검색 단계는 평균은 안정적인데 인덱스가 커지거나 필터 조건이 붙으면 상위 몇 퍼센트에서 크게 튀고, 사용자가 느리다고 말하는 것은 그 구간이다. 프롬프트 쪽도 마찬가지다 — 퓨샷 예시를 늘리면 평균 입력 길이가 아니라 가장 긴 요청의 길이가 먼저 한도에 닿는다.
지식 갱신 주기
참조해야 하는 자료가 얼마나 자주 바뀌는가가 RAG와 파인튜닝을 가르는 가장 확실한 축이다. 매일 바뀌는 자료를 파인튜닝으로 넣으면 매일 다시 학습해야 하고, 그것은 유지할 수 없는 구조다. 문서를 고치면 다음 요청부터 바로 반영되는 것이 RAG의 값이고, 이 값은 성능이 아니라 운영에서 나온다.
갱신 주기를 잴 때 자료 전체의 평균을 보면 안 된다. 열에 아홉은 반년째 그대로인데 나머지 하나가 매주 바뀐다면, 서비스가 틀리는 자리는 언제나 그 하나다. 자주 바뀌는 조각만 검색으로 빼고 나머지는 프롬프트에 박아 두는 구성이 그래서 흔하다.
이 구성은 지연에도 도움이 된다. 검색 대상이 줄면 인덱스가 작아지고 찾아오는 문서도 짧아지므로, 앞의 지연 예산 항목에서 문제가 됐던 꼬리 구간이 같이 줄어든다. 자료를 「자주 바뀌는 것」과 「거의 안 바뀌는 것」으로 한 번 갈라 두는 일은 그래서 두 축을 동시에 개선한다.
돌볼 사람 수
셋은 남기는 짐이 다르다. 프롬프트는 텍스트 파일 하나라 누구든 고칠 수 있다. RAG는 인덱스·임베딩 모델·청크 전략이 함께 늙고, 문서가 늘면 검색 품질이 조용히 떨어져 주기적으로 들여다볼 사람이 필요하다. 파인튜닝은 거기에 학습 파이프라인과 평가셋, 기저 모델이 바뀔 때마다의 재학습이 붙는다. 두 사람짜리 팀에서 파인튜닝을 유지하는 것은 대개 실패한다 — 성능이 안 나와서가 아니라 돌볼 사람이 없어서다.
이 축은 도입 시점에는 잘 안 보인다. 처음 붙이는 비용은 셋 다 몇 주 안에 끝나지만, 남는 비용은 몇 달에 걸쳐 나타나기 때문이다. 선택을 적어 둘 때 「이걸 누가 반년 뒤에 고치는가」를 함께 적어 두면, 그 한 줄이 나중에 가장 자주 읽히는 줄이 된다.
선택이 뒤집히는 자리
위 넷은 방향을 알려 주지만 경계를 알려 주지는 않는다. 실제로 선택이 뒤집히는 지점 셋을 적어 둔다.
예시가 프롬프트에 안 들어갈 때
퓨샷 예시는 프롬프트에 넣을수록 좋아지다가 어느 지점부터 안 좋아진다. 예시 하나가 길거나 종류가 많아 스무 개쯤 넘어가면, 입력이 길어져 비용과 지연이 늘고 모델이 마지막 몇 개에만 기울어지는 일도 생긴다. 예시 스무 개로 준수율이 목표에 못 미치는데 예시를 더 넣을 자리가 없다면 그 자리가 파인튜닝의 경계다. 파인튜닝은 예시를 가중치로 옮겨 넣는 일이라 개수 제한이 사실상 사라진다.
경계에 닿기 전에 한 번 더 시도할 것이 있다. 예시를 줄이는 대신 고르는 것이다. 스무 개를 무작위로 넣는 것보다 지금 질문과 가까운 다섯 개를 골라 넣는 편이 대체로 낫고, 이렇게 하면 예시 창고는 얼마든지 커져도 프롬프트는 짧게 유지된다. 예시를 검색해서 넣는 셈이라 구조는 RAG와 같다.
다만 이 방식에는 캐시가 잘 안 듣는다는 대가가 있다. 요청마다 예시가 달라지면 프롬프트의 앞부분이 매번 바뀌어 벤더의 프롬프트 캐시가 걸리지 않는다. 고정된 예시를 앞에 두고 고른 예시를 뒤에 붙이는 배치로 어느 정도는 피할 수 있다.
문서가 바뀌는 주기가 학습 주기보다 짧을 때
앞의 갱신 주기를 숫자로 적으면 이렇다. 파인튜닝 한 바퀴에 며칠이 든다면, 자료가 그보다 자주 바뀌는 순간 모델은 영원히 뒤처진다. 이 비교는 절대적인 속도가 아니라 두 주기의 대소로만 판정한다 — 반년에 한 번 개정되는 법령이라면 파인튜닝도 가능하고, 주 단위로 바뀌는 제품 사양이라면 RAG 말고는 답이 없다.
학습 주기에는 학습 시간만 들어가는 것이 아니다. 데이터를 모으고 검수하고, 학습하고, 평가하고, 배포하고, 문제가 있으면 되돌리는 한 바퀴 전체가 주기다. 실제로 재어 보면 학습 자체는 그 바퀴에서 가장 짧은 구간인 경우가 많다.
검색이 못 찾는 것을 프롬프트가 아는 때
RAG가 답을 못 만드는 실패의 상당수는 생성이 아니라 검색에서 난다. 질문의 낱말과 문서의 낱말이 달라 애초에 문서가 안 올라오는 경우다. 이때 파인튜닝으로 넘어가는 것은 잘못된 이동이고, 고칠 자리는 질의 재작성·하이브리드 검색·청크 크기처럼 검색 쪽에 있다. 실패를 검색 실패와 생성 실패로 나눠 세는 것이 전략을 바꾸기 전에 할 일이다.
나누는 방법은 간단하다. 틀린 답마다 정답이 든 문서가 검색 결과 안에 있었는지만 보면 된다. 없었으면 검색 실패, 있었는데 답이 틀렸으면 생성 실패다. 이 두 수의 비율이 다음에 무엇을 손볼지를 그대로 알려 주고, 이 비율을 모르는 채로 전략을 바꾸면 고쳐지지 않는 쪽에 몇 주를 쓴다. 검색 실패가 대부분이라면 손댈 자리는 인덱스와 질의 쪽이고, 생성 실패가 대부분이라면 그제야 프롬프트와 파인튜닝의 비교가 시작된다. 둘이 반반이면 검색부터 고치는 편이 낫다 — 검색이 좋아지면 생성 실패로 세던 것 중 일부도 함께 사라지지만, 그 반대는 일어나지 않는다.
세 전략을 섞는 구성
실제로 오래 사는 시스템은 셋을 함께 쓴다. 다만 아무렇게나 겹치는 것이 아니라 층마다 맡는 것이 다르다.
층마다 맡는 것
지식은 RAG가, 형식과 말투는 파인튜닝이, 그때그때의 지시는 프롬프트가 맡는다. 이 분담을 지키면 각 층을 따로 고칠 수 있다 — 문서가 바뀌면 인덱스만, 형식이 바뀌면 학습만, 이번 요청의 조건이 달라지면 프롬프트만 손대면 된다. 반대로 형식 규칙을 프롬프트와 학습 데이터 양쪽에 적어 두면 둘이 어긋나는 날이 오고, 그때 어느 쪽이 이기는지는 아무도 모른다.
층을 가르는 또 하나의 이유는 평가다. 셋이 뒤섞여 있으면 답이 나빠졌을 때 인덱스 때문인지 프롬프트 때문인지 모델 때문인지 가릴 수 없다. 층마다 바꾼 것을 따로 기록하고 평가셋을 같은 상태로 두면, 나빠진 날에 되돌릴 한 가지가 분명해진다.
def answer(question: str) -> str:
docs = retriever.invoke(question) # 지식: RAG
context = "\n\n".join(d.page_content for d in docs)
return client.messages.create(
model=FINETUNED_MODEL_ID, # 형식·말투: 파인튜닝
max_tokens=2048,
system="주어진 문서만 근거로 답한다.", # 이번 요청의 지시: 프롬프트
messages=[{"role": "user",
"content": f"문서:\n{context}\n\n질문: {question}"}],
).content[0].text형식만 파인튜닝한 작은 모델
비용을 크게 줄이는 구성이 하나 있다. 지식은 RAG가 다 넣어 주므로, 모델에게 남는 일은 주어진 문서를 정해진 형식으로 옮겨 적는 것뿐이다. 이 일은 큰 모델이 아니어도 된다. 작은 모델을 그 형식으로만 파인튜닝하면 형식 준수율은 큰 모델보다 높아지고 토큰 단가는 몇 분의 일이 된다. 파인튜닝의 값이 「똑똑해지는 것」이 아니라 「좁은 일을 싸게 잘하는 것」에 있는 자리다.
이 구성에는 조건이 하나 붙는다. 작은 모델은 주어진 문서를 벗어난 추론을 잘 못하므로, 검색이 정답 문서를 안정적으로 올려 줘야 한다. 검색이 부실한 상태에서 모델만 작게 바꾸면 틀린 답이 더 단정한 형식으로 나올 뿐이다. 그래서 이 구성은 RAG가 충분히 좋아진 뒤에 붙이는 마지막 단계에 가깝다.
순서
붙이는 순서는 프롬프트 → RAG → 파인튜닝이다. 앞의 둘은 되돌리기 쉽고 파인튜닝은 어렵다는 것이 이 순서의 이유이지, 파인튜닝이 더 고급 기술이어서가 아니다. 그리고 앞 단계를 건너뛰면 뒤 단계의 재료가 없다 — 프롬프트 없이는 학습 데이터가 없고, 평가셋 없이는 파인튜닝이 좋아졌는지 나빠졌는지 알 수 없다.
순서를 지킨다는 것이 앞 단계를 버린다는 뜻은 아니다. RAG를 붙인 뒤에도 프롬프트는 계속 고쳐야 하고, 파인튜닝을 한 뒤에도 프롬프트에는 이번 요청의 조건이 남는다. 쌓는 것이지 갈아타는 것이 아니다.
자주 하는 오판
형식 문제를 지식 문제로 읽기
가장 흔한 오진이다. 답이 마음에 안 들면 「자료를 더 넣어 줘야겠다」로 가는 반사가 있다. 그런데 검색 문서를 다섯 개에서 스무 개로 늘려도 답의 모양이 그대로라면 그것은 처음부터 지식 문제가 아니었다. 문서를 늘리는 동안 비용과 지연만 네 배가 된다.
이 오진을 막는 장치는 앞서 말한 대조 실험 하나다. 자료를 더 넣어서 좋아지는지를 스무 건으로 먼저 확인하면 되는데, 그 확인이 반나절이고 검색 파이프라인을 키우는 일은 몇 주다.
파인튜닝으로 최신 정보 넣기
모델에게 새 사실을 가르치려는 시도는 학습이 되기는 한다. 문제는 그것이 언제 갱신되는지를 아무도 통제할 수 없다는 점이다. 옛 사실과 새 사실이 가중치 안에서 섞이면 모델은 둘을 반반 섞은 답을 내놓고, 어느 쪽을 봤는지 추적할 방법이 없다. RAG는 최소한 「이 문서를 보고 이렇게 답했다」가 남는다.
예외는 있다. 바뀌지 않는 사실, 이를테면 도메인의 고정된 용어 체계나 분류 기준은 파인튜닝으로 넣어도 된다. 기준은 「그 사실이 바뀌면 누가 언제 알려 주는가」이고, 답할 수 없으면 가중치에 넣지 않는다.
평가 없이 바꾸기
세 전략 중 무엇을 고르든 바꾸기 전과 후를 같은 문제로 재지 않으면 나아졌는지 알 수 없다. 특히 파인튜닝은 목표한 형식이 좋아지는 대신 다른 능력이 조금씩 나빠지는 일이 흔해서, 목표 지표 하나만 보면 전체가 나빠진 것을 못 본다. 바꾸기 전에 고정된 문제 묶음을 만들어 두는 것이 세 전략 모두의 전제 조건이다.
문제 묶음은 크지 않아도 된다. 실제 트래픽에서 뽑은 오십 건에 사람이 정답을 달아 둔 것이면 첫 판단에는 충분하고, 중요한 것은 그것을 바꿀 때마다 같은 상태로 다시 돌리는 것이다. 매번 다른 문제로 재면 좋아졌다는 말도 나빠졌다는 말도 근거가 없다.
되돌아가는 비용
무엇이 남는가
프롬프트를 되돌리는 것은 파일을 되돌리는 일이고, RAG를 걷어내면 인덱스가 남지만 서비스는 그날로 원래대로 돈다. 파인튜닝은 다르다. 걷어내기로 해도 모델 식별자를 참조하는 코드, 학습 파이프라인, 평가셋, 그리고 무엇보다 그 모델이 하던 형식 보정이 사라진 자리가 남는다. 파인튜닝 모델을 기저 모델로 되돌리면 형식 준수율이 학습 전 수준으로 떨어지므로, 걷어내는 작업에는 프롬프트를 다시 쓰는 일이 딸려 온다.
그래서 파인튜닝을 붙일 때 프롬프트 쪽 규칙을 지우지 않는 편이 낫다. 모델이 이미 지키고 있으니 중복처럼 보이지만, 그 중복이 되돌아갈 길이다. 남겨 두는 비용은 입력 토큰 몇십 개이고 지우는 비용은 며칠이다.
기저 모델이 바뀔 때
파인튜닝에는 안 적히는 만기가 하나 있다. 기저 모델이 더 나은 것으로 바뀌면 우리 모델은 옛 모델 위에 얹힌 채로 남는다. 새 모델이 파인튜닝 없이도 우리 형식을 지킨다면 그동안의 학습은 통째로 짐이 된다. 그래서 파인튜닝을 유지하는 팀은 주기적으로 기저 모델과 맨몸으로 붙여 보는 절차를 같이 둔다. 이 비교를 안 하면 몇 세대 전 모델을 계속 쓰고 있다는 사실조차 모른다.
비교 절차 자체는 가볍다. 평가셋을 그대로 새 기저 모델에 돌려 준수율과 품질을 재고, 우리 파인튜닝 모델의 수와 나란히 적어 두면 된다. 두 수의 간격이 좁아지는 추세면 걷어낼 시점이 다가오는 것이고, 벌어지는 추세면 파인튜닝이 여전히 값을 하고 있는 것이다.
되돌아가기 쉽게 붙이는 법
세 층 중 어느 것도 영구적이지 않다고 보고 붙이는 편이 낫다. 모델 식별자를 설정값으로 빼 두고, 형식 규칙을 프롬프트 쪽에도 사람이 읽을 수 있게 남겨 두고, 평가셋을 학습 파이프라인 밖에 두는 것 정도면 충분하다. 이 셋을 지켜 두면 전략을 바꾸는 일이 코드를 다시 쓰는 일이 아니라 설정을 바꾸는 일이 된다.
세 전략을 고르는 일은 한 번 하고 끝나는 결정이 아니다. 자료가 안정되면 RAG의 값이 줄고, 트래픽이 늘면 작은 모델의 값이 커지고, 기저 모델이 좋아지면 파인튜닝의 값이 줄어든다. 그래서 지금의 선택을 적어 둘 때는 고른 것만 적지 말고 무엇이 바뀌면 이 선택이 뒤집히는지를 함께 적는다. 그 한 줄이 반년 뒤에 같은 논쟁을 처음부터 다시 하지 않게 해 준다.
읽어주셔서 감사합니다. 😊