[플젝기록] 배포와 배포 자동화 CI/CD 고민의 흔적: Jenkins vs GitHub Actions

예전 프로젝트에서 배포 방식을 고민하면서 짧게 적어둔 글이 있었는데, 마침 오늘 올릴 거 없나 뒤져보다가 발견했다.

CI/CD는 흔히들 묶어서 부르지만, 사실 각각의 용어가 꽤 넓은 함의를 갖고 있다. 나는 주로 코드 통합, 빌드, 배포에만 신경쓰다보니, 자소서나 이력서에 CI/CD에 대해 적을 때면 이걸 내가 할 줄 안다고 적는 것이 맞을까 망설이게 될 때도 있다. 하지만 코드뿐만 아니라 많은 분야의 지식이 늘 그렇다. 조금 알게되면 내가 더 많이 모르고 있었다는 것을 깨닫게 될 뿐이다. 그렇게 조금씩 알아가면서 또 새로운 미지의 세계가 펼쳐지는 것을 보면서 한 걸음씩 나아가는 것 뿐이지. 그래서 이제는 그냥 이런 경험을 해 보았고 할 줄 압니다~ 라고 적는 것에 만족하고 있다.

최근에는 새롭게 배포할 일이 없어서 기존의 자동화된 배포 프로세스를 유지하고 간간히 점검하는 정도인데, 언젠가 배포 과정을 최적화해야겠다는 결심만 해두고 자꾸 미루고 있다. AWS 프리티어도 슬슬 다해가고 있어서 무료 배포를 알아봐야 하는데 백엔드 서버는 DB도 (로컬을 쓸 게 아니라면) 같이 배포해야 하는지라 이래저래 고민할 게 많다. 일단 닥친 문제부터 어떻게 좀 하고...

---

배포(CI / CD) - Continuous Integration / Continuous Deployment

• Continuous Integration (지속적 통합):
  • 코드가 지속적으로 통합되고 테스트되는 프로세스.
  • 여러 개발자들이 동시에 작업하더라도, 각자의 변경 사항이 공유 코드베이스에 통합될 때마다 자동으로 빌드 및 테스트를 수행.
  • 목표 : 문제 초기 발견 통한 통합 오류 최소화 + 팀 전체가 안정적인 코드베이스 유지.
• Continuous Deployment (지속적 배포):
  • 통합된 코드가 자동으로 프로덕션 환경에 배포되는 프로세스.
  • CI에서 통과한 코드는 자동으로 스테이징 환경 등을 거쳐 프로덕션 환경으로 배포.
  • 목표 : 더 빠르게 새로운 기능을 사용자에게 제공 + 소프트웨어의 배포 주기 단축 및 릴리스 주기 효과적으로 관리.

1. 빠른 피드백: 코드 변경이 발생할 때마다 자동으로 테스트 = 오류를 발견 / 수정 빠름
2. 안정성 향상: 통합된 코드베이스가 항상 테스트되므로 안정성 향상, 배포 오류 감소.
3. 자동화: 빌드, 테스트, 배포와 같은 반복적이고 루틴 작업을 자동화하여 효율성 증가.
4. 빠른 릴리스: 새로운 기능이나 수정된 코드를 신속하게 사용자에게 제공 = 경쟁 우위 확보.

 

각설하고 본론으로 넘어왔다. CI는 코드베이스에 안정적으로 통합되는 것을 기본으로 한다. 이후 CD 과정에서 프로덕션 환경에 배포되는 것으로 보통 CI/CD를 구축했다고 하면 코드를 커밋commmit 했을 때 코드베이스 통합부터 프로덕션 배포까지 자동으로 진행되는 파이프라인을 구축했다는 것을 의미한다.

흔히 사용되는 툴에는 Jenkins, GitHub Actions 그리고 AWS에서 제공하는 배포 툴도 있는데, AWS는 보통 비용이 나가서... 이건 얼마인지 알아보지 않았는데 하여튼 사이드 프로젝트에서는 보통 Jenkins 혹은 GitHub Actions을 사용한다. 나는 대학에서는 Jenkins를 배웠는데 이후 부트캠프에서 배운 GitHub Actions이 훨씬 간단하고 편리하다고 느껴서 후자로 주로 사용한다.

 

Jenkins 젠킨스

: 오픈 소스 CI/CD 도구로, 빌드, 배포 및 자동화된 테스트를 수행하는 데 사용. 확장 가능하며, 플러그인을 통해 다양한 통합 가능.

• Web UI를 통해 Job을 구성 / 관리.
• 자체 서버에 설치되고 구성해야 함. 서버 관리, 플러그인 업데이트 등을 수동 처리해야 함.
• Groovy 기반의 Pipeline DSL을 사용하여 복잡한 빌드 및 배포 프로세스를 정의할 수 있음.

GitHub Actions 깃허브 액션

: GitHub에서 제공하는 네이티브 CI/CD 서비스, 코드 레포지토리와 쉽게 통합됨.

• .github/workflows 디렉토리에 정의된 YAML 파일을 사용하여 작업 정의.
• GitHub 레포지토리에 네이티브로 통합되어 있어 별도의 설치 없이 사용 가능.
• GitHub 레포지토리와 긴밀하게 통합되어 있어 설정 간단하고 관리 용이.
• Workflow를 통해 여러 Job을 조합하고, 이벤트 트리거를 통해 배포 자동화 가능.

 

개인적으로 느낀 장점은 다음과 같다.

GitHub Actions는 GitHub과 연결되어 있다는 것이 가장 큰 장점이다. GitHub는 많은 사람들이 사용하는 분산형 버전 관리 시스템인 Git의 연동 플랫폼으로, 코드를 보관하고 협업하는데 편리한 많은 기능을 제공하고 있다. 브랜치를 나누고 버전과 형상을 관리하는 기능이라 혼자 일할때도 편리한 기능이라 많은 개인 프로젝트에서도 활용된다. GitHub Actions은 GitHub repository와 연동하여 특정 브랜치에 merge 되는 것을 이벤트 트리거로 삼는 방식이 일반적이다. 나또한 main-develop-feature-fix-release의 일반적인 git flow에 익숙해서 release branch를 트리거로 두는 방식을 주로 사용한다. 배포에는 Docker를 활용하는데 이건 나중에 자세히 풀 일이 있겠지... 특별하진 않고 많이들 쓰는 방식이다.

Jenkins는 과제로만 써봤고 실제 프로젝트에는 써 본적이 없는데, 과제할 당시에 느꼈던 특징은 자유도가 굉장히 높다는 점이다. GitHub Actions도 일종의 스크립트를 통해 관리하는 방식이라 작성하는 스크립트에 따라 이벤트 트리거부터 그외 옵션까지 다양하게 설정할 수 있지만, Jenkins는 정말 다양한 기능을 자유롭게 풀어놓고(?) 제공해서 러닝 커브도 좀 있지만 여러 트리거를 두어야 하는 복잡한 시스템 환경에서는 유용한 플랫폼이다. GitHub Actions과 마찬가지로 특정 브랜치를 지정해둘 수도 있지만, Jenkins는 시간 기준의 트리거도 제공하기 때문에 많은 사람들이 코드를 작성하기 때문에 정해진 시간에 자동으로 업데이트 해줘야 하는 환경에서는 Jenkins가 더 적합할 수 있다. 소규모의 경우 각자 코드 리뷰를 마치고 PR을 통해 release에 merge하는 걸로 트리거를 당길 수 있지만 여러 파트의 작업이 동시다발적으로 이루어지는 경우 매번 누군가가 도맡아 트리거를 당기는 것 보다 시간을 정해두고 정기적으로 알아서 배포되게 한 뒤 그 마감에 맞춰서 각자 알아서 일하게 두는 것이 나을 수도 있다. 이후 버그를 고치는 종류의 특수 이벤트의 경우에만 따로 수동 배포하거나 그에 맞는 트리거를 설정해두면 되니까 말이다.

사담이 길어졌는데, 처음 Jenkins를 배울 때는 일단 플랫폼 전체가 영어라서 싫었던 기억이 있다. 지금은 너무 긴 글만 아니면 영어라도 있는게 어디냐 하긴 하는데 ㅋㅋㅋㅋ 하여튼 그떈 그랬다. 그리고 이건 딴 소리지만, Java 사용자로서 @Scheduled 어노테이션이랑 트리거 기준 시간 표기하는 방식이 똑같아서 @Scheduled 사용할 때마다 Jenkins가 생각난다.