0258

개발

"린트, 테스트, 배포까지 자동화: CI/CD 개념부터 구성까지"

오프닝

프론트엔드 개발을 하면서 코드 품질을 유지하고, 안정적으로 배포하는 방법에 대한 고민이 늘 있었다.

그러던 중 CI/CD라는 개념을 접하게 되었고, 이를 실제 프로젝트에 어떻게 적용할 수 있는지 공부해보게 되었다.

이번 포스팅에서는 CI/CD가 무엇이며, 왜 중요한지에 대해 정리해보았다.

CI/CD란?

1) CI (Continous Integration, 지속적인 통합)

: 개발자들이 작은 단위로 자주 코드를 병합하고, 병합 시마다 자동으로 테스트와 빌드를 수행하여 문제를 빠르게 발견하는 과정

(1) 예시 상황

  • main 브랜치에 PR을 보내자마자

  • GitHub Actions가 자동으로 npm run build, npm run test, npm run lint를 돌림

  • 문제가 있으면 병합 못하게 막음

  • → 버그나 린트 오류가 main에 올라갈 일이 없음!

2) CD (Continous Delivery / Deployment, 지속적인 배포)

: 테스트를 통과한 코드를 자도응로 배포 가능한 상태로 만들거나, 실제 운영 서버에 자동 배포까지 하는 과정

(1) 예시 상황

  • main에 머지하면 자동으로 Vercel이 배포

  • 혹은 staging 서버까지는 자동, 운영은 수동 승인

CI/CD 파이프라인 구성 요소

단계

설명

예시 도구

1. 코드 푸시

개발자가 Git에 변경사항 업로드

GitHub, GitLab

2. 자동 빌드

프로젝트를 실행 가능한 형태로 번들링

Webpack, Vite, Rollup

3. 자동 테스트

유닛/통합 테스트 자동 실행

Jest, Playwright, Vitest

4. 린트 & 포맷

코드 스타일 자동 검사/수정

ESLint, Prettier

5. 배포

테스트 통과 후 서버에 배포

Vercel, Netlify, AWS S3 + CloudFront

1) CI/CD 관련 용어 요약

  • Lint: 코드 스타일 체크 도구

  • Unit Test: 작은 단위 함수나 컴포넌트를 검증하는 테스트

  • Build: 프로젝트를 실제 서비스 가능한 코드로 번들링하는 과정

  • 배포(Deployment): 사용자에게 서비스가 도달하도록 서버에 코드 올리는 일

2) 흐름 예시

(1) 개발자가 GitHub에 push

(2) GitHub Actions가 자동으로:

- Lint 검사 (eslint)

- Unit test 실행 (jest)

- Build 실행 (vite build)

(3) 모두 성공하면 → Vercel로 자동 배포

프론트엔드에서 CI/CD가 중요한 이유

1) 코드 품질 유지

  • 작은 UI 오류도 사용자 경험에 직접 영향.

  • CI로 테스트·린트 자동화하면 오류를 미리 차단 가능.

2) 빠른 피드백

  • 코드 푸시하자마자 자동 테스트 → 문제 발생 시 즉시 알림.

  • 버그를 조기에 발견하고 빠르게 대응할 수 있음.

3) 협업 효율 향상

  • 누가 병합하든 자동 체크로 기본 품질 보장.

  • 팀원 간 충돌 줄이고, 안심하고 작업 가능.

4) 안정적인 배포

  • CD로 배포 자동화하면 수동 실수 줄어듦.

  • main 브랜치 머지 시 바로 운영에 반영되도록 설정 가능.

CI/CD 도입 시 고려할 점

1) 테스트 커버리지가 충분한가?

  • CI의 핵심은 자동화된 테스트를 기반으로 품질을 검증하는 것이다.

  • 하지만 테스트 코드가 거의 없다면 CI를 돌려도 신뢰성이 떨어질 수밖에 없다.

  • 프론트엔드라면 최소한 컴포넌트 단위 테스트나 렌더링 확인 정도는 갖춰야 했다.

2) 빌드 시간이 과도하게 오래 걸리지는 않는가?

  • CI 파이프라인이 복잡하거나 빌드 시간이 너무 길면 푸시할 때마다 대기 시간이 발생하고, 이는 오히려 개발 리듬을 방해하게 된다.

  • vite와 같이 빠른 번들러를 쓰거나, 캐시를 잘 활용하는 설정이 필요했다.

3) 병합 조건과 트리거를 어떻게 구성할 것인가?

  • 무조건 모든 브랜치에 CI/CD를 적용하면 효율이 떨어진다.

  • 예를 들어 develop 브랜치에는 프리뷰 배포만, main 브랜치에는 운영 배포만 수행되도록 브랜치 전략을 설정하는 것이 필요했다.

4) 비용 및 리소스 제한은 고려했는가?

  • GitHub Actions나 Vercel은 무료 요금제에서도 CI/CD 기능을 제공하지만, 무제한은 아니었다.

  • 빌드 횟수, 테스트 시간, 동시 실행 수 등에 제한이 있어 잦은 커밋이 많은 프로젝트라면 요금제 초과가 발생할 수 있었다.

5) 민감한 정보나 환경변수 관리 방법은 안전한가?

  • CI 환경에서 API 키, DB 주소, 시크릿 값 등을 다뤄야 할 때는 반드시 .env 파일이 아닌 환경변수 설정 기능을 활용해야 했다.

  • 특히 Vercel, GitHub Actions 등에서는 프로젝트 설정에서 환경변수를 따로 관리할 수 있도록 제공하고 있었다.

마무리

이번에 CI/CD에 대해 정리하면서, 개발 효율성과 안정성을 높이기 위해 왜 많은 팀들이 CI/CD를 도입하는지 조금은 이해할 수 있었다.

아직 직접 파이프라인을 구축해본 경험은 없지만, React 기반 프로젝트에서 GitHub Actions와 Vercel을 활용해 실제로 적용해보고 싶다는 생각이 들었다.

하지만 파이프라인을 구축해볼 수 있었고, 위의 글을 확인해보면 도움이 될 것이다!