OpenClaw Gateway와 stdio MCP는 이미 돌아가지만, 프로덕션에서 자식 프로세스 수가 서서히 늘고 RSS가 오르거나 간헐적 OOM이 나와 설정을 손봐야 할지 아키텍처를 바꿔야 할지 막막한 경우가 있습니다. 본문은 MCP stdio/HTTP 핸드셰이크·멈춤 트러블슈팅, Gateway 프로덕션 관측과 역할을 나누고, 먼저 일곱 가지 체크리스트로 경계를 긋고, stdio 대 HTTP 운영 대조표로 트레이드오프를 좁힌 뒤, 여섯 단계 회수·속도 제한 Runbook과 systemd/Docker 환경 변수·재시작 전략을 제시합니다. 말미에는 OpenClaw 목록과 컴퓨트 시나리오로 이어집니다.
stdio MCP의 연결 핸드셰이크, 멈춤, 권한 거부는 핸드셰이크 글을, 허용 목록·도구 정책은 MCP 도구체인 허용 목록 글을, 헬스 체크·로그·업그레이드/롤백은 관측 글을 우선합니다. 이 글은 Gateway가 세션을 안정적으로 받아들인 뒤에도 자식 프로세스와 메모리 곡선이 받아들일 수 없을 때, 층으로 나눠 다루는 방법만 답합니다.
첫 핸드셰이크 실패: MCP 전송과 다운스트림 실행 경로를 보는 영역이며 여기서는 다루지 않습니다.
토큰·스코프와 gateway closed (1000): 전용 closed(1000) 글을 보고, 회수 스크립트를 바꾸지 않습니다.
순수 보안 정책: dmPolicy / networkPolicy 변경은 하드닝 글로 갑니다.
Gateway 기동 실패·not ready: 포트·메모리·compose 순서는 not ready 트러블슈팅 글을 먼저 봅니다.
앱 레이어 모델 백엔드 타임아웃: MCP 자식 프로세스 거버넌스와 병행할 수 있으나 원인은 모델 라우팅일 수 있습니다.
서드파티 MCP 구현의 일회성 누수 버그: 상류 수정이나 버전 고정이 필요하며 회수는 완화에 그칩니다.
「정리」를 만능으로 삼기: 수위·버전 대장 없는 강제 종료는 실제 누수 지점을 가립니다.
오픈소스 논의에서 stdio MCP가 Gateway 자식 프로세스로 장시간 세션을 유지하면 세션에 따라 풀이 부풀 수 있습니다. 동작은 릴리스마다 달라지므로 운영에서는 「허용 프로세스 상한 + 회수 정책」을 당번 매뉴얼에 적고 기본값에만 의존하지 않는 편이 낫습니다. 먼저 세션 격리에서 예상되는 누적 모델을 세운 뒤 대조표로 갑니다.
핸드셰이크 글과의 접점은, 실패 시 로그에 연결·핸드셰이크 오류가 남는다는 점입니다. 이 글이 다루는 전형 신호는 프로세스 수 단조 증가, 메모리 계단식 상승, 고정 주기의 OOM killer입니다. 분리할 때 Gateway 부모와 MCP 자식의 부모-자식 관계를(ps·컨테이너 안 pstree) 확인해 모델 백엔드나 채널 프로세스를 MCP에 넣지 않습니다.
여러 도구체인(로컬 스크립트와 원격 Mac의 상시 에이전트 등)을 돌리면 어떤 호스트에 Gateway를 두고 어디에 무거운 MCP를 둘지 토폴로지로 그리는 것이 좋습니다. Gateway 노드의 메모리 여유가 동시 stdio 세션 상한을 결정합니다. 용량·접속 안내는 Mac Mini 대여 가격과 헬프 센터 네트워크 요구를 함께 보세요.
관측 관점에서는 최소 세 가지 시계열을 권합니다: 프로세스 수, Gateway와 MCP의 RSS, 도구 호출 QPS와 세션 수. 세션 차원이 없으면 「누적」이 트래픽 피크인지 회수 누락인지 알 수 없습니다. 관측 글의 로그 필드와 맞춘 뒤 대시보드에서 주간 비교를 하지 않으면 당번은 감으로 재시작만 하게 됩니다.
또 흔한 오해는 「자식이 많다 = HTTP로 갈아타야 한다」입니다. 도구가 매우 가볍고 동시성이 낮다면 세션이 닫히지 않았거나 다운스트림 실행 파일이 블로킹인 경우가 더 많으므로, 먼저 클라이언트 세션 수명을 조이고 전송 계층 이전 비용을 봅니다.
stdio 전송은 MCP 서버를 Gateway 수명에 자식 프로세스로 강하게 결합시킵니다. HTTP 전송은 독립 엔드포인트에 가깝고 스케일·헬스 체크 경로가 다릅니다. 아래 표는 「stdio를 더 다듬을지」「HTTP로 올릴지」 검토에 씁니다.
| 차원 | stdio MCP | HTTP MCP |
|---|---|---|
| 프로세스 결합 | 자식은 Gateway·세션 모델을 따르고 누적이 체감되기 쉬움 | 대개 독립 프로세스이고 Gateway는 클라이언트 |
| 수평 확장 | Gateway 동시 확장이나 세션 속도 제한이 필요한 경우가 많음 | MCP 서비스만 복제 확장 가능 |
| 헬스 체크 | Gateway 로그와 프로세스 표에 의존 | HTTP 프로브와 독립 SLO |
| 장애 반경 | 자식 문제가 같은 호스트 Gateway를 느리게 만들기 쉬움 | 격리는 나으나 네트워크 홉이 하나 늘어남 |
| 적합한 경우 | 가벼운 도구·낮은 동시성·동일 호스트 신뢰 | 무거운 도구·높은 동시성·독립 릴리스 리듬 |
거버넌스는 기계를 무한히 쌓는 것이 아니라 프로세스와 메모리 곡선에 계약을 거는 것입니다. 계약을 넘기면 속도 제한·회수·전송 방식 변경입니다.
stdio/HTTP 핸드셰이크 글에서 설정이 맞다고 확인했는데도 메모리 적색선 근처가 이어지면, 호스트 스펙만 올리는 대신 「HTTP화」를 아키텍처 검토에 올립니다.
단계는 「먼저 증거, 그다음 속도 제한, 마지막 아키텍처」입니다. 관측 글의 로그 필드와 맞추고 로그 없는 강제 종료는 피합니다.
기준선: 안정 부하에서 프로세스 수·RSS·Gateway 버전·MCP 패키지 버전을 변경 대장에 기록합니다.
스파이크와 누수 구분: 스파이크는 대개 동시 세션과 연동됩니다. 단조 증가는 미회수나 다운스트림 정지 가능성이 있어 스택을 잡습니다.
동시성·타임아웃 조이기: 설정 범위에서 병렬 도구 호출을 내리고 유휴 타임아웃을 짧게 해 곡선이 세션 수와 함께 내려가는지 봅니다.
계획된 회수: 유지보수 창에서 Gateway를 롤링 재시작하거나 노드를 분리하고 먼저 세션을 드레인합니다.
컨테이너와 systemd: 환경 변수가 실제 실행 환경에 주입되는지 확인합니다(데몬과 대화형 셸 불일치는 흔한 함정입니다).
HTTP 이전 평가: 무거운 MCP나 독립 스케일이 필요한 서비스는 별도 배포와 헬스 체크를 두고 Gateway 쪽을 HTTP 전송으로 바꿉니다.
ps -axo pid,ppid,rss,comm | grep -E 'openclaw|mcp|node' | head -n 50 # 컨테이너에서는 pstree -p 1과 함께 부모-자식을 확인
팁: openclaw.json을 수정한 뒤에는 사이트 문서가 권장하는 검증 경로(예 config:validate / doctor)를 실행하고 롤링 재시작해 「설정은 반영된 것 같은데 프로세스는 옛값」을 피합니다.
GitHub 이슈에는 「stdio MCP 자식이 세션 교대 시 회수되지 않는다」는 보고도 있으며, 운영에서는 주기적 회수·버전 추적을 임시 완화로 두고 상류 수정을 따릅니다. 문서화되지 않은 수동 kill에 장기 의존하지 마세요.
systemd 타이머나 k8s CronJob 등으로 사이드카 회수를 쓸 때는 Gateway 실행 사용자·환경 변수·cgroup 메모리 상한을 맞춥니다. 그렇지 않으면 스크립트가 보는 프로세스 트리와 실서비스가 엇갈려 분리가 어렵습니다. 작은 단일 노드에서는 먼저 설정으로 동시성과 타임아웃을 계약 안에 넣고 사이드카 복잡도는 나중을 고려합니다.
마지막으로 회수나 속도 제한 변경은 릴리스 버전과 묶습니다. stdio 동작은 Gateway 마이너에서 바뀔 수 있어 버전을 맞추지 않은 곡선 비교는 의미가 없습니다.
systemd 유닛은 대화형 ~/.zshrc를 물려받지 않습니다. Docker Compose에서는 MCP 실행 파일 경로와 읽기 전용 마운트 때문에 자식이 반복 기동할 수도 있습니다. Docker 프로덕션 글을 보며 Environment=, WorkingDirectory=, 이름 있는 볼륨, 이미지 digest를 점검합니다.
주의: 이전 종료 코드를 보지 않고 docker compose restart를 자주 하면 설정 오류를 메모리 누수로 오인하기 쉽습니다.
not ready 트러블슈팅 글과 연동합니다. 메모리가 부족하면 Gateway가 안정적인 MCP 세션 단계에 들어가기 전에 멈출 수 있어, 먼저 리소스와 기동 순서를 고칩니다.
아래 숫자는 흔히 쓰는 출발점이며 실제 부하에 맞춥니다.
에이전트와 Gateway를 불안정한 소메모리 노드에 몰아 넣으면 「도구체인과 모델의 이중 지터」가 납니다. 세션 모델을 바꾸지 않고 기계만 더하면 비용은 선형으로 불어납니다. macOS 빌드나 자동화를 장기 온라인·예측 가능한 연산으로 돌리고 OpenClaw 주변에도 여유를 두려는 팀에는 고정 SSH와 명확한 사양의 NodeMini Mac Mini 클라우드 대여가 노트북이나 과잉 공유 호스트를 끼워 맞추는 것보다 유리한 경우가 많습니다. 먼저 대여 가격을 보고 헬프 센터에서 네트워크·접속을 확인하세요.
실행 시에는 「stdio 세션 상한 + 회수 정책 + HTTP 이전 트리거」를 같은 운영 계약 페이지에 적어 개발과 SRE가 같은 지표로 검토합니다.
대외 사후 분석에는 프로세스 스냅샷과 로그 발췌를 붙여 설정 오설정과 상류 결함을 구분하기 쉽게 합니다.
반드시 그렇지는 않습니다. 세션 격리로 인한 예상 증가와 누수형 누적을 구분하고 RSS와 Gateway 버전으로 알려진 이슈를 대조합니다. 필요하면 수정 릴리스로 올리고 cron만 더하지 않습니다.
자식 수명이 세션 모델과 오래 맞지 않거나 노드 메모리 여유가 계속 부족하고 수평 확장도 어려울 때 HTTP MCP가 독립 스케일·헬스 체크에 유리한 경우가 많습니다. 배경은 OpenClaw 목록도 참고하세요.