클라우드 API vs 로컬 LLM: 망 분리·비용·프라이버시로 정하는 배치 기준

엔터프라이즈 아키텍처

클라우드 API vs 로컬 LLM: 망 분리·비용·프라이버시로 정하는 배치 기준

AI아키텍트 2026. 7. 30. 14:11

AI Agent를 처음 만들 때 대부분은 클라우드 LLM API로 시작합니다. 키를 발급받고, SDK를 붙이고, 프롬프트를 넣으면 최신 모델이 응답합니다. 서버도, GPU도, 모델 파일도 필요 없습니다.

그런데 그 시스템을 실제 조직에 넣으려는 순간, 기술과는 무관한 질문이 먼저 들어옵니다.

회의 녹취록과 계약서 초안이 외부 API로 나가도 되는가?
인터넷이 차단된 망분리 (Air-gap) 구간에서도 같은 기능이 동작해야 하는가?
트래픽이 늘면 월 API 비용이 예측 가능한 수준으로 유지되는가?
특정 국가·산업 규제상 데이터가 국경을 넘어도 되는가?

이 질문들의 답은 모델 품질 벤치마크로 결정되지 않습니다. 데이터 주권 (Data Sovereignty), 규제, 망분리 요구, 개인정보·기밀, 지연 (Latency), 처리량 (Throughput), 총소유비용 (TCO, Total Cost of Ownership)이 함께 결정합니다.

이 글은 "클라우드 API와 로컬 오픈 웨이트 모델 (Open-Weight Model)을 언제, 어느 워크로드에, 어떤 크기로 배치할 것인가" 라는 배치·선택 (Deployment & Selection) 의사결정을 다룹니다. 필자는 오픈 웨이트 모델인 Gemma (버전 3·4) 와 Qwen 을 상용 운영 (Production) 환경에서 함께 운영하고 있으며, GPU 환경에는 NVIDIA DGX Spark 와 CPU/GPU가 포함됩니다. 실시간 음성 인식 (STT, Speech-to-Text)용 Faster-Whisper large-v3도 이 환경에 배치되어 있습니다.

이 글은 Provider를 교체 가능하게 만드는 방법(메시지 계약, 도구 스키마 이식성, 스트리밍 정규화, 기능 행렬)을 다시 설명하지 않습니다. 그 내용은 동반 글인 멀티 LLM Agent Core 설계에 있습니다. 이 글은 그 교체 가능한 Provider Core 위에 로컬·온프레미스 모델을 얹는 관점에 집중합니다. 클라우드 Provider도, 로컬 vLLM 서버도 같은 공통 계약 뒤에 있는 하나의 Provider일 뿐입니다. 보안 Gateway와 Orchestrator의 전반적인 역할 분리는 엔터프라이즈 Gateway·Orchestrator 글을 참고하시기 바랍니다.

                   Agent Core (공통 계약)
                          │
          ┌───────────────┼───────────────────┐
          ▼               ▼                   ▼
   Cloud Adapter    Local Adapter       Local Adapter
   (Cloud API)      (vLLM / Gemma)      (vLLM / Qwen)
          │               │                   │
          ▼               ▼                   ▼
    외부 데이터센터    사내 GPU 서버        망분리 GPU 서버

핵심 논지는 하나입니다. 클라우드냐 로컬이냐는 이분법이 아니라, 워크로드별 배치 결정의 집합입니다. 어떤 요청은 로컬로, 어떤 요청은 클라우드로 보내고, 로컬이 죽으면 정책이 허용하는 범위에서 클라우드로 넘기는 하이브리드 (Hybrid) 설계가 현실적인 목표입니다.

1. 이 결정을 "품질"이 아니라 "제약"에서 시작한다

가장 흔한 실수는 "어떤 모델이 제일 똑똑한가"부터 묻는 것입니다. 엔터프라이즈에서는 순서가 반대입니다. 먼저 넘을 수 없는 제약 (Hard Constraint) 을 확정하고, 그 안에서 품질을 최적화합니다.

제약 유형질문위반 시 결과

규제·계약	이 데이터가 외부로 나가도 되는가	계약 위반, 감사 지적
망분리	대상 구간에 인터넷이 있는가	기능 자체가 불가
데이터 주권	처리·저장이 특정 국경 안이어야 하는가	법적 리스크
개인정보	개인 식별 정보 (PII)가 프롬프트에 포함되는가	유출 리스크
지연 목표	첫 토큰 시간 (TTFT, Time To First Token)이 목표 내인가	UX 실패
예산	월 변동비를 감당할 수 있는가	운영 중단

품질은 대체로 이 제약들을 통과한 뒤에 비교하는 항목입니다. 다만 "품질은 항상 제약 다음"이라고 절대화하면 안 됩니다. 의료·금융·안전처럼 정확도·안전성 자체가 배포 가능 여부를 가르는 Hard Constraint가 되는 영역이 있습니다. 이때 품질은 후순위 최적화 대상이 아니라 넘을 수 없는 제약입니다. 그런 영역이 아니라면, 제약을 무시하고 벤치마크 1위 모델을 골랐다가 배치 단계에서 "그 API는 우리 망에서 못 씁니다"라는 한마디로 프로젝트가 멈추는 경우를 자주 봅니다.

[Step 1] 제약 확정 → 후보 배치 형태 결정(클라우드 가능? 로컬 필수?)
[Step 2] 후보 모델 선정 → 제약을 통과하는 것만
[Step 3] 품질·비용·지연 비교 → 워크로드별 배치 결정
[Step 4] 하이브리드 라우팅·Fallback 정책 확정

2. 클라우드 API의 강점과 한계를 정직하게 본다

클라우드 API를 열등한 선택지로 취급하면 안 됩니다. 많은 워크로드에서 여전히 최적입니다.

강점.

초기 투자 (CapEx)가 사실상 0입니다. GPU도, 데이터센터도 필요 없습니다.
최신·최대 규모 모델에 즉시 접근합니다.
확장 (Scaling)을 Provider에 위임합니다. 다만 무제한 자동 확장이 아니라, 계약된 한도와 공급자 용량 안에서 확장 책임을 위임하는 것입니다.
운영 부담(패치, 드라이버, 장애 복구)이 적습니다.

한계.

데이터가 조직 경계 밖으로 나갑니다. 계약·규제상 불가한 경우가 있습니다.
외부 클라우드 서비스로 연결되는 승인된 통신 경로가 필요합니다. 공용 인터넷 대신 전용선·VPN·Private Endpoint(예: AWS PrivateLink, Azure Private Endpoint, Google Private Service Connect)로 공용 인터넷을 거치지 않고 호출할 수도 있습니다. 다만 완전 Air-gap 구간에서는 이런 사설 경로조차 없으므로 외부 클라우드 API를 호출할 수 없습니다.
비용이 사용량에 비례하는 변동비 (OpEx)입니다. 대량·상시 워크로드에서 급증할 수 있습니다.
Rate Limit, 모델 폐기(Deprecation), 가격 변경 같은 외부 의존성이 있습니다.

즉 클라우드 API는 가변 수요, 비민감 데이터, 최고 품질이 필요한 워크로드에서 강하고, 상시 대량 처리, 민감 데이터, 망분리 구간에서 약합니다.

3. 로컬 LLM의 강점과 한계를 정직하게 본다

로컬 오픈 웨이트 모델은 반대의 프로파일을 가집니다.

강점.

데이터가 조직 경계를 벗어나지 않도록 통제하기 쉽습니다. 망분리·데이터 주권 요구를 충족하는 데 유리합니다(다만 로컬 배치만으로 자동 충족되지는 않습니다. 텔레메트리·백업·원격 관리·로그 수집·업데이트 경로가 있으면 데이터가 나갈 수 있습니다. 4·5·25절 참고).
상시 대량 워크로드에서 요청당 한계 비용 (Marginal Cost)이 낮습니다. GPU를 사놓으면 추가 호출의 주된 증분 비용은 전력·냉각·소모품과 추가 운영비 정도입니다(감가상각·고정 운영비는 이미 지불한 고정비 성격).
외부 LLM API 공급자의 Rate Limit·가격 변경·모델 폐기 영향이 크게 줄어듭니다. 모델 IP를 소유한다는 뜻이 아니라, 가중치 파일을 보유하고 버전을 고정할 수 있다는 뜻입니다. 다만 런타임·드라이버·보안 패치·오픈 웨이트 라이선스 변화 같은 외부 의존성은 여전히 영향을 줍니다.
지연을 내부에서 통제합니다. 네트워크 왕복이 사내로 한정됩니다.

한계.

GPU·서버·전력·운영 인력이라는 초기 투자와 고정비가 있습니다.
최상위 클라우드 모델 대비 품질 격차가 워크로드에 따라 존재할 수 있습니다.
확장이 조직 책임입니다. 트래픽 급증을 GPU 증설로 흡수해야 합니다.
양자화·서빙·모니터링 등 기술 난이도가 높습니다.

로컬은 민감 데이터, 망분리, 상시 대량, 예측 가능한 비용에서 강하고, 최고 난이도 추론, 가변·희소 수요에서 상대적으로 약합니다.

4. 데이터 주권과 규제: 가장 먼저 걸러지는 조건

데이터 주권은 "데이터가 물리적·법적으로 어느 관할권 안에 있어야 하는가"의 문제입니다. 특정 산업·국가·계약은 다음을 요구합니다.

처리와 저장이 특정 국경 안에서만 일어날 것.
제3자(클라우드 Provider 포함)에게 원문이 노출되지 않을 것.
처리 이력이 감사 가능(Auditable)할 것.

이 요구가 있으면, 해당 데이터를 다루는 워크로드는 후보에서 클라우드 API가 탈락합니다. 품질 논의 이전의 문제입니다. 회의 녹취·계약·인사·의료·금융 등 민감 도메인이 여기에 해당하는 경우가 많습니다.

반대로, 공개 자료 요약이나 사내 위키 검색처럼 민감도가 낮은 워크로드는 규제 필터를 통과하므로 클라우드가 여전히 유효합니다. 핵심은 조직 전체를 한 방향으로 몰지 말고, 데이터 분류 (Data Classification)에 따라 워크로드별로 나누는 것입니다.

아래는 하나의 예시 정책입니다. 실제 분류 기준·매핑은 조직의 규정·계약이 정하는 것이므로, 이 표를 규범처럼 그대로 적용해서는 안 됩니다.

데이터 분류 → 배치 결정 (예시 정책)
─────────────────────────────
Public       → 클라우드 허용
Internal     → 클라우드 조건부(마스킹·계약)
Confidential → 로컬 우선
Restricted   → 로컬 전용(클라우드 금지)

한 가지 더 짚을 점은, 로컬 배치가 데이터 주권을 자동으로 충족해 주지는 않는다는 것입니다. 처리·저장이 경계 안이라도 원격 관리 채널·텔레메트리·백업·관리자 계정·모델 업데이트 경로를 통해 데이터나 통제권이 밖으로 나갈 수 있습니다. 데이터 주권 요건은 배치 위치뿐 아니라 이 경로들까지 함께 통제해야 실제로 충족됩니다.

5. 망분리와 Air-gap: 로컬이 선택이 아니라 전제가 되는 지점

먼저 용어를 구분해야 합니다. 흔히 "망분리"와 "Air-gap"을 같은 말처럼 쓰지만, 둘은 동의어가 아닙니다.

망분리(논리적 인터넷 차단망). 외부 인터넷과 논리적으로 분리된 네트워크입니다. 방화벽·프록시·전용 게이트웨이 등으로 인터넷 접근을 차단하지만, 물리적으로는 연결이 존재할 수 있고 통제된 논리적 경로가 열려 있을 수 있습니다.
완전 Air-gap(물리적 격리). NIST 정의상 Air gap은 물리적으로 연결되지 않고, 자동화된 논리적 전송 경로도 없는 상태입니다. 데이터 이동은 사람이 개입하는 매체 반입 같은 비자동 경로로만 일어납니다.

즉 논리적 망분리·방화벽·프록시 제한 환경이 곧 완전 Air-gap인 것은 아닙니다. 어느 수준을 요구받는지에 따라 반입 절차와 통제 강도가 달라지므로, 대상 구간이 논리적 망분리인지 완전 Air-gap인지를 설계 초기에 명확히 해야 합니다.

완전 Air-gap 구간에서는 외부 클라우드 API 호출이 원천적으로 불가능합니다. 반면 논리적 망분리는 승인된 프록시·중계 게이트웨이·전용선·Private Endpoint 같은 통제된 경로가 존재할 수 있어, 그런 경로가 정책상 허용된다면 특정 클라우드 서비스를 제한적으로 호출할 여지가 남습니다. 따라서 "망분리면 클라우드는 무조건 불가"로 단정하기보다, 대상 구간이 완전 Air-gap인지 통제된 경로가 열린 논리적 망분리인지에 따라 판단해야 합니다. 어느 쪽이든 외부 반출 제약이 강한 워크로드에서는 로컬 배치가 옵션이 아니라 전제가 됩니다. 다만 로컬 배치 자체가 데이터 주권·경계 준수를 자동으로 보장하지는 않습니다. 원격 관리 채널, 텔레메트리, 백업 경로, 관리자 계정, 모델 업데이트 반입 경로까지 함께 통제해야 실제로 경계가 지켜집니다.

망분리 설계에서 흔히 놓치는 부분은 "모델만 들여놓으면 된다"는 오해입니다. 실제로는 다음이 모두 폐쇄망 안에 들어와야 합니다.

모델 가중치 파일(사전 반입, 오프라인 배포).
추론 런타임(vLLM 등)과 모든 의존 패키지.
토크나이저·설정·양자화 산출물.
벡터 저장소(PostgreSQL + pgvector)와 문서 임베딩 파이프라인.
로그·감사·모니터링 스택.
업데이트 반입 절차(외부에서 검증 후 오프라인 이전).

[외부망]  모델·패키지 검증 → 서명 → 매체/전용 반입 게이트
                                   │ (단방향/승인)
                                   ▼
[망분리망] 아티팩트 저장소 → vLLM 서빙 → Orchestrator → Gateway
                                   │
                                   ▼
                        PostgreSQL + pgvector(로컬)

망분리에서는 "인터넷에서 pip install" 같은 습관이 전부 막힙니다. 사내 미러(오프라인 패키지 저장소)와 반입 절차를 설계 초기에 확정해야 배치 단계에서 막히지 않습니다.

6. 개인정보·기밀: 마스킹으로 해결되는가, 근본적으로 못 나가는가

개인정보·기밀 데이터는 두 가지로 나눠 다뤄야 합니다.

마스킹·비식별화로 클라우드 전송이 허용되는 경우. 프롬프트에서 PII를 치환·제거한 뒤 클라우드로 보냅니다. 단, 마스킹이 완전하지 않을 위험과, 문맥 손실로 품질이 떨어질 위험이 있습니다.
원문이 경계를 넘으면 안 되는 경우. 이때는 마스킹이 아니라 로컬 처리가 답입니다.

판단 기준은 "마스킹 후 남는 데이터로도 규제·계약을 위반하는가"입니다. 위반하면 로컬로 보내고, 위반하지 않으면 마스킹 후 클라우드도 가능합니다.

여기서 감사 로그(Audit Log)의 PII 마스킹은 별도 주제입니다. 요청 자체의 라우팅 결정과, 로그에 무엇을 남길지는 다른 계층에서 다룹니다. 관련 상세는 감사·추적 관련 동반 글의 범위입니다.

7. 지연(Latency)과 TTFT: 사용자 경험을 결정하는 축

지연은 두 지표로 나눠 봐야 합니다.

첫 토큰 시간 (TTFT): 요청 후 첫 토큰이 나오기까지. 스트리밍 UX의 체감 속도를 좌우합니다.
토큰당 시간 (TPOT, Time Per Output Token): 이후 토큰 생성 간격. 긴 출력의 총 시간을 좌우합니다.

클라우드와 로컬의 지연 특성은 다릅니다.

구간클라우드 API로컬 서빙

네트워크 왕복	외부 인터넷 왕복 포함	사내망으로 한정
대기열	Provider 혼잡·Rate Limit 영향	내부 배치 스케줄러가 통제
TTFT 변동성	외부 요인으로 예측 어려움	내부에서 측정·통제하기 상대적으로 쉬움
피크 흡수	계약 한도·공급자 용량 내에서 확장 위임	GPU 용량 한계 내에서만

지연에 민감한 대화형·실시간 워크로드는 로컬 서빙이 네트워크 왕복과 외부 대기열을 제거해 내부에서 측정·통제하기가 상대적으로 쉽다는 점에서 유리할 수 있습니다. 다만 로컬은 GPU 용량이 곧 한계이므로, 동시성 급증 시에는 대기열이 길어질 수 있습니다. 구체 수치는 하드웨어·모델·양자화·동시성에 따라 크게 달라지므로, 반드시 자체 환경에서 측정해야 합니다.

8. 처리량(Throughput): 상시 대량 워크로드의 손익분기

처리량은 초당 처리 토큰·요청 수입니다. 상시 대량 워크로드(예: 대량 문서 요약·분류·임베딩)에서는 처리량이 곧 비용입니다.

클라우드: 처리량이 늘수록 변동비가 선형으로 증가합니다.
로컬: GPU 고정비를 이미 지불했으므로, 처리량이 늘수록 요청당 비용이 낮아집니다(고정비 분산).

즉, 호출량이 적으면 클라우드가, 호출량이 손익분기점을 넘으면 로컬이 총비용에서 유리해지는 교차 지점이 존재할 수 있습니다. 다만 이 교차점이 항상 유효 용량 구간 안에 있는 것은 아닙니다. 로컬 최대 처리량을 넘으면 GPU를 추가 구매해야 해서 비용이 계단식으로 뛰고, 낮은 이용률에서는 로컬이 감가상각 기간 내내 더 비쌀 수도 있습니다. 그래서 교차점은 "존재할 수 있으며, 유효 용량 구간별로 계산한다"로 보는 편이 안전합니다. 이 교차점은 조직마다 다르므로 9절의 TCO 모형으로 계산해야 합니다.

9. TCO: 초기 투자 vs 월 API 비용을 같은 표에 놓는다

로컬과 클라우드를 비교할 때 자주 저지르는 실수는 "GPU 구매가"만 로컬 비용으로 보는 것입니다. 실제 TCO는 훨씬 넓습니다.

비용 항목클라우드 API로컬 배치

초기 투자(CapEx)	거의 없음	GPU·서버·네트워크·설치
변동비(OpEx)	토큰당 API 요금	전력·냉각
인건비	통합 개발만	서빙·모니터링·장애 대응
감가상각	없음	하드웨어 수명 기준
소프트웨어	Provider 포함	런타임·오케스트레이션 운영
확장 비용	자동(요금 증가)	GPU 증설(추가 CapEx)
규제 대응	계약·검증 비용	반입·감사 절차 비용

간단한 손익분기 모형을 텍스트로 표현하면 다음과 같습니다.

월 총비용(클라우드) = 월 처리 토큰 × 토큰당 단가
월 총비용(로컬)     = (초기투자 ÷ 감가상각 개월) + 월 전력·운영 인건비

손익분기: 두 값이 같아지는 월 처리 토큰량 = 교차점(존재할 때)
  → 예상 처리량이 교차점보다 크면 로컬이 유리(단, 기존 로컬 용량 범위 안에서)
  → 예상 처리량이 교차점보다 작으면 클라우드가 유리
  ※ 클라우드 단가는 입력·출력·캐시·배치·약정 할인별로 다르고,
     로컬도 전력 외 유지보수·지원·라이선스 등 변동비가 붙는다

여기서 하드웨어의 공개 정가는 참고가 됩니다. 예를 들어 NVIDIA DGX Spark는 2025년 10월 15일 출시 시점에 미화 3,999달러로 안내되었고, 이후 메모리 공급 사정으로 2026년 2월 말(공식 가격 변경 공지의 명시 일자는 2월 23일) 4,699달러로 인상되었습니다(공개 정보). 이처럼 정가 자체가 시점에 따라 바뀌므로, TCO에서는 특정 시점의 정가를 고정값으로 못 박기보다 "확인 시점의 현행 정가"로 갱신해 사용해야 합니다. 또한 실제 TCO는 정가만으로 결정되지 않고, 전력·운영·감가상각·규제 대응까지 포함해야 하므로, 정가는 CapEx 항목의 한 입력값으로만 사용해야 합니다.

주의: 이 글은 조직별 비용·성능 벤치마크 수치를 제시하지 않습니다(하드웨어 공개 정가나 파라미터·메모리 같은 공개 스펙은 참고용으로 인용합니다). 단가·처리량·전력비는 계약·지역·시점에 따라 달라지므로, 위 모형에 조직의 실제 값을 대입해 스스로 계산해야 합니다.

10. 로컬 모델 후보: Gemma 3 / Gemma 4 개요

로컬 후보로 필자가 상용 운영 중인 첫 계열은 Google의 오픈 웨이트 모델 Gemma입니다.

Gemma 3 (2025년 3월 최초 공개군 기준).

크기: 1B / 4B / 12B / 27B.
컨텍스트: 128K(1B는 32K).
멀티모달 (Multimodal): 텍스트 전용인 1B을 제외한 4B·12B·27B가 비전 인코더로 이미지 입력을 지원합니다. 계열 전체가 텍스트·이미지라고 뭉뚱그리면 안 됩니다.
다국어: 140개 언어 지원.
함수 호출 (Function Calling) 지원.
라이선스: Gemma Terms of Use(및 금지 사용 정책)를 따릅니다. Apache 라이선스가 아니므로 상업 이용·재배포 조건을 별도로 확인해야 합니다.

위 목록은 2025년 3월 최초 공개군 기준이며, 이후 270M 같은 소형 모델이나 파생 모델이 추가되었으므로 실제 채택 시 현재 모델 카드로 후보 목록을 다시 확인해야 합니다.

Gemma 4 (2026년 4월 2일 최초 공개군 기준, Apache-2.0 라이선스).

최초 공개군 크기: E2B / E4B / 26B(MoE) / 31B(Dense).
Gemini 3 연구를 기반으로 구축.
멀티모달.
Hugging Face·Kaggle·Ollama·Google AI Studio를 통해 제공.
라이선스: Gemma 4는 Gemma 3과 달리 Apache-2.0으로 제공됩니다. 같은 Gemma 계열이라도 세대별 라이선스가 다르므로 묶어서 다루면 안 됩니다.

이후 Google은 2026년 6월 3일 Gemma 4 12B를 추가했습니다. 12B는 E4B와 26B MoE 사이를 잇는 중간 크기의 멀티모달 모델로, 네이티브 오디오 입력을 지원하며 Apache-2.0 라이선스로 공개되었습니다. 따라서 2026년 7월 30일 현재 후보군을 검토할 때는 최초 공개군뿐 아니라 12B도 함께 비교해야 합니다.

크기 표기의 E2B/E4B에서 앞의 E는 Effective, 즉 단순 총 파라미터 수라기보다 추론 시 유효하게 활성화되는 파라미터 footprint를 가리키는 효율 지향 소형 구성을 뜻합니다. 상위 구성인 26B와 31B는 성격이 다릅니다. 26B는 토큰당 약 3.8B만 활성화하는 MoE로 총 파라미터 대비 연산 비용이 낮고, 31B는 전 파라미터를 매 토큰 사용하는 Dense 구조입니다. 모델 선정 시 "26B < 31B"라는 크기 대소가 아니라, MoE(연산 효율·메모리는 총 파라미터 기준)와 Dense(전체 파라미터를 매 토큰 사용)의 성격 차이로 판단해야 합니다. 실무에서는 소형(경량·저지연)과 대형(고품질) 사이에서 워크로드에 맞춰 선택합니다.

11. 로컬 모델 후보: Qwen 계열 개요

두 번째로 필자가 상용 운영 중인 계열은 Alibaba Cloud의 오픈 웨이트 모델 Qwen3입니다(2025년 4월 29일 공개, Apache-2.0 라이선스). 필자의 상용 운영 세대는 Qwen3이며, 이후 세대가 더 나왔다는 점은 아래에서 별도로 짚습니다.

밀집 (Dense) 모델: Qwen3-0.6B / 1.7B / 4B / 8B / 14B / 32B.
전문가 혼합 (MoE, Mixture-of-Experts) 모델: Qwen3-30B-A3B(총 30B, 활성 3B), Qwen3-235B-A22B(총 235B, 활성 22B).
컨텍스트: 초기 공개 Qwen3의 사전학습(Pretrain) 네이티브 컨텍스트는 최대 32,768(32K)입니다. 131,072(131K)는 YaRN RoPE 스케일링을 적용한 확장 설정으로, 네이티브 사양이 아닙니다. "8B 이상은 128K"처럼 크기별로 단정하면 안 되고, Qwen3-2507 같은 후속 체크포인트는 별도의 컨텍스트 사양을 가진다는 점도 함께 확인해야 합니다.
다국어: 119개 언어·방언.

MoE 모델은 총 파라미터는 크지만 토큰당 활성 파라미터가 작아, 대형 품질을 상대적으로 낮은 연산 비용으로 낼 수 있는 구조입니다. 다만 산정의 일반적 기본값으로는 총 파라미터 전체를 메모리에 올려야 하므로 요구 메모리를 총 파라미터 기준으로 잡는다는 점을 놓치면 안 됩니다. 이는 절대 명제는 아니며, 전문가 병렬화(Expert Parallelism)·샤딩·오프로딩을 쓰면 노드별 실제 메모리 배치가 달라질 수 있습니다.

시점 주의(2026-07-30 확인 기준). Qwen3는 필자의 상용 운영 세대일 뿐, 이 시점 기준 "최신 세대"는 아닙니다. 이후 2026년 4월 16일 Qwen3.6-35B-A3B(Apache-2.0, MoE 총 35B·활성 3B, 멀티모달)가 Qwen3.6 계열의 첫 공개 모델 중 하나로 공개되었습니다(같은 계열에 27B 등 다른 구성도 있습니다). 모델 세대는 빠르게 갱신되므로, 실제 채택 시 현재 최신 세대와 필자 운영 세대를 구분해 확인해야 합니다.

12. 크기별 용도: 소형·중형·대형을 어디에 쓰나

동일 계열 안에서도 크기 선택은 워크로드가 결정합니다.

크기대대표 용도배치 특성

소형(≈1B~4B)	분류·라우팅·간단 추출·가드레일	저지연·고동시성, 단일 GPU
중형(≈8B~14B)	요약·RAG 응답·도구 호출	품질·비용 균형
대형(≈27B~32B+)	복합 추론·긴 문맥 종합	고품질, VRAM 요구 큼

실무 패턴은 작업을 잘게 쪼개 크기별로 배치하는 것입니다. 예를 들어 라우팅·PII 탐지·분류는 소형 모델이, 최종 요약·종합은 중·대형 모델이 담당하면 전체 처리량과 비용이 개선됩니다. 모든 요청을 대형 모델 하나로 처리하는 구조는 대부분 비효율적입니다.

13. 한국어·멀티링구얼 품질을 어떻게 검증하나

한국어 워크로드에서 "다국어 지원"이라는 스펙만 믿으면 안 됩니다. 지원 언어 수와 실제 한국어 품질은 다른 문제입니다. Gemma 3의 140개 언어, Qwen3의 119개 언어·방언 같은 공개 스펙은 후보 자격의 출발점일 뿐입니다.

검증은 조직의 실제 데이터로 해야 합니다.

도메인 용어(사내 약어·제품명·업무 표현)의 처리 정확도.
존댓말·문체 일관성.
긴 한국어 문맥에서의 요약 충실도·환각(Hallucination) 여부.
도구 호출 인자 생성 시 한국어 입력의 파싱 안정성.

이 검증은 고정 평가 세트(Golden Set)로 만들어 모델 교체 때마다 재실행해야 합니다. "체감상 A가 낫다" 수준의 판단은 배치 결정 근거가 될 수 없습니다.

14. 컨텍스트 길이와 품질의 트레이드오프

컨텍스트 길이(128K 등)는 "넣을 수 있는 최대치"이지, "그만큼 넣으면 품질이 유지된다"는 뜻이 아닙니다. 긴 문맥에서는 다음이 발생할 수 있습니다.

중간 정보 소실(문맥 중앙의 정보를 덜 활용).
KV 캐시 (KV Cache) 메모리 급증 → 동시성 저하.
TTFT 증가(긴 프리필 (Prefill) 시간).

따라서 "긴 컨텍스트로 통째로 밀어넣기"보다, RAG로 관련 청크만 선별해 넣는 편이 품질·비용·지연 모두에서 유리한 경우가 많습니다. 로컬 배치에서는 컨텍스트 길이가 곧 VRAM·처리량과 직결되므로 더욱 신중해야 합니다.

15. 양자화(Quantization) 개요: 왜 필요한가

양자화는 모델 가중치를 낮은 비트로 표현해 메모리와 대역폭을 줄이는 기법입니다. 로컬 배치에서 양자화는 사실상 필수라기보다는 용량·동시성·비용 목표에 따라 중요한 선택지입니다. 예를 들어 27B급 BF16 가중치(약 54GB)는 128GB 통합 메모리에 그대로 올릴 수 있으므로, 양자화 없이도 구동 가능한 경우가 있습니다. 다만 더 큰 모델을 올리거나 동시성·컨텍스트 여유를 확보하려면 양자화가 유력한 수단이 됩니다.

정밀도대략적 가중치 크기(파라미터당)특성

FP16/BF16	약 2바이트	기준 품질, 메모리 큼
INT8	약 1바이트	메모리 절반, 손실은 방식에 따라 다름
INT4	약 0.5바이트	메모리 1/4, 품질 손실 관리 필요

주의할 점이 있습니다. 위 표는 가중치 크기만 비교한 것입니다. 실제 메모리·품질은 양자화 방식에 따라 달라집니다. INT8도 가중치만 양자화하는 weight-only인지, 활성값까지 8비트로 다루는 W8A8인지, KV 캐시 정밀도를 낮추는지에 따라 결과가 다르며, "항상 품질 손실이 작다"고 단정할 수 없습니다. 또한 양자화는 스케일(Scale)·제로포인트(Zero-point) 같은 메타데이터를 추가로 저장하므로, 이론적 비트 수만큼 정확히 줄지는 않습니다.

거칠게 잡으면 가중치 메모리 ≈ 파라미터 수 × 바이트/파라미터이고, 여기에 KV 캐시·활성값·런타임 오버헤드와 양자화 메타데이터가 더 붙습니다. INT4로 내리면 더 큰 모델을 같은 하드웨어에 올릴 수 있지만, 품질 손실을 반드시 자체 평가 세트로 확인해야 합니다.

16. GPTQ와 AWQ: 대표 양자화 방식

INT4 급 양자화의 대표적 후처리 방식은 GPTQ와 AWQ입니다.

GPTQ (Post-Training Quantization): 사후 학습 양자화 계열로, 2차(헤시안 기반) 근사로 반올림 오차를 보정해 정확도 손실을 줄입니다.
AWQ (Activation-aware Weight Quantization): 활성값 분포를 고려해 중요한 가중치를 보존하며 그룹 단위로 INT4 양자화합니다. 그룹 스케일을 함께 저장합니다.

두 방식 모두 vLLM에서 지원되며, 서빙 시 전용 커널(예: Marlin)로 가속됩니다. 다만 vLLM이 GPTQ·AWQ·INT8·FP8을 지원한다고 해서 모든 GPU·CPU·커널 조합에서 지원되는 것은 아닙니다. 하드웨어 아키텍처(예: ARM64 기반 DGX Spark)와 정밀도·커널 조합별 호환성 표를 반드시 사전 확인해야 합니다. 실무 선택 기준.

이미 배포된 양자화 산출물(체크포인트)이 있는지.
서빙 런타임이 해당 커널을 지원하는지.
조직 평가 세트에서 품질 손실이 허용 범위인지.

"어느 방식이 절대적으로 낫다"는 없습니다. 모델·태스크·런타임 조합에서 자체 측정으로 결정합니다.

17. DGX Spark 128GB에서 모델 크기 산정

로컬 배치의 핵심 실무는 "이 하드웨어에 어떤 모델을, 어떤 양자화로 올릴 수 있는가"입니다. NVIDIA DGX Spark의 공개 스펙은 다음과 같습니다(공식 정보).

GB10 Grace Blackwell Superchip.
128GB LPDDR5x, CPU+GPU 일관성(Coherent) 통합(Unified) 메모리(NVLink-C2C).
최대 1 petaFLOP FP4 연산(with sparsity 조건 기준).
단일 유닛에서 지원 상한 약 200B 파라미터 모델, ConnectX로 두 유닛 연결 시 지원 상한 약 405B 파라미터(두 노드 분산 추론). 이는 최적화된 정밀도·런타임 조합에서의 지원 상한이며, 모든 모델·정밀도를 포괄하는 일반 보장은 아닙니다.

128GB 통합 메모리가 CPU와 GPU에 일관적으로 공유된다는 점이 중요합니다. 전통적 개별 GPU VRAM과 달리, 큰 모델을 통합 메모리에 올려 구동하는 접근이 가능합니다. 따라서 Spark 문맥에서는 "VRAM 점유"보다 "통합 메모리 중 런타임 가용량" 으로 표현하는 것이 정확합니다. 대략적 산정 개념은 다음과 같습니다.

필요 메모리 ≈ 가중치(파라미터수 × 비트/8)
            + KV 캐시(동시요청 × 컨텍스트길이에 비례)
            + 활성값·런타임 오버헤드

예) 27B급 모델
  - FP16: 가중치만 약 54GB → KV·오버헤드까지 여유 필요
  - INT8: 가중치만 약 27GB → 더 큰 동시성/컨텍스트 여유
  - INT4: 가중치만 약 14GB → 대형 모델 다중 구동 여지
※ 위 수치는 산정 개념 예시이며, 실제 값은 모델·런타임·설정에 따라 다름

단일 유닛 200B, 이중 유닛 405B라는 공개 스펙은 최적화된 정밀도·런타임에서의 공식 지원 상한이지, "그 상태로 원하는 동시성·컨텍스트가 나온다"는 보장이 아닙니다. 실제 배치 크기는 상한보다 보수적으로 잡고, KV 캐시와 동시성 여유를 반드시 남겨야 합니다.

18. vLLM 서빙: PagedAttention과 KV 캐시

로컬 GPU 서빙에서 처리량을 좌우하는 핵심은 KV 캐시 관리입니다. vLLM은 PagedAttention으로 이를 개선합니다.

PagedAttention(paged KV-cache 관리 개념): KV 캐시를 고정 크기 블록(페이지)으로 나눠, 운영체제의 가상 메모리처럼 논리 블록 테이블로 비연속 물리 블록에 매핑하는 개념입니다. 요청마다 연속된 메모리를 미리 크게 예약할 필요가 없어, 메모리 단편화가 줄고 더 많은 동시 요청을 담을 수 있습니다. 이는 특정 내부 구현이 영구히 고정된다는 뜻이 아니라 관리 개념으로 이해하는 것이 안전하며, 세부 구현은 vLLM 버전에 따라 달라질 수 있습니다.
KV 캐시: 생성된 토큰의 키·값을 저장해 재계산을 피합니다. 동시성·컨텍스트가 커질수록 KV 캐시가 메모리를 크게 차지하므로, paged KV-cache 관리의 효율이 곧 동시성 상한을 좌우합니다.

vLLM은 GPTQ·AWQ·INT4·INT8·FP8 등 양자화를 지원하며, 모델 config.json의 양자화 설정을 감지해 커널로 분기합니다. 다만 이 자동 감지가 항상 해당 하드웨어에서 최적 커널을 선택한다고 보장할 수는 없으므로, 실제 서빙 전에 대상 하드웨어에서 커널·정밀도 조합을 검증해야 합니다.

19. 배치(Batching)와 스트리밍, 동시성

로컬 서빙에서 처리량을 끌어올리는 또 다른 축은 연속 배치 (Continuous Batching)입니다.

연속 배치: 스케줄러가 매 forward 단계마다 새 요청을 실행 중인 배치에 합류시키고, 끝난 시퀀스 자리를 즉시 채웁니다. GPU 유휴를 줄여 고동시성에서 처리량이 개선됩니다.
스트리밍(Streaming): 토큰을 생성 즉시 흘려보내 TTFT 체감을 개선합니다. 대화형 UX에 필수입니다.

여기서 트레이드오프가 생깁니다.

목표유리한 설정대가

최대 처리량(배치 지향)	큰 배치, 대량 요청 병합	개별 요청 TTFT 증가 가능
최소 지연(대화 지향)	스트리밍, 작은 배치	GPU 이용률 저하 가능

대량 백그라운드 처리(문서 일괄 요약)는 배치 지향으로, 실시간 대화는 스트리밍·저지연으로 나눠 서빙하는 것이 실무 패턴입니다. 하나의 서빙 설정으로 두 목표를 동시에 최적화하려 하면 양쪽 다 어중간해집니다.

20. DGX Spark 단일/이중 구성 설계

DGX Spark는 단일 유닛과 이중 유닛(ConnectX 연결) 구성이 가능합니다. 배치 관점의 선택 기준은 다음과 같습니다.

[단일 유닛]  공식 지원 상한 ~200B급 모델
  → 중·대형 모델 1~수 개 서빙, 부서·팀 단위 워크로드
  → 초기 도입, PoC→상용 전환 초기 단계에 적합

[이중 유닛]  ConnectX 연결로 공식 지원 상한 ~405B급 (분산 실행)
  → 초대형 모델 적재 시연 또는 더 큰 동시성 요구
  → 하나의 모델을 두 노드에 걸쳐 분산 추론하는 구성

여기서 주의할 점은, ~405B라는 이중 유닛 상한은 매우 제한된 설정에서의 적재·실행 시연 상한에 가깝다는 것입니다. NVIDIA의 이중 Spark vLLM 안내조차 405B 모델에 대해서는 운영용 메모리 여유가 부족하다고 경고하며, 예시를 컨텍스트 64·동시 요청 1 같은 극단적으로 제한된 조건으로 잡습니다. 즉 이 숫자를 일반적인 운영 컨텍스트·동시성을 갖춘 Production 용량으로 해석하면 안 됩니다. 실무 운영에서는 405B보다 훨씬 보수적인 모델 크기와 동시성으로 잡아야 합니다.

여기서 반드시 구분해야 할 개념이 있습니다.

분산 실행(Distributed Inference). ConnectX로 두 유닛을 연결해 하나의 모델을 두 노드에 나눠 올리는 구성입니다. 이는 "더 큰 모델을 올리기 위한" 것이지 자동 HA가 아닙니다. 오히려 한 노드가 죽으면 그 모델의 추론 전체가 실패합니다. 즉 노드 수가 늘수록 단일 추론의 장애 표면이 넓어질 수 있습니다.
독립 복제 HA(High Availability). 가용성을 얻으려면 각 노드가 독립적으로 같은 요청을 처리할 수 있는 복제본(Replica), 그 앞단의 로드밸런서, 헬스 체크, 그리고 세션·진행 상태 관리가 필요합니다. 이때 한 노드가 죽어도 다른 노드가 요청을 받아냅니다.

따라서 "이중 유닛 = 이중화"가 아닙니다. 초대형 모델의 분산 실행이 목표인지, 장애 대비 HA가 목표인지를 먼저 정하고, HA가 목표라면 분산 실행 구성이 아니라 독립 복제 + 로드밸런서 구성을 설계해야 합니다. 이중화 여부는 워크로드의 가용성 목표(SLA)와 예산으로 결정할 문제입니다.

21. 하이브리드 라우팅: 민감 데이터=로컬, 일반=클라우드

이제 앞의 제약과 후보를 하나의 라우팅 정책으로 묶습니다. 핵심 규칙은 단순합니다.

민감·기밀·망분리 대상 → 로컬 전용.
비민감·일반 → 클라우드 허용(품질·비용에 따라 선택).
경계 사례 → 마스킹 후 클라우드, 또는 로컬.

라우팅 결정은 요청의 데이터 분류와 정책으로 하고, 모델 선택이 아니라 배치 위치를 먼저 정한다는 점이 중요합니다. 이 라우팅 로직은 멀티 LLM Agent Core에서 다룬 교체 가능한 Provider 추상화 위에 얹힙니다. 즉, 로컬 vLLM Provider와 클라우드 Provider가 같은 공통 계약을 구현하고, Orchestrator가 정책에 따라 둘 중 하나를 선택합니다.

아래는 예시용 비표준 정책입니다(표준 규격이 아니므로 평가 의미를 함께 명시합니다). rules는 위에서부터 first-match로 평가하고, 한 match 안의 여러 필드는 모두 AND 조건입니다. 미지원 필드·미정의 분류값이 들어오면 규칙에 매칭되지 않고 default로 떨어집니다. 그리고 그 default는 fail-closed(거부) 입니다. pii_masked나 cloud_processing_authorized 같은 Boolean은 호출자가 임의로 지정하는 값이 아니라, 신뢰된 정책 엔진이 법무·계약 검토 결과로 산출해 주입해야 합니다.

{
  "routing_policy": {
    "version": "1",
    "evaluation": { "rule_order": "first_match", "match_fields": "AND", "on_unknown_field_or_class": "deny" },
    "rules": [
      {
        "match": { "data_classification": "restricted" },
        "route": {
          "provider": "local",
          "model_class": "medium",
          "failure_domain": "primary_gpu_pool",
          "fallback": { "action": "deny", "reason": "restricted_no_cloud" }
        }
      },
      {
        "match": { "data_classification": "confidential" },
        "route": {
          "provider": "local",
          "model_class": "large",
          "failure_domain": "primary_gpu_pool",
          "fallback": { "provider": "local", "model_class": "small", "failure_domain": "secondary_gpu_pool" }
        }
      },
      {
        "match": {
          "data_classification": "internal",
          "pii_masked": true,
          "cloud_processing_authorized": true
        },
        "route": {
          "provider": "cloud",
          "model_class": "balanced",
          "fallback": { "provider": "local", "model_class": "medium", "failure_domain": "primary_gpu_pool" }
        }
      },
      {
        "match": { "data_classification": "public" },
        "route": {
          "provider": "cloud",
          "model_class": "best_quality",
          "fallback": { "provider": "local", "model_class": "medium", "failure_domain": "primary_gpu_pool" }
        }
      }
    ],
    "default": { "action": "deny", "reason": "classification_required" },
    "audit": { "policy_version": "1", "approved_by": "<policy_owner>", "effective_at": "<timestamp>", "audit_id": "<id>" }
  }
}

핵심은 default의 기본 동작 자체를 거부(fail-closed) 로 두는 것입니다. 이전처럼 미분류 요청을 "일단 로컬로" 흘리면, fallback: "deny"는 로컬 실행이 실패한 뒤의 동작일 뿐이어서 실제로는 분류 없는 요청이 그대로 모델에 전달됩니다. 진짜 fail-closed라면 분류가 없거나 오타가 난 요청은 라우팅 이전에 action: "deny"로 막혀야 합니다. 분류가 명확하지 않은 요청을 실수로 어느 경계로든 흘리는 것보다, 분류를 요구하며 거부하는 편이 규제 리스크가 낮습니다.

몇 가지 추가로 짚을 점이 있습니다.

pii_masked는 충분조건이 아닙니다. 마스킹·가명처리는 익명화와 다르며, 문맥 결합으로 재식별될 수 있으면 여전히 개인정보입니다. 그래서 위 internal 규칙은 pii_masked와 함께 cloud_processing_authorized(법무·계약·공급자 조건 검토를 통과했다는 신뢰된 플래그)를 AND로 요구합니다. 공급자 보존·학습 사용·처리 지역·하위처리자·재식별 위험·처리 근거가 모두 허용될 때에만 이 플래그가 참이어야 합니다.
failure_domain으로 장애 도메인을 구분합니다. confidential → local large → local small이 같은 DGX Spark·전원·vLLM 서버 안에서 일어나면 장애 복구가 아닙니다. fallback 대상이 별도 서빙 풀·전원·저장소에 있어야 실제 가용성이 생깁니다.
거부는 provider가 아니라 별도 action으로 표현합니다. fallback을 provider/model_class를 가진 객체로 구조화하고, 거부는 { "action": "deny" }로 분리해 타입 혼용(문자열 local_small과 deny를 한 필드에 섞던 문제)을 없앱니다.

이 정책 JSON은 어디까지나 예시이며, 실제 운영 정책은 버전·승인자·발효 시각·감사 ID를 함께 기록하고 신뢰된 정책 엔진에서 평가해야 합니다.

한 가지 더 중요한 점은, 라우팅 결정을 최초 요청 한 번으로 끝내면 안 된다는 것입니다. 에이전트 실행 중에는 분류가 동적으로 바뀔 수 있습니다. 최초 요청은 Public이어도, RAG 검색으로 끌어온 문서나 MCP 도구가 반환한 결과가 Confidential·Restricted일 수 있습니다. 이렇게 누적된 컨텍스트를 그대로 클라우드로 보내면, 초기 분류만 믿다가 민감 데이터를 경계 밖으로 흘리게 됩니다. 그래서 클라우드 Provider를 호출하기 직전에 프롬프트·검색 결과·도구 출력까지 합친 누적 컨텍스트를 다시 분류하고, 상향된 분류에 맞춰 로컬로 재라우팅하거나 거부해야 합니다. 재분류로 경계가 바뀌면 라우팅 정책을 처음부터 다시 적용하는 것이 안전합니다.

22. Fallback: 로컬 장애 시 무엇을 어디까지 허용하나

로컬 GPU가 죽거나 대기열이 폭주하면 어떻게 할지 미리 정해야 합니다. 그런데 fallback은 "무조건 클라우드로 넘긴다"가 아닙니다. 데이터 분류가 fallback 허용 범위를 제한합니다.

원 배치장애 시 fallback근거

Restricted(로컬 전용)	거부/대기	클라우드 금지, 넘기면 규제 위반
Confidential(로컬)	다른 로컬(소형)	경계 밖 금지
Internal(마스킹 후 클라우드)	로컬 중형	반대 방향 fallback도 유효
Public(클라우드)	로컬 중형	외부 장애 대비

즉 fallback은 양방향입니다. 로컬 장애 시 클라우드로 못 넘기는 워크로드도 있고(Restricted), 클라우드 장애 시 로컬로 받아내는 워크로드도 있습니다(Public). 라우팅 정책의 fallback 필드에 이 방향과 한계를 명시해야 합니다.

23. Checkpoint 복구: fallback 전에 부작용을 확인한다

모델을 도중에 바꾸는 fallback은 위험을 동반합니다. 도구 호출(Tool Call)이 이미 부작용(예: 저장·전송)을 냈는데, fallback 모델이 그 도구를 다시 호출하면 중복 실행이 됩니다. 그래서 fallback 전에 Checkpoint(체크포인트) 로 어디까지 진행됐는지 확인해야 합니다.

[정상] 로컬 모델 → Tool A 호출 → Tool A 결과 저장(checkpoint) → 응답
[장애] 로컬 모델 다운
   ↓
Checkpoint 확인:
   - Tool A는 이미 성공(부작용 발생) → 재실행 금지
   - 아직 남은 단계만 fallback 대상 모델로 재개
   ↓
[복구] 클라우드 모델(정책 허용 시) → 남은 단계만 이어서 실행

다만 Checkpoint 하나만으로는 중복 부작용을 완전히 막지 못합니다. 도구 실행이 성공한 직후 체크포인트를 저장하기 전에 프로세스가 죽는 원자성 공백(Atomicity Gap)이 존재하기 때문입니다. 이 경우 재개 시점의 Checkpoint에는 도구 성공 기록이 없어, fallback 모델이 같은 도구를 다시 호출할 수 있습니다. 그래서 실제 안전한 복구는 다음을 함께 갖춰야 합니다.

Checkpoint: 어디까지 진행됐는지의 실행 상태.
멱등 키(Idempotency Key): 같은 논리적 작업에 동일 키를 부여해, 재시도가 새 부작용을 만들지 않게 함.
중복 제거 저장소/Outbox: 이미 수행된 부작용을 기록해 두고, 같은 키의 재실행을 걸러 냄. 단, Transactional Outbox가 원자적으로 묶는 것은 일반적으로 "로컬 DB 상태 변경과 발행할 메시지 기록"까지이며, 외부 시스템으로의 실제 전달은 여전히 중복될 수 있습니다. 그래서 소비자 측 멱등성 또는 Inbox·중복 제거가 별도로 필요합니다.
상태 조회·조정(State Reconciliation): 재개 전에 외부 시스템의 실제 상태를 조회해 Checkpoint와 실제를 맞춤.

이 복구 가능한 실행(Recoverable Execution) 패턴 자체는 복구 가능한 워크플로 설계 글에서 원자성 공백·멱등성·재조정을 포함해 깊게 다룹니다. 로컬/클라우드 fallback 설계에서는 Checkpoint 없이 fallback을 붙이면 안 되고, Checkpoint만으로 충분하다고 여겨도 안 된다는 원칙을 반드시 지켜야 합니다. 데이터 분류에 따른 fallback 허용 여부와, 멱등성·중복 제거를 포함한 재개 설계는 함께 설계해야 합니다.

24. 온프레미스/망분리 재배치: Gateway와 Orchestrator

클라우드에서 검증한 Gateway·Orchestrator 구조를 온프레미스·망분리로 옮길 때, 아키텍처는 유지하되 배치와 의존성을 바꿉니다.

[클라우드/일반망]
  Client → Gateway(보안·인증·정책) → Orchestrator(LangGraph)
         → Cloud LLM Provider

[온프레미스/망분리]
  Client → Gateway(보안·인증·정책) → Orchestrator(LangGraph)
         → Local LLM Provider(vLLM: Gemma/Qwen)
         → PostgreSQL + pgvector(로컬)
         → Local MCP Tools(폐쇄망 내부 도구)

바뀌는 것.

LLM Provider 목적지가 외부 API에서 사내 vLLM 엔드포인트로 바뀝니다(공통 계약은 유지).
벡터 저장소·데이터베이스가 사내 PostgreSQL + pgvector로 바뀝니다.
MCP 도구가 외부 SaaS 대신 폐쇄망 내부 도구로 바뀝니다.
외부 반출이 필요한 모든 경로가 제거되거나 승인 게이트를 거칩니다.

유지되는 것.

Gateway의 인증·인가·정책 적용 지점.
Orchestrator의 워크플로 로직과 Checkpoint.
Provider 공통 계약(교체 가능한 Core).

이 구조 덕분에, 같은 코어를 클라우드·온프레미스·망분리에 걸쳐 재사용할 수 있습니다. 다만 "코어는 유지하고 목적지만 바꾼다"를 문자 그대로 받아들이면 안 됩니다. Provider가 바뀌면 프롬프트 템플릿, 도구 호출(Tool Call) 포맷, 멀티모달 입력 처리, 스트리밍 이벤트 형식, 오류 형식, 컨텍스트 한도가 함께 달라질 수 있습니다. 그래서 "교체 가능"의 의미는 API 모양이 같다는 수준이 아니라, 기능 행렬(Feature Matrix)과 호환성 테스트까지 통과한다는 뜻이어야 합니다. 배치 형태가 달라도 코어의 뼈대는 하나로 유지하되, Provider별 차이는 어댑터 계층에서 흡수한다고 보는 편이 정확합니다.

25. 로컬 MCP 도구와 감사(Audit)

망분리·온프레미스에서 MCP(Model Context Protocol) 도구는 폐쇄망 내부에서 동작해야 합니다. 외부 SaaS 도구는 쓸 수 없으므로, 사내 시스템을 감싸는 로컬 MCP 서버가 필요합니다.

감사 관점에서 로컬 배치의 장점은 모든 요청·도구 호출·결과를 조직 내부 로그에 남길 수 있다는 점입니다. 다만 이는 자동으로 되는 효과가 아니라 로깅을 구현하고 정책으로 강제한 결과라는 점을 오해하면 안 됩니다. 로컬에 두었다는 사실만으로 감사 로그가 저절로 생기지 않으며, 원격 관리·텔레메트리·백업 경로로 로그 밖 유출이 없는지도 별도로 확인해야 합니다. 또 이 로그에는 민감 데이터가 포함될 수 있으므로 다음을 지켜야 합니다.

프롬프트·도구 인자에서 PII·비밀을 마스킹해 로그에 남깁니다.
어떤 요청이 로컬로/클라우드로 라우팅됐는지(배치 결정)를 감사 항목으로 기록합니다.
로그 보존 기간과 접근 권한을 정책으로 통제합니다.

라우팅 결정 자체가 감사 대상이라는 점이 중요합니다. "이 민감 요청이 실제로 로컬로 갔는가"를 사후에 증명할 수 있어야 규제 대응이 됩니다. 감사 로그의 마스킹·보존 정책 상세는 감사·추적 동반 글의 범위입니다.

26. 로컬 저장소: PostgreSQL + pgvector

로컬·망분리 배치에서 RAG 검색용 벡터 저장소는 조직 경계 안에 있어야 합니다. PostgreSQL + pgvector는 이 요구에 적합한 조합입니다.

이미 운영 중인 관계형 데이터베이스 위에 벡터 검색을 얹을 수 있습니다.
문서 원문·메타데이터·임베딩을 한 시스템에서 관리해 데이터가 경계를 벗어나지 않습니다.
접근 제어·백업·감사를 기존 DB 운영 체계로 흡수합니다.

여기서 멀티테넌트(Multi-tenant) 격리, 중복 청크 방지, 재색인(Idempotent Indexing) 같은 RAG 인프라 상세는 별도 주제이며, 관련 동반 글들에서 다룹니다. 이 글의 범위에서는 "벡터 저장소도 로컬 경계 안에 배치한다"는 배치 원칙만 확인합니다.

27. 운영·모니터링: 로컬 배치에서 반드시 봐야 할 지표

로컬 서빙은 운영 책임이 조직에 있으므로 모니터링이 필수입니다. 최소한 다음을 관측해야 합니다.

범주지표왜 보는가

지연	TTFT, TPOT	UX·SLA 위반 조기 감지
처리량	초당 토큰·요청, 대기열 길이	용량 한계 접근 감지
자원	GPU 사용률, 메모리/KV 캐시 점유(통합 메모리 환경에서는 런타임 가용량 기준)	OOM·포화 예방
안정성	오류율, 재시도율, fallback 발생률	장애 신호
라우팅	로컬/클라우드 분배 비율	정책 준수·비용 추적
품질	평가 세트 통과율	모델 교체·양자화 회귀 감지

특히 fallback 발생률과 라우팅 분배 비율은 로컬/클라우드 하이브리드에서 핵심 지표입니다. fallback이 잦아지면 로컬 용량 부족 신호이고, 라우팅 비율이 정책과 어긋나면 데이터가 잘못된 경계로 흐르고 있다는 신호입니다.

28. 구축 체크리스트

배치·선택 결정을 실제로 내릴 때 순서대로 점검할 항목입니다.

[제약 확정]
  ⬜ 데이터 분류(Public/Internal/Confidential/Restricted) 정의
  ⬜ 규제·계약상 반출 금지 데이터 식별
  ⬜ 망분리 대상 구간·워크로드 식별
  ⬜ 지연 목표(TTFT/TPOT)와 SLA 정의

[비용 모형]
  ⬜ 예상 처리량 산정(워크로드별)
  ⬜ 클라우드 변동비 vs 로컬 TCO 손익분기 계산
  ⬜ CapEx(GPU·정가 참고)·OpEx·인건비 항목화

[모델·서빙]
  ⬜ 후보 모델(Gemma 3/4, Qwen 등)·크기대 선정
  ⬜ 양자화(INT8/INT4, GPTQ/AWQ) 및 품질 회귀 평가
  ⬜ 하드웨어 메모리 산정(가중치+KV+오버헤드)
  ⬜ vLLM 서빙 구성(배치 지향/스트리밍) 분리
  ⬜ DGX Spark 단일/이중 구성 결정

[라우팅·복구]
  ⬜ 분류 기반 라우팅 정책 작성(default=거부, fail-closed)
  ⬜ 호출 직전 재분류(RAG·도구 결과 포함) 적용
  ⬜ fallback 방향·허용 한계(분류별)·장애 도메인 명시
  ⬜ Checkpoint + 멱등 키 + 중복 제거/Outbox + 상태 재조정으로 중복 부작용 통제

[온프레미스·망분리]
  ⬜ Gateway·Orchestrator 재배치(공통 계약 유지)
  ⬜ 로컬 MCP 도구·PostgreSQL+pgvector 배치
  ⬜ 오프라인 반입·업데이트 절차 확정

[운영]
  ⬜ 지연·처리량·자원·안정성·라우팅·품질 모니터링
  ⬜ fallback 발생률·라우팅 분배 비율 알람
  ⬜ 감사 로그(PII 마스킹·라우팅 기록·보존정책)

29. 흔한 함정과 회피법

마지막으로 배치 결정에서 반복적으로 보이는 함정을 정리합니다.

"클라우드냐 로컬이냐"의 이분법. 워크로드별로 나누지 않고 조직 전체를 한쪽으로 몰면, 어느 쪽이든 비효율·위험이 생깁니다. 데이터 분류 기반 하이브리드가 답입니다.
품질부터 비교하기. 제약(규제·망분리·주권)을 먼저 확정하지 않으면 배치 단계에서 뒤집힙니다.
GPU 정가만 TCO로 보기. 전력·운영·인건비·감가상각·규제 대응을 빼면 손익분기가 틀립니다.
양자화 후 품질 미검증. INT4로 큰 모델을 올렸다고 끝이 아닙니다. 자체 평가 세트로 회귀를 확인해야 합니다.
컨텍스트 한계치=사용량으로 착각. 128K를 다 쓰면 KV 캐시·지연이 폭증합니다. RAG로 선별이 우선입니다.
fallback을 무조건 클라우드로. Restricted 데이터를 클라우드로 넘기는 fallback은 규제 위반입니다. 분류별로 방향과 한계를 정해야 합니다.
Checkpoint 없는 fallback. 모델 교체 중 도구 부작용이 중복 실행됩니다.
로컬 상한을 그대로 사용. 200B/405B 같은 공개 상한은 "올라간다"는 뜻이지 원하는 동시성·컨텍스트를 보장하지 않습니다. 보수적으로 잡아야 합니다.

마무리

클라우드 API와 로컬 LLM 중 하나를 고르는 문제로 접근하면 대부분 틀립니다. 실제 결정은 워크로드별 배치의 집합입니다.

핵심을 다시 정리하면 다음과 같습니다.

품질이 아니라 제약(주권·규제·망분리·개인정보·지연·예산)에서 시작합니다.
데이터 분류로 워크로드를 나누고, 분류가 배치 위치를 결정합니다.
TCO는 GPU 정가가 아니라 전력·운영·감가상각·규제 대응까지 포함합니다.
로컬 후보는 Gemma 3/4와 Qwen 같은 오픈 웨이트 모델을 크기별로 나눠 배치하되, 세대별 라이선스(Gemma 3=Gemma Terms of Use, Gemma 4=Apache-2.0)와 상업 이용·재배포 조건을 각각 확인합니다.
양자화(INT8/INT4, GPTQ/AWQ)로 하드웨어에 맞추되 품질 회귀를 검증합니다.
vLLM의 PagedAttention·연속 배치로 처리량을 확보하고, 배치·스트리밍을 워크로드별로 분리합니다.
DGX Spark 128GB 통합 메모리에 맞춰 모델 크기를 보수적으로 산정합니다.
라우팅은 교체 가능한 Provider Core 위에 얹고, default를 가장 안전한 쪽으로 둡니다.
fallback은 양방향이며, 데이터 분류가 허용 범위를 제한합니다. Checkpoint 없이 붙이지 않습니다.
온프레미스·망분리에서는 코어를 유지한 채 배치와 의존성만 바꾸고, 감사와 모니터링을 필수로 둡니다.

로컬 모델을 상용에 올린다는 것은 "GPU에 모델을 띄운다"가 아니라, 교체 가능한 Provider Core 위에 로컬을 하나의 Provider로 얹고, 데이터 분류·라우팅·fallback·감사·모니터링까지 함께 설계한다는 뜻입니다. 클라우드와 로컬은 경쟁하는 선택지가 아니라, 같은 코어 뒤에서 워크로드에 따라 함께 쓰이는 두 개의 배치 형태입니다.

참고 자료

이 글은 2026년 7월 30일 기준 Google, Alibaba Cloud(Qwen), NVIDIA와 vLLM의 공개 공식 문서, 그리고 오픈 웨이트 모델(Gemma 3·4, Qwen)을 상용 운영하고 온프레미스·망분리 환경을 설계한 공개 가능한 구현 경험을 바탕으로 작성했습니다. 모델 세대·크기·라이선스, 하드웨어 스펙과 가격, 서빙·양자화 기능은 계속 바뀔 수 있으므로 실제 적용 시 각 공식 문서와 현재 버전을 다시 확인해야 합니다. 특정 지연·처리량·비용·정확도 수치는 하드웨어·모델·설정에 따라 크게 달라지므로 반드시 자체 환경에서 측정해야 합니다.

'엔터프라이즈 아키텍처' 카테고리의 다른 글

프라이빗 망 Server SDK 운영 안정성: 인증·재시도·멱등성과 관측성 (1)	2026.07.31
폴리글랏 보안 계약 검증: Java↔Python Golden Vector와 Canonical Byte (0)	2026.07.30
엔터프라이즈 AI Agent 권한 설계: 사용자·테넌트·Tool 인가와 감사 로그 (1)	2026.07.30
운영 가능한 AI Agent 만들기: Checkpoint, Retry, Idempotency와 Outbox (0)	2026.07.29
기업용 AI 백엔드 설계: Java Security Gateway와 Python AI Orchestrator의 책임 분리 (0)	2026.07.29

현재글클라우드 API vs 로컬 LLM: 망 분리·비용·프라이버시로 정하는 배치 기준

AI 아키텍처 기술 블로그

수년간 개발 경험으로 전하는 AI 에이전트, RAG, MCP와 시스템 아키텍처 실전 기록

java, faster-whisper, owasp top 10, Production Readiness, embedding, ai 도입, MCP 보안, Secure coding, Spring Security, Rag, Private API, ai agent, SDK 설계, AI Agent 보안, STT, 엔터프라이즈 아키텍처, spring boot, mcp, tool calling, 기업 AI Agent,

Today :
Yesterday :

AI 아키텍처 기술 블로그