CI/CD에 꾸준히 투입하라 — 아니면 사라진다
Source: Dev.to
초기 생각
- 파이프라인에도 신진대사가 있다
- 굶주린 파이프라인의 해부학
- 우리가 갇힌 성숙도 사다리
- 능동적인 CI/CD 엔지니어는 스스로 비용을 회수한다 — 8배
- “먹이 주기”가 실제로 어떻게 보이는지
- 대화용 치트 시트
- AI 시대: 유기체는 그 어느 때보다 빠르게 소화해야 한다
- 마무리
- 추가 읽을거리
우리 고객이 “좋아, CI/CD는 끝났어!”라고 말한 순간—그것이 첫 번째 놓친 식사였다. 파이프라인은 마감일이 있는 산출물이 아니다. 살아있는 유기체다. 그리고 지금 수천 개 기업에서, 모두 배포가 점점 어려워지는 이유를 궁금해 하는 사이에 파이프라인은 서서히 굶어가고 있다.
우리 모두 겪어봤다. 팀이 몇 주—때로는 몇 달—걸려 견고한 CI/CD 파이프라인을 구축한다. 린팅, 단위 테스트, 통합 테스트, 자동 배포, 어쩌면 보안 스캔까지. 고객은 고개를 끄덕이며 승인한다. 예산 항목도 체크된다. 그리고… 아무 일도 일어나지 않는다. 파이프라인은 유지보수 모드에 들어가는데, 실제로는 유지보수가 전혀 이루어지지 않는다.
이 “설정하고 잊어버리기” 사고방식은 현대 소프트웨어 엔지니어링에서 가장 비싼 오해 중 하나다. Jez Humble가 말했듯이, 우리는 변화를 프로젝트처럼 시작하고 끝낸 뒤 일상으로 돌아가서는 안 된다. CI/CD는 목적지가 아니라 규율이다. 토요타 생산 시스템은 수십 년 전부터 카이젠(지속적 개선)이라는 개념으로 이를 이해했다: 지속적 개선은 단계가 아니라 기본 상태다. (스포일러: 토요타는 이 접근법으로 괜찮았다.)
핵심 문제는 경제적 프레이밍의 오류다. 고객은 CI/CD를 인프라 비용—한 번 구축하면 도로처럼 영구적인 것—으로 본다. 하지만 파이프라인은 도로가 아니다. 정원에 더 가깝다. 혹은 정확히 말하면, 정기적인 먹이가 필요하고 살아야 하는 유기체다.
이 글은 파이프라인이 서서히 부패하는 모습을 지켜본 모든 개발자와, CI/CD 투자를 중단하는 것이 올해 가장 비싼 결정이 될 것이라는 사실을 진심으로 이해하지 못하는 모든 의사결정자를 위한 것이다.
CI/CD 파이프라인은 소비한다
매일 새로운 코드, 새로운 의존성, 새로운 프레임워크 버전, 새로운 보안 권고, 새로운 인프라 설정을 처리한다. 입력(커밋, 머지 요청, 스케줄)과 출력(아티팩트, 배포, 리포트)이 있다. 소화 시스템(빌드 단계), 면역 시스템(테스트와 보안 스캔), 신경 시스템(알림, 대시보드, DORA 메트릭)도 갖추고 있다.
우리가 제대로 “먹이”를 주면—테스트 스위트를 업데이트하고, 빌드 시간을 최적화하고, 코드베이스가 진화함에 따라 새로운 품질 게이트를 추가하면—파이프라인은 건강을 유지한다. 빠른 빌드, 신뢰할 수 있는 테스트, 자신감 있는 배포. 팀은 파이프라인을 믿고, 의존하고, 이를 통해 속도를 낸다.
하지만 먹이를 끊으면, 스트레스를 받는 모든 유기체처럼 증상이 서서히 나타난다:
- 불안정한 테스트가 급증한다. 테스트 스위트를 관리하는 사람이 없으니 간헐적인 실패가 배경 소음이 된다. 개발자들은 “혹시 모르니” 파이프라인을 다시 실행한다. (자동판매기에서 망치를 두드리는 식의 유지보수와 같다.)
- 빌드 시간이 늘어난다. 의존성이 부풀고, 캐시가 만료되고, 병렬 설정이 오래돼서 5분 걸리던 것이 20분이 된다. 개발자는 컨텍스트 스위치를 해야 하고, 흐름 상태가 사라진다.
- 보안 스캔이 비활성화된다. 느리고, 오탐이 많아 삼매경을 할 시간이 없기 때문이다. “나중에 다시 켤게.” 라고 말하지만 실제로는 켜지 않는다.
- 파이프라인 코드가 부서 지식이 된다. 파이프라인을 만든 엔지니어는 6개월 전에 떠났고, 아무도 YAML을 건드리려 하지 않는다. 이제 그것은 신성하고, 신비롭고, 두려운 존재—레포지토리의 언약궤가 된다.
Google의 DORA 연구 프로그램은 이러한 안티패턴을 광범위하게 문서화한다. 실패한 테스트를 무시하는 파이프라인은 면역 붕괴 상태다. 빌드가 10분을 초과하면 대사 장애가 있는 파이프라인이다. 유기체가 아직 죽지는 않았지만, 생명 유지 장치 위에 놓여 있고, 아무도 모니터를 확인하지 않는다.
아래는 파이프라인 굶주림이 월별로 어떻게 진행되는지 보여준다. 이 타임라인이 너무 익숙하게 느껴진다면, 바로 그게 목적이다.
월 1
파이프라인은 빠르고, 초록색이며, 신뢰받는다. 개발자는 자신감 있게 코드를 푸시한다. 테스트는 실제 버그를 잡아낸다. 배포는 주 2~3회 이루어진다. 삶이 좋다. 💚
월 3
몇몇 불안정한 테스트가 등장한다. retry: 2 혹은 allow_failure: true 로 무음 처리한다. “시간 날 때 고치자.” 테스트 스위트는 이제 약간 구멍 난 그물처럼 약간 투과성이 생긴다. 작은 물고기들이 빠져나오기 시작한다.
월 6
빌드 시간이 조용히 두 배가 된다. 의존성은 두 마이너 버전 뒤처지고, 프레임워크는 세 버전 뒤처진다. 보안 스캔은 “잠시” 비활성화된다—8분이 추가되고 47개의 중간 심각도 CVE가 뜨지만, 이를 삼킬 인력이 없기 때문이다. 파이프라인은 여전히 동작하지만, 보호 기능은 거의 사라졌다.
월 9
개발자들은 파이프라인을 신뢰하지 않는다. 빨간 빌드가 일상이 된다. “항상 빨강이니 그냥 머지하자.” 팀은 부득이하게 우회 방법을 만든다: “이 단계 무시”, “그 테스트는 화요일에만 통한다”, “배포 잡은 수동 재시도가 필요하다.” 신규 개발자는 실제 실패와 잡음의 차이를 구분하지 못한다. 파이프라인은 이제 슈뢰딩거의 품질 게이트가 된다—동시에 통과와 실패를 동시에 보여주며, 우회 방법을 기억하는 사람만이 의미를 파악한다.
월 12
수동 QA가 복귀한다. 핫픽스 사이클이 스프린트 계획을 장악한다. 고객은 “왜 작년보다 배포가 느려졌나요?” 라고 묻는다. 컨설턴트가 투입돼 상황을 평가한다. 첫 질문: “마지막으로 파이프라인에 투자를 한 게 언제인가요?” 침묵. 💀
마틴 파울러가 주방 비유로 말했듯이, 우리는 어질러지지 않고는 요리를 할 수 없지만, 진행 중에 청소하지 않으면 찌꺼기가 굳어버려 제거가 어려워지고 결국 요리 자체를 할 수 없게 된다. 파이프라인은 주방이다. 현재 천장에 마른 스파게티 소스가 묻어 있고, 깨끗한 팬을 찾을 수 없는 상황이다.
CI/CD 성숙도 모델
CI/CD는 이진 상태가 아니다. 다섯 단계로 명확히 정의된 스펙트럼이다:
- Base — 버전 관리만 존재하고, 빌드는 수동 또는 반자동이다. 테스트는 사후 고려 사항이다. 배포는 체크리스트, 기도, 가끔은 데모 신에게 바치는 제물 정도다.
- Beginner — 기본 CI가 구축된다. 단위 테스트가 자동으로 실행된다. 파이프라인이 존재하지만, 부서지고 부분적으로 수동이다. 대부분의 조직이 이 단계에 도달해 승리를 선언한다.
- Intermediate — 업계 평균 수준. 파이프라인이 전체 라이프사이클(빌드, 테스트, 배포)을 커버한다. 하지만 반응형 유지보수—깨질 때마다 고치고, 그 외에는 무시한다.
- Advanced — 전담 툴 또는 플랫폼 팀이 있다. 파이프라인 개선