[Control Tower]Spring Boot + AWS RDS + Nginx 배포기: 삽질하며 배운 인프라의 중요성

🧐 왜 EC2와 RDS를 분리했는가?

처음 배포를 구상할 때 EC2 한 대에 모든 것을 넣을 수도 있었지만, 실제 상용 서비스 수준의 아키텍처를 지향하며 **컴퓨팅(EC2)**과 **데이터 저장(RDS)**을 분리했습니다.

• 보안: DB를 사설망에 격리하고 EC2의 보안 그룹을 통해서만 접근을 허용하여 데이터 노출 위험을 줄였습니다.
• 가용성: 서버가 다운되어도 데이터는 안전하게 보존되며, RDS의 자동 백업 기능을 활용할 수 있기 때문입니다.
• 확장성: 트래픽이 몰릴 때 WAS와 DB의 자원 점유를 분리하여 성능 저하를 방지했습니다.

---

🛠 배포 아키텍처: Nginx 리버스 프록시와 보안

사용자가 api.도메인으로 접속하면 Nginx가 이를 받아 내부의 **8080 포트(Spring Boot)**로 넘겨주는 리버스 프록시 구조를 채택했습니다.

Nginx를 앞세운 이유

1. 포트 은닉: 8080 포트를 외부에 노출하지 않고 80/443 포트로 깔끔하게 서비스할 수 있습니다.
2. HTTPS 적용: Certbot을 연동하여 SSL 인증서 관리와 리다이렉션 설정을 자동화했습니다.
3. 정적 자원 처리: API 요청 외의 처리를 분담하여 WAS의 부담을 덜어줍니다.

---

🚧 고난의 기록: 배포를 생각하지 않은 개발의 대가

이번 프로젝트에서 가장 뼈아프게 배운 점은 "로컬 환경과 배포 환경은 천차만별이다"라는 사실입니다.

1. 양방향 통신(WebSocket/SSE)과 Nginx의 충돌

우리 서비스의 핵심인 **실시간 알림(SSE)**과 **채팅(WebSocket)**을 배포했을 때 정상적으로 동작하지 않았습니다.

• 원인: Nginx의 기본 설정이 지속적인 연결(Persistent Connection)을 끊어버렸기 때문입니다.
• 해결: Nginx 설정 파일에 Upgrade, Connection 헤더 설정을 명시하고, 타임아웃 시간을 늘려주는 설정을 추가하며 해결했습니다. 배포 단계에서 네트워크 프로토콜에 대한 깊은 이해가 왜 필요한지 깨닫는 계기가 되었습니다.

2. "내 컴퓨터에선 됐는데..."

로컬 DB 설정과 AWS 환경 설정이 섞여 있어 배포 시 빌드 에러가 잦았습니다. 이를 방지하기 위해 application-prod.yml을 분리하고, DB 접속 정보와 같은 민감 정보는 EC2 환경변수를 통해 주입받도록 고도화했습니다.

---

💡 향후 고도화 계획

1. CI/CD 파이프라인 구축

현재는 수정 사항이 생길 때마다 수동으로 빌드하고 scp로 파일을 넘기고 있습니다. 나중에는 로컬에서 코드를 Push하면 GitHub Actions나 Jenkins를 통해 AWS에 자동으로 배포되는 환경을 구축해보고 싶습니다.

2. 아키텍처 고도화 (S3 + CloudFront)

현재 정적 자원도 서버에서 처리하는 부분이 일부 있는데, 이를 S3와 CloudFront 조합으로 완전히 분리하여 백엔드 서버는 오직 비즈니스 로직(API)에만 집중할 수 있는 구조로 개선할 예정입니다.

---

✨ 마치며

"코딩만 잘하면 배포는 금방 하겠지"라는 생각이 얼마나 안일했는지 알게 된 프로젝트였습니다. 하지만 직접 서버를 세팅하고, 도메인을 연결하고, Nginx 설정을 만지며 서비스 전체의 흐름을 보는 시야를 가질 수 있었습니다. 다음 프로젝트에서는 설계 단계부터 '배포 환경'을 최우선으로 고려하는 개발자가 되겠습니다.