MCP란 무엇일까? CLI와 비교해 고르는 에이전트 툴

MCP란 무엇이며, CLI 대신 언제 선택해야 할까요?

저장소에서 작업하는 개발자라면 CLI부터 시작합니다. CLI, 즉 명령줄 인터페이스는 명령으로 조작하는 프로그램입니다. 에이전트에 이미 승인된 명령 실행기가 있고 해당 툴로 작업을 처리할 수 있다면, 통합을 하나 더 추가해도 결과는 나아지지 않고 유지보수만 늘어날 수 있습니다.

여러 사용자를 지원하는 호스팅형 어시스턴트라면 높은 권한의 셸을 공유하기보다 권한 범위를 제한한 MCP 서비스를 선택합니다. Model Context Protocol은 AI 애플리케이션이 툴을 발견하고 호출하는 표준입니다. 원격 서버는 각 사용자의 인가를 받아 어시스턴트에 필요한 작업을 제공할 수 있습니다. 다만 실제로 권한을 검사하고 강제하는 일은 여전히 구현해야 합니다.

여러 엔지니어가 함께 쓰는 환경에서는 역할에 따라 둘을 병행합니다. 저장소 작업은 명령 실행기에 맡기고, 공유 비즈니스 작업은 호출자의 신원과 권한을 검사하는 서비스 뒤에 둡니다.

판단 기준은 실행 환경의 접근 범위, 인증 정보의 소유자, 필요한 작업의 지원 여부, 모델에 전달되는 정보량입니다. 프로토콜 이름은 그다음 문제입니다.

이 비교의 근거가 된 제작사 문서는 2026년 11월 11일에 확인했습니다. 문서에 나온 워크플로와 아키텍처에 대한 판단을 다룬 글이며, 벤치마크나 직접 사용해 테스트했다는 주장은 아닙니다.

CLI와 MCP는 각각 어떻게 모델과 연결될까요?

MCP는 에이전트에 툴 설명을, CLI는 실행할 명령을 제공합니다. 어느 쪽도 모델이 스스로 작업을 수행하게 하지는 않습니다. 모델을 둘러싼 애플리케이션이 제안된 호출을 받아 통제 절차를 적용하고, 실행한 뒤 결과를 돌려줍니다.

MCP에서는 클라이언트가 서버에 사용 가능한 툴을 요청합니다. 각 툴은 이름, 용도, 입력 스키마, 즉 어떤 필드를 받는지를 설명합니다. 애플리케이션이 이 정의를 모델에 제공하면 모델은 툴을 고르고 구조화된 인수를 전달합니다. MCP 툴 명세는 툴의 발견과 호출 방식을 정의하지만, 사용자와 상호작용하는 방식은 애플리케이션에 맡깁니다.

CLI에서는 에이전트가 명령 실행 툴로 설치된 프로그램을 실행합니다. 흔한 명령은 이미 알고 있을 수 있지만, --help를 읽어 설치된 툴의 문법을 확인할 수도 있습니다. 응답은 텍스트일 수도, 구조화된 JSON이나 파일 경로일 수도 있습니다. ‘CLI 출력’이 곧 ‘비정형 텍스트’라는 뜻은 아닙니다.

예를 들어 ‘내가 연 풀 리퀘스트 목록 보여줘’라는 요청은 인수가 붙은 GitHub 툴 호출이나 gh pr list 명령이 될 수 있습니다. 어느 경우든 실제 계정에 해당 풀 리퀘스트를 읽을 권한이 있어야 합니다. 인터페이스를 바꾼다고 접근 권한이 생기지는 않습니다.

프로토콜의 더 넓은 역할은 MCP 개념 안내에서 살펴볼 수 있습니다.

컨텍스트 비용: 단순한 로컬 작업에서는 CLI가 유리합니다

CLI는 불필요한 툴 정보를 모델의 컨텍스트에서 제외할 수 있지만, 컨텍스트 소비 자체를 없애지는 못합니다. 컨텍스트는 모델이 다음 행동을 결정할 때 받는 정보입니다. 호스트가 툴 설명과 매개변수 스키마를 포함하면 토큰을 차지합니다. 도움말과 명령 출력도 마찬가지입니다.

따라서 툴 목록이 방대한 MCP 서버는 유용한 작업을 시작하기 전부터 상당한 컨텍스트를 소비할 수 있습니다. 여기서 중요한 조건은 호스트가 언제 그 목록을 포함하느냐입니다. 모든 애플리케이션이 매번 모델을 호출할 때마다 사용 가능한 툴 정의를 전부 넣는다고 가정해서는 안 됩니다. 툴을 적게 선택하거나 필요할 때 찾아 쓰면 비교 결과도 달라집니다.

CLI 경로에서는 명령 실행기의 정의만으로 시작하고, 개별 툴의 도움말은 필요할 때 불러올 수 있습니다. 모델에 결과를 돌려주기 전에 데이터를 필터링할 수도 있습니다. 풀 리퀘스트의 전체 레코드를 반환한 뒤 대부분을 무시하라고 하는 것보다 제목과 URL만 요청하는 편이 낫습니다.

반대로 CLI가 거대한 로그를 출력하거나 스킬이 긴 매뉴얼을 불러오면 그 이점은 사라질 수 있습니다. 간결한 답을 반환하는 MCP 툴이 셸에서 여러 번 탐색하는 것보다 효율적일 수도 있습니다. 정의, 도움말, 출력, 재시도, 결과의 정확성까지 작업 전체를 측정해야 합니다. 명령 문자열이 짧다는 사실만으로는 알 수 있는 것이 많지 않습니다.

이 항목의 선택: 필요한 출력만 골라 받는 일상적인 로컬 작업에는 CLI입니다. MCP도 툴 구성과 결과를 작게 유지하면 충분히 경쟁력이 있습니다. 여기서 모든 경우에 통용되는 토큰 배수를 제시할 근거는 없습니다.

인증과 권한: 서비스가 경계를 강제할 때 MCP가 유리합니다

에이전트가 JSON을 보내는지 명령 문자열을 보내는지보다 사용자별 인가가 더 중요합니다. OAuth는 사용자가 비밀번호를 넘기지 않고 클라이언트에 권한을 부여하는 위임형 로그인 절차입니다. 원격 MCP 환경에서는 이 신원을 바탕으로 클라이언트가 접근할 계정, 레코드, 작업을 결정할 수 있습니다.

여러 고객사를 지원하는 고객 지원 어시스턴트를 생각해 봅니다. 이 어시스턴트는 모든 계정을 읽을 수 있는 엔지니어의 인증 정보를 받는 대신, 로그인한 고객의 레코드만 조회해야 합니다. 권한 범위를 올바르게 제한한 원격 MCP 서비스와 관리자가 사용하는 셸을 공유하는 방식 중에서는 서비스를 선택해야 합니다. 바로 이런 경우에 MCP가 그 두 구현 중에서는 유일하게 허용할 수 있는 선택이 됩니다.

물론 안전한 아키텍처가 이것뿐인 것은 아닙니다. API를 직접 통합해도 같은 경계를 강제할 수 있습니다. MCP를 추가한다고 경계가 자동으로 생기지도 않습니다. MCP 인가 명세는 인가를 선택 사항으로 두고 HTTP 인가 흐름을 정의하며, 환경에서 인증 정보를 가져오는 로컬 STDIO 서버를 별도로 구분합니다.

CLI도 브라우저 로그인과 범위가 제한된 인증 정보를 사용할 수 있습니다. 위험을 결정하는 것은 프로세스가 접근할 수 있는 인증 정보, 파일, 네트워크 목적지, 다른 실행 파일입니다. 권한을 좁힌 인증 정보로 샌드박스 안에서 동작하는 명령 실행기는 개발자 머신에 제한 없이 접근하는 환경과 다릅니다.

이 항목의 선택: 여러 사용자를 대신해 접근해야 한다면 권한 범위를 제한한 원격 MCP입니다. 어느 경로든 계정과 객체 단위의 인가를 코드로 강제하고, 모델이 볼 수 있는 출력에 인증 정보가 섞이지 않게 하며, 각 작업을 누가 승인했는지 기록해야 합니다.

GitHub CLI와 GitHub MCP: 저장소 작업인가요, 공유 서비스 접근인가요?

명령줄 클라이언트인 GitHub CLI, 즉 gh는 이미 저장소를 체크아웃해 작업 중인 코딩 에이전트에 가장 간단한 선택입니다. 내가 연 풀 리퀘스트를 요약한다고 가정해 봅니다. 인증을 마친 뒤 저장소 안에서 다음과 같이 문서에 나온 플래그를 사용할 수 있습니다.

gh pr list --author "@me" --json number,title,url

이 명령은 요약에 필요한 필드만 요청합니다. CLI는 JSON이 모델에 전달되기 전에 필터링할 수 있는 --jq도 지원합니다. 토큰 벤치마크 수치를 내세우지 않아도 바로 활용할 수 있는 컨텍스트 절약 방법입니다.

CLI의 한계는 이를 둘러싼 실행 환경에 있습니다. 내 노트북에서 작동하는 명령이 모든 직원이나 고객에게도 적절한 인터페이스인 것은 아닙니다. GitHub CLI 로그인 매뉴얼에 따르면 브라우저 로그인은 보통 시스템 자격 증명 저장소에 토큰을 보관하지만, 해당 저장소를 사용할 수 없으면 일반 텍스트로 저장합니다. ‘로컬’이라는 이유로 격리되어 있다고 가정하지 말고 실제 인증 정보 구성을 확인해야 합니다.

GitHub의 공식 툴 서버인 GitHub MCP Server는 MCP를 통해 저장소 작업을 수행해야 하는 어시스턴트에 적합합니다. 같은 요약 작업을 하려면 관련 풀 리퀘스트 툴을 제공하고, 의도한 사용자의 인가를 사용해 그 사용자가 연 요청을 조회하도록 합니다. GitHub는 호스팅형 원격 서버와 로컬 옵션을 모두 제공합니다.

GitHub 문서에는 툴셋과 개별 툴 선택 방법, 쓰기 툴을 제외하는 읽기 전용 모드가 나와 있습니다. 원격 OAuth 지원 역시 호스트 애플리케이션에서 적절한 GitHub 앱 또는 OAuth 앱을 설정해야 합니다. 전송 방식이 호환된다는 것만으로 인증 문제가 해결되지는 않습니다.

비교 결론: 개발자의 요약 작업과 저장소 스크립트에는 gh를 사용합니다. 공유 어시스턴트의 클라이언트가 필요한 인증 흐름을 지원한다면 MCP가 더 적합합니다. 어느 쪽도 저장소 권한을 대신하지 않습니다. MCP 툴 수를 줄이면 동작을 더 명확하게 만들고 컨텍스트 사용량도 줄일 수 있습니다.

Playwright CLI와 MCP: 코딩 작업인가요, 탐색을 반복하는 브라우저 작업인가요?

브라우저 작업을 위한 Microsoft의 명령 인터페이스인 Playwright CLI는 웹 변경 사항을 확인하는 코딩 에이전트의 기본 선택입니다. 제작사는 코딩 에이전트에 CLI와 스킬의 조합을 권장합니다. 명령을 사용하면 방대한 스키마와 페이지 데이터를 컨텍스트에 넣지 않아도 되기 때문입니다. 이는 제작사의 설계 지침이며, 이 글에서 속도를 측정했다는 주장은 아닙니다.

개발자가 폼을 확인할 때는 페이지를 열고, 관련 요소를 살펴보고, 상호작용한 뒤 결과를 확인하는 흐름으로 작업합니다. 행동할 때마다 페이지의 모든 세부 사항을 읽을 필요는 없습니다.

playwright-cli install: 제작사가 안내하는 명령으로 시작합니다

문서에 나온 설치 방법과 페이지를 읽기만 하는 확인 절차는 다음과 같습니다.

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

이 명령들은 공개 페이지를 살펴보는 절차이며 테스트 스위트는 아닙니다. 자체 애플리케이션에 상호작용을 추가하기 전에, 생성된 스냅샷으로 대상 요소를 파악합니다.

Playwright CLI 스킬: 워크플로 지침을 추가합니다

CLI를 설치한 뒤 스킬을 추가하는 공식 명령은 다음과 같습니다.

playwright-cli install --skills

중요한 제약은 주변 환경을 직접 갖춰야 한다는 점입니다. 명령을 실행할 환경, 적절한 브라우저 세션, 성공 기준을 정하는 지침이 필요합니다. 스킬은 절차를 도울 수 있지만 실제 고객 거래가 승인된 것인지는 판단해 주지 못합니다.

Microsoft의 브라우저 툴 서버인 Playwright MCP는 탐색을 반복하는 과정에서 MCP 클라이언트가 구조화된 페이지 정보를 활용할 수 있을 때 더 적합합니다. 페이지 요소를 구조적으로 설명하는 접근성 스냅샷을 사용해 브라우저 상호작용을 지원합니다.

주의할 점이 두 가지 있습니다. 첫째, 브라우저 상태 유지는 MCP만의 기능이 아닙니다. Playwright CLI도 한 세션 안에서 호출 사이에 쿠키와 저장소를 유지하며, 브라우저를 다시 시작해도 유지되는 영구 프로필을 제공합니다. 둘째, MCP 저장소는 서버가 보안 경계가 아니라고 명시합니다. 오리진 제어 역시 보안 경계를 제공하지 않으며 리디렉션에도 영향을 주지 않는다고 경고합니다.

비교 결론: 코딩 워크플로 안에서 반복적으로 확인하는 작업에는 CLI와 스킬을 사용합니다. 브라우저 툴을 통한 상호작용이 클라이언트와 작업에 도움이 된다면 MCP를 선택합니다. 세션 상태를 유지하려는 이유만으로 바꿀 필요는 없습니다. 이 경로는 Playwright MCP 설정 및 브라우저 테스트 가이드에서 더 자세히 다룹니다.

Stripe CLI와 Stripe MCP: 웹훅 개발인가요, 계정 작업인가요?

Stripe의 터미널 툴인 Stripe CLI는 결제 연동을 개발하고 디버깅할 때 유리합니다. 대표적인 작업은 Stripe에서 어떤 일이 발생했을 때 보내는 알림인 웹훅 이벤트를 로컬에서 실행 중인 애플리케이션으로 받는 것입니다. CLI 문서는 이벤트를 수신하고 전달하는 stripe listen, 예제 이벤트를 생성하는 stripe trigger를 안내합니다.

이 워크플로는 샌드박스 안에서 수행해야 합니다. 이벤트를 트리거하면 API 객체가 만들어지고 추가 이벤트가 발생할 수 있습니다. 단순히 샘플 페이로드를 출력하는 작업이 아닙니다. CLI는 API 작업과 요청 로그 확인도 지원하므로 웹훅 전달 외에도 활용할 수 있습니다.

인증 방식의 차이는 ‘CLI라면 API 키를 복사해 쓴다’는 설명보다 복잡합니다. Stripe 문서는 사용자별 브라우저 로그인, 가능한 환경에서의 안전한 로컬 인증 정보 저장, 세션 갱신과 해지를 설명합니다. 개발자에게는 적절한 방식일 수 있습니다. 호스팅형 어시스턴트에서 CLI를 사용하려면 여전히 사용자별 실행 환경과 인증 정보를 격리할 방법이 필요합니다.

에이전트를 위한 Stripe의 서비스 인터페이스인 Stripe MCP는 로컬 명령 실행기 없이 호환 어시스턴트에서 계정 작업을 수행할 때 유리합니다. 예를 들어 인가된 운영자는 어시스턴트에 관련 Stripe API 데이터를 찾아 읽도록 요청할 수 있습니다. 이 서버는 작업마다 개별 툴을 정의하는 대신 API 검색, 매개변수 탐색, 읽기, 쓰기 툴을 제공합니다.

Stripe는 사용자를 대신해 접근할 때 OAuth를, 독립적으로 접근할 때 에이전트 API 키를 지원합니다. 범용 툴인 stripe_api_write는 여러 작업을 포괄할 수 있습니다. Stripe가 요구하는 사람의 확인 절차는 작업에 따라 달라지며, 클라이언트 자체의 툴 승인 설정과도 별개입니다. 따라서 툴 범주를 승인하는 것은 그 툴이 수행할 수 있는 모든 비즈니스 작업을 승인하는 것과 다릅니다.

비교 결론: 로컬 웹훅 개발에는 CLI를, 어시스턴트에서 사용자를 대신해 계정 작업을 할 때는 MCP를 선택합니다. 명령이나 툴의 개수가 아니라 필요한 작업을 비교해야 합니다. 계정 데이터를 읽는 MCP 연결은 개발 워크플로의 로컬 웹훅 수신기를 대체하지 않습니다.

MCP와 스킬의 차이: 지침은 별도 계층입니다

스킬은 에이전트에게 일하는 방법을 알려 주고, MCP와 CLI는 행동할 수단을 제공합니다. Agent Skills 형식에서는 SKILL.md 파일에 이름, 설명, 작업 지침을 담고 필요에 따라 스크립트와 참고 파일을 덧붙입니다. 에이전트는 메타데이터를 먼저 발견하고, 필요할 때 자세한 지침을 불러옵니다.

‘MCP vs CLI vs skills’를 비교할 때 실용적인 조합은 흔히 CLI와 스킬입니다. CLI는 작업을 수행하고, 스킬은 사용할 명령, 선택할 환경, 살펴볼 증거, 멈춰야 할 시점을 정합니다. 스킬은 MCP 툴을 쓰는 에이전트에도 똑같이 지침을 제공할 수 있습니다.

풀 리퀘스트 요약 스킬이라면 열린 요청만 대상으로 삼고, 간결한 필드를 선택하며, 보고 작업 중에는 댓글을 게시하지 못하게 할 수 있습니다. 하지만 실제 접근 경계는 인증 정보와 실행 환경에서 강제해야 합니다. 문서화된 지침은 에이전트가 올바르게 행동하도록 돕지만 권한을 없애지는 않습니다.

이 항목의 선택: 반복 가능한 절차에는 스킬입니다. 스킬은 어느 인터페이스와도 함께 쓸 수 있으며, 불러올 때는 그 지침도 컨텍스트를 차지합니다.

MCP, API, CLI 비교: 서비스 로직은 한곳에 둡니다

비즈니스 규칙은 서비스에 두고, 사용자에게 필요한 인터페이스를 제공합니다. API는 애플리케이션을 프로그램으로 이용하는 접점입니다. Stripe의 인터페이스에서 보듯 CLI도 MCP 서버도 API를 호출할 수 있습니다.

둘 다 유지한다면 ‘누가 이 레코드를 바꿀 수 있는가’를 따로따로 구현하기보다 인가와 검증 로직을 재사용해야 합니다. 프로토콜 계층을 추가할 가치가 있는 경우는 MCP와 API 비교에서 설명합니다.

임의의 셸 문자열을 받는 래퍼만으로는 전환할 이유가 약합니다. 기존 명령 실행기에 MCP로 접근할 수 있게 만들 수는 있지만, 실행기의 권한은 그대로 유지되기 때문입니다. 유용한 어댑터는 범위가 한정된 작업을 제공하고 입력을 검증하며, 에이전트에 필요한 근거만 반환합니다.

배포 환경에 따른 선택 기준

권한 범위를 넓히지 않으면서 작업을 처리할 수 있는 최소한의 인터페이스를 선택합니다. 아래 구성은 출발점이지, 끝까지 고수해야 하는 선택은 아닙니다.

MCP에서 CLI로, 또는 CLI에서 MCP로 전환하려면

전체 툴 목록이 아니라 워크플로 단위로 옮깁니다. 비용이 많이 드는 부분은 툴 이름을 명령으로 바꾸는 일이 아니라, 기존 권한과 출력, 실패 처리 방식을 보존하는 일인 경우가 많습니다.

CLI로 옮길 때는 설치, 인증 정보, 명령 실행기, 출력 필터링, 재현 가능한 지침을 준비해야 합니다. MCP로 옮길 때는 서버를 선택하거나 운영하고, 클라이언트 인증과 툴 범위를 설정하며, 해당 인터페이스를 통해 오류를 처리해야 합니다. 브라우저 워크플로에서는 세션과 프로필의 소유 주체도 명시적으로 정해야 합니다.

정상적으로 작동하는 CLI 워크플로를 단지 프로토콜 지원을 추가하려고 바꾸지 않습니다. 명령이 더 짧아 보인다는 이유로 셸이 없는 사용자를 지원하는 원격 MCP 통합을 없애지도 않습니다.

에이전트 워크플로를 선택하고 범위를 정하는 실용적인 가이드를 더 받아 보려면 뉴스레터를 구독하세요.

자주 묻는 질문