RAG와 LLM의 한계 — ChatGPT는 왜 모르는 걸 지어내고, 어떻게 고치나

⏱ 정독 약 40분 · LLM 이론 집중코스 7편
이 글에서 잡는 것 4가지:
1. ChatGPT가 왜 모르는 걸 자신있게 지어내는지(환각) — 그리고 LLM의 다섯 가지 한계
2. 이 한계 때문에 “LLM = AGI?”가 왜 아직 천장에 막혀 있는지
3. 그 한계를 검색으로 메우는 RAG — 5·6편의 벡터·내적이 다시 일하는 법
4. RAG로도 안 되는 것, 그리고 파인튜닝·시스템 프롬프트의 자리

---

카메라를 뒤로 — 이번엔 LLM을 바깥에서 본다

1~6편이 LLM의 속을 뜯는 시간이었다면, 7편은 그 한계와 — 한계를 메우는 RAG를 본다.

토큰, 확률, 디코딩, Attention의 내적, Transformer 쌓기. 지금까지는 “안에서 어떻게 돌아가나”였어요. 이번엔 카메라를 뒤로 뺍니다.

“그래서 이게 어디까지 되고, 어디서 푹 꺼지고, 그 구멍을 뭘로 메우나.”

안을 들여다보는 게 아니라 바깥에서 LLM을 평가하는 편이에요. 동선은 이렇습니다.

• 먼저 다섯 군데가 꺼진다 — 환각·컷오프·컨텍스트·추론·기억.
• 그 한계 때문에 “LLM으로 AGI가 되나”가 천장에 막힌다.
• 그 구멍 중 지식·환각을 검색으로 메우는 게 RAG다.
• RAG로도 안 되는 것은 도구·파인튜닝으로 둘러싼다.

(개념이 헷갈리면 [5편] Attention과 [6편] Transformer를 먼저. 이 글은 그 위에 섭니다.)

ChatGPT가 모르는 걸 지어내는 이유 — 환각

흔한 장면 하나. “이 주제 관련 논문 3개 추천해줘, 저자랑 연도까지.” 그러면 진짜 있을 법한 저자 이름, 그럴듯한 제목, 멀쩡한 연도, 학술지 이름까지 딱 나와요.

그런데 그 논문, 세상에 없습니다.

저자도 실존, 학술지도 실존, 그런데 그 조합의 논문은 존재한 적이 없어요. 이걸 환각(hallucination)이라고 불러요.

여기서 다들 똑같이 막혀요.

“아니 모르면 모른다고 하지, 왜 굳이 지어내?”

핵심은 이거예요. LLM은 “사실 검증기”가 아니라 “다음 토큰 확률 예측기”입니다.

“OpenAI는 ____ 에 설립되었다”라는 문장을 이어 쓸 때, 머릿속에서 벌어지는 일은 이렇습니다.

"2015" 가 올 확률  →  0.71
"2016"            →  0.13
"2013"            →  0.08
...

이렇게 확률 분포를 만들고 그중 하나를 골라요. 여기에 “이게 진짜 맞나?”를 검사하는 단계가 어디에도 없어요. 그냥 통계적으로 가장 그럴듯한 다음 토큰을 뱉을 뿐이에요.

그게 우연히 사실이면 정답, 빈칸을 메우다 빗나가면 환각 — 메커니즘은 똑같습니다.

그래서 핵심을 한 번 못 박을게요.

환각은 버그가 아니라, 유창함과 똑같은 뿌리에서 나옵니다.

“그럴듯한 다음 말을 매끄럽게 잇는” 바로 그 능력이, 사실이 비어 있는 자리에선 “그럴듯한 거짓”을 매끄럽게 잇게 만들어요. 유창함과 환각은 동전의 앞뒤예요.

“자신있게”의 정체도 여기 있어요. LLM에겐 자신감이라는 게 없어요. 0.71이든 0.22든 그냥 가장 높은 확률의 토큰을 평소처럼 뱉을 뿐이에요. 우리 눈엔 똑같이 단호한 문장으로 보이니까 “자신있게 거짓말한다”고 느끼는 거죠. 0.22짜리 추측도 0.99짜리 사실과 글자 모양이 똑같으니까.

“사실만 가르치면 환각 안 하지 않나”

자연스러운 반격이 와요. “그럼 학습할 때 사실만 먹이면 되잖아?”

안 됩니다. 사실만 먹여도, 답할 때 LLM은 학습한 조각들을 확률로 보간(interpolation)해서 새 문장을 만들어요. 학습에 없던 조합을 물으면 빈 곳을 “그럴듯하게” 메우는데, 그게 바로 환각이에요.

사실을 외운 것과, 그 사실을 틀림없이 꺼내는 건 다른 문제예요.

“온도를 0으로 하면 환각이 사라지나”

이건 정말 좋은 함정이에요. 5편에서 본 temperature를 0으로 하면 무작위성이 사라지죠. 매번 가장 확률 높은 토큰만 고르니까.

그런데 가장 확률 높은 토큰이 거짓일 수도 있어요.

위의 OpenAI 예에서 만약 학습 데이터가 편향돼 “2016”이 0.71이었다면, temperature 0이어도 또박또박 “2016”이라고 틀려요. temperature는 무작위성을 조절하지 진위를 조절하지 않습니다. 둘은 완전히 다른 축이에요.

그래서 결론. LLM 안에는 사실을 대조할 “출처”가 없어요. 모든 지식이 가중치에 녹아 뭉개져 있어서, 답이 어디서 왔는지 추적도 안 되고 진위 검사도 못 해요. — 이 구멍이 뒤에서 RAG가 정조준하는 첫 번째 자리입니다.

나머지 네 구멍 — 컷오프·컨텍스트·추론·기억

환각이 ①번이라면, 그 거대한 우물이 꺼지는 자리가 넷 더 있어요.

② 지식 컷오프 — 학습 끝난 날 이후는 통째로 모름

“오늘 환율 얼마야?” 물으면 못 맞혀요. “방금 발표된 신제품 스펙은?” → 모르거나 지어냅니다.

왜? 학습이 끝나는 순간 가중치가 얼어붙기 때문이에요. 1~2편에서 봤듯 학습은 데이터를 부어 가중치를 빚는 과정이고, 끝나면 모델은 그 시점에서 박제돼요. 답할 땐 가중치가 1도 안 바뀝니다.

그러니 “학습 컷오프 날짜” 이후의 세상은 존재 자체를 몰라요. 어제 뉴스도, 방금 일도. — RAG가 정조준하는 두 번째 구멍.

③ 컨텍스트 한계 — 한 번에 볼 수 있는 양이 유한

회사 규정집 500페이지를 통째로 넣고 “여기서 답해” 하고 싶죠. 그런데 한 번에 넣을 수 있는 토큰 수(컨텍스트 창)가 정해져 있어요. 넘으면 잘리거나, 돈이 확 뜁니다.

왜 무한정 못 늘리냐 — 6편의 O(N²) 기억나시죠. 토큰 N개가 Attention에서 서로서로 다 내적하니까 계산량이 N²로 불어요.

토큰 1,000개  →  비교 100만 번
토큰 10,000개 →  비교 1억 번   (10배 길었는데 비용은 100배)

여기서 의문 하나. “②컷오프는 RAG로 메운다며, 그럼 검색한 문서를 컨텍스트에 다 때려넣으면 ③ 때문에 또 막히는 거 아냐?”

정확해요. 그래서 RAG의 진짜 묘수가 여기 있어요 — 통째로 넣는 게 아니라, 질문에 “관련된 조각”만 골라 넣어요. 500페이지 중 정답이 든 3문단만. ③한계를 피하면서 ②를 메우는 거죠. 한 돌로 두 마리.

④ 추론·계획 약함 — 진짜 논리가 아니라 패턴 흉내

4837 × 219 를 시켜보면 틀릴 때가 많아요. 사람은 자릿수 계산 절차를 밟는데, LLM은 “이런 식 다음엔 이런 숫자가 오더라”는 패턴으로 답을 흉내 내거든요. 다단계 논리 퍼즐이나 긴 계획에서도 헛디뎌요.

왜? 뿌리는 또 같아요 — 연역 엔진이 아니라 다음 토큰 예측기라서. “단계를 밟는 것”과 “단계를 밟는 것처럼 보이는 문장을 생성하는 것”은 달라요.

보완책은 있어요. 단계적으로 생각하게 시키기(CoT), 추론 전용 모델, 계산은 계산기에 넘기기(도구 사용). 다만 “이게 진짜 추론이냐, 더 정교한 흉내냐”는 잠시 뒤 AGI 논쟁의 핵심이라 거기서 정면으로 붙습니다.

⑤ 기억 없음 — 매 호출이 백지

새 대화창을 열면 어제 한 얘기를 다 까먹죠. “어 근데 대화 중엔 앞 내용 기억하던데?” — 그거 진짜 기억이 아니에요.

앞 대화를 매번 통째로 다시 넣어주는 것뿐이에요(=③ 컨텍스트에 얹는 것). 창을 닫으면 사라지고, 모델 자체는 한 톨도 안 변해요(②와 같은 뿌리).

다섯 구멍을 다 깔았어요. 그리고 보세요 — ①환각, ②컷오프, ③컨텍스트, ⑤기억이 전부 “밖에서 진짜 문서를 찾아다 넣으면” 완화됩니다. 네 구멍을 한 갈래 기술이 동시에 건드려요. 그게 RAG고요.

그 RAG로 가기 전에, 한계가 부르는 더 큰 질문 하나를 먼저 봅니다. “이 정도 한계면, LLM은 결국 AGI가 못 되는 건가?”

AI와 AGI — “잘한다”와 “두루 한다”는 다른 말

옛날 AI는 전부 우물 하나였어요.

알파고는 바둑에서 인간을 아득히 넘었죠. 그런데 알파고한테 “오늘 점심 뭐 먹지?” 물으면? 아무 대답도 못 합니다. 바둑판 밖으로 단 한 발자국도 못 나가요. 번역기도 똑같아요. 번역은 기가 막히게 하는데 “코드 짜줘” 하면 못 합니다.

이게 좁은 AI(Narrow AI)예요. 잘하는 우물이 딱 하나. 그 우물 안에선 신인데, 우물 밖은 깜깜이.

여기서 바로 의문이 떠오르죠 — “그럼 ChatGPT는 좁은 AI 아니잖아?” 맞아요. 그게 충격 포인트예요.

ChatGPT 하나가 번역도 하고, 코드도 짜고, 요약도 하고, 상담도 합니다. 우물이 수십 개처럼 보여요. 60년간 AI는 우물 하나였는데, 처음으로 우물이 많아 보이는 게 나왔으니까.

그래서 AGI(Artificial General Intelligence, 범용 인공지능) — 가운데 G(General, 두루)가 핵심이에요. 셋으로 못 박으면.

1. 범용성 — 인간이 하는 어떤 지적 작업이든 한다.
2. 처음 보는 것도 일반화 — 학습 때 못 본 새 문제를 응용해서 푼다.
3. 스스로 배운다 — 새로 가르치려고 모델을 통째로 다시 훈련시킬 필요가 없다.

위계를 그림으로 잡으면 이래요.

AI (인공지능)  ← 제일 큰 우산. "지능적으로 보이는 모든 것"
 ├─ 좁은 AI    ← 알파고, 번역기, 스팸필터 … 우물 하나
 │     └─ LLM도 사실 여기. "다음 토큰 예측" 한 가지 일을 할 뿐
 └─ AGI        ← 인간급 범용. 아직 아무도 못 만듦 (목표/논쟁)
       └─ ASI  ← 초지능. 인간을 능가. SF 영역

LLM은 우물이 많은 게 아니라, 우물이 하나다

여기가 진짜 한 방이에요. LLM이 번역도 코딩도 다 하니까 우물이 많아 보이지만 — 속을 까보면 LLM이 하는 일은 딱 하나입니다. “다음에 올 토큰을 확률로 맞히기.” (1~5편에서 본 그거.)

번역도, 코딩도, 상담도 전부 “다음 토큰 맞히기”라는 단 하나의 우물로 흉내 낸 거예요. 인터넷 전체를 삼켜서 그 우물이 어마어마하게 넓고 깊어졌을 뿐, 우물 자체는 하나입니다.

그러면 여기서 반격이 와요 — “근데 인간도 결국 보고 들은 거 외워서 짜깁기하는 거 아냐? 그럼 LLM이랑 뭐가 달라?”

이게 정확히 다음 논쟁의 한복판이에요.

LLM으로 AGI가 되나 — 다음 토큰 기계의 천장

질문을 LLM스럽게 다시 깎으면 이거예요.

“다음 토큰을 맞힌다”는 단 하나의 훈련 목표가, 인간급 범용 지능의 충분조건인가? 아니면 근본 천장이 있나?

학계가 둘로 쫙 갈려요. 둘 다 같은 LLM 메커니즘을 보면서 정반대 결론을 내는 게 포인트예요.

낙관 — “키우면 된다”

주장은 이래요. LLM을 더 키우면(파라미터·데이터·연산), 안 가르친 능력이 어느 규모를 넘는 순간 갑자기 솟는다. 이걸 창발(emergence)이라 불러요.

근거가 실제 역사예요.

GPT-2  →  GPT-3  →  GPT-4
작을 땐 못 하던 산수·번역·코딩·추론이,
키우자 "가르치지도 않았는데" 그냥 나타남

논리의 핵심이 멋져요 — “다음 토큰을 정말 잘 맞히려면, 결국 세계를 이해할 수밖에 없다.” 추리소설에서 “범인은 ___”의 다음을 맞히려면 줄거리의 논리 전체를 머릿속에 모델링해야 하잖아요. 그러니 압축을 극한까지 가져가면 = 이해, 충분히 키우면 AGI다.

비관 — “아무리 키워도 앵무새”

반대쪽은 이래요. LLM은 규모와 무관하게 통계적 앵무새(stochastic parrot). 말의 형식(form)을 배울 뿐 의미·세계 모델·인과가 없다.

근거가 바로 방금 깐 한계들이에요.

• 환각(①)이 안 사라져요. 본질이라서. 진짜 이해하면 없을 거짓을 매끄럽게 짜냄.
• 4837×219(④)도 틀려요. 절차를 밟는 게 아니라 흉내 내니까.

논리 — 다음 토큰 예측은 상관(correlation) 학습이지 인과·연역이 아니다. 데이터 분포 밖의 진짜 새로움엔 약하다. 인간 지능과 종류가 다른 거지, 양이 모자란 게 아니다. 그러니 키워봤자 천장.

중도 — “LLM은 부품, 단독으론 부족”

LLM은 언어·지식 엔진으로는 최고지만 단독은 모자라다. 그 둘레에 기억·도구·검색·계획을 붙인 에이전트 시스템이 AGI에 더 가깝다. 즉 LLM을 더 키우는 방향이 아니라 LLM을 둘러싸는 방향.

그리고 그 둘러싸기의 첫 단추가 RAG예요. 그래서 이 논쟁의 자연스러운 답안지가 잠시 뒤 RAG입니다.

창발이 진짜인가, 측정 착시인가

여기서 날카로운 반박이 있어요. “갑자기 솟았다”는 게, 사실은 매끄럽게 좋아지던 걸 ‘맞다/틀리다’ 같은 계단형 지표로 재서 생긴 착시일 수 있다는 거예요. 부분점수를 주는 지표로 바꿔 보면 창발이 안 보이기도 한다는 거죠.

그럼 “키우면 질적 도약”이라는 낙관의 근거가 흔들려요. — 아직 미해결입니다.

키우는 데도 한계가 있다

“그럼 무한정 키우면?”이라는 의문에는 세 가지 벽이 있어요.

• 데이터 고갈 — 인터넷의 양질 텍스트를 거의 다 먹었어요. 더 부을 게 없음.
• 연산 비용 — 키울수록 돈·전기가 기하급수.
• 수익 체감 — 2배 키워도 2배 똑똑해지진 않아요.

그래서 답은 — 아무도 “됐다/안 됐다”를 못 박아요. 이유가 LLM스러워요. AGI의 정의·합격선 자체가 합의 안 됨. 어떤 벤치마크를 통과하면 AGI인지조차 안 정해졌으니, 지금 모델이 “AGI에 몇 %”인지도 못 답해요.

확실한 건 하나 — 다음 토큰 예측 단독으론 ①④가 안 풀린다. 그래서 판이 “더 키우기”에서 “둘러싸기”로 옮겨가는 중이고, 그 둘러싸기의 1번 타자가 이제 볼 RAG입니다.

RAG — 답하기 직전에 진짜 문서를 펴놓기

이름부터 정면으로 뜯어요. RAG = Retrieval-Augmented Generation = 검색-증강 생성. 세 글자를 거꾸로 읽으면 정의가 그냥 나와요.

Generation (생성)   — 답을 만든다           ← LLM이 원래 하던 일
Augmented  (증강)   — 보강해서
Retrieval  (검색)   — 찾아온 자료로

한 줄 핵심은 더 단순해요. “가중치 속 흐릿한 기억으로 답하지 말고, 답하기 직전에 진짜 문서를 눈앞에 펴놓고 답해.” 닫힌 책 시험 보던 애한테 열린 책 시험으로 바꿔준 거예요.

말로만 하면 안 와닿으니 실물로. “우리 회사 연차 며칠이야?”를 물어본다고 해요.

RAG 없이 (LLM 단독):

[프롬프트]
우리 회사 연차 휴가 며칠이야?

[LLM 속마음] 사내 규정? 내 가중치엔 없는데…
[답] "보통 15일 정도입니다."   ← 일반론 또는 환각. 우리 회사 아님

RAG 붙이면 (2단계):

[1단계: 검색] 질문으로 사내 문서를 뒤져 관련 문단을 찾아옴
   인사규정.pdf →  "제12조(연차) 입사 1년 이상 직원에게 연 18일을 부여한다…"

[2단계: 그 문단을 프롬프트에 끼워넣어서 LLM에 줌]
[프롬프트]
아래 문서를 근거로만 답해.
─── 문서 ───
제12조(연차) 입사 1년 이상 직원에게 연 18일을 부여한다…
───────────
질문: 우리 회사 연차 며칠이야?

[답] "18일입니다. (인사규정 제12조)"   ← 정답 + 출처

가장 중요한 깨달음 — RAG는 LLM을 안 건드린다

위 두 경우, 모델(가중치)은 1도 안 바뀌었어요. 재학습? 안 했어요. 바뀐 건 오직 입력(프롬프트)뿐이에요. 자료 한 덩이를 프롬프트에 끼워넣은 게 전부.

왜 그것만으로 답이 또렷해지냐 — 5·6편의 Attention이 여기서 일해요. LLM의 두 가지 “기억”을 구분해야 해요.

가중치 속 기억   →  학습 때 뭉개 넣은 것. 흐릿하고, 출처 없고, 고정(컷오프)
프롬프트 속 기억  →  지금 입력에 깔린 토큰. Attention으로 또렷이 직접 봄

RAG가 하는 일은 딱 하나 — 흐릿한 쪽(가중치)에 맡기던 걸, 또렷한 쪽(프롬프트)으로 옮기는 것. 문서를 프롬프트에 넣는 순간 그 글자들은 LLM이 Attention으로 또렷이 “보는” 토큰이 되거든요.

이게 ①환각을 메우는 이유예요. 빈 곳에 진짜 문서 텍스트를 미리 깔아주면 LLM은 지어낼 필요가 없어져요. 다음 토큰 예측이 “눈앞 문서를 베끼는 쪽”으로 흐르거든요. 덤으로 출처(“제12조”)까지 댈 수 있어 추적도 됩니다. 정직하게 못 박을 것 — 환각을 원천 차단하는 게 아니라 지어낼 유인을 확 줄이는 거예요.

그리고 ②컷오프를 메우는 이유. 검색 대상은 지금 이 순간의 바깥 문서 — 어제 뉴스, 오늘 만든 사내 파일, 방금 갱신된 DB. 그걸 프롬프트에 넣으면 재학습 없이 최신·비공개 지식으로 답해요. 핵심 통찰 한 방 — 지식을 “모델 안”이 아니라 “모델 밖”에 둔다. 지식이 바뀌면? 문서만 갈아끼우면 끝. 모델은 그대로.

“그냥 내가 복사해서 붙여넣는 거랑 뭐가 달라?”

여기서 바로 이 의문이 와요. 그리고 답이 통쾌해요 — 정확히 똑같아요. 본질이 그거예요. RAG에 무슨 신비한 마법이 없습니다. “자료를 프롬프트에 붙여넣기”가 전부예요.

차이는 딱 하나, 자동화. 문서가 수천 개라 어느 문단을 붙일지 손으로 못 고를 때, “질문에 맞는 문단을 알아서 찾아다” 붙여주는 게 RAG의 R(Retrieval)이에요. 그러니 진짜 어려운 건 “붙여넣기”가 아니라 “수천 페이지 중 딱 맞는 문단을 어떻게 찾냐”고, 그게 다음 절의 벡터·내적입니다.

“딱 맞는 문단”을 찾는 법 — 벡터와 내적

질문 “우리 회사 연차 며칠이야?”가 들어왔어요. 사내 문서가 3,000페이지. 이 중 딱 맞는 문단을 사람 없이 찾아야 해요. 어떻게?

제일 먼저 떠오르는 건 키워드 검색(Ctrl+F). “연차”라는 글자가 든 문단을 찾는 거죠. 근데 여기서 바로 깨져요.

질문:   "휴가 며칠 쓸 수 있어?"
문서:   "제12조 연차 18일 부여"

글자가 하나도 안 겹쳐요. “휴가”≠”연차”, “쓸 수 있어”≠”부여”. 사람 눈엔 같은 얘긴데, 키워드 검색은 글자만 보니까 놓쳐요.

그래서 글자 말고 의미로 찾아야 해요. 방법은 5·6편에서 이미 봤어요 — 문장을 벡터(숫자 좌표 묶음)로 바꾼다. 이걸 문장 단위로 하는 걸 임베딩(embedding)이라 불러요.

"연차 18일 부여"      →  [0.8, 0.2, 0.1, …]   (좌표 하나)
"휴가 며칠 쓸 수 있어"  →  [0.9, 0.1, 0.2, …]   (좌표 하나)

핵심 성질 — 의미가 비슷하면 좌표가 가깝다. 그래서 위 둘은 글자는 딴판인데 좌표는 옆에 붙어 있어요.

두 좌표가 얼마나 가까운지(같은 방향을 보는지)를 재는 게 내적(dot product)이에요. 5편 Attention에서 Q·K로 “이 토큰이 저 토큰과 관련 있나” 재던 그 연산 그대로입니다. 내적이 크면 비슷, 작으면 딴판.

숫자로 관통

좌표를 3칸으로 줄여서 직접 계산해 봐요. (실제론 768칸쯤 되지만 원리는 똑같아요.)

질문 q = "연차 며칠?"        →  [0.9, 0.1, 0.2]

문단 A "연차 18일 부여"      →  [0.8, 0.2, 0.1]
문단 B "주차장 이용 규정"     →  [0.1, 0.9, 0.1]
문단 C "휴가 신청은 3일 전"   →  [0.7, 0.1, 0.5]

질문 q 와 각 문단의 내적(칸끼리 곱해서 더하기):

q·A = 0.9·0.8 + 0.1·0.2 + 0.2·0.1 = 0.72+0.02+0.02 = 0.76   ← 높음
q·B = 0.9·0.1 + 0.1·0.9 + 0.2·0.1 = 0.09+0.09+0.02 = 0.20   ← 낮음
q·C = 0.9·0.7 + 0.1·0.1 + 0.2·0.5 = 0.63+0.01+0.10 = 0.74   ← 높음

값 큰 순으로 줄 세우면 A(0.76) > C(0.74) >> B(0.20). 상위 2개(A, C)를 가져오고 주차장(B)은 버려요. 이걸 top-k 검색이라 해요(여기선 k=2).

여기가 재밌는 포인트 — C는 “연차”라는 글자가 없는데도 잡혔어요. “휴가”라서 의미가 가까웠거든요. 키워드 검색(Ctrl+F)이었으면 C를 놓쳤을 텐데, 임베딩+내적은 글자가 아니라 의미로 찾으니까 잡아냈어요.

연산을 5·6편과 한 줄로 이으면 이래요.

Attention(5·6편):  토큰 Q · 토큰 K 내적  →  "어느 토큰이 관련?"
RAG 검색(여기):    질문 q · 문단 벡터 내적 →  "어느 문단이 관련?"

토큰끼리 하던 내적을, 문장/문단 단위로 키워서 한 것뿐. 5·6편에서 익힌 “내적 = 관련도 측정”이 RAG 검색의 심장에서 또 뛰고 있는 거예요.

(곁다리: 실무에선 내적을 두 벡터 길이로 나눈 코사인 유사도를 자주 써요. “방향만 보고 길이는 무시”하려고요. 본질은 같아요 — 방향이 같으면 큰 값.)

좌표는 누가 만드나 — 임베딩 모델

그 임베딩 좌표는 누가 만들까요. LLM이? 아니에요. 임베딩 전용 모델이 따로 있어요. 그리고 이게 6편의 Encoder/Decoder와 정통으로 맞물려요.

6편에서 못 박은 두 구조 기억나시죠.

Encoder      = 양방향. 모든 토큰이 앞뒤 전부를 봄 (마스크 없음)
Decoder-only = 단방향. 각 토큰이 앞만 봄 (뒤는 가림 = masked)  ← GPT

임베딩이 하는 일은 “문장 전체의 의미를 좌표 하나로 요약”하는 거예요. 요약하려면 문장 전체를 한 번에 봐야 자연스럽잖아요. 그래서 앞뒤 다 보는 encoder(양방향)가 딱이에요. BERT가 encoder-only였고(6편 곁가지), 그 BERT를 문장 임베딩용으로 손본 Sentence-BERT가 임베딩 모델의 고전이에요.

정직하게 — “encoder-only만”이라고 못 박으면 거짓이에요. 최근엔 큰 decoder LLM을 임베딩용으로 추가 훈련해서 쓰는 것도 성능 1등을 다퉈요. 어느 쪽이든 핵심은 “생성 LLM과는 따로 훈련된 전용 모델”이라는 거예요.

“좌표를 만든다”의 실제 동작 — 풀링

여기 놓치면 안 되는 디테일이 있어요. 6편에서 봤듯 Transformer는 토큰 하나당 벡터 하나를 뱉어요. 문장에 토큰이 20개면 출력 벡터도 20개. 그런데 임베딩은 문장당 좌표 1개가 필요하죠. 20개를 1개로 어떻게 줄이냐 — 이걸 풀링(pooling)이라 해요.

토큰 20개 → encoder → 토큰 벡터 20개 → [풀링] → 문장 벡터 1개

풀링 방식 두 가지가 정석이에요.

• [CLS] 방식 — 문장 맨 앞에 특수 토큰을 붙이고, 그 토큰의 출력 벡터 하나를 “문장 대표”로 씀.
• 평균 풀링 — 토큰 벡터를 그냥 다 평균. (Sentence-BERT에선 이게 더 잘 됨.)

그러니 “누가 좌표를 만드나”의 끝까지 정직한 답은 — encoder가 토큰별 벡터를 만들고, 풀링이 그걸 문장 좌표 하나로 압축한다.

왜 생성 LLM을 그냥 안 쓰고 따로 훈련하냐면 — 임베딩 모델은 대조 학습(contrastive learning)을 받아요. “의미 비슷한 문장 쌍은 좌표를 당겨 붙이고, 다른 쌍은 밀어낸다”를 수백만 쌍으로 시켜요. 그래서 “비슷하면 내적 큼”이 성립하는 거예요. 그 “비슷한 쌍”은 사람이 일일이 라벨하지 않아요 — 같은 문단에 가까이 나온 문장, 번역쌍(같은 뜻) 같은 데서 자동으로 뽑아요(self-supervised).

중요한 못 박기: 문서를 변환한 모델과 질문을 변환한 모델이 같은 임베딩 모델이어야 해요. 좌표계가 같아야 내적 비교가 말이 되거든요. 다른 자로 잰 거리는 못 비교하죠.

768칸은 각각 무슨 뜻인가 — 아무도 라벨을 안 붙였다

여기서 의문 하나. “좌표가 768칸이면, 그 칸 하나하나가 ‘동물성’, ‘시제’ 같은 뜻인가? 누가 정했지?”

아무도 안 정했어요. 각 칸은 “동물성 0.8” 같은 깔끔한 라벨이 아니에요. 학습으로 저절로 생긴 추상 축이고, 사람이 이름 붙이지 않았어요.

핵심 — 의미는 개별 칸이 아니라 768칸 전체의 방향 패턴에 분산돼 있어요(분산 표현). 한 칸만 떼서 보면 아무것도 안 보이고, 768칸이 함께 가리키는 방향이 의미예요.

그래서 임베딩도, LLM도 “왜 이 답이 나왔나”를 칸 단위로 설명 못 해요 — 환각에서 본 그 블랙박스와 같은 뿌리죠.

벡터가 길면 중요한 단어인가 — 길이와 방향

여기서 근본 질문 하나가 와요. “벡터가 원점에서 멀면(길면) 중요한 단어고, 짧으면 조사·관사처럼 영향이 적은 건가?” 직관이 상당히 맞아요.

방향(direction)  →  "무엇을 뜻하나"   (의미의 종류). 비슷한 뜻 = 비슷한 방향
길이(norm)       →  "얼마나 또렷·중요한가" (의미의 세기)

기능어(은/는/이/가, the)는 아무 맥락에나 다 붙어서 방향이 뭉개지고 길이가 짧아지는 경향, 내용어(고유명사·전문어)는 특정 맥락에 몰려 길이가 길어지는 경향이 실제로 관찰돼요. 짧은 벡터도 0만 아니면 방향은 또렷이 있고요 — 세기만 약할 뿐.

그런데 반전 — 정작 RAG 검색은 코사인 유사도로 길이를 일부러 정규화(무시)하고 방향만 봐요. 긴 문단이 길다는 이유만으로 검색 1등을 먹으면 곤란하니까요. 길이의 의미는 모델 내부 계산에선 살아 있지만, 검색 비교에선 목적상 일부러 죽이는 거예요.

(자주 헷갈리는 한 가지: “encoder는 여러 벡터를 하나로 합치는 모델”이라고 알기 쉬운데, 정확히는 encoder도 토큰당 벡터 하나(N→N)예요. N→1로 합치는 건 encoder가 아니라 풀링의 일이고요. “encoder가 문장 하나로 압축”은 Transformer 이전 RNN 시대의 그림인데, 그 압축 병목을 풀려고 나온 게 바로 Attention이었어요.)

표·이미지·스캔 PDF는 — 멀티모달 임베딩

“그럼 텍스트만 되는 거야? 표나 이미지, 스캔된 PDF는?” 텍스트만 되는 거 아니에요. 두 길이 있어요.

• 텍스트화 — 표는 마크다운으로, 스캔 PDF는 OCR로 글자를 뽑고, 이미지는 LLM이 설명한 캡션으로 바꿔서 임베딩해요.
• 멀티모달 임베딩 — 이미지와 텍스트를 같은 좌표공간에 임베딩하는 모델(CLIP류)을 써요. “강아지 사진”과 “강아지”라는 단어가 가까운 좌표로 가서, 글 질문으로 이미지를 검색할 수 있어요.

6편의 이미지 패치 기억나시죠 — 이미지를 조각으로 쪼개 벡터로 바꾼 그것과 같은 결이에요. 그래서 멀티모달 RAG가 가능한 거고요.

RAG 전체 흐름 — 청킹과 벡터DB

이제 부품을 한 줄로 이어요. RAG는 두 단계예요. 시점이 완전히 달라요.

[Phase 1: 미리 — 질문 받기 전에 딱 한 번 (색인)]
  문서들 → ✂️청킹 → 조각 수천 개 → 임베딩 모델 → 좌표 수천 개 → 벡터DB 저장

[Phase 2: 질문 올 때 — 매번 실시간]
  질문 → 임베딩 모델(★Phase1과 같은 것) → 질문 좌표
       → 벡터DB에서 top-k 내적 검색 → 관련 조각 3~5개
       → 프롬프트에 끼움 → LLM → 답(+출처)

Phase 1은 미리 해두는 “도서관 정리”, Phase 2는 질문 올 때마다 하는 “책 찾아 펴기”예요. 여기 새 부품 둘이 있어요.

✂️ 청킹 — 문서를 왜, 어떻게 쪼개나

왜 쪼개나? 이유가 둘이고 둘 다 앞에서 깐 거예요.

1. ③컨텍스트 한계 — 30페이지 문서를 통째로 프롬프트에 못 넣어요. 조각만 넣어야.
2. 임베딩 품질 — 긴 글을 좌표 하나로 임베딩하면 여러 주제가 평균돼 방향이 뭉개져요. 한 조각에 한 주제여야 좌표가 또렷이 서요.

어떻게 쪼개냐 — 고정 크기로 뚝뚝 자르거나, 문단/문장 경계로 자르거나, 조각끼리 일부 겹치게(오버랩) 잘라 경계 정보 손실을 막아요. 트레이드오프가 핵심이에요.

• 너무 크게 쪼개면 → 한 조각에 여러 주제가 섞여 흐려지고, 엉뚱한 내용까지 딸려와요.
• 너무 작게 쪼개면 → 문맥이 끊겨요. 조각이 “그것은 18일이다”만 있으면 “그것”이 뭔지 몰라 쓸모없어져요.

그래서 감각은 “한 조각 = 한 생각”. 이 크기 잡기가 RAG 품질을 좌우하는 첫 손잡이예요.

🗄️ 벡터DB — 가까운 좌표를 빠르게 찾기

수만 조각이랑 매 질문마다 다 내적하면 느리겠죠. 게다가 일반 DB(SQL)는 “정확히 일치”는 빨리 찾지만 “가장 가까운 벡터”는 못 찾아요. 그래서 전용 DB가 필요해요.

벡터DB = 좌표를 저장하고 “가장 가까운 k개”를 빠르게 돌려주는 특수 DB. 핵심 기술이 ANN(근사 최근접 탐색)이에요.

완전탐색: 5만 조각 전부와 내적 → 정확하지만 느림
ANN     : 영리하게 후보만 좁혀 검색 → "거의 정확"하고 수백~수천 배 빠름

“근사(approximate)”의 정직한 뜻 — 100% 1등을 보장 안 해요. 아주 가끔 진짜 1등을 놓칠 수 있어요. 근데 속도가 1000배라 그 트레이드오프를 받아들이는 거예요.

여기서 두 의문이 자연스럽게 와요.

• “top-k의 k는 몇 개가 좋아?” 보통 3~10개. 너무 적으면 정답 조각을 놓치고, 너무 많으면 ③컨텍스트가 넘치고 노이즈가 늘어 LLM이 오히려 헷갈려요.
• “새 문서가 추가되면 또 다 다시 해?” 아니요. 그 문서만 청킹·임베딩해서 벡터DB에 추가(증분)하면 끝. 모델은 안 건드려요. “지식 갱신 = 벡터DB 업데이트”, 재학습이 아니에요. 이게 ②컷오프 극복의 실무적 핵심.

RAG가 못 메우는 것 — 검색이 천장

이제 RAG를 띄우기만 하면 안 되니, 정직하게 천장을 봅니다. 한 줄로 못 박으면 — RAG의 답은 검색을 절대 못 넘어요. LLM은 가져온 조각을 사실 검사 안 하고 믿고 답하거든요. garbage in, garbage out.

recall 실패  : 정답 조각을 아예 못 가져옴 → 근거 없어 또 환각하거나 "모름"
precision 실패: 엉뚱한 조각을 가져옴     → 틀린 근거로 그럴듯하게 답 ★더 위험

precision 실패가 진짜 무서워요. 틀린 조각을 가져왔는데 LLM이 거기에 출처까지 딱 달아서 단호하게 답하거든요. 사용자는 “출처도 있네” 하고 더 믿어요. 환각보다 더 속기 쉬운 거짓이 돼요.

그리고 RAG가 환각을 0으로 만드는 것도 아니에요. LLM이 가져온 조각을 무시하고 제 가중치 기억으로 답하기도 하고, 조각 여러 개를 잘못 종합하기도 하고, “제12조에 따르면…” 해놓고 정작 제12조엔 그 말이 없는 출처 환각도 나요.

반직관적인 것 하나 — 검색 조각을 프롬프트에 많이 넣으면 좋을 것 같죠? 아니에요. 긴 컨텍스트에서 LLM은 앞·뒤는 잘 보는데 가운데는 잘 놓쳐요. 실측된 현상이라 이름도 있어요 — lost in the middle. 그래서 top-k를 무작정 늘리면 정답 조각이 가운데 묻혀서 오히려 답이 나빠져요.

한 가지 더, 자주 나오는 의문. “요즘 컨텍스트가 100만 토큰인데, 그냥 문서를 다 넣으면 RAG가 필요 없잖아?” 아니에요, 세 가지 때문에.

• 비용 — 100만 토큰을 매 질문마다 넣으면 토큰 과금이 폭발해요. RAG는 관련 3~5조각만.
• lost in the middle — 방금 본 그것. 다 넣어도 가운데를 놓쳐요.
• 규모 — 회사 전체 문서가 1억 토큰이면 100만 컨텍스트에도 안 들어가요. 벡터DB는 무제한 저장.

그래서 긴 컨텍스트는 RAG를 도와줄 뿐(한 번에 더 많은 조각을 넣게) 없애진 못해요. “넣을 수 있다”와 “넣는 게 효율적이다”는 다른 얘기예요.

그 외에도 청크 크기·k·임베딩 모델이 다 손잡이라 “켜면 잘 됨”이 아니고(튜닝 지옥), 매 질문마다 임베딩+검색+긴 프롬프트라 단독 LLM보다 무겁고, 벡터DB에 기밀이 섞이면 권한 없는 사람 질문에 기밀 조각이 검색돼 샐 수도 있어요(권한 필터 필요).

핵심 귀결 — RAG는 “지식” 한계는 메우지만 “추론” 한계(④)는 못 메워요. 그래서 RAG는 AGI의 답이 아니라 둘러싸기의 첫 단추고, 그다음이 도구·파인튜닝으로 이어져요. 천장이 다시 ④로 돌아가 회로가 닫히죠. 그 “검색으로 원래 못 푸는 질문”부터 봅니다.

검색으로 원래 못 푸는 질문 — 그리고 세 가지 도구

RAG 검색은 “질문과 의미 가까운 조각 top-k 찾기”예요. 그래서 답이 소수의 조각에 국소적으로 들어 있고, 한 번 찾으면 끝인 질문(사실 조회)만 잘해요. 답이 그렇게 안 생긴 질문 세 종류가 구조적으로 깨지고, 각각 맞는 도구가 따로 있어요.

① 집계·종합 → Text-to-SQL

“전 직원 평균 연차는?” “1억 넘는 계약 몇 건?” 이런 질문은 답이 어느 한 조각에도 없어요. 각 직원 연차는 흩어져 있지만 “평균”이라는 문장은 문서에 없죠. top-k를 가져와봤자 몇 명치만 와요. 의미 유사도로 닿을 수 없는 답이에요.

맞는 도구는 Text-to-SQL — LLM이 질문을 SQL로 번역해 DB에 던지는 거예요.

핵심 — LLM은 “번역”만 하고 합계·평균·개수 계산은 DB가 해요. ④추론 약점을 DB에 위임하는 거죠. 정직한 한계 — 스키마가 복잡하면 틀린 질의문을 짜고, 데이터를 지우는 위험한 명령을 생성할 수도 있어서 반드시 읽기 전용 권한을 줘요.

② multi-hop → 반복검색

“A의 상사가 속한 부서의 예산은?” 같은 질문. A → 상사(B) → B의 부서(영업부) → 영업부 예산, 이렇게 여러 단계를 타고 가야 해요.

한 번 검색으로는 “A 상사 부서 예산”과 가까운 단일 조각을 찾는데, 그런 건 없어요. 정보가 여러 문서에 흩어져 있고, 앞 단계 답을 알아야 다음을 검색할 수 있거든요.

검색1: "A의 상사" → B
검색2: "B가 속한 부서" → 영업부   ← 검색1 답(B)을 넣어 질문을 만듦
검색3: "영업부 예산" → 5억

단순 반복이 아니에요. 각 단계 사이에 LLM이 “다음에 뭘 검색할지” 추론해서 다음 질문을 만들어요. 이게 곧 다음 절의 agentic RAG로 넘어가요.

③ 부재·없음 확인 → 전수스캔

“이 계약서에 경업금지 조항 있어?”(없는 경우). “없다”를 증명하려면 전체를 다 봐야 하는데 top-k는 일부 표본만 봐요. “경업금지”와 가까운 조각을 못 찾았다고 “없다”고 단정하면 안 돼요 — 검색이 놓쳤을 수도 있으니까.

그래서 RAG는 있음(존재)은 잘 증명하는데 없음(부재)은 구조적으로 약해요. 확실히 하려면 모든 조각을 하나씩 훑어야 하고(전수스캔/map-reduce), 그건 조각 수만큼 LLM 호출이라 비싸요. 그래서 꼭 필요할 때만 써요.

한 줄 통찰 — RAG는 ‘찾기’지 ‘계산·연쇄·전수’가 아니다. 답이 국소적으로 한 곳에 있나, 흩어져 있나가 갈림길이에요.

Agentic RAG — LLM에게 도구를 쥐여주면

가장 큰 차이부터.

일반 RAG    : 고정 파이프라인. 검색 1번 → 답 1번. 직선. 코드가 흐름을 정함.
Agentic RAG : LLM이 루프 안에서 스스로 판단하며 도구를 골라 여러 번 씀. 분기·반복.

agentic의 한 사이클은 이래요.

질문 → [LLM 생각: 뭐가 필요? 어떤 도구?] → 도구 실행(검색/SQL/전수)
     → [관찰: 결과 봄] → [LLM: 충분? 다음 행동?] → (반복) → 충분하면 답

즉 위 세 도구를 LLM이 상황 봐서 고르고 조합하는 거예요. 집계면 SQL, multi-hop이면 검색 여러 번, 부재면 전수.

여기서 의문 — “LLM이 도구를 어떻게 ‘고르는’ 거야? 마법이야?”

마법 아니에요. 도구마다 이름 + 설명(언제 쓰는지) + 입력 형식을 프롬프트에 적어줘요. LLM은 그걸 보고 “SQL도구를 입력 질의문…으로 쓰겠다” 를 텍스트로 출력할 뿐이에요. 그 텍스트를 바깥 코드가 파싱해서 실제로 실행하고, 결과를 다시 프롬프트에 넣어줘요. LLM은 “무슨 도구를 무슨 입력으로”를 말만 하고, 실행은 코드가 하는 거죠. 이게 function calling(tool use)의 핵심이에요.

그래서 더 복잡해진다 — 정직하게 네 가지

1. 제어 흐름이 LLM 손에 — 일반 RAG는 코드가 흐름을 고정하는데, agentic은 LLM이 매 단계 결정 → 비결정적(같은 질문에 다른 경로). 디버깅·재현이 어려워요.
2. 실패 누적 — 단계가 5개고 각 단계가 90% 정확해도 0.9⁵ ≈ 59%. 길수록 한 번 삐끗하면 와르르.
3. 폭주·무한루프 — “충분”을 판단 못 하고 계속 검색하거나 엉뚱한 도구를 반복. 최대 단계 수·비용 상한을 안전장치로 박아야 해요.
4. 비용·지연 폭발 — 단계마다 LLM 호출 + 도구 호출. 일반 RAG가 1~2회면 agentic은 5~20회.

그리고 여기서 한 번 더 의심이 와요 — “LLM이 ‘충분한지’ 판단한다면서, 판단도 LLM이면 자기가 자기 채점이잖아?” 정확한 지적이고, 완벽한 해결은 없어요. 외부 도구로 사실을 확인하거나, 별도 critic 모델이 채점하거나, 단계 수를 제한하거나, 사람이 개입하는 식으로 완화만 합니다.

정직한 결론 — agentic은 강력하지만 “켜면 좋아짐”이 아니라 “더 무겁고 더 깨지기 쉬움”. 단순 사실 질문엔 일반 RAG가 낫고, 진짜 multi-hop·복합 작업에만 써요.

지식이 아니라 행동을 바꾸려면 — 파인튜닝

지금까지는 다 “지식을 어떻게 넣나”였어요. 그런데 LLM에게 말투·형식·기술 같은 행동을 입히고 싶을 땐 다른 길이 있어요. 파인튜닝이에요.

먼저 자리잡기. LLM은 두 단계로 만들어져요(1~2편 연결).

사전학습(pretraining): 인터넷 전체로 "다음 토큰 예측" 처음부터 → base model. 천문학적 비용.
파인튜닝(fine-tuning): 이미 다 아는 모델에 소량 데이터로 가중치를 살짝 더 조정.

핵심 — 파인튜닝도 결국 같은 “다음 토큰 예측 + 역전파로 가중치 갱신”이에요. 다만 데이터가 작고(수백~수만 쌍), 학습률이 낮아서 가중치가 원하는 스타일 쪽으로 조금 이동하는 거예요.

데이터 형식은 입력→원하는 출력 쌍이에요. 그리고 그 데이터가 미는 방향이에요 — “이 입력엔 이 출력”이라는 예시가 곧 “이쪽으로 밀어라”. 그래서 쓰레기 데이터는 쓰레기 방향이 돼요.

전부 다 바꾸기 vs 작은 메모만 — full과 LoRA

방법이 둘로 갈려요.

Full fine-tuning은 모델의 모든 가중치를 새로 학습해요. GPT-3급(1750억 개)이면 그 전부를 메모리에 올려야 하니 GPU 수십~수백 장, 천문학적이에요. 작은 모델 아니면 실무에선 거의 안 해요.

그래서 사실상 표준이 LoRA예요. 사람 시점으로 먼저 — 거대한 원본은 통째로 얼려두고, 옆에 작은 “수정 메모” 행렬만 새로 학습해서 얹는다.

원본 W (거대, 얼림)  +  작은 메모 ΔW (학습)  =  W + ΔW

왜 되냐면, 파인튜닝으로 생기는 변화량이 알고 보니 저차원이라 작은 행렬로 근사돼요. 전체를 다 바꿀 필요가 없더라는 거죠. 그 결과 학습할 파라미터가 원본의 0.1~1%로 줄어 GPU 한 장으로도 큰 모델을 다룰 수 있고, 어댑터가 작아서 작업마다 갈아끼울 수 있어요. (원본을 4비트로 압축해 메모리를 더 줄이는 QLoRA도 있어요.)

한계

• 지식 주입엔 약함 — 새 사실을 안정적으로 못 박고 오히려 환각을 늘릴 수 있어요. 그래서 사실은 RAG.
• 재앙적 망각 — 좁은 데이터로 빡세게 가르치면 원래 잘하던 걸 까먹어요. LoRA가 원본을 얼려서 이걸 완화하죠.
• 과적합 — 데이터가 적은데 과하게 학습하면 그 예시만 외워 새 입력에 약해요.
• 데이터 준비가 진짜 일 — 깨끗한 쌍 수천 개 만드는 사람 시간이 비용의 대부분이에요. 학습 자체보다 데이터가 어려워요.

클라우드 LLM은 파인튜닝이 되나

핵심 구분이 여기 있어요.

폐쇄형 (GPT·Claude·Gemini): 제공사가 "열어둔 모델·방식" 안에서만. 가중치는 못 봄.
                            데이터를 그쪽에 업로드. 모든 모델이 되는 건 아님.
오픈 모델 (Llama·Mistral·Qwen): 가중치 공개 → 내가 직접 LoRA/full 마음대로. 완전 통제.

답은 — 부분적으로 가능. 제공사가 열어둔 범위 내에서만. 자유로운 파인튜닝은 오픈 모델로 해요. 폐쇄형은 데이터를 업로드해야 하니 민감 정보면 부담이고, 그땐 오픈 모델을 로컬에서 파인튜닝하면 데이터가 안 나가요.

비용은 — 폐쇄형 API는 데이터 토큰 양에 비례해 작으면 수~수십 달러, 오픈 LoRA는 GPU 시간당 수~수십 달러, full은 수천 달러+. 진짜 큰 비용은 보통 데이터 준비예요.

RAG와 파인튜닝, 그리고 프롬프트 — 셋의 자리

이제 세 가지가 정리돼요. 바꾸는 게 달라요.

RAG     = 지식을 밖에 두고 찾아 넣음 → "무엇을 아는가"
파인튜닝 = 가중치를 추가학습으로 바꿈 → "어떻게 답하는가"
프롬프트 = 입력에 지시·예시를 얹음   → 가장 가벼운 임시 조종

고르는 법은 무게 순이에요. 예시 몇 개면 프롬프트, 큰 지식이면 RAG, 행동을 깊이 박으려면 파인튜닝. 새 지식은 RAG, 새 행동은 파인튜닝 — 보통 둘을 같이 써요.

“그건 시스템 프롬프트 아니었나?” — 행동을 정하는 3층

여기서 아주 중요한 의문이 와요. “대화의 형식을 정하는 건 파인튜닝이 아니라 시스템 프롬프트 아냐?” 반은 맞아요. 그 반과 나머지 반을 가르는 게 핵심이에요.

행동을 정하는 게 사실 3층으로 쌓여 있어요.

1층 사전학습(base)      : 다음 토큰만 잇는 날것. 대화 못 함.
2층 파인튜닝(instruct)   : 가중치를 바꿔 "지시 따르고 대화하는 본성"을 박음. ★영구·항상
3층 시스템 프롬프트       : 가중치 그대로, 입력 맨 앞에 지시를 얹어 "이번 판의 역할·톤". ★일시·교체

차이를 못 박으면 — 파인튜닝은 기질/본성(가중치에 박힘), 시스템 프롬프트는 그 위의 배역 지정(입력에 얹음)이에요.

결정적 한 방. base model한테 “프랑스 수도는?”이라고 넣으면 “파리”라고 답을 안 하고 “이탈리아 수도는? 독일 수도는?” 하고 질문을 계속 이어버려요(다음 토큰 잇기만 하니까). 여기다 “너는 상담원이야”라는 시스템 프롬프트를 줘도 무시해요. 애초에 “지시를 따라야 한다”는 성향이 없으니까.

그 성향을 가중치에 새긴 게 파인튜닝이에요. 그러니까 — 시스템 프롬프트가 먹히는 것 자체가 파인튜닝 덕분이에요. 파인튜닝이 토대, 시스템 프롬프트는 그 위에서 노는 것.

그리고 이거, RAG랑 똑같은 구조예요.

가중치에 박기 = 파인튜닝         (영구·느림·비쌈)
입력에 얹기   = 시스템 프롬프트·RAG (일시·즉시·쌈)

RAG가 지식을 입력에 얹는 거였듯, 시스템 프롬프트는 행동 지시를 입력에 얹는 거예요. 둘은 “가중치 안 건드리고 입력으로 조종”하는 한 가족이고, 파인튜닝만 가중치를 바꾸는 쪽이에요.

그래서 ChatGPT의 대화 형식은 사실 둘 다예요 — “대화를 한다는 본성”은 파인튜닝, “오늘 날짜·현재 규칙” 같은 세부는 매 요청에 숨겨 넣는 시스템 프롬프트. 그러니 “그건 시스템 프롬프트 아니냐”는 직관도 반은 맞았던 거예요.

RLHF — base의 거친 입을 길들인 법

그 “파인튜닝으로 본성을 박는다”의 대표 사건이 RLHF예요. base 모델은 거칠어서, “돈 벌고 싶은데 좋은 방법?”에 위험한 답을 천연덕스럽게 내놓기도 했어요.

이걸 길들인 방법의 핵심이 “두 출력 중 사람이 더 나은 걸 고르게” 하는 것이에요.

모델이 답 두 개 생성 → 인간이 더 나은 쪽 선택(선호 비교)
→ 그 선호를 학습한 "보상 모델"을 만듦
→ 보상이 높아지는 쪽으로 LLM을 강화학습으로 파인튜닝

이게 RLHF(인간 피드백 기반 강화학습)예요. 정확히 짚으면 — 이 정렬은 GPT-3 자체가 아니라 그 위에 RLHF를 입힌 InstructGPT(2022), 그걸 대화용으로 다듬은 ChatGPT에서 생겼어요. GPT-3 base도 거칠었거든요. 그리고 순위를 매긴 건 처음엔 고용된 인간 라벨러였어요(나중엔 좋아요/싫어요로 사용자 피드백도).

결과는 “윤리”만이 아니라 도움됨+정직+무해 전반의 정렬이에요. 그러니까 — base는 날것이라 위험·산만 → RLHF로 “말 잘 듣고 안전한” 모델로. 우리가 쓰는 ChatGPT는 이 파인튜닝 단계의 산물이에요.

조 단위 모델이 풀린 날 — Llama

마지막으로, 왜 스타트업까지 파인튜닝을 할 수 있게 됐는지. 여기엔 한 사건이 있어요. 줄기는 이래요 — 거대 모델의 가중치가 풀리면서 누구나 파인튜닝할 수 있게 됐다. 다만 순서를 정확히 박을게요.

LLaMA 1 (2023.2) : "실수로 오픈"이 아니라 → 연구자 한정 배포(신청·승인제)
유출 (2023.3)    : 약 1주 만에 가중치가 토렌트로 유출 → 통제 상실 (의도된 오픈 아님)
LLaMA 2 (2023.7) : Meta가 *의도적으로* 가중치 공개 + 상업 사용 허용 → 진짜 "공개 결단"

흔히 도는 “실수로 열었다가 닫았는데 어차피 퍼져서 그냥 공개” 이야기는 유출(Llama 1)과 전략적 공개(Llama 2)가 합쳐진 대중 서사예요. 유출이 오픈 전략을 가속·정당화한 면은 있지만, Llama 2는 유출본 재공개가 아니라 새 모델을 작정하고 연 거예요.

“조 단위 예산”은 살짝 과장이에요 — 한 모델 학습은 보통 수천만~수억 달러 규모예요(다만 Meta 전체 GPU 인프라 투자는 수십억 달러+).

하지만 “이때부터 시장이 크게 움직였다”는 정확해요. 그리고 이게 방금 배운 걸 그대로 증명해요 — 유출된 Llama 1을 스탠퍼드가 약 $600에 instruction 파인튜닝한 게 Alpaca, 이어 Vicuna 등이 폭발했어요. 오픈 가중치가 있어야 자유로운 파인튜닝이 가능하니까(폐쇄형 GPT는 못 하던 걸 오픈 Llama가 풀어버린 거죠). 오픈 가중치 사건 = 파인튜닝 생태계의 빅뱅이에요.

핵심 정리 — 이번 편을 한 손에

LLM의 한계   : ①환각 ②컷오프 ③컨텍스트 ④추론·계획 ⑤기억
AGI 되나?    : 다음 토큰 단독으론 천장. 판이 "키우기"→"둘러싸기"로
RAG         : 검색을 붙여 ①②③⑤(지식 쪽)를 메움. 벡터·내적(5·6편)이 심장
RAG의 한계   : 검색이 천장 + ④추론 구멍은 못 메움 → 도구·agentic으로
파인튜닝     : 가중치를 밀어 "행동"을 바꿈. 지식엔 약함(그건 RAG)
3층          : base → 파인튜닝(본성) → 시스템 프롬프트(배역)

세 줄로 더 줄이면.

1. LLM은 “넓고 깊은 우물 하나”(다음 토큰 예측)다. 그래서 환각·컷오프·추론 같은 한계가 본질에서 나온다.
2. RAG는 지식을 모델 밖에 두고 검색해 끼워넣어 ①②를 메운다. 검색이 천장이라 ④추론은 못 메운다.
3. 지식은 RAG, 행동은 파인튜닝, 임시 조종은 프롬프트. AGI는 이 둘러싸기들이 쌓이는 방향에 있다.

7편을 마치며

1~6편이 “LLM이 어떻게 답을 만드나”였다면, 7편은 “그 답을 어디까지 믿고, 어디서 의심하고, 뭘로 보강하나”였어요.

환각이 버그가 아니라 유창함의 그림자라는 것, “다음 토큰 기계”가 왜 AGI 앞에서 멈칫하는지, 그리고 그 한계를 모델을 안 건드리고 입력으로 메우는 RAG의 정체 — 마법이 아니라 “관련 문단을 자동으로 찾아 붙여넣기”였다는 것까지 왔어요.

이렇게 일곱 편으로 한 바퀴가 닫힙니다. 토큰 하나가 확률로 태어나는 자리에서 출발해, Attention과 Transformer로 엮이는 과정을 지나, 어디서 꺾이고 무엇으로 보강되는지까지 — LLM을 안에서 바깥까지 한 번에 관통했어요.

그 너머, “둘러싸기”가 본격적으로 자라는 자리 — 검색을 여러 번 부리고 도구를 골라 쓰는 에이전트 — 는 이 코스가 깔아둔 토대 위에서 비로소 말이 되는 이야기예요. 거기서부터는 이론이 아니라 설계의 영역이고요.

여기까지가 「LLM 이론 집중코스」 한 시즌입니다. 토큰 한 개에서 시작해 ChatGPT가 어떻게 생각하고 어디서 멈칫하는지까지 — 끝까지 함께해 줘서 고맙습니다.

---

이 글은 자주 묻는 질문(FAQ)을 따로 모아두지 않았습니다. 막히는 질문을 그 의문이 떠오르는 본문 자리에 흩어 두었어요 — “왜 굳이 지어내?”, “온도를 0으로 하면?”, “복붙이랑 뭐가 달라?”, “k는 몇 개?”, “그건 시스템 프롬프트 아냐?” 처럼.

이어 읽기
– [5편] Attention — ‘그 단어’가 누구를 가리키는지 아는 법
– [6편] Transformer — Attention을 쌓으면 어떻게 ChatGPT가 되나
– 3편 — 디코딩(softmax·temperature) 편: 이 글의 “온도를 0으로 하면” 의 근거

참고 개념
– RAG / 임베딩 / 벡터 검색 / 내적·코사인 유사도
– RLHF / InstructGPT / 파인튜닝 / LoRA
– LLaMA 오픈 가중치 · Alpaca