무료 ARM 서버에 로컬 LLM을 올리려다 포기했다, 진짜 범인은 컨텍스트 4096이었다

“이제 로컬에서 인공지능 모델 돌리는 게 공짜다”라는 말을 여기저기서 듣는다. 오라클 클라우드는 서버를 평생 무료로 준다. 올라마(Ollama)라는 도구는 명령 한 줄이면 모델을 내려받아 실행해준다. 둘을 합치면 월 0원짜리 개인 인공지능 서버가 완성될 것 같다.

나도 그 계산으로 시작했다. 결론부터 말하면 무료 서버 쪽은 실패했다. 그리고 성공한 줄 알았던 데스크탑 쪽도 한참을 헤맸다. 어디서 막혔는지, 그리고 며칠을 답답해하다 찾아낸 진짜 원인이 무엇이었는지 적어둔다. 검색해보면 “설치했더니 잘 됩니다”로 끝나는 글은 많은데, 안 되는 이유를 끝까지 파본 글은 잘 없었다.

무료 서버에서는 왜 안 되는가

지난 글에서 다룬 오라클 무료 서버의 사양은 이렇다. CPU 2코어, 메모리 10GB 남짓, 디스크 여유 공간 9.7GB. 그리고 결정적으로 그래픽카드가 없다. 오라클 무료 등급이 주는 ARM 서버가 이 정도인데, 웹서비스를 돌리기엔 넉넉해도 인공지능 모델에는 이야기가 다르다.

인공지능 모델은 그래픽카드로 돌릴 때와 CPU로만 돌릴 때의 속도 차이가 크다. 그래픽카드는 단순한 계산을 동시에 수천 개씩 처리하도록 만들어진 부품이고, 모델을 돌리는 계산이 정확히 그런 종류다. CPU로 대신하면 못 하는 건 아닌데 훨씬 느리다.

디스크도 문제였다. 모델 파일은 생각보다 크다. 40억 개 규모 모델을 압축한 파일이 2.5GB 정도, 80억 개 규모면 4.7GB쯤 된다. 여유 공간 9.7GB에 워드프레스와 데이터베이스, 자동화 도구가 이미 자리를 잡고 있는 상태에서, 모델 하나를 겨우 올려놓고 나면 다른 걸 할 자리가 없었다.

참고로 로컬 모델 자체를 처음 만져본 건 이때가 아니었다. C# 환경에서 모델을 직접 불러 쓰는 방법은 LlamaSharp를 다룬 글에 따로 정리해뒀다.

어쨌든 무료 서버에 모델을 올리는 건 접었다. 아쉽지만 이게 정확한 판단이었다고 지금도 생각한다. 어딘가에서 “2코어에서도 돌아갑니다”라는 글을 보고 따라 하다 서버 전체를 느리게 만드는 것보다는, 처음부터 안 된다고 인정하는 편이 낫다.

데스크탑으로 옮겼는데, 이번엔 다른 문제가 생겼다

집 데스크탑은 조건이 완전히 다르다. 라이젠 5 9600X에 메모리 32GB, 그래픽카드는 RTX 3080 Ti다. 이 그래픽카드의 전용 메모리는 12GB인데, 이 숫자가 나중에 이야기의 핵심이 된다.

여기에 올라마를 설치하고 모델 네 개를 받아뒀다. 그리고 내가 쓰는 인공지능 비서에 연결했다. 목표는 분명했다. 오라클 서버를 관리하고, 그 서버에서 돌아가는 자동화 도구들을 손보는 일을 이 비서에게 맡기는 것이었다. 서버에 들어가 상태를 확인하고, 워크플로가 멈췄으면 고치고, 로그를 읽어 원인을 찾는 그런 일들이다.

결과부터 말하면 제대로 되지 않았다. 문제는 한 가지가 아니었다.

첫째, 같은 문제를 붙들고 똑같은 시도를 반복했다. 방금 안 된 방법을 조금 뒤에 또 꺼낸다. 자잘한 오류가 계속 나는데 그걸 넘어서지 못하니 정비가 끝나질 않았다.

둘째, 답을 내놓기 전에 혼자 생각을 늘어놓는 부분이 지나치게 느렸다. 그리고 대화가 길어지면 어김없이 헤맸다. 처음엔 잘 하다가 어느 순간부터 앞뒤가 안 맞았다.

셋째, 내 지시에 아예 응답을 못 하고 오류만 뱉는 경우도 잦았다. 무언가를 시켰는데 결과 대신 에러 메시지가 돌아오는 상황이 반복됐다.

그리고 넷째가 가장 현실적인 문제였다. 모델을 돌리는 동안 컴퓨터를 쓰기가 어려웠다. 브라우저를 열거나 다른 작업을 하려 하면 눈에 띄게 굼떴다. 서버를 편하게 관리하려고 붙인 도구인데, 그 도구를 켜두면 정작 내 컴퓨터가 불편해지는 상황이었다.

당연히 “모델이 작아서 그렇겠지” 또는 “내 그래픽카드가 부족한가” 싶었다. 그래서 재봤다.

먼저 속도를 실제로 재봤다

같은 질문을 던지고 초당 몇 개의 토큰을 만들어내는지 측정했다. 토큰은 모델이 글을 만들 때 다루는 조각 단위인데, 한국어에서는 대략 한두 글자 정도로 생각하면 얼추 맞는다.

모델별 생성 속도 (RTX 3080 Ti, 전용 메모리 12GB)

모델	파일 크기	생성 속도
gemma4:12b	7.6GB	73.1 토큰/초
qwen3:14b	9.3GB	74.2 토큰/초
qwen3:30b	18GB	52.6 토큰/초

예상과 달랐다. 세 모델 모두 사람이 읽는 속도보다 훨씬 빨랐다. 특히 놀란 건 18GB짜리 모델이었다. 그래픽카드 메모리 12GB를 6GB나 넘기는데도 초당 52개를 만들어냈다.

이유는 그 모델의 구조에 있다. 전체 크기는 크지만 질문 하나에 실제로 동원되는 부분은 그중 일부만인 방식으로 만들어져 있다. 전문가 여럿을 모아두고 질문마다 필요한 사람만 부르는 구조라고 보면 된다. 사전은 두꺼워도 매번 펼치는 쪽은 몇 장뿐인 셈이다.

요즘 나오는 이런 구조의 모델들은 국내에 정리된 모델 가이드에서도 확인할 수 있듯, 전체 규모는 수백억 개여도 실제 활성 부분은 그 10분의 1 이하인 경우가 흔하다. 그래서 파일 크기만 보고 “이건 내 컴퓨터에서 못 돌리겠다”고 지레 포기할 필요는 없다.

어쨌든 속도는 범인이 아니었다. 그렇다면 무엇이 문제였을까.

범인은 아무도 안 건드리는 기본값이었다

올라마에는 지금 어떤 모델이 올라와 있는지 보여주는 명령이 있다. 거기에 이런 줄이 찍혔다.

NAME         SIZE      PROCESSOR    CONTEXT
qwen3:14b    9.6 GB    100% GPU     4096

맨 오른쪽 4096이 문제였다. 이건 컨텍스트 길이, 그러니까 모델이 한 번에 기억할 수 있는 분량이다. 4096 토큰이면 한국어로 대략 A4 서너 장 남짓이다.

인공지능 비서를 쓸 때 이 안에 들어가야 하는 게 무엇인지 세어보면 문제가 분명해진다. 비서에게 주는 기본 지시문, 사용할 도구들의 설명서, 참고 문서, 그리고 지금까지 오간 대화 전체다.

도구 설명서가 특히 자리를 많이 먹는다. 모델이 외부 도구를 쓰려면 각 도구의 이름과 기능, 넘겨야 할 값들을 전부 알려줘야 한다. IBM이 정리한 도구 호출 예제만 봐도 도구 하나에 붙는 설명이 짧지 않은데, 도구가 열 개만 되어도 대화를 시작하기 전에 이미 상당한 자리가 차 있는 셈이다.

넘치면 어떻게 될까. 오래된 부분부터 잘려나간다. 모델 입장에서는 자기가 조금 전에 무엇을 시도했는지가 통째로 사라진다. 그러니 방금 실패한 방법을 다시 꺼낸다. 대화가 길어질수록 앞부분이 더 많이 잘려나가니 갈수록 헤맨다.

내가 답답해했던 세 증상 중 두 개가 여기서 나왔다. 모델이 멍청해서가 아니라, 기억할 자리를 안 준 채로 시킨 것이었다. 그리고 이 4096은 내가 설정한 값이 아니라 올라마가 별도 지정이 없을 때 쓰는 기본값이다.

나머지 하나, 생각하는 시간의 비용

세 번째 증상인 “생각이 느리다”도 원인이 따로 있었다. 요즘 모델 중에는 답하기 전에 혼자 추론 과정을 길게 써 내려가는 종류가 있다. 내가 받아둔 큐원(Qwen) 계열이 그랬고, 젬마(Gemma) 계열은 아니었다.

같은 질문으로 이 기능을 켰을 때와 껐을 때를 비교했다.

생각 과정 출력의 비용 (qwen3:14b, 동일 질문)

구분	생성 토큰	걸린 시간
생각 과정 켬	563개	7.8초
생각 과정 끔	286개	4.0초

같은 답을 얻는 데 토큰이 두 배 들었다. 그런데 진짜 문제는 시간이 아니다. 그 563개의 토큰이 안 그래도 좁은 4096 자리를 또 차지한다는 것이다. 도구를 한 번 쓸 때마다 생각 과정이 쌓이니, 몇 번만 왕복해도 기억할 자리가 바닥난다. 두 문제가 서로를 악화시키고 있었다.

고치려고 보니 답이 반대였다

해결은 간단해 보였다. 컨텍스트를 늘리면 된다. 그런데 컨텍스트를 늘리면 그만큼 그래픽카드 메모리를 더 쓴다. 12GB밖에 없는 상황에서 이게 어디까지 버티는지 직접 재봤다.

컨텍스트를 늘렸을 때 실제로 벌어진 일

설정	차지한 메모리	어디서 도는가	속도
qwen3:14b, 16K	12GB	CPU 16% / 그래픽카드 84%	74 → 28 토큰/초
gemma4:12b, 32K	8.1GB	100% 그래픽카드	72.8 토큰/초 유지

더 큰 모델인 qwen3:14b는 컨텍스트를 16K로 올리자마자 12GB를 꽉 채웠다. 다 못 올라간 부분은 CPU로 밀려났고 속도가 3분의 1로 떨어졌다. 반면 작은 gemma4:12b는 컨텍스트를 그 두 배인 32K까지 올려도 8.1GB에 머물렀다. 전부 그래픽카드 안에 남았고 속도도 그대로였다.

여기서 얻은 결론이 내가 처음 생각했던 것과 정반대다. 그래픽카드 메모리가 넉넉하지 않은 환경에서 인공지능 비서를 굴릴 거라면, 큰 모델을 좁은 기억력으로 쓰는 것보다 작은 모델에 넉넉한 기억력을 주는 편이 낫다. 모델을 고를 때 우리는 보통 파라미터 수부터 본다. 그런데 도구를 여러 번 쓰며 일하는 용도에서는 얼마나 오래 기억하느냐가 더 중요했다.

컴퓨터가 굼떠지던 이유도 여기 있었다

네 번째 문제였던 “모델을 켜두면 컴퓨터를 쓰기 어렵다”도 같은 표에서 설명이 된다. 그래픽카드 메모리 12GB 중 모델이 8GB에서 12GB를 가져간다. 남는 자리로 화면 출력과 브라우저를 감당해야 하니 굼떠질 수밖에 없다.

18GB짜리 모델은 더 심하다. 그래픽카드에 다 못 들어간 6GB가 컴퓨터 본체 메모리로 넘어오고, 그 부분을 CPU가 계산한다. 속도는 앞서 본 대로 그럭저럭 나오지만, 그동안 CPU와 메모리가 붙잡혀 있다. 개인용 컴퓨터 한 대로 모델도 돌리고 일도 하려는 계획 자체에 무리가 있었던 셈이다.

그래서 지금은 어떻게 하고 있나

무료 서버에는 모델을 올리지 않는다. 대신 자동화와 웹서비스를 돌리는 데 집중하고, 인공지능이 필요한 부분은 외부 API를 부른다. 이게 지금 사양에서 가장 정직한 배치다.

서버 관리를 로컬 모델에게 맡기려던 계획은 일단 접었다. 컨텍스트를 넓히면 헤매는 문제는 줄어든다. 하지만 자잘한 오류가 났을 때 방법을 바꿔 다시 접근하는 능력, 그리고 여러 단계를 오가며 판단을 이어가는 능력은 컨텍스트를 넓힌다고 생기지 않았다. 그건 모델의 급 자체가 다른 문제였다.

대신 로컬 모델의 자리를 좁혔다. 요약이나 분류처럼 한 번에 끝나고, 틀려도 크게 손해가 아닌 일이라면 로컬로 충분하다. 반면 서버를 실제로 건드리는 일, 여러 도구를 오가며 스스로 판단해야 하는 일은 성능이 검증된 모델에 맡기는 게 맞다고 결론지었다.

혹시 나처럼 “집 컴퓨터로 서버를 관리하는 인공지능 비서를 만들어야지”라고 생각하고 있다면, 시작하기 전에 두 가지를 먼저 확인하기 바란다. 지금 컨텍스트가 몇으로 잡혀 있는지, 그리고 쓰는 모델이 생각 과정을 길게 뱉는 종류인지. 이 둘을 모르고 시작하면 나처럼 “왜 이렇게 멍청하지” 하며 애먼 모델만 탓하게 된다.

그리고 하나 더. 그 비서가 돌아가는 동안 그 컴퓨터로 다른 일도 해야 한다면, 모델 크기를 고를 때 그래픽카드 메모리를 다 쓰지 않고 남겨두는 편이 낫다. 성능표에는 안 나오지만 매일 쓰는 사람에게는 그게 더 중요하다.