Antigravity에 TaskMaster MCP 서버 연결 삽질기
최근 구글에서 에이전트 중심 IDE인 Antigravity를 출시했습니다. 마침 cursor 에이전트가 limit이 걸려있던 참이라 바로 설치해보았습니다. AI는 MCP가 있어야 성능을 최대로 끌어낼 수 있다고 생각하기 때문에 처음으로 한 일은 MCP를 설정하는 것 이었습니다.
Antigravity는 신기하게도 내부에 MCP Store가 있어서 Smithery처럼 원클릭으로 간편하게 설치가 가능했습니다. 하지만 아직 베타버전이라 그런지 종류는 많이 없어서 제가 사용하고 있는 MCP 대부분은 직접 설정을 해주어야 했습니다. 그 과정에서 겪은 두가지 오류와 해결과정을 정리합니다.
문제 1: Error: exec: “npx”: executable file not found in $PATH.
MCP 설정 파일에 직접 json으로 추가하고 나서 첫 번째 에러가 발생하였습니다.

Error: exec: "npx": executable file not found in $PATH원인 추정: asdf 삭제의 나비효과
npx 경로를 찾지 못하는 에러 였는데, 원인은 기존에 사용하던 Node 버전 관리 도구인 asdf를 삭제하고 fnm으로 갈아타면서 PATH가 꼬인 것으로 추정되었습니다. 터미널에서 npx는 잘 동작했지만 IDE는 Node가 어디에 있는지 모르는 상태가 되었습니다.
해결 과정
첫번 째 시도: 절대경로로 설정하기
먼저 시도한 방법은 절대 경로를 넣어 MCP가 실행이 되는지 확인 하는 것 이었습니다. 실행이 된다면 MCP 설정 방법은 문제가 없다는 뜻이기 때문입니다.
which npx그래서 which 명령어를 사용하여 npx의 위치는 찾아내고
{ "mcpServers": { "task-master-ai": { "command": "/User/.../npx", // which로 찾은 절대경로 입력 "args": ["-y", "task-master-ai"] } }}command에 절대 경로를 입력한 후 확인 하니 PATH 오류는 수정되었습니다. 하지만 절대 경로를 사용하면 Node버전이 변경 될 때마다 설정 파일을 수정해야 할 수도 있습니다.
두번 째 시도: 시스템 심볼릭 링크 연결
command에 npx만 적어두고 싶은 마음이 생겼습니다. 이를 위해서 IDE가 보통 기본적으로 탐색하는 표준 경로(/opt/homebrew/bin)에 fnm Node위치를 연결했습니다.
which node
# 시스템 표준 경로에 심볼릭 링크 생성sudo ln -s $(which node) /opt/homebrew/bin/node이렇게 심볼릭 링크 연결을 통해서 command에 다시 npx만 작성하여 MCP를 실행되게 할 수 있었습니다.
그렇게 PATH문제는 해결했지만…
문제 2: Error: calling “initialize”: EOF
더 난해한 에러가 나타나게 되었습니다.
Error: calling "initialize": EOFEOF에러가 나면서 연결이 맺어지기도 전에 MCP가 픽 죽어버렸습니다.
원인 추정: 터미널에서 직접 실행해보기
IDE 로그만으로는 원인을 알 수 없어, 터미널에서 직접 서버를 실행해 보았습니다.
# 터미널에서 실행을 위해 글로벌 설치npm install -g task-master-ai
# 터미널에서 직접 실행 (API 키를 붙여서 실행)export GOOGLE_API_KEY="AIz..."npx -y task-master-ai실행 결과, 정상적으로 동작하며 터미널에 아래와 같은 로그가 출력되었습니다.

터미널에서는 정상 동작함으로써 유추할 수 있는 원인이 있었습니다.
MCP 프로토콜은 클라이언트(IDE)와 서버가 오직 JSON 포맷으로만 대화해야 합니다.
그런데 taskmaster는 실행되자마자 [INFO]… 같은 일반 텍스트 로그(Plain Text)를 표준 출력(stdout)에 노출하고 있었습니다.
사람 눈에는 친절한 정보였지만, JSON만 기다리던 기계(IDE)에게는 해석할 수 없는 데이터였고, 결국 프로토콜 위반으로 연결을 끊어버린 것(EOF)으로 추정하였습니다.
해결 방안: 로그 필터링 미들웨어 만들기
그래서 텍스트 로그는 버리고 JSON만 통과시켜보기로 하였습니다.
우선, Node.js의 spawn을 이용해 실제 서버를 실행하되, stdout을 가로채서 필터링하는 스크립트를 생성해야합니다.
const { spawn } = require('child_process');// 실제 실행할 패키지 경로 (which task-master-ai 로 확인)const EXECUTABLE_PATH = '/.../bin/task-master-ai';
const proc = spawn(process.execPath, [EXECUTABLE_PATH], { env: process.env, stdio: ['inherit', 'pipe', 'inherit'], // stdout 가로채기});
proc.stdout.on('data', (data) => { const output = data.toString();
output.split('\n').forEach((line) => { if (!line.trim()) return;
// JSON 형식('{')인 경우에만 진짜 출력으로 내보냄 (MCP 통신용) if (line.trim().startsWith('{')) { process.stdout.write(line + '\n'); } else { // [INFO] 같은 텍스트 로그는 에러 채널(stderr)로 우회 (연결 유지) console.error(`[Filtered]: ${line}`); } });});이제 Antigravity MCP 설정에서 task-master-ai를 직접 실행하는 게 아니라, mute_logs.js를 실행합니다.
"task-master-ai": { "command": "node", "args": ["/Users/me/scripts/mute_logs.js"], // 래퍼 스크립트 실행 "env": { ... }}이후에 MCP 연결 상태를 보니 정상적으로 동작하는 것을 확인 할 수 있었습니다.
결론
cursor나 다른 에디터에서는 문제없이 작동하던 MCP였기 때문에 처음엔 Antigravity 쪽 문제라고 생각하기 어려웠습니다.
하지만 살펴보니 Antigravity의 MCP 구현이 아직 덜 다듬어졌거나, 프로토콜 위반에 더 민감하게 반응하는 것 같습니다.
특히 npx not found처럼 PATH 문제는 에러 메시지라도 있어 다행이었지만, EOF 에러는 로그 한 줄 없이 터지기 때문에 처음에는 무슨 문제인지조차 추정하기 어려웠습니다.
결국 하나씩 로그를 까보고, 래퍼 스크립트를 만들어야 했지만 그 덕분에 MCP 통신 방식과 설정방식을 조금 더 구체적으로 이해할 수 있었습니다.
이 삽질기가 동일한 환경에서 같은 문제를 겪는 누군가에게 최소한의 디버깅 힌트라도 되기를 바랍니다.