로컬 LLM

지도 위치 : 1일차 · ⑤애플리케이션 층 맛보기 + 1일차 정리 | 이전: 7차시 Ollama API 활용 | 다음: 9차시 LLM 메모리 구조와 GPU 자원 분석 키워드 : Python 기반 로컬 LLM 챗봇, 대화 이력 관리, 간단한 Web UI

이 차시를 다 읽으면

1. "LLM이 대화를 기억한다"가 왜 틀린 말인지, 누가 무엇을 들고 있는지 로 설명할 수 있다.
2. 대화가 길어지면 토큰 · 첫 응답 시간 · 컨텍스트 가 어떻게 되는지 말할 수 있다.
3. UI → 앱 → Ollama 세 칸 구조에서 대화 이력이 사는 칸 을 짚을 수 있다.
4. Streamlit 챗봇 코드에서 session_state와 messages= 줄 을 알아보고 무슨 일을 하는지 말할 수 있다.
5. 기억 테스트 와 두 브라우저 세션 분리 테스트 로 앱을 검수할 수 있다.

---

0. 이 차시의 판별 축

7차시 2.2에서 "/api/chat에 이전 대화는 어디에도 저장되지 않는다"고 했습니다. 그런데 ChatGPT 같은 챗봇은 분명히 앞 대화를 기억하는 것처럼 보입니다. 이 차시의 질문은 "그렇다면 기억은 누가, 어디에 들고 있는가" 이고, 그 답을 가지고 1일차의 마지막 결과물인 대화형 챗봇 앱 을 만듭니다.

---

1. ⭐ LLM API는 무상태다 — 그럼 기억은 어디에?

1.1 무상태와 상태 — 정의, 그리고 세 칸 그림

무상태 (Stateless) — [통신 · 처리 방식]인데, [ 요청 하나하나를 그 요청 안에 담긴 정보만으로 처리하고, 이전 요청을 기억하지 않는다 ]는 점에서 상태 유지와 구별된다. 자판기처럼, 누가 몇 번째로 왔는지 모르고 지금 넣은 돈과 누른 버튼만 봅니다.

상태 유지 (Stateful) — [통신 · 처리 방식]인데, [ 이전에 있었던 일을 기억해 두고 다음 처리에 이어서 쓴다 ]는 점에서 무상태와 구별된다. 단골 손님의 지난 주문을 기억하는 직원이 그렇습니다.

⭐ 여기서 가장 흔한 오해를 먼저 짚습니다. "무상태 시스템"이라고 해서 아무도 상태를 갖지 않는 것이 아닙니다. 무상태인 것은 통신 구간 — 서버가 클라이언트의 지난 일을 기억해 주지 않는다 는 것 — 뿐이고, 기억이 필요하면 클라이언트 쪽이 들고 있다가 매번 같이 보냅니다.

웹 로그인이 같은 구조입니다. 많은 웹 서버는 "이 사람이 아까 로그인했다"를 기억하지 않고, 대신 로그인할 때 받은 신분증 같은 문자열(인증 토큰, 예: JWT) 을 클라이언트가 요청마다 들고 갑니다. 서버는 매번 그 신분증만 확인합니다.

LLM 앱을 이 그림에 겹치면 이렇습니다.

   [ UI — 브라우저 ]                  ← 상태 있음: 화면에 보이는 말풍선
          │
   [ 앱 — Python (Streamlit) ]       ← ⭐ 상태 있음: messages 배열 (대화 이력)
          │
          │  ◀────── 이 구간만 무상태 (Ollama /api/chat)
          │           Ollama는 이전 요청을 기억하지 않는다
          ▼
   [ Ollama + 모델 ]                 ← 대화 기억 없음. 받은 배열을 읽고 다음 토큰을 만들 뿐

⭐ 대화 기억 = 앱이 매번 이력 전체를 다시 보내는 것 입니다. 웹 로그인에서 서버가 안 기억해 주니까 클라이언트가 신분증(인증 토큰)을 매번 들고 가듯 , 여기서는 앱이 대화 이력을 매번 들고 갑니다. 같은 구조입니다.

1.2 턴마다 배열이 자란다

1턴 요청: [system, user1]
1턴 응답:                            → assistant1
2턴 요청: [system, user1, assistant1, user2]
3턴 요청: [system, user1, assistant1, user2, assistant2, user3]
           └──────────── 매번 처음부터 다시 보냄 ────────────┘

대화 이력 (Conversation History) — [애플리케이션 상태]인데, [ 지난 턴의 질문과 답을 역할별로 쌓아 두었다가 매 요청에 통째로 다시 보낸다 ]는 점에서 모델 안에 저장되는 기억과 구별된다 — 그런 기억은 없습니다.

1.3 왜 굳이 무상태로 만드는가 — 장단점

무상태는 "기능이 모자란 것"이 아니라 일부러 고른 설계 입니다. 두 쪽의 장단점을 나란히 놓습니다.

그래서 실무의 흔한 짝은 "엔진은 무상태, 앱이 상태를 든다" 입니다. 엔진(Ollama · vLLM)은 여러 대로 늘리기 쉽게 두고, 기억은 앱 한 곳에서 책임집니다.

⚠️ 반례 — "서버 쪽에도 뭔가 남지 않나요?"

---

2. 이력이 자라면 생기는 일

2.1 비용이 같이 자란다

 num_ctx 8192 (예)
 1턴   [sys][u1]                                                 여유 많음
 10턴  [sys][u1][a1][u2][a2] ... [u10]                           여유 줄어듦
 30턴  [sys]···[u1][a1]··· 잘려 나감 ···[u29][a29][u30]           ⚠️ 첫 턴의 "제 이름은 홍길동" 이 사라짐

⚠️ 이 상태에서 모델은 "기억 안 난다"고 말하지 않고 그럴듯한 이름을 지어낼 수 있습니다. LLM은 입력이 모자라거나 틀려도 무언가를 만들어 냅니다 — 다음 토큰을 예측하는 기계이기 때문입니다(1차시 1.2). 그래서 답이 나왔다는 것은 답이 맞았다는 뜻이 아닙니다. 6차시 4.1의 "조용히 잘린다"와 같은 함정입니다.

2.2 전략 — 오늘은 이름만

앞으로 다시 만납니다 — 27차시(대화형 AI 서비스)에서 세 전략을 구현하고 토큰 예산을 숫자로 짭니다. 오늘 앱은 아무 전략 없이 만들어서, 2.1의 문제를 직접 겪어 보는 것이 목적입니다.

---

3. 앱 만들기 — UI → 앱 → Ollama

3.1 세 칸 구조

 [브라우저]  ──HTTP──▶  [Streamlit 앱 :8501]  ──HTTP──▶  [Ollama :11434]  ──▶ GPU
  말풍선 UI              session_state.messages        127.0.0.1에만 (5차시 4.2)
                         ⭐ 대화 이력이 사는 곳

⭐ 5차시 4.2의 "Ollama는 127.0.0.1에 두고, 앞에 앱을 세운다"가 이 그림입니다. 사용자는 앱만 만나고 Ollama를 직접 만나지 않습니다.

Streamlit — [Python 웹 UI 프레임워크]인데, [ Python 스크립트 하나로 화면을 만들고, 사용자 동작마다 스크립트 전체를 처음부터 다시 실행한다 ]는 점에서 HTML · JS를 따로 짜는 프론트엔드 프레임워크와 구별된다. 같은 자리에 Gradio (ChatInterface가 이력을 대신 관리)도 많이 씁니다.

3.2 코드

import ollama
import streamlit as st

SYSTEM = "당신은 쇼핑몰 고객센터 상담원을 돕는 도우미입니다. 모르는 주문 정보는 지어내지 마세요."
st.title("문의봇 (로컬)")

if "messages" not in st.session_state:                       # ① 이 브라우저 세션의 첫 실행일 때만
    st.session_state.messages = [{"role": "system", "content": SYSTEM}]

for m in st.session_state.messages[1:]:                      # ② 지금까지의 대화를 다시 그림
    st.chat_message(m["role"]).write(m["content"])

if question := st.chat_input("문의 내용을 입력하세요"):
    st.session_state.messages.append({"role": "user", "content": question})        # ③
    st.chat_message("user").write(question)
    with st.chat_message("assistant"):
        stream = ollama.chat(model="qwen3:8b",
                             messages=st.session_state.messages,                  # ④ ⭐
                             stream=True, options={"num_ctx": 8192})
        answer = st.write_stream(c["message"]["content"] for c in stream)        # ⑤
    st.session_state.messages.append({"role": "assistant", "content": answer})    # ⑥

streamlit run app.py      # 브라우저에서 http://localhost:8501

🔍 읽는 포인트

💡 Qwen3의 생각 모드는 설치된 버전에 맞는 방법으로 끕니다(4차시 3.3, 7차시 4.3).

3.3 ⚠️ 이력을 어디에 두는가 — 전역이면 사고

Streamlit은 사용자 동작마다 스크립트를 다시 실행하므로 보통 변수는 매번 사라집니다 (무상태). 그래서 상태를 남기려면 어딘가에 둬야 하는데, 두는 곳에 따라 결과가 갈립니다.

3차시에서 패키지를 두고 본 전역 ↔ 격리 (3차시 0절 축 1, 3.1)가 여기서는 사용자 데이터를 두고 다시 나오고, 이번에는 보안 문제가 됩니다. AI가 "간단하게 전역 리스트로 했습니다"라고 하면 반드시 되돌립니다.

⚠️ session_state는 메모리에만 있습니다(README 5.1 축 ① — 메모리는 휘발, 꺼지면 사라짐). 새로고침하거나 앱을 재시작하면 이력이 사라집니다. 영구 저장(DB)과 세션 ID는 27차시에서 다룹니다.

⚠️ Streamlit은 설정에 따라 같은 네트워크의 다른 PC에서도 접속되는 주소 를 엽니다(실행 화면의 Network URL). 실습에는 편하지만 이 앱에는 로그인이 없습니다 — 즉 인증("너는 누구냐", 5차시 4.2)이 없습니다. 운영 전에는 인증을 붙입니다(32차시).

---

4. 검수 — 기억 테스트와 세션 분리 테스트 ⭐

💡 긴 대화 테스트에서 prompt_eval_count가 기대보다 덜 늘어 보일 수 있습니다. 엔진이 앞부분 계산을 재사용하는 경우입니다(1.3 반례 표, 21차시). 그래도 보낸 배열 자체는 매번 길어진다 는 사실은 같습니다.

---

5. 1일차 정리 — 다섯 층을 한 번 훑었다

README 4장의 다섯 층 지도에 오늘 한 것을 겹칩니다.

README 4장의 순서 그대로 — 넓게 → 깊게 → 다시 넓게 중 넓게 를 한 번 훑었습니다. 내일부터 깊게 들어갑니다.

앞으로 다시 만납니다 — 오늘 2.1의 표에 "KV 캐시 (VRAM) — 토큰마다 쌓임"이라고만 적었습니다. 9차시 에서 config.json(4차시)의 숫자로 그 크기를 직접 계산하고, 8B 모델 · 8K 컨텍스트 · 상담원 10명이 24GB에 들어가는지 답합니다. 1일차의 질문이 "어떻게 돌리나"였다면, 2일차의 질문은 "내 GPU에 어떻게 맞춰 넣나" 입니다.

---

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

지시

목표: Ollama(qwen3:8b)를 쓰는 Streamlit 챗봇(app.py)을 만들어줘. 대화 이력을 유지해야 해.
맥락: Streamlit 공식 문서의 chat 요소(st.chat_input, st.chat_message, st.write_stream)와
      session_state 문서, ollama-python README를 기준으로 해.
제약: - 대화 이력은 반드시 st.session_state에만 둬. 모듈 전역 변수·공유 캐시 금지.
      - Ollama는 localhost:11434로만 호출 (OLLAMA_HOST 변경 금지).
      - num_ctx 8192, 생각 모드 끔.
      - 매 요청마다 [턴 번호 | 보낸 메시지 수 | prompt_eval_count | eval_count | TPS]를
        터미널 로그로 한 줄씩 남겨.
보고 형식: app.py 전체, 실행 명령, 그리고 4절의 테스트 네 가지의 화면 캡처와 로그 원문.
추측하지 말고 실행 출력 원문을 붙여.

받을 증거

• 기억 · 세션 분리 · 새로고침 테스트의 화면 캡처
• 20턴 대화의 로그 원문 (턴마다 한 줄)

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 8차시 노트만 근거로 7문제를 내줘. 비전공자 기준으로.
"LLM API는 무상태 — 기억은 앱이 든다", "messages 배열이 턴마다 자라는 대가", "전역 변수 이력의 개인정보 사고", "세션 분리 테스트"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.