CI/CD가 필요한 이유

Github Actions와 AWS로 만드는 CI/CD 파이프라인

1. CI/CD가 필요한 이유

예전에는 서버에 코드를 수정하면

• 변경된 파일을 직접 서버에 복사하거나
• jar 파일만 교체하고 톰캣을 재시작하는 식으로 배포했습니다.

이 방식은 변경이 잦아지고 배포 빈도가 높아지면 반복 작업 + 휴먼에러가 필연적으로 발생합니다.

CI/CD는 이 과정을 자동화합니다.
코드가 바뀌면 빌드, 테스트, 배포까지 한 번에 실행되도록 설정해 주기 때문에
사람이 직접 파일을 옮기거나 서버에 명령을 칠 필요가 없습니다.

---

2. Github Actions 

Github Actions는 코드 변경을 감지해서 자동으로 배포까지 해주는 도구입니다.

예시 플로우:

1. 코드 변경 감지 — 특정 브랜치에 push → 자동 시작
2. 코드 준비 — 깃허브에서 소스 내려받기, Java 설치, Gradle 캐시 불러오기
3. 빌드하기 — ./gradlew build로 jar 만들기
4. 도커 이미지 만들기 — jar를 담은 Docker 이미지 빌드
5. AWS 로그인 & 업로드 — AWS ECR에 로그인하고 이미지 푸시
6. 배포하기 — ECS 태스크 정의에 새 이미지 넣고, ECS 서비스에 적용 → 새 컨테이너로 교체

---

3. Docker와 AWS ECS

컨테이너와 Nginx

• 일반 Host OS에서 Nginx는 같은 포트(예: 80)를 두 개 프로세스가 동시에 쓸 수 없습니다.
• 컨테이너를 쓰면 각각이 독립된 네트워크·파일시스템·프로세스 공간을 가지므로 충돌 없이 여러 개 실행 가능.

“컨테이너는 하나의 집 안에 여러 개의 방을 만든 것과 같다.
같은 집에서는 TV(포트 80) 한 대만 켤 수 있지만,
각 방에는 자기만의 TV를 두고 마음대로 켤 수 있는 것처럼,
컨테이너 안에서는 각자 독립된 Nginx를 실행할 수 있다.”

Docker 이미지

• 컨테이너를 실행할 수 있는 실행파일 + 설정값이 들어 있는 패키지
• 모델하우스 설계도에 가구와 장식까지 포함된 것과 같음
  → Docker 엔진이 설계도대로 파일시스템을 만들고, 커널을 연결해 바로 실행

AWS ECR (Elastic Container Registry)

• AWS에서 제공하는 Docker 이미지 저장소
• 빌드한 이미지를 여기에 푸시하면, ECS에서 가져다 쓸 수 있음

AWS ECS (Elastic Container Service)

• AWS가 대신 컨테이너를 띄워주고 관리해주는 서비스
• “컨테이너 몇 개 띄워줘, CPU·메모리는 이만큼, 이 이미지 써”만 지정하면 배포, 헬스체크, 재시작까지 자동

---

4. Nginx와 SSL

요청 흐름

1. 사용자가 example.com 입력
2. DNS가 서버 IP 응답
3. 브라우저가 기본 포트(80/443, 주소에 생략 가능)로 접속
4. Nginx가 요청을 받아 내부 8080 포트로 전달

Certbot 동작 원리 (Let’s Encrypt)

1. Let’s Encrypt 서버에 인증서 발급 요청
2. 무작위 토큰 발급 → Nginx가 해당 경로에 서빙하도록 구성
3. Let’s Encrypt가 해당 URL로 접근해 토큰 확인
4. 검증 성공 시 /etc/letsencrypt/live/<도메인>/ 경로에 인증서 발급

왜 SSL(HTTPS)을 써야 하나?

• 보안 — 데이터 암호화, 중간 탈취/변조 방지
• 신뢰성 — 주소창 자물쇠 표시
• 데이터 무결성 — 전송 중 변경 방지
• 인증 — 서버가 진짜 해당 도메인 소유자임 증명
• SEO 혜택 — 구글 검색 랭킹 가산점
• 브라우저 정책 대응 — HTTP에서 일부 기능 차단 및 경고 표시

---

5. S3와 CloudFront를 이용한 프론트엔드 배포

React 앱의 S3 배포 과정

1. 특정 브랜치에 push/PR → 자동 시작
2. 코드 체크아웃, Node.js 18 설치
3. npm ci로 의존성 설치
4. npm run build → build/ 폴더에 정적 파일 생성
5. AWS 자격 설정
6. aws s3 sync로 S3 버킷에 업로드
7. aws cloudfront create-invalidation으로 전 세계 캐시 무효화

S3 (Simple Storage Service)

• AWS의 파일 저장 서비스
• 트래픽이 늘어도 자동 확장, 정적 웹사이트 호스팅 가능
• React 앱은 빌드 후 정적 파일(JS/CSS/HTML) 로 변환되므로 S3에서 호스팅 가능

CloudFront

• 전 세계 엣지 서버 캐싱으로 속도 향상
• 트래픽 비용 절감 — 캐시 히트로 S3 요청 수 감소
• HTTPS/도메인 지원 — ACM 무료 인증서 적용 가능
• 보안 기능 — 버킷 비공개(OAC), WAF, 지리적 차단, HTTP/2·3 지원

---

6. 마무리

이 구조를 쓰면,

• 백엔드는 Github Actions → Docker → ECR → ECS로 자동 배포
• 프론트엔드는 Github Actions → S3 → CloudFront로 자동 배포
• SSL 인증서(Certbot)로 보안 강화
• Nginx로 라우팅과 리버스 프록시 처리

결과적으로 개발자는 코드를 수정하고 push만 하면 백엔드와 프론트 모두 최신 상태로 안전하게 배포됩니다.