DevOps 개요: 문화부터 도구 체인까지
1. DevOps란 무엇인가
DevOps는 **Development(개발)**과 **Operations(운영)**의 합성어로, 소프트웨어 개발과 IT 운영 간의 벽을 허물고 협업을 통해 더 빠르고 안정적으로 소프트웨어를 전달하는 문화이자 방법론이다.
전통적인 소프트웨어 개발에서는 개발팀과 운영팀이 분리되어 있었다:
┌─────────────────────────────────────────────────────┐
│ 전통적 개발-운영 구조 │
│ │
│ 개발팀 (Dev) │ 운영팀 (Ops) │
│ ┌──────────────┐ │ ┌──────────────┐ │
│ │ 코드 작성 │ │ │ 서버 관리 │ │
│ │ 기능 개발 │ ──▶ │ ──▶ │ 배포 수행 │ │
│ │ 버그 수정 │ 벽 │ 벽 │ 모니터링 │ │
│ └──────────────┘ │ └──────────────┘ │
│ "빠르게 변경하자" │ "안정성이 최우선" │
└─────────────────────────────────────────────────────┘
이 구조에서는 개발팀은 빠른 변경을, 운영팀은 안정성을 추구하면서 자연스럽게 충돌이 발생했다. DevOps는 이 갈등을 공동의 목표와 자동화된 프로세스로 해결한다.
┌─────────────────────────────────────────────────────┐
│ DevOps 문화 │
│ │
│ ┌─────────────────────────┐ │
│ │ 공동 책임 & 협업 │ │
│ │ ┌─────┐ ┌─────┐ │ │
│ │ │ Dev │◀─▶│ Ops │ │ │
│ │ └─────┘ └─────┘ │ │
│ │ 자동화 파이프라인 │ │
│ │ 지속적 피드백 루프 │ │
│ └─────────────────────────┘ │
└─────────────────────────────────────────────────────┘
핵심은 도구가 아니라 문화라는 점이다. 아무리 좋은 CI/CD 파이프라인을 구축해도, 팀 간 협업 문화가 없으면 DevOps는 실패한다.
2. DevOps 핵심 원칙: CALMS
DevOps의 핵심 원칙은 CALMS 프레임워크로 요약할 수 있다:
| 원칙 | 설명 | 실천 예시 |
|---|---|---|
| Culture (문화) | 협업과 신뢰 기반의 조직 문화 | 비난 없는 포스트모템, 공유 온콜 |
| Automation (자동화) | 반복 작업의 자동화 | CI/CD, IaC, 자동 테스트 |
| Lean (린) | 낭비 제거, 작은 배치로 빠른 전달 | 작은 PR, 빈번한 릴리스 |
| Measurement (측정) | 데이터 기반 의사결정 | DORA 메트릭, SLI/SLO 추적 |
| Sharing (공유) | 지식과 책임의 공유 | 내부 기술 블로그, 런북 작성 |
특히 Measurement 영역에서는 DORA(DevOps Research and Assessment) 팀이 정의한 4가지 핵심 메트릭이 널리 사용된다:
- 배포 빈도 (Deployment Frequency): 얼마나 자주 프로덕션에 배포하는가
- 변경 리드 타임 (Lead Time for Changes): 커밋부터 배포까지 걸리는 시간
- 변경 실패율 (Change Failure Rate): 배포 후 장애가 발생하는 비율
- 복구 시간 (Time to Restore Service): 장애 발생 후 복구까지 걸리는 시간
3. DevOps 라이프사이클
DevOps 라이프사이클은 무한 루프(∞) 형태로, 개발과 운영이 끊임없이 순환한다:
Plan ──▶ Code ──▶ Build ──▶ Test
▲ │
│ ∞ DevOps ▼
│ Release
Monitor │
▲ ▼
Operate ◀── Deploy ◀────────────┘
각 단계별 핵심 활동:
| 단계 | 핵심 활동 | 대표 도구 |
|---|---|---|
| Plan | 요구사항 정의, 작업 분배 | Jira, Linear, GitHub Issues |
| Code | 소스코드 작성, 코드 리뷰 | Git, GitHub, GitLab |
| Build | 컴파일, 의존성 관리, 이미지 빌드 | Maven, Gradle, Docker |
| Test | 단위/통합/E2E 테스트 자동화 | Jest, pytest, Selenium |
| Release | 릴리스 승인, 버전 태깅 | GitHub Releases, Semantic Versioning |
| Deploy | 프로덕션 배포 | Kubernetes, ArgoCD, Ansible |
| Operate | 인프라 관리, 스케일링 | Terraform, Kubernetes |
| Monitor | 로그, 메트릭, 트레이스 수집 | Prometheus, Grafana, Datadog |
4. CI/CD 개념 정리
CI/CD는 DevOps의 핵심 실천 방법으로, 세 가지 개념으로 구분된다:
┌─────────────────────────────────────────────────────────────────┐
│ │
│ CI CD (Delivery) CD (Deployment) │
│ ┌───────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ 코드 커밋 │ │ 릴리스 준비 │ │ 자동 배포 │ │
│ │ ↓ │ │ ↓ │ │ ↓ │ │
│ │ 자동 빌드 │ ─▶│ 스테이징 배포 │ ─▶│ 프로덕션 배포 │ │
│ │ ↓ │ │ ↓ │ │ (자동) │ │
│ │ 자동 테스트 │ │ 수동 승인 대기 │ │ │ │
│ │ ↓ │ │ │ │ │ │
│ │ 코드 품질 검사 │ │ │ │ │ │
│ └───────────────┘ └────────────────┘ └────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
- CI (Continuous Integration): 개발자가 코드를 자주 통합하고, 매번 자동 빌드와 테스트를 수행
- CD (Continuous Delivery): CI를 통과한 코드를 언제든 배포 가능한 상태로 유지. 프로덕션 배포는 수동 승인 후 진행
- CD (Continuous Deployment): Delivery에서 한 단계 더 나아가, 모든 변경사항을 자동으로 프로덕션에 배포
5. DevOps 도구 체인 맵
카테고리별 대표적인 DevOps 도구:
| 카테고리 | 도구 | 특징 |
|---|---|---|
| 소스 관리 | Git, GitHub, GitLab | 분산 버전 관리 |
| CI/CD | GitHub Actions, Jenkins, GitLab CI, CircleCI | 파이프라인 자동화 |
| 컨테이너 | Docker, Podman | 애플리케이션 패키징 |
| 오케스트레이션 | Kubernetes, Docker Swarm | 컨테이너 관리 |
| IaC | Terraform, Ansible, Pulumi | 인프라 코드화 |
| 모니터링 | Prometheus, Grafana, Datadog | 메트릭 수집 및 시각화 |
| 로깅 | ELK Stack, Loki, Fluentd | 로그 수집 및 분석 |
| 보안 | Vault, Trivy, SonarQube | 시크릿 관리, 취약점 스캔 |
| 협업 | Slack, Microsoft Teams, PagerDuty | 커뮤니케이션 및 알림 |
| 아티팩트 | Docker Hub, Harbor, Nexus | 이미지/패키지 저장소 |
6. DevOps vs SRE vs Platform Engineering
세 가지 접근 방식은 서로 보완적이지만, 초점이 다르다:
| 구분 | DevOps | SRE | Platform Engineering |
|---|---|---|---|
| 정의 | 개발-운영 협업 문화 | 소프트웨어 엔지니어링으로 운영 문제 해결 | 개발자를 위한 내부 플랫폼 구축 |
| 기원 | 2009년 DevOpsDays | Google (2003~) | DevOps + SRE 성숙 이후 |
| 핵심 초점 | 문화와 프로세스 | 신뢰성과 SLO | 개발자 경험(DX) |
| 주요 관심사 | CI/CD, 자동화 | 에러 버짓, 토일 제거 | 셀프서비스 플랫폼 |
| 측정 지표 | DORA 메트릭 | SLI/SLO/SLA | 플랫폼 채택률, 개발자 만족도 |
| 적합한 조직 | 대부분의 조직 | 대규모 서비스 운영 | 엔지니어링 조직 100명+ |
SRE는 DevOps의 구체적 구현체라고 볼 수 있다. Google의 VP Ben Treynor는 “SRE는 DevOps 인터페이스의 구현 클래스”라고 표현했다.
7. DevOps 도입 시 고려사항
조직 문화 준비
- 비난 없는 포스트모템 문화 정착이 선행되어야 한다
- 사일로를 허물고 크로스 펑셔널 팀 구성을 고려한다
- 경영진의 지원과 이해가 필수적이다
점진적 도입 전략
Phase 1: 버전 관리 + 코드 리뷰 정착
↓
Phase 2: CI 파이프라인 구축 (자동 빌드 + 테스트)
↓
Phase 3: CD 파이프라인 구축 (자동 배포)
↓
Phase 4: IaC 도입 + 모니터링 체계 구축
↓
Phase 5: 보안 자동화 (DevSecOps) + 최적화
흔한 실수
- 도구 먼저 도입: 문화 변화 없이 도구만 도입하면 효과가 제한적이다
- 한 번에 모든 것을 변경: 점진적 도입이 핵심이다
- 측정 없는 개선: “측정할 수 없으면 개선할 수 없다”
- 자동화 과잉: 모든 것을 자동화하기보다, ROI가 높은 것부터 시작한다
- 보안 후순위: 초기부터 보안을 파이프라인에 통합해야 한다 (Shift Left)
성공 지표
DevOps 도입의 성공 여부를 판단하려면 다음 지표를 추적한다:
- 배포 빈도가 증가하고 있는가?
- 변경 리드 타임이 단축되고 있는가?
- 장애 발생 빈도가 감소하고 있는가?
- 장애 복구 시간이 단축되고 있는가?
- 개발자 만족도가 향상되고 있는가?
마무리
DevOps는 단순한 도구의 집합이 아니라, 사람과 프로세스, 도구가 조화를 이루는 문화다. 기술적 역량만큼이나 소통과 협업 능력이 중요하며, 조직의 성숙도에 맞는 점진적 도입이 성공의 열쇠다.
다음 글에서는 DevOps의 핵심 도구 중 하나인 GitHub Actions를 활용한 실전 CI/CD 파이프라인 구축 방법을 다룰 예정이다.