CI/CD, DevOps

✅ CI/CD

 

🔸 개념

• CI(Continuous Integration, 지속적 통합)
  개발자가 여러 명일 때 각자의 코드를 자주(예: 하루에도 여러 번) 메인 브랜치에 병합하여 통합하는 과정입니다.
  코드 병합 시 자동으로 빌드, 테스트가 진행되어 코드 품질과 충돌 문제를 조기에 발견할 수 있습니다.
• CD(Continuous Deployment, 지속적 배포)
  CI 이후에 빌드된 결과물을 실제 서비스 환경(또는 스테이징 환경)에 자동으로 배포하는 과정입니다.
  • Continuous Delivery: 수동 승인 후 배포 (자동화된 배포 준비 상태)
  • Continuous Deployment: 승인 없이 자동으로 바로 배포

 

🔸 CI/CD 도구 및 사용 방법

• 대표 도구
  • GitLab CI/CD (GitLab 내장)
  • Jenkins
  • GitHub Actions
  • CircleCI
  • ArgoCD (특히 Kubernetes 환경에서 GitOps 방식으로 배포 자동화)

 

🔸  CI/CD 배포 자동화 절차 및 방법

(1) 코드 커밋 및 푸시

• 개발자가 Git 저장소(예: GitLab)에 코드를 커밋하고 푸시한다.

(2) CI 파이프라인 실행 (빌드 및 테스트)

• GitLab CI가 자동으로 트리거되어 파이프라인이 실행된다.
• 소스코드 빌드 → 단위 테스트 및 통합 테스트 자동 수행 → 결과 보고
• 테스트 성공 시 아티팩트(빌드 결과물)를 생성한다.

(3) CD 파이프라인 실행 (배포 준비 및 배포)

• 빌드된 아티팩트를 테스트 환경에 배포한다 (자동화 가능).
• ArgoCD를 이용해 Kubernetes 클러스터에 배포를 자동화
• GitOps 방식으로 Git 저장소에 배포 명세(Manifest)를 반영하면 ArgoCD가 자동으로 클러스터에 적용한다.

(4) 배포 완료 후 모니터링 및 알림

• 배포 성공/실패 여부를 개발팀에 알린다.
• 장애 발생 시 롤백 절차를 준비한다.

 

코드 통합	코드 병합 및 자동 빌드/테스트	GitLab CI, Jenkins, GitHub Actions
테스트	자동 단위 및 통합 테스트 수행	JUnit, Selenium 등
아티팩트 생성	배포 가능한 빌드 결과물 생성	Docker 이미지, JAR 파일 등
배포 자동화	테스트 및 운영 환경에 자동 배포	ArgoCD, Helm, Kubernetes
모니터링 및 알림	배포 상태 확인, 실패 시 롤백 및 알림	Prometheus, Grafana, Slack 알림

 

 

 

---

✅ 쿠버네티스(Kubernetes)

 

🔸 개념

• 여러 서버(노드) 위에 여러 컨테이너(작고 독립된 실행 환경)를 자동으로 배포·관리하는 오케스트레이션 시스템
• 컨테이너의 상태를 계속 감시하고, 문제가 생기면 자동 복구, 부하 분산, 확장 등을 수행
  여러 대의 서버(노드)에 배포된 컨테이너 애플리케이션을 ▶️자동으로 배포, 확장, 복구, 스케일링해 주는 오픈소스 시스템입니다.
• 주요 개념
  • Pod: 하나 이상의 컨테이너 그룹.
  • Node: 쿠버네티스 에이전트가 설치된 VM 혹은 물리 서버.
  • Cluster: 여러 Node가 모여 구성된 하나의 쿠버네티스 클러스터.
  • Deployment: 선언된 상태(몇 개의 Pod를 몇 버전으로) 유지하도록 관리하는 리소스.
  • Service: Pod들에 대한 로드밸런싱·내부 통신 추상화.
• 장점
  • 컨테이너 헬스체크 및 자동 복구
  • 트래픽에 따라 자동으로 스케일 아웃/인
  • 선언형으로 관리

🔸 목적

• 금융 서비스는 24시간 안정성·가용성이 매우 중요해 수동 관리 불가
• MSA(마이크로서비스) 아키텍처가 확산되며 서비스가 작고 많아져 이를 수동으로 관리하기 어려움
• 쿠버네티스가 자동으로 배포와 관리를 해줘 다운타임 최소화, 신속한 장애 복구가 가능함

🔸 사용 

• 개발자는 Docker로 애플리케이션을 컨테이너화
• 쿠버네티스 클러스터에 컨테이너 실행 명령(매니페스트)을 작성(배포 파일)
• 쿠버네티스가 노드에 컨테이너 배포, 상태 유지, 확장 등 수행

🔸 주의할 점

• 클러스터 및 네트워크 보안 관리 필수 (금융정보라 엄격)
• 리소스(메모리, CPU) 관리와 비용 최적화 필요
• 컨테이너 이미지 취약점 검사 및 업데이트 체계 필요

 

---

✅ GitOps

 

🔸 개념

• 운영(Ops)을 Git 중심으로 수행하는 방법론
  • 운영 환경(스테이징·프로덕션)의 “원하는 최종 상태(매니페스트)”를 Git 저장소에 선언해 두고
  • 자동화 도구(예: ArgoCD)가 Git에 정의된 상태와 실제 클러스터 상태를 계속 비교하여
  • Git 기준으로 자동으로 동기화(sync)·배포·롤백까지 수행
  • Git 저장소를 인프라 및 배포 설정의 단일 ‘진실 소스’로 삼아 운영 자동화하는 방법론
  • 모든 환경 설정을 Git 코드로 관리하고, Git 변경 시 자동으로 시스템에 반영
• 특징
  1. Git을 단일 소스 오브 트루스(Source of Truth) 로 사용
  2. 모든 배포 이력·설정 변경은 Git 커밋을 통해 이뤄짐
  3. 변경 내역은 Git 로그로 완벽히 감사(audit) 가능
  4. 수동 개입 없이 Git만 변경하면 자동으로 배포

🔸 목적

• 금융권은 변경 관리와 감사(audit) 요구가 엄격
• GitOps는 모든 변경 사항이 Git에 기록되어 감사·추적이 쉬움
• 자동화로 인적 오류 최소화, 배포 안정성 증가

🔸 사용

• 인프라 설정과 배포 매니페스트를 Git에 저장
• GitOps 도구(ArgoCD 등)가 Git 변경 감지 → 자동 배포 실행
• 실패 시 자동 롤백 가능

🔸 주의할 점

• Git 권한 관리 강화 필요 (누가 변경 가능한지 엄격 관리)
• 환경 간 차이(개발/운영) 관리 방법 명확히 해야 함
• 자동 배포가 실수로 문제 환경에 바로 반영되지 않도록 적절한 승인 프로세스 구성 필요

🔸 Git vs. GitOps

역할	분산 버전 관리 시스템, 코드·파일의 변경 이력 관리	Git을 “운영 환경 선언·자동 동기화”에 적용한 운영 방법론
사용 목적	소스코드, 문서, 설정 파일 등 파일 버전 관리	쿠버네티스 클러스터 상태 관리 및 배포 파이프라인 자동화
“배포” 트리거	사람(개발자)이 직접 명령어로 푸시/머지 후 수동 배포 필요	Git 커밋 하나로 자동화된 도구(ArgoCD 등)가 즉시·반복적으로 배포 실행

• Git: 단순히 파일의 버전 관리
• GitOps: “Git 안에 선언된 상태”를 자동으로 운영 환경에 반영하는 프로세스

1.  

---

✅  ArgoCD

 

🔸 개념

• Kubernetes 환경에서 GitOps 방식을 구현하는 오픈소스 툴
• Git 저장소에 저장된 배포 매니페스트를 지속적으로 감시, 변경 시 자동 동기화하여 배포

🔸 목적

• 금융 시스템은 복잡한 규제와 안정성 요구가 높아 자동화 필요
• ArgoCD는 배포 변경 이력 추적, 실시간 상태 모니터링, 롤백 지원 등 금융 서비스 운영에 최적

🔸 사용

• 쿠버네티스 클러스터에 ArgoCD 설치
• Git 저장소와 연동, 배포 매니페스트 경로 지정
• Git 변경 시 ArgoCD가 자동으로 배포를 적용하고 상태를 웹 대시보드로 보여줌

🔸 주의할 점

• ArgoCD 접근 권한과 인증 체계 철저히 설정
• Git 저장소와 쿠버네티스 간 네트워크 보안 확보
• 대규모 환경에서는 성능과 확장성 테스트 필수

🔸 Kibana vs ArgoCD 차이

기능	- 로그 시각화 및 검색 - WAS 로그, 시스템 로그 조회 - 실시간 모니터링 가능	- Kubernetes 배포 자동화 - GitOps 기반으로 배포 상태 확인 - 롤백, 배포 이력 관리
목적	- 장애 원인 찾기 - Exception, Stack Trace 조회 - 성능 문제, 에러 탐색	- 배포 상태 관리 - 배포 성공/실패 - 롤백, Git 상태 동기화
어디서 사용?	- 운영 중인 서비스의 상태 확인	- 애플리케이션을 Kubernetes에 배포하고 관리
예시 상황	- 서비스 응답 오류 발생 → Kibana에서 /api/v1/user 관련 Exception 조회	- 배포 중 장애 발생 → ArgoCD에서 배포 실패 여부 확인 및 롤백 수행

 

• ArgoCD = 배포 상태 확인 도구 (CI/CD)
• Kibana = 운영 중인 서버/애플리케이션의 로그 확인 도구

🔥 ArgoCD 배포 방식 흐름

1. Git 저장소에 Kubernetes 배포 YAML 작성 (deployment.yaml, service.yaml 등)
2. Git에 코드 푸시 → ArgoCD가 Git 변경 감지
3. ArgoCD가 Kubernetes 클러스터에 자동 배포
4. 상태 불일치 발생 시 자동 복구 또는 롤백

 

 

운영 중 장애 발생 시, Kibana에서 로그를 먼저 확인해 API 단의 에러 로그나 Stack Trace를 파악하고, 필요 시 Whatap APM으로 트랜잭션 호름을 확인합니다. 배포와 관련된 문제라면 ArgoCD에서 배포 상태를 확인하고, 필요 시 롤백까지 진행합니다.

 

 

 

✅ 자동 배포 파이프라인 (DevOps)

 

🔸 개념

• 개발(Dev)과 운영(Ops)을 통합해, 개발 → 테스트 → 배포 → 운영까지 자동화하는 프로세스.
• 사람의 개입 없이 CI/CD 도구를 통해 품질 높은 배포를 반복 가능하게 함.

 

🔸 기존 방식 vs 자동화 방식

수동 배포 → 오류 많음	자동 배포 → 오류 감소
테스트 생략 또는 수동	테스트 자동화 → 품질 보장
배포 속도 느림	빠른 배포, 롤백 가능
환경 별 설정 오류 발생	동일한 인프라 구성 (IaC)
장애 발생 시 수동 복구	모니터링 + 자동 롤백

 

→ 특히 금융권은 안정성, 무중단 배포, 감사 로그, 보안이 필수이기 때문에 더 강력하게 필요함.

---

🔸 자동 배포 파이프라인 절차

개발 → 빌드 → 테스트 → 배포 → 모니터링

소스 관리	코드 버전 관리	Git, GitLab, GitHub
CI (빌드)	코드 변경 시 자동으로 빌드 + 테스트 수행	Jenkins, GitLab CI, GitHub Actions
테스트	유닛 테스트, 통합 테스트, 보안 테스트	JUnit, Selenium, SonarQube
이미지화	컨테이너 이미지로 변환	Docker
저장소 등록	이미지 레지스트리에 저장	Harbor, Docker Hub, AWS ECR
CD (배포)	스테이징/운영 환경으로 자동 배포	ArgoCD (GitOps), Flux, Spinnaker
운영/모니터링	상태 모니터링, 장애 감지	Prometheus, Grafana, ELK, Sentry

 

🔸 주의할 점

1. 보안 강화
   • CI/CD 파이프라인 접근 권한 관리
   • 민감 정보는 Vault, Sealed Secrets로 암호화
2. 인증·승인 절차
   • 금융권 특성상 자동 배포 전에 승인 프로세스 필수
3. 감사 로그 및 변경 이력
   • 배포 이력, 변경 이력을 로그로 남겨야 함 (컴플라이언스 대응)
4. 장애 대응 전략
   • Canary 배포, Blue-Green 배포로 단계적 배포
   • ArgoCD Rollback 기능 활용

 

 

"DevOps 파이프라인은 단순히 자동 배포를 넘어서, 개발 → 테스트 → 배포까지 전 과정을 자동화하는 체계입니다. 저는 GitLab CI/CD와 ArgoCD를 활용해, 개발 브랜치에서 코드가 푸시되면 자동으로 Docker 이미지를 빌드하고, 이를 Kubernetes 클러스터에 배포하는 GitOps 방식을 경험했습니다. 금융권에서는 안정성이 중요하기 때문에 Canary 배포, 인증 승인 절차, 감사 로그 기록 같은 보안 요소까지 고려하여 설계합니다."

 

 

 

🔥 SI 개발 + 운영 = DevOps인가?

기능 개발 후 → 배포 담당자에게 전달	코드 작성 → 빌드 → 테스트 → 배포까지 모두 자동화
수동 배포, 운영자는 장애 대응만	인프라 코드화, 모니터링, 자동 롤백 포함
운영은 별도 부서가 담당	개발자와 운영자가 협업 (혹은 겸임)
배포 속도 느림	빠르고 안정적인 배포 가능

 

🔸 즉, SI에서 단순히 '개발'하고, 릴리즈 후 '운영'한다고 해서 그걸 DevOps라고 말하진 않습니다.

---

🔍 DevOps가 직무처럼 불리는 이유

• DevOps 엔지니어는 CI/CD 파이프라인 구축, 클라우드 인프라 자동화, 배포 자동화, 모니터링 환경 구축을 담당합니다.
• 그래서 DevOps는 실제 직무명으로도 쓰입니다. (예: DevOps 엔지니어 채용)

---

✅ DevOps = 인프라 + 자동화 + 소프트웨어 파이프라인 전문가

🔧 DevOps 주요 역할

• CI/CD 설계 및 구축
• Kubernetes, Docker 인프라 운영
• ArgoCD, Flux 같은 GitOps 도구 운용
• AWS, Azure, GCP 같은 클라우드 인프라 관리
• 모니터링, 장애 대응 자동화 (Prometheus, Grafana)

 

---

✅ Zero Downtime 배포 방법

✔️ 개념

• 서비스 중단 없이 배포하는 방식 (무중단 배포)
• 배포 중에도 사용자에게는 서비스가 정상적으로 제공됨.

 

✔️ 주요 방법

1. Blue-Green Deployment
   • 기존 서버(Blue) → 신규 서버(Green)로 스위치
   • 배포 실패 시 즉시 롤백 가능
2. Canary Deployment (카나리아 배포)
   • 트래픽의 일부만 신규 버전에 전달
   • 문제가 없으면 점진적으로 100% 전환
3. Rolling Deployment
   • 서버 하나씩 순차적으로 배포
4. Kubernetes 기반 무중단 배포
   • Deployment + Rolling Update 전략 사용

 

✔️ 금융권 실무 예시

• Web + WAS → 무중단 Rolling 배포 (Nginx Health Check)
• DB 변경 시 → Feature Toggle 전략 + 배포 전 이중 컬럼 생성
• 금융권 배치 → Rolling 배포
• 프론트엔드 → Vercel Canary 배포 적용
• 백엔드 API → Nginx + Health Check로 Rolling
• DB 변경 시 → 신규 컬럼 추가 후 점진적 이전

 

✔️ 적용 방식

🔹 배포 전략

• Blue-Green Deployment
  → 새 환경(Green) 배포 → 정상 확인 → 트래픽 전환
  → 실패 시 기존(Blue) 환경으로 롤백
• Canary Deployment
  → 전체의 5~10% 트래픽만 신규 버전에 전달 → 이상 없으면 점진적 전환
• Rolling Deployment
  → 서버 하나씩 순차적으로 배포
• Kubernetes Rolling Update
  → Pod 단위로 순차 배포, readiness probe 체크

🔹 DB 배포 방식

• Backward Compatible Schema 변경
  → 기존 테이블에 컬럼 추가 (DROP, RENAME 절대 금지)
  → 코드와 DB가 모두 이전 버전과 동작하도록 배포 설계