GitHub Actions 파이프라인, 무엇을 근거로 설계해야 하나?
결론부터 적으면, 캐시와 병렬화는 피드백 속도를 올리는 장치이고 카나리·블루그린은 그 속도를 안전하게 쓰기 위한 브레이크다. 둘 중 하나만 잘 짜서는 배포가 잦아지지 않는다. 이 글은 캐시 동작 원리, 병렬화가 실제로 리드타임을 줄이는 지점, 배포 단계에서 진짜 위험이 어디서 생기는지를 공식 문서와 2026년 장애 회고 기준으로 정리한다.
- 캐시는 저장소당 기본 10GB, 2026년 기준 사용자 저장소는 최대 10TB까지 설정 가능하지만 7일 미접근 시 자동 삭제된다.
- 캐시 API는 2025-02-01부로 v2 서비스로 전환됐고, 레거시 서비스는 같은 날 종료됐다.
- install/build와 test job을 분리해야 matrix 병렬화의 효과가 제대로 난다.
- 2026년 8월 GitHub 장애 회고는 "평범한 배포"가 내부 캐시 CPU 사용률을 98%까지 밀어붙인 사례를 보여준다.
- 카나리는 1~5% 트래픽 노출과 30분 관측 창 같은 작은 단위로 굴러가는 실전 사례가 있다.
캐시는 어떻게 파이프라인 속도를 바꾸나?
캐시는 무조건 저장하는 창고가 아니라 자주 쓰는 의존성만 살아남게 설계해야 하는 가속 장치다. GitHub 공식 문서는 캐시 복원이 exact match → partial match → restore-keys 순서로 진행된다고 명시하는데, 이 순서 때문에 캐시 키를 너무 느슨하게 잡으면 원하지 않는 버전이 재사용되거나, 반대로 너무 빡빡하게 잡으면 매번 새로 받는 일이 생긴다. 실제로 대용량 코드베이스와 모노레포에서는 기존 10GB 한도 때문에 자주 쓰는 의존성이 캐시에서 밀려나 다음 워크플로우에서도 계속 다시 내려받는 문제가 있었다는 게 GitHub 쪽 설명이다. 2026년 기준으로는 사용자 소유 저장소가 최대 10TB까지 캐시 상한을 늘릴 수 있게 됐지만, 그렇다고 무한정 쌓아두면 7일간 미접근 캐시는 그대로 삭제되니 저장 자체가 목적이 될 이유는 없다. I/O 쪽도 상한이 있어서 저장소당 분당 최대 200회 업로드, 1500회 다운로드로 제한된다는 점도 GitHub Actions 캐싱 문서에 나온 수치다. 러너나 캐시 인프라 자체를 바꾸는 방식도 있는데, Depot는 캐시 업로드·다운로드가 최대 1000 MiB/s, 네트워크 처리량 12.5 Gbps라고 문서화했고 Blacksmith는 자사 고객 사례에서 최대 10배 빨라졌다고 주장한다. 다만 이 수치들은 벤더 보고치라서, 실제 팀 환경에 그대로 적용될 것으로 기대하기보다는 참고 지표 정도로 두는 편이 맞다.
병렬화는 실제로 어디까지 리드타임을 줄이나?
병렬화는 GitHub Actions의 기본 동작이라, 같은 워크플로우 안의 여러 job과 같은 저장소의 여러 run은 별도 설정 없이도 동시에 돈다. 문제는 병렬화가 효과를 내려면 그 전에 단계를 나눠야 한다는 점이다. Cypress의 GitHub Actions 가이드는 install job에서 의존성과 빌드를 먼저 처리해 캐시를 만들고, 이후 여러 worker job이 그 캐시를 재사용하면서 matrix 전략으로 테스트를 나눠 돌리는 구조를 권장한다. 이 순서가 중요한 이유는, install과 test를 한 job에 몰아넣으면 matrix로 몇 개를 늘리든 매번 의존성 설치부터 반복하게 되기 때문이다. 즉 캐시 히트율이 낮은 상태에서도 install/build/test를 분리해두면 테스트 병렬화만으로 전체 리드타임을 줄일 여지가 생긴다. 반대로 캐시 최적화에만 매달리고 job 구조를 그대로 두면, 캐시가 아무리 빨라도 순차 실행 구간이 그대로 남아 체감 효과가 제한적이다. matrix 전략 문서에서 보듯 matrix는 같은 job 정의를 여러 변형으로 동시에 띄우는 방식이라, 이 구조가 갖춰진 다음에야 병렬 job 수를 늘리는 선택이 의미를 가진다.
배포 단계에서 진짜 위험은 어디서 생기나?
배포는 파이프라인 전체에서 가장 짧지만 가장 위험한 구간이다. 2026년 8월 GitHub 장애 보고는 이를 수치로 보여준다. job-routing 변경으로 33%의 job을 제한된 프로덕션 클러스터에서 여유 용량 쪽으로 옮기면서 캐시 CPU 사용률이 98%에서 80%로 낮아졌고, 이 조치로 약 3개월치 여유 용량을 확보했다고 밝혔다. 더 눈에 띄는 부분은, 내부 Actions 서비스의 평범한 배포 자체가 용량 저하를 유발했다는 사실이다. 배포 내용 자체에는 문제가 없었지만, rollout 중 pod가 교체되는 짧은 구간에 한 데이터센터의 처리량이 잠시 줄었고, 그 여파가 나머지 사이트로 번져 한계치에 닿았다는 설명이다. 이 사례는 GitHub Actions 파이프라인에서도 배포 단계의 무중단성이 왜 중요한지 보여준다. 배포가 내부 이벤트 처리 계층의 용량을 잠깐만 흔들어도 작업 라우팅과 캐시 계층이 함께 압박받을 수 있다는 뜻이기 때문이다. 이런 배경에서 카나리 배포는 전체 트래픽을 한 번에 넘기는 대신 1~5% 수준의 라이브 트래픽만 먼저 흘려보내고, 30분 단위 관측 창을 두고 평균 드리프트가 임계치를 넘으면 자동으로 롤백하는 구조로 운영되는 사례가 2026년에 공개됐다. 블루그린은 새 버전을 별도 환경에 완전히 올린 뒤 트래픽을 한 번에 전환하는 방식이라 전환 자체는 단순하지만, 문제가 트래픽 전환 이후에 한꺼번에 드러난다는 차이가 있다.
"캐시를 늘리면 무조건 빨라진다"는 말, 맞을까?
틀린 전제다. 캐시 상한이 10TB까지 늘어난 것과 실제 워크플로우 속도가 빨라지는 것은 별개 문제다. 캐시는 exact match가 안 되면 partial match, 그다음 restore-keys 순서로 내려가면서 복원을 시도하는데, 키 설계가 느슨하면 오히려 원치 않는 버전을 복원하거나 결국 전체를 다시 받는 상황이 생긴다. 또한 7일간 미접근 캐시는 상한과 무관하게 삭제되므로, 자주 실행되지 않는 워크플로우의 캐시는 상한을 아무리 늘려도 계속 새로 만들어지는 구조다. 분당 업로드 200회, 다운로드 1500회라는 I/O 상한도 있어서, job을 과도하게 쪼개 캐시 요청을 몰아넣으면 오히려 병목이 생길 수 있다. 캐시는 "얼마나 저장할 수 있는가"보다 "어떤 키로, 얼마나 자주 접근되는가"가 실제 속도를 좌우한다는 점이 공식 문서가 말하는 구조에 가깝다.
이 조합, 언제 쓰고 언제 피해야 하나?
배포 빈도가 하루 여러 번인 팀이라면 install/build 분리, matrix 병렬 테스트, 카나리 배포의 조합이 균형점에 가깝다. 이 조합은 공식 문서가 보장하는 병렬성·캐시 재사용 구조와, 실제 장애 회고가 보여준 배포 리스크 완화 필요성을 함께 만족시킨다. 반대로 배포가 주 1회 이하로 드문 팀, 혹은 트래픽 관측·자동 롤백 스크립트를 붙일 여력이 없는 팀에는 카나리보다 블루그린이 운영 부담이 적다. 롤백 판단을 사람이 수동으로 내려도 되는 규모라면 30분 관측 창 같은 자동화 인프라를 억지로 만들 필요는 없다. 캐시 상한을 늘리는 것도 모노레포처럼 의존성 재설치 비용이 큰 경우에 의미가 있지, 저장소가 작고 빌드가 몇 초 안에 끝나는 경우에는 캐시 설계에 들이는 시간이 오히려 손해일 수 있다.
핵심 정리
- 캐시는 저장소당 기본 10GB, 2026년 기준 최대 10TB까지 늘릴 수 있지만 7일 미접근 시 삭제되고 exact/partial/restore-keys 순서로 복원된다.
- install/build와 test job을 분리해야 matrix 병렬화가 리드타임 단축으로 이어진다.
- 2026년 8월 장애 회고는 평범한 배포도 캐시 CPU 사용률을 98%까지 밀어붙일 수 있음을 보여줬다.
- 카나리는 1~5% 트래픽과 30분 관측 창으로 빠른 피드백을, 블루그린은 단순한 전환으로 낮은 운영 부담을 준다.
- 캐시 상한 확대는 속도 보장이 아니라 키 설계·접근 빈도와 함께 봐야 의미가 있다.