· 5분 읽기
로컬 LLM 서비스 스택 가이드: 하드웨어 선택부터 LangChain/LangGraph까지
로컬 LLM 서비스를 구축하는 과정은 결국 두 계층의 의사결정으로 나뉩니다. 하나는 모델을 어떤 하드웨어에 얹을지이고, 다른 하나는 그 위에서 실행 흐름을 어떻게 조율할지입니다. 이 글은 하드웨어 계층부터 시작해 오케스트레이션 계층까지 순서대로 짚습니다.
1부. 하드웨어 계층: VRAM이 가장 비싼 실패 포인트
로컬 LLM 장비 선택의 핵심은 단순 연산 성능이 아니라 "목표 모델이 메모리에 안정적으로 올라가는가"입니다. 연산 속도가 아무리 빨라도 VRAM이 부족하면 모델 자체가 로드되지 않거나, 오프로딩과 멀티 GPU 구성을 붙이느라 비용과 복잡도가 급격히 늘어납니다.
먼저 결정할 4가지
하드웨어를 고르기 전에 다음 네 가지를 먼저 정해야 합니다.
- 목표 모델 크기 (7B / 13B / 70B 이상)
- 주 용도 (추론 전용인지, 파인튜닝까지 포함하는지)
- 운영 제약 (전력, 소음, 랙 환경)
- 총비용 (초기 구매 비용 + 운영 비용)
계열별 비교
로컬 LLM용 하드웨어는 크게 세 계열로 나뉘고, 계열마다 강점과 한계가 뚜렷합니다.
| 계열 | 장점 | 한계 | 적합한 상황 |
|---|---|---|---|
| NVIDIA 워크스테이션 계열 | CUDA 생태계, 학습/추론 도구 호환성 최고 | VRAM 부족 시 멀티 GPU·오프로딩 비용 급증 | 튜닝과 서비스 운영을 모두 해야 할 때 |
| 소비자 GPU 계열 | 높은 가성비, 빠른 단일 카드 추론 | 대형 모델에서 VRAM 부족이 빨리 찾아옴 | 7B~30B 중심의 개발·프로토타입 |
| Mac Studio 계열 | 큰 통합 메모리 구성, 전력·소음 유리 | CUDA 전용 스택·학습 워크로드와 호환성 제약 | 대용량 추론 실험, 개인 연구 환경 |
세 계열 모두 "최고 성능"이 아니라 "목표 모델을 안정적으로 돌리는 최소 구성이 어디인가"라는 기준으로 비교해야 합니다.
실무 추천
- 서비스 준비 단계에서는 NVIDIA 단일 GPU로 시작해 실제 병목을 측정합니다.
- 70B 이상 모델의 추론이 목표라면 메모리 여유를 최우선 구매 기준으로 삼습니다.
- 파인튜닝이 필요하다면 CUDA 호환성을 비용보다 먼저 검토합니다.
- 구매를 확정하기 전에는 반드시 동일한 목표 모델로 직접 벤치마크를 돌려봅니다. 확인할 항목은 토큰/초 처리량, p95 지연 시간, OOM(메모리 부족) 발생률입니다.
VRAM은 로컬 LLM 인프라에서 가장 비싼 실패 포인트입니다. 부족한 VRAM은 나중에 소프트웨어로 메꾸기 어렵고, 결국 멀티 GPU 구성이나 재구매로 이어집니다. 하드웨어 결정을 VRAM 기준으로 먼저 고정하고, 나머지(전력·소음·비용)를 그 안에서 조율하는 순서가 안전합니다.
2부. 오케스트레이션 계층: LangChain과 LangGraph
하드웨어 위에 모델이 안정적으로 올라갔다면, 다음은 그 모델을 실제 서비스 흐름 안에서 어떻게 호출하고 제어할지의 문제입니다. LangChain과 LangGraph는 종종 경쟁 도구처럼 소개되지만, 실제로는 계층이 다른 도구입니다.
- LangChain: 모델 호출, 프롬프트 구성, 도구 바인딩을 담당합니다.
- LangGraph: 상태 전이, 분기, 재시도, 체크포인트를 담당합니다.
언제 무엇을 쓸까
| 상황 | 적합한 도구 |
|---|---|
| 단일 체인 기반 RAG | LangChain만으로 충분 |
| 도구 호출이 단순한 챗봇 | LangChain만으로 충분 |
| 짧은 요청-응답 워크플로우 | LangChain만으로 충분 |
| 다단계 에이전트 플로우 | LangGraph 필요 |
| 실패 시 특정 단계만 재실행해야 함 | LangGraph 필요 |
| 사람 검토(HITL), 상태 지속, 분기 라우팅 | LangGraph 필요 |
권장 아키텍처
- LangChain으로 노드 내부 로직(모델 호출, 프롬프트, 도구 바인딩)을 구현합니다.
- LangGraph로 노드 간 상태와 흐름을 제어합니다.
- 체크포인트 저장소를 두어 세션 유지와 장애 복구를 지원합니다.
실패를 줄이는 노드 설계 원칙
- 노드 단위를 너무 크게 잡지 않습니다. 하나의 노드가 여러 책임을 겸하면 실패 지점을 특정하기 어려워집니다.
- 각 노드의 입력/출력 스키마를 고정합니다. 스키마가 흔들리면 그래프 전체의 상태 관리가 깨집니다.
- 도구 호출 실패와 모델 실패를 분리해서 계측합니다. 원인을 구분해야 재시도 전략을 다르게 적용할 수 있습니다.
- 프롬프트·모델 버전을 상태와 함께 기록합니다. 나중에 특정 실행 결과를 재현하거나 디버깅할 때 필수적입니다.
빠른 MVP는 LangChain만으로 시작하고, 운영 안정성이 필요해지는 시점에 LangGraph를 도입하는 순서가 비용 효율적입니다. 처음부터 LangGraph의 상태 관리 전체를 설계하는 것은 과잉 엔지니어링이 되기 쉽습니다.
정리
로컬 LLM 스택은 하드웨어와 오케스트레이션이라는 두 계층이 순서대로 쌓입니다. 하드웨어 계층에서는 VRAM을 기준으로 목표 모델이 안정적으로 올라가는 최소 구성을 찾아야 하고, 구매 전 반드시 직접 벤치마크로 검증해야 합니다. 그 위 오케스트레이션 계층에서는 LangChain과 LangGraph의 역할을 분리해서 이해하는 것이 핵심입니다. 단순한 흐름은 LangChain만으로 충분하고, 상태·분기·재시도가 필요해지는 순간 LangGraph를 얹습니다. 아래 계층(하드웨어)이 불안정하면 위 계층(오케스트레이션)에서 아무리 견고하게 설계해도 지연·OOM 같은 문제가 그대로 전파되므로, 두 계층을 함께 고려해서 설계해야 합니다.