E2E 파이프라인 (새 탭에서 열림)
Slack은 E2E 테스트 파이프라인에서 프론트엔드 변경이 없어도 매번 프론트엔드를 빌드하는 비효율을 발견했다. Git 변경 감지와 기존 빌드 산출물 재사용을 도입해 프론트엔드 빌드 횟수를 60% 줄이고, 전체 파이프라인 시간을 약 10분에서 2분으로 단축했다. 그 결과 개발자 대기 시간과 AWS S3 저장 비용을 줄였을 뿐 아니라 E2E 테스트의 플래키함도 개선됐다. ## 프론트엔드 빌드가 병목이 된 이유 - Slack의 대규모 모노레포에서는 병합 전 전체 스택을 검증하기 위해 E2E 테스트를 실행했다. - 기존 파이프라인은 다음 순서로 동작했다. - 코드 변경 후 브랜치 푸시 - 프론트엔드 빌드: 약 5분 - QA 환경 배포 - 200개 이상의 E2E 테스트: 약 5분 - 프론트엔드와 무관한 백엔드·데이터베이스·서비스 변경에도 프론트엔드를 새로 빌드했다. - 매주 수천 번의 빌드가 발생했고, 빌드 하나당 AWS S3에 약 1GB의 데이터가 저장됐다. - 이 중 절반가량은 실제 프론트엔드 변경이 없어 중복 산출물에 해당했다. ## Git diff를 이용한 조건부 빌드 - 현재 브랜치와 `main`의 최신 공통 커밋을 기준으로 `git diff`의 3-dot 표기법을 사용했다. - 변경 내역에 프론트엔드 관련 파일이 포함된 경우에만 새 프론트엔드 빌드 작업을 실행했다. - 프론트엔드 변경이 없으면 빌드를 완전히 건너뛰고 기존 산출물을 사용했다. - 추적 파일이 10만 개가 넘는 모노레포에서도 Git의 변경 감지는 약 몇 초 안에 완료됐다. ## 기존 빌드 산출물과 내부 CDN 재사용 - 새 빌드가 필요하지 않은 경우 AWS S3에 저장된 기존 프론트엔드 빌드를 탐색했다. - 현재 Production에서 사용 중인 비교적 최신 빌드를 선택해 테스트에 활용했다. - 내부 CDN이 해당 프론트엔드 정적 파일을 제공하도록 구성했다. - 이를 통해 PR마다 새 빌드를 생성하지 않으면서도 최신 상태에 가까운 프론트엔드 자산으로 E2E 테스트를 수행했다. ## 대규모 환경에서의 자산 관리 - 수백 개의 PR이 매일 병합되므로 재사용할 빌드가 충분히 최신인지 판단해야 했다. - S3의 파일명 규칙과 저장 구조를 활용해 빌드 산출물의 최신성, 일관성, 검색 성능을 관리했다. - 변경 여부 판단과 적절한 빌드 산출물 탐색을 평균 3초 이내에 처리했다. - 결과적으로 전체 테스트 흐름에서 프론트엔드 빌드 단계를 효율적으로 제거할 수 있었다. ## 성능과 비용 개선 - 불필요한 프론트엔드 빌드 빈도를 60% 줄였다. - AWS S3 중복 저장 데이터를 매월 수 테라바이트 규모로 절감했다. - 클라우드 컴퓨팅 비용과 개발자의 파이프라인 대기 시간을 줄였다. - 기존 Webpack 개선으로 평균 빌드 시간이 10분에서 5분으로 줄어든 데 이어, 이번 최적화로 약 2분까지 단축했다. - 전체 E2E 파이프라인 시간은 평균 10분에서 2분으로 감소했다. ## 예상하지 못한 효과 - 프론트엔드 빌드 과정과 자산 전달 방식이 단순해지고 일관되면서 E2E 테스트의 플래키함이 감소했다. - 월별 측정 결과 테스트 실패의 불안정성이 가장 낮은 수준까지 개선됐다. - 오래된 여러 시스템의 레거시 코드를 조사하는 과정에서 기존 동작을 재발견하고 향후 개선 과제도 발굴했다. ## 실용적인 결론 CI/CD 파이프라인에서는 모든 단계를 무조건 실행하기보다 실제 변경 범위와 필요한 검증 수준을 기준으로 조건부 실행을 설계하는 것이 효과적이다. 특히 Git 변경 감지, 빌드 산출물 캐싱, CDN 재사용을 결합하면 빌드 시간과 클라우드 비용을 동시에 줄일 수 있다.
