HP ZGX Nano G1n에서 로컬 LLM Agent 구축기 - 30B급 모델의 한계와 GPT-OSS 120B의 가능성

들어가며

NVIDIA DGX Spark의 레퍼런스 디자인인 HP ZGX Nano G1n AI Station을 구매했어요. 128GB 통합 메모리에 NVIDIA GB10 Grace Blackwell Superchip을 탑재한, 손바닥 크기의 AI 워크스테이션이에요. 원래 DGX Spark 자체를 살까 고민했지만, HP 버전이 올메탈 바디에 그린 파워 인디케이터까지 달려 있어서 조금 더 마음에 들었거든요.

이 글에서는 이 장비 위에서 로컬 LLM 기반 Agent를 구축하면서 겪은 시행착오와, 최종적으로 어떤 조합이 "쓸 만한" 수준이었는지를 공유해 보려고 해요.

HP ZGX Nano G1n - 어떤 장비인가요?

HP ZGX Nano G1n은 NVIDIA DGX Spark과 동일한 하드웨어 플랫폼을 사용해요. 핵심 스펙을 정리하면 이래요.

가장 큰 특징은 UMA(Unified Memory Architecture) 에요. CPU와 GPU가 128GB 메모리를 동적으로 공유하기 때문에, 별도의 VRAM 전송 오버헤드 없이 대형 모델을 바로 올릴 수 있어요. 다만 메모리 대역폭이 273GB/s로, 디스크리트 GPU 대비 낮은 편이라 추론 속도(tok/s)는 체감상 느린 편이에요. LMSYS 벤치마크 리뷰에서도 "프로토타이핑과 실험에 적합하지, 프로덕션용은 아니다"라는 평가가 나왔고, 저도 동의해요.

그래도 128GB 통합 메모리 덕분에 100B급 이상의 모델도 로컬에서 로드할 수 있다는 점이 이 장비의 가장 큰 매력이에요.

왜 로컬 Agent를 구축하려 했나

원래 OpenClaw(오픈소스 AI 에이전트 프레임워크)를 사용해서 개인 AI 에이전트를 세팅하고 있었어요. OpenClaw는 WhatsApp, Telegram, Slack 등 메신저 앱과 연동돼서 LLM이 단순히 대답만 하는 게 아니라, 이메일 발송, 브라우저 자동화, 파일 관리, 스케줄링까지 실행해 주는 프레임워크에요. 2026년 초에 GitHub 스타 10만 개를 넘기면서 가장 핫한 에이전트 프로젝트로 떠올랐죠.

문제는 OpenClaw의 시스템 프롬프트가 매우 무겁다는 거예요. 대화 히스토리, 툴 스키마, 스킬 설명, 메모리까지 전부 컨텍스트에 패킹하기 때문에, 프론티어 모델(Claude, GPT, Gemini)에서는 잘 작동하지만 로컬 소형 모델에서는 처참한 결과가 나와요.

상용 모델로 OpenClaw를 돌리면? 잘 돌아가요. 대신 토큰 비용이 어마무시해요. 단순한 질문 하나에도 뒤에서 코드 생성, 웹 검색, 결과 요약 등을 연쇄적으로 처리하니까, 하루에 수만~수십만 토큰이 순삭돼요. 개인 사이드 프로젝트에서 이 비용을 감당하기는 현실적으로 어렵죠. 말 그대로 텅장각이에요.

그래서 "HP ZGX Nano의 128GB 메모리를 활용해서, 로컬에서 충분히 쓸 만한 Agent를 구축할 수 있지 않을까?"라는 생각으로 실험을 시작했어요.

30B급 모델 테스트 - 전멸의 기록

vLLM 프레임워크 세팅 (초기)

처음에는 추론 엔진으로 vLLM을 선택했어요. PagedAttention 기반의 메모리 효율성과 continuous batching, OpenAI 호환 API를 제공하기 때문에 에이전트 프레임워크와 연동하기 좋거든요.

다만 DGX Spark(HP ZGX Nano 포함)에서 vLLM을 돌리려면 약간의 삽질이 필요해요. ARM64 아키텍처에 CUDA 13.0, Blackwell SM121이라는 아직 성숙하지 않은 조합이라, 공식 PyTorch 휠도 x86_64 전용이고 Triton 컴파일러도 SM121을 완벽히 지원하지 않아요. NVIDIA NGC 컨테이너(nvcr.io/nvidia/vllm:25.09-py3)를 쓰거나, --enforce-eager 플래그로 CUDA Graph 최적화를 끈 채 실행해야 하는 상황이에요. Eager 모드에서 대략 20~30%의 성능 손실이 있지만, 일단 돌아가는 것 자체가 먼저니까요.

참고: 이후 GPT-OSS 120B로 모델을 변경하면서 추론 엔진도 SGLang으로 전환했어요. 이 부분은 아래에서 자세히 다룰게요.

테스트한 30B급 모델들

OpenClaw의 시스템 프롬프트를 로드한 상태에서, 다음 모델들을 차례로 테스트했어요.

공통적인 문제는 이거였어요:

OpenClaw가 시스템 프롬프트에 넣는 정보량이 워낙 방대하다 보니, 30B 급 모델들의 한정된 컨텍스트 처리 능력으로는 감당이 안 돼요. 지시사항을 제대로 파싱하지 못하고, 한국어로 응답하라는 기본적인 요구도 무시하거나, 있지도 않은 툴을 호출하는 할루시네이션이 빈번하게 발생했어요.

특히 한국어와 영어가 혼재된 프롬프트에서, 30B급 모델들은 언어 전환 처리를 제대로 못 했어요. 한국어로 질문해도 영어로 답하거나, 한국어 답변의 문맥이 완전히 붕괴되는 경우가 잦았어요.

전환점 - OpenClaw 대신 Pydantic AI로

OpenClaw의 풍부한 기능은 매력적이지만, 무거운 시스템 프롬프트가 소형 모델에서는 독이 된다는 결론을 내렸어요.

그래서 찾은 대안이 Pydantic AI 에이전트 프레임워크에요.

Pydantic AI는 Python의 Pydantic 라이브러리를 만든 팀이 개발한 에이전트 프레임워크인데, 핵심 철학이 "FastAPI 같은 느낌으로 GenAI 앱을 만들자" 에요. 주요 특징을 꼽으면:

• 극도로 가벼운 시스템 프롬프트: 필요한 지시와 툴 스키마만 최소한으로 주입
• 타입 세이프: Pydantic 모델 기반으로 입출력을 검증해서 런타임 에러 최소화
• 모델 어그노스틱: OpenAI, Anthropic, Google, Ollama, vLLM 등 거의 모든 모델/프로바이더 지원
• 커스텀 극한: 툴, 의존성 주입, 동적 시스템 프롬프트 등을 파이썬 코드로 세밀하게 제어 가능

다만 파이썬 코딩을 직접 해야 한다는 진입장벽이 있어요. OpenClaw처럼 설치하고 메신저 연결하면 바로 쓸 수 있는 턴키 솔루션은 아니에요. 하지만 그 덕분에 시스템 프롬프트를 원하는 대로 경량화할 수 있고, 불필요한 컨텍스트를 완전히 걷어낼 수 있어요.

Pydantic AI로 전환한 뒤, Qwen 3.0 모델에서 제법 쓸 만한 결과가 나오기 시작했어요. 시스템 프롬프트를 수백 토큰 수준으로 줄이고, 필요한 툴만 선별적으로 등록하니까 한국어 품질도 유지되고 지시 따르기도 괜찮았거든요.

그런데 Qwen 3.0도 툴 사용 능력이 부족했다

Pydantic AI + Qwen 3.0 조합으로 기본적인 대화와 간단한 작업은 가능했지만, 에이전트의 핵심인 툴 사용(Function Calling) 능력이 형편없었어요.

구체적으로:

• 툴 호출 시 JSON 인자 구조를 자주 틀림
• 복수 툴을 체이닝해야 하는 상황에서 중간에 멈추거나 엉뚱한 툴 호출
• 툴 결과를 받아서 다음 액션을 결정하는 ReAct 루프가 불안정

에이전트에서 툴 사용 능력은 타협할 수 없는 핵심 역량이에요. 아무리 한국어를 잘하고 시스템 프롬프트를 잘 따라도, 툴을 제대로 호출하지 못하면 "잘 말하는 무능력자"에 불과하니까요.

GPT-OSS 120B - 드디어 만난 쓸 만한 로컬 모델

결국 모델을 바꿔야 했어요. 그래서 올려본 게 OpenAI GPT-OSS 120B에요.

GPT-OSS 120B는 OpenAI가 Apache 2.0 라이선스로 공개한 오픈웨이트 모델이에요. 핵심 스펙은:

• 117B 파라미터, Mixture-of-Experts(MoE) 아키텍처
• 128개 전문가 중 4개만 활성화 → 포워드 패스당 실제 활성 파라미터는 5.1B
• MXFP4 네이티브 양자화 → 80GB GPU 하나에서도 구동 가능
• 체인 오브 쏘트(CoT) 추론 지원, 추론 노력(low/medium/high) 조절 가능
• 네이티브 툴 사용 지원: Function Calling, 브라우징, 코드 실행, Structured Output

MoE 구조 덕분에 총 파라미터는 120B이지만 실제 연산량은 5.1B 수준이라, DGX Spark의 128GB 통합 메모리에 올라가요. Ollama에서 ollama pull gpt-oss:120b로 간단히 받을 수도 있어요.

vLLM의 함정 - 툴 호출이 깨진다

GPT-OSS 120B를 처음에는 vLLM으로 서빙했어요. 그런데 치명적인 문제를 발견했어요. vLLM에서 OpenAI 호환 API로 tools 파라미터를 넘기면, 모델이 tool_calls 객체를 반환하지 않고 일반 텍스트 content에 JSON을 그냥 출력해 버려요.

예를 들어 get_weather 함수를 등록하고 "서울 날씨 알려줘"라고 물어보면, 정상적이라면 tool_calls 필드에 구조화된 함수 호출이 들어와야 하는데, vLLM에서는 이렇게 돼요:

{
  "content": "[{ \"name\": \"get_weather\", \"parameters\": { \"city\": \"Seoul\" } }]",
  "tool_calls": []  // 비어 있음!
}

모델 자체는 "이 함수를 호출해야겠다"고 판단하지만, vLLM의 파서가 GPT-OSS의 Harmony 포맷을 제대로 처리하지 못하는 거예요. vLLM GitHub에도 이 이슈가 올라와 있고, NVIDIA 포럼에서도 DGX Spark 사용자들 사이에서 반복적으로 보고되고 있어요. 에이전트에서 이건 완전한 쇼스토퍼예요. Pydantic AI가 tool_calls 객체를 기대하는데 빈 배열이 오니까, 아무 액션도 트리거되지 않거든요.

SGLang으로 전환 - 툴 호출이 살아났다

SGLang으로 바꾸니까 상황이 완전히 달라졌어요. SGLang은 GPT-OSS 전용 파서(--tool-call-parser gpt-oss, --reasoning-parser gpt-oss)를 제공하고 있어서, GPT-OSS의 Harmony 포맷을 네이티브로 파싱해요. 단일 툴 호출 기준으로는 tool_calls 필드에 정상적으로 구조화된 응답이 들어오고, Pydantic AI와의 연동도 매끄럽게 작동했어요.

docker run --gpus all --shm-size 32g -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --ipc=host lmsysorg/sglang:spark \
  python3 -m sglang.launch_server \
  --model-path openai/gpt-oss-120b \
  --host 0.0.0.0 --port 30000 \
  --reasoning-parser gpt-oss --tool-call-parser gpt-oss

공식 문서에도 code_interpreter, web_search_preview 같은 빌트인 도구 사용 예시가 정리돼 있고, MCP 서버 연동 가이드까지 있어요.

물론 SGLang도 완벽하지는 않아요. 멀티 펑션 콜(여러 함수를 한 번에 병렬 호출)에서는 여전히 불안정한 부분이 있고, <|call|> 스톱 토큰 처리 관련 이슈도 보고되고 있어요. 하지만 단일 툴 호출과 순차적 ReAct 루프에서는 vLLM과는 비교 자체가 안 될 정도로 안정적이에요.

성능 면에서도 차이가 있어요. NVIDIA 포럼의 벤치마크 스레드를 보면, DGX Spark에서 GPT-OSS 120B MXFP4를 돌릴 때 vLLM이 SGLang이나 llama.cpp보다 느리다는 보고가 여럿 올라와 있어요. vLLM이 GB10의 네이티브 FP4 텐서코어 커널을 제대로 활용하지 못하고 느린 폴백 경로를 타는 것으로 보여요.

정리하면:

Pydantic AI에서 SGLang의 OpenAI 호환 API(http://localhost:30000/v1)를 바로 연결할 수 있기 때문에, 프레임워크 전환도 매끄러웠어요.

테스트 결과

한국어 능력: 30B급 모델들과는 차원이 달라요. 한국어로 질문하면 자연스러운 한국어로 답변하고, 한국어-영어가 혼재된 지시에서도 컨텍스트를 잃지 않아요.

툴 사용 능력: SGLang의 gpt-oss 전용 파서 덕분에, Pydantic AI에서 등록한 커스텀 툴들을 정확한 JSON 스키마로 호출해요. 복수 스텝이 필요한 작업에서도 ReAct 루프가 안정적으로 돌아가고, 툴 결과를 바탕으로 다음 액션을 합리적으로 판단해요. vLLM에서는 불가능했던 것이 SGLang에서는 자연스럽게 작동하는 걸 보면, 추론 엔진 선택이 얼마나 중요한지 체감할 수 있었어요.

추론 속도: 데이터센터 GPU 대비 빠르다고는 할 수 없지만, 에이전트 용도에서는 "속도보다 정확성"이 중요하기 때문에 충분히 수용 가능한 수준이에요.

현재 구성과 앞으로의 계획

현재 운영 중인 구성을 정리하면 이래요.

아직 완성형은 아니에요. 계속 테스트하면서 최적의 설정을 찾아가는 중이에요. 특히:

• SGLang의 DGX Spark 최적화가 계속 진행 중이라, Blackwell SM121 네이티브 지원이 더 안정화되면 추가 속도 개선을 기대하고 있어요
• NVFP4 양자화 모델들이 더 나오면 메모리 효율을 극대화할 수 있을 것 같아요
• Pydantic AI의 MCP(Model Context Protocol) 연동으로 외부 서비스 통합도 확장해 볼 계획이에요

마무리 - 배운 것들

이번 실험을 통해 체감한 핵심 교훈을 정리해 볼게요.

1. 에이전트 프레임워크의 시스템 프롬프트 무게가 모델 선택을 결정해요.
OpenClaw처럼 풍부한 기능을 제공하는 프레임워크는 필연적으로 무거운 시스템 프롬프트를 생성하고, 이건 프론티어 모델이 아니면 감당하기 어려워요. 로컬 모델을 쓰려면 Pydantic AI처럼 경량 프레임워크로 직접 시스템 프롬프트를 설계하는 게 현실적이에요.

2. 30B급 모델은 에이전트 용도로는 아직 역부족이에요.
단순 대화에서는 괜찮을 수 있지만, 툴 호출과 다단계 추론이 필요한 에이전트 시나리오에서는 30B급 모델의 한계가 뚜렷해요. 특히 한국어 환경에서는 더 심해요.

3. MoE 모델이 로컬 에이전트의 답이 될 수 있어요.
GPT-OSS 120B처럼 총 파라미터는 크지만 활성 파라미터가 적은 MoE 모델은, 제한된 메모리 대역폭의 로컬 장비에서도 "큰 모델의 품질"을 얻을 수 있는 현실적인 방법이에요.

4. 추론 엔진 선택이 생각보다 큰 차이를 만들어요.
같은 모델, 같은 하드웨어에서도 vLLM, SGLang, Ollama 중 어느 것을 쓰느냐에 따라 체감 성능이 크게 달라져요. DGX Spark + GPT-OSS 조합에서는 SGLang이 LMSYS와 NVIDIA의 직접적인 최적화 덕분에 현재로서는 최선의 선택이에요.

5. DGX Spark(ZGX Nano)의 진가는 "큰 모델을 올릴 수 있다"는 것 자체에요.
속도는 느려요. 하지만 Mac Studio나 일반 데스크톱 GPU에서는 올릴 수조차 없는 100B급 모델을 로컬에서 돌릴 수 있다는 점이 가장 큰 가치예요. 프로토타이핑과 실험에는 이것만으로도 충분해요.

로컬 AI 에이전트의 시대는 아직 초기 단계이지만, 방향성은 분명해요. 더 효율적인 MoE 모델과 하드웨어 최적화가 계속 나오고 있으니까요.