[온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계] 1/14화: 온프레미스 AI 자체 호스팅, Qwen3을 선택한 6가지 이유

이 글은 「온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계」 시리즈 1일차로, 온프레미스 AI 환경을 직접 구축하기 위해 Qwen3을 선택한 이유와 설계 출발점을 다룹니다.

시리즈를 시작하며

2026년 현재, 대형 언어 모델(Large Language Model, LLM)을 업무에 도입하지 않는 조직을 찾기 어렵습니다. 그러나 대부분의 팀이 클라우드 API 호출에 의존하고 있고, “우리 서버에서 직접 돌리겠다”는 온프레미스(On-premises) 선택지는 여전히 소수의 영역으로 남아 있습니다.

이 시리즈는 그 소수의 선택지를 실제로 구축 가능한 수준까지 풀어냅니다. 모델은 Qwen3과 Qwen3-VL로 고정합니다. ‘어떤 모델을 쓸까’ 같은 추상적 비교가 아니라, “이 모델을 Mac Studio(MLX)와 NVIDIA GPU(vLLM) 위에서 어떻게 서빙하고, 통합하고, 운영하는가”에만 집중합니다.

14일 동안 매일 한 편씩, 개관에서 레퍼런스 아키텍처 완성까지 달립니다. 최종 목표는 명확합니다. 14일째에 독자가 Qwen3 기반 온프레미스 AI Assistant의 전체 아키텍처를 직접 설계·구축할 수 있는 것.

오늘의 핵심 3가지

• 클라우드 API vs 온프레미스 — 데이터 주권·규제·비용·지연 네 축으로 트레이드오프를 정리합니다.
• Qwen3 선정 6대 이유 — Apache 2.0 라이선스, 한국어 지원, 사이즈 스펙트럼, 서빙 생태계, LLM/VLM 통합 패밀리, Thinking 모드까지.
• 전체 레이어 지도 — 하드웨어부터 에이전트까지, 14일간 다룰 아키텍처 스택을 한 장 다이어그램으로 조감합니다.

왜 온프레미스 AI인가 — 클라우드 API의 세 가지 벽

클라우드 LLM API는 빠르게 시작할 수 있다는 장점이 있습니다. 키 하나 발급받으면 5분 안에 첫 응답을 볼 수 있으니까요. 하지만 프로덕션으로 올라가면 세 가지 벽에 부딪힙니다.

벽 1: 데이터가 외부로 나간다

클라우드 API를 호출하면, 프롬프트에 담긴 데이터가 외부 서버로 전송됩니다. 사내 문서, 고객 정보, 금융 거래 내역 — 이런 데이터가 조직 경계 밖으로 나가는 순간, 데이터 주권(Data Sovereignty) 문제가 발생합니다.

특히 금융권에서는 이것이 치명적입니다. 한 금융사 담당자의 말을 빌리면, “API 호출 한 번에 들어가는 프롬프트가 내부 감사 대상 문서를 포함하는 순간, 그 API 공급자도 데이터 처리자(Processor)로 등록해야 한다”는 겁니다. 처리자 등록은 계약, 감사, 규제 보고의 연쇄 반응을 일으킵니다.

벽 2: 비용이 사용량에 비례한다

클라우드 API의 과금 구조는 토큰(token) 단위입니다. 소규모 PoC(Proof of Concept)에서는 월 수십 달러로 끝나지만, 조직 전체가 하루 수만 건의 요청을 보내기 시작하면 이야기가 달라집니다. 월 수천 달러에서 수만 달러까지 올라가는 것은 흔한 일입니다.

온프레미스는 초기 하드웨어 투자가 크지만, 일정 사용량을 넘으면 토큰당 비용(cost per token)이 급격히 낮아지는 구조입니다. GPU를 24시간 가동하더라도 전기료와 감가상각비만 들기 때문입니다.

벽 3: 지연(Latency)을 통제할 수 없다

클라우드 API의 응답 지연은 네트워크 경로, 서버 부하, 리전(region) 위치에 따라 달라집니다. 한국에서 미국 서부의 API 서버를 호출하면, 네트워크 왕복만 최소 100~200ms가 추가됩니다. 여기에 큐 대기, 추론 시간까지 더하면 첫 토큰까지(TTFT, Time To First Token) 1~3초는 기본입니다.

온프레미스에서는 같은 네트워크 안에서 추론하므로, 네트워크 지연을 1ms 미만으로 줄일 수 있습니다. 실시간 대화형 인터페이스나 저지연이 필수인 업무 자동화에서 이 차이는 결정적입니다.

클라우드 vs 온프레미스 트레이드오프 비교표

감으로 판단하지 말고, 항목별로 냉정하게 비교해 봅시다.

비교 항목	클라우드 API	온프레미스 (자체 호스팅)
데이터 주권	데이터가 외부 서버로 전송됨. 공급자의 데이터 처리 정책에 종속. 리전 선택 가능하나 물리 서버 위치 미보장	데이터가 조직 경계 내에 잔류. 물리 서버 위치를 직접 통제. 데이터 처리자 등록 불필요
규제 대응	외부 위탁 계약, 제3자 감사 대응 필요. 금융권 망분리 환경에서 사용 제한적	내부 시스템으로 분류 가능. 망분리 환경 내 배치 가능. 감사 로그 직접 관리
초기 비용	거의 0 (API 키 발급만으로 시작)	GPU 서버 또는 Mac Studio 구매 필요 (수백만~수천만 원)
운영 비용 (대규모)	토큰 비례 과금. 일 1만 건 이상이면 월 수천~수만 달러	전기료 + 감가상각. 일정 사용량 초과 시 토큰당 비용이 클라우드 대비 1/5~1/10
손익 분기점	조직 규모·사용량에 따라 다르나, 일반적으로 일 5,000~10,000건 요청 수준에서 온프레미스가 유리해지기 시작 (14B 모델, NVIDIA A6000 48GB 기준 시산)
지연 (TTFT)	네트워크 왕복 100~200ms + 서버 큐 대기. 일반적으로 0.5~3초	로컬 네트워크 <1ms. 하드웨어 성능에만 의존. 일반적으로 0.1~0.8초
모델 선택 자유도	공급자가 제공하는 모델만 사용 가능. 파인튜닝 제한적	오픈 웨이트 모델 자유 선택. 파인튜닝, 양자화, 커스텀 서빙 가능
가용성	공급자 SLA에 의존. 장애 시 대응 불가	자체 HA(고가용성) 구성 필요. 장애 대응 팀 운영 부담
최신 모델 접근	공급자의 최신 모델 즉시 사용 가능	오픈소스 릴리스 주기에 의존. 최신 프로프라이어터리 모델은 사용 불가
운영 복잡도	낮음 (API 호출만)	높음 (GPU 관리, 모델 업데이트, 모니터링, 장애 대응)

이 표에서 핵심은 데이터 주권·규제와 비용·지연 두 축입니다. 데이터가 외부로 나가면 안 되거나, 사용량이 일정 수준을 넘으면, 온프레미스가 합리적 선택이 됩니다. 둘 다 해당하면 사실상 온프레미스가 필수입니다.

왜 Qwen3인가 — 6대 선정 이유

온프레미스를 결정했다면, 다음 질문은 “어떤 모델을 올릴 것인가”입니다. 2026년 6월 현재, 오픈 웨이트 LLM 시장에는 Llama, Mistral, Gemma, DeepSeek, Qwen 등 수십 개의 선택지가 있습니다. 이 시리즈가 Qwen3을 고정 모델로 선택한 이유를 여섯 가지로 정리합니다.

이유 1: Apache 2.0 라이선스 — 상업 사용 완전 자유

Qwen3 전 사이즈가 Apache 2.0 라이선스로 배포됩니다. 이는 다음을 의미합니다.

• 상업적 사용에 어떤 제한도 없음
• 수정·재배포 자유
• 사용량 보고, 등록, 사용자 수 제한 없음
• 파생 모델(파인튜닝 결과물) 배포 시에도 동일 라이선스 강제 없음

Llama 시리즈의 Meta Community License는 월간 활성 사용자(MAU) 7억 명 이상 시 별도 협의가 필요하고, 출력물에 대한 제한 조항이 존재합니다. Mistral의 일부 모델은 상업 라이선스가 별도입니다. Qwen3의 Apache 2.0은 이런 부담이 전혀 없습니다.

금융권이나 대기업에서 법무팀 검토 없이 도입할 수 있는 모델이 생각보다 많지 않습니다. Apache 2.0은 법무팀이 가장 편하게 승인하는 라이선스 중 하나입니다.

이유 2: 한국어 포함 다국어 지원

Qwen3는 119개 언어와 방언을 지원하며, 한국어가 명시적으로 포함되어 있습니다. 학습 데이터에 한국어 코퍼스가 충분히 포함되어 있어, 한국어 지시(instruction) 이해, 한국어 생성, 한국어-영어 코드스위칭 모두에서 안정적인 성능을 보여줍니다.

이것이 중요한 이유는, 오픈 웨이트 모델 중 영어 성능은 우수하지만 한국어에서 급격히 품질이 떨어지는 모델이 적지 않기 때문입니다. 사내 AI Assistant를 구축할 때, 사용자의 질문은 한국어고 참조 문서도 한국어인 환경에서, 모델의 한국어 능력은 선택이 아닌 필수입니다.

이유 3: 1.7B부터 235B까지 — 사이즈 스펙트럼

Qwen3는 동일 아키텍처 패밀리 안에서 7단계 사이즈를 제공합니다.

모델	파라미터	구조	대표 용도
Qwen3-1.7B	1.7B	Dense	분류, 키워드 추출, 임베딩 전처리
Qwen3-4B	4B	Dense	경량 라우팅, 인텐트 분류
Qwen3-8B	8B	Dense	라우팅 판단, 간단한 Q&A, 요약
Qwen3-14B	14B	Dense	일반 대화, RAG 생성기
Qwen3-30B-A3B	30B (활성 3B)	MoE	메인 생성 모델, 대화·분석
Qwen3-32B	32B	Dense	고품질 생성, 코딩, 추론
Qwen3-235B-A22B	235B (활성 22B)	MoE	최고 성능, 복잡 추론, 전문 분석

이 스펙트럼이 온프레미스 아키텍처에서 의미하는 바는 명확합니다. “한 패밀리 안에서 역할별로 다른 사이즈를 배치할 수 있다”는 것입니다.

예를 들어, 사용자 요청이 들어오면 Qwen3-4B가 인텐트를 분류하고, 단순 질문은 Qwen3-14B가 처리하고, 복잡한 분석은 Qwen3-32B로 라우팅하는 구조를 모두 같은 패밀리의 모델로 구성할 수 있습니다. 토크나이저(tokenizer)가 동일하므로, 프롬프트 호환성 문제가 없고, 모델 간 전환 비용이 최소화됩니다.

이유 4: vLLM과 MLX 생태계 — 듀얼 서빙 스택

Qwen3는 현재 가장 성숙한 두 개의 로컬 추론 엔진에서 1급 지원(first-class support)을 받습니다.

• vLLM (NVIDIA CUDA): PagedAttention 기반 연속 배치(continuous batching), FP8/AWQ 양자화, 텐서 병렬(tensor parallelism) 지원. NVIDIA GPU에서 최고 처리량을 뽑아내는 산업 표준 엔진.
• mlx-lm (Apple Silicon MLX): Apple의 통합 메모리(Unified Memory) 아키텍처를 활용한 Metal 가속 추론. Mac Studio의 대용량 메모리(최대 512GB)로 대형 모델을 양자화 없이 적재 가능.

두 엔진 모두 Qwen3를 공식 지원하며, OpenAI 호환 API 엔드포인트를 기본 제공합니다. 즉, 같은 클라이언트 코드로 vLLM 서버와 MLX 서버를 전환할 수 있습니다.

이것은 6회차에서 다룰 하이브리드 게이트웨이 아키텍처의 기반이 됩니다. Mac Studio와 NVIDIA GPU 서버를 동시에 운영하면서, 워크로드 특성에 따라 요청을 분산하는 구조입니다.

이유 5: LLM과 VLM이 같은 패밀리

Qwen3의 텍스트 모델(Qwen3)과 비전-언어 모델(Qwen3-VL)은 같은 패밀리입니다. 이것이 아키텍처 설계에서 갖는 의미는 큽니다.

• Qwen3-VL 8B: 문서 이미지, 차트, UI 스크린샷 이해. Visual Agent(시각 기반 에이전트), Visual Coding(코드 생성 시 화면 참조) 지원.
• Qwen3-VL 30B-A3B: MoE 구조로 활성 파라미터 3B만 사용하면서 30B급 성능. 복잡한 문서 분석, 다중 이미지 비교.

텍스트 LLM과 비전 VLM이 같은 패밀리라는 것은, 시스템 프롬프트·대화 템플릿·도구 사용 규격이 호환된다는 뜻입니다. 텍스트 전용 파이프라인에 이미지 입력을 추가할 때, 모델을 통째로 바꾸는 것이 아니라 같은 아키텍처의 VL 변형으로 확장하면 됩니다.

금융권에서 이것이 특히 유용한 사례가 있습니다. 고객이 보험 청구서 스캔본을 업로드하면 Qwen3-VL이 문서를 읽고, 추출된 정보를 Qwen3 텍스트 모델이 심사 규칙에 맞춰 판단하는 파이프라인. 같은 패밀리이므로 중간 표현의 불일치 없이 매끄럽게 연결됩니다.

이유 6: Thinking 모드 — 추론 체인 내장

Qwen3는 Instruct 에디션과 Thinking 에디션을 구분합니다.

• Instruct: 일반적인 지시 따르기. 빠른 응답, 낮은 지연.
• Thinking: 응답 전에 추론 토큰(reasoning token)을 생성하여 단계별 사고 과정을 거침. 수학, 코딩, 복잡한 분석에서 정확도 향상.

Thinking 모드는 추론 토큰이 추가로 생성되므로 지연과 비용이 증가하지만, “언제 Thinking 모드를 켜고 끌 것인가”를 시스템이 자동으로 판단하는 아키텍처를 설계할 수 있습니다. 단순 인사말에는 Instruct, 복잡한 계산에는 Thinking — 이 라우팅 자체를 경량 Qwen3(4B/8B)가 판단하는 구조입니다.

이 내용은 2일차(모델 변형 결정)와 8일차(Thinking 모드 운영)에서 깊이 다룹니다.

Qwen3 패밀리 한눈에 보기

Qwen3 패밀리의 구조를 한 번 정리하고 넘어갑시다. 아래 다이어그램은 사이즈별 모델과 에디션, 양자화 포맷, 서빙 엔진의 관계를 보여줍니다.

graph TD
    subgraph "Qwen3 패밀리"
        direction TB
        Q1["Qwen3-1.7B"] --> Dense
        Q4["Qwen3-4B"] --> Dense
        Q8["Qwen3-8B"] --> Dense
        Q14["Qwen3-14B"] --> Dense
        Q30["Qwen3-30B-A3B"] --> MoE
        Q32["Qwen3-32B"] --> Dense
        Q235["Qwen3-235B-A22B"] --> MoE
    end

    subgraph "Qwen3-VL 패밀리"
        VL8["Qwen3-VL-8B"] --> Dense
        VL30["Qwen3-VL-30B-A3B"] --> MoE
    end

    subgraph "에디션"
        Dense --> Instruct
        Dense --> Thinking
        MoE --> Instruct
        MoE --> Thinking
    end

    subgraph "양자화 포맷"
        Instruct --> FP8["FP8 (CUDA)"]
        Instruct --> AWQ["AWQ (CUDA)"]
        Instruct --> GGUF["GGUF (CPU/GPU)"]
        Instruct --> MLXQ["MLX 4bit/8bit"]
        Thinking --> FP8
        Thinking --> AWQ
        Thinking --> GGUF
        Thinking --> MLXQ
    end

    subgraph "서빙 엔진"
        FP8 --> vLLM["vLLM (NVIDIA CUDA)"]
        AWQ --> vLLM
        GGUF --> Ollama["Ollama / llama.cpp"]
        MLXQ --> mlx["mlx-lm (Apple Silicon)"]
    end

Dense vs MoE — 무엇이 다른가

Qwen3 라인업에는 두 가지 아키텍처가 공존합니다.

• Dense(밀집): 모든 파라미터가 매 추론마다 활성화됩니다. Qwen3-8B Dense 모델은 추론 시 8B 파라미터 전체를 사용합니다. 구조가 단순하고 예측 가능한 메모리·지연 특성을 가집니다.
• MoE(Mixture of Experts, 전문가 혼합): 전체 파라미터 중 일부 전문가(expert)만 활성화됩니다. Qwen3-30B-A3B는 총 30B 파라미터를 갖지만, 한 번의 추론에서 활성화되는 파라미터는 약 3B입니다. 이 구조 덕분에 30B급 품질을 3B급 연산 비용으로 얻을 수 있습니다.

MoE의 함정은 메모리입니다. 활성 파라미터가 3B이더라도, 모델 가중치 전체(30B)는 메모리에 적재되어야 합니다. 연산은 가볍지만 메모리는 무겁습니다. 이 특성이 하드웨어 선택에 직접적인 영향을 미치며, 3일차에서 상세히 다룹니다.

양자화 포맷 비교

온프레미스 서빙에서 양자화(Quantization)는 선택이 아닌 필수입니다. 모든 모델을 FP16(반정밀도 부동소수점)으로 올리려면 천문학적인 VRAM이 필요하기 때문입니다. Qwen3가 지원하는 주요 양자화 포맷을 비교합니다.

포맷	비트 수	플랫폼	메모리 절감	품질 손실	비고
FP16	16bit	CUDA	기준 (1×)	없음	기준선. VRAM 2× 소모
FP8	8bit	CUDA (Hopper+)	~50%	무시 가능	H100/H200/L40S 권장. NVIDIA FP8 하드웨어 지원
AWQ	4bit	CUDA	~75%	미미 (1~2%)	가중치만 양자화. 활성화는 FP16 유지
GGUF	2~8bit	CPU / GPU 혼합	가변	비트 수에 비례	llama.cpp/Ollama. CPU 오프로드 가능
MLX	4/8bit	Apple Silicon	~75% / ~50%	미미~소	통합 메모리 활용. Metal 가속

어떤 포맷을 어느 하드웨어에 올릴지는 2~3일차에서 결정 트리로 정리합니다. 오늘은 “Qwen3가 이 모든 포맷을 공식 지원한다”는 점만 기억하면 됩니다.

온프레미스 AI Assistant — 전체 레이어 지도

이 시리즈에서 14일간 구축할 시스템의 전체 아키텍처 레이어를 한 장으로 조감합니다. 각 레이어가 몇 일차에 해당하는지 함께 표시합니다.

graph TB
    subgraph "Layer 7: 에이전트 & 안전 (12~14일차)"
        Agent["에이전트 오케스트레이션\nReAct · Plan-Execute\n멀티에이전트 라우팅"]
        Safety["가드레일 · 평가\n환각 억제 · PII 마스킹\n감사 로그"]
    end

    subgraph "Layer 6: 도구 & 액션 (12일차)"
        Tools["Function Calling\nMCP 사내 시스템 연동\n툴 권한 · 안전장치"]
    end

    subgraph "Layer 5: 메모리 (11일차)"
        Memory["세션 관리\n단기 메모리 (요약 버퍼)\n장기 메모리 (영속 저장)"]
    end

    subgraph "Layer 4: 지식 (9~10일차)"
        RAG["RAG 파이프라인\nbge-m3 임베딩 · Qdrant\nGraph RAG · 멀티모달 RAG"]
    end

    subgraph "Layer 3: 컨텍스트 (8일차)"
        Prompt["프롬프트 엔지니어링\n시스템 프롬프트 계층화\n컨텍스트 조립 · 압축"]
    end

    subgraph "Layer 2: 서빙 (4~7일차)"
        Serving["추론 엔진\nvLLM (CUDA) · mlx-lm (MLX)\n게이트웨이 · 로드밸런싱\nQwen3-VL 멀티모달 서빙"]
    end

    subgraph "Layer 1: 하드웨어 & 모델 (2~3일차)"
        HW["Mac Studio (Apple Silicon)\nNVIDIA GPU (CUDA)\n모델 선택 · 양자화 · 배치"]
    end

    subgraph "Layer 0: 설계 원칙 (1일차 = 오늘)"
        Principle["온프레미스 동기\n모델 선정 근거\n전체 아키텍처 조감"]
    end

    Agent --> Tools
    Safety --> Tools
    Tools --> Memory
    Memory --> RAG
    RAG --> Prompt
    Prompt --> Serving
    Serving --> HW
    HW --> Principle

이 다이어그램에서 주목할 점은 아래에서 위로 쌓아가는 구조입니다. 오늘(1일차)은 가장 아래의 설계 원칙 레이어입니다. 내일부터 모델 선택, 하드웨어, 서빙 엔진을 거쳐, 최종적으로 에이전트와 안전 레이어까지 올라갑니다.

각 레이어는 아래 레이어에 의존합니다. 서빙 엔진(Layer 2)이 안정적이지 않으면 RAG(Layer 4)도 신뢰할 수 없고, 컨텍스트 조립(Layer 3)이 부실하면 에이전트(Layer 7)의 판단도 부실해집니다. 이 시리즈가 모델·하드웨어부터 시작하는 이유입니다.

금융IT 관점에서 본 온프레미스의 의미

이 시리즈 전체에서 금융IT·규제 산업의 관점을 수시로 녹여냅니다. 1일차에서는 온프레미스 선택이 금융 환경에서 갖는 의미를 짚고 넘어갑니다.

망분리 환경과 AI

한국의 금융권은 망분리 규정을 적용합니다. 업무망(내부)과 인터넷망(외부)이 물리적 또는 논리적으로 분리되어, 업무망에서 외부 인터넷 API를 직접 호출하는 것이 원칙적으로 불가능합니다.

클라우드 LLM API는 인터넷을 통해야 합니다. 업무망 내 데이터로 LLM을 활용하려면, 데이터를 인터넷망으로 옮기거나(규제 위반 소지), 중간에 DMZ를 두고 프록시하거나(아키텍처 복잡도 급증), 아예 업무망 안에 LLM을 설치하는 것이 가장 단순한 해법입니다.

온프레미스 Qwen3는 이 맥락에서 의미가 있습니다. Apache 2.0 라이선스이므로 내부 배포에 법적 장벽이 없고, 네트워크 연결 없이 독립 구동되므로 망분리 요건을 자연스럽게 충족합니다.

데이터 잔존과 감사

금융 규제에서는 데이터 잔존(data residency)이 핵심 이슈입니다. 고객 데이터가 어디에 저장되고, 누가 접근했으며, 언제 삭제되었는지를 추적해야 합니다.

클라우드 API를 사용하면, API 제공자의 서버에 프롬프트 데이터가 일시적으로라도 존재하게 됩니다. 대부분의 공급자가 “학습에 사용하지 않는다”고 약속하지만, 물리적으로 데이터가 외부에 존재한 이력 자체가 감사 포인트가 될 수 있습니다.

온프레미스에서는 모든 데이터가 자체 서버 내에서 처리되고, 로그도 자체 시스템에 남습니다. 감사 대응이 단순해집니다. 13일차에서 감사 로그 설계를 상세히 다룹니다.

비용 구조의 차이

금융권에서 클라우드 LLM API 비용을 논의할 때 자주 간과되는 점이 있습니다. 변동 비용(variable cost)은 예산 승인이 어렵다는 것입니다.

GPU 서버를 구매하면 자본적 지출(CAPEX)로 처리됩니다. 한 번 승인받으면 감가상각 기간 동안 추가 비용 없이 사용할 수 있습니다. 반면 API 사용료는 운영적 지출(OPEX)로, 매달 예측 불확실한 비용이 발생합니다. 사용량이 급증하는 달에는 예산을 초과할 수 있고, 이를 통제하려면 사용량 제한이 필요합니다. 사용량 제한은 곧 서비스 품질 저하를 의미합니다.

NVIDIA A6000 48GB GPU 기준으로, Qwen3-14B를 FP8로 서빙하면 단일 GPU로 초당 약 30~50 토큰(입력 프롬프트 2,048 토큰, 배치 사이즈 1 기준, vLLM 0.8.x 측정)의 생성 속도를 낼 수 있습니다. 이 GPU의 가격은 약 500~600만 원. 하루 10시간, 월 22일 가동 시 월 전기료는 약 3~5만 원입니다. 감가상각 3년을 잡으면 월 약 15~17만 원. 총 월 운영비 약 20만 원으로, 하루 수천 건의 요청을 처리할 수 있습니다.

같은 사용량을 클라우드 API로 처리하면? 입출력 토큰 비용을 합산하면 월 100만 원을 넘기는 것이 어렵지 않습니다. 물론 정확한 비교는 사용 패턴에 따라 크게 달라지므로 수치를 절대화하면 안 됩니다. 다만, 일정 사용량을 넘으면 온프레미스의 경제성이 확보된다는 구조적 사실은 변하지 않습니다.

14일 시리즈 로드맵

앞으로 13일간 어떤 주제를 다루는지, 한눈에 봅시다.

단계	일차	주제	핵심 산출물
Phase A 개관·모델·HW	1	아키텍처 개관 — 왜 Qwen3인가 (오늘)	트레이드오프 표, 레이어 지도
	2	Qwen3 모델 변형 결정 트리	Dense vs MoE, 사이즈별 배치 표, 양자화 비교
	3	하드웨어 분기 — Mac Studio vs CUDA	메모리 대역폭 매트릭스, 노드 매핑
Phase B 서빙	4	mlx-lm으로 Qwen3 서빙 (핸즈온)	동작하는 MLX 서빙 코드
	5	vLLM으로 Qwen3 서빙 (핸즈온)	동작하는 vLLM 설정·운영 패턴
	6	하이브리드 게이트웨이	LiteLLM 기반 통합 라우팅
	7	Qwen3-VL 멀티모달 서빙	이미지 이해 파이프라인
Phase C 컨텍스트·지식·메모리	8	프롬프트 엔지니어링 & Thinking 모드	chat template, 컨텍스트 조립기
	9	로컬 RAG 스택 (핸즈온)	bge-m3 + Qdrant + Qwen3
	10	고급 RAG — Graph RAG & 멀티모달	지식 그래프, Qwen3-VL RAG
	11	메모리 아키텍처	세션·단기·장기 메모리 스키마
Phase D 에이전트·안전·종합	12	도구 사용 & 에이전트 (핸즈온)	MCP 연동, ReAct 구현
	13	가드레일·평가·관측	안전장치, 평가 파이프라인
	14	레퍼런스 아키텍처 종합 (핸즈온)	전체 아키텍처 다이어그램 + 체크리스트

4·5·9·12·14일차는 핸즈온 클라이맥스입니다. 설명에 그치지 않고, GitHub 저장소에 올려도 동작하는 수준의 완성된 설정·코드를 제공합니다. 14일차에는 13일치를 한 장 다이어그램으로 압축한 레퍼런스 아키텍처와 단계별 구축 체크리스트로 시리즈를 마무리합니다.

첫 번째 핸즈온: Qwen3 로컬 실행 확인

시리즈 첫 날이니, 가볍게 시작합니다. Qwen3를 로컬에서 실행할 수 있는지 확인만 해봅시다. 본격적인 서빙 구성은 4~5일차에서 다루고, 오늘은 “동작하는지 확인”에 집중합니다.

방법 1: Ollama로 빠르게 확인 (모든 OS)

가장 간단한 방법입니다. Ollama는 GGUF 포맷의 모델을 자동 다운로드하고 서빙합니다.

# Ollama 설치 (https://ollama.com)
# 설치 후 터미널에서:

# Qwen3-8B 모델 다운로드 및 실행
ollama run qwen3:8b

# 대화 프롬프트가 뜨면 한국어로 테스트
# >>> 한국어로 자기소개를 해줘.

Ollama는 GGUF 4bit 양자화를 기본으로 사용합니다. Qwen3-8B의 4bit GGUF는 약 5~6GB 메모리를 사용하므로, 16GB RAM 이상의 노트북에서도 구동됩니다.

방법 2: mlx-lm으로 Apple Silicon 확인 (macOS)

Mac을 사용 중이라면, mlx-lm으로 Apple Silicon의 Metal 가속을 확인할 수 있습니다.

# mlx-lm 설치
pip install mlx-lm

# Qwen3-8B MLX 4bit 양자화 모델로 테스트 생성
python -m mlx_lm.generate \
  --model mlx-community/Qwen3-8B-4bit \
  --prompt "한국의 온프레미스 AI 도입 현황을 분석해줘." \
  --max-tokens 512

# OpenAI 호환 서버 모드로 실행 (4일차에서 상세히 다룸)
python -m mlx_lm.server \
  --model mlx-community/Qwen3-8B-4bit \
  --port 8080

mlx-lm 서버가 뜨면 http://localhost:8080/v1/chat/completions로 OpenAI 호환 API를 사용할 수 있습니다. 이것이 4일차 MLX 서빙의 기초입니다.

방법 3: vLLM으로 NVIDIA GPU 확인 (Linux/WSL)

NVIDIA GPU가 있다면, vLLM으로 확인합니다.

# vLLM 설치 (CUDA 12.4+ 필요)
pip install vllm

# Qwen3-8B 서빙 (FP16, 단일 GPU)
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-8B \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 4096

# 다른 터미널에서 테스트
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-8B",
    "messages": [
      {"role": "user", "content": "온프레미스 AI의 장점 3가지를 설명해줘."}
    ],
    "max_tokens": 512
  }'

Qwen3-8B FP16은 약 16~17GB VRAM을 사용합니다. NVIDIA RTX 4090(24GB) 이상이면 여유 있게 올릴 수 있습니다. 24GB 미만이라면 AWQ 4bit 양자화 모델(Qwen/Qwen3-8B-AWQ)을 사용하면 약 5~6GB VRAM으로 줄일 수 있습니다.

동작 확인 스크립트 (Python)

위 세 방법 중 하나로 서버를 띄운 뒤, 아래 Python 스크립트로 정상 동작을 확인합니다. OpenAI 호환 API를 사용하므로, 어떤 서빙 엔진을 쓰든 같은 코드로 테스트할 수 있습니다.

"""Qwen3 로컬 서빙 동작 확인 스크립트"""
import json
import urllib.request

# 서빙 엔진에 맞춰 URL과 모델명 수정
BASE_URL = "http://localhost:8000"  # vLLM: 8000, mlx-lm: 8080, Ollama: 11434
MODEL_NAME = "Qwen/Qwen3-8B"       # Ollama: "qwen3:8b"

def check_health() -> bool:
    """서버 헬스 체크"""
    try:
        req = urllib.request.Request(f"{BASE_URL}/v1/models")
        with urllib.request.urlopen(req, timeout=5) as resp:
            data = json.loads(resp.read().decode("utf-8"))
            models = [m["id"] for m in data.get("data", [])]
            print(f"[OK] 사용 가능한 모델: {models}")
            return True
    except Exception as e:
        print(f"[FAIL] 서버 연결 실패: {e}")
        return False

def test_completion() -> None:
    """한국어 생성 테스트"""
    payload = json.dumps({
        "model": MODEL_NAME,
        "messages": [
            {"role": "system", "content": "당신은 IT 기술 블로그 작가입니다."},
            {"role": "user", "content": "온프레미스 AI의 핵심 장점을 한 문장으로 요약해줘."}
        ],
        "max_tokens": 128,
        "temperature": 0.7
    }).encode("utf-8")

    req = urllib.request.Request(
        f"{BASE_URL}/v1/chat/completions",
        data=payload,
        headers={"Content-Type": "application/json"}
    )

    with urllib.request.urlopen(req, timeout=30) as resp:
        result = json.loads(resp.read().decode("utf-8"))
        content = result["choices"][0]["message"]["content"]
        usage = result.get("usage", {})
        print(f"\n[응답] {content}")
        print(f"[토큰] prompt={usage.get('prompt_tokens', '?')}, "
              f"completion={usage.get('completion_tokens', '?')}")

if __name__ == "__main__":
    if check_health():
        test_completion()
    else:
        print("서버를 먼저 시작하세요.")

이 스크립트는 의도적으로 requests나 openai 같은 외부 패키지 없이, Python 표준 라이브러리만으로 작성했습니다. 어떤 환경에서든 python check_qwen3.py만으로 실행할 수 있습니다.

운영 함정 (Pitfall) 미니 코너

함정: “일단 가장 큰 모델을 올리자” 증후군

온프레미스 AI를 처음 구축할 때 가장 흔한 실수는 “보유한 GPU에 올릴 수 있는 가장 큰 모델을 올리는 것”입니다.

예를 들어, RTX 4090(24GB VRAM)이 있으니 Qwen3-14B AWQ(약 9GB)를 올릴 수 있고, 품질이 더 좋을 테니 14B를 선택하자 — 이 판단이 틀린 것은 아닙니다. 하지만 놓치는 것이 있습니다.

KV 캐시 메모리입니다. 모델 가중치만 올리면 끝이 아닙니다. 추론 중에 생성되는 Key-Value 캐시가 추가 VRAM을 차지합니다. 컨텍스트 길이가 길어지고 동시 요청이 늘어나면, KV 캐시가 남은 VRAM을 모두 소모하여 OOM(Out of Memory) 에러가 발생합니다.

24GB VRAM에 14B AWQ 모델(~9GB)을 올리면, KV 캐시에 쓸 수 있는 메모리는 약 15GB. 이론상 충분해 보이지만, vLLM의 연속 배치에서 동시 요청 4~8개가 쌓이면 KV 캐시가 급격히 증가합니다. 결과적으로 동시성이 2~3개로 제한되거나, max-model-len을 짧게 잡아야 합니다.

반면, 같은 GPU에 8B AWQ(~5GB)를 올리면 KV 캐시에 19GB를 할당할 수 있어, 동시 요청 8~16개를 안정적으로 처리할 수 있습니다.

교훈: 모델 사이즈를 결정할 때는 가중치 메모리 + KV 캐시 + 시스템 오버헤드를 합산하고, 목표 동시성(concurrent requests)을 기준으로 역산하세요. 가장 큰 모델이 아니라, 목표 동시성을 달성하는 가장 큰 모델이 정답입니다. 이 계산법은 5일차(vLLM 서빙)에서 구체적인 수식과 함께 다룹니다.

정리 — 1일차의 세 줄 요약

• 온프레미스는 데이터 주권·규제·비용 세 축에서 클라우드 API의 대안이 됩니다. 특히 금융·규제 산업에서는 사실상 필수입니다.
• Qwen3는 Apache 2.0 라이선스, 한국어 지원, 사이즈 스펙트럼, 듀얼 서빙 생태계, LLM/VLM 통합, Thinking 모드의 6가지 이유로 온프레미스 기준 모델에 적합합니다.
• 14일간 하드웨어·서빙·지식·에이전트까지 7개 레이어를 쌓아 올려 레퍼런스 아키텍처를 완성합니다.

내일 예고

2일차: Qwen3 모델 변형 결정 트리 — Dense vs MoE, Instruct vs Thinking, 사이즈별 어디에 배치할 것인가. 양자화 포맷 비교표(FP8/AWQ/GGUF/MLX × 메모리·속도·정확도·플랫폼)와 함께, “어떤 변형을 어떤 역할에 붙일지”를 결정 트리로 정리합니다.

---