MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준
MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준 AI 코딩 에이전트에 도구를 붙이는 방식을 두고 MCP냐 CLI냐 하는 글이 늘었다. 나는 양쪽을 다 쓴다. 코드 검색은 MCP 서버로 하고, 시크릿 차단과 블로그 발행은 CLI 쪽에 맡긴다. 그런데 오늘 평소와 다른 디렉토리에서 세션을 열었다가, 늘 쓰던 MCP 서버가 조용히 빠져 있는 걸 발견했다. 에러 한 줄 없었다. 이 사건까지 겹치고 나서야 정리가 됐다 — 판단 기준은 도구의 모양이 아니라 “무엇을 통제해야 하는가”였다. 먼저 요약. 세션 안에서 반복되는 조회는 MCP가 이기고, 실행을 막거나 검증해야 하는 작업은 CLI가 이긴다. 그리고 내 환경에서 제일 잘 굴러가는 구조는 둘 중 하나를 고르는 대신, CLI 훅이 MCP 사용을 강제하는 조합이었다. 누가 읽으면 좋은가 Claude Code나 Codex에 MCP 서버를 몇 개 붙였는데, 컨텍스트만 커지고 체감 이득이 없던 적이 있다. 에이전트가 cat과 grep으로 코드를 통째로 읽어대서, 토큰 사용량이 신경 쓰인 적이 있다. .env 노출 같은 사고를 막고 싶은데, MCP 서버를 잘 고르면 될 거라고 기대한 적이 있다. 셋 다 내가 직접 겪은 일이다. 같은 상황이라면 아래 기준을 그대로 가져다 써도 될 것 같다. 내 환경에서 두 방식이 놓이는 자리 MCP(Model Context Protocol)는 에이전트가 세션 안에서 도구를 함수처럼 호출하는 연결 방식이고, CLI는 에이전트가 셸에서 명령을 실행하는 방식이다. 아래 표의 훅은 그 실행 앞뒤에 끼어드는 검사 스크립트를 말한다. 내 환경에서 실제로 돌아가는 작업을 연결 방식별로 나누면 이렇다. 작업 연결 방식 이유 코드 구조 파악·검색 pluck (MCP) 반복 조회, 토큰 절감 브라우저 조작·검사 chrome-devtools (MCP) 세션 상태 유지 시크릿 노출 차단 secret-output-gu...