매일공부

[작업 기록] NAS 호스트 메모리 진단 — VS Code Remote-SSH가 먹는 몫 본문

IT/작업기록

[작업 기록] NAS 호스트 메모리 진단 — VS Code Remote-SSH가 먹는 몫

julian 2026. 8. 3. 14:34

배경

지난번 장애 대응 기록에서 컨테이너별 메모리 제한과 watchdog 스크립트를 도입한 뒤에도, 여유 메모리가 하루 500~600MB씩 꾸준히 줄어드는 패턴이 계속 관찰됐다. docker stats로 확인한 컨테이너 사용량은 정상 범위(합계 약 400MB)였기 때문에, 원인은 컨테이너 안이 아니라 호스트 레벨에 있는 게 분명했다.

진단 — 무엇이 호스트 메모리를 먹고 있었나

ps aux --sort=-%mem으로 확인한 주요 사용처:

원인 메모리 비고

VS Code Remote-SSH (extensionHost + Pylance + 언어 서버) 약 1.9GB 가장 큰 원인
Claude Code 세션 (여러 개 동시 실행) 세션당 약 200~280MB VS Code 창 개수만큼 상시 존재
SMB 파일공유(smbd) 프로세스 다수 약 1.1GB 정상적인 직원 접속 세션
특정 컨테이너 (자동 시작 켜져 있던 것) 1.1GB 자동시작 옵션 꺼서 조치 완료
고아 상태 manage.py runserver 약 110MB 아래 참고

고아 프로세스 하나 발견

manage.py runserver 프로세스가 두 개 떠 있어서 처음엔 "중복 실행 아닌가" 싶었는데, 확인해보니 하나는 다른 하나의 자식 프로세스였다 — Django runserver가 기본으로 쓰는 auto-reloader가 부모/자식 쌍으로 뜨는 정상 구조라 인스턴스는 1개뿐.

다만 진짜 문제는 따로 있었다: 이 프로세스가 고아 프로세스였다.

  • 부모 셸(터미널 세션)에 물려 있었는데, 그 셸은 이미 종료된 상태
  • 터미널 창을 닫았지만 runserver는 계속 살아서 포트를 리슨 중이었음
  • who -a로 확인해도 해당 터미널에 연결된 로그인 세션이 없었음

메모리 자체는 110MB로 크지 않았지만, "안 쓰는데 계속 떠 있는" 전형적인 케이스라 종료 조치했다.

VS Code Remote-SSH 1.9GB, 새는 건가 원래 드는 비용인가

8GB 램 기준으로 1.9GB면 전체의 약 25%. 처음엔 "이게 새로 생긴 문제 아닌가" 싶었는데, 따져보니 결론은 **"원래 있던 비용"**에 가까웠다.

  • VS Code Remote-SSH + 언어 서버(Pylance 등) 조합은 원래 메모리를 꽤 먹는 도구다. 로컬 PC에서 VS Code로 개발할 때도 비슷하게 먹는데, 지금은 그게 로컬이 아니라 NAS 위에서 돌고 있는 것뿐이다. 즉 "개발하려면 어차피 드는 비용"이지, 뭔가 잘못돼서 새는 양이 아니다.
  • 실제로 문제였던 건 별도로 켜져 있던 컨테이너 쪽 1.1GB였고, 이건 끄자마자 바로 회복됐다. VS Code 쪽은 "지금 실제로 쓰고 있어서" 나가는 비용이라 성격이 다르다.

다만 진짜 문제가 되는 지점은 따로 있었다 — "얼마나 오래 켜두는가".

8GB 중 시스템 기본 + SMB 등 고정 비용이 2~3GB, 컨테이너들이 최대 5.5GB까지 쓸 수 있는 상태에서, 개발할 때만 VS Code가 1.9GB를 얹는 구조였다. 그런데 퇴근 후·주말에도 Remote-SSH 연결을 계속 열어두는 습관이 있었다면, 이게 지난번 사고의 "숨은 공범"이었을 가능성이 있다. 필요할 때만 쓰는 도구가 며칠씩 상시 상주하며 1.9GB를 깔고 있으면, 그만큼 컨테이너들이 쓸 수 있는 여유가 줄어드는 셈이기 때문이다.

결론

  • 개발하는 동안 VS Code Remote-SSH가 1.9GB를 쓰는 것 자체는 정상 — 문제는 이게 아님
  • 문제는 개발이 끝난 뒤에도 연결을 계속 열어두는 것. VS Code Remote-SSH의 enable-remote-auto-shutdown 옵션이 켜져 있으면 클라이언트가 완전히 끊겼을 때 서버 프로세스가 정리되긴 하지만, 터미널에서 직접 백그라운드로 띄운 프로세스(runserver 같은)는 이 메커니즘 밖이라 알아서 정리되지 않는다
  • 근본적으로는 "NAS 위에서 직접 개발하는 방식" 자체가 호스트에 상시 1.9GB+를 물려두는 구조라는 게 드러났다 → 이 진단 결과를 계기로 개발 방식 자체를 바꾸기로 했다 (다음 글에서 이어짐)
Comments