빌드 도구, 테스트 도구, 배포 도구를 따로 만들었으면 그 다음 문제는 "이걸 어떻게 자동으로 이어 붙일까"다. 한 사람이 매번 손으로 "빌드 끝났으니 테스트 시작", "테스트 통과했으니 배포 시작"을 누르는 건 출시 직전 새벽 3시까지 누군가가 깨어 있어야 하는 비극을 만든다. CodePipeline은 그 비극을 끝내는 도구다. "소스 변경 감지 → 빌드 → 테스트 → 승인 → 배포"라는 흐름을 한 번 정의해두면, 그 다음부터는 코드를 push할 때마다 자동으로 production까지 흘러간다.
DVA-C02 시험에서 CodePipeline 자체의 문법은 많이 묻지 않는다. 대신 다른 Code 서비스들과 어떻게 조합되는지*, 수동 승인이 언제 필요한지, artifact가 어떻게 단계 간에 흐르는지, 그리고 2023년 등장한 V2 파이프라인의 변수와 트리거 필터링이 출제 포인트다. 이번 글에서는 CodePipeline의 내부 동작 모델, 아티팩트 시스템의 본질, 그리고 크로스 계정/리전 패턴까지 짚는다.
CodePipeline은 build tool이 아니다. 빌드 자체는 CodeBuild가 하고, 배포는 CodeDeploy/CloudFormation/ECS가 한다. CodePipeline의 역할은 그것들을 순서대로, 조건부로, 병렬로 실행하는 워크플로우 엔진이다