Ollama MCP 연결 방법 2026: 로컬 모델을 파일, 데이터베이스, API에 연동하기

빠른 사실

• 프로토콜: stdio(로컬 하위 프로세스) 또는 Streamable HTTP(원격)를 통한 JSON-RPC 2.0. 기존 HTTP+SSE 전송은 더 이상 권장되지 않습니다(deprecated). 로컬 에이전트는 거의 stdio만 사용합니다. 현재 사양 개정판은 2026-07-28입니다.
• 기원: Anthropic이 오픈 사양(modelcontextprotocol.io)으로 만들었습니다. modelcontextprotocol/servers에서는 일부 참조 서버(filesystem, git, fetch, memory 등)만 계속 유지 관리되며, SQLite, PostgreSQL, Puppeteer, GitHub는 servers-archived로 옮겨졌습니다. 이제는 각 벤더가 자체 서버를 제공합니다.
• 로컬 클라이언트: Goose(오픈 소스, 저장소 aaif-goose/goose), Cline(VS Code 확장), Continue.dev(VS Code/JetBrains), LM Studio(데스크톱 앱), 그리고 여러 CLI 도구.
• 호환되는 Ollama 모델: 네이티브 tool calling 훈련을 받은 모든 모델. 예: Gemma 4 31B, GLM-4.7 Flash, Qwen3.6 27B, Qwen3 32B, Qwen3-Coder 30B, Llama 3.3 70B.
• 서버 전송 기본값: 로컬 프로세스에는 stdio. 서버를 여러 기기나 에이전트가 공유해야 할 때만 Streamable HTTP를 사용합니다.
• 설정은 클라이언트에 있습니다: Goose는 ~/.config/goose/config.yaml의 extensions 블록(또는 goose configure)을 읽고, Cline과 Continue.dev에는 각자의 MCP 설정이 있습니다. 필드의 개념은 어디서나 같습니다: 서버 이름, 명령, args, 환경 변수.
• Claude Desktop이 필요하지 않습니다. 프로토콜은 오픈되어 있고 Claude Desktop과 독립적입니다. 여기서 사용하는 서버는 오픈 소스(라이선스는 각각 확인하십시오)이며 모든 호환 클라이언트에서 작동합니다.

MCP 연동으로 로컬 모델에 실제로 가능해지는 것

• "이 저장소에서 모든 TODO를 찾아 파일별로 그룹화하고 notes/todos.md에 Markdown 요약을 작성하십시오." — filesystem 서버가 읽고, 모델이 그룹화하고, 같은 서버가 씁니다. 처음부터 끝까지 한 번의 왕복입니다.
• "이번 분기 수익 기준 상위 10개 고객을 보여주고 차트를 만드십시오." — postgres 서버가 SQL을 실행하고(읽기 전용 역할), 모델이 요약하고, 차트 도구를 위해 filesystem으로 CSV를 씁니다.
• "Hacker News 첫 페이지를 열어 상위 3개 AI 기사를 찾아 요약하고 내 읽기 목록에 추가하십시오." — playwright 서버가 브라우저를 제어하고, 모델이 추출 및 요약하고, filesystem이 추가합니다.
• "내 포크에 chore: bump deps 제목으로 draft PR을 열고 실패한 CI 실행을 링크하십시오." — github 서버가 PR을 만들고, 실행 정보를 가져오고, 설명에 링크를 씁니다.
• "events.db의 최근 100개 행을 보고 새 오류 급증의 원인이 된 사용자 ID를 알려주십시오." — 데이터베이스 서버가 데이터 사본을 쿼리하고, 모델이 추론하고, 답은 채팅 패널에서 확인합니다.
• 이 각각은 예전에는 호스팅된 도구가 있는 클라우드 모델이나 직접 작성한 스크립트가 필요했던, 문장 하나로 행동을 일으키는 워크플로입니다. MCP는 같은 서버를 여러 클라이언트에서, 같은 모델을 여러 서버에서 재사용할 수 있게 하는 계층입니다.

가장 많이 사용되는 4개의 MCP 서버 비교

구성 요소가 맞물리는 방식

• Ollama는 127.0.0.1:11434에서 백그라운드 서비스로 실행되며 OpenAI 호환 API로 모델을 제공합니다. MCP가 무엇인지 알지 못합니다. 채팅 완성에 응답하고, 모델이 요청할 때 tool call을 생성할 뿐입니다.
• MCP 클라이언트(Goose, Cline, Continue.dev, LM Studio)가 다리 역할을 합니다. 모델을 위해 Ollama와, 도구를 위해 MCP 서버와 통신합니다. 모델이 tool call을 생성하면 클라이언트가 올바른 서버로 라우팅하고, 결과를 받아 대화에 되돌려 줍니다.
• MCP 서버는 기능마다 하나씩 있는 독립적인 하위 프로세스입니다. stdio를 통해 JSON-RPC 2.0을 사용합니다. 각 서버는 Tools, Resources, Prompts 목록을 공개하며, 클라이언트는 이를 합쳐 모델에 제시되는 도구 표면을 만듭니다.
• stdio 전송은 모든 것을 로컬에 유지합니다. 서버는 클라이언트가 시작하고, stdin/stdout으로 통신하며, 클라이언트가 종료되면 함께 종료됩니다. 서버 자체가 연결을 여는 경우를 제외하면 네트워크로 나가는 것이 없습니다(브라우저 서버는 연결을 열지만 filesystem과 데이터베이스 서버는 열지 않습니다).
• 모델은 평평한 도구 목록 하나를 봅니다. 모델의 관점에서 서버는 없습니다. filesystem.read_file, playwright.browser_navigate, github.create_pull_request 같은 도구 이름의 목록만 있습니다. 라우팅은 클라이언트가 처리합니다.

설정: 15분 안에 Ollama + Goose 연결하기

• 1단계 — Ollama 설치. ollama.com/download(macOS/Windows/Linux)에서 다운로드하십시오. curl http://127.0.0.1:11434/api/tags로 서비스가 실행 중인지 확인하십시오.
• 2단계 — tool calling 모델 다운로드. Gemma 4 31B(gemma4:31b), GLM-4.7 Flash(glm-4.7-flash), Qwen3.6 27B(qwen3.6:27b), Qwen3 32B(qwen3:32b), Llama 3.3 70B(llama3.3:70b) 중에서 선택하십시오. 32GB 통합 메모리 또는 24GB VRAM이면 Q4_K_M에서 26B~32B를 여유 있게 처리할 수 있습니다.
• 3단계 — Goose 설치. macOS 또는 Linux에서는 curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash를 실행하십시오(또는 brew install block-goose-cli). Windows에서는 Goose 문서의 PowerShell 설치 프로그램이나 WSL을 사용하십시오. CLI는 goose로 설치됩니다.
• 4단계 — Ollama를 제공자로 구성. goose configure를 실행하고, ollama를 제공자로 선택하고, 모델을 다운로드한 것으로 설정하고, 호스트를 http://127.0.0.1:11434로 설정하십시오(비워 두어도 localhost:11434를 의미합니다). Goose가 이 내용을 ~/.config/goose/config.yaml에 기록합니다. Ollama의 기본 컨텍스트 창은 작을 수 있으며(Goose 문서는 4096 토큰을 언급합니다), Goose가 extension을 무시할 수 있으므로, Ollama를 OLLAMA_CONTEXT_LENGTH=32768(또는 더 높게)로 시작하십시오.
• 5단계 — filesystem MCP 서버 추가. goose configure를 실행해 Add Extension을 선택한 다음 Command-line Extension을 고르거나, ~/.config/goose/config.yaml에 extensions 블록을 추가하십시오(아래 예시). 일회성 테스트라면 goose session --with-extension "npx -y @modelcontextprotocol/server-filesystem /path/to/workspace"로 해당 세션에서만 활성화할 수 있습니다. goose session을 시작하고 테스트 디렉터리의 파일 목록을 요청하십시오. 첫 번째 턴이 서버가 연결되었음을 확인해 줍니다.
• 6단계 — 실제 작업으로 확인. goose session을 실행하고 "notes/의 모든 Markdown 파일을 제목과 단어 수와 함께 나열하고 결과를 notes/index.md에 쓰십시오."라고 요청하십시오. 에이전트가 읽고, 요약하고, 다시 쓰면 루프가 작동하는 것입니다.

# 1. Pull a tool-calling model
ollama pull gemma4:31b

# 2. Install Goose (macOS / Linux)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:31b
# Host:     http://127.0.0.1:11434

# 4. Give Ollama a context window big enough for tool use, then start a session
OLLAMA_CONTEXT_LENGTH=32768 ollama serve   # in a separate terminal
goose session

Filesystem 서버: 격리된 디렉터리에서 읽기 및 쓰기

• 설치: 참조 서버는 @modelcontextprotocol/server-filesystem이며 npx -y로 실행합니다(전역 설치 불필요, Node.js 필요). 지금도 유지 관리되는 참조 서버 중 하나입니다. Goose, Cline, Continue.dev가 설정에서 이 서버를 시작합니다.
• 허용 목록 경로: 서버는 하나 이상의 디렉터리 인수를 받아 그 밖의 작업을 거부합니다. 항상 명시적이고 좁은 경로를 전달하십시오. ~나 /는 절대 사용하지 마십시오.
• 노출되는 도구: read_file, read_multiple_files, write_file, edit_file(행 단위 대체), list_directory, search_files, move_file, create_directory, directory_tree. 모델은 이것들을 filesystem.read_file 등으로 봅니다.
• 사용 편의성: directory_tree는 JSON 트리를 반환하므로 모델이 특정 파일을 읽기 전에 방향을 잡기에 좋습니다. search_files는 grep과 비슷한 재귀 검색을 수행합니다.
• 위험 표면: 서버는 허용 목록을 지키지만, 그 안에서는 읽기/쓰기 권한이 완전합니다. 허용 목록을 유일한 장벽으로 취급하고 홈 폴더 대신 전용 workspace 디렉터리를 고르십시오.

# ~/.config/goose/config.yaml
extensions:
  filesystem:
    type: stdio
    name: filesystem
    enabled: true
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/agent-workspace"]
    envs: {}
    timeout: 300

데이터베이스 서버: Postgres(와 SQLite)를 안전하게 쿼리하기

• Postgres: postgres-mcp(Crystal DBA, MIT 라이선스)는 읽기 전용 모드가 있는 선택지입니다(최신 PyPI 릴리스는 2025년 5월이므로 의존하기 전에 저장소의 활동을 확인하십시오). uvx postgres-mcp --access-mode=restricted로 실행하고(또는 pipx install postgres-mcp, 혹은 Docker 이미지), 연결 URI는 DATABASE_URI 환경 변수로 전달하십시오. 제한(restricted) 모드는 읽기 전용 트랜잭션과 쿼리 시간 제한을 허용하며, 제한 없는(unrestricted) 모드는 개발 전용입니다.
• 전용 읽기 전용 역할도 함께 사용하십시오. 제한 모드가 하나의 장벽이고, 데이터베이스 역할이 또 하나의 장벽입니다. SELECT 권한만 있는 agent_ro 역할을 만들고 그 역할의 연결 문자열을 사용하십시오.
• SQLite: 참조 서버는 보관되었습니다. Python 패키지 mcp-server-sqlite(npm 패키지가 아니며, 마지막 릴리스는 2025년 4월)로, 아직 실행될 수는 있지만 수정은 제공되지 않습니다. 하나뿐인 원본이 아니라 반드시 파일 사본에만 연결하거나, 데이터를 Postgres에 불러와 사용하십시오. 커뮤니티 SQLite 서버는 파일을 넘기기 전에 코드를 읽으십시오.
• 스키마 인식: 분석적인 질문을 하기 전에 에이전트에게 "테이블을 나열하고 가장 많이 사용되는 5개를 설명하십시오"라고 요청하십시오. 모델은 열 이름을 추측할 때보다 스키마를 확인한 뒤에 훨씬 정확합니다.
• 비용: 쿼리는 데이터베이스로 직접 갑니다. 1억 행 테이블에 대한 잘못된 SELECT *는 사람이 실행했을 때와 똑같은 사고입니다. 역할을 statement timeout이 있는 별도의 연결 풀에 두십시오.

# ~/.config/goose/config.yaml
extensions:
  postgres:
    type: stdio
    name: postgres
    enabled: true
    cmd: uvx
    args: ["postgres-mcp", "--access-mode=restricted"]
    envs:
      DATABASE_URI: "postgresql://agent_ro:${PG_AGENT_PASSWORD}@127.0.0.1:5432/analytics"
    timeout: 300

브라우저 MCP 사용법: 로컬 LLM에 Playwright MCP 연결하기

• 어떤 서버를 쓸까: Microsoft의 @playwright/mcp(npx @playwright/mcp@latest)를 사용하십시오. 기존 @modelcontextprotocol/server-puppeteer에는 "no longer supported" 표시가 있고, npm에는 @modelcontextprotocol/server-playwright 패키지가 존재하지 않습니다.
• 노출되는 도구: browser_navigate, browser_snapshot, browser_click, browser_type, browser_fill_form, browser_evaluate(JavaScript 실행), browser_take_screenshot, browser_tabs, browser_wait_for. 모델은 browser_snapshot(접근성 스냅샷으로, Playwright MCP가 동작 수행에는 스크린샷보다 이쪽을 권장합니다)으로 페이지를 읽고, 스크린샷은 눈으로 확인할 때만 사용합니다.
• 지연: 실제 브라우저 세션은 동작당 1~5초가 걸립니다. 페이지 내용이 크기 때문에 다단계 탐색은 쉽게 30~60초와 수만 토큰을 소비합니다. 32K 이상 컨텍스트 창을 사용하십시오.
• 요소 참조: 모델은 스냅샷에 있는 참조로 요소를 클릭합니다. 작은 모델은 잘못된 요소를 자주 고르며, 27B 이상의 tool calling 모델은 일반적인 패턴을 안정적으로 처리합니다. 작업 범위를 제한하십시오. "이 URL에서 제목과 첫 단락을 추출하십시오"는 "사이트를 탐색하여 연락처 페이지를 찾으십시오"보다 훨씬 신뢰할 수 있습니다.
• 올바른 사용 사례: 연구(페이지 열기, 요약하기, 노트에 추가), 회귀 테스트(탐색, 클릭, 스크린샷), 직접 제어하는 페이지의 양식 작성. 잘못된 사용 사례: 라이브 웹에서 잘못된 클릭이 결과를 일으키는 모든 작업.

# ~/.config/goose/config.yaml
extensions:
  playwright:
    type: stdio
    name: playwright
    enabled: true
    cmd: npx
    args: ["@playwright/mcp@latest"]
    envs: {}
    timeout: 300
# Block obviously dangerous endpoints at the OS firewall level
# rather than relying on the agent to refuse them.

GitHub 서버: 로컬 모델로 저장소, 이슈, PR 다루기

• 설치: GitHub 공식 github/github-mcp-server를 사용하십시오. Docker 이미지(ghcr.io/github/github-mcp-server)로 실행하며, PAT는 GITHUB_PERSONAL_ACCESS_TOKEN 환경 변수에 넣습니다. 기존 @modelcontextprotocol/server-github npm 패키지에는 "no longer supported" 표시가 있으므로 새 설정에는 사용하지 마십시오.
• 노출되는 도구: search_repositories, get_file_contents, create_or_update_file, create_pull_request, list_issues, create_issue, add_issue_comment, merge_pull_request, 그 외 다수. 전체 표면은 크지만 대부분의 작업은 5~10개의 도구를 사용합니다.
• PAT의 범위를 제한하십시오. 필요한 최소 권한(탐색에는 Read, PR/이슈 생성에는 Write)으로 특정 저장소에 한정된 fine-grained PAT를 사용하십시오. 실험적인 에이전트에 repo 권한이 있는 classic PAT를 사용하지 마십시오.
• 실제 워크플로: 트리아지("최근 열린 이슈 20개를 읽어 그룹화하고 레이블을 제안하십시오"), 초안 작성("README를 읽고 오타를 수정하는 PR을 여십시오"), 보고("이번 주에 정체된 PR은 무엇입니까").
• 위험 표면: 에이전트는 이슈와 PR을 만들고 댓글을 달 수 있으며, 쓰기 권한이 있으면 커밋을 push할 수도 있습니다. 모델과 워크플로를 모두 신뢰하지 않는 한 merge 도구는 비활성화하십시오. fine-grained PAT를 쓰는 저장소에서 잘못 merge한 것은 복구할 수 있지만, 빨리 알아차렸을 때만 가능합니다.

# ~/.config/goose/config.yaml
extensions:
  github:
    type: stdio
    name: github
    enabled: true
    cmd: docker
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    envs:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
    timeout: 300
# Fine-grained PAT scoped to one or two test repos,
# not your personal account-wide classic token.

모델을 신뢰하지 않는 보안 모델

• filesystem 서버를 하나의 디렉터리로 제한하십시오. ~나 /는 절대 안 됩니다. agent-workspace/ 폴더를 정하고 에이전트가 다룰 파일의 사본을 그 안에 넣으십시오. 에이전트가 잘못되더라도 최악의 경우는 폴더 하나입니다.
• 데이터베이스 서버를 기본적으로 읽기 전용으로 실행하십시오. SELECT 권한만 있고 30초 statement timeout이 설정된 전용 agent_ro 역할이 한 부류의 사고를 완전히 없애 줍니다.
• 모든 쓰기 또는 셸 도구를 명시적 승인 뒤에 두십시오. Goose, Cline, Continue.dev는 모두 도구별 승인 규칙을 지원합니다. 읽기 도구는 기본적으로 허용하고, write_file, edit_file, execute_command, create_pull_request, 양식을 제출하는 모든 브라우저 동작에는 승인을 요구하십시오.
• 감사 로그를 사용하십시오. 모든 MCP 클라이언트는 tool call과 결과를 기록합니다. 긴 세션이 끝나면 로그를 훑어보십시오. 모델이 예상하지 못한 것을 시도하는 모습이 발견됩니다(때로는 무해하고, 때로는 권한을 더 조일 이유가 됩니다).
• 타사 접근은 토큰 범위를 좁게 제한하십시오. GitHub PAT는 테스트 저장소 두 개로, Postgres 역할은 읽기 전용으로, 브라우저 세션은 자격 증명 없이. 모델은 결국 예상하지 못한 것을 시도합니다. 할 수 있는 일의 한계가 모델이 올바르게 행동하는지에 달려 있으면 안 됩니다.
• 민감한 데이터 작업에는 에이전트를 격리하십시오. 개인 데이터를 다룰 때는 에이전트를 실행하는 동안 호스트의 네트워크 접근을 끄십시오(또는 네트워크 네임스페이스를 사용). 로컬 스택은 이미 기기 밖으로 아무것도 보내지 않지만, 심층 방어는 타사 서버의 실수를 잡아 줍니다.
• MCP 서버 선택도 다른 의존성 선택과 똑같이 다루십시오. 참조 서버는 잘 유지 관리되지만 많은 타사 서버는 그렇지 않습니다. 자격 증명이 필요한 서버는 설치하기 전에 코드를 읽으십시오.

로컬 MCP vs Claude Desktop: 무엇이 바뀌고 무엇이 그대로인가

로컬 MCP를 위한 tool calling 모델 선택

• Gemma 4 31B(gemma4:31b) — Google의 tool calling 훈련은 이 크기에서 최고 수준입니다. Q4_K_M에서 16GB 통합 메모리 또는 24GB VRAM에 들어갑니다. 일반 추론이 좋고, 연쇄 tool call에서는 다소 보수적입니다.
• GLM-4.7 Flash(glm-4.7-flash) — Zhipu의 모델은 tool calling 신뢰성이 매우 높고 기본으로 128K 컨텍스트 창을 제공합니다. Gemma 4보다 약간 무겁지만 24GB GPU에 여유 있게 들어갑니다.
• Qwen3.6 27B(qwen3.6:27b) — Ollama에서 쓸 수 있는 더 새로운 Qwen 선택지입니다(약 18~19GB, 256K 컨텍스트, tool calling 지원). Qwen3 32B(qwen3:32b) — 균형이 잘 잡혀 있고, 조밀한 32B는 MCP를 문제없이 처리하며 긴 에이전트 루프에서도 잘 작동합니다. Qwen3-Coder 30B(qwen3-coder:30b)는 에이전트 작업이 코드 중심이라면 최선의 선택입니다.
• Llama 3.3 70B(llama3.3:70b) — 성능 한계는 가장 높지만 가장 무겁습니다. Q4_K_M에서 48GB 이상 통합 메모리 또는 2× 24GB GPU가 필요합니다. 하드웨어가 허용하는 경우에만 사용하십시오. 더 작은 모델로 충분한 경우가 많습니다.
• MCP 작업에서 피해야 할 것: 7B 미만의 모든 모델, 그리고 명시적인 tool calling 훈련이 없는 범용 모델. 잘못된 형식의 호출을 생성하고, 루프가 멈추고, harness를 탓하게 됩니다. 하지만 harness는 문제가 없습니다.
• 어떤 모델에서든 tool calling 품질을 높이는 구조적 프롬프팅 기법은 Chain-of-thought 프롬프팅을 참조하십시오.
• 비교 데이터는 2026년 tool calling을 위한 최고의 로컬 모델을 참조하십시오.

MCP vs 일반 Function Calling: 차이점은 무엇인가

• Function calling은 LLM 측의 기능입니다. 모델이 도구 이름과 인수를 설명하는 구조화된 JSON 객체를 생성합니다. OpenAI의 도구, Anthropic의 도구, Ollama의 tool call API는 wire 형식만 조금씩 다를 뿐 같은 아이디어를 사용합니다.
• MCP는 그 위에 위치합니다. 도구가 프로세스 간에 설명, 발견, 호출, 반환되는 방식을 표준화합니다. function calling만 있는 모델은 filesystem에 대해 아무것도 모릅니다. MCP 서버가 filesystem 작업을 사용할 수 있게 만들고, 클라이언트가 이를 모델의 function calling API에 매핑하면, 모델이 그것을 호출할 수 있게 됩니다.
• 이점은 상호 운용성입니다. filesystem 서버를 한 번 작성하면 Claude Desktop, Goose, Cline, Continue.dev, LM Studio 모두 변경 없이 사용합니다. 모델을 Claude에서 Gemma 4로 바꿔도 서버는 바뀌지 않습니다.
• 순수한 function calling으로도 에이전트를 만들 수 있습니다. 다만 프로젝트마다 filesystem, 데이터베이스, 브라우저 핸들러를 다시 구현하게 됩니다. MCP를 쓰면 이것들이 바로 가져다 쓰는 의존성이 됩니다.
• 일회성 스크립트라면 순수한 function calling이 더 간단합니다. 프로젝트나 모델을 넘나들며 재사용하고 싶은 것이라면, 며칠 안에 MCP 쪽이 더 적은 노력으로 끝납니다.

로컬 MCP 설정 시 일반적인 실수

• 실수 1: 범용 소형 모델 사용. 7B 미만 모델(그리고 tool calling 파인튜닝이 없는 대부분의 7B~13B 범용 모델)은 잘못된 형식의 tool call을 생성합니다. tool calling에 맞게 튜닝된 27B 이상 모델을 사용하고 harness와 싸우는 일을 그만두십시오.
• 실수 2: 허용 목록에 홈 디렉터리 넣기. "테스트만 하려고" 넣은 ~ 허용 목록은 일상적인 사용까지 살아남습니다. 처음부터 전용 agent-workspace를 만드십시오.
• 실수 3: 데이터베이스 서버를 읽기/쓰기 모드로 두기. 자신만만한 에이전트가 실제 테이블에 DELETE 쿼리를 작성하는 것이 바로 이 설정이 막는 사고입니다. agent_ro를 기본 역할로 만들고, 명시적으로 필요한 작업에만, 그 작업이 진행되는 동안에만 별도의 쓰기 가능 역할을 만드십시오.
• 실수 4: 모든 도구 자동 승인. "모두 승인" 토글은 편리하지만 위험합니다. 읽기 도구(read_file, list_directory, query)는 자동 승인하고, 쓰기/셸/PR 도구는 항상 승인을 요구하십시오.
• 실수 5: 다단계 브라우저 작업에 32K 컨텍스트 모델 사용. 페이지 내용이 크기 때문에, 세 페이지를 탐색하는 에이전트는 추론에 들어가기 전에 32K 토큰을 소진할 수 있습니다. 브라우저 중심 작업에는 128K 컨텍스트 모델을 사용하십시오.
• 실수 6: 에이전트에게 판단력이 있다고 가정하기. 판단력은 없습니다. 모델에게는 "이것은 프로덕션 데이터베이스다"나 "이 PR은 배포된다"라는 개념이 없습니다. 권한이 유일한 장벽입니다.
• 실수 7: 처음부터 모든 참조 서버 설치. 도구가 많아지면 시스템 프롬프트가 커지고 도구 선택이 느려지고 덜 안정적이 됩니다. filesystem으로 시작하고, 필요한 워크플로가 생겼을 때만 다른 서버를 추가하십시오.
• 실수 8: 오래된 튜토리얼의 보관된 참조 서버 설치. npm 패키지 @modelcontextprotocol/server-postgres, -puppeteer, -github에는 "no longer supported" 표시가 있고 SQLite 서버는 보관되었습니다. 일부 오래된 가이드는 존재하지 않는 npm 패키지(server-sqlite, server-playwright)를 언급하기도 합니다. 위에서 소개한 유지 관리되는 서버를 사용하십시오.
• 실수 9: Ollama에 MCP 설정 넣기. Ollama에는 MCP 설정이 없습니다. 서버는 클라이언트에서 구성합니다(Goose extensions, Cline 또는 Continue.dev의 MCP 설정).

출처

• Model Context Protocol 사양 — 공식 사양, JSON-RPC 스키마, 전송 및 수명 주기 정의, 2026-07-28 변경 내역 포함.
• modelcontextprotocol/servers GitHub 저장소 — 유지 관리되는 참조 서버(filesystem, git, fetch, memory 등)와 보관된 서버 목록.
• github/github-mcp-server — GitHub 공식 MCP 서버, Docker 및 바이너리 설정.
• microsoft/playwright-mcp — Playwright MCP 서버와 브라우저 도구.
• crystaldba/postgres-mcp — 제한(읽기 전용) 접근 모드를 갖춘 Postgres MCP 서버.
• Goose 문서 — CLI 설치, Ollama 제공자 설정, extension(MCP 서버) 설정 구문.
• Ollama 모델 라이브러리 — 이 가이드에서 참조하는 사용 가능한 로컬 모델, tool calling 지원 표시, 양자화 수준.
• Cline GitHub 저장소 — VS Code용 MCP 클라이언트 구현, MCP 서버 패널.
• Continue.dev 문서 — Continue.dev 클라이언트의 mcpServers 설정 블록 참조.

자주 묻는 질문

관련 읽기

• 2026년 tool calling을 위한 최고의 로컬 모델 — 위에서 권장한 모델(Gemma 4, GLM-4.7, Qwen3, Llama 3.3)에 대한 비교 벤치마크.
• 로컬 자율 에이전트가 실제로 작동합니다 — 장시간 작업에서 로컬 MCP 에이전트가 안정적으로 할 수 있는 것과 없는 것에 대한 현실 점검.
• Continue.dev vs Cline vs Aider: 2026년 최고의 로컬 코드 에이전트 — 코드 중심 작업을 위한 인접 에이전트 맥락. Cline과 Continue.dev도 MCP 클라이언트입니다.
• 2026년 최고의 로컬 LLM — 더 넓은 오픈 웨이트 환경을 위한 모델 참조.
• 로컬 AI 에이전트로 Zapier 대체하기 — 같은 MCP 스택을 위한 워크플로 자동화 관점.
• Power Local LLM 허브 — 전체 가이드 라이브러리.