Feedback Loops 컴파일러와 CI/CD 완벽 가이드

컴파일러 피드백 루프부터 CI/CD 파이프라인, 테스트 자동화, 자가 치유 빌드까지 현대 개발 워크플로우의 핵심을 다룹니다. 초급 개발자도 쉽게 이해할 수 있도록 실무 예제와 함께 설명합니다.

---

목차

1. 컴파일러_피드백_루프_설계
2. CI/CD_파이프라인_통합
3. 테스트_자동화_패턴
4. 빌드_실패_시_자가_치유
5. 린터_및_포맷터_피드백
6. 배포_자동화_전략

---

1. 컴파일러 피드백 루프 설계

김개발 씨가 새벽까지 작성한 코드를 커밋하려던 순간, 터미널에 빨간 에러 메시지가 줄줄이 쏟아졌습니다. "분명히 문법 오류는 없는데..." 하며 머리를 긁적이던 김개발 씨에게 박시니어 씨가 다가왔습니다.

"컴파일러가 주는 피드백을 제대로 활용하고 있나요?"

컴파일러 피드백 루프란 코드를 작성하는 순간부터 실행 전까지 발생하는 모든 오류를 즉시 감지하고 알려주는 시스템입니다. 마치 글을 쓸 때 맞춤법 검사기가 실시간으로 빨간 줄을 그어주는 것과 같습니다.

이 피드백 루프가 빠르고 정확할수록 개발 생산성이 비약적으로 향상됩니다.

다음 코드를 살펴봅시다.

// tsconfig.json - 엄격한 타입 체크 설정
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    // 증분 빌드로 피드백 속도 향상
    "incremental": true,
    "tsBuildInfoFile": ".tsbuildinfo"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

김개발 씨는 입사 3개월 차 주니어 개발자입니다. 오늘도 새로운 기능을 구현하느라 밤늦게까지 코드를 작성했습니다.

자신만만하게 git push를 했는데, CI 파이프라인에서 빌드가 실패했다는 알림이 날아왔습니다. "어라, 로컬에서는 잘 돌아갔는데?" 김개발 씨는 당황했습니다.

알고 보니 TypeScript의 strict 모드가 CI 환경에서만 활성화되어 있었던 것입니다. 그렇다면 컴파일러 피드백 루프란 정확히 무엇일까요?

쉽게 비유하자면, 컴파일러는 마치 까다로운 편집자와 같습니다. 글을 쓸 때 편집자가 바로 옆에서 "여기 문장이 어색해요", "이 단어는 맞춤법이 틀렸어요"라고 실시간으로 알려준다면 어떨까요?

최종 원고를 제출하기 전에 모든 오류를 잡을 수 있을 것입니다. 컴파일러도 마찬가지입니다.

컴파일러 피드백이 없던 시절에는 어땠을까요? 개발자들은 코드를 실행해보기 전까지는 오류를 발견할 수 없었습니다.

프로그램이 한참 돌아가다가 갑자기 죽어버리면, 그제야 어디가 문제인지 추적을 시작해야 했습니다. 더 큰 문제는 이런 버그가 운영 환경에 배포된 후에 발견되는 경우였습니다.

바로 이런 문제를 해결하기 위해 정적 타입 검사가 등장했습니다. TypeScript의 strict 모드를 활성화하면 암묵적인 any 타입을 허용하지 않습니다.

또한 null과 undefined에 대한 엄격한 검사를 수행합니다. 이렇게 하면 런타임에 발생할 수 있는 많은 오류를 컴파일 시점에 잡아낼 수 있습니다.

위의 설정 파일을 살펴보겠습니다. strict: true는 모든 엄격한 검사를 한 번에 활성화합니다.

noImplicitAny는 타입을 명시하지 않으면 에러를 발생시킵니다. noUnusedLocals와 noUnusedParameters는 사용하지 않는 변수나 매개변수를 잡아냅니다.

특히 주목할 부분은 incremental 옵션입니다. 이 옵션을 켜면 이전 빌드 정보를 저장해두고, 변경된 파일만 다시 컴파일합니다.

마치 수학 시험에서 틀린 문제만 다시 푸는 것과 같습니다. 프로젝트가 커질수록 이 옵션의 효과는 극대화됩니다.

실제 현업에서는 어떻게 활용할까요? 대규모 프로젝트에서는 빌드 시간이 수 분에서 수십 분까지 걸리기도 합니다.

이때 증분 빌드를 활용하면 피드백 시간을 초 단위로 줄일 수 있습니다. 개발자가 코드를 저장하는 순간 거의 즉시 오류를 확인할 수 있습니다.

하지만 주의할 점도 있습니다. 처음부터 너무 엄격한 설정을 적용하면 기존 코드베이스에 수백, 수천 개의 에러가 쏟아질 수 있습니다.

따라서 점진적으로 엄격함을 높여가는 전략이 필요합니다. 예를 들어 새로 작성하는 파일에만 먼저 strict 모드를 적용하는 방식입니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 듣고 로컬 환경에서도 strict 모드를 활성화했습니다.

처음에는 수정할 부분이 많아 당황했지만, 이제는 "컴파일러가 잡아주니까 안심이 되네요"라며 웃을 수 있게 되었습니다.

실전 팁

💡 - 새 프로젝트는 처음부터 strict: true로 시작하세요

• 기존 프로젝트는 skipLibCheck: true와 함께 점진적으로 엄격함을 높이세요
• IDE의 실시간 타입 체크 기능을 적극 활용하세요

---

2. CI/CD 파이프라인 통합

"제 컴퓨터에서는 되는데요?" 김개발 씨의 이 말에 팀원들이 일제히 한숨을 쉬었습니다. 분명히 로컬에서는 잘 돌아가던 코드가 서버에만 올리면 오류가 납니다.

박시니어 씨가 화이트보드 앞으로 걸어갔습니다. "오늘 CI/CD 파이프라인에 대해 이야기해볼까요?"

CI/CD 파이프라인은 코드가 저장소에 푸시되는 순간부터 운영 환경에 배포되기까지의 모든 과정을 자동화한 시스템입니다. 마치 공장의 컨베이어 벨트처럼, 코드가 여러 검증 단계를 거쳐 최종 제품이 됩니다.

CI는 지속적 통합, CD는 지속적 배포를 의미합니다.

다음 코드를 살펴봅시다.

# .github/workflows/ci.yml
name: CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Node.js 환경 설정
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      # 의존성 설치 및 검증 단계
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm run test -- --coverage
      - run: npm run build

김개발 씨는 새로운 기능 개발을 마치고 자신감에 차서 Pull Request를 올렸습니다. 그런데 몇 분 후, GitHub에서 빨간 X 표시가 떴습니다.

CI 파이프라인이 실패한 것입니다. "이게 뭐죠?" 김개발 씨가 물었습니다.

박시니어 씨가 설명을 시작했습니다. "CI/CD 파이프라인은 마치 자동차 검사소와 같아요.

새 차가 출고되기 전에 여러 검사를 통과해야 하잖아요. 코드도 마찬가지입니다." 그렇다면 CI/CD는 왜 필요한 걸까요?

과거에는 개발자마다 개발 환경이 달랐습니다. 운영체제도 다르고, 설치된 라이브러리 버전도 다르고, 설정도 제각각이었습니다.

그래서 "내 컴퓨터에서는 되는데"라는 말이 팀의 일상이 되었습니다. 이런 문제를 환경 불일치라고 부릅니다.

CI/CD 파이프라인은 이 문제를 해결합니다. 모든 코드는 동일한 환경에서 빌드되고 테스트됩니다.

GitHub Actions의 runs-on: ubuntu-latest가 바로 그 역할을 합니다. 어떤 개발자가 어떤 운영체제를 쓰든, CI 환경은 항상 동일합니다.

위의 워크플로우 파일을 단계별로 살펴보겠습니다. on 섹션은 언제 파이프라인이 실행될지를 정의합니다.

main이나 develop 브랜치에 푸시하거나, main으로 PR을 올리면 자동으로 실행됩니다. actions/checkout은 코드를 가져오고, actions/setup-node는 Node.js 환경을 설정합니다.

핵심은 그 다음에 이어지는 검증 단계들입니다. npm ci는 package-lock.json을 기반으로 정확한 버전의 의존성을 설치합니다.

npm install과 달리 lock 파일과 일치하지 않으면 에러를 발생시킵니다. 이렇게 하면 "어제는 됐는데 오늘은 안 돼요"라는 상황을 방지할 수 있습니다.

그 다음으로 lint, type-check, test, build가 순차적으로 실행됩니다. 이 순서가 중요합니다.

빠르게 실패하는 것들을 앞에 배치해야 합니다. 문법 오류는 몇 초 만에 발견할 수 있지만, 전체 테스트는 몇 분이 걸릴 수 있습니다.

린트에서 실패하면 굳이 테스트까지 갈 필요가 없습니다. 실제 현업에서는 이보다 훨씬 복잡한 파이프라인을 구축합니다.

보안 취약점 검사, 의존성 업데이트 확인, 성능 테스트, 스테이징 환경 배포, 승인 프로세스 등이 추가됩니다. 하지만 핵심 원리는 동일합니다.

코드가 커밋될 때마다 자동으로 검증하고, 문제가 있으면 즉시 알려주는 것입니다. 주의할 점도 있습니다.

파이프라인이 너무 느리면 개발자들이 피드백을 기다리다 지쳐버립니다. 10분 이상 걸리는 파이프라인은 개발 흐름을 끊어놓습니다.

따라서 캐싱, 병렬 실행, 증분 빌드 등을 적극 활용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

CI 실패 로그를 확인해보니, 테스트 중 하나가 실패한 것이었습니다. 로컬에서 테스트를 돌려보지 않고 푸시한 것이 문제였습니다.

이제 김개발 씨는 커밋 전에 항상 테스트를 돌려보는 습관이 생겼습니다.

실전 팁

💡 - 파이프라인은 5분 이내에 완료되도록 최적화하세요

• 캐시를 적극 활용하여 의존성 설치 시간을 줄이세요
• 실패 시 명확한 에러 메시지가 나오도록 구성하세요

---

3. 테스트 자동화 패턴

"테스트 코드요? 시간 없어서 못 썼어요." 김개발 씨의 말에 박시니어 씨가 고개를 저었습니다.

"테스트 없이 배포하는 건 눈 감고 운전하는 것과 같아요. 지금 당장은 괜찮아 보여도, 언젠가 반드시 사고가 납니다."

테스트 자동화란 사람이 수동으로 검증하던 작업을 코드로 작성하여 자동으로 실행하는 것입니다. 마치 품질 검사관을 24시간 고용해둔 것과 같습니다.

단위 테스트, 통합 테스트, E2E 테스트 등 여러 층위의 테스트가 피라미드 구조를 이룹니다.

다음 코드를 살펴봅시다.

// src/utils/calculator.test.ts
import { describe, it, expect, beforeEach } from 'vitest';
import { Calculator } from './calculator';

describe('Calculator', () => {
  let calc: Calculator;

  // 각 테스트 전에 새 인스턴스 생성
  beforeEach(() => {
    calc = new Calculator();
  });

  it('두 숫자를 더할 수 있어야 한다', () => {
    expect(calc.add(2, 3)).toBe(5);
    expect(calc.add(-1, 1)).toBe(0);
  });

  it('0으로 나누면 에러를 던져야 한다', () => {
    expect(() => calc.divide(10, 0)).toThrow('Division by zero');
  });
});

어느 금요일 오후, 김개발 씨는 간단한 버그 수정을 배포했습니다. 그런데 주말 동안 고객센터에 문의가 폭주했습니다.

작은 수정이 다른 기능을 망가뜨린 것입니다. 이런 현상을 회귀 버그라고 부릅니다.

월요일 아침, 박시니어 씨가 말했습니다. "테스트가 있었다면 이 버그는 배포 전에 잡혔을 거예요." 테스트 자동화는 마치 안전망과 같습니다.

서커스 곡예사가 높은 곳에서 묘기를 부릴 때, 아래에 안전망이 있으면 과감한 시도를 할 수 있습니다. 테스트도 마찬가지입니다.

코드를 과감하게 수정하거나 리팩토링할 때, 테스트가 있으면 실수를 바로 잡아낼 수 있습니다. 테스트에는 여러 종류가 있습니다.

가장 작은 단위인 단위 테스트는 함수 하나, 클래스 하나를 검증합니다. 위의 예제 코드가 바로 단위 테스트입니다.

실행 속도가 빠르고, 문제가 생겼을 때 원인을 찾기 쉽습니다. 전체 테스트의 70~80%는 단위 테스트로 구성하는 것이 좋습니다.

통합 테스트는 여러 컴포넌트가 함께 동작하는지 검증합니다. 예를 들어 API 엔드포인트가 데이터베이스와 제대로 연동되는지 확인합니다.

단위 테스트보다는 느리지만, 실제 운영 환경에 더 가까운 검증이 가능합니다. 전체의 15~20% 정도를 차지합니다.

E2E 테스트는 사용자 시나리오 전체를 검증합니다. 실제 브라우저를 띄우고, 버튼을 클릭하고, 폼을 입력하는 과정을 자동화합니다.

가장 확실한 검증이지만, 실행 시간이 오래 걸리고 유지보수도 어렵습니다. 핵심 시나리오에 대해서만 5~10% 정도 작성합니다.

위의 코드를 살펴보겠습니다. describe는 테스트 그룹을 만듭니다.

beforeEach는 각 테스트 전에 실행되어 깨끗한 상태를 보장합니다. it은 하나의 테스트 케이스입니다.

expect와 toBe로 기대값과 실제값을 비교합니다. 특히 마지막 테스트가 중요합니다.

"0으로 나누면 에러를 던져야 한다"는 경계 조건 테스트입니다. 정상적인 입력뿐 아니라, 예외적인 상황도 테스트해야 합니다.

오히려 이런 엣지 케이스에서 버그가 많이 발생합니다. 테스트 작성 시 흔히 하는 실수가 있습니다.

구현 세부사항을 테스트하는 것입니다. 예를 들어 "이 함수가 내부적으로 특정 메서드를 호출하는가"를 테스트하면, 리팩토링할 때마다 테스트가 깨집니다.

대신 "입력이 주어졌을 때 올바른 출력이 나오는가"를 테스트해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

그 이후로 김개발 씨는 새 기능을 만들 때 테스트부터 작성합니다. 처음에는 번거로웠지만, 이제는 테스트 없이는 불안해서 코드를 푸시하지 못합니다.

"테스트가 저를 지켜준다는 느낌이에요."

실전 팁

💡 - 테스트는 구현 전에 작성하세요 (TDD)

• 하나의 테스트는 하나의 동작만 검증하세요
• 테스트 이름은 "~하면 ~해야 한다" 형식으로 작성하세요

---

4. 빌드 실패 시 자가 치유

새벽 3시, 김개발 씨의 폰에 알림이 울렸습니다. "빌드 실패: npm package conflict".

졸린 눈을 비비며 노트북을 열었지만, 어디서부터 손을 대야 할지 막막했습니다. 다음 날 박시니어 씨가 물었습니다.

"자가 치유 빌드 시스템은 들어봤나요?"

자가 치유 빌드란 빌드 실패 시 자동으로 문제를 분석하고, 가능한 경우 스스로 복구하거나, 최소한 명확한 해결책을 제시하는 시스템입니다. 마치 자동차의 자가 진단 시스템처럼, 문제가 발생하면 원인을 파악하고 대처 방안을 알려줍니다.

다음 코드를 살펴봅시다.

# .github/workflows/self-healing-build.yml
name: Self-Healing Build
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      # 캐시 복구 실패 시 자동으로 클린 설치
      - name: Install with fallback
        run: |
          npm ci || (rm -rf node_modules package-lock.json && npm install)

      # 빌드 실패 시 재시도 (flaky 빌드 대응)
      - name: Build with retry
        uses: nick-fields/retry@v2
        with:
          timeout_minutes: 10
          max_attempts: 3
          command: npm run build

빌드 실패는 개발자의 일상입니다. 하지만 모든 실패가 코드 문제인 것은 아닙니다.

김개발 씨가 경험한 것처럼, 의존성 충돌이나 네트워크 오류 같은 일시적인 문제도 많습니다. 이런 문제로 새벽에 호출당하는 것은 정말 피곤한 일입니다.

자가 치유 빌드는 마치 자동 복구 기능이 있는 전자제품과 같습니다. TV가 잠깐 멈췄을 때, 사용자가 직접 플러그를 뽑았다 꽂을 필요 없이 알아서 재부팅되는 것처럼요.

빌드 시스템도 마찬가지입니다. 간단한 문제는 스스로 해결하고, 정말 사람의 개입이 필요한 문제만 알려주면 됩니다.

위의 워크플로우를 살펴보겠습니다. Install with fallback 단계가 핵심입니다.

npm ci가 실패하면 node_modules와 lock 파일을 삭제하고 처음부터 다시 설치합니다. 캐시가 오염되었거나 lock 파일이 깨진 경우에 효과적입니다.

retry 액션도 중요합니다. 네트워크 타임아웃이나 외부 서비스 장애로 빌드가 실패하는 경우가 있습니다.

이런 flaky 빌드는 다시 실행하면 성공하는 경우가 많습니다. 최대 3번까지 재시도하면 대부분의 일시적 오류를 극복할 수 있습니다.

더 고급스러운 자가 치유 전략도 있습니다. 예를 들어 TypeScript 타입 오류가 발생하면, AI가 자동으로 수정 PR을 만들어주는 시스템도 있습니다.

또는 의존성 버전 충돌이 감지되면, 호환되는 버전으로 자동 다운그레이드하는 것도 가능합니다. 하지만 자가 치유에도 한계가 있습니다.

논리 오류나 설계 문제는 자동으로 고칠 수 없습니다. 자가 치유는 인프라 수준의 문제에 집중해야 합니다.

코드 품질 문제까지 자동으로 고치려 하면, 오히려 더 큰 문제를 만들 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

대기업에서는 빌드 실패 패턴을 분석하여 자동 대응 규칙을 만들어둡니다. "이런 에러가 나면 이렇게 대응한다"는 플레이북을 시스템에 입력해두는 것입니다.

시간이 지날수록 시스템이 더 똑똑해집니다. 주의할 점이 있습니다.

모든 실패를 숨기면 안 됩니다. 재시도해서 성공했더라도, 그 사실을 기록해두어야 합니다.

같은 문제가 반복되면 근본 원인을 해결해야 합니다. 자가 치유는 응급 처치일 뿐, 근본적인 치료는 아닙니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 자가 치유 빌드를 도입한 후, 새벽 알림이 크게 줄었습니다.

정말 중요한 문제가 발생했을 때만 알림이 오니, 그때는 진짜로 집중해서 해결할 수 있게 되었습니다.

실전 팁

💡 - 재시도 횟수는 3회 정도가 적당합니다

• 모든 자가 치유 시도를 로깅하세요
• 같은 문제가 반복되면 근본 원인을 해결하세요

---

5. 린터 및 포맷터 피드백

"여기 들여쓰기가 탭이네요. 저희는 스페이스 2칸을 쓰는데..." 코드 리뷰에서 박시니어 씨가 지적했습니다.

김개발 씨는 얼굴이 붉어졌습니다. 기능에는 문제가 없는데, 이런 사소한 것으로 리뷰가 반려되다니.

"이런 건 자동으로 잡아줄 수 없나요?"

린터는 코드의 문법 오류나 잠재적 버그를 찾아주고, 포맷터는 코드 스타일을 자동으로 통일해줍니다. 린터가 맞춤법 검사기라면, 포맷터는 문서 서식을 자동으로 맞춰주는 도구입니다.

이 둘을 함께 사용하면 코드 리뷰에서 스타일 논쟁을 없앨 수 있습니다.

다음 코드를 살펴봅시다.

// eslint.config.js (ESLint 9+ Flat Config)
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
import prettier from 'eslint-config-prettier';

export default tseslint.config(
  eslint.configs.recommended,
  ...tseslint.configs.strict,
  prettier, // Prettier와 충돌하는 규칙 비활성화
  {
    rules: {
      // 사용하지 않는 변수는 에러
      '@typescript-eslint/no-unused-vars': 'error',
      // console.log는 경고 (개발 중에는 허용)
      'no-console': 'warn',
      // 명시적 any는 에러
      '@typescript-eslint/no-explicit-any': 'error',
    }
  }
);

코드 리뷰에서 가장 소모적인 논쟁은 무엇일까요? "중괄호 같은 줄에 쓸까요, 다음 줄에 쓸까요?" "세미콜론 붙일까요, 말까요?" 이런 스타일 논쟁은 끝이 없습니다.

모든 개발자가 각자의 취향이 있기 때문입니다. 린터와 포맷터는 이런 논쟁을 끝내줍니다.

마치 회사에 드레스 코드가 있는 것과 같습니다. 개인 취향과 상관없이, 모두가 같은 규칙을 따릅니다.

처음에는 불편할 수 있지만, 일단 정해지면 더 이상 고민할 필요가 없습니다. ESLint는 JavaScript와 TypeScript의 대표적인 린터입니다.

코드를 정적으로 분석하여 잠재적인 버그나 안티 패턴을 찾아냅니다. 예를 들어 사용하지 않는 변수, 도달할 수 없는 코드, 잘못된 타입 사용 등을 잡아냅니다.

Prettier는 코드 포맷터입니다. 들여쓰기, 줄바꿈, 따옴표 스타일 등을 자동으로 통일합니다.

개발자가 할 일은 코드를 저장하는 것뿐입니다. 나머지는 Prettier가 알아서 정리합니다.

위의 설정 파일을 살펴보겠습니다. eslint.configs.recommended는 ESLint 팀이 추천하는 기본 규칙입니다.

tseslint.configs.strict는 TypeScript에 대한 엄격한 규칙을 추가합니다. prettier는 ESLint와 Prettier가 충돌하는 규칙을 비활성화합니다.

rules 섹션에서 팀만의 규칙을 정의할 수 있습니다. no-unused-vars를 error로 설정하면, 사용하지 않는 변수가 있으면 빌드가 실패합니다.

no-console을 warn으로 설정하면, console.log가 있어도 빌드는 성공하지만 경고가 표시됩니다. 실제 현업에서는 이 도구들을 어떻게 통합할까요?

pre-commit hook을 설정하면 커밋 전에 자동으로 린트와 포맷팅이 실행됩니다. husky와 lint-staged를 조합하면, 변경된 파일에 대해서만 검사를 실행하여 속도를 높일 수 있습니다.

주의할 점도 있습니다. 너무 엄격한 규칙은 오히려 생산성을 떨어뜨립니다.

모든 경고를 에러로 바꾸면, 개발하는 동안 계속 빨간 줄에 시달리게 됩니다. 처음에는 느슨하게 시작해서 점진적으로 엄격하게 만드는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 팀에서 ESLint와 Prettier를 도입한 후, 코드 리뷰가 훨씬 빨라졌습니다.

더 이상 스타일에 대한 지적이 없으니, 리뷰어도 리뷰이도 로직에만 집중할 수 있게 되었습니다.

실전 팁

💡 - IDE에 ESLint와 Prettier 확장을 설치하여 실시간 피드백을 받으세요

• 저장 시 자동 포맷팅을 활성화하세요
• 팀 규칙은 한번 정하면 자주 바꾸지 마세요

---

6. 배포 자동화 전략

"이번 배포는 제가 직접 할게요." 김개발 씨가 자신있게 말했습니다. 그런데 몇 시간 후, 서비스가 다운되었습니다.

수동 배포 과정에서 환경 변수 하나를 빠뜨린 것입니다. 박시니어 씨가 조용히 말했습니다.

"배포는 자동화해야 합니다. 사람은 실수하니까요."

배포 자동화란 코드가 승인되면 테스트 환경, 스테이징 환경, 운영 환경까지 자동으로 배포되는 시스템입니다. 마치 택배 자동 분류 시스템처럼, 패키지가 올바른 목적지에 정확하게 도착하도록 보장합니다.

롤백, 카나리 배포, 블루그린 배포 등 다양한 전략이 있습니다.

다음 코드를 살펴봅시다.

# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 빌드 및 테스트 통과 확인
      - run: npm ci && npm test && npm run build

      # 스테이징 배포 후 스모크 테스트
      - name: Deploy to Staging
        run: ./scripts/deploy.sh staging
      - name: Smoke Test
        run: curl -f https://staging.example.com/health

      # 운영 배포 (카나리 전략)
      - name: Canary Deploy (10%)
        run: ./scripts/deploy.sh production --canary 10
      - name: Monitor for 5 minutes
        run: ./scripts/monitor.sh --duration 5m
      - name: Full Rollout
        run: ./scripts/deploy.sh production --canary 100

수동 배포는 왜 위험할까요? 사람은 반복 작업에서 실수하기 쉽습니다.

특히 긴장된 상황에서, 체크리스트의 한 항목을 빠뜨리거나 명령어를 잘못 입력하기 쉽습니다. 한 번의 실수가 서비스 전체를 다운시킬 수 있습니다.

배포 자동화는 마치 자동 조종 장치와 같습니다. 비행기 조종사도 이착륙 외에는 대부분 자동 조종에 맡깁니다.

기계는 지치지 않고, 항상 같은 절차를 정확하게 수행합니다. 배포도 마찬가지입니다.

위의 워크플로우는 점진적 배포 전략을 보여줍니다. 먼저 스테이징 환경에 배포하고 스모크 테스트를 실행합니다.

스모크 테스트란 "연기가 나는지 확인하는" 기본적인 테스트입니다. 서버가 뜨는지, 헬스체크가 통과하는지 정도만 확인합니다.

그 다음이 카나리 배포입니다. 카나리아 새는 예전에 광부들이 가스 누출을 감지하기 위해 탄광에 데려갔습니다.

새가 먼저 쓰러지면 광부들이 대피할 수 있었습니다. 카나리 배포도 같은 원리입니다.

전체 사용자의 10%에게만 먼저 새 버전을 배포합니다. 5분 동안 모니터링하면서 에러율이 증가하는지, 응답 시간이 느려지는지 확인합니다.

문제가 감지되면 즉시 롤백합니다. 문제가 없으면 점진적으로 비율을 높여 100%까지 롤아웃합니다.

이렇게 하면 문제가 생겨도 피해를 최소화할 수 있습니다. 또 다른 전략으로 블루그린 배포가 있습니다.

블루 환경과 그린 환경 두 개를 준비해둡니다. 현재 블루에서 서비스 중이라면, 그린에 새 버전을 배포합니다.

테스트가 통과하면 트래픽을 그린으로 전환합니다. 문제가 생기면 다시 블루로 돌리면 됩니다.

실제 현업에서는 더 정교한 시스템을 구축합니다. 피처 플래그를 사용하여 특정 기능만 특정 사용자에게 노출할 수 있습니다.

A/B 테스트와 연계하여 새 기능의 효과를 측정할 수도 있습니다. 배포 파이프라인은 단순한 코드 전달을 넘어, 비즈니스 의사결정 도구가 됩니다.

주의할 점이 있습니다. 자동화된 배포라도 모니터링은 필수입니다.

자동화는 사람의 개입을 줄여주지만, 완전히 없애지는 않습니다. 특히 첫 몇 분은 대시보드를 주시해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 배포 자동화를 도입한 후, 배포는 더 이상 긴장되는 이벤트가 아닙니다.

버튼 하나로 안전하게 배포되고, 문제가 생기면 자동으로 롤백됩니다. 김개발 씨는 이제 배포 날에도 편하게 퇴근할 수 있게 되었습니다.

실전 팁

💡 - 롤백 절차를 미리 테스트해두세요

• 배포 후 5분은 반드시 모니터링하세요
• 금요일 오후에는 배포하지 마세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!