VS Code Remote-SSH는 원격 서버에서 개발할 수 있어 편리하지만, 접속하자마자 서버 CPU가 100% 이상 치솟는 문제가 생기기도 합니다. 특히 `/data`처럼 로그와 백업 파일, 빌드 결과물까지 포함된 큰 디렉터리를 워크스페이스로 열었을 때 증상이 두드러집니다.

이 문제는 단순히 VS Code 본체가 무거워서 발생하는 것이 아닙니다. 원격 서버에 설치된 VS Code Server가 파일 감시, 확장 기능 초기화, 검색 인덱싱을 동시에 수행하면서 CPU와 디스크 I/O를 많이 사용하기 때문입니다. 설정을 무작정 끄기보다 어떤 프로세스가 일을 하는지 확인한 뒤 범위를 줄이는 방식이 효과적입니다.

먼저 확인할 프로세스는 node 아래에 있다

Remote-SSH로 접속하면 서버에는 VS Code Server 프로세스가 실행됩니다. 이 프로세스는 보통 `node`로 표시되며, 그 아래에 여러 작업별 자식 프로세스가 붙습니다.

`top`에서는 node가 높은 CPU를 사용하는 것으로 보이지만, 실제 원인은 `pstree`로 확인해야 더 분명합니다. 대표적으로 다음과 같은 프로세스가 문제를 일으킵니다.

• `--type=extensionHost`: 설치된 확장 기능을 실행하는 프로세스
• `--type=fileWatcher`: 워크스페이스의 파일 변경을 감시하는 프로세스
• `--type=ptyHost`: 통합 터미널을 관리하는 프로세스

이 가운데 대형 디렉터리를 열었을 때 특히 부담이 커지는 것은 `fileWatcher`와 `extensionHost`입니다. 파일 감시 프로세스는 워크스페이스의 파일 변화를 추적하고, 확장 호스트는 Python, TypeScript, Git 같은 확장이 프로젝트 구조를 읽고 분석합니다.

따라서 “Remote-SSH에 붙는 순간 서버가 느려진다”면 먼저 서버의 `top`, `htop`, `pstree`를 확인하고, 특정 node 자식 프로세스가 CPU를 사용하는지 구분하는 것이 좋습니다. 서비스 전체가 느려지는지, VS Code Server만 바쁜지도 함께 봐야 합니다.

대형 워크스페이스가 CPU와 디스크를 동시에 자극하는 이유

가장 흔한 원인은 워크스페이스의 범위가 지나치게 넓은 경우입니다. `/data` 아래에 실제 소스 코드뿐 아니라 로그, 압축 파일, 백업, 가상환경, `node_modules`, `dist`, `build`가 함께 있다면 VS Code는 이 파일들을 개발 대상과 완전히 구분하지 못할 수 있습니다.

파일 감시는 모든 파일 내용을 계속 읽는 작업은 아니지만, 감시 대상이 많아질수록 운영체제의 파일 이벤트 처리와 상태 관리에 부담이 생깁니다. Rocky Linux 8.9 같은 서버 환경에서는 inotify 기반 감시 자원과 디스크 응답 속도도 결과에 영향을 줍니다.

검색 기능도 별도의 부담을 만듭니다. VS Code 내부 검색은 보통 `ripgrep`, 즉 `rg`를 사용해 파일을 훑습니다. 로그와 CSV, 압축 파일, Git 관련 디렉터리까지 검색 대상에 포함되면 검색이나 인덱싱 시 CPU와 I/O가 급증할 수 있습니다.

확장 기능은 또 다른 변수입니다. Python 확장은 가상환경이나 프로젝트 구조를 확인할 수 있고, TypeScript 관련 기능은 의존성과 타입 정보를 분석합니다. Git, ESLint, Prettier처럼 프로젝트 전체를 살펴보는 확장이 여러 개 활성화되어 있으면 접속 직후 초기화 작업이 겹칠 가능성이 커집니다.

Remote-SSH 설정은 진단용과 운영용을 나눠 적용한다

문제의 원인을 빠르게 확인하려면 원격 설정에서 파일 감시를 우선 차단해 볼 수 있습니다. 예를 들어 원격 환경의 `settings.json`에 다음과 같이 설정합니다.

```json

{

"files.watcherExclude": {

"**": true

},

"git.enabled": false,

"extensions.autoUpdate": false,

"extensions.autoCheckUpdates": false,

"npm.autoDetect": "off",

"typescript.disableAutomaticTypeAcquisition": true,

"typescript.tsserver.useSeparateSyntaxServer": true,

"typescript.tsserver.experimental.useVsCodeWatcher": false,

"javascript.suggest.completeFunctionCalls": false,

"editor.wordBasedSuggestions": false,

"window.restoreWindows": "none",

"workbench.editor.restoreViewState": false,

"workbench.startupEditor": "none",

"remote.autoForwardPorts": false

}

```

여기서 `files.watcherExclude`의 `"**": true`는 모든 파일 감시를 막는 강한 설정입니다. CPU가 파일 감시 때문에 오르는지 확인하는 진단 단계에서는 유용하지만, 적용 후에는 파일 변경 자동 반영이나 일부 확장 기능이 정상적으로 작동하지 않을 수 있습니다. 문제가 확인되면 전체 차단을 유지하기보다 필요한 코드 경로만 감시하도록 점진적으로 완화하는 편이 낫습니다.

`git.enabled`를 끄면 Git 패널과 자동 상태 갱신으로 인한 부담을 줄일 수 있지만, 원격 저장소의 변경 상태를 VS Code에서 바로 확인하기 어려워집니다. TypeScript, npm, 자동완성 관련 옵션도 마찬가지로 CPU를 줄이는 대신 분석 기능과 편의성을 일부 포기하는 방식입니다.

설정은 사용자 전체가 아니라 원격 호스트 또는 특정 워크스페이스에만 적용하는 것이 안전합니다. 로컬 개발 환경까지 같은 설정을 적용하면 필요하지 않은 기능까지 꺼질 수 있습니다.

워크스페이스를 줄이는 것이 가장 효과적인 대응이다

설정 변경보다 먼저 할 일은 열어 둔 폴더의 범위를 줄이는 것입니다. `/data` 전체를 여는 대신 실제 애플리케이션 코드가 있는 하위 폴더만 열어야 합니다. 로그, 백업, 결과물 디렉터리는 파일 탐색기와 검색 대상에서 제외하거나 별도의 터미널 명령으로 확인하는 편이 효율적입니다.

예를 들어 다음과 같은 경로는 일반적인 소스 편집 범위에서 제외할 후보입니다.

```text

logs/

backup/

node_modules/

.venv/

dist/

build/

```

워크스페이스를 코드 폴더로만 제한하면 파일 감시 대상 자체가 줄어듭니다. 이 방식은 자동완성이나 Git 기능을 광범위하게 끄지 않아도 되므로, 기능 손실이 적다는 장점이 있습니다. 실제 자료에서도 전체 디렉터리를 열었을 때보다 코드 폴더만 열었을 때 CPU 스파이크가 거의 느껴지지 않는 수준으로 줄었습니다.

검색 제외 규칙과 확장 정리로 남은 부담을 줄인다

워크스페이스 루트에는 `.ignore` 파일을 둘 수 있습니다. 다음처럼 로그와 생성 파일을 검색에서 제외하면 `rg`가 불필요한 파일을 훑는 일을 줄일 수 있습니다.

```text

logs/

*.log

*.gz

*.csv

node_modules/

.venv/

dist/

build/

```

다만 파일 감시 제외와 검색 제외는 서로 다른 기능입니다. `.ignore`는 검색 도구가 파일을 건너뛰도록 하는 규칙이고, `files.watcherExclude`는 변경 감시 대상을 제어합니다. 검색에서 제외했다고 해서 파일 감시까지 자동으로 중단되는 것은 아니므로 두 부분을 별도로 확인해야 합니다. 프로젝트나 VS Code 버전에 따라 `.gitignore`, 검색 설정, `.ignore`의 적용 범위가 다르게 보일 수 있으므로 실제 검색 결과로 확인하는 것도 필요합니다.

원격 세션에서는 확장도 최소화하는 편이 좋습니다. Remote-SSH와 언어 지원에 필요한 Python 같은 확장만 켜고, GitLab 연동, ESLint, Prettier, 테마·아이콘팩처럼 서버에서 반드시 실행할 필요가 없는 확장은 원격 호스트에서 비활성화할 수 있습니다. 확장을 완전히 삭제하지 않고 원격에서만 끄면 로컬 개발 환경의 구성을 유지할 수 있습니다.

설정만으로 부족할 때는 서버 운영 정책을 보조 수단으로 쓴다

워크스페이스를 줄이고 확장을 정리해도 특정 프로세스가 계속 서버 자원을 차지한다면 운영체제 수준에서 우선순위를 낮출 수 있습니다. `renice`는 프로세스의 CPU 스케줄링 우선순위를 낮추는 데 사용하고, `ionice`는 디스크 I/O 우선순위를 조정하는 데 활용할 수 있습니다.

이 방법은 VS Code Server를 빠르게 만드는 설정이 아닙니다. 같은 서버에서 nginx나 gunicorn 같은 서비스가 실행 중일 때 개발 도구가 핵심 서비스의 자원을 빼앗지 않도록 완충하는 대응에 가깝습니다. 프로세스 ID를 잘못 지정하면 다른 서비스에 영향을 줄 수 있으므로 적용 전 `ps`, `pstree` 등으로 대상을 확인해야 합니다.

필요하다면 `cpulimit`이나 cgroup으로 CPU 쿼터를 제한할 수도 있지만, 제한이 너무 강하면 확장 초기화와 검색이 지나치게 느려질 수 있습니다. 여러 사용자가 공유하는 서버라면 개인 설정으로 해결할 문제인지, 서버 전체의 자원 정책으로 다룰 문제인지 먼저 구분해야 합니다.

적용 후에는 CPU 최고치보다 안정화 속도를 본다

해결 여부는 접속 직후의 순간적인 최고치만 보고 판단하기 어렵습니다. 설정 적용 전에는 CPU가 100% 이상 올라갔지만, 자료의 적용 후 결과는 약 40% 이하로 잠시 치솟은 뒤 곧 안정화되는 양상이었습니다. nginx와 gunicorn 등 서버의 주요 서비스에도 영향이 거의 없었습니다.

특히 워크스페이스를 코드 폴더로 좁혔을 때는 접속 직후의 스파이크 자체가 거의 사라졌습니다. 이는 모든 자동 기능을 끄는 것보다 감시·검색 대상의 규모를 줄이는 방법이 우선이라는 점을 보여줍니다.

적용할 때는 한 번에 모든 설정을 바꾸기보다 다음 순서가 원인 파악에 유리합니다. 먼저 워크스페이스를 좁히고, 그다음 로그와 생성물을 검색에서 제외합니다. 이후에도 문제가 남으면 확장을 줄이고 Git·TypeScript·자동 업데이트 설정을 조정한 뒤, 마지막으로 파일 감시 전체 차단이나 프로세스 우선순위 조정을 검토하면 됩니다.

Remote-SSH의 CPU 폭주는 대체로 원격 개발 기능 자체보다 “너무 많은 파일과 확장이 동시에 초기화되는 구조”에서 시작합니다. 서버에서 꼭 필요한 코드만 열고, 로그·백업·의존성·빌드 산출물을 감시와 검색에서 분리하는 것이 기능 손실과 서버 부담 사이의 균형이 가장 좋습니다. 전체 감시 차단은 효과가 빠른 대신 불편도 크므로 진단용으로 사용한 뒤 필요한 범위만 다시 허용하는 방식이 안전합니다.