프로덕션 시스템으로서의 개발 파이프라인

개발 파이프라인은 프로덕션 시스템이다

소프트웨어 개발 팀은 종종 고객 대상 프로덕션 장애를 무엇보다 우선시하지만, 정작 자신들의 개발 도구, 빌드 시스템, QA 환경의 장애는 부차적인 문제로 취급하는 경우가 많습니다. 하지만 가치를 전달할 책임이 있는 개발자와 테스터에게 개발 파이프라인은 프로덕션 시스템입니다. 파이프라인이 중단되면 팀의 소프트웨어 생산 능력이 멈추게 되며, 이는 내부 조직에 기능적인 프로덕션 장애를 초래합니다.

개발 파이프라인의 구성 요소 식별하기

파이프라인을 프로덕션 시스템으로 취급하려면, 팀은 먼저 고객의 요청이 전달된 기능으로 전환되는 과정을 촉진하는 모든 구성 요소를 식별해야 합니다. 이러한 핵심 경로 구성 요소에는 다음이 포함됩니다:

• 요청 추적: 이슈 보고 및 변경 요청 시스템 (예: GitHub Issues, Jira).
• 로컬 개발 도구: IDE, 빌드 도구 (Gradle, Maven), 패키지 저장소 (npm, Maven Central), 로컬 데이터베이스 및 컨테이너.
• 자동화 인프라: Jenkins 및 GitHub Actions와 같은 CI/CD 도구.
• 품질 게이트: 테스트 스위트 및 QA 서버. 프로덕션 배포를 방해하는 실패한 테스트 스리트나 오프라인 QA 서버는 치명적인 장애 지점입니다.

파이프라인 장애가 전달에 미치는 영향

개발 파이프라인의 핵심 구성 요소가 실패하면 가치 전달이 완전히 중단됩니다. 코드가 컴파일되지 않거나 테스트를 실행할 수 없다면, 팀은 작동하는 소프트웨어를 생산할 수 없습니다. 제조업에서는 이를 조립 라인 중단과 동일하게 간주하며, 유휴 인력의 비용이 매우 크기 때문에 가동 중단 시간을 최소화하기 위해 광범위한 프로세스와 SLA를 사용합니다.

인프라-as-프로덕션

운영 관점에서 보면, 기술 스택을 따라 내려갈수록 "프로덕션"의 정의가 확장됩니다. 제품 개발자는 고객 대상 시스템을 프로덕션으로 보지만, 인프라 및 운영 팀은 개발 및 테스트 환경을 프로덕션으로 취급해야 합니다. 그 실패가 수백 명의 개발자를 마비시키기 때문입니다.

인프라 운영팀 입장에서 보면, 개발과 테스트도 실제로 프로덕션입니다... 만약 개발이나 테스트 환경을 망가뜨리면, 수백 명의 개발자가 일을 못 하고 비명을 지르기 시작할 테니까요.

반론 및 리스크 관리

파이프라인을 프로덕션으로 취급하는 것이 긴급성을 높여주기는 하지만, 관리해야 할 특정 트레이드오프와 리스크가 수반됩니다.

우선순위 결정의 딜레마

일부에서는 "프로덕션"이라는 라벨이 용어의 오용이라고 주장하며, 고장난 IDE나 빌드 도구는 프로덕션 장애가 아닌 "개발 시스템 장애"라고 제안합니다. 주요 비판은 파이프라인 수정의 긴급성이 무조건적인 "전원 투입