MCP 서버 env와 스킬 런타임 env는 다르다 — 3일 조용히 실패한 토큰 하나

자동화가 3일 동안 멈춰 있었는데, 에러 로그는 한 줄도 없었어요. 혹시 이런 적 없나요? 저는 최근에 직접 겪어 보니, 원인이 코드가 아니라 환경변수 이름 하나였어요.

무슨 일이 있었나

AI 에이전트에 노션 연동을 붙이면서 MCP 서버 설정의 env 블록에 토큰을 넣었어요. MCP 도구를 호출해 보니 정상 응답이 와서 연동 완료라고 판단했죠.

그런데 같은 서비스를 쓰는 스킬 쪽 자동화는 3일간 아무것도 쓰지 않았어요. 실패 알림도 없이요. 로그를 열어 보니 스킬 런타임은 다른 이름의 환경변수를 찾고 있었어요. 한쪽은 NOTION_TOKEN, 다른 쪽은 NOTION_API_KEY. 이름 하나 차이였어요.

왜 이런 일이 생기나

MCP 설정의 env는 MCP 서버 프로세스에만 주입돼요. 스킬이나 스크립트는 별도 프로세스라 그 값을 못 봐요.

무인 경로에서는 더 조용히 죽어요. 스케줄러로 도는 헤드리스 실행은 셸 프로필을 읽지 않는 경우가 많아서, 터미널에서는 되던 게 자동 실행에서만 실패해요. 게다가 토큰이 없으면 "쓸 게 없다"로 처리하고 성공처럼 끝나는 구현도 있어서, 상태만 보면 초록불이에요.

MCP 설정 env→MCP 서버 프로세스에만 주입→스킬 런타임은 별도 이름 탐색→값 없음→조용한 실패

어떻게 잡았나

거창한 디버깅은 아니었어요. 스킬이 실제로 읽는 env 이름을 로그로 찍어 보니 10분 만에 원인이 나왔어요. "설정에 넣었다"가 아니라 "런타임이 읽었다"를 확인해야 했던 거죠.

같은 방식을 다른 연동에도 적용해 봤더니, 비슷하게 어긋난 이름이 하나 더 나왔어요. 저는 플랜비(plan-b) 같은 서비스를 혼자 운영하면서 자동화에 기대는 부분이 많아서, 이런 조용한 실패가 제일 무서워요.

재발 방지 체크리스트 3가지

• ✓런타임이 읽는 env 이름 로그 확인
• ✓무인 경로에 env 명시 주입
• ✓성공 상태 대신 실제 결과물 확인

정리해 보니 3단계면 충분했어요.

1. 연동 직후, 스킬이 실제로 읽는 환경변수 이름을 로그로 확인해요. 문서 말고 코드가 기준이에요.
2. 스케줄러 같은 무인 경로에는 환경변수를 실행 설정에 직접 주입해요. 셸 프로필을 믿지 않는 게 안전해요.
3. "성공" 상태 대신 실제 결과물을 봐요. 게시가 목적이면 게시물이 있는지까지 확인해야 진짜 성공이에요.

작동 확인은 설정 화면이 아니라 결과물이 있는 자리에서 하는 것. 이번에 얻은 작은 교훈이에요.