Watch at Ease세상을 읽고, 일상의 답을 찾다.

기술 · 실용 가이드

VS Code Remote SSH가 서버를 계속 다운로드하나요? 삭제 전에 설치 반복 구간부터 확인하세요

반복 다운로드는 이전 시작이 받아들여지지 않았다는 뜻이며, 모든 기존 설치를 지워도 된다는 증거가 아닙니다. 전체 로그를 정확한 VS Code 커밋과 연결하고 다운로드·압축 해제·시작·전달을 따로 확인해 입증된 실패 구간만 고칩니다.

셸, 다운로드·전송, 압축 해제, 서버 시작, SSH 전달을 다섯 증거 구간으로 나눈 원본 기술 개념 일러스트.
원본 진단 개념 일러스트: 전체 로그를 보존하고 마지막 성공 구간을 찾아 입증된 첫 실패만 고칩니다. Watch at Ease

Remote-SSH가 VS Code Server를 거듭 다운로드하면 원격 설치 디렉터리를 비우고 싶어집니다. 그러나 원인을 보여 주는 로그와 정상 작동하는 커밋 설치까지 잃을 수 있습니다. 실제 실패 지점은 네트워크, 도구 누락, 저장 공간, 소유권, 압축 해제, 시작 출력, SSH 전달 중 어디든 될 수 있습니다. 반복은 클라이언트가 이전 부트스트랩을 받아들이지 않았다는 사실만 보여 줍니다.

통제된 연결 시도 한 번을 감사 대상으로 삼으세요. 클라이언트 커밋과 Remote-SSH 로그에 표시된 원격 경로를 기록하고 증거를 보존한 뒤 부트스트랩 순서대로 확인합니다. 마지막 성공 구간과 첫 실패 구간을 모두 확인해야 수리할 근거가 생깁니다.

변경하기 전에 한 번의 시도 증거를 고정하세요

Remote-SSH 출력 채널을 열고 로그인 메시지가 숨겨질 수 있으면 로그인 터미널을 표시한 뒤 한 번 연결합니다. 재시도 전에 전체 출력을 저장하고 호스트 별칭, 로컬 VS Code 버전과 커밋, 확장 버전, 원격 플랫폼·아키텍처, 설치 경로, 다운로드 경로, 아카이브 또는 커밋 이름, 최종 오류를 기록하세요. 중요한 전환은 앞부분에 있을 수 있어 마지막 줄 스크린샷만으로는 부족합니다.

커밋은 설치 식별자의 일부입니다. 클라이언트가 업데이트되어 다른 서버 빌드를 요구하는 것은 정상일 수 있습니다. 같은 커밋을 반복해서 다운로드한다면 설치 또는 승인 과정이 완료되지 않은 것입니다. 이슈 #11269는 느린 연결에서 발생하는 비용과 무차별 삭제가 진단 가능한 문제를 다시 전체 전송으로 바꾸는 이유를 보여 줍니다.

서버 트리를 건드리기 전에 읽기 전용으로 목록을 확인합니다. 가능하면 로그의 정확한 경로를 쓰세요. `df -h "$HOME"`, `df -i "$HOME"`, `id`, `find ~/.vscode-server -maxdepth 4 -type d -print 2>/dev/null`로 블록 공간, inode 고갈, 예상 밖 소유권, 여러 커밋 설치를 파일 변경 없이 살펴볼 수 있습니다.

구간 1: 셸과 필수 조건을 입증하세요

다른 시작 파일을 읽을 수 있는 대화형 로그인만 믿지 말고 같은 SSH 대상으로 비대화형 검사를 합니다. `ssh your-host 'printf "shell-ok\n"; command -v bash; command -v tar; command -v curl || command -v wget; uname -s; uname -m; getconf GNU_LIBC_VERSION 2>/dev/null || true'` 출력을 연결 로그와 함께 보관하세요. Bash 또는 tar가 없거나, curl과 wget이 모두 없거나, 런타임이 지원되지 않으면 필수 조건 실패이며 같은 아카이브 재다운로드로 해결되지 않습니다.

비대화형 시작 파일이 부트스트랩 표식 앞에 배너, 디버그 텍스트, 오류를 출력하는지 확인하세요. 오래된 Stack Overflow 포트 구문 분석 질문은 일반 SSH가 작동해도 Remote-SSH가 구조화된 시작 출력을 읽지 못할 수 있음을 보여 줍니다. 장식성 출력은 대화형 셸에서만 나오게 한 뒤 통제된 연결을 한 번 재시도합니다.

셸과 도구가 통과했으면 계속 바꾸지 마세요. 해당 구간을 입증된 것으로 표시하고 다음으로 이동합니다. 감사는 원인 범위를 좁히는 작업이며 무관한 설정을 더하는 과정이 아닙니다.

구간 2: 다운로드 경로를 선택하고 입증하세요

원격 호스트가 직접 서버를 다운로드할 때는 `update.code.visualstudio.com`과 `vscode.download.prss.microsoft.com`으로 HTTPS 통신이 필요합니다. 원격에서 사용 가능한 도구로 DNS와 TLS를 확인하되 HTTP 상태를 신중히 해석하세요. 먼저 이름 해석, 라우팅, 인증서 협상을 입증하며 사이트 기본 주소를 아카이브 URL로 가정하지 않습니다.

원격 외부 통신은 차단되지만 로컬 컴퓨터가 다운로드할 수 있으면 로컬 VS Code 사용자 설정에 `"remote.SSH.localServerDownload": "always"`를 넣어 로컬 다운로드 후 전송을 선택합니다. 확장 전체 설정이므로 다른 SSH 대상에도 영향을 줄 수 있어 이전 값을 기록하고 복원하세요. 이미 로컬 전송이 로그에 있다면 원격 프록시를 바꾸지 말고 전송과 목적지를 확인합니다. 원격 다운로드가 정상이라면 강제 전송은 구간 하나를 더 만듭니다.

진행률을 설치 완료로 보지 마세요. 아카이브 다운로드 완료, 목적지 파일 존재, 압축 해제 단계 진입을 기록합니다. 압축 해제 표식 없이 반복되면 다운로드 또는 전송 문제이고, 다운로드 완료 뒤 실패하면 다음 구간 문제입니다.

구간 3: 공간·소유권·압축 해제를 확인하세요

홈 디렉터리에 몇 GB가 남아도 inode는 고갈될 수 있습니다. `df -h`와 `df -i`를 모두 확인하고 서버 상위 디렉터리와 정확한 커밋 경로의 소유권을 살펴보세요. 계정 전체의 소유권을 재귀 변경하지 말고 잘못된 소유권이 입증된 경로만 처리하며 발생 원인을 먼저 확인합니다.

아카이브가 있으면 tar 실행 가능 여부와 로그에 표시된 압축 해제 대상의 쓰기 권한을 확인합니다. 커밋과 실패를 기록할 때까지 부분 설치 디렉터리를 보존하세요. Remote-SSH 세대마다 배치가 달라지므로 모두 `bin/<commit>` 구조라고 가정하지 말고 현재 로그의 경로를 사용합니다.

전송 성공 후 압축 해제 오류는 다시 다운로드해서 고쳐지지 않습니다. 입증된 공간, inode, 권한 또는 tar 문제를 고친 뒤 같은 커밋으로 한 번 재시도하세요. 기대하는 전환은 아카이브 존재에서 서버 트리 채움과 시작 명령 표시로 이어지는 것입니다.

구간 4: 서버 시작과 SSH 전달을 구분하세요

압축 해제가 성공하면 시작 명령과 서버의 구조화된 출력을 찾습니다. 수신 대기 엔드포인트를 보고하기 전에 프로세스가 종료되면 종료 상태와 주변 표준 오류를 보관하세요. 임시 디렉터리 권한과 시작 스크립트 출력 등 실제로 전달된 원격 환경을 확인합니다. 서버 시작을 입증하기 전에 터널 실패로 단정하지 않습니다.

서버가 수신 엔드포인트를 보고했지만 클라이언트가 이용하지 못하면 SSH 전달로 이동합니다. 공식 문서는 TCP 모드의 AllowTcpForwarding과 Unix 소켓 모드의 AllowStreamLocalForwarding을 구분합니다. 관리자에게 실제 엔드포인트 모드의 정책을 확인하세요. `remote.SSH.useLocalServer: false`는 로컬 서버 경로가 오류를 가릴 때 진단을 비교하는 설정이며 전달 권한을 부여하지 않습니다.

'failed to parse remote port'는 분류 단서이지 모든 환경의 근본 원인이 아닙니다. 저장한 출력과 예상 시작 표식을 비교하세요. 불필요한 셸 텍스트, 서버 조기 종료, 차단된 터널에는 서로 다른 조치가 필요합니다.

입증할 수 있는 최소 조치를 선택하세요

되돌릴 수 있는 변경부터 선택합니다. 필수 도구 보완, 정상 다운로드 경로 선택, 불필요함이 확인된 공간 정리, 정확한 경로 소유권 수정, 비대화형 셸 출력 수정, 필요한 전달 정책 요청 등이 해당합니다. 한 항목을 바꿀 때마다 한 번 연결하고 첫 실패 구간이 이동했는지 기록하세요.

공식 Kill VS Code Server on Host 명령은 실제로 멈춘 인스턴스에 도움이 되지만 범위가 넓은 복구 작업이며 진단을 대신하지 않습니다. 실행 전에 전체 출력을 보관하고 정상 작동하는 다른 커밋 설치까지 제거되는지 확인합니다.

정확한 커밋 설치 하나가 불완전하다고 입증되면 먼저 관련 원격 창을 닫고 서버 프로세스나 다른 세션이 해당 인스턴스를 사용하지 않는지 확인합니다. 로그를 보존한 뒤 정확히 대응된 디렉터리만 격리하고 `.vscode-server` 전체를 지우지 마세요. 같은 클라이언트 커밋으로 한 번 다시 연결해 새 설치를 확인합니다. 정상 상태와 로그를 확보하기 전에는 격리본을 보관하세요. 경로가 불분명하거나 다른 세션이 활동 중이면 멈춥니다.

반복을 놓치지 않는 완료 조건을 정하세요

창이 한 번 열렸다는 사실만으로는 부족합니다. 연결을 끊고 같은 로컬 클라이언트 커밋으로 재연결합니다. 두 번째 연결은 전체 아카이브를 다시 전송하지 않고 기존 설치를 재사용해야 합니다. 원격 터미널에서 무해한 명령을 실행하고 원격 확장 호스트의 연결이 유지되는지 확인하세요.

감사 행에 시간, 클라이언트 커밋, 원격 플랫폼·아키텍처, 다운로드 경로, 설치 경로, 가용 블록과 inode, 필수 도구 버전, 마지막 성공 구간, 조치, 첫 번째·두 번째 결과, 전체 재다운로드 여부를 남깁니다. 다음 재발은 다시 지우고 시도하는 대신 기록과 비교할 수 있습니다.

관찰 가능한 구간이 모두 통과해도 같은 커밋이 반복되면 보존한 전체 로그로 상위 지원에 보고합니다. 최소 재현 가능한 호스트 설정을 포함하고 비밀 정보는 가리세요. 구간 설명에 필요하지 않은 호스트명, 사용자명, 토큰, 비공개 경로는 공개하지 않습니다.

같은 VS Code 커밋의 두 연결을 비교하고 설치 격리 전 중단 조건을 표시한 원본 기술 개념 일러스트.
원본 감사 개념 일러스트: 두 번째 연결의 같은 커밋 재사용을 확인하고 식별이나 사용 상태가 불명확한 인스턴스는 보존합니다. Watch at Ease