1. 프리티어 가상 서버의 물리적 한계: 램 1GB의 장벽

현재 우리가 프리티어 혜택 범위 내에서 구동 중인 가상 머신인 t2.micro (또는 리전에 따른 t3.micro) 인스턴스의 물리 램(RAM) 용량은 정확히 1 GiB에 불과합니다. 이는 현대적인 백엔드 어플리케이션과 원격 개발 도구를 동시에 소화하기에는 턱없이 부족한 용량입니다.

이 비좁은 1GB 메모리 내부 공간을 뜯어보면 다음과 같은 점유 구조를 이룹니다:

• Amazon Linux 2023 OS 커널 점유: 가상 서버 운영체제가 정상적으로 기동되어 맥박을 유지하는 데 최소 200~300 MB가 상시 점유됩니다.
• VSCode Server 데몬의 점유: 로컬 편집기와 원격 리눅스를 동기화하며 구문 분석과 파일 감시를 전담하는 백그라운드 프로세스인 'VSCode Server' 데몬이 물리적으로 약 400~600 MB에 달하는 대용량 메모리를 단독으로 사용합니다.
• 노드JS 및 npm 컴파일 연산: 결과적으로 우리가 실행할 Express 웹 서버 프로세스나, 패키지의 의존성을 다운로드하는 npm install 명령어 빌드 연산이 트리거 되는 순간, 시스템 전체의 가용 램 잔여량은 즉시 0 바이트 임계치에 다다르게 됩니다.

■ OOM (Out of Memory) 킬러의 프로세스 처형

물리적 메모리가 완전히 고갈되면 리눅스 커널의 자위 보안 메커니즘인 OOM(Out-of-Memory) 킬러가 즉각 가동됩니다. OOM 킬러는 운영체제 자체의 완전한 붕괴를 막기 위해, 현재 가동 중인 프로세스 중 메모리를 가장 많이 소모하고 있는 대상(대부분 VSCode Server 통신 프로세스)을 임의로 강제 종료(Kill)해 버립니다.

이로 인해 VSCode 에디터와의 연결이 뚝뚝 끊기는 상태가 반복되며, 심한 경우 가상 컴퓨터 전체가 마비되어 AWS 콘솔에 들어가 수동으로 하드웨어 강제 재부팅을 수행하기 전까지는 복구가 불가능한 상태가 전개됩니다.

2. 시스템 엔지니어링의 해법: 가상 메모리 스왑 (Swap)

이 가혹한 하드웨어 스펙의 제한을 추가 비용 없이 극복하는 기술이 바로 가상 메모리 스왑(Swap Memory)을 구성하는 것입니다.

• 스왑(Swap)의 개념: 물리적 RAM 공간이 부족해졌을 때, 가상 가상 서버에 장착된 하드디스크 스토리지의 빈 영토를 가상의 휘발성 메모리(RAM) 공간처럼 빌려서 사용하는 기술입니다.
• 동작 원리: 물리 RAM 내부에서 현재 쓰이지 않고 잠잠히 대기 중인 메모리 페이지들을 가상 디스크 영역으로 임시 이동시키고(Swap-out), 물리 RAM에는 당장 실행되어야 할 고부하 연산 공간을 확보합니다. 이후 이동된 데이터가 필요해지면 다시 RAM으로 복구(Swap-in)합니다.
• 비용 효율적인 생존 보루: 가상 디스크(EBS gp3)의 I/O 속도는 실제 물리 RAM에 비해 느립니다. 하지만 메모리 고갈로 인한 시스템 셧다운 크래시를 방지하고, 1GB 프리티어 서버 환경에서도 VSCode Server와 패키지 빌드 연산을 안정적으로 완주시키는 훌륭한 실무 표준 안전지대 역할을 수행합니다.

3. [실습] 7단계 프로시저: 4GB 가상 메모리 스왑 생성 명령어

AWS Console에서 EC2 인스턴스 원격 터미널 창에 접속한 뒤 아래의 시스템 제어 명령어들을 순서대로 입력하여 4GB 가상 메모리를 확보해 보겠습니다.

# 1. 기존 가상 스왑 장치 상태 점검 (최초에는 아무런 출력값이 없어야 정상입니다)
sudo swapon --show

# 2. EBS gp3 스토리지 공간 중 4GB를 가상 스왑 파일 공간으로 정확히 할당
sudo fallocate -l 4G /swapfile

# 3. 소유자(root) 외에 다른 일반 사용자가 스왑 파일에 접근할 수 없도록 철저한 권한 차단(보안 최소 권한 적용)
sudo chmod 600 /swapfile

# 4. 할당된 파일 영역을 리눅스 전용 가상 스왑 디바이스 포맷으로 변환
sudo mkswap /swapfile

# 5. 생성된 4GB 스왑 파일을 리눅스 커널 가상 메모리 시스템에 공식 등록 및 기상
sudo swapon /swapfile

# 6. 메모리 임계치 도달 시 가상 메모리를 적극 활용하도록 스왑 활성도를 수치 60(표준 설정값)으로 설정
sudo sysctl vm.swappiness=60
echo 'vm.swappiness=60' | sudo tee -a /etc/sysctl.conf

# 7. 가상 서버가 재부팅(Reboot)되어도 4GB 스왑 공간이 자동 복구되어 가동되도록 부트 설정 파일 등록
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

■ 프리티어 요금 검증

스왑 공간으로 활용되는 EBS gp3 볼륨은 AWS 프리티어 정책에 따라 가입 후 최대 30GB까지 무료 제공됩니다. 이전 실습 단계에서 우리가 20GB만 디스크 용량으로 할당해 두었기 때문에, 4GB를 스왑용으로 추가 할당하더라도 누적 사용량은 24GB에 머물러 비용이 일절 청구되지 않는 안전 영역입니다.

4. 최종 확인: 가상 메모리 할당 상태 보고서

모든 커널 설정을 정상 이행했다면, 메모리 모니터링 구문을 입력하여 최종 검증을 이행합니다.

free -h

정상적으로 설정이 적용되었다면 터미널 화면에 아래와 같이 정비된 리소스 보고서가 출력됩니다:

               total        used        free      shared  buff/cache   available
Mem:           980Mi       520Mi       120Mi       2.0Mi       340Mi       320Mi
Swap:          4.0Gi          0B       4.0Gi

• 결과 분석: 상단의 Mem: 행은 1GB 크기의 기본 물리 RAM 용량을 가리키고 있습니다. VSCode Server 작동으로 인해 여유 잔량이 부족한 상태입니다.
• 하지만 그 아래, 우리가 할당한 가상 버퍼룸인 Swap: 4.0Gi 영역이 성공적으로 인식되어 시스템을 방어하고 있음을 볼 수 있습니다.
• 이로써 npm install 등의 무거운 압축 해제 연산이 동시에 몰려들더라도 가상 대피소 덕분에 OOM 크래시가 원천 예방되며, 끊김 현상 없는 쾌적한 백엔드 코딩 연구소가 가동됩니다.

5. 가상 메모리 분업화 구성 설계도

물리적 RAM과 SSD 기반의 가상 디스크(EBS)가 VSCode Server 구동 시 어떻게 유기적으로 데이터를 임시 수송하며 메모리 고갈 상황을 통제하는지 보여주는 흐름도입니다.

마치며: 리소스 최적화 완료, 이제 실전 코딩으로!

오늘 우리는 시스템 엔지니어링의 정수인 리눅스 스왑 메모리(Swap File 4GB) 할당 기술을 완수하여, 프리티어 1GB 메모리가 가진 물리적 결계를 비용 지출 없이 무결하게 해결해 냈습니다.

"비싼 인스턴스로 규모를 올려 돈으로 타협하려는 원시적인 접근을 지양하고, 시스템에 대한 정교한 하부 아키텍처 이해도를 바탕으로 4GB의 무과금 비상 안전 기지를 수립해 낸 여러분은 이미 실무형 아키텍트의 자질을 충분히 입증했습니다."

가상 서버(EC2), 데이터베이스(RDS), 인바운드 보안망, 한글 문자셋 조율에 이어 가상 대피소 셋업까지 끝마쳤으니 마침내 실전 비즈니스 논리 구현을 위한 완벽한 클라우드 전진 기지가 이 세상에 완성되었습니다.

다음 포스팅에서는 이 쾌적하고 단단해진 인프라 요새 위에, 실전 Express 프레임워크와 의존성 라이브러리 패키지들을 얹어 정식 백엔드 코딩을 개시하는 '[개발 환경 세팅] Node.js-Express 웹 애플리케이션 생성 및 mysql2 연결 라이브러리 연동 준비' 단계로 힘차게 전진하겠습니다. 오늘 스왑 할당 과정에서 커널 예외 메시지를 마주했다면 주저 없이 운영자 메일로 질문을 올려주세요. 오늘도 똑똑하고 안전한 클라우딩 라이프 하세요. 감사합니다! 😉

출처

• 이현호. 실무 프로젝트로 완성하는 클라우드 환경에서 DB 구축과 웹 개발. 길벗캠퍼스. 2026.04. (4.4장 '클라우드 개발 환경 구축 - EC2 인스턴스에 스왑 메모리 확보', 120-121페이지 및 128페이지 참조)
• 이현호. "04장. 데이터베이스 연동 개발 환경 구축" 설명 오디오 가이드 스크립트 기반 t2/t3.micro 가상서버 1GB 메모리 OOM 킬러 파국 대책 및 EBS 4GB Swap File 우회 할당 아키텍처 대화록 완벽 반영.
• AWS EC2 Linux Instance Memory Optimization (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Memory-optimization.html) 및 RedHat Enterprise Linux Swap Space Configuration Manual.

자주 묻는 질문 (FAQ)

Q. t2.micro 인스턴스가 VSCode Remote-SSH 연결 중 먹통(Freezing)이 되는 구체적인 원인은 무엇인가요?

A. VSCode Server가 단독으로 400~600MB의 메모리를 차지하기 때문입니다. 1GB의 제한된 램을 가진 t2.micro 환경에서 OS 기본 사용량(200~300MB)과 합쳐져 가용 메모리가 고갈되면 리눅스의 OOM 킬러가 프로세스를 강제 종료시켜 먹통이 됩니다.

Q. 스왑(Swap) 파일의 크기를 4GB로 설정했을 때 AWS 프리티어 계정에서 비용이 발생하나요?

A. 추가 비용은 발생하지 않습니다. 프리티어 정책상 30GB까지의 EBS(gp3) 스토리지 공간이 무상 제공되며, 4GB 크기의 가상 스왑 파일은 이 무료 디스크 범위 내에서 생성되기 때문에 영구적으로 완전한 무과금 실습이 보장됩니다.

Q. 생성한 스왑 파일을 가상 서버가 재부팅된 후에도 자동으로 자동 유지되도록 만드는 명령어는 무엇인가요?

A. /etc/fstab 파일에 마운트 명령어를 영구 삽입하는 명령어입니다. 터미널에서 echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab을 실행하여 설정 파일 하단에 관련 부팅 정보를 직접 추가하면 해결됩니다.