로컬 LLM

지도 위치 : 5일차 · 프로젝트 1단계 · 다섯 층 전체의 설계도 | 이전: 32차시 AI 애플리케이션 통합 | 다음: 34차시 LLM 모델 선정 및 최적화 키워드 : 업무 시나리오 선정, 사용자 요구사항 분석, 서비스 기능 정의

이 차시를 다 읽으면

1. 5일차 여덟 차시가 각각 무엇을 산출 하고, 그 산출물이 다음 차시의 입력 이 되는 순서를 말할 수 있다.
2. 내 업무 시나리오가 로컬 LLM에 맞는지 판별 기준 표 로 가를 수 있다.
3. "빠르게", "정확하게" 같은 요구를 측정 가능한 완료 기준 으로 바꿀 수 있다.
4. 평가셋 을 프로젝트의 첫 산출물로 만들고, 가명 처리 규칙을 정할 수 있다.
5. 기능마다 완료 기준을 형식 기준과 의미 기준으로 따로 적을 수 있다.
6. 범위 밖 목록 을 왜 따로 쓰는지 설명할 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — 1~4일차는 다섯 층을 하나씩 깊게 팠습니다. 5일차는 README 4장의 "넓게 → 깊게 → 다시 넓게 "의 마지막 칸입니다. 그 첫 차시인 33차시는 새로 배우는 시간이 아니라, 앞에서 배운 1차시(로컬이 맞는가) , 6 · 28 · 31차시(평가셋) , 29차시(형식 ↔ 내용) 를 문서 한 장으로 회수 하는 시간입니다.

---

1. 5일차 전체 지도 — 산출물이 다음 차시의 입력이다

1.1 여덟 단계와 산출물 ⭐

이 표를 세로로 읽으면 평가셋이 세 번 등장합니다. 34차시에 모델을 거르고, 36차시에 프롬프트를 고르고, 39차시에 최적화가 품질을 망가뜨리지 않았는지 확인합니다. 그래서 평가셋이 33차시의 가장 중요한 산출물 입니다(5절).

⭐ 이 순서는 AI에게 개발을 맡길 때의 기본 순서이기도 합니다. ① 무엇을 만들지 적은 문서(md 파일)를 먼저 쓰고, 이 단계에서는 코드를 쓰지 않게 한다 → ② 범위와 경계(무엇을 하고 무엇을 하지 않는가)를 확정한다 → ③ 그 문서를 AI에게 함께 주고 코드를 만들게 한다. 33차시의 요구사항 문서가 그 ①번 문서입니다. 이 문서 없이 AI에게 "문의봇 만들어줘"라고 하면, AI가 범위와 기준을 대신 정합니다.

1.2 💡 내 업무로 바꿔 적용하는 법

이 노트의 예제는 README 8.1절의 문의봇 입니다. 하지만 표의 칸은 그대로 두고 내용만 바꾸면 어떤 업무에도 씁니다.

---

2. 업무 시나리오 선정 — 로컬 LLM에 맞는 일인가

2.1 정의

업무 시나리오 — [요구사항 문서의 출발점]인데, [ 누가 · 어떤 입력을 받아 · 무엇을 만들고 · 누가 확인하는지를 한 흐름으로 적는다 ]는 점에서 기능 이름만 나열한 기능 목록과 구별된다.

"요약 기능, 분류 기능"은 기능 목록입니다. "상담원이 문의 메일을 붙여넣으면 분류 · 추출 결과와 답변 초안이 뜨고, 상담원이 고쳐서 확정한다"가 시나리오입니다. 확인하는 사람 이 문장 안에 들어 있어야 합니다.

2.2 ⭐ 판별 기준 표 — 1차시 회수

앞에서 배운 로컬이 맞지 않는 경우(1차시 3.2) 와 SLM (1차시 1.1 — GPU 한 장으로 돌릴 수 있는 작은 언어 모델) 의 한계 를 시나리오 선정 기준으로 바꾼 표입니다. SLM은 업무 하나로 좁힌 일(분류 · 추출 · 요약)은 잘하지만, 여러 단계를 거치는 어려운 추론이나 학습 때 보지 못한 최신 지식에는 약합니다. 아래 표의 마지막 두 줄이 그 한계입니다.

⭐ 위 네 줄(텍스트 · 반복 · 사람 검토 · 민감)이 모두 1 이고 아래 두 줄이 0이 아니면 로컬 LLM 프로젝트로 좋은 시나리오입니다. 앞에서 배운 로컬 LLM이 필요한 다섯 가지 이유(1차시 3.1) 중 "데이터 보안"이 결정타인 경우입니다.

2.3 반례 — 이런 시나리오는 이번 프로젝트로 고르지 마세요

2.4 시나리오 한 장 양식

[시나리오 이름]  문의봇 — 고객 문의 1차 처리 도우미
[사용자]        상담원 10명 (동시 사용)
[입력]          고객 문의 메일 본문 (한국어, 길면 수천 자)
[출력]          ① 분류  ② 추출 필드  ③ 3줄 요약  ④ 답변 초안
[사람이 확인]    상담원이 ①~④를 보고 고친 뒤 '확정'을 누름. 자동 발송 없음
[도구]          주문 조회 (읽기 전용)
[왜 로컬인가]    본문에 개인정보 → 외부 API 전송 불가 (1차시 3.1 이유 1)
[빈도]          하루 약 N건 (실제 숫자로 채울 것)

🔍 읽는 포인트 : [사람이 확인] 줄이 비어 있으면 그 시나리오는 아직 덜 쓴 것입니다. 0절 축 4의 어느 쪽인지 처음부터 정합니다.

---

3. ⭐ 요구사항을 측정 가능한 완료 기준으로

3.1 정의

완료 기준 (Acceptance Criteria) — [요구사항의 일부]인데, [ 측정 방법과 통과 숫자가 함께 적혀 있어 느낌이 아니라 검사로 끝을 판정할 수 있다 ]는 점에서 바람을 적은 요구 문장과 구별된다.

좋은 요구사항은 두 가지를 갖춥니다.

그리고 완료 기준에는 "정상적으로 쓰면 동작하는가"만 넣지 않습니다. "잘못 쓰이거나 공격당했을 때 막는가" 도 넣습니다. 정상 입력으로만 시험한 서비스는, 실제 운영에서 처음 들어온 이상한 입력에 무너집니다. 아래 표의 "본문에 없는 주문번호 생성 0건", "되돌릴 수 없는 작업 자동 실행 0건"이 그런 기준입니다.

3.2 변환표 — 사용자의 말 → 완료 기준

⚠️ 표의 숫자는 목표 입니다. 아직 아무것도 재지 않았습니다. 34 · 39차시에서 실제로 재 보고 목표가 비현실적이면 고쳐도 됩니다. 단, 고친 이유를 기록 합니다. 숫자를 조용히 바꾸면 완료 기준이 다시 "느낌"이 됩니다.

💡 지표 이름(TTFT, TPOT, p95)은 앞에서 배운 14 · 22차시 그대로입니다. 33차시에서 처음 정하는 것은 통과선 뿐입니다.

3.3 요구사항 ID — 원자성과 추적성

요구사항마다 ID를 붙입니다. 두 가지를 얻기 위해서입니다.

• 원자성 — 요구사항 한 줄에 요구 하나만 담는다. "분류하고 추출한다"처럼 둘을 묶으면, 하나만 통과했을 때 완료인지 아닌지 말할 수 없습니다.
• 추적성 — 요구사항 → 구현(프롬프트 파일 · 코드) → 측정 결과를 같은 ID로 따라갈 수 있다 . 40차시 발표에서 "FR-01은 어디서 어떻게 확인했나"에 바로 답할 수 있게 됩니다.

FR (Functional Requirement, 기능 요구사항) — [요구사항]인데, [ 시스템이 무엇을 하는가 ]를 적는다는 점에서, 어떻게 · 얼마나 잘 하는가 (속도 · 보안 · 가용성)를 적는 NFR(비기능 요구사항) 과 구별된다.

앞으로 다시 만납니다 — 36차시에서 프롬프트 파일 맨 위에 FR-01 같은 ID를 주석으로 답니다(3.3절의 추적성). 40차시 발표의 성능 표는 NFR-01 줄을 그대로 채운 것입니다.

---

4. 서비스 기능 정의 — 4일차 기능 중에서 고르기

4.1 4일차 메뉴판

4.2 ⭐ 축 ⑧ — 형식 기준과 의미 기준을 따로 적기

앞에서 배운 29차시 의 핵심 문장은 "형식이 맞아도 내용이 틀릴 수 있다"였습니다. 완료 기준도 그래서 두 줄 입니다.

❌ "JSON이 잘 나오니 추출 기능 완료" — 형식 기준만 통과한 것입니다. ⭕ "스키마 통과 100%, 주문번호 정확도 96%, 지어낸 주문번호 0건" — 두 줄 다 적힌 완료입니다.

⭐ 형식 기준은 코드가 판정 할 수 있고, 의미 기준은 평가셋이나 사람 이 판정합니다. 기능을 더 꼼꼼히 보고 싶으면 이 표에 칸을 늘리면 됩니다. 쓸 만한 칸은 다섯 가지입니다 — 형식 (스키마 통과), 근거 일치 (답이 본문에 근거하는가, 31차시 3.1), 금지 사항 (약속하면 안 되는 말을 했는가), 인젝션 방어 (28차시 5절), 범위 이탈 (맡은 일 밖의 답을 했는가). 첫 칸만 코드가 판정하고, 나머지는 평가셋과 사람이 판정합니다.

4.3 범위 밖 목록

범위 밖 목록 (Out of Scope) — [요구사항 문서의 일부]인데, [ 하지 않기로 한 것을 명시해 둔다 ]는 점에서 아직 정하지 않은 것(미정)과 구별된다.

AI에게 구현을 맡기면 AI는 범위를 넓히는 쪽 으로 움직입니다. "로그인도 넣었습니다", "자동 발송 기능도 추가했습니다". 범위 밖 목록은 그것을 막는 가이드 , 즉 AI가 일하기 전에 읽게 하는 "여기까지만" 표지판입니다.

---

5. ⭐ 평가셋 — 프로젝트의 첫 산출물

5.1 정의와 왜 첫 번째인가

평가셋 (Evaluation Set) — [테스트 데이터]인데, [ 실제 업무 입력과 사람이 정한 기대 결과를 짝지어 고정해 둔다 ]는 점에서 그때그때 떠오르는 질문으로 해 보는 시험과 구별된다.

앞에서 배운 평가셋(6차시 5절) 이 출발점입니다. 처음부터 수백 건을 모을 필요는 없습니다. 20~50건 이면 모델 · 프롬프트 사이의 큰 차이는 충분히 보입니다. 1.1절 표에서 본 대로 평가셋은 34 · 36 · 39차시에 다시 쓰입니다. 모델을 고르기 전에 있어야 합니다. 모델을 먼저 고르고 평가셋을 나중에 만들면, 고른 모델이 잘하는 문제만 모이기 쉽습니다.

5.2 무엇을 담나

{"id": "E001", "input": "주문번호 20261128-0042 배송이 일주일째 안 와요...", "expected": {"category": "배송지연", "order_id": "20261128-0042", "customer_name": "고객A"}, "tags": ["평범"]}
{"id": "E017", "input": "환불해 주세요. 주문번호는 기억이 안 나요", "expected": {"category": "교환·반품", "order_id": null}, "tags": ["주문번호없음"]}

🔍 읽는 포인트 : expected 안의 "order_id": null — "없음"도 정답입니다. 모델이 여기에 번호를 채워 넣으면 지어낸 것 입니다. tags는 나중에 "어느 묶음에서 틀렸나"를 보기 위한 꼬리표입니다.

5.3 가명 처리 ⚠️

⚠️ 가명 처리 전의 원본을 코딩 도우미 AI 대화창에 붙여넣지 마세요. 코딩 도우미가 클라우드 서비스라면, 그 순간 "개인정보 때문에 로컬"이라는 이 프로젝트의 이유가 무너집니다. 가명 처리는 사람이 먼저 , 그다음에 AI에게 넘깁니다. 보관하지 않은 데이터는 유출될 수도 없습니다. 원본은 꼭 필요한 곳에만 두세요.

5.4 기대 결과는 사람이 씁니다

❌ "평가셋 정답도 AI가 만들어 줘" — 같은 계열 모델이 문제와 정답을 둘 다 만들면, 채점이 관대해집니다(README 9장 "품질 자가 채점"). 채점자가 응시자와 같은 사람이면 채점이 아닙니다. ⭕ 입력 수집 · 가명 처리 · JSONL 변환은 AI에게 맡기고, expected 칸은 업무를 아는 사람이 채웁니다.

---

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

이 차시는 문서를 만드는 단계 입니다. AI는 초안 작성자, 당신은 결정권자입니다.

지시

아래 [시나리오 메모]를 바탕으로 프로젝트 요구사항 문서 초안을 만들어줘.

목표: 로컬 LLM 기반 '문의봇'(고객 문의 요약·분류·추출·답변 초안 + 주문 조회 도구)의 요구사항 문서.
맥락: 상담원 10명 동시 사용, RTX 4090 24GB 한 대, 개인정보 때문에 외부 API 사용 불가.
제약:
- 요구사항마다 ID(FR-xx, NFR-xx)를 붙이고, 완료 기준은 반드시 '측정 방법 + 숫자'로 써.
- 기능 요구사항의 완료 기준은 [형식 기준 | 의미 기준] 두 칸으로 나눠 써.
- 숫자는 아직 측정 전이므로 전부 '목표(미측정)'라고 표시해. 측정값처럼 쓰지 마.
- 범위 밖 목록을 따로 만들어. 내가 쓰지 않은 기능을 범위 안에 추가하지 마.
- 평가셋 JSONL 양식(필드 이름과 예시 2줄)만 만들고, expected 값은 비워 둬.
보고 형식:
[ID | 구분 | 요구사항 | 형식 기준 | 의미 기준 | 측정 차시] 표 + 범위 밖 목록 표 + 평가셋 양식.

[시나리오 메모]
(2.4절 양식으로 쓴 내 시나리오를 붙여넣기 — 가명 처리된 것만)

받을 증거

• 요구사항표 (ID · 형식 기준 · 의미 기준 칸이 다 채워진 것)
• 범위 밖 목록
• 평가셋 양식 파일 (expected가 비어 있는 것)

내가 직접 볼 것

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

• 시나리오 한 장 (2.4절 양식, [사람이 확인] 줄 포함)
• 로컬 적합성 판별표 (2.2절, 내 시나리오로 채움)
• 요구사항표 (ID, 형식 기준 · 의미 기준, 측정 차시)
• 성능 목표(SLO) 한 줄 이상 — 예: "동시 10명 TTFT p95 < 1초" → 39차시에서 씀
• 범위 밖 목록
• 평가셋 v1 (30건 이상, 묶음별 태그, 가명 처리 완료, expected는 사람이 작성)
• 가명 처리 규칙표 (5.3절)

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 33차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"로컬 LLM에 맞는 시나리오 판별", "형용사 요구를 완료 기준으로 바꾸기", "형식 기준과 의미 기준", "평가셋이 첫 산출물인 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.