[CI/CD] DevOps CI/CD 정리

우유·2026년 4월 10일

CI/CD cloud devops

[Cloud] CI/CD

목록 보기

13/13

CI/CD 통합 정리

핵심 흐름은 DevOps와 CI/CD 개념 -> 파이프라인 구조 -> Jenkins -> GitHub Actions -> GitOps/Argo CD -> AWS 네이티브 CI/CD 순서로 이해하면 된다.

1. DevOps와 CI/CD 기본 개념

DevOps란

DevOps는 Development와 Operations의 합성어이며, 개발과 운영을 분리된 조직으로만 보지 않고 서비스 생명주기 전체를 함께 책임지는 방식이다.

DevOps는 특정 도구 이름이 아니라 다음을 포함하는 문화와 실천 방식이다.

개발과 운영의 협업
반복 작업 자동화
빠른 피드백
지속적인 모니터링
장애와 배포 이력의 공유

전통적 개발/운영 방식의 한계

전통적인 방식에서는 개발팀, 테스트팀, 운영팀이 강하게 분리되는 경우가 많다. 이를 사일로 구조라고 한다.

문제점:

배포 요청과 승인 과정이 병목이 됨
개발 환경과 운영 환경 차이로 장애 발생
수동 배포로 인한 실수 증가
책임 소재가 불분명해짐
롤백과 추적이 어려움

DevOps의 핵심 요소

요소	의미
Culture	책임 공유, 협업, 빠른 피드백
Automation	빌드, 테스트, 배포, 모니터링 자동화
Measurement / Monitoring	운영 상태를 수치와 로그로 관찰
Sharing	지식, 이력, 장애 원인, 운영 절차 공유

CI

CI는 Continuous Integration, 즉 지속적 통합이다.

핵심:

코드를 자주 통합
통합 시마다 자동 빌드/테스트
문제를 빨리 발견

CI의 목적:

통합 충돌 최소화
빌드 실패 조기 발견
테스트 자동화
코드 품질 유지
배포 가능한 상태 유지

CD

CD는 문맥에 따라 두 가지 의미로 쓰인다.

구분	의미
Continuous Delivery	배포 가능한 상태까지 자동화하고 운영 반영은 사람이 승인
Continuous Deployment	검증 통과 후 운영까지 자동 배포

암기:

Delivery = 배포 준비 자동화 + 사람 승인 가능
Deployment = 운영 배포까지 자동

2. CI/CD 파이프라인 구조

파이프라인이란

소스코드 변경이 발생한 뒤 빌드, 테스트, 패키징, 배포, 검증까지 이어지는 자동화 흐름이다.

기본 흐름:

Source
 -> Build
 -> Test
 -> Package / Artifact
 -> Publish
 -> Deploy
 -> Verify

중요:

앞 단계가 실패하면 다음 단계로 넘어가면 안 됨
파이프라인은 단순 명령어 묶음이 아니라 품질 통제 흐름

Source 단계

파이프라인의 시작점이다.

트리거:

push
pull_request
merge
tag
수동 실행
일정 기반 실행

Source 단계 산출물:

커밋 SHA
브랜치 이름
태그 이름
특정 버전의 소스코드

Build 단계

소스코드를 실행 가능하거나 배포 가능한 형태로 변환한다.

예:

Java: JAR/WAR 생성
Node.js: 번들링
Python: 의존성 설치/패키징
Docker: 이미지 빌드

Test 단계

자동 검증 단계다.

테스트 종류:

Unit Test
Integration Test
End-to-End Test
Lint / Static Analysis
Security Scan

Quality Gate

다음 단계로 넘어가기 위한 품질 기준이다.

예:

테스트 실패 0건
코드 커버리지 80% 이상
Lint 오류 0건
High 취약점 0건

Package / Artifact

빌드 결과물을 배포 가능한 단위로 정리하는 단계다.

Artifact 예:

JAR/WAR
바이너리
정적 파일
Docker Image
배포 ZIP

중요:

같은 Artifact를 dev/stage/prod에 승격해야 재현성이 좋아짐
환경마다 다시 빌드하면 결과물이 달라질 수 있음

Publish 단계

Artifact를 저장소에 업로드한다.

예:

Docker Hub
Amazon ECR
S3 Artifact Bucket
Nexus/Artifactory

Deploy 단계

Artifact를 특정 환경에 반영한다.

환경 예:

dev
staging
production

배포 방식:

방식	의미
In-place	기존 서버 위에 직접 교체
Rolling	일부씩 순차 교체
Blue/Green	새 환경 준비 후 트래픽 전환
Canary	일부 사용자/트래픽에 먼저 배포

Verify 단계

배포 후 실제 서비스가 정상인지 확인한다.

확인 예:

HTTP 응답 확인
Health Check
로그 확인
에러율 확인
주요 기능 테스트

실패 처리 원칙

Fail Fast
로그 명확화
알림
재실행 가능성
롤백 고려

Deploy와 Release 구분

Deploy: 코드/Artifact가 환경에 배포됨
Release: 사용자가 실제 기능을 사용하게 됨

Feature Flag를 쓰면 배포와 릴리스를 분리할 수 있다.

3. Jenkins 아키텍처

Jenkins란

Jenkins는 반복 작업을 자동화하는 오픈소스 자동화 서버다.

주요 역할:

소스코드 가져오기
빌드
테스트
Artifact 생성
Docker 이미지 빌드/Push
배포 스크립트 실행
결과 알림

Jenkins의 위치

Jenkins는 CI 실행 엔진이면서 CD 파이프라인 제어 도구가 될 수 있다.

GitHub
 -> Jenkins
 -> Build/Test
 -> Docker Registry
 -> Deploy Target

Jenkins 특징

오픈소스
Plugin 기반 확장
Pipeline as Code 지원
분산 실행 가능
자체 인프라/폐쇄망 환경에 적합

Controller / Agent 구조

구성	역할
Controller	UI, Job 설정, 스케줄링, 플러그인, 권한 관리
Agent	실제 빌드/테스트/스크립트 실행

Controller와 Agent를 분리하는 이유:

부하 분산
실행 환경 분리
보안 격리
확장성 확보

Workspace와 Executor

Workspace: Job이 실행될 때 소스코드와 임시 파일이 놓이는 작업 공간
Executor: Agent에서 동시에 실행 가능한 작업 슬롯

Jenkins Job 유형

유형	특징
Freestyle	UI 기반 단순 작업
Pipeline	Jenkinsfile 기반 파이프라인
Multibranch Pipeline	브랜치별 Jenkinsfile 자동 인식

Jenkins의 장점

복잡한 커스텀 파이프라인에 강함
다양한 플러그인
사내망/자체 인프라에 적합
오래된 레거시 자동화 자산과 연동 쉬움

Jenkins의 한계

직접 운영 부담
플러그인 의존성과 취약점 관리 필요
Controller 과부하 가능
UI 중심 설정은 추적 어려움
보안/권한 관리 중요

4. Jenkins Pipeline과 Jenkinsfile

Jenkins Pipeline

빌드, 테스트, 패키징, 배포 단계를 코드 형태로 정의하고 실행하는 방식이다.

Pipeline as Code

파이프라인 정의를 UI가 아니라 코드 파일로 저장소에 함께 보관하는 방식이다.

Jenkins에서는 이 파일이 보통 Jenkinsfile이다.

장점:

변경 이력 추적
코드 리뷰 가능
재현성 향상
브랜치별 독립 파이프라인 가능
애플리케이션 코드와 자동화 흐름을 함께 관리

Jenkinsfile

Jenkins Pipeline 정의 파일이다.

보통 저장소 루트에 위치한다.

my-app/
 ├ src/
 ├ Dockerfile
 └ Jenkinsfile

Declarative vs Scripted Pipeline

구분	Declarative	Scripted
특징	정해진 문법 구조	Groovy 기반 자유도 높음
장점	읽기 쉽고 표준화 쉬움	복잡한 로직 가능
단점	자유도 제한	가독성/관리 난이도
입문/표준	권장	고급 상황

Declarative Pipeline 기본 구조

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                echo 'checkout'
            }
        }
        stage('Build') {
            steps {
                echo 'build'
            }
        }
    }

    post {
        success {
            echo 'success'
        }
        failure {
            echo 'failure'
        }
    }
}

주요 구성요소

pipeline: 전체 파이프라인
agent: 실행 노드
stages: 단계 묶음
stage: 개별 단계
steps: 실제 명령
post: 후처리
environment: 환경 변수
parameters: 실행 입력값
when: 조건 실행
input: 승인 대기
options: 실행 옵션

Stage 설계 원칙

논리적으로 구분
실패 원인을 빠르게 알 수 있어야 함
너무 잘게 쪼개지지 않아야 함
운영 관점에서 의미 있는 이름 사용

5. Jenkins CI Pipeline 실습 핵심

실습 흐름:

GitHub
 -> Jenkins Pipeline
 -> Docker Build
 -> Docker Hub Push

실습 핵심 포인트

Jenkins 설치
Java 설치
Git/Docker 설치
Jenkins 사용자를 docker 그룹에 추가
Docker Hub Credentials 등록
Pipeline Job 생성
GitHub Webhook 연결

Docker 기반 CI 결과물

실습에서 중요한 점은 빌드 결과물이 단순 파일이 아니라 Docker 이미지라는 점이다.

Source Code + Dockerfile
 -> docker build
 -> docker image
 -> docker push
 -> Registry 저장

Jenkins Credentials

비밀번호나 토큰을 Jenkinsfile에 직접 쓰면 안 된다.

대신 Jenkins Credentials에 등록하고 withCredentials로 사용한다.

GitHub Webhook

GitHub에 push가 발생했을 때 Jenkins에 이벤트를 전달해 자동 실행한다.

Webhook 확인 포인트:

Payload URL
Content type
Event: push
Jenkins Job Trigger 설정

자주 발생하는 오류

Jenkins 접속 불가: 보안 그룹/포트/서비스 상태 확인
Docker 권한 오류: jenkins 사용자를 docker 그룹에 추가 후 재시작
Docker login 실패: Credentials/토큰 확인
Push 후 Registry에서 안 보임: 이미지명/태그 확인
Webhook 미동작: URL, 포트, GitHub에서 Jenkins 접근 가능 여부 확인

6. GitHub Actions 개념

GitHub Actions란

GitHub 저장소 이벤트를 기준으로 자동화 작업을 수행하는 플랫폼이다.

주요 용도:

push 시 자동 빌드
PR 생성 시 테스트
Docker 이미지 빌드
Artifact 업로드
배포 자동화
보안 검사

기본 구성요소

구성	의미
Workflow	자동화 절차 전체
Job	Workflow 안의 작업 단위
Step	Job 안의 개별 실행 단위
Runner	실제 실행 환경

Workflow 파일 위치

.github/workflows/

GitHub는 이 디렉토리의 YAML 파일을 Workflow로 인식한다.

Runner

구분	특징
GitHub-hosted Runner	GitHub가 제공, 관리 부담 낮음
Self-hosted Runner	사용자가 직접 운영, 사내망/특수 환경 접근 가능

이벤트 기반 구조

대표 이벤트:

push
pull_request
workflow_dispatch
release
schedule
tag

GitHub Actions 장점

GitHub와 통합성 높음
시작이 쉬움
YAML 파일 기반 관리
Marketplace Action 재사용 가능
GitHub 중심 협업 흐름에 적합

한계

GitHub 종속성
복잡한 자체 인프라 제어에는 한계
실행 시간/비용/자원 제한 고려
Workflow가 비대해질 수 있음

7. GitHub Actions Workflow 문법

기본 골격

name: CI Workflow

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Run command
        run: echo "hello"

주요 요소

name: Workflow 표시 이름
on: 실행 트리거
jobs: 실행할 Job 목록
runs-on: Runner 환경
steps: 실행 단계
uses: 재사용 Action 호출
run: 직접 명령 실행

`uses`와 `run` 차이

요소	의미
`uses`	이미 만들어진 Action 재사용
`run`	쉘 명령 직접 실행

자주 쓰는 요소

env: 환경 변수
defaults: 기본 실행 설정
if: 조건부 실행
needs: Job 간 의존성
strategy.matrix: 여러 환경 조합 병렬 실행
secrets: 민감정보
workflow_dispatch: 수동 실행

Job 실행 관계

기본적으로 Job은 병렬 실행
순서가 필요하면 needs 사용

변수와 Secret

변수: 일반 설정값
Secret: 토큰, 비밀번호, 키 같은 민감정보

Secret은 로그에 노출되지 않도록 보호되며, 배포/인증에서 중요하다.

8. GitHub Actions 실습 핵심

실습에서 다룬 내용:

기본 Workflow 실행
Python 코드 실행
pytest 테스트 자동화
결과 파일 생성
Artifact 업로드
브랜치별 실행 분기
Secret 사용
EC2 자동 배포

Python CI 흐름

push
 -> checkout
 -> setup-python
 -> pip install
 -> pytest
 -> 결과 확인

Artifact 업로드

빌드나 테스트 결과물을 GitHub Actions 실행 결과에 저장한다.

예:

테스트 리포트
빌드 결과 파일
로그 파일

브랜치별 분기

브랜치 전략과 Workflow 트리거를 연결할 수 있다.

예:

dev: 테스트만
main: 빌드 + 배포
tag: 릴리스

EC2 자동 배포

GitHub Secrets에 EC2 접속 정보나 SSH Key를 저장하고, Workflow에서 SSH/SCP로 배포할 수 있다.

주의:

Secret 노출 금지
SSH 대상 보안 그룹 확인
배포 후 서비스 재시작/검증 필요

9. Jenkins와 GitHub Actions 비교

항목	Jenkins	GitHub Actions
운영 방식	직접 설치/운영	GitHub 내장형
실행 구조	Controller / Agent	Workflow / Runner
확장 방식	Plugin	Marketplace Actions
설정 위치	Jenkinsfile 또는 UI	`.github/workflows/*.yml`
자체 인프라	강함	Self-hosted Runner로 가능
시작 난이도	상대적으로 높음	낮음
운영 부담	높음	낮음

Jenkins가 유리한 경우

사내망/폐쇄망
레거시 빌드 환경
복잡한 커스텀 파이프라인
자체 인프라 통제 필요

GitHub Actions가 유리한 경우

GitHub 중심 개발
빠른 CI 도입
소규모~중간 규모 서비스
YAML 기반 간단한 자동화

10. GitOps 개념

GitOps란

운영 환경이 어떤 상태여야 하는지를 Git에 선언하고, 실제 시스템이 Git 상태를 기준으로 동기화되도록 만드는 방식이다.

핵심:

Git = 운영 상태의 Single Source of Truth

GitOps에서 Git이 저장하는 것

Kubernetes 매니페스트
Helm values
Kustomize 설정
이미지 태그
환경별 구성값
운영 반영 이력

핵심 철학

개념	의미
Declarative	원하는 상태를 선언
Single Source of Truth	Git이 운영 기준
Reconciliation	실제 상태를 Git 기준으로 동기화

Push 방식 vs Pull 방식

기존 Push 기반 CD

CI 도구
 -> 운영 환경에 직접 kubectl apply / SSH / 배포 명령

문제:

CI 도구가 운영 권한을 많이 가짐
실제 상태와 Git 상태 비교가 약함
수동 변경 Drift 추적 어려움

GitOps Pull 기반

CI
 -> 이미지 빌드/Push
 -> GitOps 저장소 매니페스트 변경
 -> GitOps 도구가 Git 변경 감지
 -> 클러스터에 Sync

장점:

운영 환경 인바운드 접근 감소
변경 이력이 Git에 남음
Drift 감지와 복원 가능
롤백이 쉬움

GitOps는 CI를 대체하지 않음

CI 역할:

빌드
테스트
이미지 생성
이미지 Push
GitOps 저장소 업데이트

GitOps 역할:

Git의 원하는 상태를 클러스터에 동기화

11. Argo CD

Argo CD란

Kubernetes 환경에서 GitOps 방식 배포를 구현하는 대표적인 오픈소스 도구다.

Argo CD는 Git 저장소를 원하는 상태로 보고, 클러스터 실제 상태를 그 상태와 맞춘다.

Argo CD 기본 흐름

Git 저장소에 매니페스트 존재
 -> Argo CD가 저장소 감시
 -> 변경 감지
 -> 원하는 상태 렌더링
 -> 클러스터 실제 상태와 비교
 -> 차이가 있으면 Sync
 -> 클러스터 상태를 Git 기준으로 맞춤

핵심 개념

개념	의미
Application	배포/동기화 관리 단위
Source	Git 저장소, 경로, 브랜치
Destination	대상 클러스터/네임스페이스
Sync Policy	수동/자동 동기화 정책

Sync Status와 Health Status

상태	의미
Sync Status	Git 기준 상태와 실제 상태가 같은가
Health Status	리소스가 정상 동작하는가

중요:

Synced여도 Pod가 Crash이면 Health는 나쁠 수 있음
Healthy여도 Git과 다르면 OutOfSync일 수 있음

Manual Sync vs Auto Sync

방식	특징
Manual Sync	사람이 동기화 승인
Auto Sync	Git 변경 감지 시 자동 반영

Drift

Git에 없는 수동 변경으로 실제 클러스터 상태가 Git과 달라진 상태다.

Argo CD는 Drift를 감지하고, 정책에 따라 원래 Git 상태로 되돌릴 수 있다.

Argo CD 운영 주의점

Git 변경 통제가 매우 중요
클러스터 직접 수정을 줄여야 함
Sync와 Health를 구분해야 함
저장소 구조 설계가 중요
Argo CD 자체도 운영 대상

12. Argo CD GitOps 실습 핵심

전체 흐름

소스코드 수정
 -> GitHub Actions 실행
 -> Docker 이미지 빌드
 -> Docker Hub Push
 -> GitOps 저장소 deployment.yaml 이미지 태그 변경
 -> Argo CD가 Git 변경 감지
 -> EKS에 Sync
 -> 새 Pod 생성
 -> 기존 Pod 종료

저장소 2개 구조

Application Source Repository

애플리케이션 코드
Dockerfile
CI Workflow
이미지 빌드/Push
GitOps 저장소 이미지 태그 변경

GitOps Repository

Kubernetes 매니페스트
Namespace
Deployment
Service
Kustomization
배포 이미지 태그

왜 저장소를 분리하는가

앱 코드와 운영 선언을 분리
운영 변경 이력 추적
배포 승인/리뷰 구조 만들기 쉬움
여러 환경 관리에 유리

실습 핵심 리소스

EKS Cluster
Argo CD
GitHub Repository 2개
Docker Hub Repository
Kubernetes Namespace/Deployment/Service
GitHub Actions Workflow

확인 순서

GitHub Actions 실행 확인
Docker Hub 이미지 태그 확인
GitOps 저장소 deployment.yaml 변경 확인
Argo CD Sync 확인
Pod 교체 확인
웹 화면 확인

핵심 포인트

CI는 직접 클러스터에 배포하지 않음
CI는 이미지 빌드와 GitOps 저장소 변경을 수행
Argo CD가 GitOps 저장소 기준으로 EKS에 배포
Pod가 바뀌는 이유는 Deployment 이미지 태그가 변경되기 때문

13. AWS 네이티브 CI/CD

사용 서비스

서비스	역할
CodeCommit	Git 소스 저장소
CodeBuild	빌드 수행
CodeDeploy	EC2/ECS/Lambda 배포
CodePipeline	전체 단계 오케스트레이션
S3	Artifact 저장
EC2	배포 대상 서버

전체 구조

Developer
 -> CodeCommit push
 -> CodePipeline 변경 감지
 -> CodeBuild 빌드
 -> S3 Artifact 저장
 -> CodeDeploy EC2 배포
 -> Nginx 웹서버 반영

CodeCommit

AWS 관리형 Git 저장소다.

역할:

소스 저장
Push 이벤트로 Pipeline 시작

CodeBuild

빌드 실행 서비스다.

buildspec.yml을 읽어서 빌드 단계를 수행한다.

buildspec.yml 핵심

version: 0.2
phases:
  install:
    commands:
      - echo "install"
  build:
    commands:
      - mkdir -p output
      - cp -r index.html appspec.yml scripts output/
artifacts:
  files:
    - "**/*"
  base-directory: output

중요:

phases: install/build/post_build 등 빌드 단계
artifacts: 다음 단계로 넘길 결과물
base-directory: Artifact 기준 디렉토리

CodeDeploy

배포 대상 서버에 Artifact를 반영하는 서비스다.

EC2 배포에서는 대상 서버에 CodeDeploy Agent가 필요하다.

appspec.yml

CodeDeploy가 배포 파일을 어디에 복사하고 어떤 Hook을 실행할지 정의한다.

핵심:

files: 파일 복사 규칙
permissions: 파일 권한
hooks: 배포 생명주기 스크립트

Hook 예

BeforeInstall
ApplicationStart
ValidateService

중요:

배포 성공은 파일 복사 완료가 아니라 서비스 정상 동작 확인까지 포함해야 함
ValidateService에서 curl -f 같은 검증을 수행

CodePipeline

전체 단계를 연결하는 오케스트레이션 서비스다.

Source -> Build -> Deploy

각 단계:

Source: CodeCommit
Build: CodeBuild
Deploy: CodeDeploy

S3 Artifact Bucket

CodePipeline/CodeBuild가 중간 산출물을 저장하는 위치다.

중요:

S3는 소스 저장소가 아니라 Artifact 저장소

EC2 준비 포인트

Nginx 설치
CodeDeploy Agent 설치
EC2 IAM Role 연결
배포 대상 식별용 태그 설정

자주 발생하는 오류

CodeDeploy가 EC2를 못 찾음: 태그/Deployment Group/Agent 상태 확인
appspec.yml 오류: YAML 문법, 경로, Hook 확인
스크립트 실행 실패: 실행 권한, shebang, 권한 확인
Build 실패: buildspec.yml, Artifact 경로 확인
ValidateService 실패: Nginx 상태, 파일 경로, HTTP 응답 확인
Git push 인증 실패: CodeCommit 인증/credential helper 확인

핵심 정리

CodePipeline은 전체 흐름 제어
CodeBuild는 빌드
CodeDeploy는 배포와 Hook 실행
CodeCommit은 소스 저장소
S3는 Artifact 저장소

14. 주요 비교 정리

CI vs CD

항목	CI	CD
목적	코드 통합과 검증	배포 가능/운영 반영
주요 작업	Build, Test	Package, Deploy, Verify

Continuous Delivery vs Continuous Deployment

항목	Delivery	Deployment
운영 반영	사람 승인 가능	자동
핵심	언제든 배포 가능	자동 운영 배포

Jenkins vs GitHub Actions

항목	Jenkins	GitHub Actions
운영	직접 운영	GitHub 내장
실행 단위	Job/Pipeline	Workflow/Job/Step
실행 환경	Agent	Runner
확장	Plugin	Marketplace Action
적합	복잡한 자체 환경	GitHub 중심 빠른 자동화

Push CD vs GitOps Pull CD

항목	Push 방식	GitOps Pull 방식
배포 주체	CI 도구	클러스터 내부 GitOps 도구
운영 권한	CI가 직접 가짐	Argo CD 등 배포 도구가 가짐
Drift 감지	약함	강함
기준점	배포 스크립트/실행 결과	Git 저장소

CodePipeline vs Jenkins/GitHub Actions

항목	CodePipeline	Jenkins/GitHub Actions
성격	AWS 네이티브 오케스트레이션	범용 자동화 도구
통합	AWS 서비스와 강함	외부 서비스 연동 다양
관리 부담	낮음	도구별 상이

CodeBuild vs CodeDeploy

항목	CodeBuild	CodeDeploy
역할	빌드 수행	배포 수행
기준 파일	buildspec.yml	appspec.yml
결과	Artifact 생성	대상 환경 반영

15. 아키텍처 흐름으로 외우기

일반 CI/CD 파이프라인

Source
 -> Build
 -> Test
 -> Artifact
 -> Publish
 -> Deploy
 -> Verify

Jenkins Docker CI

GitHub push
 -> Jenkins Webhook
 -> Jenkins Pipeline
 -> Docker Build
 -> Docker Hub Push

GitHub Actions Python CI

GitHub push
 -> Workflow 실행
 -> Checkout
 -> Python 설치
 -> 의존성 설치
 -> pytest
 -> 결과/Artifact 확인

GitOps with Argo CD

App repo push
 -> GitHub Actions
 -> Docker image build/push
 -> GitOps repo image tag update
 -> Argo CD Sync
 -> Kubernetes Pod 교체

AWS Native CI/CD

CodeCommit
 -> CodePipeline
 -> CodeBuild
 -> S3 Artifact
 -> CodeDeploy
 -> EC2

16. 실습형 문항에서 자주 나오는 함정

CD에서 Delivery와 Deployment를 혼동하지 말 것
Artifact를 만들지 않으면 같은 결과물을 환경 승격하기 어려움
테스트 없는 파이프라인은 단순 자동 빌드에 가까움
Jenkins Controller에서 무거운 빌드를 모두 돌리면 과부하 위험
Jenkinsfile이나 Workflow에 비밀번호를 직접 쓰면 안 됨
GitHub Actions에서 Job은 기본 병렬이므로 순서가 필요하면 needs 사용
uses는 Action 재사용, run은 명령 실행
GitOps는 Git으로 배포 명령을 실행하는 것이 아니라 Git을 운영 상태 기준으로 삼는 것
Argo CD에서 Synced와 Healthy는 다름
Argo CD 실습에서 CI는 클러스터에 직접 배포하지 않고 GitOps 저장소를 수정함
CodeDeploy EC2 배포에는 CodeDeploy Agent가 필요
CodeDeploy 대상 EC2는 태그와 Deployment Group 조건이 맞아야 함
buildspec.yml은 CodeBuild용, appspec.yml은 CodeDeploy용
ValidateService가 실패하면 파일 복사가 되어도 배포 실패로 판단될 수 있음

17. 핵심 포인트

DevOps는 도구가 아니라 협업과 자동화 중심의 운영 문화
CI는 지속적 통합, CD는 지속적 제공/배포
파이프라인은 품질 게이트를 포함한 자동화 흐름
Artifact는 재현성과 환경 승격의 핵심
Jenkins는 Controller/Agent 구조
Jenkins Pipeline은 Jenkinsfile로 코드화
GitHub Actions는 Workflow/Job/Step/Runner 구조
GitHub Actions Workflow는 .github/workflows 아래 YAML로 정의
GitOps는 Git을 운영 상태의 단일 기준으로 삼음
Push 배포와 Pull 기반 GitOps 차이를 이해해야 함
Argo CD는 Git과 Kubernetes 실제 상태를 비교하고 동기화
Argo CD의 Sync Status와 Health Status는 다름
AWS 네이티브 CI/CD는 CodeCommit, CodeBuild, CodeDeploy, CodePipeline 조합
CodePipeline은 전체 오케스트레이션, CodeBuild는 빌드, CodeDeploy는 배포
배포 완료는 파일 복사가 아니라 정상 서비스 검증까지 포함

18. 한 줄 요약

CI/CD의 핵심은 소스 변경을 검증 가능한 Artifact로 만들고, 통제된 방식으로 배포하며, 운영 상태를 지속적으로 확인하고 되돌릴 수 있게 만드는 자동화 흐름이다.

우유

Front-end Developer, Cloud Engineer

이전 포스트

[CI/CD] DevOps CI/CD 정리

[Cloud] CI/CD

CI/CD 통합 정리

1. DevOps와 CI/CD 기본 개념

DevOps란

전통적 개발/운영 방식의 한계

DevOps의 핵심 요소

CI

CD

2. CI/CD 파이프라인 구조

파이프라인이란

Source 단계

Build 단계

Test 단계

Quality Gate

Package / Artifact

Publish 단계

Deploy 단계

Verify 단계

실패 처리 원칙

Deploy와 Release 구분

3. Jenkins 아키텍처

Jenkins란

Jenkins의 위치

Jenkins 특징

Controller / Agent 구조

Workspace와 Executor

Jenkins Job 유형

Jenkins의 장점

Jenkins의 한계

4. Jenkins Pipeline과 Jenkinsfile

Jenkins Pipeline

Pipeline as Code

Jenkinsfile

Declarative vs Scripted Pipeline

Declarative Pipeline 기본 구조

주요 구성요소

Stage 설계 원칙

5. Jenkins CI Pipeline 실습 핵심

실습 핵심 포인트

Docker 기반 CI 결과물

Jenkins Credentials

GitHub Webhook

자주 발생하는 오류

6. GitHub Actions 개념

GitHub Actions란

기본 구성요소

Workflow 파일 위치

Runner

이벤트 기반 구조

GitHub Actions 장점

한계

7. GitHub Actions Workflow 문법

기본 골격

주요 요소

uses와 run 차이

자주 쓰는 요소

Job 실행 관계

변수와 Secret

8. GitHub Actions 실습 핵심

Python CI 흐름

Artifact 업로드

브랜치별 분기

EC2 자동 배포

9. Jenkins와 GitHub Actions 비교

Jenkins가 유리한 경우

GitHub Actions가 유리한 경우

10. GitOps 개념

GitOps란

GitOps에서 Git이 저장하는 것

핵심 철학

Push 방식 vs Pull 방식

기존 Push 기반 CD

GitOps Pull 기반

GitOps는 CI를 대체하지 않음

11. Argo CD

Argo CD란

Argo CD 기본 흐름

핵심 개념

Sync Status와 Health Status

`uses`와 `run` 차이