DevOps를 처음 시작하는 분을 위한 출발점입니다. DevOps가 도구가 아니라 문화이자 방법론인 이유, 코드가 운영 환경에 도달하기까지의 전체 흐름, Linux·Docker·CI/CD·Kubernetes·모니터링으로 이어지는 기술 지도, 그리고 단계별 학습 로드맵과 실습 플랜을 정리합니다.
DevOps를 처음 시작하는 분을 위한 출발점입니다. DevOps가 도구가 아니라 문화이자 방법론인 이유, 코드가 운영 환경에 도달하기까지의 전체 흐름, Linux·Docker·CI/CD·Kubernetes·모니터링으로 이어지는 기술 지도, 그리고 단계별 학습 로드맵과 실습 플랜을 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
설치 명령을 외우기보다 트래픽, 런타임, 관측, 장애 대응이 어떤 순서로 이어지는지 파악합니다.
글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 DevOps 입문 & 로드맵를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.
DevOps 입문 & 로드맵를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.
| 구분 | 전통적 방식 | DevOps 방식 |
|---|---|---|
| 배포 주기 | 수 주~수 개월에 한 번 | 하루에도 여러 번 |
| 배포 방법 | 사람이 수동으로 서버 접속 | 파이프라인 자동화 |
| 인프라 | 서버를 손으로 설정 (눈송이 서버) | 코드로 정의 (IaC) |
| 장애 대응 | 사용자 신고로 인지 | 모니터링·알림으로 먼저 인지 |
| 책임 | 개발/운영 분리 | 만든 팀이 운영까지 (You build it, you run it) |
코드가 운영 환경에 닿기까지은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 단계 | 무슨 일 | 대표 도구 | 가이드 |
|---|---|---|---|
| 1. 코드 (Code) | 기능 개발, 코드 리뷰 | Git, GitHub | - |
| 2. 빌드 (Build) | 컴파일, 의존성 설치, 이미지 생성 | Docker, Gradle, npm | Docker |
| 3. 테스트 (Test) | 단위·통합 테스트, 보안 스캔 | GitHub Actions, Jenkins | CI/CD |
| 4. 배포 (Release/Deploy) | 스테이징 → 운영 반영 | Argo CD, Helm | CI/CD, K8s 심화 |
| 5. 운영 (Operate) | 컨테이너 실행, 확장, 자가 치유 | Kubernetes | Kubernetes |
| 6. 관측 (Monitor) | 메트릭, 로그, 알림, 대시보드 | Prometheus, Grafana | Prometheus, Grafana |
| 7. 피드백 | 장애 회고, 개선 사항을 다시 코드로 | 포스트모템 | - |
DevOps 기술 지도: 쌓아 올리는 순서은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 층 | 기술 | 왜 필요한가 | 가이드 |
|---|---|---|---|
| 기반 | Linux, 셸, 네트워크 기초 | 모든 서버와 컨테이너는 Linux 위에서 동작 | Linux |
| 패키징 | Docker, 컨테이너 이미지 | "내 PC에서는 되는데" 문제 해결 | Docker |
| 자동화 | CI/CD, IaC(Terraform, Ansible) | 사람의 실수 제거, 반복 가능한 배포 | CI/CD |
| 오케스트레이션 | Kubernetes, Helm | 수많은 컨테이너의 배치·확장·복구 | Kubernetes, K8s 심화/실무 |
| 관측성 | Prometheus, Grafana, 로그 수집 | 시스템 상태를 숫자로 파악 | Prometheus, Grafana |
| 인프라 | 클라우드, 로드밸런서, 캐시 | 서비스가 실행되는 토대 | 클라우드 로드맵, 인프라 로드맵 |
컨테이너가 바꾼 것은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 구분 | 가상 머신 (VM) | 컨테이너 |
|---|---|---|
| 격리 단위 | OS 전체 (게스트 OS 포함) | 프로세스 (호스트 커널 공유) |
| 크기 | 수 GB | 수십~수백 MB |
| 시작 시간 | 수십 초~분 | 1초 내외 |
| 밀도 | 서버당 수십 개 | 서버당 수백 개 |
| 주 용도 | 강한 격리, 다른 OS 실행 | 마이크로서비스, CI/CD, 빠른 확장 |
여기서는 첫 파이프라인: push하면 테스트하고 이미지 빌드을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
test-and-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: 의존성 설치 & 테스트
run: |
pip install -r requirements.txt
pytest -q
- name: Docker 이미지 빌드
run: docker build -t myapp:latest .DevOps 성과 지표: DORA 4대 지표은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 지표 | 의미 | 좋은 팀의 모습 |
|---|---|---|
| 배포 빈도 | 운영 환경에 얼마나 자주 배포하나 | 필요할 때마다 (하루 여러 번) |
| 변경 리드 타임 | 커밋부터 운영 반영까지 걸리는 시간 | 하루 이내 |
| 변경 실패율 | 배포 중 장애·롤백으로 이어진 비율 | 낮게 유지 (예: 15% 이하) |
| 복구 시간 | 장애 발생부터 복구까지 걸리는 시간 | 1시간 이내 |
DevOps · SRE · 플랫폼 엔지니어은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 직무 | 초점 | 주요 업무 |
|---|---|---|
| DevOps 엔지니어 | 배포 자동화와 개발 생산성 | CI/CD 구축, 컨테이너화, IaC |
| SRE (Site Reliability Engineer) | 서비스 신뢰성 | SLO 설정, 모니터링, 장애 대응, 용량 계획 |
| 플랫폼 엔지니어 | 내부 개발자 플랫폼 | Kubernetes 플랫폼, 셀프서비스 배포 도구 |
| 클라우드 엔지니어 | 클라우드 인프라 설계·운영 | 네트워크, 보안, 비용 최적화 |
| MLOps / LLMOps | AI 모델 배포·운영 | 모델 서빙, GPU 인프라, 품질 모니터링 (LLMOps) |
시작 전 준비물은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 영역 | 무엇을 | 어느 정도 |
|---|---|---|
| Linux 명령어 | 파일, 권한, 프로세스, 패키지, 로그 | 필수 — 가장 먼저 |
| 네트워크 기초 | IP, 포트, DNS, HTTP, TLS | "왜 연결이 안 되지?"를 추적할 수 있는 수준 |
| 스크립팅 | Bash, Python 중 하나 | 반복 작업 자동화 스크립트 작성 |
| Git | branch, merge, PR, 태그 | 필수 |
| 애플리케이션 1개 | 간단한 웹 앱을 직접 만들 수 있음 | 배포할 대상이 있어야 실습 가능 |
| YAML | 들여쓰기, 리스트, 맵 | CI 설정·Kubernetes 매니페스트 작성 |
단계별 로드맵: Linux부터 Kubernetes 운영까지은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 단계 | 목표 | 학습 내용 | 가이드 | 완료 체크 |
|---|---|---|---|---|
| 0. Linux | 서버 다루기 | 셸, 파일·권한, 프로세스, systemd, SSH, 네트워크 명령 | Linux | 원격 서버에 웹 서버 설치·운영 |
| 1. Docker | 애플리케이션 컨테이너화 | 이미지, Dockerfile, 볼륨, 네트워크, Compose | Docker | 앱+DB를 compose로 실행 |
| 2. CI/CD | 배포 자동화 | 파이프라인, 테스트 자동화, 이미지 레지스트리, IaC 기초 | CI/CD | push → 테스트 → 이미지 푸시 |
| 3. Kubernetes 기본 | 컨테이너 오케스트레이션 | Pod, Deployment, Service, ConfigMap, Ingress | Kubernetes 기본 | 로컬 클러스터에 앱 배포 |
| 4. Kubernetes 실무 | 운영 수준 클러스터 | Helm, 오토스케일링, 리소스 관리, 보안, GitOps | K8s 심화/실무 | Helm 차트 + 무중단 배포 |
| 5. 관측성 | 상태를 숫자로 | 메트릭 수집, PromQL, 알림 규칙, 대시보드 | Prometheus, Grafana | 에러율·지연 알림 대시보드 |
| 6. 클라우드 | 실제 운영 환경 | 관리형 Kubernetes, 네트워크, IAM, 비용 | AWS, 클라우드 로드맵 | 클라우드에 전체 파이프라인 구성 |
| 7. 신뢰성 | 장애에 강한 시스템 | SLO, 장애 대응 절차, 부하 테스트, 포스트모템 | k6 | 부하 테스트 + 장애 회고 문서 |
12주 학습 플랜: 하루 1~2시간 기준은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 주차 | 주제 | 결과물 |
|---|---|---|
| 1~2주 | Linux 명령어·권한·프로세스·네트워크 | 서버 초기 설정 스크립트 |
| 3주 | Docker 이미지와 Dockerfile | 내 앱의 경량 이미지 (멀티 스테이지) |
| 4주 | Docker Compose | 앱+DB+캐시 로컬 환경 |
| 5~6주 | CI/CD 파이프라인 | GitHub Actions: 테스트 → 빌드 → 레지스트리 푸시 |
| 7~8주 | Kubernetes 기본 리소스 | kind 클러스터에 앱 배포 + Ingress |
| 9주 | Helm + GitOps | Helm 차트 + Argo CD 자동 동기화 |
| 10주 | Prometheus + Grafana | 서비스 대시보드 + 알림 규칙 |
| 11주 | 클라우드 배포 | 관리형 Kubernetes에 동일 구성 재현 |
| 12주 | 부하 테스트 + 회고 | k6 부하 테스트 리포트 + 아키텍처 문서 |
DevOps 입문자가 자주 하는 실수은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 실수 | 문제 | 대신 이렇게 |
|---|---|---|
| Linux 없이 Kubernetes부터 | 장애 원인을 전혀 추적 못함 | Linux → Docker → K8s 순서 지키기 |
| latest 태그로 배포 | 어떤 버전이 떠 있는지 모름, 롤백 불가 | 커밋 SHA·버전 태그 사용 |
| 비밀번호를 이미지·저장소에 포함 | 유출 위험 | Secret 관리 도구, CI 시크릿 |
| 리소스 요청·제한 미설정 | 한 컨테이너가 노드 전체 자원 독점 | requests/limits 설정 |
| 헬스체크 없음 | 죽은 컨테이너로 트래픽 전달 | liveness/readiness probe 설정 |
| 모니터링 없이 운영 | 사용자 신고로 장애 인지 | 배포와 동시에 대시보드·알림 구성 |
| 수동으로 서버 설정 변경 | 재현 불가능한 환경 | IaC로 모든 변경을 코드화 |
핵심 용어 사전은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 용어 | 한 줄 설명 |
|---|---|
| CI (지속적 통합) | 코드 변경마다 자동으로 빌드·테스트하는 방식 |
| CD (지속적 배포/전달) | 검증된 변경을 자동으로 운영 환경까지 배포하는 방식 |
| IaC | 서버·네트워크 등 인프라를 코드로 정의하고 관리하는 방식 |
| GitOps | Git 저장소를 인프라·배포 상태의 유일한 기준으로 삼는 운영 방식 |
| 이미지 레지스트리 | 컨테이너 이미지를 저장·배포하는 저장소 (Docker Hub, ECR 등) |
| 블루-그린 / 카나리 배포 | 새 버전을 병렬로 띄우거나 일부 트래픽에만 먼저 적용하는 무중단 배포 방식 |
| SLI / SLO | 서비스 품질 지표 / 그 지표의 목표치 (예: 가용성 99.9%) |
| 오토스케일링 | 부하에 따라 인스턴스·Pod 수를 자동 조절하는 기능 |
| 포스트모템 | 장애 후 비난 없이 원인과 개선책을 정리하는 회고 문서 |
| 관측성 (Observability) | 메트릭·로그·트레이스로 시스템 내부 상태를 파악하는 능력 |