기술의 발전과 함께 점점 더 기업들이 쉽고 빠르게 업무에 AI 에이전트를 도입할 수 있는 생태계가 갖추어지고 있습니다. 이전보다 쉽고 저렴하게 Anthropic과 OpenAI 등 첨단 회사의 최신 LLM을 활용할 수 있게 되었을 뿐 아니라, 데이터 연동과 원활한 배포를 위한 서비스까지 비교적 쉽게 우리 회사 서비스에 적용할 수 있게 되었기 때문입니다.

이처럼 회사 편의에 맞게 AI를 도입할 수 있는 시대에 기업들의 고민은 일견 단순해 보입니다. 어떤 모델이 가장 똑똑한지, 토큰당 API 호출 비용은 얼마인지, 우리가 원하는 시스템을 구축하기 위해 어떤 기술 스택을 적용하면 되는지 따지면 되니까요. 특히 외부 클라우드 API를 호출하는 방식은 서버 한 대 없이도 바로 시작할 수 있다는 점이 큰 매력으로 다가옵니다.

하지만 엔터프라이즈 AI를 직접 다루는 엔지니어로서 현장에서 피부로 느끼는 현실은 훨씬 더 복잡합니다. 클라우드 AI를 쓴다는 것은 곧 회사 데이터를 외부로 내보낸다는 뜻이고, 클라우드는 이미 공격자들의 주요 표적이기 때문입니다. 조사 결과에 따르면 클라우드 보안 침해의 약 80%가 설정 오류에서 시작되고, 자동화된 공격 도구는 설정 실수 하나를 찾아내 몇 시간 만에 데이터를 빼낼 수 있다고 합니다. 한 가지 예로 2024년 클라우드 데이터 플랫폼 Snowflake에서는 탈취된 고객 계정 정보로 165개 조직의 데이터가 유출되기도 했습니다.

AI는 이 위험을 더 키웁니다. API 키, 문서 저장소, 서비스 계정처럼 관리해야 할 지점이 늘어나고, 무엇보다 직원이 프롬프트를 입력하는 순간 데이터가 외부 서버로 넘어갑니다. 2023년 삼성전자가 반도체 부문에 챗GPT를 허용한 지 20일 만에 사내 정보 유출을 겪고 사용을 제한한 것도 같은 이유였습니다.

그래서 실제 프로젝트에서 더 중요한 질문은 "어떤 AI를 쓸까"가 아니라 "우리 회사 AI는 어디에 있어야 할까"인 경우가 많습니다. 특히 금융·공공·제조처럼 민감한 데이터를 다루는 산업에서는 AI를 회사 내부 인프라에서 직접 운영하는 온프레미스(On-premise) AI가 다시 주목받고 있습니다.

온프레미스 방식이 다시 주목받고 있는 이유

온프레미스는 말 그대로 '사내(premises)에 설치한다'는 뜻입니다. 서버와 소프트웨어를 외부 업체의 데이터센터가 아닌, 기업이 직접 소유하고 관리하는 공간에서 운영하는 방식입니다.

쉽게 비유하면 클라우드 AI는 외식, 온프레미스 AI는 집밥에 가깝습니다. 외식은 주방 없이도 바로 먹을 수 있지만, 재료가 어디서 왔는지와 조리 과정은 식당에 맡겨야 합니다. 집밥은 주방을 갖추는 수고가 들지만, 재료부터 조리법까지 모두 내 손으로 통제할 수 있습니다.

온프레미스 AI가 다시 떠오르는 이유는 크게 세 가지 정도로 정리해 볼 수 있습니다. 우선 데이터 보안과 규제 대응입니다. 고객 개인정보, 내부 기밀 문서, 상담 녹취 같은 데이터는 외부로 내보내는 것 자체가 기업에 큰 부담입니다. 특히 망분리 규제를 받는 금융·공공 기관은 외부 API를 쓰는 것부터가 원천적으로 어려운 경우가 많습니다.

두 번째는 장기 운영 비용입니다. 클라우드 API는 시작 비용이 낮은 대신, 쓰는 만큼 비용이 계속 늘어나는 구조입니다. 몇몇 부서의 시범 사용 단계에서는 문제가 되지 않지만, 전사 단위로 AI 사용량이 커지면 이야기가 달라집니다. 초기 투자가 들더라도 자체 인프라를 갖추는 편이 장기적으로 더 유리해지는 지점이 생기기 때문입니다.

마지막으로, 그리고 가장 중요한 이유는 AI 에이전트 시대에 커진 통제의 필요성입니다. AI는 이제 질문에 답하는 수준을 넘어, 사내 시스템에 직접 접속해 데이터를 조회하고 업무를 실행하는 에이전트로 진화하고 있습니다. AI가 말하는 데서 그치지 않고 '행동'까지 하게 되면서, 그 AI가 어디에서 돌아가고 무엇에 접근할 수 있는지를 기업이 직접 통제해야 할 필요성도 그만큼 커졌습니다.

온프레미스 AI를 구성하는 다섯 가지 레이어

온프레미스 AI는 우리 회사 서버룸에 고성능 GPU 서버 몇 대를 들여놓는 것처럼 단순한 작업이 아닙니다. 그보다는 기존에 클라우드 기반 AI 회사에 아웃소싱하던 요소들을 직접 구축하고 운영하는 일에 가깝습니다. 아래부터 차례로 쌓이는 다섯 계층으로 이해하면, 기업이 무엇을 직접 소유하고 통제하게 되는지가 분명해집니다.

우선 가장 아래에는 인프라가 있습니다. AI 연산을 담당하는 GPU 서버와 네트워크, 그리고 데이터를 저장하는 스토리지가 여기에 해당합니다. 온프레미스 도입에서 가장 큰 초기 투자가 발생하는 계층이기도 합니다.

그 위에 올라가는 것이 모델입니다. 사내에서 직접 실행할 수 있도록 Qwen이나 Llama처럼 가중치가 공개된 오픈웨이트 LLM을 쓰거나, 특정 업무에 맞춘 경량 모델(sLLM)을 골라 씁니다. 필요하다면 사내 데이터로 추가 학습을 시켜 우리 업무에 더 잘 맞게 다듬을 수도 있습니다.

모델을 설치했다고 바로 쓸 수 있는 것은 아닙니다. 사내 애플리케이션이 모델을 호출할 수 있도록 API 형태로 제공하는 모델 서빙 계층이 필요합니다. 뒤에서 소개할 Ollama와 vLLM이 바로 이 역할을 맡는 도구입니다.

서빙 위에는 RAG 검색 계층이 자리합니다. 모델이 학습하지 않은 사내 문서를 실시간으로 찾아 답변의 근거로 붙여주는 역할로, 환각을 줄이고 최신 정보를 반영하는 핵심 장치입니다.

그리고 가장 위에는 에이전트·권한 관리 계층이 있습니다. AI가 어떤 시스템에 접근하고 어떤 업무를 실행할 수 있는지를 정하는 계층입니다. AI가 답변을 넘어 행동하는 시대에는 이 계층을 어떻게 설계하느냐가 보안의 성패를 가릅니다. 클라우드 API를 쓸 때는 이 가운데 인프라, 모델, 서빙 계층을 외부 사업자에게 맡기는 셈입니다. 반면 온프레미스는 다섯 계층 전부를 기업이 직접 쥐는 방식입니다.

클라우드 vs 온프레미스 vs 하이브리드

그렇다면 우리 회사 보안을 위해서 무조건 온프레미스를 도입해야 할까요? 온프레미스 방식이 만능은 아닙니다. 세 가지 방식은 각각 분명한 장단점이 있고, 기업의 데이터 성격과 사용 규모에 따라 답이 달라집니다.

온프레미스와 다른 방식의 가장 근본적인 차이는 데이터가 어디에 머무느냐입니다. 클라우드 AI에서는 데이터가 외부 사업자의 서버를 거쳐 처리되기 때문에, 보안과 규제 대응도 결국 사업자의 정책에 기댈 수밖에 없습니다. 반면 온프레미스 AI는 데이터가 사내 인프라를 벗어나지 않으므로 보안 수준과 접근 범위를 기업이 직접 정할 수 있습니다. 하이브리드는 그 중간에서 민감한 데이터는 내부에, 나머지는 외부에 두고 업무별로 방식을 고르는 구조입니다.

비용은 시간 축으로 나눠 봐야 합니다. 클라우드는 서버 없이 시작할 수 있어 초기 비용이 낮지만, 쓰는 만큼 요금이 계속 쌓입니다. 온프레미스는 반대로 GPU 서버와 네트워크, 스토리지를 갖추는 데 상당한 초기 투자가 들지만, 사용 규모가 커질수록 단위 비용이 낮아져 장기적으로 유리해집니다. 다만 사용량 예측 없이 장비부터 들이면 활용률이 낮은 비싼 서버만 남을 수 있다는 점은 주의해야 합니다.

모델 성능에서는 클라우드가 앞섭니다. 최신 대형 모델을 출시 즉시 쓸 수 있기 때문입니다. 온프레미스는 사내에서 직접 돌릴 수 있는 오픈웨이트 모델이 중심이 되며, 범용 성능만 놓고 보면 최상위 상용 모델보다 낮을 수 있습니다. 하지만 사내 데이터와 결합한 특정 업무에서는 이 격차가 크게 줄어듭니다.

운영 부담 역시 온프레미스가 짊어져야 할 몫입니다. 클라우드는 인프라 관리를 사업자가 맡지만, 온프레미스에서는 모델 업데이트와 서빙 최적화, 장애 대응을 맡을 내부 인력과 역량이 필요합니다.

결국 세 방식 중 하나가 정답이라기보다, 각자의 강점이 다른 것입니다. 그래서 최근에는 민감한 업무는 온프레미스에서, 최신 모델의 성능이 필요한 범용 작업은 클라우드에서 처리하며 작업 난이도에 따라 모델을 나눠 쓰는 하이브리드 구성을 택하는 기업이 늘고 있습니다.

실험에서 운영까지: Ollama와 vLLM

"그래서 사내에서 LLM을 실제로 어떻게 띄우나요?" 온프레미스 AI를 검토하는 담당자가 가장 먼저 부딪히는 질문입니다. 다행히 지금은 오픈소스 도구 덕분에 진입 장벽이 크게 낮아졌습니다. 대표적인 두 도구가 Ollama와 vLLM이며, 둘은 경쟁 관계라기보다 도입 단계별로 역할이 다른 도구로 이해하는 것이 좋습니다.

1) Ollama: 가장 빠르게 시작하는 PoC 도구

Ollama는 개인 PC나 단일 서버에서 오픈웨이트 LLM을 손쉽게 실행할 수 있게 해주는 도구입니다. 설치 후 명령어 한 줄이면 모델을 내려받아 바로 대화할 수 있습니다.

# 모델을 내려받고 바로 실행

ollama run gemma3

실행과 동시에 로컬 API 서버도 함께 열리기 때문에, 사내 애플리케이션에서 이 모델을 호출하는 간단한 연동 테스트까지 바로 해볼 수 있습니다. 설치가 쉽고, GPU가 없는 노트북에서도 작은 모델 정도는 무리 없이 돌아간다는 점이 가장 큰 장점입니다.

그래서 Ollama는 "우리 문서로 이런 게 되는지"를 확인하는 PoC 단계나 개발자 개인 실험, 소규모 내부 테스트에 잘 맞습니다. 다만 여러 사용자의 요청이 동시에 몰리는 운영 환경을 감당하도록 설계된 도구는 아니기 때문에, 실서비스로 넘어가는 시점에는 다른 선택지가 필요합니다.

2) vLLM: 운영 환경을 위한 고성능 서빙 엔진

vLLM은 UC 버클리에서 시작된 오픈소스 LLM 서빙 엔진으로, 많은 요청을 동시에 빠르게 처리하는 것에 초점을 맞춘 도구입니다. GPU 메모리를 효율적으로 관리하는 PagedAttention 기법과, 들어오는 요청을 실시간으로 묶어 처리하는 연속 배칭(continuous batching) 덕분에 같은 GPU로 더 많은 사용자를 감당할 수 있습니다.

# OpenAI 호환 API 서버로 모델 서빙

vllm serve Qwen/Qwen2.5-7B-Instruct

vLLM은 OpenAI API와 호환되는 서버를 제공합니다. 기존에 외부 API를 호출하던 애플리케이션이라면 접속 주소만 사내 서버로 바꿔 전환할 수 있다는 점이 실무에서 큰 장점입니다. 높은 처리량과 다중 GPU 지원까지 갖추고 있어, 전사 서비스나 상담 지원처럼 동시 사용자가 많은 운영 환경에 적합합니다. 그만큼 GPU 서버 환경과 서빙 설정에 대한 이해가 필요하다는 점은 감안해야 합니다.

즉, 두 도구는 도입 단계에 따라 자연스럽게 나눠 쓸 수 있습니다. 가능성을 검증하는 PoC 단계에서는 개발자 PC나 단일 서버에 Ollama를 띄워 빠르게 실험하는 것으로 충분합니다. 일부 부서가 실제로 써보는 파일럿 단계에서는 전용 GPU 서버 한 대를 두고, 사용 규모에 따라 Ollama를 유지하거나 vLLM으로 옮겨 갑니다. 그리고 전사 서비스로 확대하는 운영 단계에서는 여러 대의 GPU 서버와 모니터링 체계를 갖추고 vLLM으로 서빙하는 것이 일반적입니다.

핵심은 처음부터 거창한 인프라를 갖추는 것이 아니라, 작게 검증하고 확신이 생긴 만큼 확장하는 것입니다. 참고로 위 명령어의 모델명은 예시일 뿐이며, 실제로는 한국어 성능과 라이선스, 보유한 GPU 사양을 함께 따져 모델을 골라야 합니다.

결론: 위치가 아니라 통제의 문제

이번 시간에는 온프레미스 AI의 개념과 특징, 그리고 온프레미스 모델을 실제 활용하기 위한 대표적인 툴들에 대해 살펴보았습니다. 온프레미스 AI를 "서버를 회사 안에 두는 것"으로만 이해하면 본질을 놓치게 됩니다. 보다 근본적인 질문은 우리 데이터와 AI의 행동 범위를 누가 통제하느냐입니다. AI가 답변을 넘어 업무를 실행하는 에이전트로 진화할수록, 이 질문의 무게는 더 커질 것입니다.

처음부터 모든 것을 내재화할 필요는 없습니다. 가장 현실적인 전략은 민감한 데이터와 핵심 업무부터 단계적으로 온프레미스로 옮기는 것입니다. Ollama로 작게 검증하고, 효과가 확인된 업무부터 vLLM 기반 운영 환경으로 확장하며, 범용 작업은 필요에 따라 클라우드와 병행하는 방식입니다.