폐쇄망 AI 도입은 사는 건 싸고 신선하게 유지하는 건 비싸다. 벤더가 흡수하는 비용 vs 고객이 부담하는 비용의 비대칭 — 실제 운영 채널의 숫자로.
규제 산업 엔터프라이즈가 "AI는 우리 네트워크 안, 완전 폐쇄망에서 돌려야 한다" 는 결론에 도달했을 때, TCO 산정표에는 보통 두 칸이 있습니다. 서버 + 라이선스 + 구축 비용 과 SaaS 구독료. 이 둘을 비교해 숫자를 내고, 수치가 합리적이면 의사결정을 내립니다.
그 표에 빠져 있는 한 줄이 있습니다. 모델이 낡아갈 때 그 비용은 누가 부담하는가.
SaaS 형태의 AI 제품에서는 답이 명확합니다 — 벤더가 부담합니다. 폐쇄망 도입 환경에서는 답이 다릅니다. 그 부담은 고객사의 인프라 팀에 고스란히 돌아오고, 규모는 대부분의 구매자가 예상한 것의 약 한 자릿수 배수입니다. 일회성 마이그레이션 비용이 아니라 무기한으로 반복되는 운영 비용이기 때문입니다.
저희는 금융, 제조, 공공, 의료 분야의 고객사에 폐쇄망 모드와 SaaS 모드를 나란히 운영하고 있습니다. "이게 실제로 얼마인가" 에 대한 내부 근거는 구체적이고 일관되게 쌓였습니다. 마케팅적 수사가 아니라 Slack 채널과 PR 로그에 남은 실제 운영 이벤트들입니다. 공유드립니다.
클라우드에서 프런티어 모델을 쓰는 사용자는 백엔드에서 조용히 업그레이드되는 모델을 씁니다. 업그레이드 경로는 "탭 닫고, 탭 열고, 새 모델이 이미 있다" 수준입니다. 재학습, 서버 재기동, 통합 재작업 — 전혀 없습니다. GPT-4 에서 최신 Claude 혹은 Gemini 세대로의 체감 차이는 이 사용자의 일상에서 '이벤트' 가 아닙니다.
폐쇄망 도입 고객도 같은 프런티어 모델을 돌립니다 — 점점 더 많이 동일한 오픈소스 가중치를, Hugging Face 나 동등한 경로에서 받아오는 방식으로. 그러나 업그레이드 경로는 '프로젝트' 입니다. 두 가지 이유 때문입니다.
첫째, 모델 자체가 기능적으로 낡습니다. 8개월 전에 학습된 모델은 2개월 전에 학습된 모델이 가진 역량 일부가 없습니다. 마케팅 문구가 아닙니다. 행태적인 차이입니다 — 신규 모델은 구조화된 도구 호출을 더 안정적으로 처리하고, 긴 instruction chain 을 더 잘 따르며, 도메인 특화 RAG 에서 환각 발생이 적고, 더 많은 언어를 더 자연스럽게 이해합니다. 차이는 누적됩니다. 작년 가중치를 폐쇄망 클러스터에서 돌리는 팀은 2024년 역량으로 2025년 업무를 처리하는 셈입니다. SaaS 기반 경쟁사는 그렇지 않습니다.
둘째, 인프라도 낡습니다. 구세대 GPU (H100, H200) 에서 신세대 (B200, GB200) 로 바꾸는 일은 추론 서버의 드롭인 교체가 아닙니다. 텐서 병렬의 동작이 달라지고, 커널 경로가 달라지며, H200 에서 최적이었던 파라미터가 B200 에서는 조용히 저조한 성능을 냅니다 — 때로는 몇 배 차이로. 누군가 새 최적값을 찾아내야 하는데, 그 누군가는 모델 벤더가 아닙니다. 폐쇄망 클러스터를 운영하는 고객사의 팀입니다.
TCO 산정표 어디에도 이 두 항목은 보이지 않습니다 — 구매 의사결정 단계에서는.
최근 엔터프라이즈 도입 현장에서 관찰된 세 가지 대표 사례입니다. 어느 고객인지는 익명 처리했습니다. 중요한 것은 패턴 이고, 패턴은 어느 산업에서든 동일합니다.
대규모 폐쇄망 도입 제조사 A사 가 추론 GPU 를 H200 2장에서 B200 4장으로 업그레이드했습니다. VRAM 증가, 신규 아키텍처, 데이터시트 상 처리량 상승. 스펙만 보면 명백한 upgrade.
실제는 아니었습니다. vLLM 기본 serving 파라미터로 띄운 B200 클러스터는 이전 H200 기반 클러스터보다 측정상 느렸습니다. 트레이드오프가 있는 미묘한 차이가 아니라, 동일 워크로드에서 실제로 더 오래 걸렸습니다.
원인은 아키텍처적입니다. B200 은 H200 과 병렬 동작, 메모리 활용 목표, 커널 레벨 설정이 모두 다릅니다. H200 에서 최적이던 값이 B200 에서는 조용히 저조한 성능을 냅니다 — 때로는 몇 배 차이로. 해당 시점에 "B200 기본 설정" 이라는 canonical 값은 없었고, 최적 설정은 모델 의존 / 워크로드 의존이었으며 추론 서버 업스트림의 기본값에 아직 반영되지 않은 상태였습니다.
운영 팀은 적합한 조합을 찾아내 검증하는 데 숙련 엔지니어 여러 명과 며칠이 걸렸습니다. 회귀 리스크를 통제하기 위해 프로덕션에 가까운 별도 스테이징 환경이 그 기간 내내 유지되어야 했습니다. 튜닝이 끝난 뒤 클러스터는 기대 성능을 냈습니다 — 그러나 튜닝 비용 자체는 실재한 지출이었습니다.
SaaS 도입이었다면 이 일을 누가 흡수했을까요? 모델 벤더입니다. 대부분 rolling update 안에서 조용히. 고객 경험: 없음. 고객 엔지니어링 시간: 0.
다른 고객인 금융권 A사 는 프로덕션에서 PDF 수집 파이프라인을 돌리고 있었습니다 — 분기 실적, 금융 리포트처럼 차트와 표가 많은 문서 대상. 파이프라인은 오픈소스 MinerU 파서 2.7.x 를 썼습니다.
팀이 파서의 새 minor 버전으로 업그레이드했습니다. 업그레이드가 파이프라인을 깼습니다. 몇 달간 정상 파싱되던 문서들이 조용히 validation 에서 실패하기 시작했습니다 — 파서의 새 릴리스가 이전 버전에 없던 콘텐츠 타입을 추가했는데, 하위 스키마가 이전 버전 타입 세트 기준으로 설계되어 있어서 새 타입을 포함한 문서를 validation 단계에서 rejection 했습니다. 차트가 포함된 PDF — 금융 리포트의 기본 형태 — 마다 인덱싱 파이프라인에서 빠져나갔습니다.
문제는 프로덕션 트래픽이 쌓인 뒤에야 드러났습니다. 금융 리포트가 인덱스 코퍼스에서 사라지기 시작했고, 사용자 질의가 "관련 문서 없음" 을 반환하기 시작했습니다 — 일주일 전까지 정상 인덱스되던 문서들에 대해.
수정 자체는 진단 후 반나절 정도의 엔지니어링 작업으로 끝났고, master 브랜치와 고객 폐쇄망 포크 양쪽에 적용했습니다. 진단부터 hot-patch 까지 영업일 1일 이내.
넓은 시사점은 "이 파서 한 번 호환 이슈 있었다" 가 아닙니다 — 폐쇄망 환경에서 모든 upstream 업그레이드는 증명되기 전까지는 깨는 변경 이고, 증명 비용은 고객 부담입니다. SaaS AI 고객은 이 리스크를 소유하지 않습니다. 폐쇄망 고객은 스택의 모든 의존성에 대해 이 리스크를 소유합니다.
세 번째 고객인 공공기관 C사 는 현재 쓰는 비전-언어 모델을 훨씬 큰 모델 (양자화 후에도 수십 GB 규모) 로 교체하고자 했습니다. 폐쇄망 클러스터의 내부 모델 레지스트리로 업로드를 시작했는데, 업로드가 조용히 실패했습니다. 레지스트리의 기본 구성 — 일반 오브젝트 스토리지 크기를 전제한 설정 — 이 동시대 오픈 가중치 모델 아티팩트 규모를 감당하지 못했습니다. 레지스트리를 대형 모델 수용 가능하도록 재구성하고 검증한 뒤 업로드를 완료하는 데 숙련 인프라 엔지니어 한 명 × 영업일 1일 정도가 들었습니다.
해결 자체는 단순하지만 — 그것이 포인트입니다. 폐쇄망 환경에서의 대형 모델 업로드는 단순 다운로드가 아니라 시스템 엔지니어링 과제입니다. 모델 교체 한 번 한 번이 이 과제의 축소판이고, 업그레이드 주기마다 비용이 반복됩니다.
SaaS 등가물: 없습니다. 벤더 쪽에서 새 모델을 서빙할 뿐, 고객은 업그레이드 자체를 인지하지 못합니다.
위 세 사례 어디도 언론에 오르지 않았습니다. 고객사 최종 사용자에게 보이는 장애로 귀결되지도 않았습니다. 역량 있는 팀이 평범한 운영 업무로 흡수했고, 각 사례 후에 클러스터는 다시 잘 돌아갔습니다.
하지만 비용 구조에는 남습니다. 저희가 고객사별로 운영하는 Slack 채널 19곳 — 온프레미스 도입 관련 — 을 지난 180일 스캔해 model, version, upgrade, performance, benchmark, vllm, qwen, claude, gpt 같은 키워드로 필터했습니다:
비대칭은 우연이 아닙니다. 폐쇄망 TCO 계산에서 가장 크게 빠져 있는 단일 항목이고, 업그레이드 주기마다 반복됩니다. 현재의 모델 세대 교체 속도를 감안하면 — 베이스 모델은 분기 1회, 주변 스택은 월 단위 혹은 그 이하 — 결코 작은 수치가 아닙니다.
확실히 정답인 경우가 있습니다. 질문은 어느 고객에게 그런가 입니다.
대략적인 의사결정 프레임:
폐쇄망이 정답일 때:
보통 폐쇄망이 정답이 아닌 경우:
판단이 어려운 한 카테고리가 있습니다. "동종 업계가 다 폐쇄망이니까 우리도" 라고 가정했지만, 실제 컴플라이언스 요건은 암호화 이그레스와 감사 가능한 경계를 갖춘 하이브리드 배포로도 충족되는 엔터프라이즈들. 저희 관찰로는 이 카테고리가 큽니다 — 지금 폐쇄망 AI 를 검토 중인 규제 산업 엔터프라이즈의 다수일 가능성이 높습니다. 맞는 테스트는 "다른 은행이 폐쇄망을 쓰는가" 가 아니라 "이 워크로드에 대해 제로 이그레스를 특정해서 요구하는 규제 조항을 내게 보여달라" 입니다. 그 조항이 존재하면 폐쇄망으로 가고 모델 tax 를 인지한 채 부담합니다. 존재하지 않으면, 3년 지평에서 하이브리드가 거의 확실히 더 저렴합니다.
온프레미스 AI 플랫폼을 평가 중이고 TCO 를 스트레스 테스트하고 싶다면, 아래 질문을 벤더에 해보세요. 마케팅 질문이 아닙니다. 운영 질문입니다.
폐쇄망 AI 도입은 사는 건 싸고 신선하게 유지하는 건 비싸다. 이걸 모르고 시작한 구매자는 4차 업그레이드 주기쯤에 자사 인프라 팀의 throughput 지표로 배우게 됩니다. 아는 구매자는 인프라 팀 규모를 맞추거나, 벤더의 refresh 의무를 협상하거나, 하이브리드를 선택합니다 — 셋 다 합리적 결과입니다. 합리적이지 않은 것은 모르고 부담하는 것 입니다.
컴플라이언스 요건이 특정 워크로드에 대해 폐쇄망을 유일 합법 경로로 만들었다면, 이 글이 그 선택을 말리려는 것이 아닙니다. 다만 컴플라이언스가 하이브리드 아키텍처를 허용하는데 감에 의존해 폐쇄망을 택하고 있다면 — 더 안전하게 느껴져서, 동종 업계가 그래서, 발견 단계에서 영업이 잘 해서 — 약정 전에 모델 tax 를 계산에 넣으세요. 벤더 refresh 주기를 서면으로 받아내고, 업그레이드 breakage 이력을 요청하고, 현재 두 분기 이상 된 가중치를 돌리는 고객이 몇 퍼센트인지 물으세요.
답이 보여준 TCO 의 완결성을 가늠해줄 것입니다.
특정 워크로드에 대해 폐쇄망 vs 하이브리드 비교를 검토 중이고 환경에 맞춘 수치로 함께 돌려보고 싶으시다면, 저희 팀이 도와드립니다 — 피치덱 없이, 슬라이드 없이, 숫자만.
문의하기 — 도입 모델, 규제 제약, 일정을 공유해주시면 저희 팀이 구체적인 답변으로 이어 연락드립니다.
