도커로 ollama MCP 연결하기 for 안티그래비티와 VScode

table of contents

배경 설명
전제 조건
1단계. Ollama 환경변수 설정 (OLLAMA_HOST)
2단계. Docker/WSL 내부 네트워크 대역 확인
- 왜 필요한가
- 실행 방법
3단계. Windows 방화벽 인바운드 규칙 생성 (접근 허용 대역 한정)
4단계. Antigravity의 mcp_config.json 작성
- 왜 필요한가
- 실행 방법
5단계. 전체 동작 검증
6단계. (유지보수) Docker/WSL 서브넷 변경 시 대응
7단계. (선택) VSCode에도 동일하게 적용하기
요약 체크리스트

배경 설명

1년 이상 Cursor랑 Gemini만 쓰면서 코딩도 시켜보고 문서 정리도 시켰는데, 시간이 지날수록 두 공급사의 기본 모델의 지성에 한계를 느꼈다. 거기에 더해 저번에 디지털 트윈 프로젝트 할 때 코덱스가 일하는 거 옆에서 보고, 나도 cursor 종량제 추가해서 써보니까 역시 오픈AI/앤트로픽 모델은 뭐가 다르긴 다르다 싶은 수월함이 있었다. 똑같이 말해도 훨씬 일을 내가 원하는대로 잘 해주더라. 그렇다고 새로 구독을 하자니 이미 cursor도 구독 종료하고 gemini 할인받아 쓰는 마당에 3만원 지출을 늘리기엔 지금 수입이 없어서 재정이 부담스러운 상황.

그렇게 다다른 결론: 이참에 로컬 LLM을 들여보자. 설치만 하면 인터넷 연결도 비용 추가도 필요 없는 모델들을 데려와서 유료 모델의 비용 절감을 해볼 생각이었다.

ollama 설치 후 몇 가지 모델 다운로드까지는 쉬웠는데, 문제는 이 AI들은 사실상 채팅만 가능할 뿐 gemini처럼 에이전틱하게 쓸 수가 없었다는 점. 매번 파일 하나하나 지정해서 이걸 읽어라 저걸 써라 지시하는 건 너무 비효율적이라서 에이전트로 쓸 수 있는 방법을 찾아보니 나온 게 MCP 서버였다. 로컬 LLM을 MCP 서버로 연결해두면 vscode나 안티그래비티에 있는 유료 모델들이 로컬 LLM을 사용하기 때문에 토큰을 많이 먹는 작업은 로컬에 시키고 좀 더 정제된 컨텍스트를 유료 모델들이 쓸 수 있게 한다고 이해했었다.

ollama를 안티그래비티 or VScode에 MCP 서버로 추가해서 원래 각 IDE에 있던 모델들이 사용하게 하는 것까지는 이해가 됐는데, 문제는 윈도우 환경에서 그 둘을 어떻게 연결해주느냐였다. 서버라는 말은 말 그대로 server를 만들어서 IDE와 ollama 사이의 연결을 제공해야 하는 거잖아요? 근데 그걸 실행하려면 항상 터미널 한 편에서 ‘서버 실행 중…‘이 차지해야 하는 거니까 난 그게 미관상 마음에 안드는 겁니다. 그래서 gemini와 클로드랑 터미널 점유 안 하고, 로컬에 뭔가 추가 설치 안 하고, 가능한 한 도커만 써서 MCP 서버를 추가하고 사용할 방법을 좀 조사했다. gemini한테만 물어봐서는 답변이 좀 부족했는데, 그걸 클로드한테 가져가서 보충하게 시키니까 딱 좋더라. 이번에 직접 구축해보고 잘 작동해서 가이드 남기려고 한다.

요약하자면 목적은 ollama MCP 서버를 안티그래비티와 VScode에 추가하는 것, 목표는 ollama.exe와 도커만 설치해서(no npm) 연결을 성사시키는 것. 아래 작성된 가이드는 내가 직접 서버 만들면서 클로드랑 고치고 완성한 것이다.

별개로, 도커와의 연결을 위해서 윈도우가 포트 하나를 열어줄 필요가 있었는데, 그거 방화벽 설정이 낯설어서 좀 미루다가 했다. 결국엔 잘 되긴 했다.

주의: 모든 내용은 기본적으로 Gemini와 클로드가 작성했다(내가 직접 하면서 일부 첨언한 부분이 있긴 한데, 비중이 매우 적다). 그래서 별도로 남겨둔 참고문헌이 없다. 실행 검증은 했지만 개념적인 부분에서 실제 정보와 차이가 있는 부분이 있을 수 있으니 주의. 만약 발견한다면 꼭 내게 알려주시면 감사드리겠습니다..

전제 조건

Ollama가 Windows(Win11 Pro 기준)에 네이티브로 설치되어 있음 (ollama.exe)
Docker Desktop이 설치 및 실행 중 (WSL2 백엔드)
npm/npx 등 로컬 개발 도구는 설치하지 않고, MCP 서버는 Docker 이미지(wuodan/mcp-ollama)로 실행
목표: 인터넷에서는 물론, 같은 사내망(LAN)의 다른 PC에서도 접근 불가능하게 하면서, Docker 컨테이너에서만 Ollama에 접근 가능하도록 구성

MCP 서버 추가 완료 시 실행 흐름은 다음과 같다.

[Antigravity] → [MCP 서버 컨테이너(Docker)] → [host.docker.internal:11434] → [Windows에 설치된 Ollama]

1단계. Ollama 환경변수 설정 (OLLAMA_HOST)

왜 필요한가

Ollama는 기본적으로 127.0.0.1(자기 자신만 접근 가능한 루프백 주소, 윈도우 기준)에만 바인딩된다. 그런데 Docker 컨테이너는 호스트 PC와 별도의 가상 네트워크에 속해 있어서 호스트의 127.0.0.1은 컨테이너 입장에서 “컨테이너 자기 자신의 루프백”으로 해석된다. 그러니까 컨테이너에서는 호스트의 127.0.0.1에 절대 도달할 수 없는 것이다.

이 문제를 해결하려면 Ollama가 모든 네트워크 인터페이스(0.0.0.0)에서 리스닝하도록 바꿔야 Docker가 제공하는 host.docker.internal이라는 특수 주소를 통해 컨테이너에서 호스트의 Ollama에 접근할 수 있게 된다.

참고: 이렇게 하면 원리상 LAN의 다른 기기도 접근을 시도할 수는 있는 상태가 된다. 이 위험은 3단계(방화벽)에서 차단한다. 지금 단계는 포트를 열어주는 단계이고, 3단계가 불필요한 접근을 차단하는 단계라고 보면 됨.

참고: OLLAMA_HOST에 포트를 생략하고 0.0.0.0만 적어도 Ollama가 내부적으로 기본 포트(11434)를 자동 적용하기 때문에 동작 자체는 동일한데, 이 가이드의 다른 단계(방화벽, MCP config)에서 11434 포트를 명시적으로 다루고 있으므로, 값도 포트까지 함께 적어 일관성을 유지하고 오타와 설정 누락을 예방함.

실행 방법 (GUI)

시작 메뉴에서 “환경 변수 편집” 검색 후 실행
“시스템 변수” 섹션에서 새로 만들기 클릭
- 변수 이름: OLLAMA_HOST
- 변수 값: 0.0.0.0:11434
확인 눌러 창 닫기
Ollama 완전히 재시작
- 작업 표시줄 트레이에서 Ollama 아이콘 우클릭 → Quit(종료)
- 다시 Ollama 실행 (또는 Windows 서비스로 등록되어 있다면 서비스 재시작)
- 환경변수는 재시작해야 프로세스에 반영되니까 꼭 ollama 껐다 켜기. 안하면 다음 과정 진행이 안 됨.

검증

관리자 권한 PowerShell에서:

  
netstat -ano | findstr 11434

명령어 뜻: 현재 PC에서 11434 포트를 누가 어떤 주소로 리스닝하고 있는지 확인
- 결과가 0.0.0.0:11434로 나오면 정상 (모든 인터페이스에서 리스닝 중)
  - 예: TCP 0.0.0.0:11434 0.0.0.0:0 LISTENING 6340
- 결과가 127.0.0.1:11434로만 나오면 환경변수가 아직 반영 안 된 것 → Ollama 재시작을 다시 확인

2단계. Docker/WSL 내부 네트워크 대역 확인

왜 필요한가

3단계에서 방화벽 규칙을 만들 때, “이 IP 대역에서 오는 접속만 허용한다”는 조건을 걸어야 한다. Docker Desktop은 WSL2 안에 가상 네트워크 어댑터를 만들어 컨테이너 트래픽을 처리하는데, 이 어댑터가 사용하는 IP 대역을 미리 확인해야 정확한 범위로 방화벽을 좁힐 수 있다.

실행 방법

일반 PowerShell(관리자 권한 아니어도 됨)에서:

ipconfig

명령어 뜻: PC에 연결된 모든 네트워크 어댑터와 그 IP 정보를 나열

출력 결과 중 vEthernet (WSL) 또는 vEthernet (WSL (Hyper-V firewall))라는 이름의 항목을 찾는다. 결과 예시:

이더넷 어댑터 vEthernet (WSL):
   IPv4 주소 . . . . . . . . : 172.18.144.1
   서브넷 마스크 . . . . . . : 255.255.240.0

여기서 172.18.144.1처럼 172로 시작하는 대역이 Docker/WSL이 사용하는 내부 네트워크다. 이 값이 실행 환경마다 다를 수 있으므로 반드시 MCP를 추가할 PC에서 직접 확인해야 하고, 윈도우는 도커 데스크탑이 실행되어 있어야 저게 나온다.

Docker/WSL2가 쓰는 사설 대역은 일반적으로 172.16.0.0/12(172.16.0.0 ~ 172.31.255.255) 범위 안에 들어간다. 정확한 서브넷을 확인했다면 그 값을, 확인이 번거롭다면 이 넉넉한 범위(172.16.0.0/12)를 3단계에서 사용해도 된다.

넉넉하게 정하는 게 혹시나 나중에 서브넷 주소가 바뀌었을 때에도 문제 없이 동작하게 되긴 하겠지만, 우연히 같은 LAN 안에 그 서브넷 범위에 들어가는 다른 기기가 있다면 거기서 접근이 가능할 수도 있게 된다. 그래서 나도 처음엔 넉넉하게 설정했다가 모바일에서 접근이 되는 걸 보고 정확한 서브넷으로 수정했다. 각자 사용하는 상황에 따라 적당한 쪽으로 선택하는 것을 추천.

도커의 서브넷 주소는 도커를 업데이트하거나 WSL을 재시작하는 등의 경우에 바뀔 수 있다고 하니까 정확한 서브넷으로 설정했을 경우 나중에 뭔가 갑자기 안되면 주소 확인해보기.

3단계. Windows 방화벽 인바운드 규칙 생성 (접근 허용 대역 한정)

왜 필요한가

1단계에서 Ollama를 0.0.0.0 주소로 열어놓았기 때문에 이 상태로 두면 같은 사무실 Wi-Fi/네트워크에 연결된 다른 PC도 이론적으로 http://<내PC의 LAN IP>:11434로 접속을 시도할 수 있다. Windows 방화벽 규칙으로 11434 포트는 Docker/WSL 대역에서 오는 접속만 허용하고, 그 외에는 전부 차단하도록 명시적으로 제한해야 한다.

실행 방법

관리자 권한 PowerShell에서:

  
New-NetFirewallRule -DisplayName "Ollama 11434" `
  -Direction Inbound -Protocol TCP -LocalPort 11434 `
  -Action Allow -RemoteAddress 172.16.0.0/12 `
  -Profile Private,Domain

각 옵션의 의미:

키워드	의미
`New-NetFirewallRule`	새 방화벽 규칙을 생성하는 PowerShell 명령 (Windows 방화벽을 GUI 없이 코드로 조작)
`-DisplayName "Ollama 11434"`	이 규칙에 붙이는 이름표. 나중에 조회/삭제할 때 이 이름으로 찾아야 하고, 정확히 검색해야 함(=기억할 수 있게 써야 함).
`-Direction Inbound`	들어오는 트래픽에 적용. (내 PC → 밖으로 나가는 건 Outbound, 여긴 해당 없음)
`-Protocol TCP`	TCP 프로토콜에만 적용 (Ollama API가 TCP 기반이므로 해당)
`-LocalPort 11434`	내 PC의 11434번 포트로 들어오는 트래픽만 대상 (Ollama가 쓰는 포트)
`-Action Allow`	조건에 맞으면 “허용”. Windows 방화벽은 기본적으로 명시적으로 허용 안 된 인바운드는 막기 때문에 이 규칙 밖의 트래픽은 자동으로 차단됨. (아래 RemoteAddress 조건과 결합되어, 조건 밖의 트래픽은 Windows 기본 정책인 “차단”이 자동 적용됨.)
`-RemoteAddress 172.16.0.0/12`	상대방(발신지) IP가 이 대역이어야 허용. 현재 작성된 값은 “넉넉한 범위”로 작성되어 있음. 2단계에서 확인한 Docker/WSL 대역으로, 이 옵션이 빠지면 모든 곳에서의 접속이 허용되니까 반드시 써야 함.
`-Profile Private,Domain`	이 규칙이 “개인” 네트워크와 “도메인(회사 관리)” 네트워크 프로필에서만 작동하도록 제한함. `Public`을 뺐기 때문에 카페·공항 같은 공용 Wi-Fi에서는 이 규칙 자체가 꺼짐 (안전장치임)

검증

  
Get-NetFirewallRule -DisplayName "Ollama 11434" | Get-NetFirewallAddressFilter

명령어 뜻: 방금 만든 규칙의 세부 주소 필터 설정을 조회한다. RemoteAddress 항목이 172.16.0.0/12로 표시되면 정상 등록된 것이다.

출력 예시:

LocalAddress  : Any
RemoteAddress : 172.16.0.0/255.240.0.0

(선택) 규칙 삭제/되돌리기

설정을 취소하고 싶다면:

  
Remove-NetFirewallRule -DisplayName "Ollama 11434"

명령어 뜻: 이름으로 지정한 방화벽 규칙을 삭제한다. 삭제 후에는 11434 포트에 대한 Windows 기본 인바운드 정책(대부분 차단)이 다시 적용된다.

4단계. Antigravity의 mcp_config.json 작성

왜 필요한가

Antigravity가 MCP 서버를 어떻게 실행할지 알려주는 설정 파일이다. 여기서는 docker run 명령을 실행하도록 지정해 Antigravity가 대화 중 필요할 때마다 wuodan/mcp-ollama 컨테이너를 띄우고 표준입출력(stdio)으로 통신하게 한다.

실행 방법

Antigravity 우측 상단 ... 메뉴 클릭 → MCP Servers → Manage MCP Servers → View raw config
아래 경로의 파일이 열린다(안티그래비티 버전에 따라 일부 차이가 있을 수 있음).
1 %USERPROFILE%\.gemini\config\mcp_config.json

아래 JSON을 mcpServers 항목 안에 추가한다. (기존에 다른 MCP 서버가 등록되어 있다면 그 옆에 콤마로 구분해서 추가하면 된다고 함. 나는 빈 파일이었어서 그대로 넣었다.)

  
{
   "mcpServers": {
      "ollama": {
         "command": "docker",
         "args": [
            "run",
            "-i",
            "--rm",
            "-e", "OLLAMA_HOST=http://host.docker.internal:11434",
            "wuodan/mcp-ollama:latest"
         ]
      }
   }
}

각 필드의 의미:

"ollama": Antigravity 내에서 이 MCP 서버를 부르는 이름. 아무 이름이나 가능하지만 알아보기 쉽게 지정하는 게 좋다.
"command": "docker": Antigravity가 이 MCP 서버를 실행할 때 docker라는 실행 파일을 호출하라는 뜻. (npx 대신 docker를 직접 command로 지정했기 때문에 로컬에 npm/Node.js가 없어도 됨)
"args": docker 뒤에 붙는 인자들. 실제로는 다음 명령이 실행되는 것과 같음.
1 docker run -i --rm -e OLLAMA_HOST=http://host.docker.internal:11434 wuodan/mcp-ollama:latest
- run: 새 컨테이너를 실행하라는 Docker 명령
- -i: 표준 입력을 컨테이너에 연결(interactive). MCP는 stdio로 JSON-RPC 메시지를 주고받는 프로토콜이라 이 옵션이 필수다. 없으면 Antigravity와 컨테이너 간 통신이 되지 않는다.
- --rm: 컨테이너가 종료되면 자동으로 삭제한다. Antigravity가 대화할 때마다 컨테이너를 새로 띄우는 구조이므로, 매번 자동 정리해서 불필요한 컨테이너가 쌓이지 않도록 한다.
  - 부연설명을 좀 더 하자면, 매번 ollama 모델을 호출할 때마다 컨테이너 올려 컨테이너 내려 하는 건 아니다. 안티그래비티/VScode의 MCP 서버가 켜져 있는 동안에는 내내 사용하고, MCP 서버가 종료될 때 같이 정리된다. 내가 딱 이렇게 오해했어서 덧붙임…
  - 삭제를 안하면 불필요한 컨테이너가 쌓인다고 하는 이유는 컨테이너에 이름 지정을 안 했기 때문(매번 랜덤 이름으로 컨테이너가 생성됨). 이름을 지정하면 물론 재사용에는 더 좋겠지만, 그러면 MCP 설정 파일에도 컨테이너 존재 여부 확인과 재사용 관련 코드를 추가해야 한다. 굳이 컨테이너에 뭔가 더 남겨야만 하는 데이터도 없는데 그렇게까지 쓰기엔 복잡하니까 일회용 컨테이너를 쓰는 것.
- -e OLLAMA_HOST=http://host.docker.internal:11434: 컨테이너 내부에 환경변수를 설정한다. host.docker.internal은 Docker Desktop이 제공하는 특수 DNS 이름으로, “이 컨테이너를 실행하고 있는 호스트 PC”를 가리긴다. 즉 컨테이너 안의 MCP 서버가 “Ollama는 호스트 PC의 11434번 포트에 있다”는 것을 알게 된다.
- wuodan/mcp-ollama:latest: 실행할 Docker 이미지 이름과 태그. Docker Hub에서 자동으로 받아온다(처음 실행 시 다운로드, 이후엔 로컬 캐시 사용).

파일 저장 (Ctrl+S)
Antigravity의 MCP 서버 관리 화면으로 돌아가면 ollama 항목이 활성화 상태로 표시되고, 사용 가능한 도구(tool) 목록이 함께 보여야 한다(새로고침이 필요할 수 있음).

5단계. 전체 동작 검증

5-1. 컨테이너 단독 실행 테스트

Antigravity를 거치지 않고 컨테이너가 Ollama에 직접 접근되는지 먼저 확인한다.

  
docker run --rm curlimages/curl curl http://host.docker.internal:11434/api/tags

명령어 뜻: curlimages/curl이라는 가벼운 curl 전용 이미지를 임시로 띄워, 컨테이너 내부에서 호스트의 Ollama API(/api/tags, 설치된 모델 목록을 반환하는 엔드포인트)를 호출해본다.
- 설치된 모델 목록이 JSON으로 출력되면 성공
- Connection refused나 timeout이 뜨면 1단계(환경변수) 또는 3단계(방화벽)를 다시 점검하기 (나는 바로 성공해서 점검할 일이 없었음)

5-2. LAN 격리 확인 (보안 검증)

같은 네트워크의 다른 기기(스마트폰 브라우저 등)에서 내 PC의 LAN IP로 접속을 시도해본다. 내 PC의 LAN IP는 아래로 확인:

  
ipconfig | findstr IPv4

명령어 뜻: 실제 Wi-Fi/이더넷 어댑터에 할당된 IP를 찾는다. (앞서 확인한 vEthernet(WSL)이 아니라 실제 네트워크 어댑터 쪽 IP를 봐야 한다.)

다른 기기 브라우저에서 http://<내 IP>:11434/api/tags 접속을 시도했을 때 연결이 거부되거나 응답이 없어야 정상. 응답이 온다면 방화벽 규칙이 제대로 적용되지 않은 것이니 3단계를 재점검하거나, 허용 IP 범위를 줄일 것.

5-3. Antigravity에서 실제 사용

Antigravity 대화창에서 “로컬 Ollama 모델 목록 보여줘” 같은 요청을 해서, MCP 도구가 정상적으로 호출되는지 확인.

6단계. (유지보수) Docker/WSL 서브넷 변경 시 대응

왜 필요한가

2단계에서 확인한 vEthernet (WSL) 대역은 영구적으로 고정된 값이 아니다. 아래와 같은 상황에서 이 대역이 바뀔 수 있다.

Docker Desktop을 업데이트하거나 재설치한 경우
wsl --shutdown 실행 후 WSL 네트워크가 재생성된 경우
Windows 네트워크 어댑터 구성이 크게 바뀐 경우 (VPN 연결/해제 등)

3단계에서 방화벽 규칙에 정확한 서브넷(예: 172.18.144.0/20)을 등록해두었다면, 위 상황 이후 이 대역이 바뀌는 순간 방화벽이 새 컨테이너 IP를 막아버려 “어제까지 되던 Ollama 연결이 갑자기 안 되는” 문제가 발생한다. 이 경우 아래 절차로 방화벽 규칙을 갱신해야 한다.

참고: 3단계에서 넉넉한 범위(172.16.0.0/12)를 사용했다면 대역이 이 범위 안에서 바뀌는 한 별도 조치가 필요 없다. 다만 이 범위는 같은 와이파이의 다른 기기(예: 공유기가 172.x.x.x 대역을 쓰는 경우)도 함께 통과시킬 수 있으므로, 접속 시도한 기기의 IP가 이 범위와 우연히 겹치지 않는지 별도로 확인해 두어야 한다.

6-1. 서브넷 변경 여부 확인

일반 PowerShell에서:

ipconfig

명령어 뜻: vEthernet (WSL) 항목의 IPv4 주소와 서브넷 마스크를 확인한다. 이 값이 2단계에서 처음 기록해둔 값과 다르다면 대역이 변경된 것.

6-2. 방화벽 규칙의 허용 대역 갱신

관리자 권한 PowerShell에서, 기존 규칙 이름과 새 서브넷 값을 이용해 RemoteAddress만 갱신한다.

  
Set-NetFirewallRule -DisplayName "Ollama 11434" -RemoteAddress <새로운 대역>/<CIDR>

예: 새 대역이 172.20.32.1, 서브넷 마스크 255.255.240.0(/20)으로 확인된 경우:

  
Set-NetFirewallRule -DisplayName "Ollama 11434" -RemoteAddress 172.20.32.0/20

명령어 뜻:
- Set-NetFirewallRule: 기존에 만들어둔 규칙을 삭제하지 않고, 지정한 속성값만 수정하는 명령. 규칙 이름(-DisplayName)으로 대상을 찾아 -RemoteAddress만 새 값으로 교체하고, 포트/프로토콜/프로필 등 나머지 설정은 그대로 유지한다.
- 규칙을 지웠다가 New-NetFirewallRule로 다시 만드는 것과 결과는 동일하지만, 한 줄로 끝나니까 더 간단하다.

6-3. 재검증

  
Get-NetFirewallRule -DisplayName "Ollama 11434" | Get-NetFirewallAddressFilter

RemoteAddress가 새 값으로 반영되었는지 확인한 뒤, 5-1단계(컨테이너 curl 테스트)와 5-2단계(LAN 격리 확인)를 다시 수행해 정상 동작을 재확인한다.

서브넷 값 변경 이력 예시

이런 건 제때 기록해야 나중에 문제가 생겨도 해결이 수월하다.

확인 날짜	vEthernet(WSL) 주소	서브넷 마스크	CIDR	비고
2026-08-17	172.18.144.1	255.255.240.0	/20	최초 설정

7단계. (선택) VSCode에도 동일하게 적용하기

왜 필요한가

1~3단계(Ollama 환경변수, 방화벽 규칙)는 Antigravity와 무관한 OS/Docker 레벨의 설정이므로 그대로 재사용된다. 다만 MCP 설정 파일 자체는 Antigravity와 VSCode가 서로 다른 형식과 경로를 사용하니까 4단계에서 만든 mcp_config.json을 그대로 가져다 쓸 수 없고 VSCode용으로 별도 작성해야 한다.

	Antigravity	VSCode
루트 키 이름	`mcpServers`	`servers`
설정 파일 경로	`~/.gemini/config/mcp_config.json`	사용자 전역 설정 (아래 참고)
적용 범위	사용자 전역	워크스페이스별 또는 사용자 전역 선택 가능

실행 방법 - 사용자(전역) 설정으로 등록

프로젝트마다 매번 설정을 반복하지 않고, PC의 모든 프로젝트에서 공통으로 쓰려면 워크스페이스 설정(.vscode/mcp.json)이 아니라 사용자 설정에 등록한다.

VSCode에서 커맨드 팔레트 열기: Ctrl+Shift+P
MCP: Open User Configuration 명령 입력 후 실행
사용자 프로필의 mcp.json 파일이 열린다. (특정 프로젝트 폴더가 아니라 VSCode 사용자 프로필에 저장되는 파일이라, 어떤 프로젝트를 열어도 동일하게 적용됨. 실제 경로를 봐도 프로젝트 폴더와 별개인 것을 확인할 수 있을 것.)

아래 JSON을 붙여넣는다. (당연히 앞서 설정한 게 있다면 적절히 이어붙여야 할 것)

  
{
   "servers": {
      "ollama": {
         "command": "docker",
         "args": [
            "run",
            "-i",
            "--rm",
            "-e", "OLLAMA_HOST=http://host.docker.internal:11434",
            "wuodan/mcp-ollama:latest"
         ]
      }
   }
}

Antigravity 설정과의 차이점: 4단계에서 작성한 것과 내용은 완전히 동일, 루트 키가 "mcpServers"에서 "servers"로 바뀐 것이 유일한 차이. command, args 등 서버 실행 방식(Docker 컨테이너를 stdio로 띄우는 방식)은 MCP 표준 프로토콜이라 동일하게 유지됨.

파일 저장

검증

VSCode에서 아무 프로젝트나 열기
Copilot Chat 패널에서 모드를 Agent로 전환 (MCP 도구는 Ask 모드에서는 동작하지 않고 Agent 모드에서만 인식된다)
커맨드 팔레트 → MCP: List Servers 실행 → ollama 서버가 목록에 뜨고 정상 상태로 표시되는지 확인
Copilot Chat에서 “로컬 Ollama 모델 목록 보여줘” 같은 요청을 해서 MCP 도구가 정상 호출되는지 확인 (5-3단계와 동일한 방식)

참고: 프로젝트별로 다르게 설정하고 싶을 때 주의사항

특정 프로젝트에서만 다른 MCP 서버 구성을 쓰고 싶거나, 팀원과 설정을 공유하고 싶다면 사용자 설정 대신 해당 프로젝트 루트에 .vscode/mcp.json 파일을 만들어 같은 형식으로 작성하면 된다. 이 경우 그 프로젝트를 클론받은 팀원도 동일한 MCP 서버를 갖게 되므로, API 키처럼 민감한 값이 들어가는 서버라면 커밋 전에 .gitignore 처리나 ${input:...} 변수 사용을 검토해야 한다. (Ollama 서버는 민감 정보가 없으므로 이번 경우는 해당 없음)

참고: VSCode에 로그인해 Settings Sync를 켜둔 경우, 위 사용자 설정은 로그인한 다른 PC로도 동기화된다. 다만 이 설정은 host.docker.internal을 통해 “그 PC에 설치된 Ollama”를 가리키는 구조이므로, 동기화된 다른 PC에 Docker/Ollama가 없다면 그 PC에서는 단순히 연결이 안 될 뿐 별다른 부작용은 없다.

대안: 프로젝트 폴더별로 개별 설정하기

사용자(전역) 설정 대신, 특정 프로젝트에서만 MCP 서버를 쓰고 싶거나 팀원과 설정을 공유하고 싶다면 워크스페이스 설정을 사용한다. 이 경우 프로젝트 폴더마다 별도로 반복 작업이 필요하다.

전역 설정과의 차이:

	사용자(전역) 설정	워크스페이스(프로젝트별) 설정
파일 위치	VSCode 사용자 프로필 (`MCP: Open User Configuration`)	프로젝트 루트의 `.vscode/mcp.json`
적용 범위	PC의 모든 프로젝트	그 프로젝트 폴더를 열었을 때만
반복 작업 여부	최초 1회만 설정	새 프로젝트를 열 때마다 반복 필요
팀 공유	불가 (개인 PC 전용)	`.vscode/mcp.json`을 커밋하면 팀원과 공유 가능

실행 방법

MCP 서버를 쓰고 싶은 프로젝트 폴더를 VSCode로 연다.
프로젝트 루트에 .vscode 폴더가 없다면 새로 만든다.
그 안에 mcp.json 파일을 생성한다. 최종 경로:
1 <프로젝트 루트>\.vscode\mcp.json

아래 내용을 작성한다. (내용은 사용자 전역 설정과 동일하고 위치만 다름)

  
{
   "servers": {
      "ollama": {
         "command": "docker",
         "args": [
            "run",
            "-i",
            "--rm",
            "-e", "OLLAMA_HOST=http://host.docker.internal:11434",
            "wuodan/mcp-ollama:latest"
         ]
      }
   }
}

파일 저장 → 이 프로젝트를 열 때만 ollama MCP 서버가 인식된다. 다른 프로젝트 폴더를 열면 (그 폴더에 별도로 .vscode/mcp.json을 만들지 않는 한) 인식되지 않는다.

검증

사용자 전역 설정과 같은 방식임.

Copilot Chat을 Agent 모드로 전환
VSCode가 워크스페이스 서버를 처음 실행할 때는 보안을 위해 실행 승인을 한 번 요청한다 → 확인 후 승인
커맨드 팔레트 → MCP: List Servers로 ollama 서버 상태 확인

주의: 새 프로젝트마다 반복해야 함

전역 설정과 달리, 새로운 프로젝트 폴더를 열 때마다 위의 MCP 서버 json 작성 과정을 다시 해야 한다. 여러 프로젝트에서 Ollama를 공통으로 쓸 계획이라면 이 방식보다는 위의 “사용자(전역) 설정” 방식이 권장된다. 이 방식은 다음과 같은 경우에만 유용할 것:

특정 프로젝트에서만 Ollama MCP를 쓰고 싶고, 다른 프로젝트에서는 노출되지 않길 원하는 경우
팀원과 .vscode/mcp.json을 Git으로 공유해서, 프로젝트를 클론받은 사람이 자동으로 동일한 MCP 설정을 갖게 하고 싶은 경우 (다만 각자의 PC에도 Docker + Ollama가 설치되어 있어야 실제로 동작함)

참고: 만약 사용자 전역 설정과 워크스페이스 설정에 동일한 이름(ollama)의 서버가 둘 다 등록되어 있다면, 워크스페이스 설정이 우선 적용되는 것이 일반적인 동작이긴 하다. 그래도 두 곳에 서로 다른 설정을 넣어 혼동되지 않도록 보통은 둘 중 한 가지 방식만 선택해서 사용하는 게 권장됨.

요약 체크리스트

단계	조치	확인 명령
1	`OLLAMA_HOST=0.0.0.0` 환경변수 설정 + Ollama 재시작	`netstat -ano \\| findstr 11434`
2	Docker/WSL 내부 대역 확인	`ipconfig` (vEthernet WSL 항목)
3	방화벽 인바운드 규칙을 해당 대역으로 한정	`Get-NetFirewallRule ... \\| Get-NetFirewallAddressFilter`
4	`mcp_config.json`에 docker 기반 ollama MCP 서버 등록	Antigravity MCP 서버 관리 화면에서 활성화 확인
5	컨테이너→Ollama 통신 및 LAN 차단 검증	`docker run --rm curlimages/curl curl ...` / 타 기기에서 접속 시도
6	Docker 업데이트/재설치, WSL 재시작 등 이후 서브넷 변경 여부 확인 및 방화벽 규칙 갱신	`ipconfig` → `Set-NetFirewallRule -RemoteAddress ...` → `Get-NetFirewallRule ... \\| Get-NetFirewallAddressFilter`
7	(선택) VSCode 사용자 설정에 `servers` 키로 동일한 ollama MCP 서버 등록	`MCP: List Servers` 명령으로 활성화 확인

도커로 ollama MCP 연결하기 for 안티그래비티와 VScode

배경 설명

전제 조건

1단계. Ollama 환경변수 설정 (OLLAMA_HOST)

왜 필요한가

실행 방법 (GUI)

검증

2단계. Docker/WSL 내부 네트워크 대역 확인

왜 필요한가

실행 방법

3단계. Windows 방화벽 인바운드 규칙 생성 (접근 허용 대역 한정)

왜 필요한가

실행 방법

검증

(선택) 규칙 삭제/되돌리기

4단계. Antigravity의 mcp_config.json 작성

왜 필요한가

실행 방법

5단계. 전체 동작 검증

5-1. 컨테이너 단독 실행 테스트

5-2. LAN 격리 확인 (보안 검증)

5-3. Antigravity에서 실제 사용

6단계. (유지보수) Docker/WSL 서브넷 변경 시 대응

왜 필요한가

6-1. 서브넷 변경 여부 확인

6-2. 방화벽 규칙의 허용 대역 갱신

6-3. 재검증

서브넷 값 변경 이력 예시

7단계. (선택) VSCode에도 동일하게 적용하기

왜 필요한가

실행 방법 - 사용자(전역) 설정으로 등록

검증

참고: 프로젝트별로 다르게 설정하고 싶을 때 주의사항

대안: 프로젝트 폴더별로 개별 설정하기

실행 방법

검증

주의: 새 프로젝트마다 반복해야 함

요약 체크리스트

관련된 글

도커로 블로그 로컬 빌드하기 + 그런데 이제 로컬엔 WSL과 도커만 설치한

2048 게임하는 강화학습 에이전트 만들어보기

AR, RBM, ResNet