팀들은 내부 도구들을 에이전트(agents)가 사용할 수 있도록 서둘러 공개하고 있습니다. 이는 좋은 현상입니다. 하지만 동시에 많은 설계상의 실수가 시작되는 지점이기도 합니다.

질문은 보통 다음과 같이 나타납니다:

"이것을 MCP 서버로 노출해야 할까요, 아니면 에이전트가 그냥 우리의 CLI를 사용하게 해야 할까요?"

이러한 프레임은 마치 한 가지 옵션이 다른 옵션보다 더 "에이전트적(agentic)"인 것처럼 들리게 만듭니다. 저는 이것이 유용한 구분이라고 생각하지 않습니다. CLI와 MCP 서버는 서로 다른 문제를 해결합니다. 더 나은 질문은 이것입니다: 이 기능이 자연스럽게 어디에 위치하며, 에이전트가 이를 잘 사용하기 위해 어떤 계약(contract)이 필요한가?

현재 Linux Foundation 산하의 Agentic AI Foundation에서 호스팅하고 있는 MCP는 개방형 에이전트 AI 생태계에 에이전트를 도구, 데이터 및 애플리케이션에 연결하기 위한 공유 프로토콜을 제공합니다. 이러한 공유 프로토콜은 중요합니다. 팀들이 모든 에이전트 런타임(runtime)마다 동일한 통합 패턴을 다시 구축할 필요가 없어야 하기 때문입니다. 하지만 MCP가 모든 실행 파일(executable)을 서버로 감싸야 한다는 이유가 되지는 않습니다. 때로는 CLI가 정확히 적절한 인터페이스일 수 있습니다. 때로는 MCP 서버가 적절할 수도 있습니다. 종종 정답은 서로 다른 책임을 가진 두 가지 모두인 경우가 많습니다.

여기에 제가 사용하는 기준(rubric)이 있습니다.

워크플로우(workflow)부터 시작하세요

CLI는 워크플로우가 이미 인간 개발자에게 속해 있을 때 가장 강력합니다.

만약 작업이 리포지토리 로컬(repo-local)이고, 터미널 네이티브(terminal-native)이며, 개발자들이 소프트웨어를 빌드, 테스트, 디버그 또는 배포하는 방식의 일부라면, CLI부터 시작하세요. 개발자들은 이를 검사하는 방법을 알고 있습니다. CI(지속적 통합)에서 실행할 수 있습니다. 로그는 보통 눈에 보입니다. 실패 사례는 에이전트 외부에서도 재현할 수 있습니다. 동일한 인터페이스가 인간, 스크립트 및 자동화 모두에 작동합니다.

CLI 형태의 좋은 예시들:

• 프로젝트 전용 코드 생성기 (code generator) 실행
• 로컬 개발 환경에서 마이그레이션 (migration) 적용
• 린팅 (Linting), 포매팅 (formatting), 테스트 (testing) 또는 패키징 (packaging)
• 저장소 (repo) 상태 조사
• 체크아웃된 프로젝트 내부의 파일 스캐폴딩 (scaffolding)
• 표준 출력 (stdout)과 종료 코드 (exit codes)만으로 충분한 일회성 진단 실행

MCP 서버는 워크플로우가 자연스럽게 터미널 세션에 속하지 않거나, 에이전트가 명령 문자열 대신 구조화되고 발견 가능한 기능 (capability)을 필요로 할 때 가장 강력합니다.

MCP 형태의 좋은 예시들:

• SaaS API로부터 읽거나 쓰기
• 프라이빗 지식 베이스 (knowledge base) 검색
• 내부 시스템에서 타입이 지정된 레코드 (typed records) 가져오기
• 범위가 지정된 권한 부여 (scoped authorization)가 필요한 작업 수행
• 여러 에이전트 클라이언트에 걸쳐 기능 노출
• 단순한 명령 출력이 아닌 리소스 (resources)로서 컨텍스트 (context) 제공
• 에이전트에게 광범위한 셸 (shell) 액세스 대신 제한된 도구 호출 (tool calls) 세트 제공

함정은 "에이전트가 명령을 실행할 수 있다"와 "에이전트가 좋은 도구 인터페이스를 가지고 있다"를 동일한 것으로 가정하는 것입니다. 이 둘은 다릅니다.

CLI는 에이전트에게 실행할 수 있는 방법을 제공합니다. MCP는 에이전트에게 어떤 기능이 존재하는지, 어떤 입력을 받는지, 그리고 어떤 종류의 결과가 돌아오는지 이해할 수 있는 방법을 제공합니다.

다섯 가지 질문의 루브릭 (rubric)

CLI, MCP 서버, 또는 둘 다를 사용할지 결정할 때, 저는 다섯 가지 질문을 던지는 것을 좋아합니다.

1. 이것이 주로 상호작용하는 인간의 워크플로우인가?

그렇다면, CLI를 선호하십시오.

개발자에게는 여전히 에이전트가 관여하지 않을 때도 작동하는 도구가 필요합니다. 만약 인간이 저장소 내에 앉아 로그를 읽고, 플래그 (flags)를 조정하며, 재시도하는 과정에서 해당 도구를 실행하는 것이 합리적이라면, CLI가 보통 적절한 기본 인터페이스입니다.

그것이 에이전트 (agents)가 이를 사용할 수 없다는 의미는 아닙니다. 명령어가 문서화되어 있고 출력이 예측 가능하다면, 에이전트는 기존의 개발자 워크플로 (workflows)를 실행하는 데 매우 능숙합니다. 바로 이 지점에서 AGENTS.md가 자연스럽게 쓰임새를 찾습니다. 어떤 명령어가 안전한지, 테스트를 어떻게 실행하는지, 어떤 디렉토리가 접근 금지 구역인지, 그리고 어떤 실패 모드 (failure modes)가 예상되는지를 문서화하는 것입니다.

CLI는 가장 좋은 의미에서 '지루해야' 합니다:

• 명확한 서브커맨드 (subcommands)
• 안정적인 플래그 (flags)
• 유용한 경우 기계가 읽을 수 있는 출력 (machine-readable output)
• 실패 시 0이 아닌 종료 코드 (non-zero exit codes)
• 위험한 동작을 위한 드라이 런 (dry-run) 모드
• 훌륭한 도움말 텍스트 (help text)
• 자동화 경로 내에 숨겨진 대화형 프롬프트 (interactive prompts) 없음

만약 도구가 실행 도중 인간의 판단을 필요로 한다면, 그 상호작용을 CLI에 남겨두어야 합니다. 이를 MCP 도구 뒤에 숨기고 워크플로가 자율화된 것처럼 가장하지 마십시오.

2. 에이전트가 해당 기능을 스스로 발견(discover)해야 합니까?

그렇다면, MCP 쪽으로 기울어야 합니다.

MCP의 진정한 장점 중 하나는 도구를 에이전트에게 '도구'로서 설명할 수 있다는 점입니다. 에이전트는 README, 셸 히스토리 (shell history), 또는 암묵적인 지식 (tribal knowledge)으로부터 모든 것을 추론할 필요가 없습니다. 사용 가능한 도구 이름, 설명, 스키마 (schemas), 그리고 예상되는 입력을 직접 볼 수 있습니다.

이는 해당 기능이 여러 에이전트나 여러 팀 간에 재사용되도록 설계되었을 때 매우 중요합니다.

CLI도 잘 문서화될 수 있지만, 발견 (discovery) 과정은 여전히 간접적입니다. 에이전트는 명령어가 존재한다는 것을 알아야 하고, 어디에 설치되어 있는지, 어떻게 호출하는지, 그리고 출력을 어떻게 해석해야 하는지를 알아야 합니다. MCP는 해당 기능을 에이전트의 도구 표면 (tool surface)의 일부로 만듭니다.

에이전트가 다음과 같은 질문에 답할 수 있어야 할 때는 MCP를 사용하십시오:

• 나에게 사용 가능한 도구는 무엇인가?
• 이 동작에는 어떤 인자 (arguments)가 필요한가?
• 내가 조사할 수 있는 리소스 (resources)는 무엇인가?
• 결과의 형태 (shape)는 어떠할 것인가?
• 이 환경에서 허용되는 동작은 무엇인가?

이는 가공되지 않은 CLI가 너무 많은 정보를 노출하거나, 에이전트가 인간 중심의 인터페이스를 학습하도록 강요하게 되는 API 및 내부 시스템에서 특히 유용합니다.

3. 인증 경계 (auth boundary)는 어디에 있습니까?

만약 동작이 권한 경계 (authorization boundary)를 넘나든다면, MCP 도입을 신중하게 고려하십시오.

CLI는 종종 개발자의 로컬 환경(shell credentials, 설정 파일, 토큰, SSH 에이전트, 클라우드 프로필 등)을 그대로 상속받습니다. 이는 로컬 워크플로우에는 적합할 수 있지만, 에이전트(agent)의 접근 권한 측면에서는 범위가 너무 넓을 수 있습니다.

MCP는 팀에게 권한 경계를 정의할 수 있는 더 깔끔한 장소를 제공합니다. 서버는 에이전트가 가져야 할 작업(operations)만을 노출할 수 있습니다. 서버 측에서 자격 증명(credentials)의 범위를 제한할 수 있으며, 하위 시스템에 접근하기 전에 입력을 검증할 수 있습니다. 또한 임의의 셸 실행(shell execution)보다 검토하기 쉬운 방식으로 도구 호출(tool calls)을 기록할 수 있습니다.

그렇다고 해서 MCP가 마법처럼 안전해지는 것은 아닙니다. 잘못 설계된 MCP 서버는 여전히 위험할 수 있습니다. 하지만 서버 경계(server boundary)는 정책을 강제할 수 있는 지점을 제공합니다.

다음 질문을 던져보십시오:

• 에이전트가 사용자의 전체 셸 환경을 상속받아야 하는가?
• 이 동작이 위임된(delegated) 또는 범위가 제한된(scoped) 자격 증명을 사용해야 하는가?
• 도구별 권한 부여(per-tool authorization)가 필요한가?
• 에이전트 동작에 대한 감사 로그(audit logs)가 필요한가?
• 임의의 명령 조합(arbitrary command composition)을 방지해야 하는가?

이 질문들에 대한 답변이 '예'라면, CLI만으로는 너무 투박할 수 있습니다.

프로덕션 환경을 대상으로 하는 시스템의 경우, agentgateway와 같은 인프라 프로젝트가 관련성을 갖게 되는 지점이기도 합니다. 에이전트 트래픽이 MCP 서버, API, 모델 및 서비스에 걸쳐 확장되면, 팀은 일관된 정책, 라우팅 및 관측성(observability)이 필요합니다. 이는 개별 도구 결정과는 다른 계층이지만, 설계 선택 사항들은 서로 연결되어 있습니다.

4. 동작이 상태 유지(stateful) 방식입니까?

상태 변경(state changes)은 요구 사항의 수준을 높입니다.

읽기 전용 진단 명령은 별개의 문제입니다. 티켓을 생성하거나, 서비스를 배포하거나, 고객 데이터를 업데이트하거나, 비밀값(secrets)을 교체하거나, 인프라를 변경하는 도구는 차원이 다릅니다.

상태를 변경하는 동작의 경우, 인터페이스는 해당 동작을 오용하기 어렵게 만들어야 합니다. 이는 CLI, MCP 서버, 또는 둘 다에서 수행될 수 있습니다. 핵심은 어떤 인터페이스가 더 나은 제어 표면(control surface)을 제공하느냐 하는 것입니다.

상태 변경이 개발자가 제어하는 워크플로우에 속하는 경우라면 CLI가 적절할 수 있습니다:

• 이 마이그레이션을 내 로컬 데이터베이스에 적용하기
• 내 브랜치에 이 파일 생성하기
• 테스트 통과 후 릴리스 아티팩트 (release artifact) 생성하기

상태 변경이 외부 시스템에 영향을 미치는 경우라면 MCP 서버가 적절할 수 있습니다:

• 인시던트 (incident) 생성하기
• CRM 레코드 업데이트하기
• 구조화된 페이로드 (structured payload)를 포함한 풀 리퀘스트 (pull request) 열기
• 사용자에 대한 액세스 권한 부여하기
• 배포 플랫폼의 워크플로우 트리거하기

상태를 가진 (stateful) MCP 도구의 경우, 동작을 더 구체적으로 모델링할 수 있다면 run, execute, 또는 update와 같은 일반적인 동사는 피하는 것이 좋습니다. 도구는 자신이 무엇을 하는지 명시해야 합니다. 입력 스키마 (input schema)는 발생할 수 있는 일을 제한해야 합니다. 응답에는 에이전트 (agent)가 결과를 확인할 수 있을 만큼 충분한 구조화된 데이터가 포함되어야 합니다.

상태를 가진 (stateful) CLI의 경우, 드라이 런 (dry-run) 지원, 명시적인 자동화 모드에서만 비활성화할 수 있는 확인 제어 (confirmation controls), 그리고 무엇이 변경되었는지 명확하게 보여주는 출력을 원합니다.

공통된 원칙은 동일합니다: 에이전트가 추측하게 해서는 안 됩니다.

5. 유지보수 비용은 얼마인가?

모든 새로운 인터페이스는 하나의 제품 접점 (product surface)이 됩니다.

CLI는 패키징, 버전 관리, 문서, 도움말 텍스트, 예시, 그리고 호환성 보장이 필요합니다. MCP 서버는 이 모든 것에 더해 서버 생명주기 (lifecycle), 전송 (transport) 결정, 스키마 설계, 클라이언트 호환성, 인증, 배포, 모니터링, 그리고 운영 책임까지 필요합니다.

그 비용을 지불할 가치가 있을 수도 있습니다. 하지만 반드시 실질적인 무언가를 얻어야 합니다.

CLI를 감싸는 MCP 래퍼 (wrapper)는 다음과 같은 요소를 추가할 때 유용할 수 있습니다:

• 더 나은 도구 설명
• 더 안전한 입력 유효성 검사 (input validation)
• 구조화된 출력 (structured outputs)
• 범위가 지정된 권한 (scoped permissions)
• 에이전트 클라이언트 간의 공유된 액세스
• 복잡한 하위 명령에 대한 안정적인 추상화 (abstraction)
• CLI가 제대로 제공하지 못하는 리소스 액세스

반면, 단순히 기존 명령어를 셸 (shell)로 호출하고 에이전트가 어차피 보았을 것과 동일한 텍스트 출력을 반환하기만 한다면, MCP 래퍼는 아마도 그만한 가치가 없을 것입니다.

이것이 “CLI를 절대 래핑하지 마라”는 뜻은 아닙니다. 래퍼(wrapper)는 레버리지(leverage, 지렛대 효과)를 만들어내야 한다는 의미입니다. 만약 MCP 서버가 단순히 동일한 명령어로 가는 더 얇고 디버깅하기 어려운 경로에 불과하다면, CLI를 유지하고 이를 잘 문서화하십시오.

“둘 다(both)” 패턴

많은 팀이 두 가지를 모두 구축해야 하지만, 중복된 형태로 만들어서는 안 됩니다.

좋은 패턴은 다음과 같습니다:

• CLI는 인간과 CI(지속적 통합) 인터페이스로 남습니다.
• MCP 서버는 에이전트(agent)를 위해 선택된 기능(capabilities)을 노출합니다.
• 공유된 핵심 로직(core logic)은 두 인터페이스 아래에 존재합니다.
• MCP 서버가 모든 CLI 명령어를 쏟아붓는 쓰레기통이 되어서는 안 됩니다.
• CLI가 안전하지 않은 에이전트 동작을 위한 탈출구(escape hatch)가 되어서는 안 됩니다.

예를 들어, 내부 배포 도구를 상상해 보십시오.

CLI는 빌드, 검증, 미리보기, 배포, 롤백, 로그 조사, 로컬 체크 실행 등 전체 개발자 워크플로우(workflow)를 지원할 수 있습니다. 이는 사용자가 저장소(repo) 접근 권한과 배포 권한을 가진 개발자임을 가정합니다.

MCP 서버는 더 좁은 범위의 도구를 노출할 수 있습니다: 배포 상태 가져오기, 서비스 목록 나열, 미리보기 환경 생성, 롤백 계획 요청, 또는 특정 서비스의 로그 가져오기 등입니다. 이러한 도구들은 더 엄격한 스키마(schema)와 더 안전한 기본값(defaults)을 가질 수 있습니다. 또한 에이전트가 터미널 출력을 파싱(parsing)할 필요 없이 추론할 수 있는 구조화된 데이터(structured data)를 반환할 수 있습니다.

두 인터페이스 모두 동일한 기반 배포 라이브러리를 호출할 수 있습니다. 하지만 동일한 노출 영역(surface area)을 가질 필요는 없습니다.

그러한 분리는 건강합니다. 인간에게는 강력한 도구(power tools)가 필요합니다. 에이전트에게는 명확한 계약(contracts)이 있는 제약된 기능(constrained capabilities)이 필요합니다.

실질적인 결정 가이드

다음과 같은 경우에는 CLI를 사용하십시오:

• 작업이 저장소 로컬(repo-local)이거나 터미널 네이티브(terminal-native)인 경우
• 인간이 직접 실행해야 하는 경우
• CI가 동일한 인터페이스를 실행해야 하는 경우
• 셸 조합(shell composition)이 기능인 경우
• 텍스트 출력과 종료 코드(exit codes)만으로 충분한 경우
• 인증 모델(auth model)이 이미 로컬 개발자 컨텍스트에 적합한 경우

다음과 같은 경우에는 MCP 서버를 사용하십시오: