안녕하세요, 닥스훈트입니다.

2026년 6월부터 GitHub Copilot의 과금 방식이 AI Credit에 의한 종량제로 이행되었습니다. 이전과 같은 방식으로 계속 사용하고 있음에도 요금이 꽤 올랐다는 실감이 들며, X(구 Twitter)에서도 "실질적인 가격 인상 아닌가?"라는 목소리를 자주 접하게 됩니다.

그래서 "GitHub Copilot에서 사용하는 LLM 부분을 로컬 LLM (Local LLM)으로 전환하면, AI Credit을 소비하지 않고 이용 요금도 억제할 수 있지 않을까?"라고 생각했습니다. 로컬 LLM이라면 추론 비용은 제로이므로 마음껏 사용할 수 있을 터——라고 생각하여, 우선 가지고 있는 노트북(CPU 전용)으로 시도해 보기로 했습니다. (실제로 시도해 보니 로컬 LLM의 동작이 극도로 느리다는 것을 알게 되어, GPU 탑재 노트북으로도 검증했습니다.)

이번 기사에서는 GitHub Copilot에 로컬 LLM을 연결하기 위한 설정 절차와 실제로 구동한 결과를 공유합니다.

• Copilot Chat (Ask/Agent 모드)에 대해 로컬 LLM을 연결하여 검증했습니다.

• 인라인 보완 기능 (코드를 작성하면 옆에 표시되는 회색 후보)에 대해서는, Continue 확장 기능을 사용하면 로컬 LLM에 연결할 수 있는 것 같습니다. (이번에는 다루지 않습니다)

• 노트북(CPU 전용)에서 로컬 LLM을 구동했을 경우, 실용적인 속도는 나오지 않았습니다. "안녕하세요"라는 인사만으로 응답에 8분 31초가 걸립니다.

• GPU가 있는 것만으로 속도는 급변합니다. "안녕하세요"라는 인사에 대한 응답에 약 3초(CPU 대비 약 170배).

• 다만 이번에 시도한 어떤 모델도 Agent 모드의 동작은 불안정했습니다.

• 비용 절약을 위한 완전한 대체제로는 아직 멀었지만, "GitHub Copilot에 로컬 LLM을 연결하는 절차는 어떤 것인가"는 파악할 수 있었습니다.

• 1. 검증을 시도하게 된 계기
• 2. 시스템 구성
• 3. 검증한 로컬 LLM
• 4. 로컬 LLM 구동 절차 (Docker + Ollama)
• 5. GitHub Copilot로의 로컬 LLM 연결 절차
• 6. 검증 결과
• 7. 팀에서 사용한다면: 발전형 구성안
• 8. 앞으로 시도해 보실 분들에게: 모델 선택의 포인트

• 요약

GitHub Copilot은 2026년 6월부터 이용 요금 계산 방법이 바뀌었습니다. 기존에는 요청 횟수 기반의 추산이었으나, 현재는 LLM의 토큰 소비량에 따라 AI Credit이 계산됩니다. LLM이 에이전트로서 동작하여 주고받는 내용이 길어지면, 그만큼 Credit도 늘어납니다.

이전과 똑같이 사용하고 있을 뿐인데 청구 금액이 늘어나고 있습니다. X에서도 "실질적 가격 인상"이라는 목소리가 눈에 띕니다.

이러한 상황을 고려하여 "LLM 부분만 로컬 LLM으로 전환하면 AI Credit을 소비하지 않아도 되지 않을까?"라고 생각했습니다. 로컬 LLM이라면 추론 비용이 들지 않으므로 마음껏 사용할 수 있을 것입니다. 그래서 가지고 있는 노트북(CPU 전용)으로 시도해 보았습니다. (동작이 너무 느려 실용적이지 않다는 것을 금방 알게 되어, GPU 탑재 노트북으로도 검증했습니다)

Ollama 서버에서 로컬 LLM을 호스팅해 두고, Visual Studio Code 상의 GitHub Copilot에서 해당 로컬 LLM에 접속하여 Copilot Chat을 사용하는 구성입니다.

주요 기술 요소는 다음과 같습니다.

이번에는 2종류의 PC로 검증했습니다.

이번에 테스트한 모델은 phi4-mini와 llama3.1:8b 두 가지입니다.

phi4-mini 주의사항

Ollama로 호스팅한 phi4-mini를 GitHub Copilot에서 사용할 경우, 도구 실행이 정상적으로 작동하지 않는(모델이 Function Calling 응답을 할 때 형식이 깨지는) 오류 보고가 있습니다. 이번 검증에서도 도구 실행이 작동하지 않는 동작을 확인했습니다.

여기에서는 Docker와 Ollama를 사용하여 로컬 LLM을 구동하기까지의 절차를 설명합니다. 이번에는 Dockerfile, entrypoint.sh, docker-compose.yaml 세 개의 파일로 구성했습니다.

이 파일에서는 Ollama용 컨테이너 정의를 수행합니다. 베이스 이미지(Base Image)는 공식 ollama/ollama를 그대로 사용했습니다.

FROM ollama/ollama
COPY local-llm/entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
...

컨테이너 구동 시의 처리를 정의하는 스크립트입니다. 먼저 Ollama 서버를 백그라운드에서 실행하고, 서버가 응답할 수 있는 상태가 될 때까지 폴링(Polling)하며 대기합니다. 준비가 완료되면 환경 변수 MODEL_NAME으로 지정된 모델을 풀(Pull)합니다. 모델은 Docker 볼륨에 캐시되므로, 두 번째 실행부터는 기존 캐시가 사용되어 다운로드가 생략됩니다.

#!/bin/bash
set -e
# Ollama 서버를 백그라운드에서 실행
...

Ollama 컨테이너의 구동 설정을 정리한 파일입니다. 포트 호스트 공개(11434번), 다운로드된 모델의 캐시 경로가 되는 Docker 볼륨(ollama-data), 그리고 사용할 모델명과 컨텍스트 윈도우(Context Window) 크기의 환경 변수를 정의하고 있습니다. MODEL_NAME은 기본값으로 phi4-mini가 사용되지만, 구동 명령 시 덮어쓸 수 있습니다.

services:
  ollama:
    build:
      ...

GPU 버전의 docker-compose.yaml은 다음과 같습니다. CPU 버전과의 주요 차이점은 두 가지입니다. 첫 번째는 deploy 섹션으로, NVIDIA GPU를 모두 컨테이너에 할당하는 설정이 추가되었습니다. 두 번째는 컨텍스트 윈도우 크기로, VRAM에 여유가 있기 때문에 llama3.1:8b가 지원하는 최대치인 128K(131,072 토큰)로 설정했습니다.

services:
  ollama:
    # (포트·볼륨 설정은 CPU 버전과 동일)
    ...

구동 명령은 WSL 상에서 아래를 실행하기만 하면 됩니다. 처음에는 모델 다운로드(phi4-mini 기준 약 2.5GB)가 진행되므로 몇 분 정도 소요됩니다.

docker compose up --build

다른 모델을 테스트하고 싶다면 환경 변수로 지정할 수 있습니다.

MODEL_NAME=llama3.1:8b docker compose up --build

구동이 완료되면 다음 헬스 체크(Health Check)로 동작을 확인합니다.

curl http://localhost:11434

HTTP 200이 반환되면 Ollama 서버가 정상적으로 올라온 것입니다.

검증 시 어려움을 겪었던 점을 소개해 드립니다. Ollama의 기본 컨텍스트 윈도우 크기는 num_ctx=4096입니다.

하지만, 이 상태로는 GitHub Copilot에서 채팅을 보내더라도 로컬 LLM이 정상적으로 응답을 반환할 수 없습니다.

이유는 토큰 수에 있습니다. GitHub Copilot에서는 사용자가 "안녕하세요"라고 입력하더라도, 그 이면에서 MCP 설정, 도구 정의 (Tool Definition), 스킬 정의 등의 시스템 프롬프트 (System Prompt)를 LLM에 전달합니다. 이 시스템 프롬프트를 포함한 입력 프롬프트 (Input Prompt)의 양이 기본값인 4,096 토큰 상한을 가볍게 초과하는 경우가 있습니다. 실제로 검증한 환경에서는 입력 프롬프트가 8,000 토큰 규모가 되는 것을 확인했습니다.

입력 프롬프트가 컨텍스트 윈도우 (Context Window) 크기를 초과할 경우, Ollama가 입력을 중간에 잘라서(Truncating) LLM에 전달하기 때문에 (로그에 truncating input prompt limit=4096 prompt=8074라고 표시됨), LLM이 불완전한 입력을 처리하게 됩니다. 결과적으로 Copilot이 "분석 중" 상태로 멈춰 있거나, HTTP 500 에러가 발생하게 됩니다.

대처 방법은 컨텍스트 윈도우 크기를 크게 설정하는 것입니다. 이번 경우에는 OLLAMA_CONTEXT_LENGTH 환경 변수를 설정합니다.

environment:
- OLLAMA_CONTEXT_LENGTH=131072 # 노트북(GPU 탑재)은 VRAM에 여유가 있었으므로, 검증한 로컬 LLM의 최대 길이인 128k를 설정

VRAM에 여유가 있다면, 에이전트 (Agent) 모드의 상호작용까지 커버할 수 있도록 가능한 큰 값(128K 등)을 설정해 두는 것이 안심할 수 있습니다. 다만, VRAM에 여유가 없는 상태에서 이 값을 너무 크게 설정하면 처리 속도가 느려지거나 메모리 부족 (Out of Memory) 에러가 발생할 수 있으므로 주의가 필요합니다.

Ollama 서버에서 로컬 LLM을 실행한 후, VS Code의 모델 선택 메뉴에서 몇 단계만 거치면 연결할 수 있습니다. VS Code 1.113 + Copilot Chat 0.41.0 이후 버전이라면 Ollama를 네이티브로 지원하므로 쉽게 연결할 수 있습니다.

절차:

1. VS Code의 Copilot 채팅창을 엽니다

2. 모델 선택 메뉴에서 "기타 모델 (Other Models)"을 클릭합니다

3. 모델 목록에서 "모델 추가 (Add Model)"를 클릭합니다

4. 목록에서 "Ollama"를 클릭합니다

5. 입력창에 "Ollama"를 입력합니다

6. Ollama 서버 주소로 "http://localhost:11434"를 입력합니다

7. 모델 목록에 "Ollama"가 추가되었는지 확인합니다

8. 모델 선택 메뉴에서 사용하고 싶은 모델명을 선택합니다

Ollama 서버에서 실행 중인 모델(phi4-mini나 llama3.1:8b 등)이 목록에 표시됩니다.

9. 채팅을 전송하여 동작을 확인합니다

GitHub Copilot 채팅창에 메시지를 보내면 응답이 돌아옵니다.

응답이 돌아오기까지의 로컬 LLM 동작 상황은 Ollama 서버 측 로그를 통해 확인할 수 있습니다.

Ollama에서는 로컬 LLM의 실행 속도를 다음과 같은 지표로 확인할 수 있었습니다. 이후 표에서도 등장하므로 미리 보충 설명을 드립니다.

입력 프롬프트 평가 속도 (Input Prompt Evaluation Speed): LLM이 입력 토큰을 초당 몇 토큰 처리했는지(tok/s)를 나타냅니다. 예를 들어, 입력 토큰 수가 8,000이고 평가 속도가 20 tok/s라면, LLM이 입력 내용을 해석하는 데만 400초(약 6~7분)가 걸린다는 계산이 나옵니다.

출력 프롬프트 생성 속도 (Output Prompt Generation Speed): LLM이 답변을 초당 몇 토큰 생성할 수 있는지(tok/s)를 나타냅니다. 이 값이 낮으면 화면에 답변 글자가 나타나는 속도가 느려집니다.

GPU로 전환함으로써 응답 시간이 8분 31초에서 약 3초로 단축되었습니다 (CPU 대비 약 170배). 특히 입력 프롬프트 (8,000 토큰)의 평가 속도에서 17.75 tok/s에서 8,591 tok/s로 약 480배 빨라졌습니다.

다만, 일본어로 질문해도 영어로 답변하는 것으로 보이며, 이는 Copilot을 경유하는 시스템 프롬프트가 영어라는 점과 phi4-mini의 일본어 대응 능력이 영향을 미친 것으로 생각됩니다.

이 결과를 바탕으로, 노트북 (CPU 전용)에서의 Agent 모드 검증은 단념했습니다. Ask 모드에서 이 정도 시간이 걸린다면, 도구 호출 (Tool Calling)을 동반하는 Agent 모드는 훨씬 더 느려질 것이라고 판단했기 때문입니다.

Agent 모드에서는 "Python으로 Hello World 프로그램을 작성해 주세요"라고 요청했지만, 파일 생성에 실패했습니다. 도구 호출을 위한 JSON 프롬프트가 그대로 채팅 화면에 텍스트로 표시되어 버렸습니다. 이는 issue #9437에서 보고된 Ollama 경유 시의 Function Calling 불안정 문제와 동일한 현상이 발생한 것으로 생각됩니다.

이 검증 결과를 바탕으로, Function Calling 관련 결함 보고가 없고 소규모 모델 중에서는 도구 호출 정확도가 높다고 평가받는 llama3.1:8b를 사용하여 Agent 모드를 검증했습니다.

• Agent 모드 ("Python으로 HelloWorld 프로그램을 작성해 주세요"라고 요청: 1회차)에서의 Copilot 응답 내용

<VSCode.Cell id="1" language="markdown">
# Python 환경 설정
Python 버전과 라이브러리 확인
...

• Agent 모드 ("prime_numbers와는 별개로, 소수에 1을 더하는 함수도 구현해 주세요"라고 요청)에서의 Copilot 응답 내용 (일부 생략)

$$
def prime_numbers(n):
# Initialize an empty list to store prime numbers
...

「Python으로 HelloWorld 프로그램을 작성해 주세요」라고 요청했을 때, 첫 번째는 도구 호출 (Tool Calling)에 실패하여 Jupyter Notebook의 셀 형식 텍스트가 반환되었습니다. 두 번째는 파일 생성 자체는 성공했지만, 답변에 "Sorry, I can't assist with that."라는 거절 메시지가 섞여 나왔습니다.

그 외에 파일 생성 및 편집을 요청했을 경우에는 처리 자체는 성공했으나, 코드 전체가 $$...$$ 형식으로 채팅 화면에 표시되는 등 답변 내용에 불일치가 발생했습니다. 파일 내용은 올바르게 만들어지는데, 채팅 답변이 이상한 상태입니다.

결과적으로 llama3.1:8b는 phi4-mini에 비해 도구 호출이 작동하는 경우가 있었으나, 응답이 불안정하여 실용성에는 우려가 남습니다.

이번 구성의 한계는 두 가지가 있습니다. CPU로는 실용적인 속도가 나오지 않는다는 점, 그리고 개인 PC에 물리적으로 의존하기 때문에 여러 명이 공유하기 어렵다는 점입니다.

팀이나 프로젝트 전체에서 로컬 LLM을 사용하고 싶다면, 로컬 LLM의 호스팅 (Hosting) 부분을 클라우드로 옮기는 것이 좋다고 생각됩니다.

예를 들어 다음과 같은 구성입니다.

클라우드 상에서 로컬 LLM을 호스팅할 경우, 크게 두 가지 선택지가 있습니다.

CaaS (Container as a Service)로 운영할 경우:

이번에 작성한 Docker 컨테이너를 그대로 GPU가 장착된 컨테이너 실행 환경 (예: AWS ECS + GPU 인스턴스)에서 호스팅하는 방법입니다. 절차를 재현하기 쉽다는 장점이 있는 반면, GPU 환경의 유지 관리 비용이 발생합니다.

PaaS (Platform as a Service)로 운영할 경우:

Amazon Bedrock과 같은 매니지드 서비스 (Managed Service) 상에서 오픈 웨이트 모델 (Open-weight Model)을 사용하는 방법입니다. 직접 GPU 인스턴스를 관리할 필요가 없는 만큼 운영 부하를 낮출 수 있는 가능성이 있습니다. 다만, 비용이 어느 정도 절감될지는 사용량이나 선택하는 모델에 따라 달라지므로, 구체적인 산출은 환경에 맞춰 별도로 수행해야 합니다.

이번 검증을 통해, "Ollama에서 동작함", "Function Calling 지원"이라고 적혀 있는 것만으로는 Copilot과의 조합에서 충분히 잘 작동할지 판단할 수 없다는 것을 알게 되었습니다. 모델 단독의 벤치마크 (Benchmark) 결과는 어디까지나 참고치일 뿐이며, 실제로 Copilot의 코딩 어시스턴트 (Coding Assistant)로 작동시켰을 때의 품질을 평가해 두어야 합니다.

모델을 선택할 때는 다음 4가지를 확인해 두는 것을 권장합니다.

1. 도구 실행의 안정성

에이전트 (Agent) 모드는 파일 생성 및 편집 등을 도구 호출을 통해 모델이 실행하게 합니다. 모델이 올바른 형식으로 응답을 반환하지 못하면 아무것도 작동하지 않습니다. 이번의 phi4-mini는 바로 이 부분에서 막혔습니다. Ollama의 모델 페이지에서 tools 태그가 붙어 있는지 확인하면서, 반드시 연결된 상태에서 실제로 테스트해 보시기 바랍니다.

2. 다국어 대응 (특히 일본어/한국어)

Copilot을 통한 시스템 프롬프트 (System Prompt)는 영어이기 때문에, 다국어 대응이 약한 모델은 한국어로 질문해도 영어로 답변이 돌아옵니다 (이번의 llama3.1:8b가 이 경우였습니다). 벤치마크에서는 영어로 평가되는 경우가 많으므로, 한국어로 실제로 테스트해 보는 것이 확실합니다.

3. 코딩 보조로서의 대화 품질

코드의 정확성뿐만 아니라 답변 내용 전체의 품질이 실용성을 좌우합니다. 이번 llama3.1:8b에서는 파일 생성 자체는 성공했음에도 "Sorry, I can't assist with that."가 답변에 섞여 나오는 상태가 발생했습니다. 이러한 종류의 문제는 벤치마크에 나타나지 않으므로, 에이전트 모드에서 실제로 코드 생성을 요청하여 확인하십시오.

4. 응답 속도

한 번의 응답이 느리면 작업의 템포가 크게 무너집니다. CPU만 있는 환경에서는 이번 검증 결과와 같이 실용적이지 않습니다. 노트북 (GPU 탑재)을 사용하는 경우에도 모델의 크기가 VRAM에 들어가는지 사전에 확인해 두는 것을 권장합니다.

• 노트북 (CPU 전용)으로는 불가능했습니다. "안녕하세요"라는 인사 한마디에 8분 31초가 걸린다는 것은, 아주 간단한 작업이라도 실사용이 불가능한 수준입니다. -
• GPU가 있다면 속도 면에서 상당히 빨라집니다. 동일 조건에서 약 3초가 소요되며, CPU 대비 약 170배 빠른 속도는 체감상으로도 충분한 차이입니다. -
• GitHub Copilot 네이티브 인라인 보완 (Inline Completion)은 로컬 LLM을 지원하지 않습니다. 대안으로 Continue 확장 기능 + Ollama를 사용하는 방법이 있는 것으로 보입니다. -
• Copilot Chat (Ask 모드)는 사용할 수 있습니다. GPU 환경이라면 빠르게 동작합니다. 다만, 일본어로 질문해도 영어로 답변이 돌아오는 경우가 있습니다. -
• Copilot Chat (Agent 모드)는 불안정합니다. phi4-mini는 도구 호출 (Tool Calling)에 실패하며, llama3.1:8b는 도구 호출에 성공할 가능성은 높지만 응답이 일관되지 않을 수 있습니다. 다른 로컬 LLM을 검토하는 것이 더 나을 수도 있습니다. -
• 컨텍스트 윈도우 크기 (Context Window Size) 설정은 필수입니다. GitHub Copilot에서는 사용자가 입력한 문장 외에도 MCP나 도구 정의를 포함한 시스템 프롬프트 (System Prompt)도 함께 입력하기 때문에, OLLAMA_CONTEXT_LENGTH가 큰 값이어야 합니다. 그렇지 않으면 Ollama가 토큰을 잘라버려(Truncation) LLM이 입력을 정상적으로 해석할 수 없게 됩니다.

AI Credit 비용 절감을 위한 완전한 대체재로 쓰기에는 아직 어려운 상황이지만, "GitHub Copilot에 로컬 LLM을 연결하는 메커니즘은 어떤 것인가", "어느 지점에서 작동이 멈추는가"는 파악할 수 있었습니다. 팀 단위로 본격적으로 사용하기 위해서는 클라우드 GPU 인스턴스나 매니지드 서비스 (Managed Service)를 검토하는 것이 다음 단계라고 생각합니다.