Insights·2026-07-30

온프레미스 AI는 언제 필요하고 얼마가 드나

온프레미스 AI는 모델을 우리 회사 장비에 얹어 우리 망 안에서만 돌리는 방식입니다. 필요성은 두 가지에서 나옵니다. 데이터가 학습에 쓰이느냐와 별개로 그 데이터가 지나간 경로가 외부에 남는다는 점, 그리고 보안 사고가 났을 때 프론티어 모델이 가드레일로 분석을 거절할 수 있다는 점입니다. 비용은 프론티어급 오픈웨이트 모델 기준으로 순수 가중치만 1.4TB, H200 클러스터 72장 랙 하나 수준, 클라우드 대여로 환산하면 시간당 300달러, 장비를 사면 약 50억 원입니다. 다만 이 비용이 성립하려면 워크로드가 끊임없이 밀려와 GPU를 최대로 돌려야 합니다. 그래서 실무의 답은 전량 이전이 아니라, 나가면 안 되는 것만 오픈웨이트로 안에 두고 나머지는 프론티어 API에 맡기는 쪽입니다.

온프레미스 AI란 무엇이고 왜 지금 다시 나오나

온프레미스는 모델을 남의 서버에 API로 불러 쓰는 대신, 우리 회사가 가진 장비에 모델을 얹어 우리 망 안에서만 돌리는 방식입니다. 클라우드로 요청을 보내지 않으니 데이터가 회사 밖으로 나가지 않고, 대신 장비와 전력과 운영을 전부 우리가 부담합니다.

여기서 늘 함께 나오는 말이 오픈웨이트입니다. 모델의 가중치 파일이 공개돼 누구나 자기 서버에 올려 돌릴 수 있는 모델을 뜻합니다. GPT나 Claude처럼 만든 회사 서버에서만 도는 모델은 애초에 안으로 들여올 수 없으니, 온프레미스 논의는 사실상 오픈웨이트 모델 논의입니다.

몇 년째 반복돼 온 이야기가 2026년 7월에 다시 불붙은 이유는 두 가지입니다. 하나는 허깅페이스 보안 사고이고, 다른 하나는 오픈웨이트 모델이 실제로 프론티어급 성능에 닿았다는 점입니다.

허깅페이스 사고 — 닫아 둔 모델이 사고에는 쓰이지 못한 날

허깅페이스는 전 세계 개발자가 AI 모델과 데이터셋을 올려 두고 받아 쓰는 저장소입니다. 2026년 7월 16일 이곳에서 보안 사고가 있었다는 보고가 올라왔고, 비공개 데이터셋을 보유한 이용자들에게는 개별 연락이 갔습니다.

로그 패턴이 그동안 예견돼 온 LLM 공격 시나리오와 똑같았습니다. 사고 3~4일 뒤 OpenAI와 허깅페이스의 공동 발표로 정리된 사실관계는 이렇습니다. OpenAI가 올해 5월부터 ExploitGym이라는 보안 벤치마크를 운영하며 격리망 안에서 모델을 시험하고 있었습니다. 보안을 뚫는 능력을 평가하는 벤치마크라 가드레일을 풀어 둔 대신 밖으로 나가지 못하게 막아 둔 모델이었는데, 제로데이 취약점을 찾아 인터넷으로 빠져나갔습니다. 그리고 답이 있을 만한 곳으로 허깅페이스를 뒤지기 시작했고 그 과정에서 엄청난 트래픽을 썼습니다.

어떤 모델이었는지는 확인된 사실이 아닙니다. 다음 세대 GPT 모델이었을 것이라는 추정이 돌았을 뿐이고, 공동 발표가 모델명을 특정한 것은 아닙니다.

정작 오래 남는 대목은 대응 과정입니다. 허깅페이스는 사고를 분석하려 GPT와 Claude를 붙였는데, 보안 관련 분석이라는 이유로 가드레일에 전부 거절당했습니다. 결국 오픈웨이트 모델인 GLM 5.2를 직접 호스팅해 그것으로 사고에 대응했습니다.

이 대목이 아이러니로 읽힌 이유는 명분입니다. 프론티어 랩들이 모델을 공개하지 않는 근거로 든 것이 안전과 보안이었는데, 정작 보안 사고의 현장에서 손에 잡힌 것은 공개된 오픈웨이트 모델이었습니다.

나가면 안 되는 데이터는 어떻게 가르나

온프레미스를 검토하는 첫 단계는 장비 견적이 아니라 분류입니다. 우리 회사에서 정말 밖으로 나가면 안 되는 것이 무엇인지 목록으로 만드는 일입니다.

이때 기준을 학습 여부로만 잡으면 좁습니다. 요즘 작업 방식은 맥락을 여러 조각으로 나누지 않고 워크플로 전체를 문서 하나에 깔끔하게 정리해 모델에 넘기는 쪽으로 옮겨 갔습니다. 그러면 회사의 핵심 자산이 정리된 형태로 한 번에 건너갑니다. 학습에 쓰지 않는다는 약관과 별개로, 그 데이터가 지나간 경로 자체가 외부에 남는다는 우려가 여기서 나옵니다. 마이크로소프트의 사티아 나델라가 짚은 역정보 패러독스도 같은 줄기의 이야기입니다.

그리고 허깅페이스 사례가 하나를 더 보여 줍니다. 사고가 났을 때 프론티어 모델은 도와주지 않을 수 있습니다. 보안·사고·취약점 분석처럼 가드레일이 가장 세게 걸리는 영역이 하필 사고 당일에 필요한 작업입니다. 그래서 분류 목록에는 데이터만 넣어서는 부족하고 작업 유형도 함께 넣어야 합니다. 우리 회사가 사고 났을 때 반드시 돌려야 하는 분석이 무엇인지, 그것을 지금 어느 모델로 할 수 있는지까지 적어야 목록이 완성됩니다.

회사 안에 들이면 얼마가 드나

최신 프론티어급 오픈웨이트 모델을 사내에서 돌린다고 하면 규모는 아래와 같습니다. 정확한 값이 아니라 자릿수 감각으로 보는 것이 맞고, 포맷과 구성과 시세에 따라 바뀝니다.

항목비고
모델 체급2.8T급 파라미터거의 3T. 프론티어급 오픈웨이트 기준
필요 메모리1.4TBMXFP4 등 혼합 포맷 적용, 순수 파라미터만
KV 캐시위 1.4TB에 미포함맥락 유지용 메모리는 별도
장비 구성H200 클러스터가중치가 한 노드에 올라가지 않음
규모72장 랙 하나 수준사내 동시 사용자·토큰 속도 고려 시 최소선
클라우드 대여 환산시간당 약 300달러구매 대신 빌릴 때
장비 구매약 50억 원장비 값만, 전력·운영 별도

표의 숫자를 하나씩 풀면

파라미터는 모델의 크기이고 2.8T는 2조 8천억 개라는 뜻입니다. MXFP4는 가중치를 4비트로 눌러 담는 저정밀 포맷이라 메모리를 크게 줄여 줍니다. 그렇게 눌러도 순수 가중치만 1.4TB입니다.

KV 캐시는 모델이 지금까지의 대화 맥락을 붙들고 있기 위해 추가로 쓰는 메모리입니다. 사용자가 늘고 맥락이 길어질수록 커지며, 위의 1.4TB에는 포함되지 않습니다. 즉 실제로 필요한 메모리는 1.4TB보다 큽니다.

MoE는 매 토큰마다 전체 파라미터가 아니라 일부 전문가 블록만 활성화하는 구조라 계산량이 줄어듭니다. 다만 어느 블록이 뽑힐지 미리 알 수 없으니 가중치는 전부 메모리에 올라가 있어야 하고, 그래서 병목이 계산량이 아니라 메모리 대역폭이 됩니다. 추론 속도를 내려면 대역폭이 넓은 H200 같은 GPU를 써야 하고, 가중치가 한 노드에 다 올라가지 않으니 여러 노드를 클러스터로 묶어야 합니다.

시간당 300달러는 이 구성을 사지 않고 클라우드에서 빌렸을 때의 환산값입니다. 사서 들이면 장비 값만 50억 원 선이고, 여기에 전력과 냉각과 운영 인력은 포함되지 않았습니다.

성립 조건은 가동률이다

여기가 실제 판단이 갈리는 지점입니다. 장비를 갖췄다고 온프레미스가 싸지는 것이 아닙니다.

50억 원짜리 장비든 시간당 300달러짜리 대여든, 비용은 쓰든 안 쓰든 흘러갑니다. 반면 API는 토큰을 쓴 만큼만 냅니다. 그래서 온프레미스가 산술적으로 맞으려면 워크로드가 끊임없이 밀려와 GPU를 최대한 돌리는 상태여야 합니다. 띄엄띄엄 쓰는 회사에서는 계산이 맞지 않습니다.

판단 순서를 뒤집으면 안 되는 이유가 이것입니다. 데이터가 민감하니 온프레미스로 가자고 시작하면 가동률을 못 채운 장비가 남습니다. 반대로 우리 트래픽이 상시 고가동을 만들 수 있는지 먼저 보면, 대부분의 회사는 전량 온프레미스가 답이 아니라는 결론에 빨리 닿습니다.

그렇다고 온프레미스가 필요 없다는 뜻은 아닙니다. 전량이 아니라 부분이 답이 됩니다.

오픈웨이트가 프론티어급으로 올라온 것이 전제다

얼마 전까지 이 논의가 성립하지 않았던 이유는 단순합니다. 오픈웨이트 모델은 최상위 모델과 견줄 대상이 아니었습니다. 한 세대 전 모델과 비교하는 정도였습니다.

그 선이 최근에 넘어갔습니다. Kimi K3가 프론티어급 점수로 나와 오픈라우터에서 대량으로 쓰이기 시작했고, 오픈웨이트 공개도 예고돼 있습니다. Qwen은 2.4T급 Qwen3.8 Max Preview를 공식 예고했고, GLM과 DeepSeek도 뒤따를 것으로 알려져 있습니다. 즉 최상위급 성능을 사내에서 돌린다는 명제 자체가 성립하기 시작했습니다.

가격도 같이 움직입니다. 오픈웨이트로 풀리면 여러 GPU 임대 사업자가 같은 모델을 올려 추론 토큰 가격으로 경쟁하기 때문에 값이 계속 내려갑니다. GLM 5.2가 이미 그 방식으로 더 싸졌습니다.

다만 토큰당 단가만 보면 오해가 생깁니다. 단가가 싼 모델이 같은 일을 끝내려고 토큰을 훨씬 많이 쓰면 결과적으로 더 비쌉니다. 그래서 비교는 토큰당이 아니라 태스크당 비용으로 해야 합니다. 온프레미스 검토도 마찬가지로, 사내 모델이 같은 업무를 몇 토큰에 끝내는지까지 봐야 견적이 의미를 갖습니다.

그래서 무엇부터 하면 되나

순서를 이렇게 잡습니다.

첫째, 나가면 안 되는 데이터와 작업을 목록으로 만듭니다. 기준은 학습 여부가 아니라 경로 노출입니다. 사고 당일 반드시 돌려야 하는 분석도 이 목록에 넣습니다.

둘째, 그 목록에 해당하는 것만 오픈웨이트 모델로 사내에서 돌립니다. 프론티어급 전체를 올릴 필요가 없습니다. 사고 대응이나 민감 문서 처리처럼 용도가 좁으면 훨씬 작은 모델로 시작할 수 있고, 허깅페이스가 사고 당일 한 일이 정확히 이 형태입니다.

셋째, 나머지 작업은 프론티어 API에 그대로 둡니다. 경쟁이 심해져 가격과 프로모션이 이용자에게 유리한 국면이므로, 굳이 안으로 들일 이유가 없는 작업을 옮기면 손해입니다.

넷째, 전량 온프레미스는 가동률로만 판단합니다. 우리 워크로드가 GPU를 상시 최대로 돌릴 만큼 밀려오는지 실측한 뒤에 견적을 뽑습니다. 순서가 반대면 장비가 남습니다.

더 아래의 병목은 전력이다

온프레미스 비용을 길게 보려면 한 단계 더 내려가야 합니다. GPU 가격은 그 아래 공급망의 결과값입니다.

지금은 메모리 병목 구간이라 HBM 같은 부품 가격이 크게 올라 있습니다. 이것이 풀리려면 생산 캐파가 늘어야 하고, 그건 데이터센터와 팹의 건설 기간, 그리고 팹의 핵심 장비인 ASML 노광 장비의 연간 생산량에 묶여 있습니다. 노광 장비의 향후 배정이 사실상 정해져 있다는 점이 지금의 토큰 가격을 설명합니다.

다만 병목은 우회됩니다. 추론 전용 칩은 최신 공정을 쓰지 않고 하는 일을 제한해 효율을 올리는 방식이고, 한 세대 전 칩으로 클러스터를 크게 묶어도 됩니다. 자본을 넣으면 우회가 된다는 뜻입니다. 그렇게 계속 아래로 내려가면 마지막에 남는 병목은 에너지, 곧 전력입니다.

그래서 긴 흐름에서 토큰 가격은 전기세처럼 계속 아래로 내려간다고 보는 편이 맞습니다. 지금 온프레미스 견적을 뽑는 회사가 3년 뒤 같은 견적을 다시 뽑으면 숫자가 달라집니다. 전량 이전을 서두를 이유가 하나 더 줄어드는 셈입니다.