지난 포스팅에서는 데이터베이스의 호스트 주소와 암호 등의 일급 자격 증명 정보를 소스 코드 내부에서 물리적으로 분리하는 dotenv 환경 변수(.env) 설정과, 깃허브 원격 저장소 유출 사고를 방지하는 .gitignore 연동 전략을 구현했습니다. 이로써 소스 코드는 순수한 비즈니스 로직만 수행하고 민감한 정보는 인프라 내부에서 안전하게 관리되는 DevSecOps 보안 아키텍처를 완성했습니다.

이번 포스팅에서는 그동안 우리가 구축해 온 인프라와 백엔드를 연동해 첫 실전 API 서버를 가동해 보겠습니다. 이 과정에서 필연적으로 맞닥뜨리는 대표적인 연결 장애 유형인 VPC 보안 그룹 소스 IP 불일치와 네트워크 포트 차단 에러의 원인을 진단하고, 이를 즉각 해결할 수 있는 트러블슈팅 가이드를 객관적으로 전수해 드리겠습니다.

1. 웹 서버 가동과 예기치 못한 연결 지연(Connection Timeout) 장벽

Node.js-Express 웹 애플리케이션에 구축된 공통 데이터베이스 연동 모듈(db.js)을 활성화하고 메인 엔트리 포인트 파일(Main.js 또는 app.js)을 기동하여 클라우드 DB 연결을 시도하는 순간, 서버 콘솔창이 다음 단계로 넘어가지 않고 한참 동안 멈춰 서 있다가 연결 타임아웃 에러를 발생시키는 경우가 많습니다.

Error: connect ETIMEDOUT 15.164.x.x:3306
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1605:16)

이 에러가 출력되는 원인은 백엔드 소스 코드나 Express 라우터의 문법 오류가 아닙니다. 99%는 로컬 컴퓨터가 위치한 네트워크 환경과 AWS VPC(Virtual Private Cloud) 보안 그룹의 방화벽 규칙이 서로 어긋나 패킷 수송망이 차단되었기 때문입니다.

2. 트러블슈팅 Checkpoint ①: 공인 IP 변동에 따른 VPC 보안 그룹 불일치

가장 빈번하게 발생하며 직관적으로 감지하기 어려운 원인은 개발자 로컬 컴퓨터의 공인 IP(Public IP) 변동입니다.

• 서브넷 마스크 /32의 엄격성: 우리는 지난 실습 과정에서 외부 무단 침입을 원천 차단하기 위해 VPC 보안 그룹의 인바운드 규칙에 현재 로컬 컴퓨터의 공인 IP만을 단일 호스트 서브넷 마스크인 /32 규칙으로 묶어 등록했습니다.
• IP 세대의 유동성: 공유기 와이파이망을 사용하거나 장소를 옮기는 경우(집, 카페, 도서관 등), 통신사 네트워크 스위치가 로컬 컴퓨터에 완전히 새로운 공인 IP를 임시 재할당합니다.
• 패킷 드롭(Drop): 보안 그룹 방패병은 이 변화된 IP로부터 날아오는 3306 포트 접속 패킷을 모르는 대포 IP로 판단하여 네트워크 스위치 레벨에서 즉각 전면 드롭 처리합니다. 이로 인해 백엔드 프로그램은 응답을 받지 못해 무한 대기하다가 ETIMEDOUT 에러를 뿜어냅니다.
• 해결 방법: AWS EC2/RDS 콘솔의 보안 그룹 설정으로 이동하여 기존 인바운드 규칙의 소스를 제거하고, 현재 새롭게 바뀐 네트워크의 공인 IP를 [내 IP] 옵션으로 다시 선택해 저장해야 합니다.

3. 트러블슈팅 Checkpoint ②: 로컬 공유기 및 공용 와이파이의 3306 포트 제한

보안 그룹의 인바운드 규칙을 내 IP로 정확히 갱신했음에도 연결 타임아웃 에러가 해결되지 않는다면, 이는 아웃바운드 패킷 신호가 출발하는 로컬 네트워크 장비의 통제 정책을 의심해야 합니다.

• 포트 필터링(Port Filtering): 대학교 도서관, 공공 기관, 기업 사무실 및 일부 카페의 공용 와이파이 공유기들은 네트워크 보안성과 불법 무단 트래픽 점유를 방지하기 위해 웹 서핑 포트인 80(HTTP)과 443(HTTPS)을 제외한 나머지 모든 포트로 나가는 신호를 차단하도록 구성되어 있습니다.
• 이로 인해 MySQL 데이터베이스의 전용 통로인 3306 포트로 나가는 패킷 신호 자체가 공유기 선에서 원천 기각되므로 AWS 클라우드 영토에 가닿지 못하고 로컬에서 물리적으로 고립되는 현상이 발생합니다.

4. 트러블슈팅 Checkpoint ③: 모바일 핫스팟 테더링을 이용한 우회 실천

이러한 로컬 네트워크 장비의 포트 차단망을 우회하여 환경을 테스트하는 가장 빠르고 확실한 해결책은 스마트폰의 LTE/5G 모바일 핫스팟(테더링) 망을 기용하는 것입니다.

• 통신사 개방망의 이점: 스마트폰 모바일 핫스팟은 유선 공유기 방화벽의 영향을 전혀 받지 않는 통신사 직속의 완전 개방형 통로입니다.
• 우회 절차: 로컬 컴퓨터의 와이파이 연결을 해제하고 스마트폰의 핫스팟 신호로 변경 접속한 뒤, 바뀐 스마트폰 기준의 공인 IP를 AWS 보안 그룹 인바운드 규칙에 다시 등록해 줍니다.
• 이 방식은 공유기 설정 제어 권한이 없는 공공장소에서 포트 필터링 그물을 100% 무력화하고 가상 인프라 연결성을 검증해 내는 실무 표준 트러블슈팅 엔지니어링 팁입니다.

5. 최후 검증: 클라우드 DB 연결 증명 및 첫 실전 Web API 가동

네트워크의 장벽을 모두 허물고 나면, 마침내 Node.js Express 백엔드 서버가 Amazon RDS 인스턴스에 완벽하게 도킹되어 웹 API 서비스를 제공할 수 있는 기반이 확정됩니다.

# 원격 EC2 인스턴스 터미널에서 Node.js 애플리케이션 가동
node Main.js

성공적으로 구동을 시작하면 터미널 콘솔창에 다음과 같이 정돈된 시스템 부트 로그가 출력됩니다:

[dotenv@17.2.1] injecting env (0) from .env
CORS 미들웨어 설정 완료
요청 본문 파싱 미들웨어 설정 완료
FASHION STORE 서버가 포트 3000에서 실행 중입니다
접속 URL: http://localhost:3000
현재 시간: 2026. 8. 26. 오후 6:00:00
데이터베이스에 성공적으로 연결되었습니다.

■ 실전 회원 목록 JSON 반환 API 호출 테스트

웹 브라우저 주소창에 http://<EC2-퍼블릭-IP>:3000/api/members (혹은 구현된 라우트 API 주소)를 입력하고 엔터를 칩니다. 데이터베이스 연결 모듈(db.js)이 shopping_db 스키마 내부의 Customers 테이블을 실시간으로 쿼리하여 전역 클라이언트에 내려보낸 정형 회원 정보가 화면 가득 출력되는 모습을 볼 수 있습니다:

[
  {
    "cust_id": "user1@email.com",
    "cust_name": "홍길동",
    "m_phone": "010-1234-5678",
    "a_term": "Y",
    "a_privacy": "Y",
    "a_marketing": "N"
  }
]

이 JSON 데이터 보고서는 백엔드 프레임워크의 자바스크립트 엔진과, 클라우드 가상 컴퓨터(EC2), 그리고 영구 저장 요새인 데이터베이스(Amazon RDS)가 지리적 한계를 넘어 완벽히 한 맥락으로 융합되어 살아 움직이고 있음을 입증하는 아키텍처 수립의 최종 증명서입니다.

6. DB 연동 트러블슈팅 검증 흐름도

개발자 로컬 컴퓨터의 패킷이 출발하여 로컬 라우터와 AWS VPC 보안 그룹의 검문 검색을 거쳐 Amazon RDS 본진에 도킹하기까지의 트러블슈팅 흐름도입니다.

마치며: 첫 번째 가상 데이터 룸이 살아 움직입니다!

오늘 우리는 백엔드 개발자들의 가장 큰 장벽인 데이터베이스 연결 실패 에러(ETIMEDOUT)를 세 가지 핵심 체크리스트(공인 IP 변동 체크, 로컬 공유기 포트 차단 확인, 핫스팟 우회 기법)를 통해 완벽히 해결해 냈습니다. 또한 우리의 웹 서버와 원격 Amazon RDS를 유기적으로 결합하여 회원 목록 데이터를 동적으로 전송하는 첫 웹 API 구동 실증까지 완수했습니다.

"네트워크의 세부 동작 메커니즘을 알지 못한 채 그저 까만 모니터 속 타임아웃 대기줄만 바라보며 좌절하던 과거를 극복하고, 방화벽 패킷 드롭의 안보 원리와 개방망 테더링의 우회로를 정교하게 짚어내어 끝내 클라우드 데이터 통신망을 개통해 낸 여러분은 이제 시장에 바로 투입될 준비가 끝난 전문 클라우드 백엔드 개발자입니다."

인프라 셋업, MFA 보안, IAM 풀 권한 조율, 관계형 데이터베이스 구조 및 정적 파라미터 최적화, 스왑 가상 메모리 설계, DevSecOps 자격 정보 은닉, 그리고 마침내 첫 번째 실전 API 통신망 개통까지 클라우드와 백엔드의 숲을 온몸으로 채화해 주신 여러분께 진심 어린 감사를 보냅니다. 여러분을 평범한 코더에서 복잡한 문제를 구조적으로 돌파하는 최고의 클라우드 시스템 아키텍트로 승격시켜 줄 위대한 밑거름이 될 것입니다. 다음 편부터는 관계형 데이터베이스 설계와 웹애플리케이션 개발에 대해서 소개하는 기회를 가지겠습니다. 언제나 안전하고 영리한 클라우딩 라이프 하세요. 감사합니다! 😉

출처

• 이현호. 실무 프로젝트로 완성하는 클라우드 환경에서 DB 구축과 웹 개발. 길벗캠퍼스. 2026.04. (4.4장 '클라우드 개발 환경 구축 - Amazon RDS MySQL과 EC2 인스턴스 연결', 124-125페이지 및 7.1장 'DB 연결 모듈', 174-177페이지 참조)
• 이현호. "04장. 데이터베이스 연동 개발 환경 구축" 및 "07장. 애플리케이션_개발_-_DB_연결_및_사용자인증" 설명 오디오 가이드 스크립트 기반 로컬 공인 IP 변동 원인 분석, 3306 포트 필터링 우회 대책 및 Express API 가동 실증 대화록 완벽 반영.
• Amazon RDS Connection Troubleshooting (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Connecting) 및 AWS VPC Security Group Rules.

자주 묻는 질문 (FAQ) 

Q. 보안 설정을 전혀 변경하지 않았는데도 잘 작동하던 데이터베이스 원격 연결이 갑자기 ETIMEDOUT 에러로 막히는 진짜 이유는 무엇인가요? 

A. 로컬 컴퓨터의 공인 IP가 변경되었기 때문입니다. 공유기 재부팅이나 와이파이망 이동 시 로컬 IP가 동적으로 바뀌며, 이로 인해 VPC 보안 그룹 인바운드 규칙에 /32 단일 호스트로 지정되어 있던 기존 허용 방화벽 대역과 불일치가 발생해 패킷이 전면 드롭됩니다.

Q. 카페나 도서관 등 공공 와이파이 공유기에서 3306 포트를 이용한 클라우드 DB 다이렉트 접속이 영구 차단되는 원인은 무엇인가요? 

A. 와이파이 장비에 걸린 아웃바운드 포트 필터링 정책 때문입니다. 공공 공유기는 내부 사용자의 불법 행위나 트래픽 독점을 통제하기 위해 웹 표준인 80과 443 외에 3306을 포함한 RDBMS 전용 소켓 포트를 아웃바운드 레벨에서 전면 차단합니다.

Q. 로컬 네트워크 장비의 포트 필터링 정책으로 3306 포트가 꽁꽁 묶인 환경에서 이를 타파할 수 있는 가장 확실하고 유일한 트러블슈팅 기술은 무엇인가요? 

A. 스마트폰 모바일 핫스팟(테더링) 개방망을 사용하는 것입니다. 공유기 방화벽 영향이 일절 없는 통신사의 무제한 개방형 테더링 망으로 노트북 연결을 전환하고, 변경된 핫스팟 공인 IP를 AWS 인바운드 허용 목록에 올려주면 차단벽을 100% 원천 우회할 수 있습니다.