LabHub

블로그

프런트엔드 CI/CD·배포 전략 2025 — GitHub Actions·Turborepo·Vercel·Cloudflare·Preview·Canary·Feature Flag·SLSA·SBOM 완전 가이드

2026-04-15 · 20 분 읽기 · #ci-cd#deployment#github-actions#turborepo#nx#vercel#netlify#cloudflare#preview#canary#feature-flag#slsa#sbom#supply-chain

한국어English日本語

프롤로그 — "프라이데이 배포하지 마세요"

10년 전 엔지니어링 문화에서 금요일 배포는 금기였다. 뭔가 터지면 주말 없이 밤샘해야 했기 때문이다. 2025년에는 이 격언이 많이 낡았다. 세상의 많은 팀은 금요일에도 하루 수십 번 배포한다. 무엇이 바뀌었는가?

바뀐 건 세 가지다:

  1. 배포 파이프라인이 자동화됐다 — 사람의 실수 개입 여지가 줄었다
  2. Preview Deployment가 기본이 됐다 — 프로덕션 전에 실제 환경과 동일한 URL로 검증
  3. Progressive Delivery — Canary, Feature Flag로 "일부 사용자에게만" 먼저 배포

2025년의 주요 전환점:

  1. Monorepo Build Cache의 대중화 — Turborepo·Nx·Bazel의 Remote Cache가 무료/저렴하게 제공. 첫 빌드 10분이 두 번째 빌드 10초로
  2. Edge-first 배포 — Vercel·Cloudflare·Netlify의 Edge Function + Static 하이브리드
  3. AI 에이전트의 PR 배포 — Copilot·Cursor·Claude Code가 브랜치 생성→PR→배포까지
  4. 공급망 보안 의무화 — EU CRA, 미국 EO 14028, SLSA Level 3, SBOM 제출 요구 확산

이번 글에서는 13개 챕터로 CI/CD·배포 전략을 정리한다.

1장 · CI/CD 기본 용어 재정리

네 가지 개념

배포 지표 — DORA 4가지

Google의 DevOps Research and Assessment가 만든 표준:

지표EliteHighMediumLow
Deployment Frequency하루 여러 번주 1회+월 1회6개월
Lead Time for Changes1시간 미만1일 미만1주~1개월1~6개월
Change Failure Rate0~15%16~30%16~30%46~60%
Mean Time to Restore1시간 미만1일 미만1일~1주1주~1개월

2023년 DORA 보고서는 Stability(MTTR·Change Failure Rate) + Throughput(Frequency·Lead Time) 균형이 핵심이라고 정리. "빠른 배포"만이 아니라 "안전한 빠른 배포"가 엘리트.

2장 · GitHub Actions — 2025 de facto 표준

왜 Actions가 이겼나

  1. GitHub 내장 — 별도 계정·설정 없음
  2. Marketplace — 20,000+ 공개 Action
  3. 매트릭스 빌드 — Node 18·20·22 × OS 3종 병렬
  4. Reusable Workflow — DRY
  5. Artifact·Cache 내장

기본 CI 워크플로우

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm test
      - run: pnpm build

Concurrency — 동일 브랜치 이전 실행 취소

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

PR에 push를 여러 번 할 때 이전 실행을 자동 취소 → 비용 절감.

OIDC로 클라우드 자격 증명 관리

긴 수명의 AWS_ACCESS_KEY_ID를 GitHub Secrets에 저장하는 시대는 끝났다. OIDC Federation으로 토큰이 매번 새로 발급되고, GitHub Actions → AWS·GCP·Azure로 안전하게 인증.

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/github-actions-role
    aws-region: ap-northeast-2

대안들

2025 스타트업·중소규모: GitHub Actions가 기본. 빌드 시간이 수십 분이거나 비용이 문제되면 self-hosted runner 병행.

3장 · Monorepo — Turborepo·Nx·Bazel

왜 모노레포인가

Turborepo — Vercel 인수, Rust로 재작성 중

npx create-turbo@latest my-monorepo

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": []
    },
    "dev": { "cache": false, "persistent": true }
  }
}

Remote Cache — 협업 캐시

npx turbo login
npx turbo link

내 PC에서 빌드한 결과를 팀원과 CI가 공유. "이미 빌드한 거 또 안 함" → CI 시간 80% 감소 사례 다수.

Nx — 엔터프라이즈 모노레포

npx create-nx-workspace@latest

Turborepo 대비:

Angular 생태계에서 출발했지만 React·Vue·Svelte·Node 지원.

Bazel — Google 스케일

수천 개 패키지·다언어(C++·Go·Java·TS) 섞인 초대형 모노레포에서만 의미. 셋업 비용이 크다. Uber·Airbnb·Spotify 사례.

2025 선택

4장 · 배포 플랫폼 — Vercel·Netlify·Cloudflare Pages·AWS Amplify

Vercel

Netlify

Cloudflare Pages + Workers

AWS Amplify

선택 기준

5장 · Preview Deployment — 리뷰 문화의 혁명

왜 혁명적인가

동작 방식

  1. PR 생성 또는 push
  2. CI가 빌드 → 고유 URL(branch-name--project.vercel.app)에 배포
  3. PR에 자동 코멘트로 URL 게시
  4. 코멘트·툴바로 피드백

Vercel 기본 동작

별 설정 없이 GitHub 연결 → 모든 PR Preview 자동.

Self-host 구현

Preview URL과 환경변수

2024~2025 확장 — Stagewise·Toolbar

6장 · Progressive Delivery — Canary·Blue-Green·Feature Flag

Blue-Green Deployment

Canary Deployment

Feature Flag

Feature Flag 서비스 2025

구현 예

import { getAllFlags } from "@vercel/flags/next";

const flags = await getAllFlags();
if (flags["checkout-v2"]) {
  return <CheckoutV2 />;
}

Canary + Feature Flag 조합

2025년의 권장 패턴: "Deploy ≠ Release". 배포는 상시, 릴리스는 제품 의사결정.

7장 · Rollback 전략 — "언제든 되돌릴 수 있는가?"

자동 Rollback 조건

수동 Rollback

Database Migration의 함정

코드는 쉽게 롤백돼도 DB 스키마 변경은 비가역. 2025 권장 패턴:

  1. Expand — 새 컬럼·테이블 추가 (기존 코드와 호환)
  2. Migrate — 새 코드 배포, 점진적 이동
  3. Contract — 구 컬럼·테이블 제거 (새 코드가 안정화된 후)

이 Expand-Contract 패턴 덕분에 언제든 직전 배포로 안전 롤백.

Feature Flag의 Rollback 역할

8장 · CDN·ISR·Cache Invalidation

Frontend 배포의 Cache 3계층

  1. Browser Cache — 브라우저 내 (Cache-Control)
  2. CDN Cache — Edge 노드 (Vercel·Cloudflare·CloudFront)
  3. Origin Cache — 서버 레벨 (Redis·Memcached)

Next.js ISR (Incremental Static Regeneration)

// App Router
export const revalidate = 3600; // 1시간마다 재생성

// Page Router
export async function getStaticProps() {
  return { props, revalidate: 3600 };
}

On-demand Revalidation

// 관리자가 상품 수정 시
import { revalidateTag, revalidatePath } from "next/cache";

revalidateTag("products");
revalidatePath("/products/[id]", "page");

Cache Invalidation의 어려움

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

실전:

9장 · Edge·Regional·Serverless 배포

Edge — 전 세계 CDN 노드 실행

Regional Function — 특정 Region 서버리스

Static + Edge Revalidation

"Runtime 선언"

export const runtime = "edge"; // 또는 "nodejs"

페이지·API마다 실행 환경 선택. Edge가 빠르지만 npm 라이브러리 호환성 낮음.

10장 · Artifact·Build Cache·Remote Cache

빌드 결과물을 공유한다는 것

CI가 매번 npm install·tsc·webpack을 돌리면 시간·비용 폭발. 이미 같은 input으로 빌드된 결과는 재사용.

GitHub Actions Cache

- uses: actions/cache@v4
  with:
    path: |
      ~/.pnpm-store
      .next/cache
    key: ${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}

Turborepo Remote Cache

TURBO_TOKEN=... TURBO_TEAM=... turbo run build

Nx Cloud

Docker Layer Cache

11장 · Supply Chain 보안 — SLSA·SBOM·Sigstore

왜 의무화됐나

SBOM (Software Bill of Materials)

내가 사용하는 모든 직접·transitive 의존성 목록. 제품의 성분표.

포맷:

생성:

npx @cyclonedx/cyclonedx-npm --output-file sbom.json
# 또는
syft packages npm:. -o spdx-json

SLSA (Supply chain Levels for Software Artifacts)

Google 주도. Level 1~4로 공급망 보안 수준 표준화.

Sigstore·cosign

cosign sign --keyless ghcr.io/me/app:1.0
cosign verify --certificate-identity-regexp ...

npm Provenance

npm publish --provenance

한국 맥락

12장 · AI 에이전트가 릴리스 PR을 만드는 2025

2024년 말~2025년의 변화

자동 릴리스 PR 패턴

  1. 이슈 라벨링 (type:feature, impact:low)
  2. AI가 이슈를 읽고 변경 계획 제안
  3. 사람 승인 → 에이전트가 브랜치·PR 생성
  4. CI 통과 + 사람 리뷰 (Code·Preview URL)
  5. 머지 → 자동 배포 → Canary 단계별 모니터링

리스크

2025의 권장

13장 · 체크리스트·안티패턴·다음 글 예고

CI/CD 체크리스트 (15개)

  1. GitHub Actions(또는 CircleCI) 기본 CI: lint·test·build
  2. Concurrency cancel-in-progress로 중복 실행 취소
  3. OIDC 인증으로 클라우드 자격 증명 관리
  4. Turborepo/Nx Remote Cache로 빌드 시간 단축
  5. Preview Deployment 모든 PR에 자동
  6. Preview DB 분리 (Neon·PlanetScale branch)
  7. Feature Flag 기본 탑재 (LaunchDarkly·PostHog·Vercel)
  8. Canary/Blue-Green로 Progressive Delivery
  9. 자동 Rollback 조건 정의 (에러율·Vitals 회귀)
  10. Expand-Contract DB 마이그레이션 패턴
  11. ISR + 태그 기반 Revalidation
  12. Edge vs Regional 적재 적소 선택
  13. SBOM 생성 CI에 통합
  14. npm/docker provenance 서명
  15. DORA 4 지표 팀 대시보드

CI/CD 안티패턴 TOP 10

  1. 모든 환경 변수를 GitHub Secrets에 평문 저장
  2. Secrets를 PR 로그에 출력 (echo ${{ secrets.X }})
  3. Canary 없이 Big-Bang 배포
  4. Feature Flag를 영구적으로 유지 → dead code 폭발
  5. Preview에서 프로덕션 DB 접근
  6. 빌드 시간 30분+ 방치
  7. DB 마이그레이션과 코드 배포 동시 (롤백 불가)
  8. CI 실패를 "그냥 재실행" (Flaky 방치)
  9. 배포 후 모니터링 미확인
  10. 의존성 업데이트를 분기별로 수동 일괄 (위험 누적)

다음 글 예고 — Season 6 Ep 13 FINALE: "2025년 프런트엔드 엔지니어로 살아가기"

Season 6의 마지막 글. 기술을 넘어 프런트엔드 엔지니어로서의 일하기·성장하기·커뮤니티.

"기술은 도구다. 도구는 사람을 위한 것이다. 프런트엔드는 결국 '사람이 쓸 것'을 만드는 일이다."

다음 글에서 만나자.

"CI/CD는 코드와 사용자 사이의 다리다. 다리가 튼튼하고 자동으로 점검되고 무너져도 수 분 내 수리되는 상태가 되면, 엔지니어는 '배포가 아니라 제품'에 집중할 수 있다. 이게 2025년의 성숙한 팀이다."

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다