[IT-LLM] LLM 완전 정리: 개념·유형·RAG·파인튜닝(SFT·PEFT·LoRA·QLoRA·RLHF)·리스크까지

LLM 완전 정리: 개념·모델유형/패밀리·RAG·파인튜닝·운영 리스크까지

LLM(Large Language Model, 대규모 언어 모델)은 검색·요약·문서작성·코드 보조 등 “언어 기반 업무” 전반에 빠르게 도입되고 있습니다.
하지만 실무에서 체감 성능은 모델 이름만으로 결정되지 않습니다. 근거가 없으면 그럴듯한 오답을 만들어내는 할루시네이션(Hallucination, 환각)이 발생할 수 있고, 내부 정책/업무 규칙이 반영되지 않으면 결과가 들쭉날쭉해집니다.
그래서 운영 환경에서는 RAG(Retrieval-Augmented Generation, 검색 증강 생성)로 “근거 기반 응답”을 만들고, 파인튜닝(Fine-tuning)으로 “형식·문체·규칙”을 고정하는 전략을 함께 고려합니다.

이 글에서 얻을 수 있는 것
1) LLM이 무엇을 계산하는지(원리)와 어디서 틀리는지(한계) 이해
2) LLM “유형(성격)”과 “모델 패밀리(제품군: LLaMA/Gemma 등)”를 구분해 선택 기준 정리
3) RAG vs 파인튜닝(SFT/LoRA/QLoRA/RLHF)의 역할 차이와 조합 전략 확보
4) 할루시네이션/보안 리스크와 운영 체크리스트로 안정적인 적용 방법 이해

목 차

1. LLM 핵심 개념과 동작 원리
2. LLM 모델 유형과 대표 모델 패밀리
3. RAG(검색 증강 생성): 구조와 품질 포인트
4. 파인튜닝: SFT·PEFT·LoRA·QLoRA(기술 심화)
5. RAG vs SFT vs LoRA 비교(단독 섹션)
6. RLHF: 선호 기반 정렬과 적용 시점
7. 리스크(할루시네이션/보안)와 운영 체크리스트
8. FAQ + 마무리

1. LLM 동작 원리: 토큰·임베딩·트랜스포머 한 번에 이해

이 섹션은 “LLM이 왜 잘 맞추는지/왜 틀리는지”를 이해하기 위한 최소 핵심을 정리합니다. 원리를 이해하면 RAG와 파인튜닝이 왜 서로 보완 관계인지도 명확해집니다.

1.1 LLM(Large Language Model)이란 무엇인가?

LLM은 대규모 텍스트를 학습해, 주어진 문맥에서 다음 토큰(Token, 단어 조각)의 확률을 계산합니다. 즉 “정답 DB를 조회”한다기보다 “자연스러운 다음 표현”을 생성하는 모델입니다.
이 구조 때문에 근거가 부족하면 할루시네이션(Hallucination)이 발생할 수 있습니다.

핵심: LLM 출력은 “그럴듯함”에 최적화될 수 있으므로, 실무에서는 근거(RAG)·제약(정책)·검증(루프)이 필수입니다.

1.2 토큰(Token)·임베딩(Embedding)·트랜스포머(Transformer) 이해

텍스트는 토큰화(tokenization)되어 처리됩니다. 토큰은 벡터로 변환되며 이를 임베딩(Embedding)이라 합니다. 임베딩은 “의미/사용 맥락”을 벡터 공간에 반영하는 표현입니다.
대부분의 현대 LLM은 트랜스포머(Transformer) 구조를 사용하고, 어텐션(Attention)으로 문맥 관계를 계산합니다.

또한 모든 모델에는 컨텍스트 윈도우(Context Window, 문맥 창) 제한이 있습니다. 긴 문서(정책/매뉴얼/기술 문서)를 그대로 넣기 어려워 RAG/요약/분할 설계가 필요합니다.

요소	역할	실무 포인트
토큰(Token)	텍스트 처리 단위	비용·속도·컨텍스트 길이와 직결
임베딩(Embedding)	의미 벡터 표현	RAG 검색 품질(유사도)에 직접 영향
어텐션(Attention)	문맥 관계 계산	긴 문맥에서 계산량 증가 → RAG/요약 전략 중요
컨텍스트 윈도우 (Context Window)	모델 입력 한계	장문 지식은 “그대로” 넣기 어렵다

 

2. LLM 모델 유형과 선택기준 및 대표 모델 패밀리

LLM을 본문에 넣을 때 흔히 헷갈리는 부분이 있습니다. 유형(Type)은 “성격/정렬 방식”이고, 모델 패밀리(Family)는 “구체 모델 제품군(예: LLaMA, Gemma)”입니다. 이 둘을 구분하면 글이 훨씬 명확해집니다.

2.1 LLM 모델 유형(Type): Base / Instruction / Chat / Code / Multimodal

유형은 모델의 정렬(alignment) 방향을 나타내며 “어떤 작업에 강한지”를 가늠하는 첫 번째 힌트입니다.

유형	특징	권장 용도
Base	사전학습 중심. 자유 생성 강함. 지시 수행/정책 준수는 추가 설계 필요	리서치/실험, 커스텀 정렬 전 단계
Instruction	지시-응답 데이터로 정렬. 구조화된 출력/형식 준수에 강함	요약/정리/템플릿 출력, 문서 자동화
Chat	대화 UX·안전 정책을 고려해 정렬. 멀티턴 대화 안정적	상담/고객지원, 대화형 Q&A, 에이전트
Code	코드 데이터 비중 높음. 코드 생성/리팩터링/테스트 생성에 강점	개발 보조, 코드 리뷰, 자동화 스크립트
Multimodal	텍스트+이미지/음성 등 다중 입력/출력 지원	문서 이미지 이해, UI/도면 분석

2.2 LLM 선택 기준(실무 체크포인트) 

모델 선택은 “최대 성능”이 아니라 업무 목표와 실패 비용에 맞춰야 합니다. 예를 들어 정책/법무/절차 문서 답변은 오답 비용이 크므로 RAG·출처 표기·검증이 우선입니다.

선택 기준	질문(체크)	의사결정 힌트
정확성(근거)	답변에 출처/근거가 반드시 필요한가?	필요하면 RAG 우선, 출처 표기
출력 형식	표/템플릿/JSON 등 형식 준수가 중요한가?	Instruction/Chat + SFT/LoRA 고려
대화 안정성	멀티턴 대화와 안전 정책 준수가 중요한가?	Chat 계열 우선
코드/기술문서	코드 생성/디버깅이 핵심인가?	Code 계열 우선
지연시간/비용	응답 속도와 토큰 비용이 빡빡한가?	작은 모델 + RAG/캐시/요약, 필요 시 LoRA
보안/컴플라이언스	민감정보/폐쇄망/감사 로그가 중요한가?	가드레일 + 권한 통제

2.3 LLM 대표 모델 패밀리(제품군) 예시: LLaMA / Gemma / Mistral(Mixtral) / Qwen 등

LLaMA, Gemma 같은 이름은 “모델 유형”이 아니라 모델 패밀리(제품군)입니다. 오픈 웨이트(Open-weight)인지, 상용 API(Hosted)인지에 따라 운영 방식이 크게 달라집니다.

구분	패밀리	특징/코멘트
오픈 웨이트 (Self-hosted)	LLaMA (Meta)	대표 오픈 웨이트 계열. RAG/LoRA 적용과 자체 서빙에 자주 사용
	Gemma (Google)	경량·안정성 중심. 연구/PoC에 적합(라이선스 조건 확인 필요)
	Mistral / Mixtral	경량 고성능. Mixtral은 MoE(Mixture of Experts) 계열로 처리 효율이 장점
	Qwen (Alibaba)	다국어/코딩/멀티모달 확장 폭이 넓어 활용 범위가 큼
	DeepSeek	코딩·수학 태스크에서 언급이 많음(적합 작업 확인 필요)
	Phi (Microsoft)	소형 모델 계열로 경량 환경/엣지 활용에서 후보가 됨
상용 API (Hosted)	GPT 계열	범용성/생태계 강점. 운영 편하지만 비용·데이터 거버넌스 고려
	Claude 계열	긴 문맥/안전성 측면에서 언급이 많음(서비스 요구에 따라 선택)
	Gemini 계열	멀티모달/검색 연계 관점에서 활용도가 높음

2.4 LLaMA vs Gemma vs Mistral/Mixtral 실무 관점 비교

같은 “오픈 웨이트”라도 패밀리마다 강점이 다릅니다. 여기서는 실무 관점을 중심으로 비교합니다. (최종 선택은 목적·라이선스·벤치·운영 조건에 따라 달라집니다.)

패밀리	강점(경향)	주의 포인트	추천 시나리오
LLaMA	범용 적용 폭이 넓고 생태계/레퍼런스가 많음	상업/배포 조건은 라이선스 확인 필요	RAG + LoRA 기반 사내 Q&A/도우미 구축
Gemma	경량/안정성 중심으로 PoC와 반복 실험에 유리한 편	규모/목표 태스크에 따라 성능 한계 가능	경량 환경에서 RAG 성능 검증, 파일럿 서비스
Mistral / Mixtral	효율/성능 균형, Mixtral은 MoE로 처리 효율 장점	서빙/병렬/메모리 설계가 중요할 수 있음	비용 효율을 중시하는 운영형 서비스, 대량 요청 처리

포인트: “유형(성격)”을 먼저 고르고, 그 다음 “패밀리(제품군)”를 선택한 뒤, 마지막에 RAG/파인튜닝/운영 정책으로 품질을 고정하는 것이 실무 흐름입니다.

 

3. LLM의 할루시네이션 감소, RAG(검색 증강 생성): 구조와 품질 포인트

RAG는 “최신성/근거”를 확보하는 구조입니다. LLM이 학습으로 가진 지식만으로 답하면 근거 없는 확신이 섞이기 쉬운데, RAG는 문서 근거를 끌어와 그 문제를 줄입니다.

3.1 RAG(Retrieval-Augmented Generation)의 핵심 아이디어

RAG는 Retrieval-Augmented Generation으로, 생성 전에 검색을 수행해 관련 문서 조각을 확보합니다. 그 조각을 프롬프트 문맥에 포함시켜 답변을 만들면, 출처 기반 응답을 유도할 수 있어 할루시네이션(Hallucination)을 줄이는 데 도움이 됩니다.

3.2 RAG 파이프라인(수집→청킹→임베딩→검색→생성)

RAG는 “벡터DB 붙이면 끝”이 아니라, 문서 품질과 설계가 누적되어 성능을 결정합니다. 아래 파이프라인을 단계별로 체크하면 품질 문제를 체계적으로 개선할 수 있습니다.

단계	설명
문서 수집	FAQ/매뉴얼/정책/기술문서 확보 + 정본(Source of Truth) 정의
정제/전처리	중복 제거, 버전/날짜/출처 메타데이터 부여, 민감정보 마스킹
청킹(Chunking)	적절한 길이/오버랩 설계(너무 길면 검색 흐림, 너무 짧으면 문맥 부족)
임베딩/색인	청크(Chunk)를 임베딩(Embedding)해 벡터 DB/검색 인덱스에 저장
검색/재랭킹	Top-K 검색 후 재랭킹으로 정확도 개선(질문 유형별 전략 분리 가능)
생성/출처표시	검색 결과를 문맥에 포함해 답변 생성, 가능하면 출처(문서명/섹션) 제공

3.3 RAG + Self-hosted LLM(LLaMA) 데이터 흐름 예시

아래는 오픈 웨이트 계열(예: LLaMA)을 사내에서 서빙하면서 RAG를 붙이는 가장 흔한 구조 예시입니다. 블로그 본문에는 이런 “데이터 흐름”이 들어가면 정보성/기술성이 강화됩니다.

[User Query]
  ↓ (1) Query Normalization / Safety Filter
[Retriever]
  ↓ (2) Vector Search (Embedding) + Metadata Filter
[Top-K Chunks]
  ↓ (3) Re-ranking (optional) + Context Builder
[Prompt (Instruction + Context + Citations)]
  ↓ (4) LLaMA Inference (Self-hosted)
[Answer + Sources + Confidence Policy]
  ↓ (5) Logging / Monitoring / Feedback Loop

이 구조에서 품질을 좌우하는 지점은 (2) 문서/청킹/임베딩 품질과, (3) 재랭킹/컨텍스트 구성, 그리고 (4) 모델이 “근거 없으면 모른다고 말하게 만드는” 정책(출처/불확실성 허용)입니다.

포인트: 할루시네이션을 줄이려면 “모델을 더 크게”보다 근거(RAG) + 출처 + 모름 정책이 먼저입니다.

 

4. 파인튜닝(Fine-tuning) : SFT·PEFT·LoRA·QLoRA

파인튜닝은 모델이 “무엇을 아는가”보다 “어떻게 답하는가”를 안정화하는 데 강합니다. 따라서 RAG가 근거를 가져오는 구조라면, 파인튜닝은 형식·문체·업무 규칙·분류 기준을 고정하는 역할로 이해하는 것이 정확합니다.

4.1 SFT (Supervised Fine-Tuning, 지도 미세조정): 데이터 설계가 전부다

SFT는 Supervised Fine-Tuning의 약자로, “지시(입력)–모범답(출력)” 페어 데이터로 추가 학습하는 방식입니다. 템플릿 출력, 어조 통일, 규칙 기반 응답(예: 보고서 형식)에서 효과가 큽니다.

SFT 성패는 모델보다 데이터에 달려 있습니다. 같은 유형 질문에 답변 형식이 섞이면 모델도 섞여 출력합니다. 따라서 라벨링 규칙(길이/톤/금지 표현)을 먼저 합의하고, 검증셋(운영 질문)을 별도로 구성해 회귀 테스트를 해야 합니다.

데이터 설계 포인트	설명
일관성	같은 유형 질문은 같은 형식/길이/톤으로 답하도록 기준을 통일
금지/허용 규칙	추측성 답변, 과도한 확신 표현을 제한하는 예시 포함
검증셋 분리	운영 질문을 따로 묶어 과적합/회귀(업데이트 후 악화) 확인

4.2 PEFT (Parameter-Efficient Fine-Tuning, 파라미터 효율 미세조정): 비용을 줄이는 학습전략

PEFT는 Parameter-Efficient Fine-Tuning으로, 모델 전체를 업데이트하지 않고 일부 파라미터만 학습해 비용을 줄이는 전략입니다. 대형 모델은 전체 파인튜닝(Full Fine-tuning)이 비싸기 때문에, 실무에서는 PEFT 계열이 현실적인 선택이 되는 경우가 많습니다.

• 기존 가중치(W)는 고정(freeze), 추가 파라미터만 학습
• 학습 파라미터 감소 → GPU 요구량↓, 학습 속도↑
• 태스크/고객사별 모듈 분리 운영 → 배포/교체/롤백 용이

4.3 LoRA (Low-Rank Adaptation, 저랭크 적응): 저랭크 보정으로 빠르게 최적화

LoRA는 Low-Rank Adaptation으로, 가중치 W를 직접 바꾸지 않고 저랭크(rank r) 보정 ΔW를 학습합니다. 핵심은 ΔW를 작은 행렬 A, B의 곱으로 표현해 학습 파라미터를 줄이는 것입니다.

기존 가중치: W (고정)
변화량: ΔW = A × B (저차원)
최종 적용: W + ΔW

LoRA는 “응답 습관”을 바꾸는 데 강합니다. 예를 들어 (1) 보고서 문체, (2) 출력 포맷(JSON/표), (3) 특정 규칙(분류 기준) 등을 안정화할 때 유리합니다. 다만 최신 지식/근거를 자동으로 확보하지는 못합니다.

4.4 QLoRA (Quantized Low-Rank Adaptation, 양자화 저랭크 적응): 양자화 기반 메모리 절감 파인튜닝

QLoRA는 Quantized Low-Rank Adaptation으로, 가중치를 양자화(Quantization, 저비트 표현)해 메모리 부담을 줄이고, 그 상태에서 LoRA 어댑터만 학습하는 방식입니다.

즉, QLoRA는 “학습량을 줄이는 LoRA”에 더해 “메모리 제약까지 완화”하는 접근입니다. 하지만 양자화 설정/라이브러리 차이에 따라 품질 편차가 있을 수 있으므로, 검증셋으로 성능/회귀를 반복 확인해야 합니다.

4.5 파인튜닝만으로 “최신 지식” 문제를 해결하기 어려운 이유

파인튜닝은 “답변 스타일/규칙”을 학습시키는 데는 강하지만, “최신 정보”를 안정적으로 반영하는 용도로는 한계가 있습니다. 이유는 크게 3가지입니다.

• 정적 학습(Static): 학습 시점 이후의 정보는 모델 내부에 자동 반영되지 않음
• 근거 추적 어려움: 모델이 어떤 문서에서 배웠는지 사용자에게 출처로 제시하기 어려움
• 업데이트 비용: 최신 정보 반영을 위해 자주 재학습하면 비용/검증 부담이 큼

결론: 최신성·근거가 핵심이면 RAG가 우선이고, 파인튜닝은 형식/문체/규칙 안정화에 쓰는 것이 효과적이다.
예를 들어, 파인튜닝이 직원 교육이라면, RAG는 직원에게 최신 매뉴얼을 주는것이라고 말할 수 있습니다.

 

5. RAG vs SFT vs LoRA 비교: 목적별 선택 프레임

이 섹션은 “무엇을 개선하려는가?”에 따라 접근을 빠르게 선택하기 위한 비교표입니다. 특히 할루시네이션이 문제라면 근거 확보(RAG)가 가장 직접적인 해법인 경우가 많습니다.

5.1 무엇을 개선하려는가: 정확성·형식·비용 hooking

아래 표는 역할/강점/리스크/추천 상황을 기준으로 정리했습니다.

구분	풀네임	강점	약점/리스크	추천 상황
RAG	Retrieval-Augmented Generation	근거 기반, 최신/내부 문서 반영, 할루시네이션 감소	문서/청킹/검색 설계에 품질이 좌우	사내 문서 Q&A, 정책/매뉴얼 기반 답변
SFT	Supervised Fine-Tuning	문체/형식/규칙 일관화, 템플릿 출력	데이터 기준이 흔들리면 출력도 흔들림	형식 강제, 보고서/응대 톤 통일
LoRA	Low-Rank Adaptation	저비용 파인튜닝, 어댑터 분리 운영, 반복 실험	최신 근거 확보 한계, 과적합 가능	자원 제한 환경, 다중 고객사/태스크 운영

5.2 권장 조합 패턴: RAG + (SFT/LoRA)

운영에서 가장 흔한 패턴은 RAG로 근거/정확성을 확보한 뒤, SFT/LoRA로 형식·문체·업무 규칙을 고정하는 조합입니다.

패턴	언제 유리한가
RAG 단독	출처/정확성이 최우선, 출력 형식 요구가 크지 않을 때
SFT/LoRA 단독	형식/문체/규칙이 핵심이고 지식이 자주 바뀌지 않을 때
RAG + SFT	근거 기반 답변 + 템플릿 구조를 강하게 고정해야 할 때
RAG + LoRA(QLoRA)	근거는 RAG로, 고객사/태스크 규칙은 어댑터로 분리 운영하고 싶을 때

 

6. RLHF(Reinforcement Learning from Human Feedback): 선호도 정렬과 적용 시점

RLHF는 “정확성”뿐 아니라 “사용자 선호/정책 준수/대화 품질”을 강화하는 단계에서 고려됩니다. 도입 비용이 있는 편이므로 언제 필요해지는지(적용 시점)를 중심으로 이해하면 좋습니다.

6.1 RLHF 개요: '정확성' 이후의 품질 요소

RLHF는 Reinforcement Learning from Human Feedback의 약자로, 사람이 더 좋은 답변을 선택/평가한 데이터를 바탕으로 모델을 정렬합니다. 친절함·안전성·일관성·정책 준수 같은 요소를 강화하는 데 유리합니다.

실무에서는 보통 RAG + SFT/LoRA로 기반을 만든 뒤, 만족도/정책 준수 KPI를 더 끌어올려야 할 때 RLHF를 검토합니다.

6.2 언제 RLHF가 필요한가: KPI/정책/만족도 기준

RLHF는 KPI로 개선을 측정할 수 있을 때 효과가 큽니다(만족도, 정책 위반률, 재문의율 등).

 

7. 리스크(할루시네이션/보안)와 운영 체크리스트

LLM을 실제 프로세스에 연결하면 품질 문제뿐 아니라 보안/권한/로그 같은 운영 이슈가 같이 등장합니다. 이 섹션에서는 가장 흔한 리스크(할루시네이션, 프롬프트 인젝션)를 중심으로 실무 장치를 정리합니다.

7.1 할루시네이션(Hallucination)을 줄이는 실무 장치

할루시네이션을 0으로 만들기는 어렵지만, 설계로 리스크를 크게 줄일 수 있습니다. 핵심은 근거 강제(RAG), 불확실성 허용(모름 정책), 검증 루프(테스트/로그)입니다.

• RAG 근거 제공: 답변에 사용한 문서 조각을 문맥에 포함하고 출처를 표시
• 모름 정책: 근거가 없으면 추가 질문 또는 “확실하지 않음”을 허용
• 중요 정보 재검증: 수치/절차/규정은 룰/툴로 2차 검증
• 회귀 테스트: 운영 질문 세트로 정기 평가(업데이트 후 악화 감지)

7.2 프롬프트 인젝션(Prompt Injection)과 권한 통제

프롬프트 인젝션(Prompt Injection)은 시스템 지시를 무력화하거나 민감정보를 유출하도록 유도할 수 있습니다. 따라서 입력·검색·출력 전 구간에서 방어가 필요합니다.

영역	권장 조치
입력	인젝션 패턴 탐지, 허용된 명령만 처리, 시스템 프롬프트 노출 차단
RAG	신뢰 문서만 인덱싱, 민감 문서 접근제어, 최신 정책 우선 필터링
툴 호출	권한/스코프 제한, 고위험 기능은 서버 측 검증 또는 승인 단계
운영	감사 로그, 이상징후 모니터링, 회귀 테스트, 업데이트 루프

7.3 배포 전/후 운영 체크리스트(로그·회귀 테스트)

LLM 시스템은 “한 번 만들고 끝”이 아니라, 문서/모델/프롬프트가 바뀔 때마다 품질이 변합니다. 따라서 배포 전/후로 체크리스트를 고정해 두면 운영 안정성이 크게 올라갑니다.

구분	체크 항목
배포 전	1) 운영 질문 세트(회귀 테스트) 최신화 및 기준점(Baseline) 저장 2) RAG 인덱스 버전/문서 정본/메타데이터 필터 정상 동작 확인 3) “출처 표기/모름 정책”이 프롬프트에 반영되었는지 점검 4) 프롬프트 인젝션/민감정보 테스트 케이스 실행(차단/마스킹 확인) 5) 비용/지연시간 예산(토큰, 응답시간) 측정 및 알람 기준 설정
배포 직후	1) 로그 샘플링으로 할루시네이션 의심 응답/출처 누락 응답 모니터링 2) Top-K 검색 결과 적절성(엉뚱한 문서 검색 여부) 점검 3) 에러/타임아웃/재시도율 지표 확인, 장애 대응 Runbook 적용
운영(상시)	1) 회귀 테스트 정기 실행(주간/월간) + 성능 추이 기록 2) 사용자 피드백(좋아요/싫어요, 재문의) 기반 데이터 개선 루프 3) 문서 갱신 시 인덱스 재구축/버전 관리 + 변경 이력 보관 4) 권한/접근 정책 점검(민감 문서 접근 로그, 비정상 접근 알림)

운영 핵심: 로그와 회귀 테스트가 없으면 “좋아졌는지/나빠졌는지”를 판단할 수 없습니다. 테스트 세트 + 기준점 + 지표를 먼저 고정하는 것이 안정 운영의 시작입니다.

 

8. FAQ + 핵심요약 및 마무리

마지막으로 실무에서 자주 받는 질문을 FAQ 형태로 정리하고, 핵심 메시지를 한 번 더 요약합니다.

8.1 FAQ

Q. RAG와 파인튜닝 중 무엇을 먼저 해야 하나요?
A. 내부 문서 기반 정확성이 목적이면 RAG를 먼저 구축하는 경우가 많습니다. 그 다음 운영 데이터가 쌓이면 SFT/LoRA로 문체/형식을 고정해 품질을 안정화합니다.

Q. LoRA/QLoRA를 하면 할루시네이션이 사라지나요?
A. 완전히 사라지지 않습니다. LoRA/QLoRA는 주로 “응답 방식/규칙”을 학습하는 기법이며, 최신 근거 확보에는 한계가 있어 RAG와 조합하는 것이 일반적입니다.

Q. 왜 출처 표시가 중요한가요?
A. 사용자 신뢰를 높이고, 근거 없는 확신을 줄여 할루시네이션 리스크를 낮추는 데 도움이 됩니다.

8.2 핵심 요약(한 문단 결론)

LLM 도입의 핵심은 “모델 하나로 해결”이 아니라 구성의 조합입니다. 정확성/최신성/출처가 중요하면 RAG(Retrieval-Augmented Generation)로 근거를 확보하고, 형식·문체·업무 규칙을 안정화해야 한다면 SFT(Supervised Fine-Tuning) 또는 PEFT(Parameter-Efficient Fine-Tuning) 계열인 LoRA(Low-Rank Adaptation)/QLoRA(Quantized LoRA)로 응답 습관을 고정합니다. 그 이후 정책 준수/만족도 KPI가 경쟁력이 되는 단계에서는 RLHF(Reinforcement Learning from Human Feedback)를 검토하고, 운영 단계에서는 할루시네이션과 보안(프롬프트 인젝션)을 가드레일·출처·모름 정책·로그·회귀 테스트로 관리하는 것이 현실적인 접근입니다.

 

마무리: LLM은 단일 기술이 아니라 모델 선택(유형/패밀리) + RAG(근거) + 파인튜닝(형식/규칙) + 운영 설계(리스크 관리)의 조합입니다.
특히 할루시네이션(Hallucination)과 보안 리스크는 모델이 아니라 아키텍처와 정책으로 관리해야 합니다.

RAG와 파인튜닝을 비교하다 보면, 결국 기술 자체보다 어떤 기준으로 선택하느냐가 더 중요해진다.
이 관점은 아래 글에서 좀 더 생각의 흐름으로 정리해두었다.
정답을 찾으려 할수록 길을 잃는다, 결국 중요한 건 나만의 판단 기준이다