2026 CI/CD 완전 가이드

GitHub Actions·ECS Fargate 배포, GitOps

이 장을 읽기 전에: Git의 기본과 7장~9장의 기반 이해가 있으면 연결되기 쉽다.

CI/CD는 "자동화를 위한 자동화"가 아니다. 목적은, 변경을 빠르게 내보내는 것과 망가졌을 때 바로 멈추고 돌릴 수 있는 것을 동시에 충족시키는 것이다.

이 장에서는 CI/CD 플랫폼 선정, 배포 전략, Feature Flags, 아티팩트 관리, GitOps, AI 활용의 경계를 정리한다.

� 한국 시장 맥락: 국내 IT 기업(카카오·네이버·토스·라인·쿠팡)은 GitHub Actions를 CI/CD 표준으로 채택하는 경우가 많다. 공공·금융·SI 환경은 GitLab CI(자체 호스팅) 또는 Jenkins를 사용하는 경우가 여전히 많다.

1. CI/CD의 기본 개념과 중요성

이 섹션이 답하는 질문: CI/CD는 무엇을 자동화하고, 무엇을 인간이 판단해야 하는가?

CI와 CD

수동 배포의 문제

재현성이 없다

절차 누락이 발생한다

누가 무엇을 했는지 추적하기 어렵다 (ISMS-P 감사에서 문제가 됨)

야간이나 장애 시 대응이 특정인에 집중된다

DORA 지표로 CI/CD 성숙도 측정

DevOps Research and Assessment(DORA) 지표는 CI/CD 성숙도를 객관적으로 측정하는 기준이다.

정리

CI/CD는 "인간을 불필요하게 만드는 구조"가 아니라, 인간이 봐야 할 판단 점만을 남기는 구조다.

2. CI/CD 플랫폼

이 섹션이 답하는 질문: 어떤 CI/CD 도구를 선택해야 하는가?

주요 선택지

� 국내 환경 특이사항:
- GitHub Actions: 토스·당근마켓·카카오 등 국내 주요 IT 기업에서 표준으로 채택. GitHub Enterprise Server로 망분리 환경에서도 사용 가능
- GitLab CI(자체 호스팅): 공공기관·금융권·대기업 SI에서 보안 정책상 GitHub 외부 접근이 제한될 때 선택. NCP나 사내 서버에 GitLab 자체 호스팅
- Jenkins: 레거시 시스템이 많은 금융·제조·공공 환경에서 여전히 광범위하게 사용. 유지보수 부담이 높지만 교체 비용이 더 큰 경우 유지

무엇으로 선택하는가

GitHub Actions — 최소한의 CI 워크플로 예시

---

name: CI 파이프라인

on:

pull_request:

push:

branches: [main]

# 동시 실행 제한 — 같은 브랜치의 이전 실행 취소

concurrency:

group: ${{ github.workflow }}-${{ github.ref }}

cancel-in-progress: true

jobs:

quality:

name: 코드 품질 검사

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Node.js 설정

uses: actions/setup-node@v4

with:

node-version: 22

cache: npm

- name: 의존 관계 설치

run: npm ci

- name: 린트

run: npm run lint

- name: 타입 체크

run: npm run typecheck

- name: 유닛 테스트 (커버리지)

run: npm run test:coverage

- name: 커버리지 업로드

uses: codecov/codecov-action@v4

with:

token: ${{ secrets.CODECOV_TOKEN }}

security:

name: 보안 스캔

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: 의존성 취약점 스캔

uses: snyk/actions/node@master

env:

SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

with:

args: --severity-threshold=high

---

GitHub Actions OIDC — 클라우드 자격 증명

---

# AWS OIDC 인증 — 장수명 시크릿 없이 AWS 접근

jobs:

deploy:

runs-on: ubuntu-latest

permissions:

id-token: write # OIDC 토큰 발급 권한

contents: read

steps:

- uses: actions/checkout@v4

- name: AWS 인증 (OIDC)

uses: aws-actions/configure-aws-credentials@v4

with:

role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy

aws-region: ap-northeast-2 # 서울 리전

---

보안상의 기본

장수명 클라우드 자격 정보를 가능한 한 두지 않는다 → OIDC 우선

OIDC나 단명 토큰을 우선한다

제3자 Action은 신뢰할 수 있는 것을 선택하고, 가능하다면 commit SHA로 고정한다

본번 배포 권한과 통상 CI 권한을 나눈다

⚠️ CI/CD는 개발 보조가 아니라, 본번계로의 입구이기도 하다. 따라서 파이프라인 자체를 앱 본체와 같은 수준 이상으로 지켜야 한다.

정리

막히면 GitHub을 사용한다면 GitHub Actions, GitLab을 사용한다면 GitLab CI에서 시작하는 것이 자연스럽다. 갈아타는 이유는 통제, 기존 자산, 자기 운용 요건이 생기고 나서로 충분하다.

3. 배포 전략

이 섹션이 답하는 질문: 본번을 망가뜨리지 않고 릴리스하려면?

주요 전략

어떻게 선택하는가

배포 전략 선택 플로

실무에서 중요한 것

배포 전략 자체보다 중요한 것은 다음 3가지다.

헬스체크 — /health 엔드포인트 정의, 로드 밸런서 연동

롤백 절차 — 트리거 조건, 담당자, 소요 시간을 문서화

배포 직후의 감시 — 에러율, 레이턴시, 주요 업무 지표 모니터링

⚠️ Canary나 Blue-Green은, 감시가 없으면 단순히 복잡할 뿐이 된다. 에러율, 레이턴시, 주요 업무 지표를 보고 멈추는 구조가 전제다.

AWS 배포 실무 예시

---

# GitHub Actions — ECS Fargate 롤링 배포 (서울 리전)

deploy-production:

name: 프로덕션 배포

needs: [quality, security]

if: github.ref == 'refs/heads/main'