[TIL]CI/CD, GitHub Actions, Argo CD, Jenkins, Kubernetes, AWS 배포

1. 학습 주제

애플리케이션을 개발한 뒤 서버에 배포하는 흐름과, 이를 자동화하는 CI/CD 개념을 학습했다.
또한 AWS 환경에서 직접 배포를 진행하며 EC2와 Elastic Beanstalk 같은 배포 방식의 차이를 정리했다.

핵심 내용은 다음과 같다.

• CI/CD 개념
• GitHub Actions
• Jenkins
• Argo CD
• Kubernetes
• AWS EC2 배포
• Elastic Beanstalk
• VPC 기본 개념

---

2. CI/CD란?

CI/CD는 개발한 코드를 자동으로 검사하고 배포하기 위한 개발 자동화 흐름이다.

코드 작성
-> Git push
-> 빌드
-> 테스트
-> 이미지 생성
-> 서버 배포

CI와 CD는 역할이 조금 다르다.

구분	의미	역할
CI	Continuous Integration	코드 변경 사항을 자주 통합하고 빌드/테스트
CD	Continuous Delivery 또는 Continuous Deployment	검증된 코드를 배포 가능한 상태로 만들거나 실제 배포

CI는 “코드가 정상적으로 합쳐질 수 있는지 확인하는 단계”에 가깝다.
CD는 “검증된 결과물을 서버에 반영하는 단계”에 가깝다.

---

3. CI가 필요한 이유

여러 명이 동시에 개발하면 코드가 자주 바뀐다.
이때 사람이 매번 직접 빌드하고 테스트하면 실수하기 쉽고 시간이 많이 든다.

CI를 사용하면 Git에 코드가 올라갈 때마다 자동으로 확인할 수 있다.

push 또는 pull request
-> 의존성 설치
-> build
-> test
-> 결과 확인

CI의 목적은 문제가 있는 코드가 main 또는 dev 브랜치에 섞이는 것을 줄이는 것이다.

---

4. CD가 필요한 이유

CD는 배포 과정을 자동화한다.

수동 배포는 보통 다음 작업을 사람이 직접 해야 한다.

서버 접속
-> 최신 코드 받기
-> 빌드
-> 실행 중인 서버 중지
-> 새 버전 실행
-> 로그 확인

CD를 사용하면 이 흐름을 자동화할 수 있다.

배포 브랜치에 merge
-> 빌드
-> Docker 이미지 생성
-> 서버 또는 Kubernetes에 반영

배포 자동화의 장점은 다음과 같다.

• 반복 작업을 줄일 수 있다.
• 사람의 실수를 줄일 수 있다.
• 배포 속도가 빨라진다.
• 배포 이력을 추적하기 쉽다.

---

5. GitHub Actions

GitHub Actions는 GitHub에서 제공하는 CI/CD 자동화 도구이다.

GitHub 저장소 안에 workflow 파일을 작성하면 특정 이벤트에 맞춰 작업이 실행된다.

push
pull_request
workflow_dispatch

예를 들어 다음 흐름을 만들 수 있다.

GitHub에 push
-> GitHub Actions 실행
-> Gradle build
-> 테스트
-> Docker 이미지 빌드
-> 배포 서버로 전달

GitHub Actions는 GitHub 저장소와 바로 연결되어 있기 때문에, 개인 프로젝트나 팀 프로젝트에서 CI를 시작하기 쉽다.

---

6. Jenkins

Jenkins는 오래전부터 많이 사용된 CI/CD 도구이다.

GitHub Actions가 GitHub 중심의 자동화라면, Jenkins는 별도의 서버에 설치해서 사용하는 자동화 서버에 가깝다.

Jenkins 서버
-> Git 저장소 감지
-> 빌드
-> 테스트
-> 배포 스크립트 실행

Jenkins의 특징은 다음과 같다.

• 플러그인이 많다.
• 오래된 회사 시스템에서도 많이 사용된다.
• 자유도가 높다.
• 직접 서버를 운영해야 하므로 관리 부담이 있다.

정리하면 다음과 같다.

도구	특징
GitHub Actions	GitHub 저장소와 연동이 쉽고 설정이 간단
Jenkins	자유도가 높고 기존 기업 환경에서 많이 사용

---

7. Argo CD

Argo CD는 Kubernetes 환경에서 많이 사용하는 GitOps 기반 배포 도구이다.

GitOps는 Git 저장소를 배포 상태의 기준으로 삼는 방식이다.

Git에 배포 설정 변경
-> Argo CD가 감지
-> Kubernetes 상태와 비교
-> Git 상태와 다르면 자동 동기화

즉, Argo CD는 “Git에 적힌 상태가 실제 서버 상태가 되도록 맞춰주는 도구”라고 볼 수 있다.

예를 들어 Git에 다음 상태가 있다면:

backend image: v2
replicas: 3

Argo CD는 Kubernetes 클러스터가 실제로 이 상태가 되도록 반영한다.

---

8. Kubernetes

Kubernetes는 컨테이너를 여러 서버에서 안정적으로 실행하고 관리하는 플랫폼이다.

Docker가 컨테이너 하나를 실행하는 데 초점이 있다면, Kubernetes는 여러 컨테이너를 운영 환경에서 관리하는 데 초점이 있다.

Kubernetes가 해주는 일은 다음과 같다.

• 컨테이너 실행
• 여러 서버에 컨테이너 배치
• 장애가 난 컨테이너 재시작
• 트래픽 분산
• 배포 버전 관리
• 스케일 아웃
• 설정과 비밀값 관리

정리하면 다음과 같다.

Docker = 컨테이너 실행 도구
Kubernetes = 컨테이너 운영/관리 플랫폼

---

9. CI/CD 도구들의 관계

각 도구는 역할이 조금씩 다르다.

도구	주 역할
GitHub Actions	GitHub 이벤트 기반 빌드/테스트/배포 자동화
Jenkins	독립적인 CI/CD 자동화 서버
Argo CD	Kubernetes 배포 상태를 Git 기준으로 동기화
Kubernetes	컨테이너 실행과 운영 관리

예시 흐름은 다음과 같다.

GitHub Actions
-> 코드 빌드
-> 테스트
-> Docker 이미지 생성
-> 이미지 저장소에 push

Argo CD
-> Git의 Kubernetes 배포 설정 감지
-> Kubernetes 클러스터에 반영

---

10. AWS EC2 배포

EC2는 AWS에서 제공하는 가상 서버이다.
직접 Ubuntu 서버를 만들고, 그 안에 Java, Docker, Nginx 같은 필요한 도구를 설치해서 애플리케이션을 실행할 수 있다.

EC2 배포 흐름은 다음과 같다.

EC2 인스턴스 생성
-> SSH 접속
-> 필요한 런타임 설치
-> 프로젝트 파일 또는 Docker 이미지 준비
-> 서버 실행
-> 보안 그룹에서 포트 오픈
-> 외부 접속 확인

EC2만 사용해도 프로젝트 배포는 가능하다.
다만 로드 밸런싱, 자동 스케일링, 모니터링 같은 기능은 직접 추가로 구성해야 한다.

---

11. Elastic Beanstalk

Elastic Beanstalk는 AWS에서 애플리케이션 배포를 쉽게 해주는 서비스이다.

직접 EC2를 하나하나 설정하는 대신, 애플리케이션을 올리면 필요한 인프라 구성을 AWS가 대신 처리해준다.

Elastic Beanstalk가 도와주는 기능은 다음과 같다.

• 프로비저닝
• 로드 밸런싱
• 자동 스케일링
• 모니터링
• 애플리케이션 배포 관리

여기서 프로비저닝은 애플리케이션 실행에 필요한 서버, 네트워크, 환경을 준비하는 과정이다.

서버 생성
-> 런타임 준비
-> 네트워크 설정
-> 배포 환경 구성

---

12. EC2와 Elastic Beanstalk 차이

EC2는 서버를 직접 빌려서 직접 관리하는 방식이다.
Elastic Beanstalk는 애플리케이션 중심으로 배포하면 AWS가 필요한 EC2와 관련 리소스를 어느 정도 자동으로 관리해주는 방식이다.

구분	EC2	Elastic Beanstalk
관리 단위	서버	애플리케이션 환경
설정 자유도	높음	상대적으로 제한 있음
운영 편의성	직접 관리 필요	자동 구성 기능 제공
적합한 경우	서버 설정을 직접 제어하고 싶을 때	빠르게 배포 환경을 만들고 싶을 때

기존 프로젝트를 단순히 올려보는 단계라면 EC2만으로도 충분하다.
하지만 로드 밸런싱, 자동 스케일링, 모니터링까지 편하게 붙이고 싶다면 Elastic Beanstalk를 고려할 수 있다.

---

13. VPC

VPC는 AWS 안에서 사용하는 사용자 전용 가상 네트워크이다.

AWS 전체 공간 안에
내 서비스만 사용하는 네트워크 영역을 따로 만드는 것

VPC 안에서 다음을 설정할 수 있다.

• IP 대역
• Subnet
• Routing Table
• Internet Gateway
• Security Group
• Network ACL

EC2도 결국 특정 VPC와 Subnet 안에 생성된다.
외부에서 접속하려면 인터넷 연결 경로와 보안 그룹 설정이 맞아야 한다.

---

14. 실제 AWS 배포 흐름

실제 배포를 진행할 때는 코드 실행만 보면 안 되고, 서버와 네트워크까지 함께 확인해야 한다.

기본 흐름은 다음과 같다.

1. 애플리케이션 빌드
2. 서버 또는 배포 서비스 준비
3. 실행 환경 설정
4. 애플리케이션 업로드 또는 이미지 배포
5. 서버 실행
6. 포트 확인
7. AWS 보안 그룹 확인
8. 외부 접속 테스트

로컬에서 잘 실행되더라도 EC2에서 접속이 안 되면 다음을 확인해야 한다.

• 애플리케이션이 실제로 실행 중인가
• 서버 내부 포트가 열려 있는가
• EC2 보안 그룹에서 해당 포트를 허용했는가
• 퍼블릭 IP 또는 도메인이 올바른가
• 방화벽 또는 네트워크 설정이 막고 있지 않은가

---

15. 핵심 정리

1. CI/CD는 빌드, 테스트, 배포 흐름을 자동화하는 방식이다.
2. CI는 코드 변경을 자동으로 빌드하고 테스트하는 단계이다.
3. CD는 검증된 결과물을 배포 가능한 상태로 만들거나 실제 서버에 배포하는 단계이다.
4. GitHub Actions는 GitHub 이벤트 기반으로 CI/CD를 구성하는 도구이다.
5. Jenkins는 별도 서버에서 운영하는 범용 CI/CD 자동화 도구이다.
6. Argo CD는 Kubernetes 환경에서 Git 상태를 기준으로 배포를 동기화하는 GitOps 도구이다.
7. Kubernetes는 컨테이너를 여러 서버에서 운영하고 관리하는 플랫폼이다.
8. EC2는 AWS에서 제공하는 가상 서버이며 직접 서버 설정과 배포를 관리해야 한다.
9. Elastic Beanstalk는 배포에 필요한 서버, 로드 밸런싱, 자동 스케일링, 모니터링을 대신 구성해주는 서비스이다.
10. VPC는 AWS 안에서 사용하는 사용자 전용 가상 네트워크이다.
11. EC2만으로도 배포는 가능하지만 운영 편의 기능은 직접 구성해야 한다.
12. 실제 배포에서는 애플리케이션 실행뿐 아니라 포트, 보안 그룹, 네트워크 설정까지 함께 확인해야 한다.