1. 프로젝트 소개

“테크 뉴스 및 개발 블로그 통합 크롤링 기반 커뮤니티 서비스”

산발적으로 흩어져 있는 IT·테크 최신 뉴스와 개발자 블로그 글을 수집·정리하여 사용자에게 제공하고,
수집된 정보를 바탕으로 실시간 그룹 채팅을 통해 의견을 나눌 수 있는 커뮤니티 플랫폼을 개발했습니다.

사용자는 한 곳에서 기술 트렌드를 빠르게 파악하고, 다른 개발자들과 실시간으로 토론하며 더 깊이 있는 정보 교류가 가능합니다.

  • 기간: 2025.11.28 ~ 2025.12.16 (약 18일)
  • 발표: 2025.12.17
  • 인원: 7명
  • 내 역할: 인프라 구축

2. 일정 (Timeline)

  • 11/28 ~ 12/01: ERD 작성 및 기능 구체화 / 인프라 개념 학습
  • 12/01 ~ 12/05: 프로젝트 기초 세팅
    • 코딩 컨벤션 / 패키지 컨벤션
    • GitHub 조직 생성
    • 고정 회의 날짜 지정
  • 12/05 ~ 12/11: 기능 구현 완료 / 기획서 작성
  • 12/11 ~ 12/16: 로컬 통합 테스트 + 운영 통합 테스트 + 발표 자료 정리
  • 12/17: 발표

3. 내가 기여한 부분 (My Contributions)

✅ 백엔드 기본 세팅

  • Spring Boot 기본 세팅
  • 패키지 컨벤션 적용
  • 공통 API 응답 구조 설정

✅ 컨테이너 환경 구성

  • Docker 환경 구성
  • Docker Compose 구성 (로컬/운영 환경 고려)

✅ 환경 분리 (Profile)

  • Spring Profile 설정
    • 공통 / 개발 / 운영 환경 분리

✅ 인프라 구축

  • IAM
  • ECR / EC2 / RDS
  • ACM
  • Cloudflare
  • ALB

✅ CI/CD 구축

  • GitHub Actions 구성
    • CI.yml
    • Deploy.yml

4. 인프라 구조

 

5. 기술 선정 이유

 

 

1. CloudFlare vs Route53

DNS와 보안/가속 기능 측면에서, 저희는 Cloudflare를 선택했습니다. Cloudflare는 DNS뿐 아니라 CDN, SSL/TLS, DDoS 대응, WAF 같은 에지 보안 기능을 한 곳에서 제공해서, 초기 단계에서 구성과 운영 복잡도를 줄이면서도 기본적인 보안과 성능을 확보할 수 있었습니다.

반면 AWS에서 유사한 수준의 기능을 구성하려면, Route 53 자체가 아니라 CloudFront와 WAF 등 여러 서비스를 조합해야 하고, 이 과정에서 추가 비용과 설정/운영 부담이 커질 수 있다고 판단했습니다. 그래서 저희 프로젝트 상황에서는 Cloudflare가 비용/구성/운영 측면에서 더 효율적이라 선택했습니다.

 

2. ECR vs Docker Hub

이미지 레지스트리로 Docker Hub 대신 AWS ECR을 선택한 이유입니다. 저희 인프라는 EC2, ALB, RDS 등 대부분 AWS 기반으로 구성되어 있기 때문에, ECR을 사용하면 IAM 기반 권한 관리, 배포 서버에서의 인증/연동, 그리고 운영 측면에서의 관리 일관성을 확보할 수 있었습니다.

또한 Docker Hub는 정책에 따라 이미지 Pull에 대한 rate limit이 존재해 배포/스케일 상황에서 불확실성이 생길 수 있는데, ECR은 AWS 내부 서비스로서 배포 파이프라인과 연계가 안정적이고, Private 저장소 + 접근 제어 측면에서도 운영에 더 적합하다고 판단했습니다.

 

3. ALB 사용이유

첫째, HTTPS 적용을 위해 **SSL/TLS 인증서를 ALB에서 종료(TLS Termination)**하도록 구성했습니다.

이를 통해 애플리케이션 서버(EC2)는 HTTP로 단순하게 운영하면서도, 외부 통신은 ALB에서 안전하게 암호화된 HTTPS로 처리할 수 있습니다. 또한 인증서는 ACM과 연동해 갱신/관리 부담을 줄일 수 있습니다.

둘째, 현재는 단일 서버 구조이지만, 추후 트래픽이 증가해 서버를 여러 대로 확장할 경우 ALB가 로드밸런서 역할을 수행하여 요청을 여러 인스턴스에 분산할 수 있습니다.

즉, 지금은 HTTPS 관문 역할을 하고, 향후에는 확장성과 고가용성을 위한 진입점으로 활용하기 위해 ALB를 선택했습니다.

6. 트러블 슈팅

 

1. Redis 연결 오류

Docker Compose로 Redis와 Spring 애플리케이션을 함께 띄우는 과정에서 발생한 이슈입니다. 로컬에서는 정상 동작했지만, 운영 환경으로 배포했을 때 Spring 애플리케이션에서 Redis 연결 오류가 발생했습니다.

처음에는 redis라는 호스트명을 인식하지 못해 환경변수 주입 과정 문제를 의심했는데, 원인을 확인해보니 Redis 컨테이너와 App 컨테이너가 같은 Docker 네트워크에 묶여 있지 않아, 서비스 이름(redis) 기반의 DNS 해석/통신이 되지 않았던 문제였습니다.

그래서 docker-compose.yml에 명시적으로 동일 네트워크를 지정했고, 운영 환경에서는 필요 시 해당 네트워크를 외부 네트워크로 생성/연결해 주어 두 컨테이너가 같은 네트워크에서 통신하도록 구성했습니다. 그 결과 운영 환경에서도 Redis 연결 문제가 정상적으로 해결되었습니다.

 

2. Docker Build 시간 단축 ( 10분 -> 1분 )

자동 배포 과정에서 Docker 이미지 빌드와 ECR Push가 유난히 오래 걸렸던 문제입니다. 처음에는 네트워크 문제로 push가 느린 것이라고 생각했지만, 배포 과정을 점검하면서 Docker 레이어 캐시가 제대로 활용되지 않고 매번 거의 전체 빌드가 다시 수행되는 상황임을 확인했습니다.

원인은 배포 과정에서 application.yml을 빌드 과정 중에 생성/주입하면서, 해당 단계가 매번 변경되어 상위 레이어가 계속 무효화되고 그 결과 의존성 설치/빌드 단계까지 캐시가 깨지는 구조였던 점이었습니다.

그래서 이미지 빌드 단계에서는 설정 파일을 만들지 않고, 런타임에 환경변수만 전달하도록 변경했습니다. 또한 캐시가 잘 적용되도록 빌드 흐름을 정리하여 레이어 캐싱이 안정적으로 동작하게 만들었고, 그 결과 기존에 약 10분 정도 걸리던 과정이 약 1분 수준으로 단축되었습니다

 

7. 잘한 점 (Keep)

  • 인프라에 대한 막연한 두려움이 있었는데, 이번에 직접 구성해보면서 두려움이 확실히 줄었다.
  • 개념과 명령어들을 노션에 정리하면서 구조를 잡아두니, 이후에 비교/복습하면서 빠르게 적용할 수 있었다.
  • 헷갈리는 부분은 혼자 붙잡지 않고 주변에 도움을 요청해서 해결 속도를 높인 점이 좋았다.

8. 아쉬운 점 (Problem)

  • 일정이 지연되는 경우가 있었는데, 다음에는 “최대한 해볼게요”가 아니라
    약속한 시점에는 끝낼 수 있도록 계획을 더 구체화해야겠다.
  • “운영환경에서 되길 기도하는” 순간이 있었다…
    다음에는 로컬에서 운영과 최대한 유사한 환경으로 테스트하고, 운영 테스트도 더 체계적으로 진행하자.
  • 로그 작성 습관이 부족했다.
    다음 프로젝트에서는 디버깅/운영을 위해 로그를 더 일관되게 남기자.
  • 무분별한 PR로 Commit 가독성을 잃은점 -> 좀 더 일관된 commit 컨벤션으로 작성하자.
  • 코드리뷰를 좀 더 자세하게 하지 못한 부분이 아쉽다. 

9. 더 나아가 생각해볼 것

1) ECS on EC2

  • **ECS(Elastic Container Service)**로 컨테이너를 운영하되, 실행 환경(서버)을 내가 직접 EC2로 프로비저닝해서 올리는 방식입니다.
  • 장점: 인스턴스 스펙/비용(스폿 등) 최적화, 커스터마이징 자유도 높음
  • 단점: EC2 패치/오토스케일링/용량관리 등 운영 부담이 늘어남

2) ECS on Fargate

  • ECS로 컨테이너를 운영하되, 서버 관리는 AWS가 해주는 서버리스 컨테이너 실행 방식입니다.
  • 장점: EC2 관리(패치/용량/서버 운영) 없이 Task 단위로 바로 실행, 운영 난이도 낮음
  • 단점: EC2 직접 운영 대비 비용이 더 나올 수 있고, 세밀한 튜닝은 제한적

한 줄 요약: ECS on EC2 = 서버는 내가 관리, ECS on Fargate = 서버 관리는 AWS가.

3) VPC / Subnet 설정

  • VPC는 AWS 안에서 만드는 “내 전용 네트워크 공간”이고, Subnet은 그 안을 더 쪼갠 네트워크 구역입니다.
  • 일반적으로 Public Subnet(인터넷과 연결: ALB, Bastion 등)과 Private Subnet(외부 직접 접근 차단: EC2/ECS, RDS 등)으로 분리해 보안을 강화합니다.
  • 라우팅(IGW/NAT), 보안그룹/네트워크 ACL까지 포함해서 “네트워크 설계”를 탄탄히 하는 작업입니다.

4) 무중단 배포(Zero-downtime Deployment)

  • 배포 중에도 사용자가 끊김 없이 서비스를 이용하도록 하는 배포 방식입니다.
  • 대표 전략:
    • Rolling: 인스턴스를 조금씩 교체(점진 배포)
    • Blue/Green: 기존(Blue) 유지 + 신규(Green) 올린 뒤 트래픽만 전환(ALB Target Group 전환)
  • 보통 ALB Health Check + 두 개 이상의 인스턴스/태스크가 있어야 안정적으로 구현할 수 있습니다.

5) Nginx

  • **Nginx는 웹 서버이자 리버스 프락시(Reverse Proxy)**로, 클라이언트 요청을 받아서 내부의 애플리케이션 서버(Spring)로 전달해 주는 역할을 합니다.
  • 주로 다음 목적에서 사용합니다:
    • 정적 파일 서빙(이미지/JS/CSS 등) 또는 캐싱
    • 리버스 프록시로 API 요청을 백엔드로 전달(경로 기반 라우팅 등)
    • HTTPS(SSL/TLS) 종료 및 인증서 적용(환경에 따라 ALB 대신/또는 함께)
    • 로드 밸런싱(여러 백엔드 서버로 분산)
    • 보안/운영 편의: IP 제한, 특정 경로 차단, 요청 크기 제한, CORS/헤더 설정 등
    • 무중단 배포 보조: Blue/Green 구성에서 upstream을 바꾸거나, 헬스체크 기반으로 트래픽 전환

한 줄 요약: Nginx는 외부 요청의 ‘관문’ 역할을 하면서, 백엔드로 트래픽을 안정적으로 전달하고 운영 기능을 붙여주는 컴포넌트입니다.

 

티스토리툴바