SSH로 접속했을 뿐인데, 서버에 IDE가 깔린다고요?
VS Code 쓰시는 분들 대부분이 Remote-SSH 익스텐션 한 번쯤 써보셨을 거예요. 왼쪽 아래 초록색 버튼 누르고 서버 주소 입력하면, 마치 내 노트북에 있는 폴더처럼 원격 서버의 코드를 열어서 편집할 수 있죠. 터미널도 열리고, 자동완성도 되고, 디버거도 붙어요. 너무 편해서 그냥 '아, SSH로 연결해서 파일 읽어오는 거겠지' 하고 넘어가기 쉬운데요.
Fly.io 블로그에서 이 과정을 파헤친 글이 나왔어요. 제목부터 '바나나 같다'(bananas, 영어로 '미쳤다', '어이없다'는 뜻의 속어예요)라고 붙였을 만큼, 실제로 뒤에서 벌어지는 일이 생각보다 훨씬 큽니다. 결론부터 말하면, Remote-SSH는 SSH를 '연결 통로'로만 쓰고, 그 통로를 통해 원격 서버에 VS Code의 절반을 통째로 설치해서 실행하고 있거든요.
실제로 벌어지는 일, 순서대로 볼게요
Remote-SSH로 접속 버튼을 누르면 이런 순서로 진행돼요.
먼저 VS Code가 진짜로 ssh 명령을 실행해서 서버에 로그인해요. 여기까진 평범하죠. 그런데 로그인 직후에 꽤 긴 셸 스크립트를 서버에서 실행합니다. 이 스크립트가 서버의 운영체제와 CPU 아키텍처(x86인지 ARM인지)를 확인하고, 홈 디렉터리 아래 ~/.vscode-server 폴더를 뒤져서 '지금 내 노트북에 설치된 VS Code와 똑같은 커밋 해시의 서버'가 이미 있는지 찾아요.
없으면 어떻게 하냐면, 서버가 직접 인터넷으로 마이크로소프트 업데이트 서버에 접속해서 tarball(압축 파일)을 내려받아요. 이 안에는 Node.js 런타임이 통째로 들어 있고, VS Code의 핵심 로직 중 UI를 제외한 부분이 다 들어 있어요. 크기가 수십 MB에서 100MB 넘게 나가요. 이걸 압축 풀고, node 프로세스로 서버를 띄워요. 이 서버는 로컬 포트나 유닉스 소켓에서 대기하면서 접속 토큰을 출력하고, VS Code는 그 값을 읽어서 SSH 포트 포워딩으로 자기 노트북과 연결해요.
여기서부터가 핵심인데요. 이후 여러분이 하는 거의 모든 작업은 이 원격 node 프로세스가 처리합니다. 익스텐션 호스트(익스텐션들이 실행되는 프로세스)가 서버 쪽에서 돌고, 파이썬이나 TypeScript 언어 서버(자동완성과 오류 표시를 담당하는 별도 프로그램)도 서버에서 돌고, 파일 변경 감시(file watcher)도 서버에서 돌고, 여러분이 여는 터미널도 SSH 세션이 아니라 이 node 서버가 자식 프로세스로 띄운 셸이에요.
이게 뭐냐면, VS Code는 처음부터 '화면을 그리는 클라이언트'와 '실제 일을 하는 서버'로 나뉘게 설계돼 있어요. 평소엔 둘 다 내 컴퓨터에서 도는데, Remote-SSH를 쓰면 서버 절반만 뚝 떼어서 원격 머신에 옮겨 심는 거예요. 그러니까 SSH는 그저 그 둘 사이의 케이블 역할이고요. 마치 '건물 구경만 하고 오겠다'고 들어가서는, 안에 사무실을 차리고 직원까지 채용해 놓고 나오는 셈이죠.
그래서 뭐가 문제인데요?
편한 건 맞아요. 그런데 이 구조 때문에 생기는 부작용이 꽤 많아요.
메모리를 많이 먹어요. node 서버 자체에 익스텐션 호스트, 언어 서버까지 합치면 가볍게 수백 MB, 큰 프로젝트에서 TypeScript 서버까지 돌면 1~2GB도 넘어가요. Fly.io 같은 곳에서 256MB짜리 작은 머신을 띄워 놓고 VS Code로 접속하면 그 순간 메모리 부족으로 죽어 버리는 이유가 바로 이거예요. 라즈베리파이나 AWS 프리 티어 t2.micro에 붙였다가 서버가 먹통 되는 경험도 같은 원인이고요.
서버가 인터넷에 나갈 수 있어야 해요. tarball을 서버가 직접 받아오니까, 외부 접속이 막힌 폐쇄망 서버에서는 기본 설정으론 아예 접속이 안 돼요. 그리고 VS Code를 업데이트할 때마다 커밋 해시가 바뀌니까 서버마다 매번 새로 다운로드가 일어나고, 옛 버전들이 ~/.vscode-server 안에 쌓여요.
운영체제 버전을 가려요. 이 서버가 Node.js 기반이라 특정 버전 이상의 glibc(리눅스 기본 C 라이브러리)를 요구해요. 그래서 CentOS 7 같은 오래된 배포판은 어느 순간부터 아예 접속이 안 되기 시작했죠. 서버 쪽에서 원하는 게 전혀 없는데도 클라이언트 IDE 때문에 서버 OS를 갈아야 하는 이상한 상황이 생기는 거예요.
끊어도 안 죽어요. VS Code 창을 닫아도 원격 node 프로세스는 한동안 살아 있어요. 여러 사람이 같은 서버에 접속하면 각자의 .vscode-server와 각자의 프로세스가 따로 생기고요. 게다가 파일 워처가 큰 디렉터리(node_modules 같은)를 통째로 감시하면 CPU를 계속 점유해요.
다른 도구들은 어떻게 하나요?
사실 VS Code만 이러는 건 아니에요. JetBrains Gateway는 오히려 더 무거워요. IntelliJ의 백엔드 전체를 원격에 설치해서 JVM으로 띄우니까 메모리 요구량이 몇 GB 단위죠. 최근 나온 Zed 에디터의 원격 개발 기능도 결국 원격에 작은 서버 바이너리를 올려서 쓰는 구조예요. 요즘 에디터들은 다 이 방향으로 수렴하고 있어요.
왜 그럴까요? 자동완성이나 심볼 검색 같은 기능은 코드 파일 전체를 읽고 인덱싱해야 하는데, 이걸 SSH 너머로 파일 하나하나 읽어오면 너무 느리거든요. 그래서 '두뇌를 코드 옆에 두자'는 결정을 한 거예요. 반대편에는 옛날 방식이 있어요. vim이나 emacs를 서버에서 직접 실행하고 tmux로 세션을 유지하는 방식, 또는 sshfs나 rsync로 원격 디렉터리를 로컬에 마운트하고 로컬 에디터로 여는 방식이죠. 이 방식은 서버에 아무것도 설치하지 않아서 가볍지만, 편의성은 확실히 떨어져요. 결국 '편의성 vs 서버 자원' 트레이드오프인 셈이에요.
한국 개발자에게 주는 시사점
당장 실무에서 체크할 것들이 있어요.
작은 인스턴스에 붙이실 거라면 최소 1GB, 편하게는 2GB 이상의 메모리를 확보하세요. 안 되면 스왑이라도 잡아 두시고요. 폐쇄망 회사라면 설정에서 remote.SSH.localServerDownload 옵션을 켜서 노트북이 대신 다운로드해서 서버로 올리게 하거나, tarball을 수동으로 옮겨 설치하는 절차를 팀 위키에 정리해 두면 좋아요. 파일 워처가 CPU를 먹는다면 files.watcherExclude 설정에 node_modules, .git, 빌드 산출물 폴더를 넣어 주세요.
그리고 다른 사람이 관리하는 서버에 접속할 때는 홈 디렉터리에 수백 MB짜리 폴더가 생긴다는 걸 기억하세요. 운영 서버에 무심코 접속했다가 디스크 경고 받는 경우가 실제로 있거든요. Dev Containers 기능도 원리가 똑같아서 컨테이너 안에 같은 서버가 설치돼요. 도커 이미지 용량이 이상하게 늘었다면 그 때문일 수 있어요.
정리하며
한 줄로 정리하면, VS Code Remote-SSH는 'SSH로 파일을 여는 도구'가 아니라 'SSH를 통해 원격 서버에 IDE 백엔드를 설치하고 실행하는 도구'예요. 편리함의 대가로 서버의 메모리, 디스크, 인터넷 접근, OS 버전까지 요구한다는 걸 알고 쓰면 훨씬 덜 당황하게 돼요.
여러분은 원격 개발할 때 어떤 방식을 쓰시나요? Remote-SSH의 편의성이 이 정도 자원 비용을 감수할 만하다고 보시나요, 아니면 tmux와 vim으로 가볍게 가는 게 낫다고 보시나요?
🔗 출처: Hacker News