MCP vs API vs CLI: 에이전트를 위한 3가지 방식 구축 경험 공유

TL;DR:

MCP가 에이전트 중심 세상에서 빛을 발하는 이유는 서버와 클라이언트(예: Claude Code나 ChatGPT 데스크톱 앱) 양쪽에서 에이전트가 뭘 해야 할지 명확히 알려주기 때문임. 특히 사람이 개입하는 작업(human-in-the-loop)에 훨씬 적합함. 반면 API나 CLI는 주로 서버 측에 치중해서 에이전트가 '무엇을 할 수 있는지'에만 초점을 맞추는 경향이 있음.

그래서 에이전트에게 어떤 도구를 쥐여줄지 고민하는 개발자들을 위해 내 생각을 정리해 봄:

운영 계층 하나를 잡고 MCP 서버와 REST API를 동시에 만드셈. 서버 로직은 그냥 일반 함수로 짜고, 각 인터페이스는 그 함수를 감싸는 얇은 어댑터 정도로만 두는 거임. 일단 이 기반만 잘 닦아두면 나중에 다른 인터페이스를 얹는 건 일도 아님.

MCP 서버에 가장 공을 들이셈. 에이전트가 가장 쾌적하게 쓸 수 있는 환경이 바로 거기니까. 애초에 MCP가 에이전트를 위해 만들어진 표준이고, 사양도 계속해서 아주 잘 발전하고 있음.

API는 독자적으로 돌아가는 코드에 쓰셈. 대량의 데이터 내보내기, 일괄 쓰기, 혹은 야간 동기화나 타사 연동처럼 에이전트 없이 돌아가는 작업에는 여전히 API가 최고임. 에이전트도 나중에 다시 실행할 스크립트를 짤 때는 API를 선호하기도 하고, 아직 많은 클라이언트가 MCP의 코드 모드를 지원하지 않기도 하니까.

CLI는 굳이 필요 없을 수도 있음. 에이전트가 앱이랑 상호작용하면서 로컬 파일을 읽어야 하는 상황 같은 게 아니라면 말이지. 그래도 탄탄한 API를 기반으로 만들어뒀다면 CLI 하나 얹는 건 식은 죽 먹기임.

웹 앱을 에이전트가 쓰기 좋게 만드는 방법은 훨씬 더 많음. 위 글에서 더 자세히 다뤘으니 참고하셈.

저장소는 여기 있음: https://github.com/vincanger/linkly-api-mcp-cli