도구 아키텍처
MCP, CLI, API는 모두 인터페이스이며 모든 상황의 승자는 없습니다
어떤 기술이 더 새롭냐가 중요한 게 아닙니다. 기능이 어디서 실행되고, 누가 발견해야 하며, 데이터를 어떻게 검증하고, 어떤 운영 비용을 감수할지를 기준으로 선택해야 합니다.
CLI: 이동하기 쉽고 관찰하기 쉽습니다
CLI는 터미널, 스크립트, CI에 자연스럽습니다. 로컬 filesystem을 직접 다룰 수 있고 보편적인 도구로 디버깅하기 쉽습니다. 다만 사람용 출력이 일관되지 않으면 각 소비자가 다시 해석해야 합니다.
qzx diagnoseProject . --jsonAPI: 명확한 네트워크 경계
기능이 이미 서비스로 존재하거나 중앙 인증이 필요하거나 많은 원격 클라이언트가 사용해야 한다면 API가 적합합니다. 대신 네트워크, 가용성, 자격 증명, 서버 운영 비용이 추가됩니다.
MCP: AI 클라이언트를 위한 발견과 계약
MCP는 호환 클라이언트가 도구와 schema를 발견하는 공통 방식을 제공합니다. 각 클라이언트와 서버 사이의 전용 통합을 줄이는 데 유용합니다.
핵심 로직을 복제하지 마세요
같은 작업을 CLI와 MCP 모두로 제공해야 한다면 핵심을 전송 방식과 분리하세요. 테스트와 의미는 공유하고 각 어댑터는 자신의 프로토콜과 UX만 처리할 수 있습니다.
자주 묻는 질문
어떤 인터페이스가 가장 단순한가요?
환경에 따라 다릅니다. 터미널에서는 CLI, 서비스 간 통신에서는 API, 호환 클라이언트가 도구를 발견해야 할 때는 MCP가 자연스럽습니다.
세 가지를 함께 사용할 수 있나요?
네. 하나의 핵심 작업을 유지하고 여러 어댑터를 통해 노출하면 핵심 로직을 중복하지 않을 수 있습니다.
구조화된 결과가 왜 중요한가요?
소프트웨어와 에이전트가 성공, 오류, 데이터, 다음 단계를 사람용 문장을 추측하지 않고 판단할 수 있기 때문입니다.