메모장과 Windows 내장 엔진으로 MCP 서버 만들기 — Node.js 없이 Claude 연동하는 법 (hackers.pub)
한줄 요약
Windows 메모장과 OS 내장 스크립트 엔진만으로 Claude와 통신하는 MCP 서버를 구현할 수 있다.
어떤 상황에서 필요한가?
MCP(Model Context Protocol)가 주목받으면서, Claude Desktop에 자체 도구를 연결하려는 수요가 빠르게 늘고 있다. 그런데 대부분의 MCP 서버 예제는 Node.js, Python, 혹은 전용 IDE 설치를 전제로 한다. 현장에서는 이게 생각보다 큰 장벽이다.
외부 패키지 설치가 정책적으로 막혀 있는 기업 환경, 고객사 PC에 개발 런타임을 올릴 수 없는 SI 프로젝트, 또는 단순히 "설치 없이 동작 검증"이 필요한 상황이 실제로 존재한다. 이런 환경에서 "메모장만으로 MCP 서버를 작성할 수 있는가"라는 질문은 단순한 도발이 아니라 현실적인 요구사항에서 출발한 실험이다.
핵심은 Windows에 기본 내장된 cscript 엔진이다. 이 엔진은 별도 설치 없이 Windows에서 JScript(ES3 기반 JavaScript)를 실행할 수 있다. WelsonJS 프레임워크는 바로 이 엔진 위에서 동작하는 라이브러리 생태계를 갖추고 있으며, 이번 구현의 실행 기반이 된다.
핵심 구현 방법
MCP 프로토콜의 구조는 의외로 단순하다. Claude Desktop 같은 MCP 클라이언트가 지원하는 주요 통신 방식은 표준입출력(stdio) 위에서 JSON-RPC 2.0 규격으로 메시지를 주고받는 것이다. 정리하면 이렇다.
요청: MCP Client → Stdin (JSON-RPC 2.0 request) → MCP Server
응답: MCP Client ← Stdout (JSON-RPC 2.0 response) ← MCP Server
이 두 가지 조건만 충족하면 어떤 런타임으로도 MCP 서버를 만들 수 있다. Node.js가 필수가 아니라는 뜻이다.
구현 흐름을 보면, WelsonJS의 StdioServer와 JsonRpc2 라이브러리를 활용해 mcploader.js 파일 하나를 작성한다. 이 파일은 initialize, tools/list, tools/call 세 가지 메서드를 처리한다. 예제에서 제공하는 도구는 두 가지다.
add_both_numbers: 숫자 두 개를 받아 합산 결과를 반환evaluate_js_es3: ES3 문법의 JavaScript 코드를 받아 실행하고 결과를 반환
Claude Desktop에 등록하는 방법도 간단하다. claude_desktop_config.json에 아래처럼 추가하면 된다.
{
"mcpServers": {
"local-tools": {
"command": "cscript",
"args": [
"/nologo",
"<WelsonJS 설치 경로>/app.js",
"mcploader",
"/quiet"
]
}
}
}
cscript는 Windows 내장 명령이므로 별도 설치가 필요 없다. 설정 후 Claude Desktop을 재시작하고 개발자 메뉴에서 local-tools가 running 상태인지 확인하면 된다.
실전에서 주의할 점
stdio 채널 오염 문제가 가장 흔한 함정이다. 표준출력(stdout)은 MCP 통신 전용 채널이어야 하는데, 프로그램 실행 중 발생하는 디버그 메시지나 로그가 섞이면 JSON-RPC 파싱이 깨진다. 이 구현에서는 /quiet 옵션으로 부가 메시지를 억제하는 방식으로 해결하고 있다. 자체 MCP 서버를 만들 때도 stdout에는 JSON-RPC 응답만, 진단 메시지는 반드시 stderr로 분리해야 한다.
ES3 제약도 염두에 둬야 한다. cscript의 JScript 엔진은 현대 JavaScript와 다르다. let, const, 화살표 함수, Promise, async/await 같은 문법은 사용할 수 없다. evaluate_js_es3 도구 이름에 "ES3"이 붙은 이유가 여기에 있다. 이 도구로 최신 JS 문법을 실행하려 하면 에러가 반환된다.
notifications/initialized 처리도 빠뜨리기 쉽다. 이 메서드는 클라이언트가 보내는 단방향 알림이라 응답을 반환하지 않아야 한다. 코드에서 return false로 처리하고 있는 이유다. 응답을 돌려보내면 프로토콜 오류가 발생할 수 있다.
보안 관점에서는 evaluate_js_es3처럼 임의 코드를 실행하는 도구를 실제 서비스에 노출할 때 신중해야 한다. 이 예제는 기능 검증용으로 적합하지만, 프로덕션에서는 실행 가능한 코드의 범위를 엄격히 제한하는 설계가 필요하다.
이 접근법의 진짜 가치는 "환경 제약이 심한 곳에서도 AI 도구 통합이 가능하다"는 점을 증명했다는 데 있다. MCP 프로토콜이 특정 언어나 런타임에 종속되지 않는 개방적 설계를 갖고 있다는 걸 이 실험이 잘 보여준다.
자주 묻는 질문
Q.cscript가 없는 환경이나 macOS/Linux에서도 같은 방식을 쓸 수 있나?
cscript는 Windows 전용이므로 macOS나 Linux에서는 동작하지 않는다. 다만 아이디어 자체, 즉 OS 내장 런타임으로 stdio 기반 JSON-RPC 서버를 만든다는 접근은 다른 환경에서도 적용 가능하다. macOS나 Linux에는 bash, Python, Perl 등이 기본 탑재돼 있어 같은 원리로 MCP 서버를 구현할 수 있다. 핵심은 특정 도구가 아니라 "stdio + JSON-RPC 2.0"이라는 프로토콜 구조다.
Q.WelsonJS 없이 순수 cscript만으로 MCP 서버를 만들 수도 있나?
가능하다. WelsonJS는 `StdioServer`와 `JsonRpc2` 같은 편의 라이브러리를 제공할 뿐, cscript 자체가 stdin/stdout 처리와 JSON 파싱을 지원한다. 다만 WelsonJS 없이 구현하려면 JSON 직렬화, 줄 단위 stdin 읽기, 에러 처리 등을 직접 구현해야 해서 코드량이 상당히 늘어난다. 빠른 검증 목적이라면 WelsonJS를 활용하는 편이 현실적이다.
Q.이 방식으로 만든 MCP 서버의 성능 한계는 어느 정도인가?
cscript 기반 구현은 경량 작업의 로컬 도구 통합에 적합하다. 단순 계산, 파일 읽기, 레지스트리 접근, COM 객체 활용 같은 용도에서는 충분히 실용적이다. 다만 높은 동시성이 필요하거나 대용량 데이터를 처리하는 시나리오에는 맞지 않는다. MCP stdio 방식 자체가 요청-응답을 순차 처리하는 구조이므로, 이 제약은 cscript만의 문제가 아니라 stdio 기반 MCP 서버 전반의 특성이기도 하다.