정적 호스팅을 넘어: AWS EC2에 Node.js 연락처 폼 API 배포

Source: Dev.to

위에 제공된 내용 외에 번역할 텍스트가 없습니다. 번역이 필요한 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

왜 연락 양식에 EC2를 사용할까?

분명히 말하자면, EC2가 정적 포트폴리오를 호스팅하기 위한 “최고”의 도구는 아닙니다. 관리형 서비스가 존재하는 이유가 있으며, 이러한 서비스는 보통 이와 같은 사용 사례에 대해 더 나은 확장성, 보안 및 단순성을 제공합니다.

하지만 EC2는 학습용으로는 최고의 도구 중 하나입니다. 실제 서버에서 애플리케이션이 어떻게 실행되는지, 백엔드 서비스가 어떻게 배포되는지, 트래픽이 시스템을 통해 어떻게 흐르는지, 그리고 가동 시간과 신뢰성이 실제로 어떻게 관리되는지를 이해하고 싶었습니다.

특히, Linux 서버를 직접 다루고, 장기 실행 프로세스를 관리하며, 리버스 프록시를 설정하고, 실제 HTTP 요청을 처리하는 실습 경험을 얻고 싶었습니다. 이러한 학습 목표가 EC2를 이 프로젝트에 적합한 선택으로 만든 이유입니다.

내가 만든 것

이 프로젝트를 위해 두 개의 간단한 엔드포인트를 가진 작은 Node.js와 Express API를 구축했습니다:

• GET /api/health – 헬스 체크
• POST /api/contact – 포트폴리오에서 전송된 연락 양식 제출을 받습니다

서드파티 폼 서비스에 의존하는 대신, 프론트엔드가 폼 데이터를 직접 이 백엔드 API로 전송하여 요청 흐름과 서버 동작을 완전히 제어할 수 있습니다.

고수준 아키텍처

고수준에서 아키텍처는 다음과 같습니다:

1. 사용자가 브라우저에서 내 포트폴리오와 상호작용합니다.
2. 요청이 인터넷을 통해 AWS EC2 인스턴스로 전송됩니다.
3. Nginx가 포트 80에서 들어오는 트래픽을 수신합니다.
4. Nginx가 API 요청(/api/*)을 포트 3000에서 실행 중이며 PM2로 관리되는 Node.js 애플리케이션으로 전달합니다.

이 설정은 실제 운영 시스템이 훨씬 더 큰 규모에서도 구조화되는 방식을 반영합니다.

단계별 개요

1. Configure the EC2 security group – SSH (port 22) restricted to my IP, HTTP (port 80) open to the world.
   EC2 보안 그룹을 구성 – SSH(포트 22)는 내 IP에만 제한하고, HTTP(포트 80)는 전 세계에 개방합니다.

2. Launch the EC2 instance – Ubuntu AMI, free‑tier eligible instance type.
   EC2 인스턴스를 시작 – Ubuntu AMI, 프리 티어 대상 인스턴스 유형.

3. Connect via SSH using a key pair; this reminded me that servers are not “deploy‑and‑forget” resources.
   키 페어를 사용해 SSH로 연결합니다; 이를 통해 서버가 “배포하고 잊어버리는” 리소스가 아니라는 것을 다시 깨달았습니다.

4. Install Node.js (LTS) and npm on the server.
   서버에 Node.js(LTS)와 npm을 설치합니다.

5. Copy the backend project to the EC2 instance, run npm install, and verify the API with node server.js.
   백엔드 프로젝트를 EC2 인스턴스로 복사하고, npm install을 실행한 뒤 node server.js로 API를 확인합니다.

6. Introduce PM2 – a process manager that runs the app in the background, restarts it on crashes, keeps it alive after SSH disconnects, and ensures it starts on reboot.
   PM2 도입 – 앱을 백그라운드에서 실행하고, 충돌 시 재시작하며, SSH 연결이 끊겨도 유지하고, 재부팅 시 자동 시작을 보장하는 프로세스 관리자입니다.

7. Install Nginx and configure it as a reverse proxy: public traffic arrives on port 80, while requests to /api/* are proxied to the Node.js app on port 3000. This step introduced real‑world request routing and required fixing a trailing‑slash issue in the proxy_pass configuration.
   Nginx를 설치하고 역방향 프록시로 구성합니다: 공용 트래픽은 포트 80으로 들어오고, /api/* 요청은 포트 3000에서 실행 중인 Node.js 앱으로 프록시됩니다. 이 단계에서는 실제 요청 라우팅을 배우게 되었으며 proxy_pass 설정에서 슬래시 끝 문제를 해결해야 했습니다.

# Example commands
ssh -i my-key.pem ubuntu@ec2-xx-xx-xx-xx.compute-1.amazonaws.com
sudo apt update && sudo apt install -y nodejs npm
npm install
node server.js
pm2 start server.js --name contact-api
pm2 startup
pm2 save
sudo apt install -y nginx
# Edit /etc/nginx/sites-available/default with proxy_pass configuration
sudo systemctl restart nginx

엔드‑투‑엔드 테스트

모든 것이 연결된 후, 엔드‑투‑엔드로 설정을 테스트했습니다:

• 서버에서 curl을 직접 사용했습니다.
• 브라우저의 Network 탭에서 요청을 검사했습니다.
• 실제 포트폴리오에서 연락 양식을 제출했습니다.

클라우드에 호스팅된 백엔드에서 일관된 200 OK 응답을 확인하는 것은 로컬에서 테스트할 때와는 매우 달랐으며, 전체 시스템이 실제처럼 느껴졌습니다.

배운 점

• 클라우드 서버에서 백엔드 서비스를 운영하려면 적절한 프로세스 관리가 필요합니다—PM2는 Node.js 애플리케이션을 지속적으로 실행시키는 데 필수적입니다.
• Nginx는 요청 라우팅, TLS 종료, 보안 강화 등을 담당하는 일반적인 프런트엔드 프록시입니다.
• 서비스를 운영한다는 것은 단순히 코드를 실행하는 것을 넘어 보안, 모니터링, 신뢰성 등을 고려해야 함을 의미합니다.
• Linux, AWS EC2, Node.js, Nginx를 함께 다뤄보면서 프로덕션 환경 워크플로에 대한 자신감이 생겼고, 관리형 서비스가 존재하는 이유—많은 복잡성을 숨겨주기 때문—를 다시 한 번 실감했습니다.

클라우드 여정을 이제 막 시작했거나 내부 동작이 궁금하다면, 비슷한 환경을 직접 구축해 보는 것을 강력히 추천합니다.