“개인은 CLI, 회사는 MCP”라는 구분으로 도구를 고르면 불필요한 서버부터 만들기 쉽다. 한 사람이 여러 AI 앱에서 같은 원격 기능을 써야 할 수도 있고, 큰 조직도 로컬 빌드처럼 안정된 명령은 CLI가 더 단순하다. 선택 기준은 인원 수가 아니라 어디서 실행되고, 누가 소비하며, 어떤 권한으로 무엇을 바꾸는가다.
먼저 다섯 칸짜리 실행 경계표를 쓴다
도구 이름을 비교하기 전에 실제 작업 하나를 고른다. 예를 들어 “주문 데이터를 조회해 보고서를 만든다”면 ① 실행 위치 ② 입력 ③ 출력 ④ 호출 주체 ⑤ 변경 가능성을 한 줄씩 적는다. 같은 장비에서 한 런타임이 실행하고 JSON과 종료 코드만 받는다면 CLI가 기본값이다. 여러 AI 호스트가 같은 기능과 입력 스키마를 발견해야 한다면 MCP 후보가 된다.
MCP는 AI 앱과 외부 시스템이 tools·resources·prompts를 교환하는 공개 프로토콜이다. 반면 CLI는 실행 파일에 인수를 넘기고 표준 출력과 종료 상태를 받는 프로세스 인터페이스다. 둘은 경쟁 제품이 아니다. 검증된 CLI를 없애지 않고, 필요한 명령만 MCP tool로 감싸는 혼합 구조도 가능하다.
세 경로 중 가장 작은 계약을 고른다
| 상황 | 우선 선택 | 이유 |
|---|---|---|
| 로컬·단일 소비자·안정된 명령 | CLI | 설치와 실패 원인이 가장 단순하다 |
| 로컬 실행·여러 MCP 호스트 | stdio MCP | 같은 장비에서 typed 기능을 공유한다 |
| 원격 서비스·여러 호스트 | Streamable HTTP MCP | 중앙 배포와 기능 발견이 필요하다 |
MCP 2026-07-28 발표에 따르면 최신 사양은 프로토콜 수준의 세션과 초기화 핸드셰이크를 없앴다. 각 요청이 버전과 클라이언트 정보를 담고, 클라이언트는 필요할 때 server/discover로 기능을 확인할 수 있다. 다만 기존 클라이언트와 서버가 자동으로 최신 방식으로 바뀌는 것은 아니다. 도입 전 양쪽이 지원하는 프로토콜 버전과 폴백 동작을 먼저 시험한다.
기능보다 실패와 복구를 먼저 시험한다
읽기 전용 파일 하나로 작은 시범 작업을 만든다. CLI는 잘못된 인수, 네트워크 중단, 비정상 종료 때 JSON 오류와 종료 코드가 일관적인지 본다. MCP는 도구 목록, 입력 스키마, 타임아웃, 재시도, 구버전 클라이언트 연결 실패를 확인한다. 원격 MCP라면 한 인스턴스를 내려도 다음 요청이 다른 인스턴스에서 처리되는지 검증한다.
통과 기준도 숫자로 적는다. 같은 입력이 같은 형태의 결과를 내고, 실패 이유를 로그에서 찾을 수 있으며, 중복 실행이 데이터 손상을 만들지 않아야 한다. 세 조건 중 하나라도 실패하면 전사 배포가 아니라 시범 범위를 유지한다.
MCP를 붙여도 승인과 감사는 자동으로 생기지 않는다
공식 권한 사양은 권한 부여를 선택 기능으로 둔다. HTTP에서는 대상 리소스에 묶인 토큰과 최소 범위를 사용하고, stdio는 실행 환경에서 자격 증명을 받는 방식이 권장된다. 공식 보안 지침은 토큰 전달, confused deputy, SSRF, 로컬 서버 침해를 별도 위험으로 다룬다.
따라서 쓰기·삭제·결제 기능에는 호출자 식별, 최소 권한, 사람 승인, 실행 기록, 되돌리기 절차를 별도로 둔다. 최종 결정은 간단하다. 다섯 칸 실행 경계표를 작성하고 읽기 전용 시범이 통과하면, 단일 로컬 작업은 CLI로 남기고 여러 AI 호스트가 공유해야 하는 경계만 MCP로 올린다. 이 순서가 운영 복잡도를 가장 적게 늘린다.