CI/CD & 배포 자동화 — 빌드 속도·배포 전략·시크릿
발행빌드 캐시로 CI 속도 높이기, GitHub Actions 전환, 블루-그린·정적 배포 전략, 환경 분리 설계, 시크릿 관리와 파이프라인 관측까지. 배포 파이프라인 개선 실전 모음.
- 글
- 12
- 01
삼쩜삼속도 개선을 위한 노력 1탄: Codebuild S3 캐시 적용하기
AWS CodePipeline 기반 빌드가 소스 푸시 이후 배포까지 8분 이상 소요되며 외부 저장소에서 매번 의존성을 다운로드하는 비용이 높음.
- 02삼쩜삼
속도 개선을 위한 노력 2탄: Github Actions로 CI/CD 전환하기
Terraform으로 80개 이상 프로젝트를 관리하는 AWS CodePipeline 기반 CI/CD가 모듈 증가와 함께 성능 저하·오류 빈도 증가로 배포 시간이 약 20분에 달함.
- 03
- 04
쏘카FE Core팀의 CI 속도전: 캐시 전략을 활용한 병렬 빌드
turborepo 기반 monorepo 에 30+ Next.js 앱이 공존하면서 main 머지마다 전체 빌드가 트리거된다. 캐시 미스 시 20분 이상, 동시 워크플로우면 30분 이상 대기로 CI 가 강제 종료되는 일이 반복됐다.
- 05
버즈빌Python 2.7 서버의 CI Test 개선 - 13분에서 3분으로
Python 2.7 레거시 서버의 CI-Test 파이프라인이 약 13분 소요돼 긴급 배포 시 병목이 됐다. 실제 테스트는 2분이지만 패키지 설치·빌드 오버헤드가 11분을 차지했다.
- 06
사람인 기술블로그배포시간 단축: 블루-그린 배포 도입기
롤링 업데이트 방식의 로드밸런서 전환 과정에서 간헐적 에러·배포 실패 시 서비스 전체 중단 위험·13분 30초의 긴 배포 시간
- 07사람인 기술블로그
Next.js 프로젝트의 정적 파일 배포 환경 구성
온프레미스 환경에서 개발·프로덕션 정적 파일 혼재로 CDN 캐시 오염, 불필요한 개발 리소스 프로덕션 누적, 브랜치별 병렬 개발 불가
- 08
flex[코드가 환경을 모르는 구조 2/7] 배포 코드가 환경을 모르는 구조
개발/프로덕션 배포 스크립트가 시간이 지나면 디버그 플래그/리소스 제한/기능 플래그가 환경별로 갈라져 "실제로 다른 파이프라인" 이 되고, 마이그레이션 누락이나 env 변수 불일치가 발생한다.
- 09
GitLab BlogGitLab Secrets Manager 로 CI/CD 자격증명 관리
개발자들이 CI/CD 변수·설정 파일·.env 파일에 시크릿을 보관해 과도한 스코핑과 보안 노출이 발생한다.
- 10GitLab Blog
대규모 CI/CD observability 구축 방법
self-managed GitLab을 대규모로 운영하면 pipeline duration, 실패율, queue time, runner 포화도를 한눈에 보기 어렵다.
- 11
다나와CI/CD에서 기존 Provisioning Profile을 Git으로 유지하기
ConnectWave 통합 계정 정책상 앱당 Distribution Provisioning Profile은 1개만 유지해야 했고, CI 기기에 두자니 장비 교체에 약했으며 Jenkins로 관리하자니 네트워크 분리 때문에 원격 접근이 막혔다.
- 12
올리브영 테크블로그ECR - "저도 배포요정입니다 ✋🏻"
빌드·이미지 업로드·배포까지 수작업으로 돌리던 흐름은 시간이 오래 걸리고 실수가 잦아, 한 번의 클릭으로 끝나는 자동화 파이프라인이 필요했다.
