VS Code에 새로 설치한 Cline에 로컬 Ollama 모델을 물려서 쓰다가, "얘가 인터넷 검색까지 알아서 해주나?"라는 질문 하나로 시작해서 결국 MCP 웹서치 서버를 붙였다가 다시 걷어내는 데까지 하루를 다 썼다.
Cline 규칙 파일부터 정리했다
미리 만들어둔 clinerules.md(회사용)와 clinerules-personal.md(개인용) 두 파일을 Cline에 어떻게 인식시킬지부터 물어봤다. Cline은 확장자 없는 .clinerules 파일이나 .clinerules/ 폴더를 프로젝트 루트에 두면 자동으로 읽는다는 걸 확인했고, 개인용 규칙은 전역 적용을 원해서 macOS 기준 ~/Documents/Cline/Rules/personal.md로 복사해 전역 등록했다. diff로 원본과 내용이 완전히 같은지까지 확인. 회사 프로젝트가 지금은 없어서 워크스페이스별 규칙은 나중에 필요할 때 .clinerules/ 폴더로 추가하기로 미뤘다.
"인터넷 검색도 하나?" 궁금해서 파봤다
Cline에 내장된 websearch 기능은 Cline 자체 유료 provider를 쓸 때만 동작한다는 걸 확인했다. 나는 로컬 Ollama의 qwen2.5-coder:7b를 물려 쓰고 있어서 기본 웹서치는 아예 켜지지 않는 구조였다. MCP 서버를 따로 붙여야 하고, 7B급 로컬 모델은 tool-calling 신뢰도가 떨어질 수 있다는 것도 이때 미리 경고받았다.
tool-calling 전용이라던 모델, 알고 보니 껍데기였다
대안으로 나온 hhao/qwen2.5-coder-tools가 진짜 해결책인지 검증해봤다. 시스템 프롬프트 파일을 직접 열어보니 실제 파인튜닝이 아니라, 베이스 qwen2.5-coder 가중치 그대로에 "도구 쓸 때 JSON으로 답해라"는 지시만 얹은 Modelfile 래퍼였다. Ollama 공식 tools 뱃지도 없었고, 실제로 Cline과 붙였을 때 포맷 에러가 났다는 커뮤니티 사례까지 나왔다. 마침 로컬에 이미 설치돼 있던 qwen3.5:9b를 발견했는데, 공식 tools·vision·thinking 뱃지가 다 붙어 있어서 이걸로 바로 교체하기로 했다.
웹서치 MCP 서버를 직접 붙여봤다
Cline 확장의 설정 파일 위치(~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json)를 찾아서, API 키 없이 쓸 수 있는 duckduckgo-mcp-server를 등록했다. 등록 직후 "Cannot use checkpoints in Desktop directory"라는 낯선 메시지가 떠서 당황했는데, 알고 보니 작업 폴더가 ~/Desktop 하위라 macOS TCC 보호 정책 때문에 Cline이 체크포인트(자동 스냅샷) 기능만 방어적으로 꺼둔 것이었다. 실제 파일 편집이나 도구 실행에는 지장이 없어서 그대로 넘어갔다.
첫 테스트에서는 모델이 등록해둔 MCP 도구를 쓰지 않고 터미널 curl/grep으로 뉴스를 긁어왔고, 중간중간 "Invalid API Response" 에러도 반복됐다. MCP 패널을 열어보니 서버는 켜져 있는데 연결 상태가 빨간 점(연결 안 됨)이었다. "Restart Server" 버튼을 눌러 초록 점으로 복구했더니 다음 시도부터는 실제로 duckduckgo_web_search 도구 승인 팝업이 떴다.
그런데 곧바로 "DDG detected an anomaly in the request"라는 에러가 떴다. DuckDuckGo는 공식 검색 API가 없어서 이 MCP가 사실은 HTML 페이지를 스크래핑하는 방식이었고, 요청이 반복되자 봇으로 탐지돼 차단된 것이었다.
결국 MCP를 다 걷어냈다
공식 API 기반 대안도 잠깐 검토했다. Brave Search API는 2026년 2월부터 무료 티어가 없어지고 가입 시 카드 등록이 필수로 바뀌어서 제외했고, Tavily는 카드 없이 월 1,000 크레딧 무료에 공식 MCP(tavily-mcp)까지 있어서 등록까지는 해봤다. 하지만 결국 로컬 9B 모델로 MCP 신뢰성까지 계속 쫓아가는 것보다 역할을 나누는 게 낫다는 결론에 도달했다. 로컬 Cline은 외부 지식이 필요 없는 초안 작성·기계적 수정에만 쓰고, 검색과 판단이 필요한 작업은 Claude Code로 넘기기로 하고 등록해뒀던 MCP 서버(duckduckgo-search, tavily-mcp)를 전부 삭제했다.
헤르메스처럼 무인 에이전트로도 써볼까 검토만 해봤다
겸사겸사 Cline을 이미 돌리고 있는 헤르메스 뉴스 자동화 파이프라인처럼 무인 에이전트로 쓸 수 있는지도 알아봤다. Cline CLI 2.0은 헤드리스 모드(-y/--yolo 플래그)와 cron 연동을 지원했고, @cline/core/@cline/agents SDK로 직접 스크립트에 에이전트 루프를 심는 방법도 있었다. 다만 지금 겪은 tool-calling 신뢰도 문제가 사람이 없는 무인 환경에서는 더 위험해질 수 있고, Cline CLI/SDK 자체도 아직 신생이라 이미 안정적으로 도는 헤르메스를 대체할 근거는 부족했다. 그래서 적용은 보류하고 계속 헤르메스 체제로 가기로 했다.
Trouble Shooting
| 증상 | 원인 | 해결 방법 |
|---|---|---|
| hhao/qwen2.5-coder-tools가 tool-calling을 해결해줄 줄 알았음 | 실제 파인튜닝이 아니라 시스템 프롬프트만 얹은 Modelfile 래퍼, 공식 tools 뱃지 없음 | 공식 tools 뱃지가 있는 qwen3.5:9b로 교체 |
| "Cannot use checkpoints in Desktop directory" 메시지 발생 | 프로젝트가 ~/Desktop 하위라 macOS TCC 정책상 체크포인트 기능이 방어적으로 비활성화됨 | 실제 작업엔 영향 없음을 확인하고 그대로 진행 |
| MCP 도구를 안 쓰고 터미널로 우회 + Invalid API Response 반복 | 설정 파일을 실행 중에 직접 편집해 서버가 등록만 되고 연결은 안 된 상태(빨간 점)였음 | MCP 패널에서 Restart Server 클릭 → 초록 점으로 연결 복구 |
| 연결 복구 후에도 "DDG detected an anomaly" 반복 | DuckDuckGo는 공식 API가 없어 스크래핑 방식이라 봇 탐지에 걸리는 구조적 한계 | Tavily 등 공식 API 검토 후, 결국 로컬 Cline에서는 MCP 자체를 걷어내는 쪽으로 결정 |
느낀 점 / 다음에 할 일
로컬 LLM은 무료고 빠르지만, tool-calling 신뢰도는 아직 클라우드 모델과 체감 차이가 크다는 걸 직접 삽질하며 확인한 하루였다. 앞으로는 "초안은 로컬, 판단과 검색은 클라우드"로 역할을 명확히 나눠서 쓰기로 했다. 헤르메스 자동화는 여전히 cron 트리거 등록이 남아있으니, 다음 세션에서는 그것부터 마저 정리할 계획이다.
댓글
댓글 쓰기