데이터 보안과 API 비용 사이에서의 타협점: 로컬 LLM Ollama 도입기

데이터 보안과 API 비용 사이에서의 타협점: 로컬 LLM Ollama 도입기

외부 API 대신 내 서버에서 직접 LLM을 돌리겠다는 야심 찬 계획이 있었다. 보안도 지키고 비용도 아끼는 두 마리 토끼를 한 번에 잡으려 했지만, 실제 현실은 달랐다. 올라마(Ollama) 도입 과정에서 마주친 VRAM 한계와 속도 충격, 그리고 결국 찾아낸 실용적 타협점을 기록한다.

위 화면은 70B 모델 구동 시 CPU 사용률이 최대치로를 찍으며 시스템이 응답 불능 상태에 빠진 순간의 작업 관리자 캡처다. GPU VRAM이 모자라 연산이 CPU로 넘어가는 순간 서버는 마비 직전까지 몰렸다.

[배경] 보안과 비용, 두 마리 토끼를 잡고 싶었습니다

회사 내부에서 AI의 활용 빈도가 늘어날수록, 자연스럽게 두 가지 큰 벽에 부딪혔습니다. 바로 '비용'과 '보안'입니다.

처음에는 OpenAI의 API를 연동해 내부 업무 자동화와 데이터 분석을 시도했습니다. 하지만 사용량이 늘어날수록 매달 청구되는 API 비용은 눈덩이처럼 불어났습니다. 게다가 고객의 민감한 개인정보나 회사의 기밀 문서를 외부 서버로 전송해야 한다는 사실은 늘 마음 한구석을 불안하게 만들었죠.

보안 가이드라인을 엄격하게 지키려다 보니, 정작 AI의 분석이 가장 필요한 핵심 데이터에는 AI를 적용하지 못하는 아이러니한 상황이 벌어졌습니다.

그러던 중 개발자 커뮤니티에서 'Ollama(올라마)'라는 오픈소스 도구를 알게 되었습니다. 복잡한 설정 없이 내 컴퓨터나 내부 서버에서 직접 대규모 언어 모델(LLM)을 돌릴 수 있게 해준다는 소식은 가뭄의 단비 같았습니다. 외부로 데이터가 나갈 일이 없으니 보안 문제는 성공적히 해결될 것이라는 기대감에, 사내 전용 로컬 AI 구축 프로젝트를 야심 차게 시작했습니다.

[기대와 현실] 내 PC가 챗GPT가 될 줄 알았죠 (feat. 비행기 이륙 소리)

올라마에 기대한 것은 명확했습니다. 인터넷 연결 없이도, 민감한 데이터를 통째로 넣어도 안전하게 작동하는 '우리 회사 서버 안에 옮겨놓은 프라이빗 챗GPT'였죠.

설치 과정은 소문대로 놀랍도록 간단했습니다. 공식 홈페이지에서 다운로드를 받고 터미널에 명령어 한 줄만 입력하면 끝이었으니까요. 고사양 서버 장비를 대여할 필요 없이, 일단 사무실에 있는 성능 좋은 개발용 워크스테이션 정도면 하루 이틀 만에 쾌적한 사내 테스트용 챗봇을 뚝딱 만들어낼 수 있을 거라 믿어 의심치 않았습니다.

하지만 부푼 기대를 안고 모델을 실행한 첫날, 제 워크스테이션은 비행기가 이륙하는 듯한 굉음을 내기 시작했습니다.

더 심각한 건 속도였습니다. "오늘 회사 업무 일정을 정리해 줘"라는 간단한 질문에, 커서만 깜빡이더니 10초가 지나서야 '안... 녕... 하... 세... 요...'라며 한 글자씩 힘겹게 뱉어내고 있었습니다. 체감상 1초에 한 단어도 나오지 않는 끔찍한 속도였습니다. 출력되는 한국어는 어색하기 짝이 없었고, 종종 메모리 오류를 뿜으며 프로그램이 강제 종료되기 일쑤였습니다. 보안을 얻은 대신 실용성을 완전히 잃어버린 순간이었습니다.

체급 불일치를 깨달은 후 분석 과정을 정리하면서 원인이 명확해졌다.

상황을 분석하는 파이선생 캐릭터

위 그림처럼 70B 모델을 16GB VRAM에 올리려는 시도는 처음부터 실패가 예정된 구조였다. 모델 크기와 하드웨어 스펙의 불일치가 굉음과 속도 저하의 유일한 원인이었다.

[원인 파악] 올라마의 버그? 아니, 내 '욕심'이 부른 참사

처음 이 문제를 겪었을 때, 저는 이 답답함의 원인을 올라마 자체의 최적화 문제나 운영체제 호환성 탓으로 돌렸습니다.

인터넷을 뒤져가며 온갖 최적화 옵션을 터미널에 무작정 입력해 보고, 버전을 낮춰 재설치도 해봤습니다. 한국어 연산이 무거운가 싶어 영어로만 질문을 던져보기도 했죠. 하지만 하드웨어 스펙이 나름 준수했던 제 PC의 성능을 의심하지는 않았기 때문에 굉음과 답답한 속도는 전혀 나아지지 않았습니다.

며칠간의 뼈아픈 삽질 끝에 발견한 진짜 원인은 바로 저의 '과한 욕심'과 'VRAM에 대한 무지'에 있었습니다.

저는 반드시 성능이 가장 똑똑할 것이라는 단순한 생각에 무려 70B(700억 개 파라미터) 사이즈의 거대한 모델을 돌리고 있었습니다. LLM이 원활하게 작동하려면 이 거대한 모델이 그래픽 카드(GPU)의 VRAM(비디오 메모리)에 전부 올라가야 합니다.

하지만 제 PC의 VRAM은 고작 16GB. 70B 모델의 크기를 감당하기엔 턱없이 부족했습니다. VRAM이 꽉 차자 컴퓨터는 어쩔 수 없이 일반 시스템 RAM과 CPU를 끌어다 억지로 연산을 처리하기 시작했고, GPU보다 연산 속도가 현저히 느린 CPU가 과부하에 걸리며 굉음과 함께 속도가 바닥을 쳤던 것입니다. AI 모델의 체급과 내 하드웨어의 체급이 전혀 맞지 않았던 것이 근본적인 문제였습니다.

[해결책] 체급은 낮추고, 프롬프트는 날카롭게 다듬다

해결책은 생각보다 단순했다. 70B 대신 7B 모델로 교체했다. 같은 VRAM에서 7B 모델은 완전히 GPU 위에 올라갔고, 응답 속도는 즉각적으로 체감할 수 있을 만큼 빨라졌다. 물론 응답 품질은 다소 떨어졌지만, 그 간극은 프롬프트 엔지니어링으로 충분히 메울 수 있었다. 역할을 좁게 정의하고, 맥락을 압축해 주입하자 7B 모델도 사내 업무 자동화에는 충분한 수준의 결과를 냈다. 이번 경험을 통해 깨달은 핵심은 간단하다. '가장 좋은 모델'이 아니라 '내 하드웨어에 맞는 모델'을 선택하는 것이 실전에서의 올바른 출발점이다.