로컬 LLM

지도 위치 : 5일차 · 프로젝트 8단계 · 과정 전체 정산 | 이전: 39차시 성능 테스트 및 최적화 | 다음: 처음으로 — 이 노트를 읽는 법 키워드 : 서비스 시연, 구현 결과 발표, 성능 비교 및 개선사항 도출

이 차시를 다 읽으면

1. 발표를 일곱 덩어리 (문제 · 왜 로컬 → 시연 → 다섯 층 → 결정 근거 → 품질 → 성능 → 한계 · 개선)로 구성할 수 있다.
2. 실패 시나리오를 포함한 시연 대본 과 실패 대비책을 준비할 수 있다.
3. 모든 숫자를 측정 조건 · 출처와 함께 말할 수 있다.
4. 40차시 전체를 여덟 개 축 에 다시 꽂아, 새로 만든 축이 하나도 없었음을 확인할 수 있다.
5. 이 과정의 번역어 함정 과 세 문장 이 프로젝트의 어디서 실제로 걸렸는지 말할 수 있다.
6. KPT 로 개선사항을 도출하고, 다음 학습(RAG · 파인튜닝 · 멀티 GPU)으로 이어지는 자리를 찾을 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — README는 이 노트 전체에 세 가지 약속을 걸었습니다. 여덟 개의 판별 축 (README 5장)으로 모든 새 용어를 가른다, 번역어 함정 (6장)을 짚는다, 세 문장 (7장)이 과정 전체를 관통한다. 39차시 동안 그 약속을 매 차시 반복했습니다. 40차시는 그 약속을 정산 합니다. 1~3절은 프로젝트의 정산 (발표), 4절은 과정의 정산 (축 · 번역어 · 세 문장), 5절은 다음의 시작 (개선사항과 다음 학습)입니다.

---

1. 발표 구성 — 일곱 덩어리

1.1 순서와 근거 산출물

⭐ 시연을 두 번째에 둡니다. 청중이 무엇을 만들었는지 먼저 본 뒤 근거를 들어야, 3~6번이 "왜 저렇게 동작하는가"의 설명이 됩니다.

1.2 아키텍처 다섯 층 — 내 선택으로 채우기

⑤ 애플리케이션  상담원 화면 · SSE · 세션 분리 · 프롬프트 파일 · 스키마 · get_order(읽기 전용)   ← 36~38차시
④ API          OpenAI 호환 /v1, API 키, 127.0.0.1 바인딩                                  ← 35차시
③ 추론 엔진     vLLM ___ (운영) / Ollama (개발)                                          ← 35차시
② 모델 파일     ______ · ______ 양자화                                                   ← 34차시
① 하드웨어      RTX 4090 24GB 1장                                                       ← 34차시

🔍 읽는 포인트 : README 4장의 그림과 칸이 같습니다. 5일 동안 칸은 그대로였고 내용만 채워졌습니다. 오른쪽 화살표는 "이 칸을 정한 근거가 어느 차시 산출물에 있는가"입니다. 질문을 받으면 그 산출물을 엽니다.

---

2. 시연 — 대본과 실패 대비

2.1 대본

⭐ ②~⑤가 정상 장면보다 설득력이 큽니다. 앞에서 본 대로 정상 동작만 시험한 시스템은 시험하지 않은 것과 같습니다(38차시 6절) . 발표도 같습니다. 정상 장면은 "동작한다"만 보여 주지만, 실패 장면은 "막아야 할 것을 막도록 설계했다 "를 보여 줍니다.

2.2 ⚠️ 실패 대비

---

3. 숫자로 말하기 — 품질 표와 성능 표

3.1 품질 결과표 (33차시 요구사항 그대로)

3.2 성능 결과표

3.3 ⭐ 한 줄 문장 양식

성과를 말하는 문장에는 세 가지가 함께 있어야 합니다. 무엇이 얼마에서 얼마로 (이전 → 이후), 어떤 조건에서 (39차시 1.3의 측정 조건), 그동안 품질은 지켰는가 (평가셋). 하나라도 빠지면 듣는 사람이 확인할 수 없습니다.

동시 10명 TTFT p95 ___초 → ___초 (측정 P-003 → P-007, vLLM ___, ______ 양자화),
같은 조건에서 평가셋 분류 정확도 ___% → ___% (평가셋 v1, 70건).

⚠️ 미달을 숨기지 마세요. 모든 설계에는 한계가 있고, 한계를 숫자와 원인으로 말할 수 있는 것 이 오히려 설계를 이해했다는 증거입니다. "어디서 왜 깨지는지 안다"는 것은 "어디를 고치면 되는지 안다"는 뜻이기 때문입니다.

---

4. ⭐ 과정 전체 정산 — 새로 만든 축은 하나도 없었다

1차시 0절부터 39차시 0절까지, 매 차시를 같은 질문으로 시작했습니다. "이 새 용어는 여덟 축 중 어디에 꽂히는가?" 이제 그 약속을 정산합니다.

4.1 정산표 — README 5.1 · 5.2 회수

⭐ 이 표의 오른쪽 끝 열을 세로로 읽어 보세요. 여덟 축이 전부 프로젝트에서 한 번 이상 다시 나왔습니다. PagedAttention, AWQ, GGUF, SSE, 도구 호출 파서… 이 과정에서 처음 들은 이름 은 많았습니다. 그런데 그것을 이해하는 데 필요한 축은 하나도 새로 만들지 않았습니다. README 5장의 약속 — "새 용어가 나오면 새 비유를 만들 필요 없이 어느 축의 어느 쪽에 꽂히는지만 정하면 된다" — 이 40차시 동안 지켜진 것입니다.

4.2 같은 축, 다른 배율 — 축 ⑤ 하나만 세로로

배율 은 같은 축이 적용되는 규모나 층 입니다. 축 ⑤(하나 ↔ 여럿)는 요청 하나를 처리하는 규모에서도, 엔진을 고르는 규모에서도, 앱 구조와 GPU 대수에서도 똑같은 질문으로 나타납니다.

README 5.1의 축 ⑤ 정의 한 줄로 전부 읽힙니다. "뭉치면 단순하고 빠르지만 같이 멈추고, 쪼개면 안전하고 확장되지만 통신 비용을 낸다." 그리고 어느 쪽도 발전된 형태가 아닙니다. 규모와 실패 비용이 답을 정합니다.

4.3 번역어 함정 정산 — README 6장 회수

그리고 README 5.1이 미리 짚어 둔 오해 하나가 이 과정에서 한 번 더 확인되었습니다. 비동기 — "더 빠르다"가 아니라 "처리량이 늘어난다" . 37차시의 스트리밍도, 39차시의 연속 배칭도 한 건의 시간을 줄이지 않았습니다.

4.4 세 문장 정산 — README 7장 회수

⭐ 세 문장 모두 프로젝트의 산출물 하나 이상 에 실제로 박혀 있습니다. 숫자를 외운 것이 아니라 계산식과 순서와 구조 를 썼기 때문에, 모델이나 엔진이 바뀌어도 이 표는 그대로입니다.

---

5. 개선사항 도출 — KPT와 다음 학습

5.1 KPT

KPT — [회고 양식]인데, [ 유지할 것(Keep) · 문제(Problem) · 시도할 것(Try)을 나눠, 다음 행동으로 끝나게 한다 ]는 점에서 느낀 점을 나열하는 소감문과 구별된다.

⭐ Try 줄은 다음 프로젝트의 33차시입니다. 측정 가능한 완료 기준이 붙어 있지 않은 Try는 다짐일 뿐입니다.

5.2 개선 후보 → 고칠 층 → 다음 학습

다음 학습 네 가지 — 무엇인가

⭐ 순서는 프롬프트 → RAG → 파인튜닝 입니다. 비용이 싼 것부터 시도합니다. 프롬프트는 파일 하나를 고치면 되고, RAG는 검색 단계를 붙이면 되지만, 파인튜닝은 학습 데이터 · GPU 시간 · 재평가가 모두 듭니다. 그래서 먼저 원인이 "모르는 것" (입력 밖 지식 → RAG)인지 "말하는 방식" (→ 파인튜닝)인지를 가르고, 대부분의 과제는 RAG에서 끝납니다. 그리고 무엇을 붙이든 이 과정의 세 문장은 그대로입니다. RAG를 붙이면 검색된 문서가 입력에 들어가 KV 캐시 예산이 다시 바뀌고 (문장 1, 34차시로), 품질 · 속도의 거래를 다시 측정하고 (문장 2, 39차시로), 검색기도 포트 뒤의 어댑터 로 붙입니다(문장 3).

💡 멀티 GPU는 4.2절 표의 마지막 줄입니다. GPU를 쪼개면 GPU 사이의 통신 비용 을 냅니다. 새 기술이지만 새 축은 아닙니다.

---

6. 그래서 이제 무엇을 할 수 있는가

마지막 한 문장

이 과정이 가르친 것은 Ollama도 vLLM도 아닙니다. 그 도구들은 몇 달 안에 옵션 이름이 바뀝니다. 이 과정이 가르친 것은 새 도구 앞에서 던질 질문의 순서 입니다 — 무엇의 한 종류인가, 어느 축에 꽂히는가, 반례는 무엇인가, 그리고 숫자로 확인했는가. README 2.3의 네 질문으로 1차시를 열었고, 같은 네 질문에 숫자로 확인했는가 를 더해 이 과정을 닫습니다.

---

7. 실습 — 맡기고 검수하기

지시

문의봇 프로젝트 발표 자료 초안을 만들어줘.

목표: 1.1절의 일곱 덩어리 순서로 슬라이드 초안(마크다운)을 만들고, 3.1·3.2절 결과표와 4.1절 정산표를 채워.
맥락: 프로젝트 폴더의 산출물 — 요구사항표(33), DR-001과 매트릭스(34), 기동 명령과 시험표(35),
     eval/results(36), 행동 시험표(37), 통합 시나리오표(38), 부하 테스트·before/after와 측정 조건 블록(39).
제약:
- 모든 숫자는 위 산출물 파일에서만 가져오고, 숫자마다 출처(파일 이름 또는 측정 ID)를 각주로 달아.
- 산출물에 없는 숫자는 만들지 말고 '___(미측정)'으로 남겨.
- 목표 미달 항목을 빼지 마. 미달은 원인(39차시 병목 판정)과 다음 조치를 함께.
- 시연 입력은 평가셋의 가명 문의만 써.
- 정산표의 '프로젝트에서 다시 나온 자리' 열은 초안만 쓰고, 근거 파일을 함께 적어.
보고 형식: 슬라이드 초안 + [숫자 | 출처] 목록 + 미측정 항목 목록.

받을 증거

• 슬라이드 초안과 [숫자 | 출처] 목록 (숫자 하나도 빠짐없이)
• 미측정 항목 목록
• 시연 대본 (2.1절 다섯 장면)

내가 직접 볼 것

산출물 체크리스트 (40차시)

• 발표 자료 (일곱 덩어리, 다섯 층 그림에 내 선택)
• 시연 대본 (정상 1 + 실패 4) + 녹화본
• 품질 결과표 · 성능 결과표 (숫자마다 출처)
• 한 줄 문장 (이전 → 이후, 조건, 품질 유지)
• 정산표 (8개 축 + 파생 축, 프로젝트에서 다시 나온 자리)
• 번역어 함정 정산 (내 프로젝트에서 걸린 자리)
• KPT (Try는 다음 33차시 형식으로)
• 5일차 산출물 묶음: 요구사항 · 평가셋(33) · DR-001(34) · 기동 명령 · 시험표(35) · 점수표(36) · 행동 시험(37) · 통합 시나리오(38) · 부하 표 · 측정 조건(39)

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 40차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"발표 일곱 덩어리의 순서", "숫자를 조건과 함께 말하기", "여덟 축 정산표", "세 문장 정산", "KPT와 다음 학습(RAG·파인튜닝·멀티 GPU)"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.