1. 기술적 의사 결정: GitHub Actions 선택 이유

프로젝트 배포 파이프라인을 구축할 때, Jenkins와 GitHub Actions 두 가지 옵션을 검토했습니다. 여러 측면에서 비교한 결과, GitHub Actions를 선택한 주요 이유는 다음과 같습니다.

1) 통합 및 사용 편의성

GitHub Actions:
GitHub Actions는 GitHub 리포지토리와 완벽하게 통합되어 있어 별도의 CI/CD 서버를 구성할 필요 없이, 소스 코드 변경과 동시에 자동화된 배포 파이프라인을 바로 구축할 수 있습니다. 또한, YAML 기반의 워크플로우 설정이 직관적이어서 빠르게 학습하고 적용할 수 있습니다.

Jenkins:
Jenkins는 강력한 플러그인 에코시스템과 커스터마이징 가능성을 제공하지만, 별도의 설치, 관리, 유지보수가 필요합니다. GitHub와의 연동도 플러그인을 추가해야 하는 등 초기 설정과 관리에 더 많은 노력이 요구됩니다.

2) 유지보수 및 비용 효율성

GitHub Actions:
GitHub Actions는 클라우드 기반으로 운영되며, GitHub 리포지토리 내에서 관리되기 때문에 별도의 서버 관리 부담이 없습니다. 또한, 사용량에 따라 무료 제공 범위가 있어 소규모부터 중규모 프로젝트에 비용 효율적으로 적용할 수 있습니다.

Jenkins:
Jenkins는 자체 호스팅이 일반적이므로, 서버 관리, 보안 업데이트, 백업 등의 추가 유지보수 작업이 필요하며, 인프라 비용이 발생할 수 있습니다.

3) 확장성과 커뮤니티 지원

GitHub Actions:
GitHub Actions는 GitHub의 활발한 커뮤니티와 풍부한 오픈소스 액션들이 이미 제공되고 있어, 필요에 따라 다양한 액션을 쉽게 활용할 수 있습니다. 또한, GitHub의 인프라를 활용하여 높은 확장성을 확보할 수 있습니다.

Jenkins:
Jenkins 또한 오랜 기간 널리 사용되며 방대한 플러그인을 보유하고 있지만, 플러그인 간의 호환성 문제나 업데이트 관리 등에서 복잡성이 증가할 수 있습니다.

2. Docker 및 Docker Hub를 활용

배포 프로세스의 효율성과 일관성을 높이기 위해, 애플리케이션을 Docker 이미지로 빌드하고 Docker Hub에 업로드한 후, EC2 서버에서 해당 이미지를 다운로드하여 컨테이너로 실행하는 방식을 채택했습니다.

Docker 사용 이유

애플리케이션을 이미지 파일로 패키징하여 환경 간 일관성을 보장
로컬, 스테이징, 프로덕션 등 다양한 배포 환경에서 동일한 이미지를 사용할 수 있어 배포 및 유지보수가 용이

Docker Hub 사용 이유

중앙화된 이미지 저장소를 통해 배포 파이프라인에서 손쉽게 이미지를 관리
CI/CD 파이프라인과의 원활한 연계를 통해 빌드된 이미지를 자동으로 푸시하고, EC2 서버에서는 이를 풀(Pull) 받아 최신 버전으로 배포 가능

3. 결론

GitHub Actions를 선택함으로써, GitHub와의 완벽한 통합과 간편한 YAML 설정을 통해 CI/CD 파이프라인을 효율적으로 구축할 수 있습니다. 또한, Docker와 Docker Hub를 활용한 배포 전략은 애플리케이션의 일관된 환경 제공 및 배포 자동화를 가능하게 하여, EC2 서버에서 최신 이미지를 손쉽게 배포할 수 있도록 합니다. 이러한 기술적 의사 결정은 초기 설정과 유지보수의 부담을 줄이고, 배포 과정에서의 효율성과 확장성을 극대화하는 데 기여합니다.