GitHub Actions + Reusable Workflows + Matrix + Composite Action 체계 구축
⸻
🎯 왜 “모듈화된 워크플로우 구조”가 필요한가?
엔터프라이즈급 CI/CD 환경에서는 다음 문제가 반복됩니다:
• 수십 개의 리포지토리마다 거의 동일한 CI 설정을 복붙
• 워크플로우 유지보수가 지옥처럼 확산
• 공통 검증 로직(예: ESLint, 테스트, 보안 스캔)이 중복됨
• 수정 시 수십 개 워크플로우를 동시에 커밋해야 함
이러한 상황에서는 GitHub Actions를 최대한 모듈화하여,
재사용 가능한 CI 구성 요소로 한 곳에서 유지관리 가능한 구조로 전환하는 것이 핵심입니다.
⸻
🧱 핵심 기술 구성요소
기술요소 설명
Reusable Workflow 호출 가능한 .yml 워크플로우. 공통 CI 파이프라인 작성 가능
Composite Action 여러 step을 묶어 커스텀 액션처럼 재사용
Matrix Strategy 여러 환경/프레임워크에서 병렬 테스트 가능
Workflow Call Inputs 파라미터화하여 유연하게 흐름 분기 가능
⸻
📦 공통 워크플로우 구조 예시
📁 공통 워크플로우 저장소 구조
.github/
└── workflows/
└── ci-template.yml
actions/
└── setup-node/
└── action.yml
ci-template.yml (재사용 워크플로우)
on:
workflow_call:
inputs:
node-version:
required: true
type: string
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: ./actions/setup-node
with:
version: ${{ inputs.node-version }}
- run: npm install
- run: npm test
⸻
🔁 사용하는 쪽의 워크플로우
on:
push:
branches: [main]
jobs:
call-ci:
uses: org-name/shared-workflows/.github/workflows/ci-template.yml@v1
with:
node-version: '18'
→ 이렇게 하면 단 하나의 공통 워크플로우를 모든 서비스가 호출합니다.
중앙에서 관리, 자동 업데이트, 변경도 한 번에 반영 가능.
⸻
🧩 Composite Action 예시
# actions/setup-node/action.yml
name: 'Setup Node and Cache'
runs:
using: 'composite'
steps:
- uses: actions/setup-node@v3
with:
node-version: ${{ inputs.version }}
- uses: actions/cache@v3
with:
path: ~/.npm
key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
→ 이 액션을 여러 워크플로우에서 간단히 불러올 수 있음.
⸻
🧪 Matrix 전략 결합
strategy:
matrix:
node: [14, 16, 18]
steps:
- uses: ./actions/setup-node
with:
version: ${{ matrix.node }}
→ 여러 Node 버전에서 병렬 테스트 가능.
⸻
🧠 실전 운영 전략 팁
상황 전략
워크플로우 수정이 자주 발생 workflow_dispatch + reusable workflow로 빠른 테스트
팀별 서비스가 CI 요구가 다름 workflow_call input으로 유연한 조건 처리
서드파티 보안 스캔 도입 필요 composite action에 보안 스캐너 통합
버전 관리 필요 GitHub Release 태그로 워크플로우 버전 관리
⸻
🧩 결론: CI의 품질은 “코드화된 일관성”에서 나온다
GitHub Actions는 단순한 CI 도구가 아니라
“엔지니어링 조직 전체를 통제하는 자동화 플랫폼”이 될 수 있습니다.
공통 워크플로우와 재사용 가능한 컴포넌트 구조를 갖추면:
• 전사적 일관성 유지
• 실수 방지 및 코드 리뷰 간소화
• 복잡한 릴리즈도 안전하게 반복 가능
• CI 변경의 중앙 관리가 가능해짐
CI를 코드화하고, 구조화하고, 공통화하면
개발 조직 전체가 더욱 빠르게 움직이면서도 품질을 잃지 않게 됩니다.
카테고리 없음