첫 단계는 캐시 삭제가 아니라 시스템 터미널에서 기본 SSH를 확인하는 일입니다. 그다음 VS Code Remote SSH 로그를 읽어 인증, 포워딩, VS Code Server 설치, 원격 노드 자원 중 어느 계층에서 멈추는지 나눠야 합니다. 서버 구성 요소가 반복해서 시작되지 않고 재시작 뒤에도 복구되지 않으면 계속 재시도하지 말고 노드 기준선을 고치거나 다른 원격 Mac으로 바꾸는 편이 안전합니다.
이 글은 Windows나 Linux를 주 장비로 사용하면서 macOS 도구 체인이 필요한 개발자를 위한 내용입니다. 공유 원격 Mac을 관리하는 DevOps 엔지니어, 그리고 클라우드 맥 임대 환경의 복구 가능성을 검수하는 플랫폼 담당자에게도 적합합니다.
SECTION 01 고장 지점을 먼저 나누는 시간표
장애를 한 번에 고치려 하지 말고 다음 순서로 기록합니다. 각 단계의 결과가 다음 점검의 출발점이 됩니다.
| 확인 시점 | 확인 대상 | 남겨야 할 증거 | 다음 판단 |
|---|---|---|---|
| 시작 | 시스템 터미널의 SSH | 접속 성공 여부, 오류 문구, 사용자와 주소 | 실패하면 VS Code보다 먼저 기본 SSH를 복구합니다 |
| 그다음 | Remote SSH 출력 | 인증, 포워딩, 서버 설치 중 마지막 단계 | 터미널과 편집기의 설정 차이를 찾습니다 |
| 이후 | 원격 계정 환경 | 서버 파일, 셸 출력, 실행 프로세스, 저장 공간 | VS Code Server 문제인지 노드 문제인지 구분합니다 |
| 마지막 | 재시작 뒤 기능 | 일반 SSH, 작업 폴더, Git, 실제 빌드 | 복구, 재구축, 노드 교체 중 하나를 결정합니다 |
VS Code 공식 문서는 Remote SSH가 원격 호스트에 VS Code Server를 설치하고 실행하는 흐름을 설명합니다. 따라서 네트워크에 도달했다는 사실만으로 편집기 연결이 끝났다고 판단하면 안 됩니다. Remote SSH 공식 연결 흐름과 공식 시스템 요구 사항을 기준으로 원격 운영체제와 계정 환경도 따로 확인해야 합니다.
주의: 원격 Mac의 전원 상태나 포트 응답은 “SSH 로그인이 가능하다”는 증거가 아닙니다. macOS에서 Remote Login이 켜져 있고 접속 허용 계정에 현재 사용자가 포함되어야 SSH와 SFTP를 받을 수 있습니다. Apple Remote Login 안내를 확인한 뒤 서비스 상태를 기록합니다.
시스템 터미널에서 남길 기록
계정, 주소, 키 이름과 프로젝트 경로는 실제 값 대신 다음과 같은 자리표시자로 관리합니다.
ssh -vvv -i ~/.ssh/<KEY_FILE> <USER>@<REMOTE_MAC>
이 명령은 VS Code를 거치지 않는 기준선입니다. 접속 자체가 실패하면 원격 주소, 허용 계정, 키 권한, 호스트 지문과 Remote Login 상태를 확인합니다. 관리 콘솔이나 다른 운영 경로가 없다면 sshd 설정을 바꾸거나 원격 로그인 서비스를 재시작하지 않는 편이 좋습니다. 변경 뒤 현재 세션까지 끊길 수 있기 때문입니다.
SECTION 02 터미널은 되는데 편집기만 실패하는 이유는 무엇인가요?
터미널 SSH가 성공했는데도 VS Code Remote SSH가 연결되지 않는다면, 먼저 두 클라이언트가 정말 같은 조건인지 비교합니다. VS Code가 실제로 호출한 SSH 실행 파일, 사용한 설정 파일, 사용자 이름, IdentityFile, 포트와 프록시 설정을 Remote SSH 출력에서 확인합니다.
| 비교 항목 | 터미널에서 확인할 값 | Remote SSH에서 확인할 값 | 위험한 임시 조치 |
|---|---|---|---|
| 사용자와 주소 | 명령줄의 계정과 호스트 | 대상 선택 화면과 로그 | 다른 계정으로 반복 접속 |
| 키 인증 | 실제 키 파일과 키 암호 입력 | IdentityFile과 인증 대기 |
개인 키를 여러 장치에 공유 |
| 호스트 확인 | 지문 확인 결과 | 지문 또는 대화형 입력 대기 | 호스트 검증을 끄기 |
| 셸 환경 | 로그인 뒤 출력 | 서버 설치 전후 출력 | 시작 파일의 모든 내용을 삭제 |
로그에 암호, 키 암호, 호스트 지문 확인을 기다리는 흔적이 있으면 인증 대화가 VS Code 안에서 진행되지 않는 상황일 수 있습니다. 해결책은 검증을 끄는 것이 아니라 클라이언트 설정을 통일하고, 필요한 입력이 비대화형 연결에서 처리되도록 정리하는 것입니다. 개인 키를 공유하거나 호스트 검증을 끄면 문제가 사라진 것처럼 보여도 운영 환경의 신뢰 경계를 약화시킵니다.
첫 번째 분기: 기본 SSH가 실패하는 경우
다음 조건을 만족하면 편집기 설정을 건드리기 전에 원격 Mac의 접근 경로를 고칩니다.
- 시스템 터미널의 상세 로그에서 인증 전 단계가 실패합니다.
- macOS의 Remote Login 설정이나 허용 계정을 확인할 수 없습니다.
- 주 주소와 실제 연결 주소가 다르거나 동적으로 바뀝니다.
- 관리 콘솔, 별도 운영자 계정 같은 복구 경로가 없습니다.
이때는 macOS Remote Login과 SSH 키 설정 안내를 기준으로 계정과 키를 다시 대조합니다. 원격 호스트가 연결마다 달라지는 구조라면 이전 연결의 주소나 소켓을 재사용하는 설정이 원인이 될 수 있습니다. 동적 장치 연결에 관한 공식 안내처럼 연결 대상의 고정 여부부터 확인해야 합니다.
두 번째 분기: 기본 SSH는 성공하는 경우
기본 SSH가 성공하면 Remote SSH 로그에서 다음 멈춤 지점을 찾습니다.
- 인증 완료 뒤 포워딩 채널이 거부됩니다.
administratively prohibited가 기록됩니다.- 로컬 포트 충돌이나 소켓 포워딩 실패가 나타납니다.
- VS Code Server 다운로드, 압축 해제 또는 실행에서 중단됩니다.
- 서버는 실행되지만 원격 확장 호스트나 프로젝트 프로세스가 종료됩니다.
이 분류는 “네트워크가 느리다”는 단일 원인보다 정확합니다. Remote SSH는 기본 셸뿐 아니라 서버 프로세스와 통신 채널도 필요하기 때문입니다.
SECTION 03 포워딩 거부와 서버 설치 실패는 어떻게 구분하나요?
인증 뒤 administratively prohibited 또는 채널 생성 실패가 보이면 포워딩 정책을 먼저 확인합니다. VS Code 공식 문서는 원격 호스트에서 TCP 포워딩을 허용해야 하는 경우와 확인 절차를 안내합니다. TCP 포워딩 점검 안내를 참고하고, AllowTcpForwarding이나 Unix 소켓 포워딩 설정은 OpenSSH 설정 설명서와 대조합니다.
sshd_config를 바꾸면 다른 사용자와 기존 CI 연결에도 영향을 줄 수 있습니다. 설정을 바꾸기 전에는 현재 SSH 세션과 별도 관리 경로를 유지합니다. 변경 뒤에는 일반 SSH, Remote SSH, 이미 운영 중인 자동화 연결을 모두 시험해야 합니다. 개발자 접속만 복구되고 CI가 끊기면 전체 장애는 해결되지 않은 것입니다.
반대로 출력에 다운로드 실패, 파일 누락, 실행 권한 문제 또는 서버 시작 실패가 있으면 서버 구성 요소 계층으로 이동합니다. 원격 계정의 디렉터리 상태와 셸 시작 파일을 확인합니다. 로그인 시 불필요한 문장을 출력하는 셸 설정은 서버 초기화 통신을 방해할 수 있습니다. 원격 노드가 외부에 접근하지 못하는 환경이라면 다운로드 단계에서 멈출 수 있습니다.
VS Code Server failed to start를 다루는 순서
다음 순서를 지키면 파괴적인 정리를 늦출 수 있습니다.
- Remote SSH 출력에서 마지막 성공 단계와 첫 실패 문장을 저장합니다.
- 원격 로그인 터미널에서 서버 디렉터리와 실행 프로세스를 확인합니다.
- 셸 시작 파일의 출력, 계정 권한, 저장 공간과 실행 경로를 점검합니다.
- 원격 노드의 외부 연결 제한과 프록시 변수를 확인합니다.
- 원인이 서버 파일 손상으로 좁혀질 때만 서버 정리와 재설치를 선택합니다.
공식 배포판은 호스트에서 VS Code Server를 정리하는 방법을 안내하지만, 이 작업은 해당 계정의 기존 원격 세션을 끝낼 수 있습니다. 서버 정리 절차를 실행하기 전 작업 중인 터미널과 미저장 변경 사항을 확인합니다.
경험칙: 설치 단계에서 멈춘다고 즉시 서버 폴더를 지우면 원인 증거를 잃을 수 있습니다. 다운로드 실패와 실행 실패는 복구 방법이 다르므로 먼저 로그, 디렉터리 상태와 셸 출력을 보존합니다.
SECTION 04 연결은 되지만 자주 끊기거나 확장이 작동하지 않으면?
연결 이후의 문제는 SSH 링크, 원격 확장 호스트, 노드 자원, 프록시 환경을 분리해서 봅니다. 여러 창이 동시에 인증을 요구한다면 연결 재사용 설정과 키 인증 흐름을 살핍니다. 연결마다 다른 노드가 할당된다면 주소와 작업 공간이 실제로 같은 호스트를 가리키는지도 확인합니다.
확장이 작동하지 않을 때는 확장 호스트의 로그와 해당 확장의 원격 의존성을 확인합니다. 로컬에서는 되지만 원격에서만 실패하는 확장은 CPU 종류, 운영체제 라이브러리, 실행 권한 또는 원격 경로 문제를 가질 수 있습니다. 노드 자원이 부족한 경우에는 프로세스 종료 기록, 저장 공간, 메모리 압박과 동시에 실행 중인 빌드를 확인해야 합니다.
보온 설정이나 프록시 변수를 무조건 추가하는 것도 위험합니다. 연결이 실제로 끊기는지, 셸은 살아 있지만 원격 확장 호스트만 종료되는지에 따라 조치가 달라집니다. 공식 Remote Development 문제 해결 문서의 로그 수집 순서를 따르되, 확인하지 않은 시간 초과 값을 임의로 넣어 문제를 가리지 않아야 합니다.
재시작 뒤 복구를 판정하는 이정표
수리가 끝났다고 판단하려면 같은 저장소에서 다음 기능을 순서대로 확인합니다.
- 새 연결을 만들고 작업 폴더를 엽니다.
- 원격 터미널에서 Git 상태와 브랜치 정보를 확인합니다.
- 파일 저장과 원격 확장 실행을 확인합니다.
- 실제 프로젝트의 검사 또는 빌드를 실행합니다.
- 클라이언트 연결을 끊었다가 다시 연결합니다.
- 원격 Mac을 재시작한 뒤 Remote Login과 VS Code Server를 다시 확인합니다.
- 같은 작업 폴더에서 다시 Git 작업과 빌드를 실행합니다.
이 과정에서 SSH만 복구되고 서버가 다시 시작되지 않으면 편집기 캐시 문제가 아닙니다. 서버 구성, 계정 환경, 저장 공간 또는 노드 기준선의 문제로 분류합니다.
SECTION 05 FAQ: 상황별 점검 기준
위의 절차를 한 줄로 줄이면, 터미널 SSH 실패는 접근 계층, 포워딩 거부는 호스트 정책, 설치 중단은 서버 구성 요소, 연결 후 종료는 확장 호스트와 자원 계층입니다. 재시작 뒤 같은 실패가 반복되면 로그를 지우며 재시도하지 말고 노드 교체 가능성을 검토합니다.
SECTION 06 수리와 노드 교체 중 무엇을 선택해야 하나요?
다음 조건 분기로 결정하면 감으로 환경을 갈아엎는 일을 줄일 수 있습니다.
- 기본 SSH와 Remote SSH가 모두 안정적이고 재시작 뒤 빌드까지 성공하면 현재 노드를 유지합니다.
- 기본 SSH는 안정적이지만 VS Code Server만 손상되었고 원인이 확인되면 세션 종료 위험을 알린 뒤 서버를 재설치합니다.
- 포워딩 정책 변경이 필요하고 다른 사용자나 CI에 영향이 있으면 운영 승인과 별도 복구 경로를 확보한 뒤 수정합니다.
- 재시작 뒤 Remote Login, 서버 실행 또는 프로젝트 환경이 반복해서 복구되지 않으면 캐시 삭제를 반복하지 말고 노드 기준선을 재구축하거나 다른 원격 Mac을 선택합니다.
- 물리 장치 접근, 장기 고정 자원 또는 무인 복구 경로가 반드시 필요하면 단순 임시 대여보다 전용 운영 방식을 비교합니다.
현재 쓰는 Windows, Linux 또는 일반 클라우드 서버는 macOS 전용 도구 체인을 제공하지 않거나, 별도 Mac을 붙일 때 네트워크 경로와 인증 구성을 직접 관리해야 하는 단점이 있습니다. 개인 Mac mini 서버는 초기 구매와 유지 관리, 재시작 뒤 원격 접근 복구를 직접 책임져야 합니다. 반면 VPSNIX의 원격 Mac 임대 방식은 테스트 기간에 실제 Mac 환경을 확보하고, 관리자 권한과 관리 경로를 기준으로 같은 저장소의 연결 및 재시작 복구를 검수하는 선택지가 될 수 있습니다.
장기적으로 항상 같은 노드에서 무거운 빌드를 실행하거나 물리 포트가 필요하다면 직접 구매가 더 적합할 수 있습니다. 그러나 일정 기간의 Xcode 작업, 원격 개발 검증, CI 연결 시험처럼 임시 개발 환경이 필요한 경우에는 먼저 복구 절차와 교체 조건을 확인한 뒤 원격 Mac을 임대하는 편이 시행착오를 줄입니다. 인수 전에는 원격 Mac 개발 환경 검수 기준에 따라 일반 SSH만이 아니라 VS Code Server, 실제 빌드와 재시작 후 복구까지 확인해야 합니다.
SECTION 07 자주 묻는 질문 FAQ
터미널 SSH는 되는데 VS Code Remote SSH만 연결되지 않는 이유는 무엇인가요?
두 연결이 같은 설정을 사용한다고 단정할 수 없기 때문입니다. VS Code가 호출하는 SSH 실행 파일, 설정 파일, 사용자 이름, 키 파일과 터미널의 값을 비교해야 합니다. 인증 뒤 포워딩이나 VS Code Server 단계에서 실패할 수도 있으므로 Remote SSH 출력과 원격 로그인 터미널을 함께 확인해야 합니다.
Mac에서 VS Code Server failed to start 오류가 나면 어떻게 해야 하나요?
먼저 원격 계정의 셸 출력, 서버 파일 상태, 실행 프로세스와 저장 공간을 확인합니다. 원격 노드의 인터넷 차단이나 셸 시작 파일의 불필요한 출력도 원인이 될 수 있습니다. 원인이 확인되기 전에는 서버 디렉터리를 삭제하지 말고, 기존 세션이 종료될 위험을 검토한 뒤 재설치합니다.
Installing VS Code Server 단계에서 계속 멈추면 무엇을 점검해야 하나요?
Remote SSH 출력에서 다운로드 실패인지, 설치 파일 누락인지, 서버 실행 실패인지 먼저 구분합니다. 원격 Mac이 필요한 주소에 접근할 수 있는지와 계정 디렉터리에 쓸 수 있는지도 확인합니다. 서버 정리는 마지막 수단으로 사용하고, 정리 뒤에는 같은 저장소에서 터미널과 편집기 작업을 모두 다시 시험합니다.
원격 Mac을 재시작한 뒤 VS Code Remote SSH가 다시 연결되지 않으면 어떻게 하나요?
관리용 접속 경로로 먼저 Mac의 전원과 네트워크 상태를 확인하고, macOS Remote Login이 다시 실행 중인지 점검합니다. 그다음 일반 SSH, VS Code Server, 작업 폴더와 실제 빌드를 순서대로 시험합니다. SSH부터 실패하면 편집기 캐시를 지우지 말고 노드 복구 또는 교체 문제로 분류해야 합니다.