대규모 CI, Bash로는 부족하다? 오케스트레이터가 필요한 이유
저자는 Bash 스크립트 기반 CI의 한계를 지적하며, 대규모 팀(Large Teams)에서 발생하는 문제점을 구체적으로 설명함
오케스트레이터(Orchestrator)의 필요성을 강조하며, Bash의 단순성(Simplicity)이 오히려 운영 복잡성(Operational Complexity)을 야기한다고 주장함
Makefiles를 활용한 CI 구축에 대한 긍정적 평가와 함께, Argo Workflows, Buildkite 등 다양한 CI/CD 솔루션이 언급됨
DevOps 엔지니어(DevOps Engineer)의 코딩 능력 중요성을 강조하며, Bash 스크립트의 유지보수(Maintenance) 어려움을 지적함
Bash 스크립트의 근본적인 한계
게시글은 Bash 스크립트가 단순한 작업(Simple Tasks)에는 적합하지만, CI 환경이 복잡해짐에 따라 여러 문제점을 야기한다고 지적한다. 특히, Bash는 데이터 구조(Data Structures), 타입 시스템(Type System), 오류 처리(Error Handling) 기능이 부족하여 대규모 CI 파이프라인(CI Pipeline) 구축에 어려움이 따른다. 저자는 Bash가 분산 시스템(Distributed System)을 구축하기에 적합하지 않다고 강조하며, 오케스트레이터의 필요성을 역설한다.
오케스트레이터의 장점: 격리 및 제어
게시글은 오케스트레이터가 제공하는 격리(Isolation)와 제어(Control) 기능을 강조한다. 오케스트레이터는 각 작업에 대해 별도의 컨테이너(Container)를 할당하여 파일 시스템(Filesystem), 프로세스 테이블(Process Table), 네트워크 포트(Network Ports) 등을 격리한다. 이를 통해, 동시 실행(Concurrent Execution) 시 발생하는 문제, 즉, 스펙트럼 오염(Spectral Contamination)을 방지하고, CI 시스템의 안정성을 확보한다. 또한, 오케스트레이터는 관찰 가능성(Observability)을 제공하여 CI 시스템의 운영 효율성을 높인다.
Makefiles의 활용과 한계
댓글에서는 Makefiles를 활용한 CI 구축에 대한 긍정적인 평가가 제시되었다. Makefiles는 정적 종속성(Static Dependencies)을 기반으로 하며, 파일 수정 시간을 기준으로 변경 사항을 감지하는 Dirty Bits 방식을 사용한다. 이는 Bash 스크립트보다 개선된 형태이지만, 동적 종속성(Dynamic Dependencies), 클라우드 캐싱(Cloud Caching), 조기 종료(Early Cutoff) 등 고급 기능을 지원하지 못한다는 한계가 있다. 게시글은 Makefiles가 특정 시나리오에서는 유용할 수 있지만, 대규모 CI 환경에서는 오케스트레이터가 더 적합하다고 주장한다.
DevOps 엔지니어의 코딩 능력 중요성
댓글에서는 DevOps 엔지니어의 코딩 능력 중요성이 강조되었다. Bash 스크립트 기반 CI는 유지보수(Maintenance)가 어렵고, 문제 발생 시 디버깅(Debugging)이 어렵다는 단점이 있다. 따라서, 복잡한 CI 파이프라인을 구축하고 관리하기 위해서는 코드 작성 능력(Coding Skills)을 갖춘 DevOps 엔지니어가 필요하다는 의견이 제시되었다. 또한, Buildkite, GitLab CI 등 오케스트레이터 기반의 CI/CD 솔루션이 대안으로 제시되었다.