MCP 서버 메모리는 왜 창을 열 때마다 다시 쌓이는가?
MCP 서버 메모리는 원인이 사라지지 않는 프로세스가 아니라, 거의 쓰지 않는 서버까지 창을 열 때마다 전부 미리 띄우는 방식에 있었다. SGK 스튜디오는 클로드 코드로 여러 창을 동시에 켜 두고 일하는데, PC를 재부팅한 직후에는 메모리가 넉넉하다가 창을 몇 개 더 열수록 부하가 눈에 띄게 쌓이는 현상을 겪었다.
처음에는 '이미 연결해 쓰는 도구들이니 그만큼 무거운 게 당연하다'고 넘겼다. 하지만 실제로 재 보니 그 전제부터 틀렸다 — 무거운 건 '쓰는 도구'가 아니라 '연결만 해 두고 거의 안 쓰는 도구'였다.
이 문제는 MCP(Model Context Protocol, 서로 다른 외부 도구를 같은 규격으로 붙이는 표준)를 붙여 쓰는 곳이면 어디서나 남의 일이 아니다. 클로드 코드는 세션 하나를 열 때마다 그 세션에 연결된 외부 도구 서버를 전부 그 자리에서 통째로 띄운다. 서버가 필요할 때만 켜지는 '지연 시작'을 지원하지 않기 때문에, 창을 열기만 해도 연결된 서버가 매번 같이 켜진다.
이 낭비가 처음엔 심각해 보이지 않을 수 있다. 하지만 여러 창을 동시에 켜 두고 일하는 방식 자체가 점점 흔해지고 있고, 창 하나마다 붙는 고정비는 켜 놓은 창 수만큼 그대로 곱해진다. PC 한 대가 쓸 수 있는 메모리는 정해져 있는데, 그 메모리를 실제로는 거의 안 쓰는 도구가 붙잡고 있으면 정작 필요한 작업이 느려지거나 PC 전체가 버벅이는 결과로 이어진다. 이건 서버 성능 문제가 아니라 '연결해 둔 것'과 '실제로 쓰는 것' 사이의 간격을 아무도 재 본 적이 없었다는 문제였다.
처음 잰 숫자 — 창 하나가 최대 428MB를 쓰고 있었다
메모리 부하가 어디서 오는지 확인하려고 두 가지를 같이 봤다. 하나는 `ps` 명령으로 PC에 떠 있는 프로세스를 전부 훑는 것이었고, 다른 하나는 메모리 사용량을 꾸준히 남긴 관측 기록 1,001건(2026년 8월 21일부터 9월 11일까지 쌓인 것)을 들여다보는 것이었다.
결과는 명확했다. 세션 하나에 연결되는 MCP 서버는 playwright(브라우저 자동화)·google-workspace(구글 메일·캘린더 연동)·veilbrowser(별도 프로젝트 전용 브라우저 도구) 3종이었고, 이 3종이 창 하나당 최소 276MB에서 최대 428MB를 차지하고 있었다.
최소치와 최대치 사이의 차이는 그 창이 어떤 프로젝트에서 열렸는지에 따라 갈렸다. veilbrowser는 특정 프로젝트에서만 연결돼 있었기 때문에, 그 프로젝트 밖에서 연 창은 276MB 쪽에 가까웠고 그 프로젝트 안에서 연 창은 428MB에 가까웠다. 어느 쪽이든 세 서버가 실제로 쓰이는지와 무관하게 창을 여는 순간 곧바로 붙는 값이라는 점은 같았다.
- playwright — 브라우저를 자동으로 조작하는 도구
- google-workspace — 구글 메일·캘린더·드라이브를 연동하는 도구
- veilbrowser — 별도 프로젝트에서만 붙여 쓰던 브라우저 도구
숫자만 보면 창 하나가 최대 428MB를 쓰는 정도는 대단해 보이지 않을 수 있다. 하지만 창을 여러 개 동시에 켜 두고 일하는 방식에서는 이 고정비가 창 수만큼 그대로 반복해서 붙는다는 게 진짜 문제였다.
이 두 가지 방법을 같이 본 이유가 있다. 프로세스 스캔만 보면 '지금 이 순간' 무엇이 얼마나 떠 있는지는 알 수 있어도, 그게 시간이 지나면서 계속 쌓이는 패턴인지 원래부터 그런 것인지는 구분이 안 된다. 반대로 관측 기록만 보면 추세는 보이지만 그 메모리를 정확히 무엇이 차지하고 있는지는 알 수 없다. 둘을 같이 봐야 '창을 열 때마다 특정 서버 3종이 매번 같은 크기로 새로 붙는다'는 패턴이 확인된다.
의심 1 — 프로세스가 안 꺼지고 쌓이는 것 아닐까?
메모리가 계속 남아 있는 걸 보면 가장 먼저 드는 의심은 하나였다. 세션을 껐는데도 그 세션에 딸린 프로세스가 제대로 안 꺼지고 고아처럼 쌓이는 것 아닐까? 창을 여러 개 열고 닫기를 반복하다 보면 이런 '좀비 프로세스'가 흔한 원인이 되곤 한다.
이 의심이 맞다면 처방은 간단하다. 오래된 프로세스를 주기적으로 찾아 강제로 정리하는 감시 장치를 하나 만들면 된다.
이런 좀비 프로세스는 보통 프로세스를 관리하던 부모 프로세스가 먼저 죽고 자식만 남을 때 생긴다. 여러 창을 열고 닫는 일이 잦을수록 이런 흔적이 하나씩 남아, 시간이 지날수록 메모리가 계속 쌓이는 것처럼 보일 수 있다.
프로세스에는 알리바이가 있었다
그런데 `ps`로 전체 프로세스를 훑어보니 이 의심은 틀렸다. 세션을 종료하거나 화면을 정리(clear)할 때 MCP 프로세스는 매번 정상적으로 같이 정리됐고, 고아로 남은 프로세스는 0건이었다.
고아 프로세스가 0건이라는 건 곧, 지금 쌓이고 있는 메모리가 '정리를 안 해서 남은 찌꺼기'가 아니라 '지금 이 순간에도 정상적으로 떠 있는 프로세스가 쓰는 몫'이라는 뜻이다. 그래서 의심의 방향을 완전히 바꿔야 했다 — 프로세스가 남는 게 문제가 아니라, 애초에 프로세스가 너무 많이·너무 일찍 켜지는 게 문제였다.
확인 방법은 단순했다. 세션을 종료한 직후와 화면을 정리한 직후 각각 프로세스 목록을 다시 찍어, MCP와 관련된 프로세스가 남아 있는지 그때그때 대조했다. 어느 시점에도 남아 있는 프로세스는 없었다 — 정리는 매번 제대로 되고 있었다.
진짜 비용은 창 하나당 붙는 고정비였다
실비용은 창 하나를 열 때마다 붙는 고정비였다. 클로드 코드의 MCP 연결 방식(표준 입출력, stdio)은 세션이 시작되는 순간 연결된 서버 전부를 한꺼번에 기동하고, 그중 어느 것도 지연 시작을 지원하지 않는다. 서버를 실제로 쓸지 안 쓸지와 상관없이 세션을 여는 순간 3종이 다 같이 켜지는 구조였다.
표준 입출력(stdio) 방식으로 붙는 MCP 서버는 웹 서버처럼 요청이 들어올 때마다 필요한 만큼만 움직이는 구조가 아니다. 세션이 시작되면 클로드 코드가 설정에 적힌 서버를 하나씩 실행 파일로 직접 띄우고, 그 프로세스는 세션이 끝날 때까지 계속 떠 있는다. 서버 쪽에 '지금 당장은 아무도 안 부르니 잠들어 있겠다'는 선택지 자체가 없는 구조라, 연결만 해 두고 실제로는 거의 안 쓰는 서버라도 세션을 여는 값을 매번 전액 다 낸다.
그럼 그 서버들을 실제로 얼마나 쓰고 있었을까. 최근 14일 동안의 대화형 세션 208개를 대상으로 서버별 실사용률을 다시 재 봤다.
playwright는 13개(6.2%), google-workspace는 18개(8.7%)에서만 실제로 쓰였고, veilbrowser는 208개 세션 가운데 단 한 번도(0%) 쓰이지 않았다. 창을 열 때마다 매번 켜지는 서버 3종 가운데 하나(veilbrowser)는 있으나 마나였고, 나머지 둘도 열에 아홉은 그냥 떠 있기만 했다.
실사용률이 이렇게 낮은 이유는 도구 자체가 쓸모없어서가 아니다. 브라우저를 자동으로 조작하거나 구글 메일·캘린더를 연동하는 작업은 세션 전체로 보면 가끔 하는 일이고, 그 가끔을 위해 창을 여는 매 순간 서버를 미리 켜 두는 쪽이 오히려 낭비였다. 자주 쓰는 도구라면 항상 켜 두는 비용이 아깝지 않지만, 이 세 서버는 그런 도구가 아니었다.
그래서 시도한 것 — 필요할 때만 서버를 켜는 중개 프로그램
세 서버 앞에 프로그램 하나를 세웠다. 이 중개 프로그램(프록시)은 세션이 맨 처음 도구 목록을 물어볼 때(initialize·tools/list) 미리 저장해 둔 답을 즉시 돌려주고, 진짜 서버는 실제로 도구를 처음 사용하는 순간(tools/call)에만 켠다. 서버를 다시 켤 때마다 도구 목록을 새로 받아 캐시를 갱신하고, 목록이 바뀌면 알림을 함께 보낸다.
사용자 범위로 연결돼 있던 google-workspace와 playwright는 이 중개 프로그램을 거치도록 바꿨고, 프로젝트 범위로 연결돼 있던 veilbrowser는 14일 동안 실사용률이 0%로 확인돼 아예 제거했다.
이 설계를 고른 이유는 단순하다. 서버를 아예 안 켜면 도구 목록조차 알 수 없어 세션이 어떤 도구를 쓸 수 있는지 판단하지 못하고, 반대로 지금처럼 전부 켜 두면 안 쓰는 서버까지 비용을 낸다. 목록 응답과 실제 실행을 분리하면 이 둘 사이에서 하나를 고르지 않아도 된다 — 목록은 항상 즉시 준비돼 있고, 비용은 실제로 쓸 때만 든다.
까다로웠던 지점 하나는 playwright가 두 갈래로 연결돼 있었다는 점이다. 하나는 사용자 설정에 있었고, 다른 하나는 확장 기능(플러그인) 형태로 연결돼 있었는데, 플러그인 쪽 연결은 중개 프로그램으로 감쌀 수 없는 구조였다. 그래서 플러그인 쪽 연결은 꺼 버리고 같은 도구를 사용자 설정 쪽(중개 프로그램을 거치는 연결)으로 옮겼다. 이 과정에서 도구를 부르는 이름이 바뀌었는데, 옮기기 전에 옛 이름을 코드 전체에서 찾아본 결과가 0건이어서 걸릴 곳이 없다는 걸 확인한 뒤 적용했다. 원래 설정은 따로 백업해 뒀다 — 예상 밖의 문제가 생기면 언제든 이전 방식으로 되돌릴 수 있게 해 두려는 목적이다.
이 방식에는 대가가 있다. 서버를 실제로 처음 쓸 때 2초에서 5초 정도 지연(콜드 스타트)이 생긴다. 다만 이 지연은 도구를 실제로 쓸 때 딱 한 번만 생기고, 실사용률이 10%가 채 안 되는 서버가 대부분이라 대부분의 창에서는 아예 체감되지 않는다.
캐시를 무한정 믿지는 않는다. 서버가 다시 켜질 때마다 도구 목록을 새로 받아 캐시를 덮어쓰고, 그사이 목록이 바뀌었으면 알림을 보내 세션이 새 목록을 다시 읽게 한다. 빠른 응답은 '오래된 답을 그냥 돌려준다'는 뜻이 아니라, '최근에 확인한 답을 먼저 돌려주고 실제로 쓸 때 다시 확인한다'는 뜻이다.
기각한 방법 셋
- 공식 설정(disabledMcpServers) — 실제로 있는 기능이지만, 꺼 둔 서버를 세션 안에서 프로그램이 스스로 다시 켤 수 없어 자동화에는 못 쓴다.
- 환경변수(MCP_DISABLE_STDIO) — 처음 조사에서 참고한 자료에 나와 있었지만, 실제 프로그램 파일(버전 2.1.268)에서 문자열을 찾아보니 이 이름은 어디에도 없었다(검색 결과 0건). 잘못된 자료를 버리고 직접 중개 프로그램을 만드는 쪽으로 방향을 틀었다.
- veilbrowser를 그대로 두는 방법 — 14일 동안 실사용률이 0%라 지연 시작 대상에 넣을 가치도 없어서, 아예 없애는 쪽이 더 단순했다.
세 가지 모두 기존에 이미 있는 방법을 그대로 쓰는 선택이었는데, 셋 다 이번 상황에 맞지 않았다. 유지보수 부담이 새로 생기는 걸 알면서도 중개 프로그램을 직접 만드는 쪽을 택한 이유가 여기에 있다.
새로 연 창에서 다시 재 봤다
중개 프로그램만 따로 켜서 시험해 보니, 캐시가 있을 때 initialize 응답은 0.02초 만에 왔고 첫 도구 호출 전까지 뜬 프로세스는 0개(메모리 12MB)였다. 도구를 실제로 부르자 그제야 서버가 켜졌고(2초에서 2.5초 소요) 응답은 성공했으며, 종료할 때 남은 자식 프로세스는 0개였다.
시험은 세 단계로 나눠 했다. 먼저 중개 프로그램만 따로 켜서 프로토콜 자체가 의도대로 동작하는지 봤고, 그다음 실제로 쓰는 환경과 똑같은 새 대화형 세션을 열어 다시 쟀고, 마지막으로 사람이 아니라 프로그램이 자동으로 부르는 비대화형 호출로도 문제없이 동작하는지 확인했다. 세 단계 모두에서 같은 그림이 나와야 이 방식을 실제로 적용해도 된다고 판단할 수 있었다.
각 단계에서 확인한 항목은 같았다 — 첫 응답이 얼마나 빨리 오는지, 실제 호출 전까지 떠 있는 프로세스가 몇 개인지, 실제 호출이 성공하는지, 종료 뒤에 남는 프로세스가 있는지. 네 가지를 전부 통과해야 다음 단계로 넘어갔고, 어느 하나라도 걸렸으면 적용을 미뤘을 것이다.
실제 사용 환경인 새 tmux 대화형 세션에서도 같은 그림이 나왔다. 적용 전에는 MCP 관련 프로세스가 6개에서 8개, 메모리는 276MB에서 428MB를 차지했는데, 적용 후에는 프로세스 2개·메모리 24MB로 줄었다. 창 하나당 메모리 절감폭은 약 95%다.
프로세스 개수도 함께 줄었다는 점이 눈에 띈다. 적용 전 6개에서 8개였던 프로세스가 적용 후 2개로 줄었는데, 이 2개는 세 서버를 대신하는 중개 프로그램 자체이지 실제 서버가 아니다. 진짜 서버는 도구를 쓸 때만 잠깐 떴다가 다시 정리된다.
비대화형 호출로도 실제 시험을 해 봤다. google-workspace와 playwright 둘 다 성공했고, 전체 43초가 걸렸는데 그중 서버는 세션이 시작되고 35초·38초 지난 시점에야 지연 기동했다. 호출이 끝난 뒤 남은 프로세스는 0개였다. 사람이 직접 붙어 있지 않은 자동화 호출에서도 서버가 필요한 순간에 정확히 켜지고 끝난 뒤 깨끗이 정리된다는 점을 확인한 셈이다.
이미 열려 있던 창은 어떻게 됐는가?
이미 켜져 있던 창 7개는 재시작하지 않았는데도 MCP 메모리 합계가 2,297MB에서 1,827MB로 줄었다. 다만 이 중 새 설정이 실제로 적용된 창은 2개뿐이었고, 나머지 5개는 창을 다시 열어야 적용된다. 지금 당장 전체 효과를 보려면 열려 있는 창을 한 번씩 재시작해야 한다.
숫자만 보면 크지 않아 보일 수 있지만, 이 회사처럼 창을 여러 개 동시에 켜 두고 하루 종일 작업하는 환경에서는 창 하나당 줄어든 메모리가 열려 있는 창 수만큼 그대로 반복해서 쌓인다. 새로 여는 창은 곧바로 이득을 보고, 기존에 열려 있던 창은 다음에 다시 열 때 자연스럽게 새 설정을 받는다.
당장 7개를 전부 재시작하지 않은 이유는 각 창마다 진행 중인 작업이 있었기 때문이다. 재시작은 그 작업을 끊는 대가가 따르므로, 효과가 확인된 지금은 창을 다시 열 때마다 자연스럽게 넘어가는 쪽을 택했다. 급한 경우가 아니면 굳이 지금 당장 전부 끄고 다시 켤 필요는 없다.
같은 PC에서 메모리를 다시 재고 고친 사례는 WSL 메모리를 5분마다 회수하도록 바꾼 기록에도 있다. 둘 다 '얼마나 쓰나'를 먼저 재고 나서야 진짜 원인이 보였다는 점이 같다.
두 사례를 나란히 놓고 보면 공통점이 하나 더 있다. 둘 다 처음에는 '어쩔 수 없이 그만큼 무겁다'고 넘길 뻔했던 문제였고, 실제로 얼마나 쓰는지 재 보고 나서야 그 전제가 틀렸다는 게 드러났다. 무겁다고 느껴지는 것과 실제로 무거운 것은 다른 얘기다.
아직 남는 문제
설정을 들여다보는 과정에서 부수적인 문제가 하나 나왔다. 구글 인증에 쓰는 자격 증명 두 개가 이 세션의 대화 기록에 평문으로 남았다. 회사 바깥으로 나간 적은 없지만, 이 기록은 나중에 검색 대상에 포함될 예정이라 안전하게 두려면 해당 자격 증명을 새로 발급해야 한다.
이 노출은 설정값을 확인하려고 화면에 그대로 띄운 동작에서 나왔다. 값 자체는 도구를 연동하는 데 쓰는 자격 증명이지 결제나 개인정보와 직접 연결된 값은 아니지만, 한 번 평문으로 남은 값은 나중에 다른 곳에 다시 나타날 수 있다는 점에서 가볍게 넘기지 않기로 했다.
검증이 아직 안 끝난 부분도 있다. 지금 열려 있는 창 전체를 재시작한 뒤 다시 재는 작업이 남아 있는데, 이건 시간이 걸리는 일이라 아직 날짜를 정하지 못했다.
이번에 바꾼 건 서버를 켜는 시점뿐이고, 서버 자체의 동작이나 결과는 그대로다. 그래서 이 변경으로 새로운 기능이 생기거나 기존 기능이 달라지는 일은 없다 — 달라지는 건 오직 필요 없을 때 얼마나 자원을 덜 쓰느냐뿐이다. 도구를 부르는 쪽에서 보면 이전과 똑같이 동작하고, 다만 그 뒤에서 서버가 켜지는 시점만 미뤄졌을 뿐이다.
처음 세운 가설, 즉 프로세스가 안 꺼지고 고아처럼 쌓인다는 의심은 이번에 틀렸다는 게 확인됐다. 그 가설이 맞았다면 프로세스를 강제로 정리하는 감시 장치를 만들었을 텐데, 실제 원인이 달라 그 방향은 접었다.
- 창 하나당 MCP 메모리 — 276~428MB에서 24MB로, 약 95% 절감
- 처음 의심했던 원인(고아 프로세스)은 0건으로 반증됐다
- 진짜 원인 — 지연 시작을 지원하지 않는 구조 + 서버 3종 가운데 최대 8.7%만 실사용
- 남은 일 — 재시작하지 않은 창 5개 재시작, 노출된 구글 인증 정보 재발급
이번 사례에서 남는 교훈은 하나다. '연결해 뒀다'와 '실제로 쓰고 있다'는 다른 말이고, 그 차이를 재 보기 전에는 어느 쪽이 진짜 비용인지 알 수 없다. 처음 의심대로 프로세스를 정리하는 감시 장치를 만들었다면 문제의 겉모습만 다스리고 원인은 그대로 남았을 것이다.
비슷하게 '연결은 해 뒀지만 거의 안 쓰는 도구'가 다른 업무 자동화에도 숨어 있을 수 있다. 어디서 메모리나 처리 시간이 새고 있는지부터 확인하고 싶다면 상담에서 시작할 수 있다.