EC2 + Docker + GitHub Actions + Nginx + Route 53 기반 프론트 배포 & HTTPS 적용기

이번 프로젝트에서는 백엔드뿐 아니라 프론트엔드까지 제가 직접 배포를 맡게 되었습니다. 처음에는 막막했지만, AWS EC2를 중심으로 Docker, GitHub Actions, Nginx, Route 53, 그리고 Let's Encrypt를 활용해 도메인에 HTTPS 기반의 프론트 배포까지 성공적으로 마무리했습니다.

이 포스팅에서는 실제 겪었던 문제들과 해결 과정까지 공유합니다.

 

이전에 작성했던 회고록도 함께 보시면 흐름을 이해하는데 도움이 될 수 있습니다.

EC2 + Docker + GitHub Actions Spring Boot 배포 회고

 

 

1. EC2 한 대로 백엔드 + 프론트 함께 운영하기

관리 비용과 리소스를 줄이기 위해 하나의 EC2에서 프론트, 백엔드, MySQL, Redis를 모두 컨테이너로 띄우기로 했습니다. 이는 운영 단순화와 비용 절감을 동시에 노릴 수 있었기 때문입니다.

사용 스택 : EC2, Docker + Docker Compose, GitHub ACtions (CI/CD), Nginx (Reverse Proxy + HTTPS)

 

2. 프론트 CI/CD 구성 - GitHub Actions + ECR + EC2

AWS ECR을 쓰면 GitHub Actions에서 빌드한 이미지를 안전하게 저장하고 EC2에서 쉽게 pull 할 수 있습니다. 사설 저장소이기 때문에 보안적으로도 우수합니다. 추가로 수명 주기 정책(Lifecycle Policy)을 설정하여 최대 이미지가 5개까지만 저장되게 하여 레포지토리의 용량을 효율적으로 관리하고 버전 관리하기 쉽게 설정하였습니다.

 

3. Route 53 + 가비아 도메인 연결

도메인을 가비아에서 구매하고, AWS Route 53을 통해 EC2와 연결하는 작업을 진행하였습니다. 가비아에서 도메인을 등록한 후, Route 53에서 호스팅 영역을 생성했습니다. Route 53은 도메인을 관리할 수 있또록 4개의 기본 네임서버(NS) 레코드를 자동으로 생성하는데, 이 네임서버 값들을 가비아 도메인 관리 페이지에서 직접 등록된 NS 값으로 변경해 주어야 합니다. 이렇게 하면 도메인 네임에 대한 최상위 DNS 요청이 AWS Route 53으로 위임되어 트래픽이 Route 53을 통해 처리될 수 있게 됩니다. 이후 A 레코드에 EC2의 퍼블릭 IP를 지정하여 도메인이 사용자의 요청을 실제 배포 서버로 전달할 수 있도록 구성하였습니다.

 

 

4. HTTPS 적용 ( Nginx + Cerbot + Let's Encrypt)

보안 강화를 위해 HTTPS를 적용하기로 결정하였습니다. 이를 위해 Nginx, Certbot, Let's Encrypt를 활용한 무료 SSL 인증서 기반 설정을 진행했습니다. HTTPS는 사용자 정보 보호뿐 아니라 사이트의 신뢰도를 높이는 핵심 요소로, 최근 Chrome이나 Firefox 같은 브라우저에서는 HTTPS가 적용되지 않은 사이트에 대해 경고 메시지를 표시하기 때문에 필수적으로 고려해야 하는 요소입니다. 또한, 프론트엔드에서 백엔드 API를 호출할 때 발생할 수 있는 CORS 보안 문제도 HTTPS를 통해 해결할 수 있습니다.

 

설정 과정은 먼저 EC2 인스턴스에 Nginx를 설치하고, 보안 그룹에서 80(http)과 443(https) 포트를 허용하는 것으로 시작했습니다. 이후 Nginx를 통해 리버스 프록시를 설정하여, 프론트엔드(3000)와 백엔드(8080) 트래픽을 각각 분기 처리할 수 있도록 구성했습니다. 마지막으로 Certbot을 이용해 도메인에 대한 SSL 인증서를 발급받고, Nginx 설정에 자동으로 적용하여 HTTPS 기반의 보안 연결을 완성했습니다.

 

 

5. 마무리 & 회고

이번 배포 여정은 단순히 배포 그 이상이었습니다. 단일 EC2에서 백/프론트/DB/Redis/Nginx/HTTPS까지 하나하나 구성하면서, 시스템 전체에 대한 이해가 깊어졌습니다.

그리고 이번 과정을 통해 "왜 DevOps라는 분야가 따로 존재하는지"를 몸소 깨달을 수 있었습니다. 예전에 DevOps 개발자 강연을 들었을 때, 그분은 "개발자들이 코딩에만 집중할 수 있도록 환경을 만들어주는 것이 DevOps의 역할"이라고 말했는데, 지금은 그 말이 뼈저리게 와닿습니다. 개발자는 기능만 만들면 끝나는 줄 알았는데, 실제 운영 환경에서는 너무나 다양한 인프라 지식과 연결 과정이 필요하다는 걸 직접 경험했기 때문입니다.

이 인프라 구성 경험은 앞으로 개발자로서 한층 더 넓은 시야를 갖게 해주는 기반이 될 것입니다.