MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준

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-guard (CLI 훅) 실행 전 차단은 실행 계층에서만 가능
블로그 발행 publish.py (CLI 스크립트) 부작용 있는 일회 실행, 결과 검증
트렌드 수집 trend-scout (CLI) 예약 실행, 세션 밖에서도 동작

표를 다시 보면 규칙이 하나 보인다. 세션 안에서 반복해 읽는 작업은 MCP, 실행을 막거나 세션 밖에서도 돌아야 하는 작업은 CLI다.

각자 이긴 자리 — 실측 두 건

MCP가 이긴 자리 — 반복 조회와 토큰

pluck은 코드 저장소를 인덱싱해서 필요한 만큼만 읽게 해주는 도구다.

실측 하나. trend-scout의 analyzer.py는 294줄, 12,295바이트다. 에이전트가 cat으로 읽으면 이 전부가 컨텍스트에 들어간다.

pluck의 outline 모드로 읽으면 168바이트다. 구조 파악에 필요한 정보만 남긴 결과다.

먼저 분명히 구분할 게 있다. 이 절감은 pluck이라는 도구의 실력이지, MCP라는 연결 방식의 실력이 아니다.

같은 outline은 pluck의 CLI 명령으로도 똑같이 나온다. 위 실측도 CLI로 했다.

그런데도 pluck을 MCP로 붙인 이유가 있다. 에이전트의 도구 목록에 pluck의 read가 항상 올라와 있으면, cat 대신 그쪽을 고를 확률부터 달라진다.

데몬이 세션 내내 인덱스를 들고 있어 두 번째 조회부터 빨라지는 것도 연결을 유지해서 얻는 이득이다. 절감을 만드는 건 도구지만, 그 절감 경로를 기본 경로로 만드는 건 연결 방식이다.

물론 outline은 위치 파악용이라, 본문이 필요하면 심볼 단위로 추가 조회한다. 그래도 파일 전체를 매번 통째로 넣는 것과는 차이가 크다. 세션 안에서 같은 저장소를 수십 번 조회하는 패턴에서 이 차이는 누적된다.

CLI가 이긴 자리 — 실행 차단과 부작용 통제

반대로 시크릿 차단은 MCP로 풀 수 없었다. 지난 글에서 다룬 secret-output-guard 훅이 그 사례다.

처음에는 도구 실행 후에 출력을 마스킹하는 방식으로 만들었는데, 구조적으로 불가능했다. 실행이 끝난 시점에는 모델이 이미 원본 출력을 받은 뒤다.

유일한 차단 지점은 실행 전이고, 그건 도구 실행 직전에 끼어드는 훅(PreToolUse) — 즉 CLI 계층에 있다.

MCP 서버를 아무리 잘 만들어도, 에이전트가 Bash로 cat .env를 치는 것까지 MCP가 막아주지는 않는다. 차단은 프로토콜의 일이 아니라 실행 계층의 일이다.

이 훅은 차단해야 할 명령과 통과시켜야 할 명령을 섞은 32건 검증을 전부 통과한 상태로 돌고 있다.

발행 작업도 CLI가 맞았다. publish.py는 Blogger에 글을 올리는 부작용 있는 일회 실행이고, 실행 후 발행 결과를 다시 조회해 검증한다.

이런 작업은 스크립트가 낫다. 로그가 남고, 사람이 같은 명령을 그대로 재현할 수 있고, 예약 실행에도 태울 수 있다.

vs 구도가 놓치는 조합 — 훅은 왜 MCP를 강제하나

여기까지면 “역할 분담”으로 끝나는 얘기다. 그런데 내 환경에서 제일 재미있는 부분은 그다음이다.

내 저장소에는 pluck-first라는 PreToolUse 훅이 있다. 에이전트가 Bash로 cat, grep, rg, head, tail을 치면 훅이 실행을 거부하고 pluck MCP 도구를 쓰라고 돌려보낸다.

CLI 계층의 훅이 MCP 사용을 강제하는 구조다. MCP vs CLI라는 대립 구도로는 이 조합이 안 보인다.

이 훅이 왜 필요했는지가 곧 답이다. 도구를 붙여놓기만 하면 알아서 쓸 거라는 기대와 달리, 모델은 손에 익은 Bash로 자꾸 돌아간다. 도구를 잘 골라 붙이는 것까지는 절반이었고, 실제로 쓰게 만드는 데는 차단 지점이 필요했다.

pluck 자체도 양쪽에 다 걸쳐 있다. 같은 기능이 CLI 서브커맨드 5개로도, MCP 도구 9개로도 제공된다.

어느 쪽으로 에이전트에게 쥐여줄지는 도구를 만든 쪽의 몫이 아니다. 붙이는 쪽이 정하는 문제다.

MCP 쪽에 남는 불편한 사실

MCP를 걷어낼 생각은 없지만, 쓰면서 확인한 약점은 적어둔다.

하나는 도구 스키마가 컨텍스트를 상시 점유한다는 점이다. 서버를 붙일수록 모든 도구의 정의가 세션에 실린다. 조회 이득보다 스키마 비용이 큰 서버라면 붙일 이유가 없다.

또 하나는 연결이 디렉토리 범위에 묶인다는 점이다. 오늘 겪은 일이 이 경우다.

pluck은 저장소 루트의 설정 파일로 등록되는데, 그 밖의 디렉토리에서 세션을 열면 그냥 없다. 에러도 안 난다.

조용한 미연결은 발견이 가장 늦어지는 실패다. 지금은 세션을 열 때 연결 목록을 눈으로 확인하는 수준으로 때우고 있고, 세션 시작 시점에 연결을 검증하는 훅이 다음 작업이다.

데몬이 죽으면 그 서버의 도구 전부가 함께 사라진다. CLI는 명령 하나가 죽어도 나머지가 독립적으로 산다.

정리 — 언제 무엇을 쓰나

Q. 같은 조회를 세션 안에서 반복하는가?

A. 그렇다면 MCP. 인덱스와 상태를 데몬이 유지하는 이득이 조회 횟수만큼 쌓인다. 코드 검색, 브라우저 검사가 여기 해당한다.

Q. 실행을 막거나 검사해야 하는가?

A. 그렇다면 CLI 훅. 차단 지점은 실행 계층에만 존재한다. 시크릿 차단, 위험 명령 확인이 여기 해당한다.

Q. 세션이 없어도 같은 작업이 돌아야 하는가?

A. 그렇다면 CLI 스크립트. 예약 실행이 되고, 로그가 남고, 사람이 같은 명령을 그대로 재현할 수 있다. 발행, 수집, 백업이 여기 해당한다.

MCP란 무엇인가를 다룬 4월 글에서는 연결 방식 자체를 소개했다. 석 달 운용하고 나서 남은 질문은 “무엇인가”가 아니라 “언제 쓰지 않는가”였다.

새 도구를 붙일 때마다 MCP냐 CLI냐부터 묻지 않기로 했다.

반복 조회면 MCP, 차단과 부작용이면 CLI, 그리고 그 규율을 지키게 만드는 건 훅이다. 이 기준에 안 맞는 사례가 나오면 그때 다시 적으려고 한다.

관련 글

황재승 (Jason) — 8년 차 프론트엔드 개발자. AI 코딩 에이전트 하네스를 직접 구축·운용하며 실측 기록을 남긴다. 이 글의 수치는 모두 내 저장소에서 직접 측정한 값이다.

태그: #MCP #CLI #AI코딩에이전트 #ClaudeCode #하네스엔지니어링

댓글

댓글 쓰기

이 블로그의 인기 게시물

맥 스튜디오 M4 Max 128GB 로컬 LLM 4개 속도 비교 — gemma4·llama3.3·qwen3 실측

이미지
결론: M4 Max 128GB에서 가장 빠른 건 120B가 아니라 26B Dense 모델이다. 이유는 MoE 구조의 메모리 접근 패턴. 4개 모델 실측(tok/s 기준) + ChatGPT Plus 쿼터 제약 우회 대안 정리. 타이틀이 약속한 반전, 왜 생겼나 gpt-oss:120b 는 117B 파라미터짜리 MoE 구조. 총량은 117B지만 토큰 생성 한 번에 활성화되는 건 5.1B 정도. 이론적으로는 작은 모델만큼 빨라야 한다. 현실은 달랐다. MoE는 토큰마다 활성화되는 “전문가”가 바뀐다. 그래서 모델 전체(65GB)가 메모리에 상주해야 하고, 토큰마다 접근 위치가 비국소적(non-local)으로 흩어진다. 활성 파라미터 5.1B라는 숫자만 보면 훨씬 빨라야 맞다. 실제로 요구되는 메모리 대역폭은 전체 모델 크기에 가깝다는 얘기. 이 비교에서 직접 확인한 결과다. 반면 gemma4:26b 는 Dense 모델. 26B가 전부 계산에 참여한다. 파라미터 수 자체는 많지만 메모리 접근이 선형적이라 Apple Silicon의 통합 메모리 대역폭(546GB/s)을 효율적으로 쓸 수 있다. 같은 하드웨어에서 Dense가 MoE를 앞지르는 지점이 여기. 맥에서 로컬 LLM 고를 때 “MoE니까 활성 파라미터 작으면 빠르겠지” 하는 직관이 깨지는 순간. 테스트 환경 하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s. 런타임은 Ollama 0.20.7 (llama.cpp 기반). 동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정. 결과 4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가). 모델 크기(디스크) 활성 파라미터 Cold Load ...
자세한 내용 보기

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기

Claude Code로 블로그 발행 15분을 1줄로 — 해고 후 첫 자동화 경험

Claude Code로 블로그 자동 발행 스크립트를 만드는 방법이다. 마크다운 파일을 터미널에서 명령어 한 줄로 Blogspot에 발행한다. Google Cloud Console 설정 10분, Claude Code에 지시 20분, 테스트 5분이면 끝난다. 코드를 직접 쓰지 않고 Claude Code에게 지시만 해서 만들었다. Claude Code가 뭔가 터미널에서 “블로그 발행 자동화해줘”라고 치면 스크립트를 만들어주는 AI 코딩 도구다. Anthropic이 만들었다. IDE 플러그인이 아니라 독립 CLI 도구다. 프로젝트 폴더 전체를 읽고, 파일을 직접 생성하고 수정하고 실행까지 한다. 블로그 글 1편 올리는 데 15분이 걸렸다 Blogspot에 글을 올리려면 마크다운 → HTML 변환 → Blogger 접속 → 제목 입력 → HTML 모드 전환 → 본문 붙여넣기 → 라벨 설정 → 검색 설명 → 미리보기 → 발행. 1편에 15분. 한 달에 30편이면 7시간 이상을 “올리는 작업”에만 쓰는 셈이다. 글 쓰는 시간보다 올리는 시간이 더 길었다. 이걸 Claude Code에게 맡겼다. Claude Code에게 한 지시 터미널에서 Claude Code를 열고 이렇게 말했다: “마크다운 파일을 Blogger API v3으로 자동 발행하는 Python 스크립트를 만들어줘. frontmatter에서 제목, 라벨, 슬러그를 읽고, 마크다운을 HTML로 변환한 뒤, OAuth 2.0으로 인증해서 Blogger에 POST해줘. dry-run 옵션도 넣어줘.” Claude Code가 만든 것: publish.py 메인 스크립트 (약 200줄) requirements.txt 의존성 목록 config.json 설정 파일 OAuth(구글 로그인 인증) 흐름 (최초 1회 브라우저 인증 → 이후 자동) dry-run 모드 (발행 없이 HTML 미리보기) ...
자세한 내용 보기