GitHub Actions 전환보다 중요했던 배포 단위 재설계

기존 Jenkins는 제가 설계한 영역이 아니었다

기존 Jenkins 구성은 제가 설계하거나 설정한 영역이 아니었습니다. 여러 프로젝트를 Jenkins에서 GitHub Actions로 이전하는 작업과 새로운 workflow 설계부터 담당했습니다.

당시 codi-rs-module 배포는 하나의 Jenkins slave에서 호텔별로 순차 실행됐습니다. 호텔 한 곳의 React 빌드와 배포가 끝나야 다음 호텔을 시작할 수 있는 구조였습니다.

Jenkins slave나 executor를 늘리는 방안은 별도로 검토하지 않았습니다. 기존 Jenkins 설정을 직접 담당하지 않았던 데다, 다른 프로젝트의 마이그레이션을 진행하면서 비용과 운영 측면에서 GitHub Actions가 더 적합하다고 판단한 뒤에는 Jenkins 확장을 대안으로 두지 않았습니다.

전환 배경에는 Jenkins 서버를 별도로 유지하는 비용도 있었습니다. 포트폴리오에서 사용하는 월 $151.84는 과거 실제 청구액이 아니라, 2026-08-20 AWS 서울 리전 Linux On-Demand t3.large 2대와 월 730시간의 공개 가격으로 다시 계산한 컴퓨팅 추정치입니다. 스토리지·네트워크·세금은 포함하지 않습니다. 같은 시점의 사용자 보고에서는 GitHub Actions 무료 티어를 초과하지 않았지만, 앞으로도 비용이 발생하지 않는다는 의미는 아닙니다.

구조가 복잡한 프로젝트를 거의 마지막에 이전했다

GitHub Actions 마이그레이션은 다른 프로젝트부터 먼저 진행했습니다. codi-rs-module은 공통 코드와 다섯 호텔별 코드, 환경변수와 배포 대상이 하나의 저장소에 함께 있어 단순한 프로젝트보다 전환 구조를 결정하기 어려웠습니다.

그래서 다른 프로젝트의 전환을 먼저 진행한 뒤 codi-rs-module을 거의 마지막에 이전했습니다. 이 프로젝트에서는 Jenkins를 GitHub Actions로 바꾸는 것만으로는 기존 순차 대기열을 해결할 수 없었습니다. 어떤 변경이 어느 호텔에 영향을 주는지 먼저 계산하고, 그 결과를 실제 배포 단위로 만들어야 했습니다.

도구가 아니라 배포 단위를 바꿨다

2026년 7월, 변경 파일을 기준으로 배포 대상 플랫폼을 계산하는 구조를 추가했습니다.

• 공통 코드가 변경되면 다섯 호텔 전체를 배포 대상으로 선택합니다.
• 특정 호텔의 코드만 변경되면 해당 호텔만 선택합니다.
• 계산된 호텔 목록을 GitHub Actions matrix에 전달합니다.
• 각 호텔은 독립된 matrix job에서 빌드와 배포를 실행합니다.

Jenkins

코드 변경
   ↓
slave 1개
   ↓
호텔 A → 호텔 B → 호텔 C → 호텔 D → 호텔 E
                  약 15분


GitHub Actions matrix

코드 변경
   ↓
변경 범위 계산
   ├─ 공통 코드 → 호텔 A·B·C·D·E
   └─ 호텔 코드 → 해당 호텔
                      ↓
              대상별 matrix job
        ┌─────┬─────┬─────┬─────┬─────┐
        A     B     C     D     E
        └─────┴─────┴─────┴─────┴─────┘
                  약 3분

작업물의 기존 CI/CD 스윔레인은 변경 감지부터 품질 검사, 시크릿 조회와 배포 결과 확인까지 현재의 전체 실행 흐름을 보여 줍니다. 이 인사이트의 데이터 흐름은 그 내용을 반복하지 않고, Jenkins 순차 대기열에서 대상별 matrix로 배포 단위가 바뀐 부분만 비교합니다.

병렬 실행과 취소 경계를 함께 나눴다

matrix에는 fail-fast: false를 적용했습니다. 특정 호텔 job이 실패하더라도 아직 실행 중인 다른 호텔 job을 GitHub Actions가 즉시 취소하지 않도록 하기 위한 설계였습니다.

다만 이 동작을 확인하기 위해 특정 호텔의 배포를 의도적으로 실패시키지는 않았고, 운영 중 실제 실패 사례로 다른 호텔의 완료 여부를 대조한 기록도 없습니다. 따라서 실패 격리는 설정과 실행 구조의 의도로만 설명하며, 검증된 장애 격리 성과로 확대하지 않습니다.

다섯 호텔 배포 화면에서 약 15분이 약 3분이 됐다

기존 Jenkins에서는 호텔별 배포가 약 3분씩 순차 실행돼 다섯 호텔 전체에 약 15분이 필요했습니다. GitHub Actions matrix에서는 다섯 호텔 job이 병렬로 실행됐고, 전체 배포 화면에서 약 3분이 걸리는 것을 확인했습니다.

이 값은 기존 Jenkins의 순차 실행 화면과 GitHub Actions matrix 실행 화면을 비교한 관찰값입니다. 동일한 조건에서 여러 번 실행해 계산한 평균이나 통제된 성능 실험은 아닙니다. 따라서 80% 개선 같은 비율로 일반화하지 않습니다.

병렬화 전에 배포 단위를 분리할 수 있어야 한다

이 방식은 여러 배포 대상이 서로 독립적이고, 코드 변경이 어느 대상에 영향을 주는지 계산할 수 있을 때 적합합니다.

반대로 공통 데이터 마이그레이션이나 선행 서비스 배포처럼 대상 사이에 순서가 필요하거나, 변경 코드가 어느 대상에 영향을 주는지 정확히 구분할 수 없다면 같은 방식으로 병렬화해서는 안 됩니다.

이번 전환에서 얻은 결론은 Jenkins와 GitHub Actions 중 어느 도구가 항상 더 낫다는 것이 아닙니다. CI 도구를 교체하는 것만으로는 기존 배포 병목이 사라지지 않았고, 공통 코드와 호텔별 코드의 영향 범위를 나눈 뒤 실제 배포 단위를 다시 설계해야 병렬화의 효과를 얻을 수 있었습니다.