로컬 LLM, 왜 지금 다시 봐야 하는가 - OpenClaw와 함께 만드는 스트림 분석 아키텍처

1. 오픈클로 설치하기 - https://likebnb.tistory.com/182에 이어지는 글입니다.

Kafka와 OpenClaw를 연계한 준실시간 스트림 분석 아키텍처

지난 글에서는 OpenClaw를 설치하고 실제로 활용하는 방법을 정리했다.

이번에는 한 단계 더 들어가서, 그 기반이 되는 로컬 LLM(Local Large Language Model) 자체를 이야기해보려고 한다.

단순히 “로컬에서도 돌아간다” 수준이 아니라,
왜 지금 로컬 LLM을 써야 하는지, 그리고 어떻게 아키텍처에 녹여야 하는지를 중심으로 정리한다.

---

1. 왜 로컬 LLM인가

클라우드 LLM은 이미 충분히 강력하다.
그럼에도 불구하고 굳이 로컬을 선택하는 이유는 명확하다.

데이터는 결국 밖으로 나간다

운영 데이터를 다뤄본 사람은 안다.
한 번 외부로 나간 데이터는 통제 대상이 아니라 리스크가 된다.

• 생산 공정 로그
• KPI 집계 데이터
• 사용자 행동 데이터

이런 것들을 외부 API로 보내는 순간,
아키텍처는 단순해지지만 대신 책임과 리스크가 복잡해진다.

로컬 LLM은 이 문제를 아주 단순하게 해결한다.

“데이터를 밖으로 보내지 않는다”

이 한 줄이면 충분하다.

---

비용 구조가 완전히 다르다

클라우드 LLM은 결국 토큰 기반이다.
처음엔 싸 보이지만, 구조가 이렇게 바뀌는 순간 얘기가 달라진다.

• Agent 반복 호출
• 자동화된 분석 파이프라인
• 로그 기반 지속 처리

이때부터는 비용이 아니라 과금 모델 자체가 병목이 된다.

로컬 LLM은 반대로:

• 초기 비용 있음
• 이후 호출 비용 거의 0

즉, 많이 쓸수록 유리한 구조다.

---

제어권(Control Plane)을 가져온다

이건 개인적으로 가장 중요하게 보는 포인트다.

클라우드 LLM:

• API 호출
• 내부는 블랙박스

로컬 LLM:

• 모델 교체 가능
• 추론 방식 제어 가능
• 프롬프트 구조 통제 가능

이건 단순한 차이가 아니다.

“LLM을 도구가 아니라 인프라로 가져올 수 있느냐”

Kafka나 Hadoop을 처음 붙일 때 느낌이랑 비슷하다.
한 번 내부로 들어오면, 그 다음부터는 설계의 일부가 된다.

---

2. 모델 선택, 감이 아니라 기준으로

로컬 LLM 얘기하면 대부분 여기서 무너진다.
“어떤 모델이 좋다”가 아니라, 무엇을 기준으로 선택하느냐가 핵심이다.

---

파라미터 크기보다 중요한 것

많이들 7B, 13B 이런 숫자에 집중하는데,
실제 중요한 건 이거다:

“내 워크로드에서 충분히 쓸 수 있느냐”

현실 기준:

• 7~8B → 빠르고 실용적 (로컬 최적)
• 13B급 → 품질과 성능 균형
• 그 이상 → 성능은 좋지만 운영 부담 증가

결국 정답은 없다.
워크로드에 맞춰 쪼개는 게 답이다.

---

Instruct 모델은 기본값이다

Base 모델로 이것저것 해보는 시도는 의미 있지만,
실무에서는 거의 필요 없다.

• 응답 일관성
• 프롬프트 단순화
• 유지보수

이 세 가지 때문에 결국 Instruct 모델로 간다.

---

Context 길이는 곧 생산성이다

이건 과소평가되기 쉬운데, 실제로는 체감이 크다.

• 짧은 context → RAG 필수
• 긴 context → 구조 단순화

로그 분석, 문서 분석처럼 길이가 중요한 경우에는
context가 곧 아키텍처 복잡도를 줄여준다.

---

성능은 TPS로 본다

모델 성능을 얘기할 때 정확도만 보는 건 반쪽짜리다.

실제 체감은 이걸로 결정된다:

“초당 몇 토큰 나오느냐”

여기서:

• GPU 여부
• quantization (4bit / 8bit)

이게 UX를 결정한다.

---

3. Ollama, 단순한 실행기가 아니다

많이들 “편해서 쓴다”고 하는데, 그건 절반만 맞다.
실제로는 운영 구조가 깔끔해서 쓴다.

---

모델을 컨테이너처럼 다룬다

• pull
• 실행
• 교체

이게 거의 Docker 느낌이다.

이게 중요한 이유는:

“모델을 코드처럼 다룰 수 있다”

---

API로 노출되는 구조

로컬에서 REST API로 바로 쓸 수 있다.

이게 의미하는 건:

• 다른 서비스와 바로 연결 가능
• Agent 구조에 바로 삽입 가능

즉, 마이크로서비스 아키텍처에 자연스럽게 들어간다.

---

모델 선택을 뒤로 미룰 수 있다

이건 생각보다 큰 장점이다.

• 모델 교체 비용 거의 없음
• 실험 부담 없음

→ 초기 설계에서 완벽한 선택을 할 필요가 없다

---

4. OpenClaw와 붙이면 구조가 바뀐다

여기부터가 핵심이다.
로컬 LLM 단독이 아니라, OpenClaw와 붙는 순간 시스템 성격이 달라진다.

---

Agent = 스트림 처리기

구조를 단순화하면 이렇게 된다:

• 이벤트 입력
• LLM 판단
• 액션 실행
• 결과 피드백

이건 거의 그대로:

“스트림 프로세싱 모델”

Kafka를 써봤다면 익숙한 흐름이다.

---

프롬프트는 코드다

이건 반드시 짚고 넘어가야 한다.

• 프롬프트 = 로직
• 프롬프트 = 정책

그런데 대부분 그냥 문자열로 관리한다.

이건 나중에 반드시 터진다.

추천 방식:

• 템플릿 분리
• Git 관리
• 테스트 가능 구조

---

RAG가 기본, 튜닝은 예외

많이들 반대로 생각한다.

실무 기준은 이거다:

• RAG → 기본 전략
• Fine-tuning → 제한적 사용

이유는 단순하다.

유지보수 비용이 다르다

---

Context 관리가 핵심이다

로컬 LLM은 결국 context 싸움이다.

대표적인 방법들:

• sliding window
• 요약 기반 memory
• vector DB

여기서 설계를 잘못하면,
모델이 아니라 시스템이 무너진다.

---

성능은 결국 UX다

최적화 포인트는 명확하다:

• 캐싱
• batching
• streaming
• quantization

목표는 하나다.

“사용자가 기다리지 않게 한다”

---

관측 없으면 운영 못 한다

LLM 시스템은 디버깅이 어렵다.

그래서 더 필요하다:

• prompt / response 로그
• latency 추적
• hallucination 패턴 분석

이건 선택이 아니라 필수다.

---

마무리

로컬 LLM을 단순히 “내 PC에서 돌아가는 AI”로 보면
솔직히 큰 의미 없다.

하지만 관점을 바꾸면 얘기가 달라진다.

“데이터를 이해하고, 판단하고, 행동하는 컴포넌트”

이걸 시스템 안으로 가져오는 순간,
LLM은 도구가 아니라 인프라 레이어가 된다.

그리고 결국 중요한 건 하나다.

모델이 아니라, 그 위에 어떤 구조를 얹느냐