edu-core 빌드 개선으로 앱 단위 증분 빌드가 가능해진 다음, 남아 있던 빌드 병목을 더 줄이기 위한 후속 작업입니다. 앱 단위 캐싱, webpack 캐싱, 인프라 스펙 순서로 단계마다 남은 문제를 다시 정의하며 풀었습니다. 그 결과 캐시가 자주 무효화되는 릴리즈성 빌드도 40분에서 7분으로 줄였습니다.
| 항목 | 내용 |
|---|---|
| 문제 | 앱 단위 증분 빌드는 됐지만, 정기 릴리즈처럼 변경 범위가 크면 캐시가 자주 무효화돼 빌드 시간이 그대로 남음 |
| 역할 | 앱 단위 캐싱 적용 / webpack 캐싱·인프라 스펙은 문제와 방안을 정의하고 SRE 스쿼드와 함께 진행 |
| 핵심 성과 | 변경 범위가 큰 빌드 40분 → 7분 (82.5% ↓) |
| 핵심 포인트 | 앱 캐싱 → webpack 캐싱 → 인프라 스펙 순으로, 단계마다 남은 문제를 정의하고 풀어간 것 |
edu-core 빌드 개선으로 앱 단위 증분 빌드가 가능해졌지만, 그것만으로 모든 빌드가 짧아지지는 않았습니다. 앱 단위 수정이나 서버 코드 수정처럼 변경이 제한적일 때는 캐시 효과가 컸지만, 정기 릴리즈처럼 여러 앱이 한꺼번에 바뀌면 앱 단위 캐시가 대부분 무효화돼 결국 다시 빌드해야 했습니다.
그래서 무효화로 다시 빌드되는 비용 자체를 줄이는 것을 목표로 삼았습니다.
Turborepo remote cache 서버를 구축해 같은 입력에 대한 빌드 결과를 재사용SRE 협업turbo cache만으로는 앱 캐시가 무효화되는 빌드를 줄이지 못해, 빌드 도중 반복해서 생기는 webpack 중간 산출물을 보존하자는 과제를 정의하고 SRE 스쿼드와 함께 진행했습니다.
EFS에 보존하는 방식으로 전환 → 앱 캐시가 무효화돼도 중간 산출물 일부는 재사용SRE 협업두 단계 캐싱 이후에도 변경 범위가 큰 빌드는 결국 다시 빌드해야 했습니다. 그래서 다시 빌드해야 할 때 어떤 인프라가 빌드에 가장 잘 맞는지 찾는 과제를 정의하고, SRE 스쿼드와 함께 빌드 시간·비용을 비교했습니다.
CPU intensive하다는 점을 확인c5a.4xlarge + concurrency=8 조합을 선택스펙이 좋을수록 빌드가 빨라지고 동시 실행 수도 늘지만 비용도 함께 오릅니다. 그래서 빌드 시간·인스턴스 비용·동시 실행 수·CPU 사용률을 함께 비교해, c5a.4xlarge + concurrency=8을 균형이 가장 좋은 조합으로 SRE 스쿼드와 함께 골랐습니다.
40분 → 7분은 캐시가 잘 맞는 앱 단위 빌드가 아니라, 변경 범위가 커서 다시 빌드해야 하는 릴리즈성 빌드를 기준으로 잰 수치입니다. 측정은 당시 CI 실행 로그와 인스턴스 조합별 빌드 결과를 비교한 값입니다.
앞선 edu-core 빌드 개선이 캐시가 의미 있게 동작할 구조를 만든 작업이었다면, 이 작업은 그 위에서 앱 캐싱 → webpack 캐싱 → 인프라 스펙 순으로 남은 빌드 시간을 줄여, 배포 시간을 더 예측 가능한 범위로 가져갔습니다.