VSCode의 SSH 원격 개발은 원격에 Node 바이너리를 깔고 파일·셸·PTY를 맘대로 부리는 구조였다

에이전트에 SSH를 줄 땐 걔가 뭘 하는지 내가 다 보고 이해하고 싶음. 내 대신 칠 수 있는 CLI 명령만 '타이핑'하게 두는 게 목표인데, opencode에 qwen 3.8-flash-next나 deepseek v4 0731 정도면 그럭저럭 잘 되더라.

다들 너처럼만 했으면 AI 안전이 이만큼 큰 문제가 안 됐을 듯. 기본 인간 패턴이 쏘고 잊기라 금방 선을 넘음.

제목에 (2025)가 빠졌는데, VSCode SSH 에이전트는 원격 개발의 천사임. fly.io가 단점이라 적은 게 전부 장점이고 여러 팀에서 써봤는데 문제 한 번 없었음. SSH 접근을 원하는 대로 쪼개서 제한할 수도 있고.

원격 툴로 원격 편집하려면 이게 맞는 아키텍처임. 정말 잘 돼서 씀. SSH 끊길 때 재연결 버그가 오래됐지만 그건 아키텍처 잘못은 아님.

근데 글이 지적한 그 비보안성은 아무것도 달라진 게 없음. 문제는 원격 호스트가 이 프로토콜로 로컬 호스트를 컨트롤할 수 있다는 거임.

리눅스 관리자 입장에서 VSCode ssh는 진짜 짜증남. MotD를 안 띄워서 사용자 공지를 못 보여주고 세션 재사용도 안 해서 몇 달치 열린 세션이 수십 개씩 쌓임. 강제로 쫓아내는 스크립트까지 써야 했음.

VSCode 정신은 가볍게, 노트패드++에 터미널 붙인 느낌이었는데 개발자들이 길을 잃음. 기능 덩어리 SSH 에이전트가 필요하면 비주얼 스튜디오를 쓰라고.

나는 출시일부터 매일 씀. 처음엔 도커가 맥을 갉아먹어서, 지금은 vim/nano가 싫어서 SSH 클라이언트 겸 파일 편집기로 씀. 다 한 IDE에서 되는 게 큼.

트램프도 원격에서 셸 명령을 부리니 할 수 있는 건 거의 비슷함. 보안판 이름은 RAT고, SSH 자체가 그 전형이니까 왜 저렇게 놀라는지 모르겠음.

맞음, 그냥 훨씬 빠를 뿐. 대신 원격에 독점 바이너리 두는 비용이 있고, tramp-rpc는 원격에 Rust 클라이언트를 두는 방식이라 vscode-over-ssh보다 빠르다고 함.

다운보트 먹는 이유를 모르겠음. 저렇게 하는 클라이언트가 꽤 있고 JetBrains도 똑같이 함.

차이는 아예 SSH 에이전트가 존재한다는 점임. Emacs는 기본 셸만 쓰고, 사용자가 명시적으로 안 한 방식으로 원격 파일시스템을 바꾸면 찝찝한 거임. Node 바이너리는 아주아주 찝찜.

아님, TRAMP는 한 방향임. 원격 쪽이 로컬 쪽을 돌아다닐 수 없음. 그래서 전혀 다름.

이 아키텍처는 나한테 괜찮은데, 손상된 원격이 내 로컬에서 마음대로 하는 역방향은 안 괜찮음.

그 역방향도 실제로 됨. Remote-SSH 확장 페이지 보안 노트에 손상된 원격이 VS Code 원격 연결로 로컬에서 코드를 실행할 수 있다고 써 있음.

너가 안 괜찮다고 한 바로 그 부분이 글 전체 요점임.

이 확장은 VSCodium에선 아예 안 되고 대안도 마땅치 않음.

그게 오히려 행운인 줄 알라. open-vsx의 jeanp413.open-remote-ssh가 대안인데, MS가 독점화하기 전 확장을 포크한 거라 잘 굴러감. 확장 관리자에서 ssh로 찾으면 1, 2번째로 나옴.

에이전트는 원격 개발 박스에서 돌라고 만든 거임. 포트 터널링도 기능이니까 프로덕션 서버에 깔고 놀라면 그건 사용자 잘못임.

근데 그게 로컬 클라이언트까지 원격 박스의 연장으로 만들어버림. 원격 접속에 대한 기대와 정면으로 어긋나는 부분임.