여러분은 스마트폰에서 자주 쓰는 앱이 업데이트될 때 어떤 일이 일어나는지 생각해 본 적 있으신가요? 앱 스토어에서 업데이트 버튼을 누르는 것은 사용자 입장에서는 아주 간단한 행동이지만, 그 뒤에서는 수십 명의 개발자들이 수주, 혹은 수개월에 걸쳐 작성한 코드가 여러 단계의 검증을 거쳐 서버에 반영되는 복잡한 과정이 숨어 있습니다.
이 과정을 업계에서는 “배포 파이프라인(Deployment Pipeline)”이라고 부릅니다. 마치 공장의 생산 컨베이어 벨트처럼, 개발자가 작성한 코드가 여러 단계를 거쳐 최종적으로 실제 서비스에 올라가는 자동화된 흐름입니다. 과거에는 개발자가 직접 서버 컴퓨터에 접속해서 파일을 하나하나 복사하고 설정을 맞추었지만, 그 방식은 실수가 잦고 서비스 장애의 원인이 되기도 했습니다.
요즘Cloud & DevOps 환경에서는 특히 Jenkins와 ArgoCD라는 두 가지 핵심 도구를 중심으로 배포 파이프라인을 자동화하고 있습니다. 이 글에서는 이 두 도구가 어떤 역할을 하는지, 코드가 개발자의 컴퓨터에서 출발해 실제 사용자 손에 닿기까지 어떤 여정을 거치는지를 살펴 보겠습니다. (비개발자도 이해하기 쉽게 작성해 보겠습니다)
DevOps 운영이란?
혹시 “개발팀이랑 운영팀이 따로 업무를 하다 보니 배포할 때마다 사고 난다”는 얘기 들어보셨나요? DevOps는 바로 이런 문제를 해결할 수 있습니다. 일반적인 소프트웨어 코드 개발(Dev)과 인프라 운영(Ops)이 손잡고 함께 일하는 방식입니다.
DevOps는 그림 속 무한대(∞) 모양처럼, 아래와 같은 과정의 이라고 할 수 있습니다.
계획 → 코드 작성 → 빌드 → 테스트 → 배포 → 운영 → 모니터링
그리고 이는 한 번 만들고 끝이 아니라, 계속 돌리면서 더 좋게 프로세스화합니다.
정리하자면 자동으로 빌드·배포해주는 CI/CD, 인프라를 코드로 관리해서 실수를 줄이는 IaC (Infrastructure as Code), 문제를 바로 알아채는 모니터링 (Monitoring), 그리고 늘 안전하게 지켜주는 보안 (Security)으로 운영됩니다.
그럼 좀 더 자세하게 어떤 방식으로 소프트웨어 코드 개발부터 배포가 되는지 살펴 보겠습니다.
CI/CD 배포(Deployment)란?
우리가 DevOps를 말할 때 항상 등장하는 용어가 CI/CD입니다.
CI (Continuous Integration, 지속적 통합)는 여러 개발자의 코드를 자주 합치고 자동으로 테스트하는 방식이며 CD (Continuous Delivery/Deployment, 지속적 배포)는 검증된 코드를 자동으로 서버에 배포하는 방식입니다. 즉 소프트웨어 개발에서 배포란, 개발자가 만든 코드를 실제로 사용자가 쓸 수 있는 서버 환경에 올려놓는 행위입니다.
현대의 소프트웨어 서비스는 규모가 크고 복잡합니다. 수십 명의 개발자가 동시에 서로 다른 기능을 개발하고, 하루에도 여러 번 새로운 코드가 만들어집니다. 이 모든 코드를 사람이 일일이 수동으로 서버에 올린다면 엄청난 시간이 걸릴 뿐 아니라, 실수가 생길 가능성도 높아집니다. 실제로 과거에는 배포 날이 개발팀에게 가장 긴장되는 날이었습니다. 새벽에 개발자들이 서버실에 모여 긴장된 표정으로 파일을 하나씩 복사하고, 서비스가 제대로 뜨는지 확인하는 광경이 흔했습니다.
이 문제를 해결하기 위해 등장한 것이 바로 DevOps라는 개념입니다. DevOps는 Development(개발)와 Operations(운영)의 합성어로, 개발팀과 운영팀 사이의 벽을 허물고 소프트웨어의 빌드·테스트·배포를 자동화하는 문화이자 방법론입니다. 그 중심에 바로 배포 파이프라인이 있습니다.
CI/CD배포 파이프라인 — 5단계의 여정
그럼 본격적으로 CI/CD 배포 과정을 살펴보겠습니다.
CI/CD 배포 파이프라인은 크게 5개의 단계로 구성됩니다. 개발자가 코드를 저장소에 올리는 순간, 이 5단계가 도미노처럼 자동으로 이어집니다. 사람이 개입할 필요가 없고, 각 단계가 성공해야만 다음 단계로 넘어가기 때문에 품질이 자연스럽게 보장됩니다.
1단계 – 소스 콘트롤 (Source Control)
“개발자가 GitLab에 코드를 push하면, Jenkis가 이를 자동으로 감지하고 다음 단계를 시작하라는 신호를 받습니다”
1단계 소스 컨트롤 (Source Control)은 모든 것은 개발자가 코드를 GitLab이라는 코드 저장소에 저장(Push)하는 것에서 시작됩니다. GitLab은 모든 개발자의 코드가 한 곳에 모이는 “코드의 집”입니다. 구글 드라이브나 네이버 클라우드에 파일을 올리면 팀원들이 같은 파일을 볼 수 있는 것처럼, GitLab에 코드를 올리면 팀 전체가 최신 코드를 공유할 수 있습니다.
개발자가 GitLab에 코드를 Push하는 순간, Jenkins가 이를 자동으로 감지합니다. Jenkins는 GitLab을 항상 지켜보고 있다가, 새로운 코드가 올라오면 즉시 “다음 단계를 시작하라”는 신호를 받습니다. 이 과정은 보통 몇 초 이내에 일어납니다.
CI/CD step 1 – Source Control (출처 : TechValley)
2단계: 빌드 & 테스트 (Build & Test)
“Jenkins는 코드를 빌드하고 자동으로 다양한 품질 검사를 실행합니다. 이에 모든 기준을 통과해야만 다음 단계로 진행할 수 있습니다.”
CI/CD step 2 : Build & Test (출처 : TechValley)
2단계 빌드 & 테스트 단계에서는 보통 Gradle이라는 도구를 사용해 Java 기반의 코드를 빌드합니다. 빌드가 완료되면 Jenkins는 자동으로 다음과 같은 코드 품질 검사를 실행합니다.
이 중 한 가지라도 기준을 통과하지 못하면 파이프라인이 멈추고, 개발자에게 알림이 전송됩니다. 문제를 수정하기 전까지는 다음 단계로 진행되지 않습니다. 이 덕분에 결함이 있는 코드가 실제 서비스에 올라가는 사고를 사전에 방지할 수 있습니다.
마치 요리사의 레시피와 같습니다. 레시피 (코드)만으로는 음식이 완성되지 않고 정확한 조리(빌드)와 맛, 위생 검사 (테스트)를 통과해야만 비로소 손님 (사용자)에게 음식을 제공할 수 있는 것과 비슷한 논리입니다.
완성된 Docker 이미지는 내부 컨테이너 레지스트리에 저장됩니다. 외부 클라우드로 이미지가 나가지 않고 내부에서 관리되므로 보안성이 높습니다. 레지스트리는 앱 이미지를 보관하는 “창고” 역할을 합니다.
내부 컨테이너 레지스트리란? (출처 : TechValley)
3단계 (컨테이너 단계)는 음식 배달에 비유하면 이렇습니다. 과거에는 셰프가 음식 재료를 각각 따로 보내고, 배달지에서 다시 조리를 해야 했습니다. 조리 환경이 다르면 맛이 달라질 수도 있었죠. Docker 이미지는 음식을 완전히 조리하고 포장까지 마친 밀키트 (meal kit) 상태로 배달하는 것과 같습니다. 이는 어느 서버에서 컨테이너를 실행하든 똑같이 동작한다는 것이 핵심입니다.
Docker와 밀키트 (Meal Kit) 비교 (출처 : TechValley)
4단계: 인프라 코드화 (Infra as Code)
“Jenkins는 Docker 이미지가 저장되면 배포 명세서 (Manifest)를 업데이트합니다. Manifest는 YAML 형식의 텍스트 파일로, 애플리케이션을 어떻게 배포할지 정의한 설계도입니다.”
컨테이너 이미지가 레지스트리에 저장되면 Jenkins는 “배포 명세서(Manifest)”를 업데이트합니다. Manifest는 YAML이라는 형식으로 작성된 텍스트 파일로, 예를 들어 “이 앱의 최신 버전 이미지를 서버 3대에 올려라, 메모리는 2GB씩 할당해라, 외부에서는 8080 포트로 접속하게 해라”와 같은 배포 설계도입니다.
CI/CD Step 4: Infra as Code (source : TechValley)
배포명세서 (Manifest)는 무엇을 정의할까?
Manifiest YAML 예시 (출처 : 테크밸리)
이 배포 명세서 (Manifest)역시 코드로 관리된다는 점이 핵심입니다. 누가, 언제, 어떤 버전으로 수정했는지 Git 기록에 모두 남습니다. 무언가 잘못되었을 때 “언제부터 문제가 생겼는가”를 정확히 추적할 수 있고, 이전 버전으로 되돌리는 것도 간단해집니다.
Git 기록 내용 및 변경 사항 추적, 문제 해결 및 롤백 (출처 : 테크밸리)
5단계: 실행 (Execution) — ArgoCD의 역할
“배포 명세서 Manifest가 업데이트되는 순간, Argo CD가 이를 감지하고 현재 서버의 상태와 Manifest의 이상적인 상태를 비교하여 자동으로 서버를 맞춰 줍니다.”
CI/CD Step 5: Execution (source : TechValley)
ArgoCD는 항상 Manifest 저장소를 바라보며, “현재 서버의 상태”와 “Manifest에 적혀 있는 이상적인 상태”가 일치하는지 지속적으로 비교합니다. 두 상태가 다르면 ArgoCD는 자동으로 서버를 Manifest의 상태와 일치하도록 맞춰줍니다.
이 방식을 “GitOps”라고 부릅니다. Git에 적혀 있는 내용이 진실(Source of Truth)이고, 서버는 항상 그 내용을 따라가야 한다는 철학입니다.
DevOps CI/CD 파이프라인, 자동화가 만드는 안정적인 서비스
CI/CD는 단순한 배포 자동화가 아니라 개발과 운영을 하나의 흐름으로 연결하는 DevOps의 핵심입니다. 개발자가 코드를 Push하면 빌드, 테스트, Docker 이미지 생성, Manifest 업데이트, ArgoCD 기반 GitOps 배포까지 모든 과정이 자동으로 수행됩니다.
위 그림과 같이 각 단계에서 품질을 검증하고 문제가 발생하면 즉시 중단하여 안정성을 확보하며, 모든 변경 이력은 Git에 기록되어 추적과 롤백도 쉽습니다. 결국 CI/CD는 더 빠른 배포, 더 높은 품질, 더 안정적인 운영을 실현하는 현대 클라우드 환경의 필수 기반이며, 반복 작업은 자동화하고 사람은 더 가치 있는 업무에 집중할 수 있도록 지원합니다
DevOps CI/CD는 빠른 배포(Faster Delivery), 높은 품질(Higher Quality), 안정적인 운영(Reliable Operation), 일관된 배포 환경(Consistent Environment)을 동시에 실현하는 현대 소프트웨어 개발의 표준입니다.
자동화는 사람을 대신하는 것이 아니라, 사람이 더 가치 있는 일에 집중할 수 있도록 반복 작업을 맡아주는 것입니다. 이것이 바로 DevOps가 추구하는 궁극적인 목표이며, CI/CD 파이프라인이 오늘날 클라우드 네이티브 환경에서 필수적인 이유입니다.
DevOPs 2편에서는 DevOps의 효율적인 운영을 위한 클라우드 구성 환경 (개발, 스테이징, 운영)에 대해 알아 보도록 하겠습니다.
