Ollama 사용법: 설치 후 첫 실행과 로컬·클라우드 구분

내 기기에서 실행하는 모델을 떠올리기 위한 AI 생성 이미지이며 실제 실행 화면은 아닙니다.

Ollama를 설치한 뒤 곧바로 큰 모델부터 받으면, 문제가 생겼을 때 설치·다운로드·모델 로딩·메모리·응답 생성 중 어느 단계가 실패했는지 알기 어렵습니다. 첫 실행의 목표는 벤치마크가 아닙니다. 작은 모델 하나로 서버가 떠 있는지, 모델이 내려받아졌는지, 실제로 메모리에 올라갔는지, 요청이 로컬에서 처리되는지를 순서대로 확인하는 것입니다.

또 하나 주의할 점은 “Ollama 앱을 사용한다”와 “모든 추론이 내 컴퓨터에서 일어난다”가 같은 문장이 아니라는 사실입니다. 공식 빠른 시작 문서는 로컬 모델과 :cloud 모델을 모두 안내합니다. 로컬 실행이 필요한 자료라면 모델 이름, 설정, 연결한 도구까지 함께 확인해야 합니다.

1. 설치, 모델 다운로드, 실행을 세 단계로 나눕니다

Ollama 빠른 시작 문서는 macOS·Windows·Linux용 설치 경로를 제공하고, 설치 후 터미널에서 ollama 메뉴나 ollama run으로 모델을 실행하는 흐름을 안내합니다. 설치가 끝났다고 모델 파일까지 준비된 것은 아닙니다.

먼저 명령줄 도구가 인식되는지 확인합니다.

ollama --version

버전이 출력되지 않고 command not found와 비슷한 메시지가 나온다면 모델을 바꿀 단계가 아닙니다. 앱 설치 여부, 터미널 재시작, 실행 경로부터 확인합니다. 버전이 출력되면 다음 단계에서 모델을 받습니다.

이 글에서는 기존 공식 라이브러리에 공개된 소형 태그인 llama3.2:1b를 절차 설명용으로 사용합니다. 최신 모델이나 한국어 품질이 가장 좋은 모델이라는 뜻은 아닙니다.

ollama pull llama3.2:1b

다운로드와 첫 대화를 한 번에 시작하려면 다음처럼 실행할 수도 있습니다.

ollama run llama3.2:1b

로컬에 해당 태그가 없으면 다운로드가 먼저 진행되고, 준비되면 대화 입력창이 나타납니다. 첫 질문은 짧고 판정하기 쉬운 것으로 고릅니다.

사과와 배의 공통점을 한 문장으로 설명해줘.

여기서 볼 것은 답변의 문학적 품질이 아닙니다. 프롬프트가 입력되고 응답이 끝까지 반환되는지 확인합니다. 대화를 종료할 때는 다음을 입력합니다.

/bye

이 흐름을 한 줄로 줄이면 다음과 같습니다.

설치 확인 → 모델 다운로드 → 모델 로딩 → 짧은 입력 → 응답 완료 → 실행 상태 확인

2. ls와 ps는 서로 다른 질문에 답합니다

Ollama CLI 문서는 내려받은 모델 목록과 실행 중인 모델 목록을 별도 명령으로 제공합니다.

ollama ls
ollama ps

• ollama ls: 로컬 저장소에 어떤 모델이 있는지 확인합니다.
• ollama ps: 지금 메모리에 올라가 실행 중인 모델을 확인합니다.

따라서 ollama ls에 이름이 나온다고 현재 실행 중이라는 뜻은 아닙니다. 반대로 방금 대화를 끝냈더라도 모델이 일정 시간 메모리에 남아 있으면 ollama ps에 계속 보일 수 있습니다. 즉, 디스크에 저장된 상태와 메모리에 로딩된 상태를 분리해서 봐야 합니다.

모델을 즉시 멈추고 싶다면 CLI 문서의 stop 명령을 사용합니다.

ollama stop llama3.2:1b

ollama ps의 PROCESSOR 열은 모델이 CPU, GPU 또는 둘의 조합에 어떻게 배치됐는지 확인하는 단서입니다. Ollama FAQ는 100% GPU, 100% CPU, CPU/GPU 혼합 표시의 의미를 설명합니다. 이 값은 “GPU를 인식했는가”를 보는 데 유용하지만, 답변 품질이나 초당 토큰 수를 보증하는 성능 점수는 아닙니다.

확인 순서는 다음처럼 두 터미널을 나누면 쉽습니다.

터미널 A: ollama run llama3.2:1b
터미널 B: ollama ps

터미널 A에서 모델이 답하는 동안 터미널 B에서 현재 로딩 상태와 PROCESSOR를 확인합니다. 대화를 종료한 뒤 다시 ollama ps를 실행하면 실행 상태가 어떻게 바뀌는지도 볼 수 있습니다.

3. 앱이 아니라 로컬 HTTP 서버로도 확인할 수 있습니다

Ollama는 로컬에서 HTTP 서버를 제공하며, 공식 FAQ의 예시에는 http://localhost:11434/api/generate 요청이 등장합니다. 터미널 대화는 되지만 다른 프로그램과 연결되지 않을 때는 API를 직접 한 번 호출하면 경계를 좁힐 수 있습니다.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2:1b",
  "prompt": "사과와 배의 공통점을 한 문장으로 설명해줘.",
  "stream": false
}'

이 요청에는 세 가지 확인점이 있습니다.

1. 주소가 localhost:11434인지 봅니다.
2. model 값이 실제로 내려받은 태그와 같은지 봅니다.
3. 스트리밍 응답을 단순하게 확인하려고 stream: false를 사용합니다.

응답이 JSON으로 돌아오면 적어도 로컬 서버와 모델 호출 경로가 연결된 것입니다. 다만 이것만으로 GPU 사용, 응답 품질, 외부 네트워크 단절 상태까지 모두 증명되지는 않습니다. 그 항목은 ollama ps, 설정, 별도의 네트워크 관찰로 확인해야 합니다.

연결이 거부된다면 모델 이름을 바꾸기 전에 서버가 실행 중인지 봅니다. 터미널에서 서버를 직접 시작하는 환경이라면 CLI 문서의 다음 명령이 있습니다.

ollama serve

macOS나 Windows 앱이 이미 백그라운드 서버를 실행 중인 상태에서 또 시작하면 포트 충돌 메시지가 날 수 있습니다. 그 경우는 “설치 실패”가 아니라 같은 주소를 이미 다른 Ollama 프로세스가 사용하고 있는지 확인할 문제입니다.

4. 작은 로컬 호출을 직접 확인한 결과

공식 명령을 따라 했다는 사실과 실제 요청이 로컬 서버에서 끝까지 처리됐다는 사실은 다릅니다. 그래서 2026년 9월 7일 제 개발 환경에서 짧은 smoke test를 한 번 실행했습니다. 이 결과는 다른 장비의 성능을 대표하지 않지만, 설치·서버·모델·프로세서 상태를 한 번에 확인하는 실제 관찰입니다.

항목	관찰값
운영 환경	arm64, macOS 26.6.2
Ollama	0.33.3
모델	qwen3:4b, 4.0B, GGUF Q4_K_M
모델 파일 크기	/api/tags에서 약 2.5GB
API 상태	GET http://127.0.0.1:11434/api/tags HTTP 200
요청	POST /api/generate, stream: false, temperature: 0

요청 본문은 다음과 같습니다. 짧고 정답을 눈으로 비교할 수 있게 만들었습니다.

curl -sS http://127.0.0.1:11434/api/generate \\
  -H 'Content-Type: application/json' \\
  -d '{"model":"qwen3:4b","prompt":"다음 문자열만 정확히 출력하세요: 로컬 확인 완료","stream":false,"options":{"temperature":0}}'

응답의 response는 두 번 모두 로컬 확인 완료였고 done은 true였습니다. Ollama가 반환한 내부 시간과 토큰 계수는 다음과 같았습니다.

실행	전체 시간	로딩 시간	eval_count	해석
첫 요청	29.745초	24.810초	463	모델을 메모리에 올리는 비용이 크게 포함됨
두 번째 요청	4.004초	0.008초	463	같은 모델이 남아 있는 warm 상태

curl 측정 시간은 각각 약 29.975초와 4.335초였습니다. 이 차이는 모델 품질 점수가 아니라 이 한 번의 요청에서 관찰한 처리 시간입니다. 눈에 보이는 답변은 8글자뿐인데 eval_count는 463이었습니다. 따라서 “답변이 짧으니 계산도 짧다”거나 “첫 요청과 두 번째 요청의 시간이 곧 모델 성능”이라고 해석하면 안 됩니다.

두 번째 요청 직후 ollama ps에는 qwen3:4b, PROCESSOR 100% GPU, CONTEXT 262144, SIZE 42 GB가 표시됐습니다. 같은 모델이 /api/tags에서는 약 2.5GB로 보였다는 점이 중요합니다. 디스크의 모델 파일 크기와 실행 중인 프로세스 표시를 같은 숫자로 읽으면 안 됩니다. 컨텍스트와 실행 상태까지 포함한 메모리 요구는 별도로 확인해야 합니다.

이 smoke test가 확인한 것은 네 가지입니다. 명령줄 설치가 인식됐고, 로컬 HTTP API가 응답했으며, 지정한 모델 태그가 존재했고, 해당 실행 시점의 프로세서 표시가 GPU 100%였습니다. 반대로 한국어 품질, 다른 모델의 속도, 장시간 안정성, 상위 애플리케이션의 외부 통신 여부까지 증명한 것은 아닙니다.

5. 로컬 모델과 클라우드 모델을 이름부터 구분합니다

공식 빠른 시작 문서는 일반 모델 실행과 :cloud 태그 실행을 별도로 보여줍니다.

ollama run gemma4
ollama run gemma4:cloud

첫 줄과 둘째 줄은 같은 실행 위치를 뜻하지 않습니다. FAQ는 로컬 모델을 사용할 때 프롬프트와 답변을 Ollama가 보지 않는다고 설명하는 반면, 클라우드 호스팅 모델은 서비스를 제공하기 위해 프롬프트와 응답을 처리한다고 밝힙니다. 따라서 비공개 문서나 고객 데이터를 다룬다면 “Ollama를 썼다”가 아니라 어떤 태그와 어떤 연결 경로를 썼는지 기록해야 합니다.

클라우드 기능을 쓰지 않을 계획이라면 FAQ가 안내하는 로컬 전용 설정을 적용할 수 있습니다.

{
  "disable_ollama_cloud": true
}

위 내용을 ~/.ollama/server.json에 두거나 다음 환경 변수를 사용할 수 있습니다.

OLLAMA_NO_CLOUD=1

설정 후에는 Ollama를 재시작해야 합니다. FAQ는 로그에서 Ollama cloud disabled: true를 확인할 수 있다고 설명합니다. 단지 :cloud 태그를 사용하지 않았다는 기억보다 설정과 로그를 함께 남기는 편이 재현하기 쉽습니다.

다만 로컬 모델을 쓴다고 데이터가 절대 외부로 나가지 않는 것은 아닙니다. 모델을 호출하는 상위 앱이 검색, 원격 도구, 텔레메트리, 파일 동기화를 사용할 수 있기 때문입니다. 모델 실행 위치와 전체 애플리케이션의 데이터 흐름은 별도로 확인해야 합니다.

6. 127.0.0.1을 바꾸기 전에 위험 범위를 계산합니다

FAQ에 따르면 Ollama는 기본적으로 127.0.0.1:11434에 바인딩됩니다. 이 주소는 같은 기기 안에서 접근하는 시작점입니다. 다른 컴퓨터나 컨테이너에서 접속시키려고 OLLAMA_HOST를 0.0.0.0:11434로 바꾸면 접근 범위가 달라집니다.

OLLAMA_HOST=0.0.0.0:11434 ollama serve

이 명령은 문제 해결용 만능 설정이 아닙니다. 0.0.0.0 바인딩은 여러 네트워크 인터페이스에서 연결을 받을 수 있게 하므로, 방화벽·인증·프록시·접근 가능한 네트워크를 함께 설계해야 합니다. 인터넷에 그대로 노출하라는 의미로 읽으면 안 됩니다.

처음 확인할 때는 기본 로컬 주소를 유지하고, 정말 원격 접근이 필요할 때만 다음을 적어보는 편이 안전합니다.

확인 항목	기록할 내용
접속 주체	같은 사용자, 같은 기기의 앱, 사내망의 다른 기기 중 무엇인가
바인딩 주소	127.0.0.1을 유지하는가, 다른 인터페이스를 여는가
인증	프록시나 상위 애플리케이션에서 어떻게 제한하는가
데이터	프롬프트에 비공개 파일이나 토큰이 포함되는가
로그	요청과 실패를 어디서 확인하는가

7. 긴 문서를 넣기 전에 컨텍스트와 메모리를 분리합니다

짧은 질문은 되는데 긴 문서에서 실패한다면 설치 문제로 되돌아갈 필요가 없습니다. FAQ는 컨텍스트 창 크기를 환경 변수나 실행 파라미터로 조정할 수 있다고 설명하고, 병렬 요청 수와 컨텍스트 길이가 필요한 RAM에 영향을 준다고 안내합니다.

예를 들어 서버의 기본 컨텍스트를 바꾸는 공식 FAQ 예시는 다음과 같습니다.

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

API에서는 options.num_ctx로 요청별 값을 전달할 수 있습니다.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2:1b",
  "prompt": "이 문서를 세 문장으로 요약해줘.",
  "options": {"num_ctx": 4096},
  "stream": false
}'

큰 숫자를 넣는다고 모델이 반드시 더 정확해지는 것은 아닙니다. 입력이 실제로 그 길이를 필요로 하는지, 메모리가 충분한지, 응답 시간이 허용 범위인지 같은 질문이 남습니다. 먼저 짧은 입력으로 성공 기준을 만들고, 실제 문서 길이까지 한 단계씩 늘리는 편이 원인을 찾기 쉽습니다.

8. 증상별로 실패 지점을 좁힙니다

증상	먼저 확인할 것	바로 모델을 바꾸지 말아야 하는 이유
ollama 명령을 찾지 못함	설치, 터미널 재시작, 실행 경로	모델 파일과 무관한 단계
pull이 멈추거나 실패함	인터넷 연결, 프록시, 디스크 공간, 정확한 태그	아직 추론 단계에 도달하지 않음
API 연결 거부	서버 실행 여부, localhost:11434, 포트 충돌	모델 품질과 무관한 서버 문제
모델 로딩 실패	사용 가능한 RAM·VRAM, 모델 크기, 실행 중인 다른 모델	다운로드 성공과 메모리 적재는 별도
응답이 매우 느림	ollama ps의 PROCESSOR, 입력 길이, 모델 크기	CPU 배치나 긴 컨텍스트가 원인일 수 있음
로컬이어야 하는데 외부 요청이 보임	:cloud 태그, cloud 설정, 상위 앱의 검색·도구	Ollama 모델 외의 구성 요소가 통신할 수 있음
종료 후 메모리가 남음	ollama ps, ollama stop	설치 목록과 실행 목록은 다름

문제 보고를 남길 때는 “Ollama가 안 된다” 대신 아래 다섯 줄을 적으면 재현성이 높아집니다.

운영체제:
Ollama 버전:
실행한 정확한 모델 태그:
실행한 명령과 전체 오류:
ollama ls / ollama ps 결과:

비공개 프롬프트, 사용자 경로, 토큰은 공유하기 전에 제거해야 합니다.

처음 15분에 끝낼 체크리스트

• 공식 설치 경로를 사용했다.
• ollama --version이 출력된다.
• 정확한 모델 태그 하나만 pull 또는 run했다.
• 짧은 질문에서 응답 완료를 확인했다.
• 별도 터미널에서 ollama ls와 ollama ps의 차이를 확인했다.
• 로컬 API를 쓴다면 localhost:11434에서 응답을 확인했다.
• 모델 이름에 :cloud가 붙는지 확인했다.
• 로컬 전용이 필요하면 cloud 비활성화 설정과 재시작 후 로그를 확인했다.
• 원격 접속이 필요하지 않다면 기본 로컬 바인딩을 유지했다.
• 긴 입력과 성능 평가는 첫 성공 이후 별도 단계로 미뤘다.

자료 확인일과 범위

자료 확인일은 2026년 9월 7일입니다. 설치·첫 실행·/bye는 Ollama 빠른 시작, run·pull·ls·ps·stop·serve는 Ollama CLI 문서, 로컬·클라우드 데이터 처리 설명과 cloud 비활성화·바인딩·컨텍스트·PROCESSOR 설명은 Ollama FAQ를 기준으로 정리했습니다.

이 글은 공식 문서에서 재구성한 절차에 한 번의 로컬 smoke test 관찰을 덧붙인 안내입니다. smoke test의 원시 결과는 프로젝트 내부 기록으로 보존했으며, 새 장비의 설치 시간이나 모델별 성능을 대표하는 벤치마크가 아닙니다. 한국어 정확도, 초당 생성 속도, 장시간 안정성, 상위 앱의 외부 통신은 측정하지 않았습니다. 모델 이름과 기본값은 이후 바뀔 수 있으므로 실행 전 현재 문서를 다시 확인해야 합니다.