대부분의 LLM 프로젝트에는 예측 가능한 흐름이 있습니다. 무언가 제대로 작동하지 않으면 누군가 "파인튜닝(Fine-tuning)을 해야 합니다"라고 말하고, 한 달 동안 데이터셋 정리와 GPU 비용을 지불하며 시간을 허비하지만, 모델은 이전과 거의 비슷하게 틀린 답을 내놓습니다. 왜냐하면 실제 문제는 모델 앞에 올바른 사실(facts)이 없었다는 것이기 때문입니다. 파인튜닝(Fine-tuning)은 결코 그 문제를 해결할 수 없었습니다.

세 가지 기술 — 프롬프팅 (Prompting), 검색 증강 생성 (RAG, Retrieval-Augmented Generation), 그리고 파인튜닝 (Fine-tuning) — 은 저렴한 것에서 비싼 것으로 올라가는 사다리가 아닙니다. 이들은 _서로 다른 문제_를 해결하며, 잘못된 기술을 선택하는 것은 알아차리기 어려운 방식으로 비용이 발생합니다. 즉, 몇 주를 허비하는 동안 마치 진전이 있는 것처럼 보이기 때문입니다.

이 글은 의사결정 프레임워크(decision framework)입니다. "각 기술이 무엇인가"에 대한 설명이 아닙니다 — 그런 정보는 어디서든 얻을 수 있습니다 — 대신, 당신의 문제가 실제로 무엇을 필요로 하는지 알려주는 구체적인 질문들과, 잘못 선택했을 때 나타나는 실패의 징후들을 다룹니다.

대부분의 논쟁을 종결시키는 단 하나의 차이점

어떤 프레임워크를 적용하기 전에, 이 구분을 내재화하십시오. 이것만으로도 "파인튜닝을 해야 하는가?"에 대한 논쟁의 80%가 해결됩니다.

• RAG는 모델이 _아는 것(knows)_을 바꿉니다. 추론(inference) 시점에 컨텍스트(context)에 사실을 주입합니다.
• 파인튜닝(Fine-tuning)은 모델이 _행동하는 방식(behaves)_을 바꿉니다. 스타일, 형식, 구조 및 특정 작업에 특화된 기술을 변화시키기 위해 가중치(weights)를 조정합니다.
• 프롬프팅(Prompting)은 모델이 이미 가지고 있는 지식과 행동을 사용하여, _지금 당장 무엇을 해야 하는지_를 바꿉니다.

따라서 첫 번째 질문은 결코 "어떤 기술이 가장 좋은가?"가 아닙니다. "내 문제가 지식의 격차(knowledge gap)인가, 아니면 행동의 격차(behavior gap)인가?"가 되어야 합니다.

• 모델이 당신의 데이터에 대해 오래된 정보, 허구의 정보, 또는 "해당 정보에 접근할 수 없습니다"라는 답변을 내놓는다면 → 지식의 격차 → RAG.
• 모델이 사실은 알고 있지만, 당신이 필요로 하는 _형식(format), 어조(tone), 또는 작업 구조(task structure)_를 안정적으로 생성하지 못한다면 → 행동의 격차 → 파인튜닝 (Fine-tuning) (아마도).
• 아직 모델에게 무엇을 해야 할지 명확하게 말해보는 시도를 진지하게 하지 않았다면 → 프롬프팅 (Prompting), 언제나 최우선입니다.

이 부분을 잘못 판단하면 그 어떤 엔지니어링으로도 구제할 수 없습니다. 모델이 "당신의 문서를 알게 하기" 위해 파인튜닝 (Fine-tuning)을 하는 것은 전형적인 오류입니다. 가중치 (Weights)에 몇 가지 사실을 구워 넣을 수는 있지만, 문서가 변경되는 순간 그 정보는 구식이 되며, 출처를 인용할 수도 없고, 단순한 조회 (Lookup) 기능보다 못한 버전을 만들기 위해 학습 컴퓨팅 자원 (Training compute)을 낭비하게 됩니다. 변화하는 지식은 가중치가 아니라 검색 (Retrieval) 영역에 있어야 합니다.

항상 프롬프팅 (Prompting)부터 시작하세요 (네, 지금도 마찬가지입니다)

프롬프팅 (Prompting)은 졸업해야 할 초보자 단계가 아닙니다. 2026년, 프론티어 모델 (Frontier models) 시대에는 잘 구성된 프롬프트와 몇 가지 좋은 예시만으로도, 팀들이 학습 (Training)이 필요하다고 가정하는 문제들의 놀라울 정도로 많은 부분을 해결할 수 있습니다. 프롬프팅은 가장 빠르고, 저렴하며, 검사 가능한 (Inspectable) 옵션이며, "파인튜닝 (Fine-tune)"이라는 단어를 꺼내기 전에 반드시 거쳐야 할 기준점 (Baseline)이 되어야 합니다.

다음과 같은 경우에는 프롬프팅을 선택하세요:

• 무엇이 "좋은 출력 (Good output)"인지 여전히 탐색 중일 때. 프롬프트는 몇 초 만에 수정할 수 있지만, 데이터셋 (Datasets)은 그렇지 않습니다.
• 작업이 모델이 이미 광범위하게 수행할 줄 아는 추론 (Reasoning), 변환 (Transformation), 또는 생성 (Generation)일 때.
• 이번 주 안에 배포해야 할 때.

프롬프팅의 효율을 극대화하는 기술들은 화려하지는 않지만 실질적입니다: 정밀한 역할 및 작업 프레이밍 (Role and task framing), 정확한 출력 형태를 보여주는 퓨샷 예시 (Few-shot examples), 다단계 추론을 위한 생각의 사슬 (Chain-of-thought), 그리고 다운스트림 (Downstream) 코드가 결과를 신뢰할 수 있도록 하는 엄격한 출력 계약 (Structured/JSON) 등이 있습니다. 대부분의 "모델이 이걸 못 한다"라는 결론은 사실 "우리가 질문을 잘못했다"라는 결론입니다. 더 무거운 작업에 비용을 쓰기 전에 프롬프팅의 한계를 끝까지 끌어올리는 것은 그 자체로 하나의 규율입니다. 이것이 바로 prompt engineering masterclass의 핵심이며, 프롬프팅을 먼저 제대로 해냈을 때의 투자 대비 효과 (ROI)는 엄청납니다. 왜냐하면 모든 다운스트림 과정이 더 나은 기준점을 물려받기 때문입니다.

프롬프팅의 한계(The prompting ceiling) — 한계에 도달했음을 아는 방법: 진지하게 반복(iteration)을 시도하고, 좋은 예시들을 추가했음에도 모델이 여전히 실패한다면, 그 실패의 원인이 (a) 모델이 도저히 알 수 없는 사실을 모르는 것이거나, (b) 지시어를 어떻게 표현하든 입력값에 따라 일관된 동작을 유지하지 못하는 것이라면 한계에 도달한 것입니다. (a)는 RAG를 가리킵니다. (b)는 어쩌면 파인튜닝(fine-tuning)을 가리킬 수 있습니다. 그 전에는 아닙니다.

지식(Knowledge)이 문제라면 RAG를 선택하세요

모델이 학습하지 않은 정보, 즉 사내 문서, 제품 카탈로그, 지난주의 티켓, 매일 업데이트되는 지식 베이스, 혹은 그 어떤 비공개 데이터나 최신 정보와 함께 작업해야 할 때마다 RAG는 정답이 됩니다.

다음과 같은 경우 RAG를 선택하세요:

• 답변이 **특정 코퍼스(corpus)에 근거(grounded)**해야 하며, **출처를 인용(cite sources)**해야 할 때.
• 지식이 변경될 때 — 가격, 정책, 문서, 재고 등. 모델이 아닌 인덱스(index)를 업데이트하면 됩니다.
• 사실 관계에 대한 환각(Hallucination)이 허용되지 않으며, 답변이 어디서 왔는지에 대한 감사 추적(audit trail)이 필요할 때.
• 지식 베이스가 방대하거나, 사용자별로 부분적인 접근 제어가 필요할 때.

지식 측면에서 RAG가 파인튜닝을 이기는 이유는 명확합니다. 문서 저장소를 업데이트하는 것은 사소하고 즉각적인 작업이지만, 가중치(weights)를 업데이트하는 것은 별도의 학습 과정(training run)이 필요하기 때문입니다. RAG는 최신성, 출처(provenance), 그리고 사용자별 접근 제어를 무료로 제공하며, 파인튜닝은 이 중 어느 것도 제공할 수 없습니다. 사실 관계에 유통기한이 있다면 검색(retrieval)이 유일한 올바른 아키텍처이며, 이를 잘 구축하는 것(청킹(chunking), 하이브리드 검색(hybrid search), 재순위화(re-ranking))이 진정한 엔지니어링의 영역입니다. 이는 RAG 및 검색 증강 생성(retrieval-augmented generation) 전문 과정의 핵심 내용이기도 합니다.

RAG 자체의 한계: 검색은 모델이 _무엇을 아는지_를 해결할 뿐, 모델이 _어떻게 행동하는지_를 해결하지는 못합니다. 만약 RAG의 답변이 사실적으로는 정확하지만 잘못된 형식이나 톤으로 출력되거나, 프롬프트를 아무리 조정해도 기업의 스타일 가이드를 따르지 않는다면, 그 잔여적인 행동 격차(behavior gap)가 바로 파인튜닝이 RAG를 대체하는 것이 아니라, RAG 위에(on top of) 얹혀서 마침내 제 역할을 수행해야 하는 지점입니다.

문제가 행동(behavior)일 때만 파인튜닝(Fine-tuning)을 수행하세요

파인튜닝(Fine-tuning)은 적절한 도구이지만, 그 명성만큼 광범위한 문제가 아니라 훨씬 더 좁은 범위의 문제에 적합합니다. 파인튜닝은 프롬프트(prompt)로 명시하기 어려운 _일관된 행동(consistent behavior)_을 가르칠 때 빛을 발합니다. 예를 들어, 매우 구체적인 출력 구조, 특정 도메인의 톤(tone)과 용어, 레이블이 지정된 예시(labeled examples)가 많은 분류(classification) 또는 추출(extraction) 작업, 혹은 베이스 모델(base model)이 서툴게 수행하는 기술 등이 이에 해당합니다.

다음과 같은 경우에 정당하게 파인튜닝(Fine-tuning)을 고려하십시오:

• 프롬프팅(prompting)만으로는 전체 입력 분포(input distribution)에 걸쳐 유지할 수 없는 수준의 일관된 스타일, 형식 또는 구조가 필요한 경우.
• 좁고, 볼륨이 크며, 잘 정의된 작업(분류, 추출, 특정 변환 등)이 있고, 충분한 양의 고품질 레이블 데이터(labeled data)를 보유한 경우.
• 프롬프트(prompt)에서 해당 행동을 제거할 수 있도록 **행동을 내재화(bake in)**하고 싶은 경우 — 이를 통해 더 짧은 프롬프트, 호출당 비용 절감, 대규모 환경에서의 빠른 응답 속도를 얻을 수 있습니다.
• 대규모 환경에서 지연 시간(latency)이나 비용이 중요하며, 더 작은 파인튜닝(fine-tuned) 모델이 프롬프트가 적용된 더 큰 모델과 대등한 성능을 낼 수 있는 경우.

두 가지 요소가 현대의 파인튜닝(fine-tuning)을 그 명성보다 훨씬 덜 두렵게 만듭니다. 첫째, 거의 전체 파인튜닝(full fine-tuning)을 수행하지 않습니다 — LoRA/QLoRA와 같은 매개변수 효율적 방법론(parameter-efficient methods)은 아주 작은 어댑터 가중치(adapter weights) 세트만을 학습시키며, 대부분의 이점을 얻으면서도 연산 및 메모리 비용을 수십 배 이상 절감합니다. 둘째, 병목 현상은 모델의 선택이 아니라 데이터의 품질입니다. 수백 개에서 수천 개의 깨끗하고, 일관되며, 대표성 있는 예시가 거대하고 노이즈가 많은 데이터 더미를 언제나 압도합니다. 파인튜닝(fine-tuning)의 어려운 점은 결코 학습 작업(training job)을 실행하는 것이 아니었습니다. 그것은 데이터셋을 구축하고, PEFT 트레이드오프(trade-offs)를 선택하며, 스스로를 속이지 않고 결과를 평가하는 것이며, 이것이 바로 파인튜닝 코스가 가치가 있으려면 반드시 다뤄야 하는 영역입니다.

파인튜닝(fine-tuning)이 잘못된 답인 경우 — 위험 신호(red flags):

• "우리 문서를 학습시켜서(fine-tune) 내용을 알게 만들자." → 아니요. 그것은 RAG입니다. 파인튜닝된 사실(facts)은 시간이 지나면 낡은 정보가 되며 출처를 인용할 수 없습니다.
• "프롬프팅(prompting)을 제대로 시도해본 적이 없어요." → 그것부터 먼저 하세요. 아예 학습(training)이 필요 없을 수도 있습니다.
• "요구사항이 매주 바뀝니다." → 파인튜닝은 동작(behavior)을 고착화합니다. 목표가 계속 움직인다면 끊임없이 재학습을 해야 합니다. 요구사항이 안정될 때까지는 프롬프트에 유지하세요.
• "예시 데이터가 40개 있습니다." → 보통 신뢰할 수 있는 동작 변화를 일으키기에는 충분하지 않습니다. 이 40개를 퓨샷 예시(few-shot examples)로 사용하는 강력한 프롬프팅이 아마 더 나은 결과를 낼 것입니다.

조합이 진정한 해답입니다

이 기술들을 경쟁 관계로 설정하는 것은 초보적인 실수입니다. 실제 프로덕션 환경에서 가장 강력한 시스템은 이들을 조합합니다. 왜냐하면 이들은 지식(knowledge), 동작(behavior), 지시(instruction)라는 서로 다른 축에서 작동하며 깔끔하게 쌓이기 때문입니다:

• RAG + 프롬프팅(prompting): 지식에 기반한 대부분의 어시스턴트를 위한 핵심 동력입니다. 적절한 컨텍스트(context)를 검색(retrieve)한 다음, 잘 설계된 프롬프트가 모델에게 오직 그 컨텍스트로부터만 답변하고 출처를 인용하도록 지시합니다. 별도의 학습이 필요하지 않습니다.
• 파인튜닝(fine-tuning) + RAG: 하이엔드 방식입니다. 도메인의 동작(톤, 형식, 작업 기술)을 위해 파인튜닝을 수행하고, 사실(facts)을 위해 RAG를 사용합니다. 모델은 정확하게 동작하면서도 최신 상태를 유지합니다. 즉, 동작은 가중치(weights)에, 지식은 인덱스(index)에 담깁니다.
• 파인튜닝(fine-tuning) + 프롬프팅(prompting): 길고 취약한 지시 사항을 학습된 동작으로 압축합니다. 이를 통해 프롬프트는 짧아지고 추론(inference) 비용은 저렴해집니다.

이들을 오케스트레이션(orchestrating)하는 것, 즉 어떤 레이어가 어떤 책임을 가질지 결정하고 검색, 도구, 모델을 적절한 순서로 거치도록 요청을 라우팅(routing)하는 것은 그 자체로 하나의 엔지니어링 전문 분야이며, 이는 고급 LLM 통합 과정(course on advanced LLM integration)의 핵심입니다. 유지해야 할 멘탈 모델은 다음과 같습니다: 지식 → 검색(retrieval), 동작 → 가중치(weights), 지시 → 프롬프트(prompt). 각 요구사항을 실제로 존재하는 축에 배치하세요.

한 번에 내리는 결정

문제를 다음 순서대로 검토하세요. 해당되는 첫 번째 단계에서 멈추면 됩니다:

1. 프롬프팅 (Prompting)을 진정으로 다 소진했는가 — 명확한 지침, 충분한 퓨샷 예시 (few-shot examples), 구조화된 출력 (structured output)을 시도했나요? 그렇지 않다면 → 프롬프팅 (prompt). (대부분의 프로젝트는 여전히 이 단계에 머물러 있어야 합니다.)
2. 실패의 원인이 지식의 공백 (knowledge gap)인가 — 누락되었거나, 오래되었거나, 비공개인 사실 정보가 필요하며 인용 (citations)이 필요한가요? → RAG.
3. 실패의 원인이 행동의 공백 (behavior gap)인가 — 프롬프트로 유지할 수 없는 형식/톤/작업 일관성 문제이며, 품질이 검증된 라벨링된 데이터 (labeled data)가 있고, 목표가 안정적인가요? → 파인튜닝 (fine-tune) (먼저 LoRA부터 시도하세요).
4. 둘 다 해당되는가? → 사실 관계를 위해 RAG를, 행동 양식을 위해 파인튜닝을 사용하세요. 그 순서를 지키십시오.

그리고 이 모든 것의 밑바탕에는 이것이 있습니다: 평가 (evaluation) 없이는 이 결정을 내릴 수 없습니다. "더 나아 보인다"는 것은 데이터가 아닙니다. 선택하기 전에, 정답(known-good outputs)이 포함된 대표적인 입력값들로 구성된 작은 평가 세트 (eval set)를 구축하세요. 그래야 프롬프팅이 이미 기준을 통과했는지, RAG가 실제로 올바른 컨텍스트 (context)를 검색하는지, 그리고 파인튜닝이 지표를 개선했는지 아니면 단순히 실패의 양상만 바꿨는지를 측정할 수 있습니다. 이를 건너뛰는 팀은 느낌 (vibes)에 따라 기술을 선택하다가 운영 환경(production)에서 실수를 발견하게 되며, 평가를 일급 시민(first-class)으로 취급하는 팀은 의도적으로 저렴하고 정확한 선택을 내립니다. 평가 세트는 이 프레임워크를 단순한 의견에서 결정으로 바꿔주는 핵심 요소입니다.

결론

수많은 LLM 프로젝트가 정체되는 이유는 기술이 부족해서가 아닙니다. 잘못된 기술을 붙잡고 움직이는 것을 진전이라고 착각하기 때문입니다. 모델에게 "사실을 학습시키기" 위해 파인튜닝을 하거나, 실제로는 잘못된 프롬프트 문제인 것을 RAG로 해결하려 하거나, 모델에 근본적으로 데이터가 부족한데 프롬프트만 붙들고 씨름하는 것: 이 모든 것은 노력처럼 보이지만 결국 실패하게 됩니다.

이 구분점에 중심을 둔다면 거의 실패할 일이 없을 것입니다. 변화하는 지식(Knowledge) → RAG. 프롬프트로 해결할 수 없는 행동 양식(Behavior) → 미세 조정 (Fine-tuning). 그 외 모든 것 → 프롬프팅 (Prompting), 그리고 프롬프팅을 잘 할 것. 저렴한 방식부터 시작하여 정직하게 측정하십시오. 그리고 직관이 아닌 평가 (Eval)를 통해 현재 계층이 한계에 도달했음을 확인했을 때만 복잡성을 추가하십시오. 최고의 아키텍처는 가장 정교한 것이 아니라, 각 요구 사항을 실제로 속해 있어야 할 축에 배치하는 아키텍처입니다.

출처 및 추가 읽기:

• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Hu et al. — LoRA: Low-Rank Adaptation of Large Language Models
• Dettmers et al. — QLoRA: Efficient Finetuning of Quantized LLMs

이 기사는 교육용 콘텐츠입니다. 모델, 도구 및 비용 간의 트레이드오프 (Trade-offs)는 빠르게 진화합니다. 프로덕션 환경에 적용하기 전에 반드시 귀하의 데이터와 현재 제공업체의 문서를 바탕으로 모든 접근 방식을 검증하십시오.