로컬 LLM 코딩 — Continue 설정과 자동완성

로컬 LLM 코딩, 모델 이름보다 연결부터 맞추기

Ollama는 모델을 실행하고 요청을 받는 프로그램이고, Continue는 VS Code 안에서 코드와 질문을 그 프로그램에 보내는 확장이다. 확장에 이름을 적는 것만으로 모델 파일이 내려받아지지는 않는다. 연결할 프로그램, 사용할 모델 파일, 편집기 설정이 각각 준비돼야 한다. 설치 자체가 낯설다면 기존 Ollama 설치·활용 가이드에서 기본 실행까지 마친 뒤 이어갈 수 있다.

처음 연결할 예시는 qwen2.5-coder:1.5b다. Continue의 로컬 자동완성 문서에 실제로 쓰인 태그이며, Ollama 배포 페이지의 표시 크기는 986MB다. 작은 파일로 연결 경로부터 점검하려는 선택이다. 큰 모델과의 품질 비교 결과를 뜻하지 않으며, 이 파일 크기가 실행에 필요한 메모리 전체라는 뜻도 아니다. RAM은 컴퓨터의 작업 메모리이고 VRAM은 그래픽카드의 전용 메모리다. 문맥을 늘리면 추가 메모리가 필요할 수 있다.

전체 순서는 여섯 단계다. 한 단계가 확인되면 다음으로 넘어간다.

1. Ollama를 켠다.
2. 모델을 받고 목록에서 이름을 확인한다.
3. 로컬 API가 모델 목록을 돌려주는지 본다.
4. Continue를 설치하고 설정 파일에 모델과 역할을 넣는다.
5. 채팅창에서 짧은 코드 설명을 받아 본다.
6. 코드 파일에서 자동완성 제안을 받아 본다.

아래는 단계마다 칠 명령과 확인할 화면이다.

1. Windows라면 Ollama 앱을 시작한다. 이미 실행 중이면 그대로 둔다. 앱 대신 서버를 직접 띄우는 환경에서는 아래 명령을 쓴다.

ollama serve

잘 됐으면 로컬 요청을 받을 서버가 실행된 상태다. 이미 주소를 사용 중이라는 오류가 뜨면 같은 서버를 또 시작한 경우인지 다음 조회로 가린다. 실행 창만 여러 개 여는 것으로 해결하려 하지 않는다.

1. VS Code의 터미널을 PowerShell로 열고, 아래 모델을 받은 뒤 목록을 조회한다. pull은 내려받기, list는 받은 모델을 보는 명령이다.

ollama pull qwen2.5-coder:1.5b
ollama list

잘 됐으면 목록에 설정할 태그가 보인다. 태그는 모델 이름 뒤 콜론(:) 다음에 붙는 크기·판 표시다. 이름 뒤의 콜론 부분까지 적어 두면 된다. Continue 안내는 deepseek-r1처럼 이름만 쓰면 :latest가 받아져 크기가 다를 수 있다고 적는다. 그래서 문서의 모델 이름과 실제 목록의 이름을 글자까지 맞춘다.

모델이 실제로 대답하는지도 터미널에서 바로 볼 수 있다. Continue 자동완성 문서의 점검 순서에도 이 명령이 들어 있다. 대화 입력 줄이 열리면 짧게 한 줄 물어보고, 답이 나오면 그 터미널 창을 닫고 다음 단계로 간다.

ollama run qwen2.5-coder:1.5b

명령을 찾을 수 없다고 나오면 Ollama 설치와 터미널에서의 인식부터 해결할 단계다. 다운로드 중 연결이 끊긴 상태를 편집기 설정 오류로 해석하지 않는다.

모델이 있다는 사실과 서버에 닿는다는 사실

1. 같은 PowerShell에서 로컬 API를 조회한다. API는 프로그램끼리 요청과 응답을 주고받는 창구다. 아래 주소는 받은 모델 목록을 돌려주는 공식 경로다.

Invoke-RestMethod -Uri 'http://localhost:11434/api/tags'

잘 됐으면 응답에 models가 나타나고, 모델을 받은 상태라면 그 안에 해당 이름이 들어 있다. 이 조회는 모델이 코드를 생성할 수 있는지까지 시험하는 것은 아니다. 통신 성공과 모델 등록을 먼저 분리해 보는 절차다. 응답은 오지만 목록이 비었다면 다운로드와 모델 이름 쪽으로 돌아간다.

연결 거부가 나오면 Ollama 앱이 켜져 있는지와 주소를 본다. Ollama의 기본 수신 주소는 127.0.0.1:11434이며 같은 PC 안에서 쓰는 구성이다. 여기서 localhost는 요청을 보내는 프로그램이 실행되는 컴퓨터를 가리킨다. 이 글은 Ollama와 확장이 같은 PC에 있는 경우를 전제로 한다. 원격 창이나 컨테이너에서 확장을 실행하면 같은 이름의 주소가 다른 환경을 가리킬 수 있다.

Ollama VSCode 설정, 채팅과 자동완성 역할 넣기

1. Continue 확장을 VS Code에 설치하고 사이드바(화면 옆 세로 패널)를 연다. 공식 설치 문서는 Visual Studio Marketplace(VS Code 확장을 내려받는 공식 장터)의 Continue 확장 페이지에서 Install을 누르는 순서를 안내한다. 채팅 입력창 위의 설정 선택기를 열고, Local Config 옆 톱니바퀴를 눌러 설정 파일로 들어간다.

설정 파일은 YAML이라는 들여쓰기로 항목을 나누는 형식이다. Windows의 위치는 %USERPROFILE%\.continue\config.yaml이다. 실제 사용자 이름을 경로에 직접 넣을 필요는 없다. 다른 폴더에 같은 이름의 파일을 새로 만드는 것보다 Continue가 열어 준 파일을 편집하는 편이 선택한 설정과 저장한 파일이 어긋나는 일을 줄인다.

기존 설정을 사본으로 남긴 뒤 아래 최소 구성으로 연결을 시험할 수 있다. 이 예시는 채팅과 자동완성을 같은 작은 모델에 맡긴다. name은 화면에서 알아볼 표시 이름이고 model은 Ollama 목록과 일치해야 하는 실행 이름이다. 화면 이름을 바꾸는 일과 모델 파일을 바꾸는 일은 다르다.

그대로 붙여 넣을 최소 설정

아래 설정의 contextLength는 문맥 길이, 즉 모델이 함께 다룰 입력과 응답의 범위를 제한하는 값이다. 단위인 토큰은 모델이 글을 처리하는 조각이다. 예시의 4096은 Ollama FAQ에 나온 값을 명시한 출발점이며, 모든 장비의 권장값이나 모델의 최대 능력을 뜻하지 않는다.

name: Local Coding
version: 1.0.0
schema: v1
models:
  - name: Local Qwen Coder
    provider: ollama
    model: qwen2.5-coder:1.5b
    apiBase: http://localhost:11434
    roles:
      - chat
      - autocomplete
    defaultCompletionOptions:
      contextLength: 4096

provider: ollama는 요청을 처리할 제공자 종류이고 apiBase는 그 서버의 기본 주소다. 기본 주소 뒤에 모델 목록 경로를 붙여 쓰지는 않는다. 앞 절의 API 조회 주소와 설정의 기본 주소는 쓰임이 다르다. 저장했으면 선택한 설정이 Local Coding인지, 채팅 모델이 Local Qwen Coder인지 본다. 정상이라면 저장 후 설정이 다시 로드된다.

파일 맨 위의 version: 1.0.0은 이 설정의 버전 표기다. 설치한 확장의 버전을 바꾸는 항목은 아니다. 예전 설명에서 config.json을 보더라도 이 글의 YAML 항목을 JSON 문법으로 섞지 않는다. 공식 참조 문서는 JSON 설정을 폐기 예정 형식으로 구분한다. 파일 확장자, 선택한 설정, 내용의 문법을 함께 맞춰야 같은 파일을 편집하고 있다는 판단이 선다.

설정을 읽지 못하면 들여쓰기와 파일 위치부터 본다. 특히 roles 아래 값은 모델 항목에 속해야 한다. YAML은 줄 앞 공백 칸 수로 어느 항목에 속하는지를 가르므로, 위 코드 블록의 두 칸 들여쓰기를 고치지 않고 그대로 붙여 넣는다. 오류 표시가 있는 채로 모델의 답변 품질을 비교할 단계는 아니다. 설정이 바뀌지 않은 것처럼 보이면 다른 설정을 선택한 상태인지도 살핀다.

여기서 놓치기 쉬운 기본값이 있다. Continue 문서는 roles를 생략했을 때 기본 목록에 chat, edit, apply, summarize가 들어간다고 적는다. 그 목록에는 autocomplete가 없다. 그래서 채팅 답변은 오는데 입력 중 제안만 안 보인다면 모델을 다시 받기 전에 자동완성 역할을 지정했는지 볼 이유가 있다.

역할 이름이 모델의 능력을 새로 만들어 주지는 않는다. 에이전트 모드는 도구를 호출할 수 있는 모델이 필요하며, 문서도 표시된 지원과 실제 동작이 다를 수 있다고 설명한다. 처음 목표는 채팅과 짧은 코드 제안이다. 파일을 찾아 수정하고 명령까지 실행하는 기능은 별도의 도구 지원 조건을 확인한 뒤 넓힐 범위다. 편집기별 작업 범위 차이는 AI 코딩 도구 비교와 함께 읽을 수 있다.

인용 — Continue. Quick Start with Autocomplete

Autocomplete provides inline code suggestions as you type.

입력하는 동안 코드 줄 안에 제안을 보여 준다는 뜻이다. 채팅창의 답변과는 화면에 나타나는 위치와 받아들이는 방식이 다르다.

로컬 LLM 코딩 점검, 답변과 코드 제안을 따로 보기

1. Continue를 채팅 모드로 두고, 선택한 로컬 모델에 짧은 코드 설명을 요청한다. 처음부터 프로젝트 전체를 고치라고 하기보다 입력한 코드와 요청이 맞는지 살피는 편이 연결 상태를 판단하기 쉽다. 아래 코드는 글에서 만든 학습용 예제이며 제품의 성능 수치가 아니다.

function sumPrices(prices) {
  return prices.reduce((total, price) => total + price, 0);
}

코드를 채팅창에 붙이고 이렇게 묻는다. 외부 라이브러리가 필요한 예제를 쓰지 않아, 설명을 받은 뒤 실행 결과까지 비교하기 쉽다.

이 JavaScript 함수가 하는 일을 한국어로 설명해 줘.
빈 배열이 들어와도 동작하는 이유를 알려 줘.
코드 수정안은 아직 만들지 말고 설명만 해 줘.

잘 됐으면 채팅창에 답변이 나온다. 다만 자연스럽게 설명했다는 사실만으로 내용까지 맞는 것은 아니다. 예제는 초기 누적값을 명시했으므로 빈 배열도 처리한다. 모델이 빈 배열에서 반드시 오류가 난다고 답했다면 실행 결과와 어긋나는 설명이다. 연결 성공과 설명 정확도를 나눠 기록할 수 있다.

자동완성은 편집기 본문에서 시험한다

1. 작업용 JavaScript 파일을 열고 주석과 함수 선언을 입력한다. 아래 예제의 마지막 줄 다음으로 커서를 옮겨 이어질 제안을 기다린다. 완성된 함수를 이미 붙여 넣은 상태와 섞지 않도록 별도 시험 파일을 쓰면 된다.

// 배열에 든 가격을 합하고 빈 배열이면 0을 반환한다.
function sumPrices(prices) {

Continue의 Enable Tab Autocomplete가 켜져 있고 자동완성 모델이 선택돼 있어야 한다. VS Code에서는 아래쪽 상태 표시줄의 Continue 버튼을 눌러 이 설정을 켜고 끈다. 정상이라면 채팅창 대신 커서 위치에 흐린 코드가 나타난다. 제안 전체를 받으려면 Tab, 버리려면 Esc를 누른다. 바로 제안을 요청하는 기본 단축키는 Ctrl+Alt+Space이며 macOS에서는 Cmd+Alt+Space다. 키가 다른 기능과 겹치면 명령의 키 배정을 볼 수 있다.

채팅은 되는데 제안이 없으면 자동완성 역할, 선택 모델, 켜기 설정을 차례로 본다. 공식 문서는 다른 완성 제공자와의 충돌을 점검하고 VS Code의 editor.inlineSuggest.enabled가 켜져 있는지도 보라고 안내한다. 아래는 VS Code 설정의 해당 값이다. 전체 설정 파일을 이 작은 조각으로 덮기보다 기존 설정 안에서 값을 찾는다.

{
  "editor.inlineSuggest.enabled": true
}

채팅용으로 큰 모델을 골랐다고 자동완성도 자연스러워지는 것은 아니다. Continue 문서는 자동완성에 특정 프롬프트 형식을 쓰는 모델을 안내한다. 대조한 어댑터 소스도 모델 템플릿에 .Suffix가 있는지를 보고 FIM 지원을 추정한다. FIM은 커서 앞과 뒤의 코드를 함께 보고 빈 부분을 채우는 방식이다. 해당 작은 Qwen 태그의 템플릿에도 .Suffix를 쓰는 분기가 보인다.

이 판별은 모델이 어떤 제안을 하더라도 정답이라고 인증하는 절차가 아니다. 문법이 맞아도 계산 조건을 빠뜨릴 수 있고, 주석과 다른 함수를 만들 수도 있다. 제안을 받아들인 뒤에는 원래 의도와 입력 조건을 비교할 차례다. 아래 코드는 앞의 완성된 함수에 붙여 실행하는 확인용 예제다.

console.log(sumPrices([1200, 800]));
console.log(sumPrices([]));

앞의 함수 그대로라면 출력은 다음과 같다. 모델이 만든 코드의 실측 결과가 아니라 이 글의 고정된 예제에서 계산한 값이다. 제안으로 함수가 달라졌다면 같은 입력을 넣고 결과를 비교할 수 있다.

2000
0

설명을 평가할 때는 정상 입력만 보지 않는다. 이 함수는 배열의 원소가 숫자라는 전제로 작성됐다. 문자열로 된 가격이 섞이면 덧셈이 문자열 이어 붙이기로 바뀔 수 있다. 모델에게 그 조건을 물어보고, 실제 입력 형식과 맞는 답인지 볼 수 있다. 처음부터 입력 보정과 예외 처리까지 한꺼번에 생성하게 하기보다 함수가 받는 값의 종류를 분명히 하는 연습이다.

제안을 받을 때마다 완성된 파일 전체를 새 답변으로 덮을 필요도 없다. 커서 뒤에 이미 코드가 있다면 그 부분과 연결되는지, 같은 반환문이나 닫는 괄호를 다시 넣지는 않았는지 읽는다. 자동완성은 입력 도중 받아들이거나 버릴 수 있는 제안이라는 사용 방식이므로, 채팅에 나온 긴 설명을 통째로 복사하는 경우와 검토 지점이 달라진다.

Ollama VSCode 메모리, 터미널과 달라지는 조건

터미널에서는 모델이 응답했는데 Continue에서는 메모리 오류가 날 수 있다. 공식 제공자 문서도 다른 Ollama 도구보다 높은 문맥 길이가 설정될 수 있다며 줄여 보라고 안내한다. 같은 모델 이름을 썼다는 사실만으로 같은 요청 설정을 쓴 것은 아니라는 뜻이다. 오류가 발생한 요청의 문맥 값이 모델 파일 크기보다 유용한 단서일 수 있다.

소스에서도 이유를 찾을 수 있다. 이번에 대조한 확장 manifest(확장의 이름·버전을 적은 설명 파일)의 표기는 1.3.40이다. Ollama 어댑터는 Continue 안에서 Ollama와 요청을 주고받는 부분의 코드다. 그 소스 묶음의 Ollama 어댑터는 다른 문맥 값이 없을 때 8192를 대체값으로 쓰고, 요청의 num_ctx에는 현재 문맥 길이를 넣는다. num_ctx는 Ollama가 요청마다 받는 문맥 길이 값이다. BaseLLM(여러 모델 연결이 함께 쓰는 공통 코드)은 명시한 설정과 모델 정보에서도 문맥 값을 가져온다. 따라서 모든 설치판이 항상 같은 길이를 쓴다고 단정할 수 없다.

Ollama FAQ가 적은 기본 문맥 안내는 4096토큰이다. 이 숫자와 어댑터의 대체값을 비교하면, 터미널에서 됐다는 이유로 편집기 요청의 메모리 사용도 같을 것이라 가정할 수 없음을 알 수 있다. 문맥 길이를 키우면 더 긴 코드를 담을 여지는 생기지만, 모델의 코딩 지식이나 계산 정확도가 그 숫자만큼 늘어나는 것은 아니다.

길이를 줄인 요청과 메모리에 남은 모델

설정을 읽는 데는 성공했지만 메모리가 부족하다면, 앞의 모델 항목 안에서 문맥 길이를 줄여 비교할 수 있다. 아래는 제공자 문서가 오류 대응 예시로 제시한 2048을 적용하는 부분이다. 기존 모델 항목의 defaultCompletionOptions 값을 바꿔 쓰는 조각이며, 파일 전체를 대신하지 않는다.

defaultCompletionOptions:
  contextLength: 2048

이 값으로 짧은 질문을 다시 보내면 같은 모델에서 문맥 설정의 영향을 좁혀 볼 수 있다. 성공해도 긴 프로젝트 전체를 담는 데 충분하다는 뜻은 아니다. 모델 변형을 줄이는 방법도 공식 문서의 대응책에 들어 있다. 모델과 문맥을 동시에 바꾸면 어느 변경이 영향을 줬는지 알기 어려우므로, 비교할 때는 질문과 설정을 함께 남기는 편이 낫다.

contextLength와 maxTokens도 다른 설정이다. 앞의 값은 모델의 문맥 범위를, 뒤의 값은 한 응답에서 생성할 토큰의 최대 수를 가리킨다. 답이 중간에 끊기는 문제와 요청을 시작하지 못하는 메모리 오류를 같은 숫자로 해결할 수는 없다. 질문에 붙인 코드가 길어졌는지, 응답 길이 제한을 바꿨는지까지 기록하면 비교가 구체적이 된다.

모델이 응답한 뒤 메모리에 남는 시간에도 차이가 있다. Ollama FAQ는 자체 기본 안내를 5분으로 적지만, Continue 설정 문서는 keepAlive의 기본값을 1800초, 즉 30분으로 적는다. 대조한 어댑터의 채팅과 생성 경로도 값이 따로 없으면 60 * 30을 keep_alive로 보낸다. 요청이 끝난 뒤에도 모델이 보이는 상황을 곧바로 멈춘 작업으로 읽을 수 없는 이유다.

현재 메모리에 올라온 모델은 아래 명령으로 본다. PROCESSOR는 GPU와 CPU 중 어디에 모델이 올라갔는지 보여 준다.

ollama ps

잘 됐으면 로드된 모델의 이름과 배치 상태가 나타난다. 내려받은 파일 목록을 보여 주는 ollama list와 목적이 다르다. 작업을 마치고 모델을 메모리에서 내리려면 아래 명령을 쓸 수 있다. 모델 파일을 지우는 명령은 아니다.

ollama stop qwen2.5-coder:1.5b

모델을 내린 뒤에도 편집기에서 계속 제안을 요청하면 다음 요청으로 다시 올라올 수 있다. 작업을 마쳤다면 Continue의 자동완성을 꺼 둔 상태에서 중지하고, 실행 중 목록을 다시 보는 편이 원인을 가르기 쉽다. 또한 Ollama FAQ는 요청의 keep_alive가 서버의 OLLAMA_KEEP_ALIVE보다 우선한다고 설명한다. 서버 환경 변수만 바꿨는데 기대한 시점에 내려가지 않는다면 클라이언트의 요청값을 볼 근거다.

채팅 모델을 추가할 때에는 표시 이름도 서로 다르게 둔다. 이어서 채팅 선택기와 자동완성 선택기에서 맡길 모델을 각각 고른다. 자동완성 역할의 모델을 바꾸지 않았는데 채팅 모델만 커졌다면, 코드 제안까지 바뀌었다고 가정할 수 없다. 처음 연결에 쓴 모델 태그와 새 태그를 함께 남겨 두면 원래 구성으로 돌아가 비교하기도 쉽다.

로컬 모델을 선택한 것과 프로그램 전체가 인터넷 요청을 하지 않는 상태도 나눠 봐야 한다. Continue의 오프라인 문서는 로컬 모델 지정과 함께 Allow Anonymous Telemetry를 끄고 필요한 확장을 미리 준비하는 절차를 안내한다. Ollama는 클라우드 기능을 끄는 OLLAMA_NO_CLOUD 설정도 제공한다. 다운로드가 끝났다는 이유만으로 현재 선택한 모델과 모든 연결이 로컬이라고 판단하지 않는다.

무료 AI 코딩을 찾는 독자라면 이번 구성의 범위를 명확히 잡을 수 있다. 여기서 고른 것은 내 PC에 받은 모델로 보내는 요청이다. 전기·저장 공간·하드웨어 부담은 남고, 유료 도구와 같은 속도나 품질을 보장하는 비교는 하지 않았다. 제품 안에서 별도 모델이나 외부 기능을 고른다면 조건도 다시 봐야 한다. 다른 편집기 흐름은 Cursor 첫 사용 가이드와 비교해 볼 수 있다.

자주 묻는 것

모델을 받았는데 Continue 목록에 안 보이면 무엇부터 보나?

로컬 API가 응답하는지 본 뒤, 선택한 Local Config의 model이 받은 태그와 같은지 살핀다. 화면에 표시할 name만 바꾸는 것으로 실행할 모델이 달라지지는 않는다. 설정 오류 표시가 있다면 모델 선택보다 그 오류를 먼저 해결할 단계다.

채팅이 되면 코드 자동완성도 연결된 것인가?

역할과 표시 위치를 따로 봐야 한다. autocomplete 역할을 넣고 해당 모델을 선택한 뒤, 확장 설정과 VS Code 인라인 제안을 켠다. 제안은 코드 파일의 커서에 나타나며 Tab으로 받고 Esc로 버린다.

작은 모델로 프로젝트 수정까지 맡길 수 있나?

이 글의 최소 구성은 코드 설명과 인라인 제안을 점검하는 범위다. 에이전트 모드는 도구 호출 지원이 필요하며 표시된 지원과 실제 동작이 다를 수 있다. 역할을 더 적는 것만으로 모델의 도구 사용 능력이나 수정 정확도가 보장되지는 않는다.

모델 파일 크기만큼 메모리가 있으면 되는가?

파일 크기와 실행에 필요한 메모리는 다른 값이다. Continue는 문맥 길이가 커져 같은 모델에서도 메모리 오류가 생길 수 있다고 안내한다. 작은 Qwen 태그의 표시 크기 986MB를 RAM이나 VRAM의 합격선으로 옮겨 읽을 수 없다.

정리 — 로컬 연결 뒤에는 제안의 동작을 본다

처음 목표는 모델 목록, API 응답, 채팅 답변, 커서의 코드 제안이 이어지는 상태다. 여기까지 되면 짧은 함수와 입력 예제로 내용이 맞는지 평가할 수 있다. 연결 오류와 모델이 틀린 답을 낸 상황이 분리되므로 다음에 바꿀 대상도 분명해진다.

메모리가 부족하면 사용한 모델 태그와 문맥 길이를 함께 남기고 짧은 요청부터 비교한다. 답변 뒤 모델이 남아 있다면 ollama ps와 유지 시간 설정을 볼 차례다. 코드 제안을 많이 받는 것보다, 필요한 부분을 받아들이고 실행 결과로 판단하는 습관이 이 구성에서 먼저 익힐 사용법이다.

참고 자료

1. Ollama. CLI Reference — 모델 받기·목록·서버 시작·실행 중 모델·중지 명령(2026-11-01 확인). docs.ollama.com
2. Ollama. List models API — 로컬 모델 목록을 조회하는 GET 경로(2026-11-01 확인). docs.ollama.com
3. Continue. Install — 공식 확장 설치 경로와 사이드바(2026-11-01 확인). docs.continue.dev
4. Continue. How to Understand Configuration — Local Config 열기·파일 위치·저장 후 재로딩(2026-11-01 확인). docs.continue.dev
5. Continue. config.yaml Reference — 역할 기본값·문맥 길이·keepAlive의 의미와 단위(2026-11-01 확인). docs.continue.dev
6. Continue. Autocomplete Setup and Configuration Guide — Qwen 자동완성 예시·인라인 설정·충돌 점검(2026-11-01 확인). docs.continue.dev
7. Continue. Quick Start with Autocomplete — 인라인 제안·수락·거절·강제 호출(2026-11-01 확인). docs.continue.dev
8. Continue. Ollama Provider — provider·apiBase·메모리 오류 시 문맥 줄이기(2026-11-01 확인). docs.continue.dev
9. Continue. Ollama.ts — 기본 주소·num_ctx·문맥 대체값·keep_alive·FIM 판별(2026-11-01 확인). raw.githubusercontent.com
10. Ollama. FAQ — 기본 바인딩·문맥 안내·모델 상주·GPU 확인·클라우드 끄기(2026-11-01 확인). docs.ollama.com
11. Continue. How to Run Without Internet — 로컬 모델·익명 사용 정보 설정·오프라인 준비(2026-11-01 확인). docs.continue.dev
12. Ollama. qwen2.5-coder:1.5b — 작은 모델 태그·표시 크기·양자화·템플릿(2026-11-01 확인). ollama.com
13. Ollama. qwen2.5-coder:7b — 확장 비교용 모델의 태그·표시 크기(2026-11-01 확인). ollama.com
14. Continue. Using Ollama with Continue — 정확한 모델 태그·직접 설정·에이전트의 도구 지원 조건(2026-11-01 확인). docs.continue.dev
15. Continue. BaseLLM 소스 — 명시한 값과 모델 정보의 문맥 길이 우선순위(2026-11-01 확인). raw.githubusercontent.com
16. Continue. VS Code 확장 manifest — 대조한 소스 묶음의 버전 표기(2026-11-01 확인). raw.githubusercontent.com