MCP를 붙이면 뭔가 프로페셔널해 보인다.
셸 스크립트는 좀 투박해 보인다.
근데 운영은 보통 반대로 굴러간다.
투박한 셸이 충분한 문제에 MCP를 얹으면 복잡도가 늘고, 반대로 구조화가 필요한 문제에 셸만 쓰면 나중에 유지보수가 지옥이 된다.
핵심만 먼저 잡으면, 외부 상태가 적고 재현이 쉬우면 script, 도구 인터페이스와 재사용성이 중요하면 MCP다.
이 글이 필요한 사람
- 사내 CLI, API, 리포트, 승인 흐름을 Claude Code에 붙이고 싶은 사람
- 내부 도구를 에이전트용으로 정리할지 셸로 끝낼지 고민하는 사람
- 팀이 커질수록 “누가 이걸 운영하지?”가 먼저 떠오르는 사람
- 새 도구를 만들기 전에 유지보수비를 계산하고 싶은 사람
지금 결론
도구 연결은 기능 문제가 아니라 운영 문제다.
MCP는 구조화, 재사용성, 표준화에 좋다.
셸 스크립트는 단순성, 투명성, 빠른 수정에 좋다.
그래서 이 선택은 “어떤 게 더 멋져 보이냐”가 아니라 “어떤 문제가 더 오래 남냐”로 결정해야 한다.
비교표
| 항목 | MCP | 셸 스크립트 |
|---|---|---|
| 시작 난이도 | 높음 | 낮음 |
| 디버깅 | 구조화되면 좋지만 초기엔 낯섦 | 바로 실행해보기 쉬움 |
| 재사용성 | 높음 | 중간 |
| 표준화 | 좋음 | 스크립트 품질에 따라 편차 큼 |
| 배포 부담 | 서버/패키지/버전관리 필요 가능 | 파일 하나로도 시작 가능 |
| 권한 경계 | 도구별로 설계 가능 | 쉘 실행 권한이 넓어질 수 있음 |
| 실패 지점 | 스키마/연결/호환성 | 인자 quoting/경로/환경변수 |
셸이면 충분한 경우
1. 한 프로젝트에서만 쓰는 도구
한 저장소에서만 쓰고, 한두 명만 운영한다면 셸이 더 낫다.
복잡한 서버 하나 세우는 것보다, 잘 만든 shell script 하나가 더 빠르다.
2. 입력과 출력이 단순한 경우
예를 들면:
- lint 돌리기
- 로그 모으기
- 리포트 파일 생성
- 특정 API 한 번 호출하기
이런 건 셸이 대체로 충분하다.
3. 실패 원인을 바로 보고 싶을 때
셸은 echo, set -x, exit code만 잘 써도 원인 추적이 쉽다.
운영 초반에는 이 투명성이 꽤 중요하다.
4. 팀이 아직 작고 규칙이 자주 바뀔 때
규칙이 자주 바뀌면 구조화된 시스템보다 스크립트가 유리하다.
왜냐면 수정 비용이 낮기 때문이다.
MCP가 필요한 경우
1. 여러 에이전트가 같은 도구를 반복 사용할 때
Claude Code, Codex, 다른 에이전트가 같은 내부 도구를 공유하면 MCP가 빛난다.
도구 설명, 입력 스키마, 기대 출력이 정리되면 재사용이 쉬워진다.
2. 입력 구조가 복잡할 때
JSON, schema, typed fields, multi-step response처럼 구조가 필요한 경우는 MCP가 낫다.
셸에서 억지로 붙이면 결국 파서 지옥이 온다.
3. 권한과 역할을 분리하고 싶을 때
도구별로 어느 기능만 쓸 수 있는지 나누고 싶다면 MCP가 더 맞다.
4. 나중에 팀 표준으로 굳힐 가능성이 있을 때
한 번 만든 도구를 여러 repo와 팀에 공유할 생각이 있으면 MCP가 장기적으로 편하다.
판단 기준 5가지
1. 재사용성이 높은가
같은 도구를 3번 이상 재사용할 생각이 있으면 구조화 쪽으로 가도 된다.
2. 도구 입력이 복잡한가
입력이 늘어나고 타입이 많아지면 셸보다 MCP가 낫다.
3. 디버깅 비용이 더 중요한가
지금은 셸이 더 빨라도, 나중에 문제 추적이 어려우면 운영비가 더 든다.
4. 보안 경계가 필요한가
도구마다 읽기/쓰기 권한을 분리하고 싶으면 MCP 설계가 유리하다.
5. 팀 밖으로 배포할 가능성이 있는가
배포 가능성이 있으면 처음부터 인터페이스를 정리해두는 게 낫다.
실전 예시
예시 1. 리포지토리 정리 도구
README 갱신, changelog 생성, 특정 폴더 스캔은 셸이 충분하다.
이유는 단순하다.
- 한 번에 끝난다
- 로컬에서 바로 확인된다
- 버전 호환이 적다
예시 2. 사내 승인 API 연결
승인 흐름, 여러 시스템 참조, 고정된 응답 구조가 필요하면 MCP가 더 맞다.
이유는 입력/출력 계약이 중요하기 때문이다.
예시 3. 대시보드용 집계 작업
간단한 수집은 셸, 반복적 집계와 표준 출력은 MCP가 더 낫다.
운영하는 사람이 계속 바뀐다면 더더욱 그렇다.
실수 TOP
1. 멋있어 보여서 MCP부터 붙이는 실수
처음부터 구조화하면 좋아 보이지만, 작은 문제에 과한 설계가 될 수 있다.
2. 셸로 시작했는데 파서가 비대해지는 실수
셸이 점점 JSON parser가 되면 그때는 MCP를 다시 봐야 한다.
3. 권한 경계를 안 나누는 실수
도구가 많아질수록 어떤 게 읽기 전용인지, 어떤 게 쓰기인지 먼저 나눠야 한다.
4. 버전관리 없이 내부 도구를 배포하는 실수
팀 도구는 한 번 퍼지면 회수하기 어렵다.
5. 디버깅 로그를 안 남기는 실수
어떤 방식이든 실패 원인을 볼 수 있어야 한다.
6. 외부 의존성이 많은데 로컬 스크립트처럼 다루는 실수
네트워크, 인증, timeout이 많아지면 셸은 금방 지저분해진다.
언제 과한가
- 도구가 1~2개뿐일 때
- 입력 구조가 단순할 때
- 팀이 아직 실험 단계일 때
- 실패 원인을 눈으로 바로 봐야 할 때
이 경우는 MCP보다 셸이 낫다.
이럴 땐 안 써도 된다
- 일회성 자동화
- repo 내부에서만 쓰는 단순 작업
- 파싱할 구조가 거의 없는 경우
- 운영 인력이 없는 경우
도구화가 목적이 아니라 작업 해결이 목적이면 셸이 더 낫다.
FAQ
Q1. MCP가 무조건 더 좋은가?
아니다.
더 좋은 게 아니라 더 구조화된 방식일 뿐이다.
Q2. 셸 스크립트는 구식 아닌가?
구식이 아니라 단순 작업에 강한 방식이다.
Q3. 둘을 같이 써도 되나?
된다.
오히려 자주 그렇게 간다.
셸은 glue, MCP는 interface로 두는 식이 자연스럽다.
Q4. 언제 셸에서 MCP로 옮겨야 하나?
반복 재사용, 복잡한 입력, 팀 표준화가 보이기 시작할 때다.
Q5. 반대로 언제 MCP를 셸로 내려야 하나?
사용 빈도가 낮아지고 구조가 너무 무거워질 때다.
다음에 읽을 글
- Claude Code hooks 보안 2026 — 자동 실행이 편할수록 왜 시크릿과 권한 경계부터 봐야 할까
- AI 코딩 에이전트 오케스트레이터가 필요한 순간 2026 — Claude Code·Codex·Copilot을 한 데 묶기 전 체크할 5가지
- 메타 에이전트가 환경을 고치게 하면 뭐가 달라질까 2026 — AutoAgent가 보여준 프롬프트보다 실행환경이 중요한 이유