GitHub Actions CI/CD 아키텍처 구축 여정

시작

올해 6월, 사내에서 Jenkins 기반으로 만든 CI/CD가 EOS되고, Github Action으로 도입하는 계획을 갖게 됐다.

어떻게 하면 유지보수를 하는데 어려움없이 효율적으로 개발할지 구상을 많이 했었다. Java, Node, Python...
각각 다른 빌드 방식과 배포 전략이 필요했지만, 매번 처음부터 다시 만드는 건 비효율의 극치였다.

그래서 재사용 가능한 GitHub Actions 아키텍처를 구축했다.

🎯 핵심 아키텍처: 조직 간 협업

1. 조직 간 워크플로우 공유 전략 ⭐

가장 큰 도전 과제는 GitHub Enterprise의 여러 조직에 흩어진 프로젝트들을 하나의 CI/CD로 통합하는 것이었다.

조직간 배포 호출 구조

해결 방법: 중앙 집중식 CI/CD

• 공통 조직에 모든 재사용 워크플로우와 액션을 집중화했다
• 다른 조직의 프로젝트들은 간단한 호출만으로 사용 가능하게 만들었다
• 각 프로젝트는 최소한의 설정으로 완전한 CI/CD 파이프라인을 갖추게 되었다

# 각 프로젝트의 배포 설정 (간소화 버전)
name: Deploy

on:
  push:
    branches: [develop, main]

jobs:
  deploy:
    uses: common-org/workflows/deploy@main
    with:
      environment: ${{ github.ref == 'refs/heads/main' && 'production' || 'development' }}
      # ... 필요한 파라미터
    secrets: inherit

2. 기술 스택별 유연한 배포 전략 ⭐

두 번째 핵심은 하나의 아키텍처로 다양한 기술 스택과 배포 방식을 모두 지원하는 것이었다.

배포 유형 선택

20개가 넘는 워크플로우를 만들었고, 각각은 특정 조합에 최적화되어 있다:

• Java 프로젝트: Maven/Gradle 빌드, 다양한 JDK 버전 지원
• 프론트엔드: Node.js 버전 관리, 빌드 최적화, 웹서버 설정
• Docker: 멀티 플랫폼 빌드, 레지스트리 푸시, 이미지 스캔
• 서버리스: 런타임 선택, Layer 관리, 콜드 스타트 최적화

3. 멀티 환경 지원 및 현재 한계 ⭐

세 번째 특징은 여러 운영 환경을 지원하면서도 현실적인 제약을 인정한 점이다.

현재 구현한 것:

• ✅ 환경별 독립적인 배포
• ✅ 브랜치 기반 자동 배포
• ✅ 운영 환경 승인 시스템
• ✅ 환경별 설정 자동 적용

아직 못한 것:

• ❌ 다중 환경 동시 배포
• ❌ 카나리 배포
• ❌ A/B 테스팅

완벽한 시스템은 아니다. 하지만 현실적으로 필요한 기능부터 구현하고, 점진적으로 개선해나가고 있다.

🏗️ 전체 아키텍처 구조

전체 시스템은 3개의 레이어로 구성되어 있다.

Github Actions 계층구조

워크플로우 실행 과정 예시

Java 프로젝트가 배포되는 전체 과정:

🔧 핵심 컴포넌트 상세

1. Reusable Workflows (재사용 워크플로우)

21개의 재사용 워크플로우를 만들었고, 각각 특정 배포 시나리오에 최적화했다.

카테고리별 분류:

• 웹 애플리케이션 (13개): Java, Vue, React, Angular, Python 등
• 서버리스 (3개): Lambda JavaScript, Python, Multi-arch
• 정적 웹사이트 (2개): S3 + CloudFront
• 패키지 배포 (2개): NPM, Java Library
• 보안 스캔 (1개): 전체 프로젝트 보안 검사

2. Composite Actions (컴포지트 액션)

24개의 Composite Action을 만들어서 재사용 가능한 작업 단위로 분리했다.

예시: 환경 설정과 배포 계획 액션

name: 'Setup and Plan'
description: '배포 환경 설정 및 계획 생성'

runs:
  using: "composite"
  steps:
    - name: Configure credentials
      # 클라우드 인증 설정

    - name: Load config
      shell: bash
      run: |
        # 환경별 설정 로드
        CONFIG=$(cat config.json)

    - name: Generate plan
      shell: bash
      run: |
        # 변경사항 분석
        # 배포 대상 결정
        # 소요 시간 계산

3. 보안 계층

모든 배포에 자동으로 보안 스캔을 포함시켰다:

💡 설계 철학과 교훈

1. 중앙 집중 vs 자율성의 균형

• 중앙 집중: 공통 로직은 common 조직에서 관리
• 자율성 보장: 각 프로젝트는 필요한 파라미터만 설정
• 버전 관리: @main 태그로 항상 최신 버전 사용

2. 점진적 개선 철학

1. Phase 1: 기본 CI/CD 구축
2. Phase 2: 다양한 기술 스택 지원 추가
3. Phase 3: 승인 시스템, 알림 추가
4. Phase 4: 보안 스캔 통합
5. Phase 5: 성능 최적화 진행 중

3. 실패에서 배운 것들

• Over-engineering 경계: 너무 많은 옵션은 오히려 복잡도만 증가
• 호환성 우선: 기존 프로젝트 마이그레이션을 고려한 설계
• 모니터링 중요성: 배포 과정의 가시성 확보가 핵심

🚀 도입 효과

개발팀 관점

• 배포에 대한 부담 없음
• CI/CD 설정 시간 단축
• 표준화된 프로세스로 팀 간 협업 개선

운영팀 관점

• 수동 작업 90% 감소
• 장애 대응 시간 75% 단축
• 예측 가능한 배포 프로세스

조직 전체 관점

• 배포 빈도 300% 증가
• 월 200시간 이상의 인력 절감
• 표준화를 통한 기술 부채 감소

마무리

GitHub Enterprise의 조직 간 협업, 다양한 기술 스택 지원, 멀티 환경 배포라는 핵심 요구사항을 충족시키며,
실제로 큰 효과를 보고 있다.