(폐쇄망 LLM 7-1) 로컬 Agent Coding 시스템 구축 - 하드웨어/소프트웨어 설계
폐쇄망에서 로컬 에이전트 코딩 시스템을 구축하기 위한 GPU 서버 사양과 소프트웨어 스택 설계 가이드. vLLM, Open-WebUI, Claude-Code 조합으로 내부망 AI 서비스를 구성합니다.
이전 글: Claude Code Router 설정
이 글은 망분리 환경 AI 배포 시리즈의 일곱 번째 글입니다.
다음 글: Docker 환경 구축
이번 글의 목표
이제부터는 망분리 환경에서 AI 배포를 직접 진행하는 실전 파트입니다.
처음부터 끝까지 따라할 수 있도록 전 과정을 다룹니다. 이번 글에서는 팀 규모에 맞는 하드웨어 사양과 소프트웨어 스택을 설계합니다.
실전 상황
8명으로 구성된 팀에 AI 모델을 제공하려고 합니다. 아마 이 중 6명 정도가 실사용자가 되겠죠?
서비스는 두 가지 방식으로 제공할 겁니다:
| 서비스 | 설명 |
|---|---|
| Open-WebUI | ChatGPT와 유사한 웹 인터페이스 |
| Claude-Code / Mistral-Vibe | CLI 기반 에이전트 |
에이전트 코딩까지 지원하려면 모델 성능이 어느 정도 받쳐줘야 합니다. 단순 챗봇용이라면 작은 모델로도 충분하지만, 코드를 읽고 수정하고 테스트까지 하려면 얘기가 달라지거든요.
모델 선정
모델 선택 가이드에서 다뤘던 것처럼 벤치마크, 실사용 경험, 커뮤니티 피드백을 종합해서 모델을 골라봤습니다:
| 모델 | 파라미터 | 용도 |
|---|---|---|
| GLM-4.5-Air-FP8 | 110B | 범용 (프로그래밍 + 일반 업무) |
| Devstral-Small-2-24B-Instruct-FP8 | 24B | 코딩 특화 |
두 모델 모두 FP8 양자화 버전을 사용합니다. VRAM 효율과 추론 속도 면에서 최선의 선택입니다.
KV Cache 계산
KV Cache 메모리 계산법을 적용해보면, 두 모델 모두 128k 컨텍스트 기준 KV cache가 대략 20GB 정도 나옵니다.
Devstral은 256k 컨텍스트까지 지원하긴 하는데, 개인적으로는 긴 컨텍스트를 남용하기보다 작업을 작은 단위로 나누는 게 낫다고 생각합니다. 128k면 충분합니다.
워스트 케이스 시나리오
동시에 4명이 풀 컨텍스트로 사용한다고 가정하면:
| 모델 | 모델 + KV Cache (4명) |
|---|---|
| Devstral (24B) | 24GB + 80GB = 100GB + α |
| GLM-4.5-Air (110B) | 110GB + 80GB = 200GB + α |
프로그래밍뿐 아니라 일반 업무까지 커버해야 한다면 GLM-4.5-Air가 더 적합합니다. 코딩만 한다면 Devstral이 더 뛰어난 것 같습니다.
VRAM 한계와 해결책
만약 GLM-4.5-Air를 써야만 하는 경우라면 200GB 이상 필요한데 전부 VRAM으로 감당하려면 예산이 너무 많이 듭니다. H100 80GB를 3장 이상 써야 하는데, 그건 현실적이지 않죠.
192GB 정도 VRAM이 있으면 모델은 전부 GPU에 올라갈 테고 KV Cache가 문제입니다. 우선순위가 낮은 KV Cache의 경우 CPU RAM 공간에 잠시 캐시해 두면 그럭저럭 관리가 가능할 것 같습니다. 실제로 vLLM에서 --swap-space 옵션을 쓰면 KV cache를 CPU RAM으로 오프로드할 수 있습니다. CPU RAM은 여러 가지 변수를 염두에 두고 최대한 넉넉히 준비할 생각입니다.
주의!
--cpu-offloading옵션은 모델 레이어를 CPU로 보냅니다. 속도에 치명적인 영향을 줍니다.
하드웨어 구성
이런 요구사항을 고려해서 다음과 같이 구성했습니다:
| 구성 요소 | 사양 |
|---|---|
| CPU | AMD Threadripper PRO 9975WX (32 Core) |
| GPU | RTX Pro 6000 Blackwell × 2 = 192GB |
| RAM | 64GB × 8 = 512GB |
| Storage | NVMe 4TB |
GPU 192GB면 모델 + 기본 KV cache는 충분히 올라가고, 동시 사용자가 많아지면 CPU RAM으로 넘치는 KV cache를 오프로드하는 전략입니다. CPU RAM이 그런 상황을 고려해도 조금 많은데요, 여러 가지 상황을 고려했습니다. 팀원이 증가한다거나, 큰 모델을 CPU RAM에 놓고 활성 전문가만 GPU에 올려 계산하는 기술이 발전할 수도 있으니까요. 후자의 방식은 현재도 존재하기는 하는데 동시 요청이나 속도 면에서 최적화가 조금 부족한 상태입니다. 저장 장치 4TB는 생각보다 그렇게 과도하게 큰 용량은 아닙니다. 받아야 하는 Docker 이미지들이 10GB 언저리고 모델들이 기본 30GB 정도는 하니까요. 몇 개 테스트하다 보면 1TB는 우습게 씁니다. 생각보다 넉넉하지 않습니다.
소프트웨어 스택
하드웨어를 정했으니 이제 소프트웨어 선택입니다. LLM 서빙 프레임워크 비교에서 정리했던 내용을 바탕으로 골랐습니다:
| 용도 | 선택 | 이유 |
|---|---|---|
| 서빙 프레임워크 | vLLM | 동시 사용자 처리, 안정성 |
| 웹 UI | Open-WebUI | ChatGPT 유사 인터페이스 |
| CLI Agent | Claude-Code + Claude-Code-Router | 에이전트 코딩 |
| 또는 Mistral-Vibe | MIstral 계열은 에이전트 코딩시 Vibe 필요 |
다음 글
로드맵은 여기까지입니다. 자, 이제 본격적으로 시작해 보죠! 다음 글에서 본격적인 설치를 진행합니다.
시리즈 목차
전체 목차는 AI 활용에서 확인하실 수 있습니다.
