CI/CD·DevOps·IaC와 관측성
DevOps 피드백 흐름과 CI/CD 파이프라인, IaC·배포전략·관측성·SRE 핵심을 학습한다.
1. DevOps의 목적
DevOps는 개발·테스트·운영·보안이 빠르고 안전하게 가치를 전달하도록 협업·자동화·피드백·지속 개선을 강조한다.
Plan → Code → Build → Test → Release
▲ │
│ ▼
Learn ← Monitor ← Operate ← Deploy
특정 도구를 설치하는 것만으로 DevOps가 완성되는 것은 아니다. 작은 변경, 자동 검증, 공동 책임, 운영 피드백이 중요하다.
2. 지속적 통합(CI)
개발자가 변경을 자주 공유 저장소에 통합하고 자동 검증한다.
commit
↓
정적 분석
↓
컴파일·빌드
↓
단위 테스트
↓
패키징
↓
아티팩트 저장
CI의 목적:
- 통합 충돌 조기 발견
- 빌드 재현성
- 빠른 피드백
- 품질 기준 자동화
- 배포 가능한 아티팩트 생성
깨진 빌드를 오래 방치하면 팀 전체 피드백이 무너진다.
3. Continuous Delivery와 Deployment
| 구분 | 의미 |
|---|---|
| Continuous Delivery | 운영 배포 가능한 상태를 지속 유지, 운영 반영에 승인 가능 |
| Continuous Deployment | 검증을 통과한 변경을 운영까지 자동 배포 |
둘 다 자동 테스트·배포 준비가 필요하지만 운영 반영의 자동화 범위가 다르다.
4. 파이프라인 예시
Source
↓
Dependency·Secret Scan
↓
Build
↓
Unit Test
↓
Static Analysis
↓
Container Image Build
↓
Image·SBOM·Signature
↓
Test Environment Deploy
↓
Integration·Security Test
↓
Approval / Policy
↓
Production Deploy
↓
Smoke Test·Monitoring·Rollback
같은 아티팩트를 환경별로 다시 빌드하지 않고 검증된 아티팩트를 승격하면 재현성을 높일 수 있다.
5. 아티팩트와 버전
아티팩트는 빌드 결과물이다.
- 실행파일·JAR
- 컨테이너 이미지
- 패키지
- DB 마이그레이션
- 배포 템플릿
- SBOM·서명·검증 결과
Source Commit abc123
↓
Artifact app:1.4.2
↓
Dev → Test → Staging → Production
배포된 버전을 소스 커밋, 설정, DB 변경과 연결할 수 있어야 한다.
6. Infrastructure as Code
IaC는 서버·네트워크·권한·클라우드 자원을 코드와 버전관리로 정의·적용한다.
선언 코드
↓ review·test
자동 계획
↓ approval
자원 생성·변경
↓
실제 상태 검증
장점:
- 재현성
- 변경 이력
- 자동화
- 환경 일관성
- 리뷰와 정책 검사
주의:
- 상태파일과 자격증명 보호
- 파괴적 변경 검토
- 수동 변경으로 인한 드리프트
- 모듈·버전 의존성
- 환경별 비밀 분리
7. GitOps 개념
원하는 운영 상태를 Git 같은 선언 저장소에 기록하고 자동화된 조정기가 실제 환경을 맞춘다.
Git Desired State
│ 변경·리뷰
▼
Reconciler
│ 비교·적용
▼
Runtime Actual State
└─ 차이 발견 시 수정·경보
저장소 변경이 승인되었다고 애플리케이션 데이터까지 자동 안전한 것은 아니다. 스키마·업무 마이그레이션은 별도 설계가 필요하다.
8. 배포 전략과 검증
- Rolling
- Blue-Green
- Canary
- Feature Flag
- Shadow Traffic
배포 후 확인:
- 기동·헬스체크
- 오류율·응답시간
- 업무 성공률
- 자원 사용량
- 로그·트레이스
- DB·메시지 지연
- 사용자 피드백
Canary 5%
↓ SLO·오류·업무지표 정상?
├─ 아니오 → 즉시 중단·롤백
└─ 예 → 25% → 50% → 100%
9. 관측성
관측성은 외부 출력으로 시스템 내부 상태를 이해할 수 있는 능력이다.
Logs : 개별 사건과 상세 문맥
Metrics: 시간에 따른 수치·추세
Traces : 분산 요청 경로와 구간
세 신호를 trace ID·서비스·버전·환경으로 연결하면 원인 분석이 쉬워진다.
10. SLI·SLO·SLA
- SLI: 실제 측정 지표
- SLO: 목표 수준
- SLA: 고객과의 공식 약속·책임
예:
SLI: 성공 요청 수 / 전체 요청 수
SLO: 월 성공률 99.95%
SLA: 월 가용성 99.9%, 미달 시 보상
SLO는 기술팀의 운영 판단과 개선 우선순위를 지원한다.
11. 오류예산
오류예산은 SLO에서 허용한 실패량이다.
SLO 99.9%
허용 실패율 = 0.1%
오류예산이 충분하면 변경 속도를 높일 수 있고, 빠르게 소진되면 안정화·결함 개선을 우선할 수 있다.
오류예산은 장애를 일부러 내도 된다는 뜻이 아니라 신뢰성과 변경속도의 균형을 위한 의사결정 도구이다.
12. 자동화의 안전장치
- 코드리뷰
- 테스트와 정책 검사
- 최소권한 실행계정
- 승인·분리된 운영 접근
- 비밀관리
- 아티팩트 무결성·서명
- 공급망 의존성 점검
- 변경 윈도우
- 롤백·중단 버튼
- 감사로그
자동화는 잘못된 변경도 빠르게 확산할 수 있으므로 검증과 제한이 필요하다.
13. 신뢰 가능한 배포 아티팩트
Source commit → build once → test → SBOM·서명·provenance
→ registry → stage 승격 → production
환경마다 다시 빌드하지 않고 동일 digest의 불변 아티팩트를 승격한다. 의존성 버전 잠금, 최소 권한 CI runner, secret 격리, branch protection과 서명 검증으로 공급망 위험을 줄인다.
14. IaC state·drift와 GitOps
Terraform 같은 도구의 state는 실제 자원과 코드의 매핑·민감정보를 포함할 수 있어 원격 잠금·암호화·접근통제가 필요하다.
Git desired state → pull request/승인 → controller reconcile
▲ │
└──────── drift·health status ─────┘
GitOps는 Git에 커밋만 하면 끝나는 것이 아니라 controller가 실제 상태를 지속 비교·수렴시키며, 긴급 수동 변경도 다시 선언 상태에 반영해야 한다.
15. 관측성 신호와 상관관계
OpenTelemetry의 대표 신호는 traces, metrics, logs다.
- Trace: 요청 경로와 span 시간
- Metric: 집계 가능한 시계열
- Log: 개별 이벤트 문맥
exemplar·trace ID를 사용해 p99 지연 metric에서 느린 trace와 관련 log로 이동할 수 있다. 고카디널리티 사용자 ID를 metric label로 넣으면 비용과 성능이 악화될 수 있다.
16. SLO·오류예산 계산
30일 99.9% 가용성 목표의 단순 허용 실패 시간은 약 43.2분이다. 성공률 SLI가 99.8%라면 목표보다 0.1%p 낮고, 0.1% 오류예산 대비 0.2% 오류를 사용해 burn rate는 2다.
오류예산을 모두 소진하면 기능 배포를 늦추고 신뢰성 개선에 집중하는 정책을 둘 수 있다. SLA 위반과 내부 SLO 미달은 동일하지 않다.
17. DORA 5개 지표와 배포 안전장치
현재 DORA 모델은 소프트웨어 전달 성과를 다음처럼 나눈다.
처리량: 변경 리드타임 · 배포 빈도 · 실패 배포 복구시간
불안정성: 변경 실패율 · 배포 재작업률
여기서 실패 배포 복구시간은 일반 장애 전체의 MTTR가 아니라 배포로 서비스가 손상된 뒤 복구되는 시간이다. 배포 재작업률은 정상적인 제품 개발이 아니라 예상하지 못한 hotfix·rollback·수정 배포의 비중을 본다.
자동화 관문은 단위·통합·보안·성능·정책 검사를 포함하고, 카나리 지표·승인·롤백 조건을 코드화한다. 처리량 지표만 좋아지고 실패율·재작업률이 악화되면 DevOps 성과가 균형 있게 개선된 것이 아니다.
확인 문제
- build once, promote의 목적은?
- IaC state를 보호해야 하는 이유는?
- OpenTelemetry의 대표 세 신호는?
- 30일 99.9%의 단순 허용 실패시간은?
- 오류예산 소진 시 일반 정책은?