사전학습 생태계와 활용
사전학습: 우리가 9주차에 한 것의 규모 확장
원리는 이미 배웠다
Ch08에서 전이학습을 배웠다: 대규모 데이터로 사전학습된 모델을 가져와 내 작업에 맞게 파인튜닝한다. HW2에서 여러분이 직접 했다 — ImageNet으로 사전학습된 모델의 분류기를 교체하고, 직접 찍은 사진 수백 장으로 동결 학습을 했다.
LLM은 정확히 같은 원리이고, 규모만 다르다:
| HW2 (9주차, 이미지) | LLM (사전학습) | |
|---|---|---|
| 사전학습 데이터 | ImageNet 약 100만 장 | 인터넷 규모 텍스트 (수조 토큰) |
| 파라미터 수 | 수천만 개 (ResNet-50 약 2,500만) | 수천억 개 (GPT-3: 1,750억) |
| 사전학습 주체 | 남이 해줌 (공개 모델) | 남이 해줌 (수만 대의 GPU) |
| 내가 하는 일 | 분류기 교체 + 동결 + 파인튜닝 | 프롬프트 작성, (필요시) 파인튜닝 |
| 왜 되는가 | 저수준 특성은 공통 (Ch08) | 언어의 일반 패턴은 공통 (같은 원리) |
라벨이 필요 없는 이유: 자기지도
HW2에서 가장 손이 많이 간 일은 라벨링이었다. 그런데 다음 토큰 예측에는 라벨링이 필요 없다. 텍스트 자체가 문제지이자 정답지이기 때문이다 — “나는 어제 학교에 갔다”라는 문장 하나에서 “나는 어제 학교에 → ?”라는 문제와 “갔다”라는 정답이 공짜로 나온다. 데이터가 스스로 정답을 제공하는 이런 방식을 자기지도학습(self-supervised learning)이라 부른다. 라벨링 비용이 사라졌기 때문에 인터넷의 텍스트 전체를 학습 데이터로 쓸 수 있었고, 이것이 “L(Large)”을 가능하게 한 열쇠다.
1주차에 예고한 그림이 완성되었다
Ch01에서 딥러닝이 각광받는 이유 중 하나로 사전학습 생태계를 소개했다 — “방대한 데이터로 미리 학습된 모형을 가져와 재활용할 수 있는 생태계.” 그때는 예고였지만, 이제 그 그림의 전부를 여러분이 직접 확인했다: Ch08에서 이미지로(HW2), 그리고 오늘 언어에서. 하나의 사전학습 모델이 요약·번역·분류 등 여러 작업의 기반이 되는 이런 모델을 기초 모델(foundation model)이라고도 부른다. 1주차의 예고가 13주차에 회수된 셈이다.
규모가 만든 놀라움과 남은 문제
창발: 시키지 않은 일을 하기 시작했다
모델과 데이터를 계속 키우자 이상한 일이 일어났다. 다음 토큰 예측만 시켰을 뿐인데, 어느 규모를 넘어서자 번역, 요약, 간단한 추론 같은 능력이 “배운 적 없이” 나타난 것이다. 작은 모델에서는 전혀 안 되던 일이 규모를 키우면 갑자기 되기 시작하는 이 현상을 창발(emergence)이라 부른다. 왜 이런 일이 일어나는지에 대한 완전한 설명은 아직 없다 — 다만 인터넷 텍스트에는 번역문, 요약문, 풀이 과정이 포함되어 있으므로, “다음 토큰을 잘 맞히려면” 그런 패턴까지 내재화해야 했다는 것이 직관적인 설명이다. 이 수업에서는 창발을 개념 수준에서만 다룬다.
정렬: 다음 토큰 예측만으로는 조수가 되지 않는다
인터넷 텍스트를 잘 흉내 내는 모델이 곧 유용하고 안전한 조수인 것은 아니다. 인터넷에는 틀린 정보, 유해한 내용, 질문에 질문으로 답하는 글도 가득하기 때문이다. 그래서 사전학습이 끝난 모델에는 추가 조정이 들어간다. 먼저 “지시 → 좋은 응답” 형태의 고품질 예시들로 파인튜닝하는 지시 튜닝(instruction tuning)을 거치고, 이어서 모델이 내놓은 여러 응답에 사람이 선호 순위를 매기면 그 선호를 반영해 모델을 미세조정하는 RLHF(인간 피드백 기반 강화학습)를 적용한다. 원리는 여전히 Ch08의 파인튜닝 — 사전학습된 가중치를 출발점으로 삼아 원하는 방향으로 조금 움직이는 것 — 이고, 다른 점은 “정답 라벨” 대신 “사람의 선호”가 학습 신호가 된다는 것이다. 이 과정을 통틀어 정렬(alignment)이라 부른다. 수식과 알고리즘 상세는 이 수업의 범위 밖이다.
사전학습 모델을 쓰는 네 가지 방법
Ch12까지 배운 구조를 여러분이 직접 학습시킬 일은 없다 — GPU 수만 대가 필요하다. 현실에서 하는 일은 남이 학습시켜 둔 모델을 가져다 쓰는 것이고, 방법은 네 가지다.
Ch08의 전이학습 표를 다시 꺼내자. 구조가 정확히 같다.
| 방법 | 무엇을 학습하나 | 필요한 데이터 | 필요한 GPU | Ch08의 무엇과 같은가 |
|---|---|---|---|---|
| ① 프롬프팅 | 아무것도 | 0 (예시 몇 개) | 없음 (API) | — (새로 생긴 방법) |
| ② 특성 추출 | 작은 분류기만 | 수백 건 | 거의 없음 | Option 1: 동결 |
| ③ 부분 파인튜닝 | 뒤쪽 층 일부 | 수천 건 | 중간 | 뒤쪽 층만 해제 |
| ④ 전체 파인튜닝 | 전부 | 수만 건 이상 | 많음 | Option 2: 전체 미세조정 |
특성 추출(feature extraction) — 사전학습 모델을 동결한 채 문장을 넣어 내부 표현(임베딩)을 꺼내고, 그 위에 작은 분류기만 학습한다.
\[\text{문장} \;\to\; \underbrace{\text{사전학습 모델}}_{\text{동결, 학습 안 함}} \;\to\; \underbrace{\text{벡터}}_{d\text{차원}} \;\to\; \underbrace{\text{작은 MLP}}_{\text{이것만 학습}} \;\to\; \text{분류}\]
Ch08에서 ResNet을 동결하고 분류기만 바꿔 학습한 것과 완전히 같은 절차다. 바뀐 것은 입력이 이미지에서 문장으로 바뀐 것뿐이다.
학습 파라미터는 전체의 0.1% 미만이므로 데이터 수백 건과 CPU만으로도 된다.
언제 무엇을 고르나
판단 기준은 Ch08과 같다 — 데이터의 양과 도메인의 거리.
| 상황 | 권장 |
|---|---|
| 일반적인 과업, 데이터 거의 없음 | ① 프롬프팅 |
| 우리 회사 문서 분류, 라벨 수백 건 | ② 특성 추출 |
| 전문 용어가 많은 도메인, 라벨 수천 건 | ③ 부분 파인튜닝 |
| 도메인이 완전히 다르고 데이터 충분 | ④ 전체 파인튜닝 |
실무의 순서는 대개 ① → ② → ③ 이다. 프롬프팅으로 먼저 해 보고, 성능이 부족하면 그때 학습을 고려한다. 파인튜닝은 마지막 수단이다 — 비용이 들고, 모델을 관리해야 하고, 사전학습 모델이 갱신되면 다시 해야 한다.
Model Hub — 남의 모델을 찾고 고르는 법
사전학습 모델은 HuggingFace Hub 같은 공개 저장소에 모여 있다. 수십만 개가 올라와 있으므로, 고르는 눈이 필요하다.
모델 이름 읽는 법
klue / bert-base
──── ──── ────
올린 곳 구조 크기
- 올린 곳: 조직·개인 계정 (
google,meta-llama,klue,beomi…) - 구조:
bert,gpt2,roberta… — Ch12에서 배운 Transformer의 변형들이다 - 크기:
base,large,small— 층 수와 \(d\)가 다르다. Ch12의 \(12d^2N\) 을 떠올리자
모델 카드에서 반드시 볼 것 넷
| 항목 | 왜 보나 |
|---|---|
| 학습 데이터 | 내 도메인과 얼마나 가까운가 (③④를 고를지 판단하는 근거) |
| 크기 | 파라미터 수 → 메모리와 속도. Colab에서 돌아가는가 |
| 언어 | 한국어 모델인가, 영어 전용인가, 다국어인가 |
| 라이선스 | 상업적 이용이 가능한가 — 프로젝트를 외부에 쓸 계획이라면 필수 확인 |
공개되어 있다고 아무렇게나 써도 되는 것이 아니다. 연구용만 허용하는 모델, 매출 규모에 따라 제약이 붙는 모델, 출처 표시를 요구하는 모델이 섞여 있다. 모델 카드의 라이선스 항목을 확인하는 것은 데이터셋의 출처를 확인하는 것과 같은 기본 절차다.
토크나이저는 모델과 짝이다
Ch10에서 배운 토크나이저는 모델마다 다르다. 모델과 다른 토크나이저를 쓰면 조용히 망가진다 — 같은 문장이 다른 번호로 쪼개지므로, 모델은 전혀 다른 입력을 받게 된다. Ch08에서 “사전학습 당시의 정규화 통계를 그대로 써야 한다”고 했던 것과 같은 종류의 함정이다.
그래서 라이브러리는
AutoTokenizer.from_pretrained(모델이름)처럼 모델 이름 하나로 토크나이저까지 함께 가져오도록 만들어져 있다.
프롬프팅: 원리에서 나온 사용법
프롬프트는 마법 주문이 아니다
LLM의 출력은 \(P(\text{다음 토큰} \mid \text{문맥})\) — 문맥에 조건부인 확률분포다. 프롬프트를 바꾼다는 것은 이 조건부의 조건을 바꾸는 것이고, 조건이 바뀌면 확률분포 전체가 바뀐다. “나는 어제 학교에”와 “품질관리 보고서: 나는 어제 학교에”는 서로 다른 분포를 만든다. 프롬프트 엔지니어링이 효과가 있는 이유는 마법이 아니라, 확률질량을 내가 원하는 출력 쪽으로 옮기는 조건 설계이기 때문이다.
좋은 프롬프트의 조건들은 전부 이 원리에서 나온다:
| 기법 | 원리와의 연결 |
|---|---|
| 구체적 문맥 제공 | 조건이 구체적일수록 분포가 원하는 답 주변으로 좁아진다 (temperature를 낮춘 것과 비슷한 효과를 조건 쪽에서 만드는 것) |
| 예시 제공 (few-shot) | LLM은 패턴 완성 기계다 — “입력→출력” 예시 몇 개를 보여주면, 같은 패턴을 잇는 토큰열의 확률이 올라간다 |
| 역할·형식 지정 | “너는 품질 엔지니어다”, “표로 답하라”는 그런 문서에서 나올 법한 토큰들로 조건을 옮긴다 |
실례: 같은 과업, 다른 프롬프트
과업: 설비 점검 일지에서 이상 징후를 뽑아 정리하기.
나쁜 프롬프트:
이 일지 요약해줘.
[점검 일지 원문 ...]
좋은 프롬프트:
너는 제조 설비 예방보전 담당 엔지니어다.
아래 점검 일지에서 이상 징후만 골라 다음 형식의 표로 정리하라.
형식: | 설비 | 징후 | 심각도(상/중/하) | 권장 조치 |
예시: | 3번 컨베이어 | 베어링 소음 증가 | 중 | 주말 정비 시 교체 |
주의: 일지에 없는 내용을 추측해서 채우지 말 것.
[점검 일지 원문 ...]
나쁜 프롬프트의 “요약”이라는 조건 아래에서는 온갖 종류의 요약문이 다 그럴듯하다 — 분포가 넓게 퍼져 있고, 어떤 것이 나올지는 운이다. 좋은 프롬프트는 역할(엔지니어의 문서), 형식(표), 예시(패턴), 금지 조건 (추측 금지)으로 조건을 겹겹이 좁혀, 원하는 출력의 확률질량을 최대로 끌어올린다. HW3에서 여러분이 직접 하게 될 일이 바로 이 조건 설계다.
API로 쓰기
챗 화면 바깥에서 LLM을 업무 시스템에 붙이려면 API를 쓴다. 어떤 회사의 API든 구조는 거의 같다 — 메시지 목록을 보내고, 이어질 토큰들을 받는다.
읽어야 할 것은 세 가지다.
- system / user 메시지: system은 지속되는 역할·규칙(프롬프팅의 “역할 지정”이 들어가는 자리), user는 매번의 요청이다. 모델 입장에서는 둘 다 합쳐져 하나의 문맥 — 조건부 확률의 조건 — 이 된다.
- temperature: 이 장에서 손으로 계산한 바로 그 파라미터다. API 문서의 “0에 가까우면 일관된 출력, 높으면 다양한 출력”이라는 설명을 여러분은 이제 수식으로 이해한다.
- 토큰 단위 과금: 입력과 출력 모두 토큰 수로 요금이 매겨진다. 토큰이 무엇인지는 Ch10에서 배웠다 — 단어보다 잘게 쪼개진 조각이므로, 특히 한국어는 눈에 보이는 글자 수보다 토큰 수가 많아지기 쉽다. 긴 문서를 통째로 넣는 설계는 그대로 비용이 된다.
한계: 환각은 버그가 아니라 본성
그럴듯함과 사실은 다르다
LLM은 지금까지 본 것처럼 확률적으로 다음 토큰을 생성하는 기계다. 학습 목표 어디에도 “사실만 말하라”는 없었다 — 목표는 언제나 “그럴듯한 다음 토큰”이었다. 그래서 존재하지 않는 사건(“조선왕조실록에 기록된 세종대왕의 맥북 던짐 사건”)을 물어도, 실록 문체로 아주 그럴듯한 이야기를 지어낸다. 이렇게 사실이 아닌 내용을 유창하게 생성하는 현상을 환각(hallucination)이라 부르는데, 이것은 고쳐야 할 버그라기보다 확률적 생성 모델의 본성이다. 그럴듯함의 확률분포에서 뽑은 문장이 우연히 사실과 일치할 수는 있어도, 일치가 보장되는 메커니즘은 어디에도 없다. 따라서 출력의 사실 여부를 검증할 책임은 언제나 사용자에게 있다.
산업 응용에서의 함의
산업공학도가 LLM을 업무에 쓸 때 이 본성은 설계 조건이 된다. 설비 제원 조회, 안전 규정 안내, 고객 응대처럼 틀린 답의 비용이 큰 업무에 LLM의 출력을 검증 없이 그대로 흘려보내면 안 된다. 실무에서는 LLM을 “초안 생성기”로 두고 사람이 최종 확인하는 절차를 넣거나, 근거 문서를 함께 제공하고 그 안에서만 답하게 조건을 좁히는(앞 절의 프롬프트 원리 그대로) 방식으로 위험을 관리한다. 어느 업무에 어느 수준의 검증 절차를 붙일 것인가 — 어느 쪽 오류가 더 비싼지를 문제가 결정하는, 전형적인 산업공학의 설계 문제다. 아울러 프롬프트에 넣은 내용은 외부 서버로 전송되므로, 사내 기밀을 입력하는 것 자체가 유출 경로가 될 수 있다는 점도 기억해 두자.
동일한 과업을 정해 놓고, 모델도 설정도 바꾸지 않은 채 프롬프트 개선만으로 결과 품질을 끌어올리는 과제다. 이 장에서 배운 원리 (구체적 문맥, few-shot 예시, 역할·형식 지정, 금지 조건)를 실제로 적용해 보는 것이 목표다.
제출물:
- 프롬프트 변천사: 최초 프롬프트 원문 → 각 수정 버전 (무엇을, 왜 바꿨는지)
- 버전별 결과 비교·해석: 각 버전의 출력을 나란히 놓고, 어떤 수정이 어떤 변화를 만들었는지 이 장의 원리(조건부 분포)로 해석
성능이 오르지 않은 수정도 기록하라 — 팀 프로젝트 때와 같은 원칙이다. 왜 안 됐는지 아는 실패는 감점 사유가 아니다.
수업 전체의 회수
한 학기 전, 여러분은 퍼셉트론의 가중합을 손으로 계산하는 것에서 시작했다. 이 수업에서 손으로 계산해 본 것들이 LLM 안에서 각각 어디에 있는지 한 표로 정리하자.
| 손으로 계산한 것 | 어디서 | LLM 안에서의 자리 |
|---|---|---|
| 가중합과 활성화 (퍼셉트론) | Ch02 | 모든 층의 기본 연산 — 어텐션의 “가중합”도 같은 것 |
| Softmax, 교차 엔트로피 | Ch03 | LLM의 출력층과 손실 함수 |
| 경사하강법, 역전파, 연쇄법칙 | Ch03~04 | 수천억 파라미터도 정확히 같은 방법으로 학습된다 |
| 표준화 \((x-\mu)/s\) | Ch04 | LayerNorm — 방향만 바꾼 같은 식 |
| 가중치 공유 | Ch06 | FFN을 모든 토큰에 같은 것으로 적용 |
| 잔차 연결 \(F(x)+x\) | Ch07 | 블록마다 두 번 — 96층을 쌓을 수 있는 이유 |
| 파라미터 수 세기 | Ch02·07 | \(12d^2N\) — 실제 모델 크기를 맞출 수 있다 |
| 전이학습: 동결과 파인튜닝 | Ch08 | 사전학습 LLM의 활용 4방법 — 같은 원리의 규모 확장 |
| 임베딩, 내적·코사인 | Ch10 | 토큰이 모델에 들어가는 첫 관문, 그리고 어텐션 스코어 |
| 어텐션, Multi-Head, 인과 마스크 | Ch11 | 문맥을 반영한 표현을 만드는 핵심 연산 |
| Transformer 블록, LayerNorm | Ch12 | 그 블록을 수십 개 쌓은 것이 곧 LLM의 본체 |
| 다음 토큰 확률, temperature | Ch12 | 생성의 마지막 한 걸음 |
이 표에 LLM을 이해하는 데 필요한 부품이 모두 있다. 빠진 것은 규모뿐이다 — 노드 5개가 수천억 개가 되었을 뿐, 새로운 종류의 수학은 등장하지 않았다.
Ch12에서 GPT-2의 파라미터 수를 손으로 맞춰 본 것이 그 증거다. 여러분은 이제 모델 카드의 숫자를 읽고 크기를 계산할 수 있다.
LLM은 새로운 마법이 아니라, 여러분이 손으로 계산해 본 것들의 규모 확장이다.
이 장에는 손계산이 없다. 기말고사 범위도 Ch12까지다.
대신 이 장에서 요구하는 것은 판단이다 — 데이터의 양과 도메인의 거리를 보고 네 가지 활용 방법 중 하나를 고르고, 그 선택의 이유를 설명할 수 있어야 한다. 창발·정렬·환각은 개념을 자기 말로 설명할 수 있으면 충분하다.
범위 밖: RLHF의 수식, 스케일링 법칙의 수식, 파인튜닝 기법(LoRA 등)의 내부.
핵심 요약
| 개념 | 핵심 내용 |
|---|---|
| 사전학습 | Ch08 전이학습의 규모 확장 — 원리는 같고 크기만 다르다 |
| 자기지도학습 | 텍스트 자체가 문제이자 정답 → 라벨링 비용 0 → “Large”의 열쇠 |
| 창발 / 정렬 | 규모가 만든 예상 밖 능력 / 지시 튜닝·RLHF로 유용한 조수 만들기 |
| 활용 네 방법 | 프롬프팅 → 특성 추출 → 부분 파인튜닝 → 전체 파인튜닝. 위에서부터 시도 |
| 특성 추출 | 모델 동결 + 작은 분류기만 학습 — Ch08 Option 1과 같은 절차 |
| Model Hub | 이름 읽기, 모델 카드 4항목(데이터·크기·언어·라이선스) |
| 토크나이저는 짝 | 모델과 다른 토크나이저를 쓰면 조용히 망가진다 |
| 프롬프팅 | 조건부 확률분포의 조건 설계 — 구체적 문맥, few-shot, 역할·형식 |
| API | system/user 메시지 + temperature + 토큰 단위 과금 (토큰은 Ch10) |
| 환각 | 그럴듯함 ≠ 사실 — 본성이므로 검증 책임은 사용자에게 |
이론은 여기까지다. 13주는 이 장의 내용을 직접 손으로 돌려 보는 실습과 현장 테스트 결과 공유를 겸한다. 14주 발표에서 만나자.