[19주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 84

CI/CD 파이프라인과 스테이징 배포, 테스트 자동화까지 한 번에 이해하기

최근 대부분의 개발 프로젝트에서는 단순히 “기능을 만든다”에서 끝나지 않습니다.
기능을 안정적으로 배포하고, 오류를 빠르게 발견하며, 협업 과정에서 품질을 유지하는 것까지 모두 개발의 중요한 영역이 되었습니다.

특히 팀 프로젝트나 실무에서는 다음과 같은 질문들이 자주 등장합니다.

• “왜 내 코드만 배포하면 오류가 날까?”
• “배포 전에 테스트를 자동으로 돌릴 수 없을까?”
• “운영 서버에 바로 올리기 전에 미리 검증할 방법은 없을까?”
• “매번 수동으로 빌드하고 배포하는 게 너무 번거로운데?”

이런 문제를 해결하기 위해 등장한 개념이 바로 CI/CD 파이프라인, 테스트 자동화, 스테이징 배포, 그리고 인수 테스트입니다.

이번 글에서는 실제 개발 흐름을 기준으로 아래 내용을 하나씩 정리해보겠습니다.

• CI/CD란 무엇인가
• 왜 자동화가 중요한가
• 빌드 및 패키징 과정
• 단위 테스트와 코드 커버리지
• 스테이징 배포
• 인수 테스트
• 실제 프로젝트 흐름 예시
• 협업 과정에서 얻을 수 있는 장점

---

CI/CD란 무엇일까?

CI/CD는 크게 두 가지 개념으로 나뉩니다.

• CI (Continuous Integration)
• CD (Continuous Delivery / Deployment)

쉽게 말하면:

“코드를 자주 합치고(CI), 자동으로 배포까지 연결(CD)하는 개발 문화와 시스템”

이라고 볼 수 있습니다.

---

Continuous Integration (CI)

CI는 지속적인 통합을 의미합니다.

여러 명의 개발자가 동시에 작업하다 보면 아래와 같은 문제가 발생합니다.

• 서로 다른 코드 충돌
• 기능 간 예기치 못한 버그
• 테스트 누락
• 환경 차이로 인한 실행 오류

예전에는 기능 개발이 끝난 뒤 한 번에 코드를 합쳤기 때문에 충돌이 매우 많았습니다.

하지만 CI 환경에서는:

1. 개발자가 코드를 push
2. 자동으로 테스트 실행
3. 빌드 검사
4. 문제 여부 확인

이 과정을 반복합니다.

즉:

“코드를 자주 합치고, 문제를 빠르게 발견한다”

가 핵심입니다.

---

Continuous Delivery / Deployment (CD)

CD는 자동 배포 개념입니다.

CI가 “문제가 없는 코드인지 검증”하는 단계라면,

CD는:

• 서버 배포
• Docker 이미지 생성
• 클라우드 반영
• 서비스 업데이트

까지 자동화합니다.

여기서 CD는 두 가지로 나뉩니다.

Continuous Delivery

배포 가능한 상태까지 자동 준비

→ 실제 운영 배포는 사람이 버튼 클릭

Continuous Deployment

운영 서버까지 완전 자동 배포

→ 테스트 통과 시 즉시 반영

---

왜 CI/CD가 중요할까?

개발을 하다 보면 아래 문제가 정말 자주 발생합니다.

1. “내 컴퓨터에서는 잘 되는데요?”

가장 유명한 문제입니다.

로컬에서는 잘 동작하지만:

• Node 버전 차이
• 환경 변수 문제
• OS 차이
• 패키지 버전 문제

등으로 서버에서는 오류가 발생합니다.

CI 환경에서는 항상 동일한 환경에서 검증하기 때문에 이런 문제를 줄일 수 있습니다.

---

2. 테스트 누락 방지

수동 테스트는 반드시 놓치는 부분이 생깁니다.

특히 프로젝트 규모가 커질수록:

• 로그인
• 회원가입
• API 응답
• 권한 처리
• 예외 처리

등을 전부 사람이 확인하기 어렵습니다.

CI에서는 코드가 올라갈 때마다 자동으로 테스트를 수행합니다.

---

3. 배포 속도 향상

수동 배포 과정은 생각보다 시간이 오래 걸립니다.

예를 들어:

1. 코드 pull
2. 의존성 설치
3. 빌드
4. 서버 실행
5. 로그 확인

이 과정을 매번 사람이 수행하면 실수 가능성이 커집니다.

CI/CD 환경에서는 이 모든 작업이 자동으로 수행됩니다.

---

CI/CD 파이프라인 설계

CI/CD 파이프라인은 보통 아래 흐름으로 구성됩니다.

코드 Push
   ↓
Lint 검사
   ↓
테스트 실행
   ↓
빌드 수행
   ↓
Docker 이미지 생성
   ↓
스테이징 배포
   ↓
인수 테스트
   ↓
운영 배포

 

각 단계를 자세히 살펴보겠습니다.

---

1. Lint 검사

Lint는 코드 스타일과 문법 문제를 검사합니다.

대표적으로:

• ESLint
• Biome
• Prettier

등을 사용합니다.

예를 들어:

 

const a = "hello"

 

세미콜론이 없거나 스타일 규칙이 맞지 않으면 자동으로 감지합니다.

---

왜 중요할까?

팀 프로젝트에서는 코드 스타일 통일이 매우 중요합니다.

스타일이 제각각이면:

• 가독성 저하
• 리뷰 어려움
• 유지보수 비용 증가

문제가 발생합니다.

---

2. 단위 테스트(Unit Test)

단위 테스트는 가장 작은 기능 단위를 검증합니다.

예시:

 

function add(a, b) {
  return a + b;
}

 

테스트:

 

expect(add(1, 2)).toBe(3);

 

---

단위 테스트의 장점

빠른 오류 발견

코드 수정 직후 문제 확인 가능

리팩토링 안정성

기존 기능이 깨졌는지 즉시 확인 가능

유지보수 향상

오래된 프로젝트일수록 효과가 큼

---

코드 커버리지(Code Coverage)

커버리지는:

“테스트가 코드의 몇 %를 검증했는가”

를 의미합니다.

예시:

• 함수 10개 중 8개 테스트
• 조건문 일부 미검증

→ 커버리지 80%

---

커버리지가 중요한 이유

테스트가 존재한다고 해서 충분한 것은 아닙니다.

실제로 중요한 로직이 테스트되지 않았을 수도 있습니다.

그래서:

• 함수
• 조건문
• 분기
• 예외 처리

등이 얼마나 검증되었는지 확인해야 합니다.

---

3. 빌드 및 패키징

테스트가 끝나면 실제 서비스 형태로 빌드합니다.

예를 들어 React 프로젝트라면:

 

pnpm build

 

NestJS라면:

 

npm run build

 

을 수행합니다.

---

패키징이란?

애플리케이션을 배포 가능한 형태로 묶는 과정입니다.

대표적으로 Docker를 많이 사용합니다.

---

Docker 기반 패키징

예시 Dockerfile:

 

FROM node:20

WORKDIR /app

COPY . .

RUN pnpm install

RUN pnpm build

CMD ["pnpm", "start"]

 

---

Docker의 장점

환경 통일

개발/테스트/운영 환경 일치

배포 안정성

“내 컴퓨터에서는 됨” 문제 감소

확장성

클라우드 환경과 궁합이 좋음

---

4. 스테이징 배포

스테이징(Staging)은:

운영과 거의 동일한 테스트 서버

입니다.

운영 서버에 바로 배포하면 위험하기 때문에 중간 검증 단계가 필요합니다.

---

왜 스테이징이 중요할까?

실제 운영 환경에서는:

• DB 연결
• Redis
• 인증
• 클라우드 스토리지
• 환경 변수

등 다양한 요소가 연결됩니다.

로컬 테스트만으로는 검증이 어렵습니다.

그래서 운영과 유사한 환경에서 먼저 테스트합니다.

---

스테이징 서버에서 하는 것

API 검증

실제 요청 테스트

UI 테스트

프론트 화면 확인

성능 테스트

응답 속도 확인

협업 검증

프론트/백엔드 연동 테스트

---

5. 인수 테스트(Acceptance Test)

인수 테스트는:

“사용자 입장에서 기능이 정상 동작하는가”

를 확인하는 테스트입니다.

---

단위 테스트와 차이점

단위 테스트

함수/모듈 중심

인수 테스트

실제 사용자 흐름 중심

---

예시

사용자 로그인 흐름:

1. 로그인 페이지 접속
2. 이메일 입력
3. 비밀번호 입력
4. 로그인 버튼 클릭
5. 메인 페이지 이동 확인

이 전체 흐름을 테스트합니다.

---

E2E 테스트와의 관계

인수 테스트는 보통 E2E 테스트 형태로 구현됩니다.

대표 도구:

• Selenium
• Cypress
• Playwright

---

실제 CI/CD 흐름 예시

예를 들어 GitHub Actions를 사용하면:

 

name: CI

on:
  push:
    branches:
      - develop

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v3

      - run: pnpm install

      - run: pnpm lint

      - run: pnpm test

      - run: pnpm build

 

이렇게 자동화할 수 있습니다.

---

GitHub Actions의 장점

GitHub와 통합 쉬움

별도 서버 없이 사용 가능

PR 검증 가능

Pull Request마다 자동 테스트

협업 효율 증가

오류 코드 머지 방지

---

실무에서 자주 사용하는 전략

브랜치 전략

대표적으로:

• main
• develop
• feature/*
• hotfix/*

형태를 많이 사용합니다.

---

feature 브랜치

기능 개발용

---

develop 브랜치

통합 테스트용

---

main 브랜치

실제 운영 코드

---

PR 기반 코드 리뷰

CI/CD와 함께 코드 리뷰 문화도 중요합니다.

PR 과정에서:

• 코드 품질 확인
• 로직 검증
• 버그 예방
• 구조 개선

이 가능합니다.

---

자동화가 가져오는 가장 큰 변화

CI/CD를 도입하면 가장 크게 바뀌는 것은:

“개발 속도보다 안정성이 훨씬 좋아진다”

입니다.

처음에는 설정이 어렵고 복잡하게 느껴질 수 있습니다.

하지만 프로젝트 규모가 커질수록 자동화의 가치가 엄청나게 커집니다.

---

실제로 줄어드는 문제들

배포 실수 감소

수동 작업 제거

테스트 누락 감소

자동 검증

협업 충돌 감소

빠른 피드백

장애 대응 속도 향상

문제 위치 빠른 파악

---

DevOps 문화와 연결

CI/CD는 단순 도구가 아닙니다.

개발(Development)과 운영(Operations)을 연결하는 DevOps 문화의 핵심입니다.

즉:

• 개발자
• QA
• 운영팀
• 인프라 팀

이 함께 안정적인 서비스를 만드는 방향으로 연결됩니다.

---

앞으로 더 중요해지는 자동화

최근에는:

• Docker
• Kubernetes
• GitHub Actions
• Jenkins
• ArgoCD
• Terraform

등 자동화 생태계가 더욱 발전하고 있습니다.

특히 AI 기반 개발 도구가 증가하면서:

“더 빠르게 개발하고 더 안정적으로 배포하는 능력”

이 점점 중요해지고 있습니다.

---

마무리

처음 CI/CD를 접하면 어렵고 복잡하게 느껴질 수 있습니다.

하지만 실제 프로젝트를 진행하다 보면:

• 테스트 자동화
• 배포 자동화
• 스테이징 검증
• 코드 품질 관리

가 얼마나 중요한지 체감하게 됩니다.

특히 팀 프로젝트에서는:

• 협업 효율 증가
• 버그 감소
• 유지보수 향상
• 안정적인 서비스 운영

에 큰 도움이 됩니다.

결국 좋은 개발은 단순히 기능을 만드는 것이 아니라:

“안정적으로 동작하고, 안전하게 배포되며, 지속적으로 개선 가능한 구조를 만드는 것”

이라고 생각합니다.

CI/CD는 바로 그 기반이 되는 핵심 개발 문화입니다.