제8부 운영·LLMOps

8.4 온프레미스·프라이빗·엣지 배포

어느 회사의 보안팀이 이런 결론에 도달했다고 하자. "우리 데이터는 밖으로 못 내보낸다. 그러니 자체 GPU를 사서 우리 데이터센터에서 모델을 돌리자." 반년 뒤 그 팀은 세 가지를 발견한다. 첫째, 자체호스팅으로 굴릴 수 있는 오픈웨이트 모델이 원래 쓰려던 폐쇄 API의 모델보다 몇몇 태스크에서 눈에 띄게 약하다. 둘째, 사둔 GPU가 하루 대부분 15% 남짓 활용률로 대부분 유휴 상태이고, 유휴 상태여도 전력·감가·인건비는 그대로 나가서 결국 API를 그대로 썼을 때보다 토큰당 비용이 더 비용이 크다. 셋째, "데이터가 밖으로 안 나가니 안전하다"고 믿었는데, 보안 패치가 벤더 클라우드처럼 자동으로 오지 않아 알려진 취약점에 몇 주씩 노출된 채로 운영되고 있다. 이 팀이 틀린 것은 아니다 — 데이터가 물리적으로 나가지 않아야 하는 실제 이유가 있었을 수도 있다. 틀린 것은 "밖으로 안 내보낸다"는 요구가 곧 "온프레미스 에어갭"을 뜻한다고 건너뛴 것, 그리고 온프레미스가 자동으로 더 안전하고 더 저렴하다고 가정한 것이다.

이 장은 그 건너뜀을 분해한다. "온프레미스냐 클라우드냐"는 이분법이 아니라 연속적인 스펙트럼이고, "프라이빗"이라는 한 단어가 서로 매우 다른 다섯 지점을 가린다. 여기서 다루는 세 가지 — 우리 데이터센터에서 직접 서빙하는 온프레미스, 클라우드를 쓰되 격리·전용 자원에 배포하는 프라이빗 클라우드·VPC, 서버가 아니라 사용자의 기기 위에서 모델을 실행하는 엣지·온디바이스 — 는 하나의 질문을 공유한다. 데이터와 모델을 우리(또는 사용자) 손 안에 두면 무엇을 얻고 무엇을 내주는가. 답은 대부분의 서비스에서 "매니지드 API가 옳고, 온프레미스·엣지는 특정 요구가 그 대가를 정당화할 때 고르는 선택지"다. 이 장 내내 반복될 문장은 하나다. 온프레미스·엣지는 더 안전하거나 더 저렴한 것이 아니라, 책임과 비용의 구조를 바꾸는 거래다. 데이터가 우리 손에 있다고 안전해지지 않는다 — 보안·패치·가용성의 책임이 벤더에서 우리로 옮겨 올 뿐이다. 이 거래가 남는지는 그 대가를 정당화하는 동인이 실제로 있느냐로 정해진다.

한 가지 미리 명시해 둘 것. 이 장에 나오는 모델 능력·크기·하드웨어 가격·GPU 시간당 요율은 시점과 벤더에 따라 바뀌므로 특정 숫자를 사실로 단정하지 않는다 — 개략 규모를 보여 주는 개략값이고, 실제 결정은 배포 시점의 값으로 다시 계산해야 한다. 특정 벤더의 프라이빗 배포 옵션·모델 ID·가격은 기억으로 지어내지 말고 공식 문서(Anthropic이라면 claude-api)에서 확인한다.

8.4.1 배포 스펙트럼 — 매니지드 API에서 온디바이스까지

배포 형태를 한 줄에 늘어놓으면 세 개의 축이 동시에 맞바뀐다. 왼쪽(공용 API)에서 오른쪽(온디바이스)으로 갈수록 컨트롤과 데이터 잔류(residency) 는 커지고, 운영·보안·조달 부담도 함께 커지며, 최상위 폐쇄 모델의 능력 접근은 대개 줄어든다. 이 셋이 서로 반대 방향으로 움직인다는 사실이 이 장 전체의 저류다 — 오른쪽으로 갈 때 컨트롤을 얻는 대가로 부담과 능력 격차를 산다.

이 그림에서 실무적으로 가장 큰 오해를 먼저 걷어내자. "프라이빗"은 오른쪽 끝에서만 생기는 것이 아니다. 데이터 잔류와 격리는 스펙트럼 ②(전용/VPC 엔드포인트)에서도 상당 부분 얻을 수 있다. 요구가 "데이터가 우리 리전·우리 계정을 벗어나면 안 된다"라면 ②③이 답일 때가 많고, "인터넷과 물리적으로 끊겨야 한다"라면 그제서야 ④가 답이다. 많은 팀이 프라이버시라는 목표를 온프레미스라는 수단과 등치시키는데, 요구를 정확히 좁히면 스펙트럼 위 위치가 훨씬 왼쪽으로 정해지는 경우가 대부분이다. 이 장의 실용적 목표는 그 좁히기다.

오른쪽으로 갈 때 치르는 가장 큰 대가는 흔히 성능이나 비용이 아니라 능력이다. 최상위 폐쇄 모델은 대개 공용/전용 API로만 접근되고, 자체호스팅할 수 있는 오픈웨이트 모델은 그에 못 미칠 수 있다. 이 능력 축이 컨트롤 축과 반대로 움직인다는 것 — 통제를 더 쥘수록 최전선 능력에서 멀어질 수 있다는 것 — 을 앞으로 여러 절에서 정면으로 따진다.

8.4.2 다섯 개의 동인 — 무엇이 이 결정을 정당화하는가

온프레미스·프라이빗을 고르는 이유는 흔히 "왠지 더 안전할 것 같아서"라는 막연한 불안으로 뭉뚱그려진다. 그러나 실무에서 이 결정을 정당화하는 것은 구체적이고 서로 다른 다섯 가지 동인이며, 각각이 요구하는 배포 형태가 다르다. 동인을 혼동하면 반드시 과잉 대응한다 — 데이터 레지던시가 이유인데 에어갭 온프레미스를 짓는 식으로. 그러니 먼저 다섯을 정확히 이름 붙인다.

데이터 레지던시·규제. 가장 흔한 동인이다. 법·규제·계약이 데이터가 특정 관할(국가·리전)이나 특정 경계를 벗어나는 것을 금지한다. 개인정보·의료·금융 데이터가 물리적으로 특정 국가·리전 안에 머물러야 하는 요건 — GDPR, 각국 개인정보보호법, 데이터 지역화(localization) 규정, 의료·금융 규제 — 이 여기 속한다(구체 요건과 관할별 차이는 9.3에서). 결정적인 것은 이 요구가 대개 온프레미스까지 안 가도 충족된다는 점이다. 해당 리전의 VPC나 전용 엔드포인트면 "데이터가 이 리전을 벗어나지 않는다"를 만족할 수 있다. 다만 매니지드 벤더가 그 리전을 제공하는지, 프롬프트·출력·로그가 어디에 저장되고 학습에 쓰이는지를 계약·설정으로 확인해야 한다. "온프레미스여야만 규제를 지킨다"는 오해가 흔한데, 실제 규정 문구는 대개 "리전 이탈 금지 + 특정 처리 통제"이지 "인터넷 단절"이 아니다. 요구를 규정 문구 그대로 읽어야 과잉 대응을 피한다.

기밀·영업비밀. 규제와 별개로, 넘겨서는 안 되는 내용 자체가 문제일 수 있다 — 소스코드, 미공개 M&A 정보, 방산·국가기밀, 핵심 R&D. 규제가 외부 처리를 허용하더라도 조직의 위험 감수 수준이 "이 데이터는 어떤 외부 API에도 넣지 않는다"일 수 있다. 이 동인은 흔히 더 오른쪽(온프레미스·에어갭)을 요구한다. "벤더가 안 본다는 계약"으로 충분치 않고 "물리적으로 나갈 수 없음"을 요구하기 때문이다. 다만 여기서 자주 빠지는 함정이 있다. 기밀 유출 경로는 데이터의 물리적 이동만이 아니다. 프롬프트 인젝션이나 모델을 통한 데이터 유출(7.4)은 온프레미스에서도 똑같이 일어난다. 온프레미스는 "외부 벤더로의 이동"이라는 한 경로를 막을 뿐, 내부 접근통제·출력 필터링이라는 다른 경로는 여전히 우리가 지켜야 한다.

지연. 이것은 물리 법칙이다 — 네트워크 왕복이 곧 지연이고, 로컬·엣지에서 실행하면 그 왕복 자체가 사라진다. 실시간 자동완성, 받아쓰기, 오프라인 동작(비행기·지하·현장), 개인화 키보드처럼 왕복 수십~수백 밀리초가 UX를 좌우하고 네트워크가 불안정하거나 아예 없을 수 있는 상황에서 온디바이스가 이긴다. 그런데 여기에 반드시 재봐야 할 함정이 있다. 지연에는 네트워크 지연과 생성 지연(TTFT·TPOT, 5.1)이 있는데, 온디바이스는 네트워크 왕복을 없애는 대신 약한 하드웨어에서 생성 자체가 느려져 총 지연이 오히려 더 나빠질 수 있다. 데이터센터 GPU의 빠른 생성이 네트워크 왕복을 상쇄하고도 남는 경우가 흔하다. "로컬이니 당연히 빠르다"는 검증 없이는 참이 아니다.

대규모의 비용. 트래픽이 크고 꾸준하면, 토큰당 API 요금이라는 변동비보다 자체 GPU의 고정비 상각이 저렴해지는 손익분기가 온다. 이 동인의 핵심 조건은 "크고 꾸준"에서 꾸준함이다. 불균일한 트래픽은 GPU를 유휴 상태로 두고, 유휴 상태로 두는 GPU는 매니지드보다 비용이 크다 — 이 계산은 8.4.12에서 직접 밟는다. 이 동인은 활용률이라는 조건이 붙어야만 성립하며, GPU 시간당 비용만이 아니라 운영 인건비·조달·전력·감가상각을 모두 넣은 총소유비용으로 따져야 한다.

에어갭·완전 격리. 가장 극단이다 — 시스템이 인터넷과 물리적으로 단절되어야 한다. 방산, 기밀 연구망, 중요 인프라의 제어망, 일부 정부·금융 내부망이 여기 속한다. 온프레미스이면서 외부 네트워크가 아예 없다는 것은 배포뿐 아니라 업데이트·패치·모델 전달의 방식 전체를 바꾼다(8.4.9) — pip install이 안 되는 세계다. 실제 에어갭이 필요한 조직은 소수다. "보안이 중요하다"와 "에어갭이 필요하다"는 전혀 다른 요구이며, 대부분은 전자이고 후자는 훨씬 강한 제약이다.

이 다섯을 요구와 배포 형태로 대응시키면 스펙트럼 위 위치가 좁혀진다.

온프레미스·엣지를 검토하기 전에 어느 동인 때문인지를 한 문장으로 적을 수 있어야 한다. 동인이 흐릿하면 십중팔구 과잉 대응이고, 동인이 분명하면 그것이 배포 형태를 거의 결정한다. 이 장의 나머지는 각 지점에서 실제로 무엇이 부과되는지를 다룬다.

8.4.3 프라이빗 클라우드·VPC·전용 엔드포인트

"프라이빗"의 대부분은 온프레미스가 아니라 클라우드 안의 격리로 달성된다. 앞의 스펙트럼에서 ②③이 여기이고, 데이터 레지던시가 동인인 다수의 팀이 실제로 착지하는 지점이다. 갈래는 셋이다.

전용/프라이빗 엔드포인트(②). 벤더의 모델을 쓰되 공용 멀티테넌트 엔드포인트가 아니라 내 계정 전용·격리된 엔드포인트로 호출한다. 흔한 형태는 트래픽이 공용 인터넷이 아니라 클라우드 내부 사설 네트워크로만 흐르는 프라이빗 링크, 특정 리전에서만 처리·저장하는 리전 고정, 그리고 프롬프트·출력을 학습에 쓰지 않고 보존하지 않는다는 계약이다. 운영은 여전히 벤더가 한다 — 스케일·패치·가용성이 벤더 몫이다. 데이터 잔류와 격리를 얻으면서 운영 부담은 낮게 유지하는 절충이고, 여기서 결정적으로 얻는 것은 최상위 폐쇄 모델의 능력을 격리된 채로 쓸 수 있다는 점이다. 특정 벤더가 어떤 프라이빗 옵션을 제공하는지는 공식 문서로 확인해야 한다(Anthropic이라면 claude-api).

매니지드 오픈모델 엔드포인트(②~③ 경계). 오픈웨이트 모델(9.2)이나 내가 파인튜닝한 모델을 클라우드·추론 제공자의 관리형 GPU 엔드포인트에 배포한다. 내부적으로 vLLM·TGI류(5.4)가 실행되지만 오토스케일·패치는 벤더가 관리한다. 내 모델을 쓰되 인프라는 안 만지는, 두 세계의 중간이다.

VPC 셀프호스트(③). 내 클라우드 계정의 격리된 VPC 안, 내가 임대한 GPU 인스턴스에 vLLM·TGI·SGLang·TensorRT-LLM(5.4)을 직접 추가해 운영한다. 데이터가 내 계정·내 VPC를 벗어나지 않으며 서빙 스택 전체를 통제한다 — 커널·양자화·스케줄까지. 대신 GPU 운영·오토스케일·용량 계획·장애 대응(5.5)이 전부 내 몫이 된다.

무엇이 ②와 ③의 갈림을 정하는지 나란히 보면 선택 기준이 선다.

데이터가 리전·계약 안에 머물면 충분하고 최상위 폐쇄 모델의 능력이 필요하면 전용 엔드포인트가 경량이고 강하다. 모델·인프라를 완전히 통제해야 하고 오픈웨이트로 충분하면 VPC 셀프호스트다. 온프레미스(④)는 이 둘로 안 되는 요구 — 에어갭, 물리 통제, 클라우드 자체를 금지하는 규제 — 일 때만 정당화된다.

여기서 계약 전에 반드시 캐물어야 할 것이 있다. "프라이빗 배포"라는 말은 벤더마다 다른 것을 가리킨다. 트래픽 경로가 정말 사설망인가 아니면 공용 API에 인증만 붙인 것인가. 프롬프트·출력·로그가 어디에 저장되고 얼마나 보존되며 학습에 쓰이는가. 처리·저장 리전이 고정되는가. 격리가 네트워크 수준인가 전용 하드웨어 수준인가(멀티테넌시가 남아 있는가). 감사·인증(SOC 2·ISO 27001 등)과 계약상 책임은 어디까지인가. 이 질문들에 명확한 답이 없으면 "프라이빗"은 마케팅 단어일 뿐이다. 그리고 이 확인은 요구(8.4.2)에 대응시켜 필요한 것만 한다 — 레지던시가 동인이면 리전과 보존을, 기밀이 동인이면 격리 수준을 캐물으면 된다.

8.4.4 엣지·온디바이스 — 왜 강한 양자화가 필수인가

스펙트럼의 오른쪽 끝(⑤)은 성격이 근본적으로 다르다. 모델이 사용자의 기기 위에서 실행된다 — 서버가 없다. 데이터가 기기를 안 떠나므로 프라이버시·오프라인·지연에서 강하지만, 소형 모델의 능력 상한과 기기 이질성이라는 대가를 치른다. 이 자리를 이해하려면 왜 온디바이스가 반드시 작고 강하게 양자화된 모델로 수렴하는지부터 봐야 한다.

온디바이스의 병목은 연산이 아니라 메모리다. 휴대폰·노트북은 데이터센터 GPU의 수십~수백 분의 일 메모리를 가진다. 그래서 두 가지가 동시에 필요하다. 하나는 소형 모델 — 파라미터 수를 수억~수십억 규모로 줄이거나(증류로 큰 모델의 능력 일부를 옮기거나 애초에 작게 학습한 모델), 다른 하나는 강한 양자화(5.2)다. FP16 가중치를 4비트급(GGUF의 Q4_K_M류, AWQ 등)으로 낮춰 메모리를 대략 4분의 1로 줄인다. 온디바이스에서는 데이터센터보다 더 공격적인 양자화를 감수한다 — 품질을 일부 내주고서라도 기기에 들어가야 하기 때문이다. 긴 컨텍스트를 다뤄야 하면 KV 캐시 양자화까지 더해 컨텍스트의 메모리도 깎는다.

가중치 메모리는 정확한 산식으로 나온다.

$$\text{가중치 메모리} \approx P \times \frac{\text{비트/파라미터}}{8} \ \text{바이트}$$

여기서 $P$ 는 파라미터 수다. 숫자를 넣어 개략을 파악하자. 30억(3B) 파라미터 모델을 4비트로 양자화하면 가중치가 $3\times10^9 \times \tfrac{4}{8} = 1.5\times10^9$, 즉 약 1.5 GB다. 같은 모델을 FP16으로 두면 6 GB, 8비트로 두면 3 GB이니 4비트가 얼마나 결정적인지 보인다. 10억(1B) 모델은 4비트에 0.5 GB, 70억(7B) 모델은 4비트에 3.5 GB다. 그런데 이것이 전부가 아니다 — 여기에 KV 캐시(컨텍스트 길이에 선형, 5.1)와 활성값·런타임 오버헤드가 더 붙고, 무엇보다 이 전부가 기기 RAM에서 다른 앱과 공존해야 한다. 8 GB RAM 폰이라면 OS와 다른 앱이 상당 부분을 이미 점유하고 있어 실제로 쓸 수 있는 것은 흔히 2~4 GB 남짓이다. 그래서 3B 4비트(1.5 GB 가중치 + 여유)는 여유 없이 들어가지만 7B는 무리인 경우가 많고, 온디바이스가 흔히 수 GB 이하 모델로 수렴하는 이유가 이 계산에 있다. 노트북은 사정이 훨씬 낫지만(수십 GB RAM), 그래도 데이터센터의 여유와는 자릿수가 다르다.

이 메모리 장벽이 온디바이스의 모든 설계 결정을 지배한다. 어떤 크기의 모델을 번들할지, 어떤 양자화를 쓸지, 컨텍스트를 얼마나 허용할지가 전부 "이 기기 RAM에 들어가는가"에서 역산된다. 서버 서빙에서는 배치를 키워 처리량을 극대화하는 것이 문제였다면(5.1), 온디바이스에서는 배치 1을, 그것도 제한된 메모리 안에서 실행하는 것이 문제다.

8.4.5 온디바이스 런타임·타깃과 능력의 상한

온디바이스는 타깃(어디서 도느냐)에 따라 런타임과 제약이 갈린다. 넷으로 나누면 지형이 보인다.

이 지형에서 사실상 표준은 llama.cpp와 GGUF다. C/C++로 짜여 이식성이 넓고, GGUF 양자화 포맷과 OpenAI 호환 llama-server로 로컬·엣지 전반에서 폭넓게 쓰인다. Ollama는 그 위에 추가된 개발자 친화 래퍼로, 모델 내려받기와 실행을 한 줄로 만든다. 애플 생태계에서는 MLX가 Apple Silicon의 통합 메모리와 Metal을 직접 활용해 노트북·맥에서 강하다.

브라우저(WebGPU)는 배포 방식이 특히 독특하다. 설치 없이 탭에서 실행되고 데이터가 클라이언트에 머무는데, 대신 모델을 브라우저로 내려받아야 하고(수백 MB~GB) WebGPU를 지원하는 브라우저·기기가 필요하다. 첫 방문의 다운로드 비용과 캐싱 전략, 지원 브라우저 범위가 실제 제약이 된다. 그럼에도 "서버에 아무것도 안 보내고 탭 안에서 추론"이라는 성질은 특정 프라이버시 요구에 정확히 들어맞는다.

이제 미화하지 말고 능력을 말하자. 온디바이스 모델은 작은 모델이다. 일반 추론·지식·복잡한 다단계 작업에서 최상위 클라우드 모델에 크게 못 미치고, 긴 컨텍스트·복잡한 도구 사용·정밀한 지시 따르기에서 약하다. 적합한 자리는 좁고 잘 정의된 태스크다 — 자동완성, 요약, 분류, 간단한 재작성, 정형 추출, 개인화 키보드, 오프라인 받아쓰기. 넓은 대화나 에이전트에는 부적합할 때가 많다. "이제 폰에서도 GPT급이 돈다"는 흔한 과장인데, 폰에서 실행되는 것은 작은 모델이고 특정 좁은 태스크에서는 훌륭하지만 최상위 대형 모델의 일반 능력과 동급이 아니다(모델·태스크에 따라 다르므로 벤치마크 함정 4.1를 조심할 것). 온디바이스의 실제 가치는 "동급 능력"이 아니라 프라이버시, 오프라인, 지연, 그리고 추론 비용이 0이라는 점 — 사용자의 기기가 계산을 대신하므로 서버 GPU 비용이 발생하지 않는다는 데 있다. 능력 한계는 온디바이스를 "전부"로 보지 않고 1차 필터·오프라인 폴백으로 설계해 우회한다. 쉬운 것과 민감한 것은 기기에서, 어려운 것은 클라우드로 — 이것이 8.4.10의 하이브리드다.

8.4.6 능력 격차 — 자체호스팅의 상한

온프레미스·엣지의 가장 큰 대가는 성능이나 비용이 아니라 흔히 능력 격차다. 자체호스팅은 대개 오픈웨이트 모델(9.2)을 뜻하고, 오픈웨이트의 최상위가 폐쇄 최상위 모델에 못 미칠 수 있다. 이 격차의 성질을 정확히 봐야 결정을 그르치지 않는다.

격차는 실재하지만 유동적이다. 어느 시점엔 오픈웨이트가 폐쇄 최상위에 근접했다가, 폐쇄 쪽이 새 세대를 내면 다시 벌어진다 — 이 간격은 몇 달 단위로 변동한다. 그래서 "오픈이 이제 폐쇄를 따라잡았다"도 "오픈은 폐쇄를 못 따라간다"도 시점·태스크·모델을 못 박지 않으면 둘 다 위험한 단정이다. 게다가 격차는 태스크마다 다르다. 코딩·요약·분류 같은 태스크에서는 좋은 오픈웨이트로 충분한 경우가 많고, 최전선 추론·에이전트·롱컨텍스트·안전성에서는 폐쇄 최상위가 앞설 때가 많다. 그리고 크기가 다시 문제를 키운다. 자체호스팅 가능한 크기 — 즉 우리 하드웨어 예산 안에 들어오는 크기 — 로 내려오면 격차가 더 벌어진다. 온프레미스 예산으로 굴릴 수 있는 모델은 흔히 최상위 오픈웨이트보다도 작기 때문이다.

이 격차를 그대로 받아들일 필요는 없다. 좁히는 수단이 여럿이다. 도메인 파인튜닝(8.3)은 좁은 도메인에서 잘 튜닝한 소형 오픈웨이트가 범용 대형 모델을 특정 태스크에서 능가하게 만들 수 있다 — 일반 능력이 아니라 내 태스크 성능이 중요하다면. RAG(6.3·6.4)는 지식 격차를 검색으로 메운다 — 모델이 세상을 다 알 필요는 없다. 추론 스캐폴딩(사고사슬·검증·도구·에이전트 루프, 3.7·6.6)은 약한 모델의 실질 성능을 높인다. 그리고 하이브리드 라우팅(8.4.10)은 어려운 질의만 폐쇄 대형으로 보내 격차를 그 소수 질의에서만 치르게 한다.

핵심은 이것이다. "오픈웨이트가 폐쇄에 못 미친다"는 일반 벤치마크 명제이지 내 태스크 명제가 아니다. 결정은 벤치마크 순위가 아니라 내 평가셋(4.1·4.2)에서 후보 모델이 요구를 넘느냐로 내려야 한다. 못 넘으면 격차가 실제 비용이고, 넘으면 격차는 나와 무관하다. 온프레미스로 가야 하는 강한 동인이 있는데 후보 오픈웨이트가 내 평가셋을 통과하지 못한다면, 그때 비로소 능력 격차가 이 결정의 실질적 대가로 비용에 반영된다.

8.4.7 하드웨어 요구와 조달 — VRAM을 직접 계산하기

매니지드에서는 안 보이던 문제가 온프레미스·VPC 셀프호스트에서 전면에 나온다 — GPU를 실제로 구해서 실행해야 한다. 그리고 그 첫 관문은 "이 모델을 서빙하려면 VRAM이 얼마나, GPU가 몇 장 필요한가"라는 질문이다. 매니지드에서는 벤더가 흡수하던 이 계산을 이제 우리가 직접 해야 한다. 직접 밟아 보자.

서빙에 필요한 VRAM은 세 부분이다 — 모델 가중치, KV 캐시, 그리고 활성값·프레임워크 워크스페이스 오버헤드다.

$$\text{VRAM} \approx \underbrace{P \times b_w}_{\text{가중치}} \;+\; \underbrace{2\, n_{\text{layers}}\, n_{\text{kv}}\, d_{\text{head}}\, b_{kv}\, L\, B}_{\text{KV 캐시}} \;+\; \underbrace{\text{활성·워크스페이스}}_{\text{오버헤드}}$$

70B급 오픈웨이트 모델을 자체 서빙한다고 하자. 가중치부터 본다. FP16($b_w=2$)이면 $70\times10^9 \times 2 = 140$ GB다. 이것만으로 80 GB GPU 한 장을 이미 넘긴다. 8비트로 양자화하면(5.2) 70 GB, 4비트면 35 GB로 내려온다. 정밀도를 낮추는 것이 단지 "메모리 절약"이 아니라 몇 장의 GPU가 필요한가를 바꾸는 결정임을 여기서 볼 수 있다.

KV 캐시는 컨텍스트와 배치에 선형으로 증가한다. 이 70B가 80개 층, GQA로 KV 헤드 8개, $d_{\text{head}}=128$, KV를 FP16($b_{kv}=2$)으로 둔다고 하면 토큰 하나가 남기는 KV는

$$2 \times 80 \times 8 \times 128 \times 2 = 327{,}680 \text{ bytes} \approx 320 \text{ KB/토큰}$$

컨텍스트 $L=8192$ 짜리 요청 하나면 $320\text{ KB} \times 8192 \approx 2.6$ GB, 동시에 32건($B=32$)을 처리하면 $2.6 \times 32 \approx 84$ GB다. 여기서 결정적인 관찰이 나온다 — 배치 32의 KV 캐시(84 GB)가 8비트 가중치(70 GB)보다 크다. 서빙 용량을 모델 가중치 크기만으로 계획하면 반드시 문제가 생기는 이유가 이것이다. "70B니까 8비트로 70 GB면 되겠지"는 배치를 조금만 키워도 틀린다.

세 부분을 합쳐 보자. 8비트 가중치(70 GB) + KV 배치 32·컨텍스트 8192(84 GB) + 활성·워크스페이스 여유(대략 10% 남짓, ~15 GB로 가정하자)면 총 약 169 GB다. 80 GB GPU로는 세 장이 필요하고, 그러면 모델을 여러 GPU에 분할하는 텐서·파이프라인 병렬(2.4)과 그것을 잇는 고속 인터커넥트(NVLink·InfiniBand류, 2.5)까지 따라온다. 배치를 8로 줄이면 KV가 21 GB로 내려가 총 약 100 GB — 두 장이면 된다. 가중치를 4비트로 더 낮추면(35 GB) 배치 32·8192에서도 $35+84+12 \approx 131$ GB로 두 장에 여유 없이 든다. 같은 모델, 같은 트래픽인데 정밀도와 배치 정책만으로 필요한 GPU가 두 장과 세 장 사이에서 변동한다. 이 계산이 곧 조달 규모이고 곧 비용이다.

그리고 이것은 소프트웨어 문제로 끝나지 않는다. 데이터센터급 GPU는 주문해서 받기까지 시간이 걸릴 수 있고(수요·공급·시점에 따라), 클라우드가 클릭 한 번이면 기동되는 것과 달리 온프레미스는 물리 배송·설치가 있다. GPU 랙은 전력과 발열이 커서 기존 사무실 전산실로는 안 되는 경우가 많고, 전력 용량·냉각·상면(rack space)이 실제 제약이 된다. 하드웨어 고장·교체·펌웨어·드라이버·물리 접근통제까지 전부 운영 인력의 몫이다. 그래서 조달 모델을 고를 때 "온프레미스"가 반드시 장비 구매를 뜻하지 않는다는 점이 중요하다.

격리·잔류 요구는 베어메탈 임대나 코로케이션, VPC로 자본지출 없이 상당 부분 충족된다. 에어갭이나 물리 통제가 실제 필요할 때만 자체 구매로 간다 — 리드타임·시설·감가상각 전체를 부담하기 때문이다. 하드웨어 조달을 과소평가하면 프로젝트가 소프트웨어가 아니라 물류에서 막힌다.

8.4.8 셀프호스트 라이선스 — 받을 수 있다고 써도 되는 것은 아니다

"오픈웨이트"는 "무엇이든 해도 된다"가 아니다. 가중치를 내려받을 수 있다는 것과 그것을 상업적으로·자체호스팅으로 써도 된다는 것은 전혀 다른 문제다. 배포 전에 반드시 통과해야 하는 법적 관문이고, 여기서 막히면 앞의 모든 계산이 무의미해진다. 라이선스 생태계 전반은 9.2, 저작권·법의 세부는 9.3에서 다루므로 여기서는 배포 관점의 체크만 다룬다.

라이선스는 스펙트럼을 이룬다. 관대한 오픈소스(Apache 2.0·MIT류)는 상업·자체호스팅·수정이 대체로 자유롭지만 그래도 조건은 확인해야 한다. 커뮤니티·맞춤 라이선스는 상업이용을 허용하되 사용자 규모, 용도, 수용정책(AUP), 재배포 조건이 붙을 수 있다 — 예컨대 특정 사용자 수를 넘으면 별도 계약이 필요하거나 특정 산업·용도를 금지하는 식이다. 비상업·연구 전용 라이선스는 프로토타입에는 되지만 프로덕션 상업 서비스에는 못 쓴다. 게이티드 모델은 접근 신청과 약관 수락을 요구하며, 특히 파인튜닝 결과물의 조건을 살펴야 한다.

배포 전에 던져야 할 질문은 구체적이다. 상업이용이 허용되는가(연구 전용이면 프로덕션 불가). 자체호스팅과 재배포가 허용되는가 — 온프레미스 배포, 컨테이너 이미지 배포, 엣지 번들이 조건에 걸리지 않는가. 규모·용도 제한이 있는가. 파인튜닝한 가중치와 모델 출력의 소유·재배포 권리는 누구에게 있는가(8.3). 그리고 흔히 놓치는 것 — 모델뿐 아니라 학습·추론 스택, 함께 배포하는 데이터·토크나이저의 라이선스도 봐야 한다. 서빙 프레임워크의 라이선스마저 개정된다(5.4의 TGI 라이선스 변경 이력이 그 예다). 모델·프레임워크·데이터 세 겹의 라이선스를 반드시 배포 시점 기준으로 확인하고, 애매하면 법무 검토를 받는다. 라이선스는 시간이 지나면 바뀌므로, 반년 전에 괜찮았다는 것이 지금도 괜찮다는 보장은 아니다.

8.4.9 에어갭 — pip install이 없는 세계

에어갭은 배포뿐 아니라 모든 유입·유출을 바꾼다. 인터넷이 없으므로 pip install, git clone, 모델 허브 다운로드, 라이선스 서버 호출, 원격 텔레메트리가 전부 불가하다. 개발 환경에서 당연하게 여기던 "필요하면 받아 온다" 전체가 사라지는 것 — 이것이 에어갭 운영의 본질적 난제다.

작동 방식은 "모든 것을 미리 통째로 가져온다"로 요약된다. 모델 가중치, 파이썬 휠과 시스템 패키지, CUDA·드라이버, 컨테이너 이미지, 심지어 토크나이저와 설정까지 번들로 만들어 물리 매체(또는 단방향 게이트웨이·데이터 다이오드)로 반입한다. 에어갭망 안에는 프라이빗 패키지 인덱스, 컨테이너 레지스트리, 모델 저장소를 세워 내부에서는 그것을 바라보게 한다. 반입하는 모든 아티팩트는 버전을 고정(pin)하고 해시·서명으로 무결성을 검증한다 — 승인된 버전만 들어가는 공급망 통제다. 그리고 외부로 나가는 모든 텔레메트리·라이선스 서버 호출을 제거·차단해야 한다. 안 그러면 도구가 조용히 실패하거나 보안 정책을 위반한다.

여기서 사람이 가장 많이 빠지는 함정이 "오프라인 지원"에 대한 낙관이다. 많은 도구가 첫 실행에 무언가를 다운로드한다 — 가중치, 토크나이저, 폰트, 모델 카드. 에어갭에서는 정확히 그 지점에서 조용히 멈춘다. 그러니 반입 전에 오프라인 실행을 미리 검증해야 한다. 두 번째 함정은 업데이트가 느리고 비용이 크다는 것이다. 보안 패치조차 수집→스캔→승인→물리 반입→검증→배포의 절차를 거치므로 패치 주기가 길어지고, 그동안 알려진 취약점에 노출된다. 이것 자체가 리스크다 — 뒤에서 보겠지만 에어갭은 "인터넷과 끊겨서 안전"이 아니라 "패치가 늦어서 위험"일 수 있다. 세 번째, 반입한 새 버전이 회귀를 일으켜도 밖에서 못 고치니 이전 버전 아티팩트를 보관하고 롤백 절차를 갖춰야 한다(8.2). 그리고 무엇을·언제·누가 반입했는지의 변경 이력이 에어갭일수록 생명이다.

8.4.10 하이브리드 — 민감·쉬운 것은 로컬, 어려운 것만 클라우드

온프레미스·엣지의 능력·비용 한계와 클라우드의 프라이버시·격리 한계를 동시에 피하는 절충이 하이브리드다. 발상은 단순하다 — 모든 질의를 같은 곳으로 보내지 않는다. 민감하거나 쉬운 질의는 로컬 소형 모델이, 민감하지 않고 어려운 질의는 클라우드 대형 모델이 처리하도록 라우팅한다(모델 라우팅·캐스케이드의 일반형은 5.6). 실무에서 "온프레미스 전부"와 "클라우드 전부" 사이의 가장 실용적인 지점일 때가 많다.

두 축으로 가른다. 민감도 축에서는 PII·기밀이 포함된 질의를 경계 안 로컬 모델에서만 처리하거나, 마스킹·비식별화 후에만 클라우드로 보낸다. 마스킹으로도 재식별 위험이 남으면 아예 안 보낸다(9.3). 난이도 축에서는 쉬운 질의(분류·자동완성·정형 추출)를 로컬 소형으로 처리하고, 어려운 질의(복잡 추론·긴 컨텍스트·창의)만 클라우드 대형 모델로 이관해 능력 격차를 그 소수에서만 산다. 이 둘을 캐스케이드로 결합하면 — 로컬이 먼저 답하고 신뢰도가 낮으면서 비민감이면 클라우드로 에스컬레이션 — 비용·프라이버시·능력을 동시에 최적화하는 흔한 패턴이 된다.

하이브리드의 급소는 "판정 자체를 어디서 하나"다. 민감도·난이도를 판정하려면 질의 내용을 봐야 하는데, 그 판정을 하려고 원문을 클라우드로 보내면 프라이버시 목적이 그 자리에서 붕괴한다. 따라서 라우팅 판정 — 민감도 분류와 난이도 추정 — 은 반드시 로컬에서 일어나야 한다. 그리고 이 분류기의 정확도가 곧 리스크이자 품질이다. 민감도 분류기가 과소탐지하면 기밀이 클라우드로 유출되고, 과대탐지하면 모든 것이 로컬로 몰려 품질이 떨어지고 하이브리드의 이점이 사라진다. 그래서 이 분류기의 정확도·재현율을 평가하고(4.2) 지속적으로 모니터링해야(7.6) 한다. 클라우드로 나가는 것은 마스킹·비식별화를 거치되, 마스킹이 완전하다고 가정하면 안 된다 — 문맥으로 재식별될 수 있다. 하이브리드는 능력·비용·프라이버시를 동시에 확보하는 대신 라우팅 정확도·마스킹·감사라는 새 책임을 만든다.

8.4.11 "온프레미스가 더 안전하다"는 착각

이 절과 다음 절이 이 장에서 가장 중요하다. 온프레미스·프라이빗을 둘러싼 두 통념을 정면으로 깬다. 첫째는 안전에 관한 것이다.

온프레미스는 더 안전한 것이 아니라, 보안 책임이 벤더에서 우리로 이전되는 것이다. 이 차이가 전부다. 매니지드 벤더는 전담 보안팀, 자동 패치, 물리 보안, 규정 준수 인증(SOC 2·ISO 27001 등)에 상시 투자한다. 온프레미스로 옮기면 그 전부가 우리 책임이 된다. 우리 보안 성숙도가 벤더보다 높다면 실제로 더 안전해질 수 있지만, 낮다면 더 위험해진다 — 그리고 대부분의 조직은 전담 보안팀을 갖춘 대형 클라우드 벤더보다 보안 성숙도가 낮다. "우리 손 안에 있으니 안전하다"는 직관은 이 비대칭을 무시한다.

구체적으로 어디가 위험해지는가. 패치 지연이 새 취약점을 만든다. 특히 에어갭(8.4.9)에서는 패치 반입이 느려 알려진 취약점에 더 오래 노출된다 — 앞서 말한 "인터넷과 끊겨서 안전"이 아니라 "패치가 늦어서 위험"이 여기서 실현된다. 공격면도 사라지지 않는다. 프롬프트 인젝션, 모델을 통한 데이터 유출, 내부자 위협, 접근통제 오설정(7.4)은 온프레미스에서도 그대로다. 데이터가 경계 안에 있다는 것과 그 경계 안이 안전하다는 것은 다르다. 온프레미스가 실제로 없애는 것은 "외부 벤더로의 데이터 이동"이라는 특정 위험 하나이고, 그 대가로 "우리가 보안을 잘 해낼 수 있는가"라는 새 위험 전체를 진다. 이것이 트레이드오프의 정직한 형태다. 그러니 온프레미스를 고르기 전에 우리 보안 성숙도가 이 이전된 책임을 감당할 수 있는지를 엄밀하게 점검해야 한다 — 감당 못 하면 "안전하려고 옮겼다가 덜 안전해지는" 역설에 빠진다.

8.4.12 "자체호스팅이 항상 싸다"는 착각 — TCO의 수계산

두 번째 통념은 비용이다. 자체호스팅의 비용은 GPU 시간당 요율이 아니라 활용률·인건비·조달까지 넣은 총소유비용(Total Cost of Ownership, TCO)으로 계산해야 하고, 낮은 활용률로 유휴 상태로 두는 GPU는 API보다 비용이 크다. 이것을 산식과 숫자로 밟는다.

자체호스팅의 토큰당 비용은 대략 이렇게 쓸 수 있다.

$$C_{\text{self}} \;\approx\; \frac{C_{\text{GPU/시간}} \times \text{시간} \;+\; C_{\text{인건비·전력·감가}}}{\text{활용률} \times (\text{처리량 토큰/시간}) \times \text{시간}}$$

반면 API는 순수한 변동비다.

$$C_{\text{API}} \;=\; (\text{토큰 수}) \times (\text{토큰당 요금})$$

두 식의 근본적 차이는 분모의 활용률에 있다. GPU는 켜져 있는 동안 돈이 나가지만 일하는 동안만 토큰을 만든다. 활용률이 절반이면 같은 토큰 수를 만드는 데 GPU가 두 배 오래 켜져 있어야 하므로 토큰당 비용이 두 배가 된다. API는 쓴 만큼만 내니 놀림 비용이 아예 없다.

숫자를 넣자(요율·처리량은 개략 규모를 보여 주는 예시일 뿐이다). GPU 임대가 시간당 \$2이고, 어떤 워크로드에서 활용률 100%일 때 처리량이 초당 1000 토큰이라 하자. 완전 활용이면 100만 토큰을 만드는 데 필요한 시간은 $\tfrac{10^6}{1000} = 1000$ 초 $\approx 0.278$ 시간이고, 비용은 $2 \times 0.278 \approx \$0.56$ 다(GPU 요율만). 그런데 트래픽이 불균일해 활용률이 20% 라면, 같은 100만 토큰을 만드는 동안 GPU가 다섯 배 오래 켜져 있어야 하므로 $0.56 \times 5 \approx \$2.8$ 로 증가한다. 여기에 아직 GPU 요율만 넣었다는 점이 중요하다. 자체호스팅에는 운영 인건비(GPU·서빙 운영, 온콜·장애 대응, 5.5), 조달·시설(온프레미스라면 전력·냉각·감가상각, 8.4.7), 스파이크에 대비한 여유 용량(오토스케일 손실)이 더 붙는다. 이 숨은 비용들이 "싼 GPU 시간"을 잠식해 실제 토큰당 비용을 더 높인다.

이제 손익분기가 어디인지 보인다. 트래픽이 크고 꾸준해서 GPU를 높은 활용률로 채울 수 있을 때 자체호스팅의 고정비 상각이 API 변동비보다 저렴해진다. 트래픽이 작거나 불규칙해 활용률이 낮으면 API가 이긴다. 초기 스타트업의 스파이키한 트래픽에서 자체 GPU를 사면 대부분의 시간 GPU가 유휴 상태로 요금만 나가고, 그것이 API를 그대로 썼을 때보다 비용이 큰 상황 — 이 장 첫머리의 그 회사가 정확히 여기 빠진 것이다. "자체가 싸다"도 "API가 싸다"도 조건 없이는 거짓이며, 결론은 언제나 "직접 계산하라"다. 정밀한 유닛 이코노믹스 모델은 7.5에서 세운다.

두 통념을 합치면 이 장의 정직한 요약이 나온다. 온프레미스·엣지는 더 안전하지도 더 저렴하지도 자동으로는 아니다. 그것은 데이터 통제·격리·오프라인·잔류를 얻는 대신 보안·운영·비용의 책임을 부담하는 거래다. 이 거래가 남는지는 동인(8.4.2)이 그 대가를 정당화하는가로 정해진다 — 동인이 강하면 대가를 치를 값어치가 있고, 동인이 약하면 매니지드가 옳다.

8.4.13 요구에서 배포 형태로 — 결정 흐름과 시나리오

이 장을 하나의 의사결정 흐름으로 묶는다. 선택을 강요하는 순서도가 아니라, 요구를 넣으면 스펙트럼 위 위치가 좁혀지는 절차다. 마지막 판단은 능력 평가(8.4.6)와 비용 계산(8.4.12)이 내린다.

세 시나리오와 하나의 반례로 직접 확인해 보자.

병원 임상 요약. 환자 기록(PHI)을 요약하는데 의료 규제와 데이터 레지던시로 데이터가 리전·경계를 못 벗어난다(9.3). 트래픽은 중간이고 최상위 추론까지는 불필요하다(요약·추출 중심). 흐름을 밟으면 — 에어갭? 아니오(인터넷 자체 금지는 아님). 어떤 API에도 못 넣는 기밀? 부분적이지만 규제 통제 아래면 격리 클라우드가 허용된다. 레지던시 제약? 예. 최상위 폐쇄 능력 필요? 아니오(요약·추출은 좋은 오픈웨이트에 도메인 파인튜닝을 더하면 충분). 결론은 ③ 리전 VPC 셀프호스트(데이터가 VPC 밖으로 안 나감), 또는 운영 부담을 낮추고 싶고 계약상 잔류가 보장되면 ② 리전 전용 엔드포인트다. 에어갭 온프레미스는 과잉이다 — 요구는 레지던시이지 물리 단절이 아니다. 대가로 VPC 셀프호스트의 운영 부담과 활용률 관리를 감수한다.

소비자 앱 오프라인 자동완성. 모바일 키보드·메모 앱의 문장 자동완성인데, 입력이 기기를 안 떠나야 신뢰가 서고 오프라인 동작과 저지연이 UX의 핵심이며 태스크는 좁다. 규제·기밀보다 지연·오프라인·프라이버시가 동인이다. 지연·오프라인이 결정적? 예. 결론은 ⑤ 온디바이스 소형 모델(강한 양자화 GGUF/NPU, 8.4.4)이다. 데이터가 기기에 머물고 오프라인에서 동작하며 왕복 지연이 없다. 긴 재작성 같은 어려운 요청은 비민감일 때만 클라우드로 에스컬레이션하는 하이브리드로 능력 한계를 메운다. 대가는 소형 모델의 능력 상한, 기기 이질성과 배터리, 앱을 통한 모델 업데이트 배포다 — 대신 프라이버시·오프라인·추론 비용 0을 얻는다.

방산 기밀 분석. 국가기밀 문서를 분석하는데 시스템이 인터넷과 물리적으로 단절된 폐쇄망에 있어야 한다. 에어갭? 예 — 첫 질문에서 바로 결정된다. 결론은 ④ 온프레미스 에어갭(8.4.9)이다. 하드웨어를 자체 구매·설치하고(8.4.7), 모델·의존성은 검역·물리 반입하며, 업데이트는 오프라인 파이프라인으로 실행한다. 대가로 최상위 폐쇄 모델을 못 쓰고(오픈웨이트만), 패치가 느려져 취약점에 더 노출되며, 조달·시설·인건비를 부담한다 — 그 전부를 감수하고 완전 격리를 산다.

그리고 대부분의 스타트업 챗봇. 일반 고객지원 챗봇은 규제·기밀이 약하고, 트래픽이 작고 불규칙하며, 최상위 능력이 오히려 도움이 된다. 흐름의 모든 질문이 아니오이고, 트래픽도 크고 꾸준하지 않다. 결론은 ① 공용 모델 API다 — 온프레미스·엣지를 검토할 동인이 없다. 규모가 커지고 꾸준해지면(활용률이 올라가면) 그때 ③ VPC 셀프호스트로 손익분기를 재검토하되, 그동안 OpenAI 호환 인터페이스 뒤로 구현을 숨겨(5.4) 이전을 되돌릴 수 있게 둔다. 이 반례가 이 장의 결론을 압축한다. 온프레미스·엣지는 특정 동인이 정당화할 때의 선택지이지 기본값이 아니다. 동인 없이 "왠지 안전할 것 같아서" 그리로 가면 능력·비용·운영에서 손실만 본다 — 첫머리의 그 회사처럼.

이 장에서 반복해 마주친 질문들 — 오픈이냐 폐쇄냐, 라이선스, 데이터가 어디에 머무는가 — 은 배포를 넘어 전략과 법의 문제다. 배포 결정을 전략 층위로 격상해 파운데이션 학습·파인튜닝·API·오픈소스를 누구에게·언제 맞는지로 펼치는 것이 9.1이고, 이 장에서 반복 참조한 오픈웨이트·라이선스 생태계는 9.2, 데이터 레지던시·GDPR·개인정보보호법을 깊이 다루는 것은 9.3다.