MCP를 셸(Shell)로 사용하기——깨달음과 가능성 그리고 복잡한 마음

발단

Mac의 Claude Desktop(Cowork)에서 Windows의 WSL2를 MCP를 통해 조작할 수 있도록 설정했다.

상세한 절차는 이전 기사에 정리해 두었다.

이 설정을 하고 나서 깨달은 점이, 절차 그 자체보다 더 흥미로웠다.

Claude Code는 셸로서 MCP에 연결되어 있다

"WSL에서 Docker를 재시작해줘"라고 지시했을 때, 내부에서는 다음과 같이 동작한다:

각 MCP 호출 시 실행되는 Claude Code는 명령어를 실행하고 결과를 반환할 뿐인 존재다. 서로를 알지 못하며 문맥(Context)도 가지고 있지 않다. 지시를 분해하고, 결과를 정리하며, 다음 조작을 판단하고, 최종적으로 보고하는 것은 Cowork 측의 Claude뿐이다.

즉, 이 구성에서 Claude Code는 AI로서 판단하지 않는다. 셸(Shell)로서 동작하고 있다.

이 구조를 이해하면 "mcpsh"라는 개념이 보인다. 경량 MCP 서버가 셸로서 움직이고, 상위 AI가 지휘자로서 판단한다——이번 Claude Code(mcp serve)는 그 선구적인 형태다.

같은 Mac 내에서도 Docker 컨테이너에 액세스할 수 있다

WSL로의 MCP 연결을 설정한 후에 깨달은 것이 있다. 같은 Mac 내에서도 MCP를 사용하면 Docker 컨테이너 안까지 액세스할 수 있다.

"DB 내용을 확인해서 문제가 없는지 봐줘"라는 지시로:

docker compose exec db psql -U appuser -d appdb -c "SELECT * FROM users;"
docker compose exec db psql -U appuser -d appdb -c "SELECT * FROM devices;"
docker compose exec db psql -U appuser -d appdb -c "SELECT * FROM subscriptions;"

이것들을 실행하고 결과를 확인하여 "subscriptions에 1건의 NULL이 남아 있는 것은 SNS의 Endpoint 생성이 실패한 흔적"과 같은 평가까지 되돌려준다.

주의해야 할 점

편리한 반면, 주의가 필요한 점도 있다.

CLAUDE.md의 규칙이 적용되지 않는 경우가 있다

패턴 A(프로젝트 고유의 CLAUDE.md만 있는 경우)에서는 CLAUDE.md가 읽히지 않는다. 일반적인 대화 흐름 속에서 MCP로의 요청이 실행되어 버릴 가능성도 있다.

대책으로서 $HOME/CLAUDE.md에 작성해 두면 확인을 요청하게 된다:

## MCP 조작 확인
mcp를 통한 작업으로 판단되는 경우에는, 어떤 mcp에 요청할지 반드시 확인할 것.

보안상의 경계가 모호해진다

패턴 A(.env 등이 포함된 디렉토리)에도 액세스할 수 있게 된다. 프로젝트마다 개별 MCP를 등록하는 패턴 B가 액세스 범위를 한정할 수 있다.

Anthropic의 서버를 경유한다

"무엇을 실행할 것인가"에 대한 판단은 Anthropic의 서버를 통한다. 실제 명령어 실행은 Mac→WSL 간의 로컬에서 완결되지만, .env의 내용 등을 Claude에게 읽게 할 때는 주의가 필요하다.

활용 방식의 현실

이 설정을 한 이후로, Windows App을 사용하여 WSL2에 들어가는 기회가 대폭 줄었다.

방법	적합한 상황
MCP 경유 (Cowork)	일본어로 지시하고 Claude에게 맡기고 싶을 때, Mac 측의 작업과 조합하고 싶을 때
...

부수적인 효과로 Mac의 터미널에서 SSH를 통해 WSL2에 직접 들어갈 수도 있게 되었다. Windows App의 원격 데스크톱과 비교했을 때 키보드 동작이 Mac 그대로 유지되어 사용하기 편하고, 일본어 입력 전환도 쉬우며, 화면 지연(Latency)도 없다.

복잡한 마음

편리한 것은 틀림없다. "WSL에서 Docker를 재시작해줘"라는 한마디로 동작한다. PostgreSQL의 내용을 확인하고 평가도 해준다. Docker 명령어의 옵션을 외우지 않아도 된다.

하지만, 그것이 문제가 되기도 한다.

Docker 명령어를 직접 입력하고, 에러를 마주하고, 로그를 읽고, 수정하는——그러한 경험이 옅어져 간다. "할 수 있다"와 "알고 있다"는 별개의 문제이며, AI에게 맡김으로써 전차(할 수 있음)만 남고 후자(알고 있음)는 자라나지 않을 가능성이 있다.

"Docker로 다른 무엇을 할 수 있는지"를 알기 위해서는 어느 정도 스스로 만져본 경험이 필요하다. 지식의 창고(引き出し)가 없다면 AI에 대한 지시의 질이 떨어질 것이고, AI의 제안이 옳은지 판단할 수도 없게 된다.

현재의 스탠스로는 「개념을 이해한 상태에서 맡긴다」를 의식하고 싶다. 커맨드(Command)의 세세한 옵션을 암기할 필요는 없지만, 「무엇을 하고 있는지」는 파악해 둔다. AI가 「이것이 정답입니다」라고 말하더라도, 그것이 자신의 프로젝트에 맞는지 여부는 경험을 통해서만 판단할 수 있다.

빌드 에러(Build Error)의 확인·수정까지 완결시키기

WSL 측의 MCP가 연결되어 있다면, Docker의 빌드 에러(Build Error)를 보면서 수정하고 재빌드(Rebuild)까지 단번에 진행할 수 있다.

1. WSL 측에서 docker compose up --build 실행 (MCP 경유)
2. 빌드 에러(Build Error) 로그를 Cowork에서 확인
3. Mac 측의 파일을 수정 (Read/Edit 툴)
...

단, Mac과 WSL에서 파일이 별도로 관리되기 때문에, Mac에서 수정 → push → WSL에서 pull이라는 번거로움이 발생한다.

Mac 측의 Claude Code도 MCP로 연결하면 번거로움이 없어진다

Mac 측의 Claude Code도 마찬가지로 MCP로 연결하면, Mac 내부에서 완결할 수 있다.

claude_desktop_config.json에 아래 내용을 추가하기만 하면 된다:

"mac_claude_code": {
"command": "/Users/okamoto/.local/bin/claude",
"args": ["mcp", "serve"]
...

이렇게 하면 Mac의 Docker 빌드 에러(Build Error)도 Cowork에서 직접 확인할 수 있으며, 파일 수정 → 재빌드(Rebuild)까지 git push/pull 없이 완결된다.

「빌드 에러(Build Error)를 보면서 수정하여 최종 결과물을 내는」 작업을 Cowork로부터 일괄적으로 맡길 수 있다.

요약

MCP는 셸(Shell)로서 기능한다. Cowork가 지휘자로서 판단하고, Claude Code (mcp serve)가 실행 엔진(Execution Engine)으로서 움직인다. 이 구조를 이해하면 「무엇을 맡길 수 있는지」, 「무엇을 스스로 판단해야 하는지」가 보인다.

설정 자체는 심플하며, SSH 키 준비와 claude_desktop_config.json에 몇 줄 추가하는 것뿐이다. 가장 막히는 부분은 패스프레이즈(Passphrase) 없는 전용 키를 만드는 것인데, 그것만 알면 작동한다.

편리한 도구를 갖게 되었기에, 어떻게 사용할지에 대한 판단은 인간의 업무로 계속 남게 된다.