블로그 본문
[클라우드 IDE 구축] VSCode Remote-SSH로 AWS EC2 가상서버 원격 개발 환경 완벽 세팅하기
니꼴라 클라우드 테크 8월 23, 2026📌 목차 바로가기
지난 포스팅에서는 로컬 컴퓨터에서 구름 속 Amazon RDS 데이터베이스를 효율적으로 조작하기 위해 대표적인 클라이언트 GUI 도구인 MySQL Workbench와 DBeaver의 장단점을 심도 있게 분석했습니다. 또한 복사해 둔 RDS 엔드포인트 도메인 주소를 사용하여 데이터베이스 원격 연결(Connection)을 성공적으로 수행하는 셋업 단계를 완료했습니다.
이번 포스팅에서는 클라우드 애플리케이션 서버를 본격적으로 셋업합니다. 가상 컴퓨터 서비스인 Amazon EC2(Elastic Compute Cloud) 인스턴스를 생성하고, 로컬 VSCode 편집기와 원격 가상 서버를 SSH 터널로 연결하여 나만의 '클라우드 통합 개발 환경(IDE)'을 구성하는 프로시저를 명확하게 정리해 드리겠습니다.
1. 인프라 대안 탐색: AWS Cloud9 중단과 VSCode Remote-SSH
기본적으로 클라우드 개발 환경을 세팅할 때 과거에는 브라우저에서 곧바로 실행할 수 있는 EC2 기반 통합 개발 환경인 AWS Cloud9 서비스를 자주 기용했습니다.
그러나 AWS는 공식 정책에 따라 최근 신규 사용자에게 Cloud9 제공을 전면 중단했습니다. 따라서 현대적인 클라우드 아키텍처 실무에서는 로컬 PC에 설치된 강력하고 익숙한 에디터 인터페이스를 유지하면서, 물리적인 소스 코드 컴파일과 패키지 빌드, 가동 위치만을 가상 서버로 안전하게 격리하는 VSCode Remote-SSH 확장 프로그램 방식이 핵심 표준으로 완벽히 대체되었습니다.
- 동작 원리: VSCode Remote-SSH는 사용자가 키보드로 코드를 수정하고 뷰를 확인하는 UI 쉘 역할만 로컬 랩탑에 남겨둡니다. 실제 코드가 저장되고 패키지 의존성(
npm install)이 빌드되며 노드 프로세스가 도는 백엔드 엔진의 역할은 전적으로 클라우드의 Amazon EC2 인스턴스에 가동된 백그라운드 데몬(VSCode Server)이 담당하게 됩니다. - 이를 통해 로컬 컴퓨터 사양에 상관없이 언제 어디서나 균등하고 일관된 고성능의 기업용 원격 협업 공간을 안전하게 유지할 수 있습니다.
2. [실습 1단계] Amazon EC2 가상 인스턴스 생성 및 보안 자격 증명
우리 애플리케이션의 집이 되어 줄 가상 컴퓨터 인스턴스를 생성해 보겠습니다.
- 리전 재확인: AWS 콘솔 로그인 후 화면 우측 상단이 반드시 '아시아 태평양(서울) ap-northeast-2'로 선택되어 있는지 엄격하게 확인합니다.
- EC2 서비스 진입: 서비스 검색창에 'EC2'를 입력하여 이동한 후, 화면 중앙의 [인스턴스 시작 (Launch instance)] 버튼을 클릭합니다.
- 기본 매개변수 설정:
- 이름: 식별하기 용이하도록 영문 명칭을 지정합니다. 예시로는
myEC2-000을 부여하겠습니다. - OS 이미지(AMI): [Quick Start] 탭에서 가장 무결하고 최적화된 호환성을 제공하는 최신 표준 [Amazon Linux] 제품군을 선택하고, 세부 버전은 'Amazon Linux 2023 AMI' (64비트 x86 아키텍처)를 지정합니다.
- 인스턴스 유형: 월 750시간 무료인 프리티어 규격인
t2.micro(일부 지원 안 되는 리전의 경우t3.micro) 인스턴스를 정확하게 선택합니다. 다른 고성능 등급(c5.small 등)을 지정할 경우 선택 즉시 요금이 부과되기 시작하므로 주의를 요합니다.
- 이름: 식별하기 용이하도록 영문 명칭을 지정합니다. 예시로는
- 보안 키 페어(Key Pair) 발급:
- 새 키 페어 생성 버튼을 클릭하여 이름을
myEC2-keypair-000으로 부여합니다. - 키 페어 유형은
RSA, 프라이빗 키 파일 형식은.pem을 지정하여 로컬 컴퓨터에 안전하게 다운로드합니다. 이 파일은 가상 서버에 패스워드 없이 안전하게 침투하기 위한 유일무이한 대칭 암호화 열쇠입니다. - 보안 권장 행동 (Mac/Linux): 외부 공유를 차단하고 안전하게 검증하기 위해 터미널을 열고
.pem파일이 보관된 경로에서 다음 명령을 실행하여 권한을 최소화해 둡니다.chmod 400 "myEC2-keypair-000.pem"
- 새 키 페어 생성 버튼을 클릭하여 이름을
- 네트워크 및 스토리지 구성:
- 방화벽(보안 그룹): 기존 보안 그룹 중
default를 매핑해 줍니다. (인바운드 규칙으로 원격 제어 포트 22번이 열려 있는지 수시로 확인해야 합니다.) - 스토리지: 기본 할당 스펙인 '8 GiB gp3 루트 볼륨, 3000 IOPS, 암호화되지 않음'을 지정합니다. 프리티어 범위(EBS 최대 30GB 무료) 내에서 최상의 기동 성능을 보장받을 수 있습니다.
- 모든 속성을 확인하고 화면 우측 하단의 [인스턴스 시작] 버튼을 눌러 프로비저닝을 마칩니다. 약 1분 이내에 가상 서버가 완벽히 기상하여 퍼블릭 IP 및 퍼블릭 DNS(도메인 주소)를 발급받게 됩니다.
3. [실습 2단계] VSCode Remote-SSH 확장 및 Config 파일 정밀 세팅
가상 컴퓨터가 성공적으로 가동되었으니, 이제 내 컴퓨터의 로컬 VSCode 편집기와 클라우드 서버 간에 전용 암호화 통로(SSH)를 정렬해 보겠습니다.
- 원격 확장 프로그램 장착: VSCode 에디터를 실행한 후 좌측 메뉴바에서 [Extensions] 아이콘을 누르고
Remote-SSH(Microsoft 제공 공식 라이브러리)를 설치 완료합니다. - SSH 구성 편집 가동: 키보드의 단축키
F1을 누르고 검색창에Remote-SSH: Open SSH Configuration File...을 입력하여 엔터 칩니다. 목록 중에서 사용자 로컬 경로에 있는.ssh/config파일을 클릭하여 열어 줍니다. - Config 구성 정보 정밀 기입: config 파일 내부에 다음 양식에 맞추어 정확하게 시스템 연결 정보를 기입하고 저장(Ctrl+S)합니다:
Host myEC2-000 HostName ec2-15-164-164-201.ap-northeast-2.compute.amazonaws.com User ec2-user Port 22 IdentityFile C:\Users\USER\.ssh\myEC2-keypair-00.pem- Host: VSCode에서 관리 제어 시 노출될 일관된 이름입니다.
- HostName: AWS EC2 콘솔 상세 창에서 복사해 온 인스턴스 전용 '퍼블릭 DNS' 주소를 기입합니다.
- User: 운영체제가 Amazon Linux인 경우 반드시 소문자로
ec2-user를 기입합니다. (Ubuntu인 경우ubuntu, Debian인 경우admin으로 자동 부여됩니다.) - IdentityFile: 앞서 다운로드하여
.ssh보안 폴더 안에 넣어둔 키페어(.pem) 파일의 로컬 절대 경로를 정확히 수동 지정합니다. - 주의: EC2 인스턴스를 영구 주소(Elastic IP) 없이 재시작할 때마다 퍼블릭 DNS 주소와 IP가 동적으로 변경되므로, 재부팅 시에는 이
HostName항목을 AWS 대시보드를 확인하여 매번 갱신해 주어야 연결 타임아웃을 피할 수 있습니다.
4. 원격 터널 연결 구조도 및 인포그래픽
로컬 컴퓨터의 VSCode 에디터와 클라우드 AWS EC2 가상 머신 간에 보안 22번 포트를 이용한 SSH 터널링을 생성하고, 원격 가상 컴퓨터 내부에 가동된 백엔드 서비스(VSCode Server)를 지휘 통제하는 전체적인 아키텍처 흐름도입니다.
5. [최종 도킹] 호스트 연결 및 보안 인프라 검증
모든 설정이 완료되었습니다. 이제 최종적인 클라우드 IDE 도킹을 선포해 보겠습니다.
- 호스트 연결 시도: VSCode 화면 좌측 하단의 녹색 원격 아이콘
[ >< ]혹은 단축키F1입력 후Remote-SSH: Connect to Host...를 클릭하여, 목록에 정상 등록된myEC2-000호스트를 클릭합니다. - OS 플랫폼 지정 및 지문 승인:
- 새로운 VSCode 보안 창이 열리면서 대상 서버의 OS 플랫폼을 묻는 프롬프트가 뜨면 주저 없이
Linux를 선택해 줍니다. - 이어서 SSH 지문 키(Fingerprint) 신뢰 여부를 묻는 보안 승인 문구가 나오면
Continue를 클릭해 패스해 줍니다.
- 새로운 VSCode 보안 창이 열리면서 대상 서버의 OS 플랫폼을 묻는 프롬프트가 뜨면 주저 없이
- 원격 터미널 가동 완료:
- 화면 좌측 하단의 녹색 구역에
SSH: myEC2-000접속 표시가 연동되며, Terminal 메뉴를 활성화하는 즉시 가상 인프라 내부의 리눅스 프롬프트 커널([ec2-user@ip-172-31-40-76 ~]$)이 모니터 화면에 그대로 가동되어 통제할 수 있게 됩니다. - 이로써 로컬 컴퓨터 물리 하드웨어 자원을 소모하지 않은 상태에서, 저 멀리 서울 리전 데이터 센터에 놓인 가상 서버 인스턴스를 로컬 호스트 에디터로 직접 코딩하고 제어할 수 있는 최첨단 클라우드 IDE 환경이 확보된 것입니다.
- 화면 좌측 하단의 녹색 구역에
6. 성능적 제약 조건에 대한 강력한 실무 경고: 1GB 램의 장벽
자, 성공의 기쁨을 누리는 것도 잠시, 이 똑똑하고 편리한 원격 개발 가상 인프라 환경의 뒤편에는 실습 진행 도중 여러분의 숨통을 조이고 밤새 컴퓨터가 멈추는 에러의 지옥에 빠뜨릴 조용하고 강력한 물리적 장벽이 도사리고 있습니다.
- 1GB의 냉혹한 한계선: 우리가 기용한 무료 프리티어 인스턴스인
t2.micro(또는t3.micro)의 물리 램(RAM) 용량은 고작1 GiB수준에 불과합니다. - VSCode Server의 탐욕: 로컬 편집기와 원격 리눅스를 매끄럽게 연동해 주며 코드 완성, 변수 정밀 분석, 실시간 터미널 덤프를 전담하는 백그라운드 프로세스인 'VSCode Server' 데몬은 물리적으로 최소 400MB에서 무려 600MB에 달하는 육중한 시스템 메모리를 단독 점유하여 갉아먹습니다.
- OM(Out of Memory) 킬러의 참극: 여기에 리눅스 운영체제 자체 커널 구동에 들어가는 최소 200MB 메모리까지 합산되면, 정작 우리가 돌려야 할 Node.js 백엔드 서버나 핵심 모듈을 설치하기 위해
npm install명령어 패키지 압축 풀기 연산을 실행하는 순간 메모리 가용량이0에 도달하게 됩니다. - 이때 리눅스 커널의 최후 수단인 **OM 킬러(Out-of-Memory Killer)**가 무단 작동하여 메모리를 가장 많이 차지하고 있는 VSCode 서버 연결 프로세스 자체를 강제로 사살(Kill)해 버립니다. 결과적으로 에디터 연결이 툭툭 끊기고 EC2 가상 머신 자체가 아예 먹통(Freezing)이 되어 AWS 콘솔에 들어가 강제 재부팅을 누르기 전까지는 복구가 불가능한 끔찍한 다운타임 사태가 끝없이 무한 루프로 반복 전개됩니다.
마치며: 물리 제약을 엔지니어링 기술로 돌파할 때입니다
오늘 우리는 AWS Cloud9 서비스 폐쇄라는 인프라 격변에 맞서, 내 랩탑의 편집 인터페이스와 클라우드 컴퓨팅 파워를 우아하게 결합해 내는 VSCode Remote-SSH 원격 가상 통합 연구소를 완벽하게 빌딩해 내는 데 성공했습니다.
"로컬 환경에 무겁고 투박하게 온갖 데이터베이스 패키지와 개발 언어 컴파일러들을 깔아서 쓰던 원시 개발 패러다임을 탈출하여, 내 로컬 컴퓨터는 오직 키보드 입력과 코드 화면을 중계해 주는 가벼운 껍데기(Thin Client)로 낮추고 실제 묵직한 연산은 클라우드 EC2에 완전히 위임해 처리하는 세련된 아키텍처에 마침내 최종 안착했습니다."
통신 도킹까지 무결하게 정렬했으나, 바로 위에서 지적해 드린 '1GB 메모리 부족으로 인한 가상 서버 프리징 먹통 재앙'을 해결하지 않는다면 단 한 줄의 백엔드 서비스 코드도 이 위에 구동해 낼 수 없습니다. 돈을 더 내고 비싼 고사양 인스턴스로 업그레이드할 것인가? 아니면 클라우드 시스템 엔지니어의 고정밀 기술력으로 이 장벽을 우아한 공짜로 극복해 낼 것인가?
다음 포스팅이자 프리티어 가상 컴퓨터의 한계를 획기적으로 극복해 주는 실무 중량급 최적화 팁인 '[실무 리소스 최적화] t2.micro 서버 프리징 해결! AWS 프리티어 필수 세팅인 가상 메모리(Swap File 4GB) 확보하기' 편에서는 부족한 물리 램 1GB의 공간을 가상 스토리지 볼륨(EBS)의 여유 디스크 공간 4GB를 할당 변환하여 완벽한 비상용 대피 버퍼룸으로 기상시키는 리눅스 스왑 메모리(Swap File) 정밀 할당 커널 명령어셋을 원포인트 레슨으로 시원하게 열어 드리겠습니다.
오늘 EC2 인스턴스 생성 중 보안 키페어(.pem) 보관 오류가 났거나, VSCode Remote-SSH 호스트 연결 구성 도중 HostName IP 매핑이 꼬이신 분들은 주저 없이 운영자 메일로 문의해 주세요. 오늘도 안전하고 똑똑한 클라우딩 라이프 하세요. 감사합니다! 😉
출처
- 이현호. 실무 프로젝트로 완성하는 클라우드 환경에서 DB 구축과 웹 개발. 길벗캠퍼스. 2026.04. (4.4장 '클라우드 개발 환경 구축', 118-124페이지 참조)
- 이현호. "04장. 데이터베이스 연동 개발 환경 구축" 설명 오디오 가이드 스크립트 기반 AWS Cloud9 중단에 따른 VSCode Remote-SSH의 의의, t2/t3.micro 가상서버의 물리 1GB 램 점유율 분석 대화록 완벽 반영.
- AWS EC2 User Guide for Linux Instances - Connecting to Your Instance (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) 및 VSCode Remote-SSH Documentation.
자주 묻는 질문 (FAQ)
Q. AWS Cloud9 신규 지원 중단 후 권장되는 원격 개발 환경 구축 방식은 무엇인가요?
A. 로컬 에디터와 클라우드 인스턴스를 연결하는 VSCode Remote-SSH 확장 프로그램 방식이 표준 대안입니다. 로컬 PC는 UI 편집 쉘로만 사용하고, 실제 코드 저장 및 빌드 연산은 Amazon EC2 가상 서버 내 VSCode Server 데몬이 전담합니다.
Q. EC2 인스턴스를 재부팅한 후 VSCode Remote-SSH 연결 타임아웃이 발생하는 원인은 무엇인가요?
A. 고정 공인 IP(Elastic IP)를 사용하지 않은 EC2 인스턴스는 재부팅 시 퍼블릭 IP와 퍼블릭 DNS가 동적으로 변경되기 때문입니다. 재시작 후에는 로컬 .ssh/config 파일의 HostName 항목을 새 퍼블릭 DNS 주소로 갱신해야 정상 연결됩니다.
Q. EC2 프리티어(t2.micro) 환경에서 npm 패키지 빌드 시 서버가 멈추거나 연결이 끊기는 이유는 무엇인가요?
A. 1GB의 적은 물리 RAM 환경에서 백그라운드 VSCode Server(400~600MB)와 OS가 메모리를 선점하여 가용량이 고갈되기 때문입니다. 메모리 부족 시 리눅스 커널의 OOM(Out of Memory) 킬러가 작동하여 VSCode 연결 프로세스를 강제 종료하게 됩니다.

