신입 DevOps 엔지니어 학습 순서: Linux·네트워크부터 CI/CD·Cloud까지

DevOps를 공부하려고 도구 목록부터 펼치면 AWS, Docker, Kubernetes, Terraform, Ansible, Jenkins가 한꺼번에 보인다. 하지만 신입 단계에서 중요한 것은 제품 이름을 많이 외우는 일이 아니다. 애플리케이션이 빌드되고 배포되어 사용자 요청을 처리하는 한 흐름을 직접 만들고, 실패했을 때 원인을 찾는 능력이 먼저다.

학습 순서도 그 흐름을 따라가면 덜 흔들린다. Linux와 네트워크를 바닥에 두고, Git과 작은 애플리케이션, CI/CD, 컨테이너, Cloud와 IaC, 관측 가능성 순으로 넓혀 간다.

1. Linux와 운영체제로 실행 환경을 이해한다

서버에서 가장 자주 마주치는 것은 셸, 파일, 프로세스, 권한과 로그다. 처음부터 커널 내부를 모두 파고들 필요는 없지만 다음 작업은 설명하고 직접 해볼 수 있어야 한다.

• 파일·디렉터리·심볼릭 링크와 권한 확인
• 표준 입력·출력·오류, pipe와 redirection 사용
• 프로세스·신호·foreground와 background 구분
• 패키지 설치와 systemd 서비스 상태 확인
• CPU·메모리·디스크·파일 디스크립터의 기본 관찰
• 로그에서 시간대와 오류 전후 맥락 확인

작은 웹 애플리케이션을 Linux에서 직접 실행하고, 서비스로 등록한 뒤 재시작과 로그 확인까지 해보면 개념이 연결된다.

2. 네트워크와 보안으로 요청 경로를 추적한다

클라우드 장애도 결국 DNS 조회, TCP 연결, TLS 협상, HTTP 요청 같은 경로에서 관찰된다. 다음 질문에 답할 수 있는 수준을 목표로 한다.

1. 도메인을 입력하면 어떤 DNS 질의를 거치는가?
2. IP와 포트는 각각 무엇을 식별하는가?
3. TCP 연결과 TLS 인증서는 어느 단계에서 확인되는가?
4. HTTP 상태 코드와 애플리케이션 오류는 어떻게 다른가?
5. 방화벽, 보안 그룹과 네트워크 ACL의 적용 범위는 무엇인가?

dig, curl -v, ss, traceroute 또는 tracepath, 패킷 캡처 도구로 한 요청을 따라가 본다. 보안은 별도 마지막 과목이 아니라, 최소 권한과 비밀 값 관리, 패치, 암호화 같은 기준을 모든 단계에 넣는다.

3. Git과 작은 애플리케이션으로 변경 단위를 만든다

운영 자동화도 결국 코드와 설정의 변경을 안전하게 전달하는 일이다. 브랜치 이름보다 먼저 다음 흐름을 익힌다.

작은 변경 → 로컬 테스트 → 커밋 → 코드 리뷰 → 병합 → 배포 가능한 산출물

애플리케이션을 전문 개발자 수준으로 만들 필요는 없지만, 빌드와 테스트, 환경 변수, 의존성, 데이터베이스 마이그레이션이 무엇인지 알아야 배포 파이프라인을 설계할 수 있다. 간단한 health endpoint와 자동 테스트가 있는 API 하나면 충분한 출발점이 된다.

4. CI/CD는 도구보다 피드백 흐름으로 배운다

CI 파이프라인에는 최소한 checkout, 의존성 설치, 정적 검사, 테스트, 빌드, 산출물 보관 단계를 넣는다. 같은 커밋에서 만든 산출물을 환경별로 다시 빌드하지 않고, 설정을 분리해 검증 환경과 운영 환경으로 전달하는 흐름을 연습한다.

Continuous delivery와 continuous deployment도 구분한다. 전자는 변경을 언제든 안전하게 배포할 수 있는 상태로 유지하는 능력이고, 후자는 통과한 변경을 자동으로 운영까지 배포하는 실천 방식이다. 자동화 버튼 하나만 만든다고 낮은 위험의 배포가 완성되는 것은 아니다. 테스트, 보안, 모니터링, 되돌리기와 팀의 작업 방식이 함께 있어야 한다.

Jenkins, GitHub Actions, GitLab CI 중 무엇을 선택하든 먼저 다음을 확인한다.

• 실패 원인을 로그만 보고 찾을 수 있는가?
• 같은 입력으로 같은 산출물을 다시 만들 수 있는가?
• 운영 배포에 승인과 감사 기록이 필요한가?
• 배포 실패를 감지하고 안전하게 중단하거나 되돌릴 수 있는가?

5. Docker 다음에 Kubernetes를 배운다

Docker에서는 이미지, 컨테이너, volume, network, registry의 관계를 먼저 익힌다. Dockerfile로 이미지를 만들고 root가 아닌 사용자로 실행하며, health check와 종료 신호가 제대로 동작하는지 확인한다.

그 다음 Kubernetes에서 Pod, Deployment, Service, ConfigMap, Secret, probe, request와 limit을 배운다. Kubernetes 공식 기본 과정도 애플리케이션 배포, 탐색, 공개, 확장, 업데이트 순으로 구성된다. YAML을 외우기보다 원하는 상태를 선언했을 때 controller가 실제 상태를 어떻게 맞추는지 관찰한다.

컨테이너 기본 구조는 Docker 이미지·컨테이너·VM 차이에서 먼저 정리할 수 있다.

6. Cloud와 IaC로 반복 가능한 환경을 만든다

AWS, Azure, GCP 가운데 하나를 골라 계정·권한, 가상 네트워크, compute, load balancer, object storage, managed database, 로그와 비용의 기본 흐름을 익힌다. 한 공급자를 깊게 다룬 뒤 공통 개념을 다른 공급자에 옮기는 편이 세 서비스를 얕게 훑는 것보다 효과적이다.

Terraform 같은 IaC 도구에서는 write → plan → apply 흐름을 이해한다. 선언 파일을 버전 관리하고 plan을 검토하며, state와 실제 인프라의 관계를 확인한다. 학습 계정에서도 비용 경보와 삭제 절차를 먼저 준비하고, 비밀 값과 state를 공개 저장소에 올리지 않는다.

Ansible 같은 구성 관리 도구는 서버 내부의 패키지와 설정을 반복 가능하게 만드는 데 쓸 수 있다. IaC와 구성 관리의 경계는 환경과 플랫폼에 따라 달라지므로 제품을 기준으로 나누기보다 “어떤 상태를 누가 책임지는가”로 구분한다.

7. 관측 가능성과 신뢰성으로 운영까지 닫는다

배포가 성공했다고 사용자가 정상적으로 서비스를 쓰는 것은 아니다. 로그, metric, trace를 모으는 목적은 대시보드를 꾸미는 것이 아니라 질문에 답하는 것이다.

• 사용자는 성공적으로 요청을 완료하는가?
• 오류율과 지연 시간은 배포 전후 어떻게 변했는가?
• 어느 구성 요소가 병목인가?
• 경보는 사람이 행동할 수 있는 신호인가?
• 장애 뒤에 같은 문제가 반복되지 않도록 무엇을 바꿨는가?

서비스 수준 지표와 목표, 알림, runbook, 장애 회고를 작은 프로젝트에도 적용해 본다. DevOps와 SRE의 역할 차이는 DevOps·SRE·플랫폼 엔지니어 구분에서 이어서 볼 수 있다.

한 프로젝트로 전체 흐름을 증명한다

과목마다 별도 예제를 만드는 것보다 하나의 작은 서비스를 점진적으로 운영 수준으로 올리는 편이 배운 내용을 연결하기 쉽다.

API와 테스트
  → Git 저장소와 코드 리뷰
  → CI 빌드와 이미지 생성
  → 컨테이너 registry
  → Cloud 또는 로컬 Kubernetes 배포
  → Terraform으로 기반 자원 선언
  → metric·로그·경보
  → 장애 시나리오와 복구 기록

각 단계에는 README, 아키텍처 그림, 선택 이유, 실패와 수정 기록을 남긴다. “Kubernetes를 공부했다”보다 “readiness probe가 없을 때 배포 중 어떤 실패가 났고 어떻게 확인했는지”가 더 강한 학습 증거다.

신입 DevOps 학습은 끝없는 도구 수집이 아니라 변경을 작게 만들고, 자동으로 검증하고, 반복 가능하게 배포하고, 사용자 관점에서 관찰하는 순환을 익히는 과정이다. 도구가 바뀌어도 이 순서는 남는다.

참고 자료

• DORA: Continuous delivery
• DORA: Monitoring and observability
• Kubernetes 공식 문서: Learn Kubernetes Basics
• HashiCorp Developer: What is Terraform?