01-step-0-0-인프라-관리의-전체-흐름-infrastructure-lifecycle.md ×

blog › posts › 01-step-0-0-인프라-관리의-전체-흐름-infrastructure-lifecycle.md

Step 00: 인프라 관리의 전체 흐름 (Infrastructure Lifecycle)

“도구는 바뀐다. 슬롯은 바뀌지 않는다. 슬롯을 보면 새 도구도 바로 이해된다.”

인프라 학습용으로 claude로 정리해둔 문서입니다

이것을 왜 배우는가?

처음 인프라를 공부하면 이런 혼란을 겪는다.

"Terraform? Ansible? 둘이 같은 거야 다른 거야?"
"K8s가 있으면 Docker Compose는 왜 있지?"
"ArgoCD? GitHub Actions랑 뭐가 달라?"
"Datadog, Prometheus, New Relic... 다 모니터링 같은데 뭐가 달라?"
"회사마다 쓰는 도구가 다른데, 이직하면 다 다시 배워야 해?"

이 혼란의 원인은 특정 도구를 먼저 배우고 전체 그림을 못 봤기 때문이다. 반대 순서로 가면 훨씬 쉽다.

핵심 통찰: 인프라 관리는 정해진 **생애주기(Lifecycle)**를 따른다. 각 단계에는 **해결해야 할 문제(= 슬롯)**가 있고, 도구는 그 슬롯을 채우는 “부품”일 뿐이다.

슬롯(자리) ≠ 도구(부품)

예:
 "Provisioning 슬롯" → Terraform / Pulumi / AWS CDK / Crossplane (부품이 여러 개)
   ※ Provision = "미리 준비해두다". 서버·네트워크 등 인프라를 미리 만들어두는 역할.

 "Observability 슬롯" → Prometheus+Grafana / Datadog / New Relic / Elastic (부품이 여러 개)
   ※ Observability = "관찰 가능성". 시스템 안에서 무슨 일이 일어나는지 바깥에서 볼 수 있게 하는 역할.

슬롯을 먼저 이해하면:

새로운 도구를 만났을 때 “이건 X 슬롯이구나” 하고 즉시 위치를 파악할 수 있다
회사마다 도구가 달라도 역할 기반으로 금방 적응한다
기술 비교 기사를 읽을 때 “A vs B” 가 의미 있는 비교인지 아닌지 판단할 수 있다

인프라의 전체 흐름 — 다이어그램

개발자가 코드를 작성한 순간부터 사용자가 그 코드를 실행하기까지, 그리고 그 이후의 운영까지 전 흐름을 본다.

┌──────────────────────────────────────────────────────────────┐
│                      [개발자 노트북]                            │
└──────────────────────────┬───────────────────────────────────┘
                           │
                           │ (1) git push
                           ▼
                  ┌──────────────────┐
                  │  Git 저장소       │  ← ①  Version Control 슬롯
                  │  (GitHub/GitLab) │
                  └────────┬─────────┘
                           │
                           │ (2) CI 트리거
                           ▼
                  ┌──────────────────┐
                  │  CI 파이프라인    │  ← ②  Build/Test 슬롯
                  │  (테스트·빌드)    │        + ⑫ Security Scan 슬롯
                  └────────┬─────────┘
                           │
                           │ (3) 이미지 빌드
                           ▼
                  ┌──────────────────┐
                  │ 아티팩트 저장소    │  ← ③  Artifact Storage 슬롯
                  │ (Docker Registry)│
                  └────────┬─────────┘
                           │
                           │ (4) 배포 트리거
                           ▼
                  ┌──────────────────┐
                  │  배포 도구        │  ← ④  Deploy/Release 슬롯
                  │  (ArgoCD 등)     │
                  └────────┬─────────┘
                           │
                           │ (5) 클러스터에 적용
                           ▼
┌───────────────────────────────────────────────────────────────┐
│                 [실행 환경 (클러스터)]                          │
│                                                                │
│   ┌──────────────────┐      ← ⑤  Orchestration 슬롯            │
│   │  오케스트레이터    │         (K8s/ECS/Nomad)                │
│   │  - Pod 스케줄링   │                                         │
│   │  - 자동 재시작    │                                         │
│   │  - 오토스케일링    │                                         │
│   └────────┬─────────┘                                         │
│            │                                                   │
│            ▼                                                   │
│   ┌────────────────────┐   ← ⑥ Provisioning 슬롯 (Terraform 등)│
│   │  인프라 리소스      │     이 "머신·네트워크·DB"를 만드는 게   │
│   │  (EC2/VPC/RDS)    │     Provisioning 슬롯                  │
│   └────────┬───────────┘                                       │
│            │                                                   │
│            ▼                                                   │
│   ┌────────────────────┐   ← ⑦ Configuration 슬롯 (Ansible 등) │
│   │  OS/패키지/설정     │     머신 안의 소프트웨어를 세팅          │
│   └────────┬───────────┘                                       │
│            │                                                   │
└────────────┼───────────────────────────────────────────────────┘
             │
             │ 사용자 요청 수신
             ▼
     ┌────────────────┐
     │  트래픽 입구    │  ← ⑧ Networking/Traffic 슬롯
     │  (LB/Ingress/  │       (Nginx/Envoy/CloudFront/Istio)
     │   CDN)         │
     └────────┬───────┘
              │
              ▼
     ┌────────────────┐
     │  실행 중인 앱   │ ◀────────┐
     └────────────────┘           │
              │                    │ 주기적 인증 · 비밀값 주입
              │                    │
              │          ┌─────────┴──────────┐
              │          │ ⑨ Secrets/Config   │  (Vault/SM/ESO)
              │          │    슬롯             │
              │          └────────────────────┘
              │
              ├─────→ ┌────────────────────┐
              │       │ ⑩ Observability   │  (Prometheus+Grafana+Loki+
              │       │    슬롯             │   Jaeger / Datadog)
              │       │ 로그·메트릭·트레이스 │
              │       └────────┬───────────┘
              │                │
              │                ▼
              │       ┌────────────────────┐
              │       │ ⑪ Alerting 슬롯    │  (Alertmanager/PagerDuty)
              │       │ 이상 감지 → 호출    │
              │       └────────────────────┘
              │
              ├─────→ ┌────────────────────┐
              │       │ ⑬ Identity/Access │  (IAM/OIDC/Teleport)
              │       │    슬롯             │  "누가 무엇을 할 수 있나"
              │       └────────────────────┘
              │
              └─────→ ┌────────────────────┐
                      │ ⑭ Backup/DR 슬롯   │  (Velero/스냅샷/멀티리전)
                      │ 재해 복구·백업      │
                      └────────────────────┘

💡 핵심: 위 다이어그램의 박스들이 슬롯이다. 각 박스에 어떤 도구를 끼울지는 팀마다 다르지만, 박스의 존재 이유는 어느 회사나 똑같다.

14개 슬롯 정리

각 슬롯이 어떤 문제를 해결하는가와 대표 도구를 함께 본다.

① Version Control 슬롯

Version Control = “버전 관리”. 파일이 바뀔 때마다 “언제, 누가, 뭘 바꿨는지” 기록을 남기는 것. 워드 문서에서 “되돌리기(Ctrl+Z)“를 무한으로 쓸 수 있게 해주는 시스템이라고 생각하면 된다.

항목	내용
해결하는 문제	”어제 잘 되던 코드가 왜 지금 안 되지?”, 여러 명이 동시에 작업할 때 충돌 관리
슬롯이 없으면	백업 파일로 관리, 덮어쓰기 사고 빈발, 히스토리 추적 불가
대표 도구	Git (표준) + GitHub / GitLab / Bitbucket
이 로드맵	→ 01-git.md

② Build / Test (CI) 슬롯

Build = “조립”. 소스 코드를 실행 가능한 프로그램으로 만드는 과정. 레고 설명서(소스 코드)를 보고 실제 레고(실행 파일)를 조립하는 것. CI = Continuous Integration, “지속적 통합”. 코드를 올릴 때마다 자동으로 테스트·빌드를 돌려서 문제를 즉시 발견하는 것.

항목	내용
해결하는 문제	”내 PC에서는 되는데”, 수동 테스트 누락, 빌드 실수
슬롯이 없으면	버그 있는 코드가 main에 들어감, 배포 전 검증 부재
대표 도구	GitHub Actions / GitLab CI / Jenkins / CircleCI / Buildkite / Drone
이 로드맵	→ 04-cicd.md

③ Artifact Storage 슬롯

Artifact = “산출물, 결과물”. 원래는 “인공물”이라는 뜻인데, IT에서는 빌드 과정을 거쳐 나온 완성품을 말한다. 밀가루(소스 코드)를 반죽·굽기(빌드)해서 나온 빵(artifact)을 창고(Storage)에 보관하는 것.

항목	내용
해결하는 문제	빌드된 산출물(이미지/바이너리/패키지)을 어디에 저장?
슬롯이 없으면	매번 새로 빌드해야 함, 배포 시 재현 불가
대표 도구	Docker Hub / AWS ECR / GitHub Container Registry / Harbor / Nexus / JFrog Artifactory
관련	Dockerfile 섹션 → 03-docker.md

④ Deploy / Release 슬롯

Deploy = “배치하다, 투입하다”. 군사 용어에서 온 말로, 완성된 프로그램을 실제 서버에 갖다 놓는 행위. 공장에서 만든 제품을 매장 진열대에 올리는 것. Release = “출시”. Deploy가 “서버에 올리는 행위”라면, Release는 “사용자가 실제로 쓸 수 있게 공개하는 것”. 배포했지만 아직 공개 안 할 수도 있다(Feature Flag 등).

항목	내용
해결하는 문제	저장된 아티팩트를 실행 환경에 올리기
슬롯이 없으면	수동 SSH 배포, 무중단 배포 불가, 롤백 어려움
대표 도구	kubectl apply / Helm / ArgoCD / Flux / Spinnaker / Vercel / Netlify / Cloud Run
이 로드맵	→ 04-cicd.md (CD 섹션, GitOps)

⑤ Orchestration 슬롯

Orchestration = “오케스트라 지휘”. 오케스트라 지휘자가 바이올린·첼로·플루트를 언제 연주하고 쉴지 조율하듯, 여러 컨테이너(연주자)를 어느 서버에 배치하고, 죽으면 다시 살리고, 트래픽이 몰리면 수를 늘리는 자동 관리자 역할.

항목	내용
해결하는 문제	여러 대의 서버에 컨테이너/프로세스 배치·자동 복구·스케일링
슬롯이 없으면	컨테이너 죽으면 수동 재시작, 트래픽 급증 대응 불가
대표 도구	Kubernetes / Amazon ECS / HashiCorp Nomad / Docker Swarm / systemd (단일 서버)
이 로드맵	→ 07-kubernetes.md

⑥ Provisioning 슬롯

Provisioning = “미리 준비해두다”. Provision의 원래 뜻은 “식량/물자를 미리 갖춰놓는 것”. IT에서는 서버·네트워크·데이터베이스 같은 인프라 자원을 만들어서 쓸 수 있는 상태로 준비하는 것. 건축에 비유하면 “빈 땅에 건물을 짓는 것”.

항목	내용
해결하는 문제	클라우드 리소스(EC2, VPC, RDS, S3 등) 생성·변경·삭제
슬롯이 없으면	콘솔에서 클릭클릭 → 재현 불가, 추적 불가
대표 도구	Terraform / Pulumi / AWS CDK / CloudFormation / Crossplane
이 로드맵	→ 06-iac.md

⑦ Configuration 슬롯

Configuration = “설정, 구성”. 이미 만들어진 서버(건물) 안에 프로그램을 깔고, 설정 파일을 넣고, 사용자를 만드는 것. Provisioning이 “빈 집을 짓는 것”이라면, Configuration은 “집 안에 가구를 들이고 전등을 다는 것”.

항목	내용
해결하는 문제	이미 존재하는 서버 안에 패키지 설치, 설정 파일 배포, 사용자 생성
슬롯이 없으면	수동 SSH, 서버마다 상태가 달라짐(Configuration Drift)
대표 도구	Ansible / Chef / Puppet / SaltStack / cloud-init
이 로드맵	→ 06-iac.md (Ansible 섹션)

⚠️ ⑥과 ⑦의 차이: Provisioning은 “빈 집을 짓는다”(서버를 만든다), Configuration은 “집 안에 가구를 넣는다”(서버 안을 세팅한다). 이 둘을 혼동하는 것이 가장 흔한 오해다.

⑧ Networking / Traffic 슬롯

Networking = “네트워크 연결”. 컴퓨터끼리 어떻게 통신하는지를 다루는 영역. Traffic = “교통량”. 도로에 차가 다니듯, 네트워크에는 사용자 요청이 오간다. 트래픽이 많다 = 사용자가 많이 몰린다. 이 슬롯은 그 교통 정리(누구를 어디로 보낼지, 길이 막히면 어떻게 분산할지)를 담당한다.

항목	내용
해결하는 문제	사용자의 요청이 어떻게 내 앱까지 도달하는가? 로드밸런싱, TLS 종료, CDN 캐시
슬롯이 없으면	서버 하나만 노출, 트래픽 분산 불가, 지연시간 큼
대표 도구	Nginx / HAProxy / Envoy / Istio (Service Mesh) / AWS ALB·CloudFront / Cloudflare / K8s Ingress
이 로드맵	→ 07-kubernetes.md (Service/Ingress), 05-cloud.md

⑨ Secrets / Config 슬롯

Secrets = “비밀값”. API 키, DB 비밀번호, 인증서처럼 절대 노출되면 안 되는 정보. 코드에 직접 적으면 위험하니까 별도의 금고(Vault)에 넣어두고, 앱이 실행될 때만 꺼내 쓰게 하는 것.

항목	내용
해결하는 문제	API 키, DB 비밀번호, 인증서를 안전하게 저장·주입
슬롯이 없으면	`.env` 파일이 Git에 올라감, 하드코딩, 키 유출 사고
대표 도구	HashiCorp Vault / AWS Secrets Manager / SSM Parameter Store / Sealed Secrets / External Secrets Operator / Doppler
이 로드맵	→ 07-kubernetes.md (Secret 보안), 05-cloud.md (Secrets Manager)

⑩ Observability 슬롯

Observability = “관찰 가능성”. Monitoring(모니터링)이 “미리 정한 항목을 감시하는 것”이라면, Observability는 예상 못한 문제까지 원인을 추적할 수 있는 능력. 자동차 계기판(모니터링)만으로는 엔진 내부 고장 원인을 모르지만, 블랙박스+엔진 센서+주행 기록(Observability)이 있으면 “왜 고장났는지”까지 알 수 있다.

항목	내용
해결하는 문제	”지금 서비스가 잘 돌고 있는가? 어디가 느린가?”
세부 3요소	Logs(뭐가 일어났나) / Metrics(숫자·추이) / Traces(요청이 어떻게 흘렀나)
슬롯이 없으면	장애 발생 후 원인 추적 불가, 성능 저하 감지 불가
대표 도구	Prometheus + Grafana + Loki + Jaeger (오픈소스 조합), Datadog / New Relic / Elastic APM / Honeycomb / Dynatrace (상용 통합)
이 로드맵	→ Phase 10 (monitoring)

⑪ Alerting / Incident Response 슬롯

Alerting = “경보”. 시스템에 이상이 생기면 담당자에게 자동으로 알림을 보내는 것. 화재 감지기가 연기를 감지하면 경보를 울리는 것과 같다. Incident Response = “사고 대응”. 경보가 울린 뒤 누가, 어떤 순서로 대응하는지의 체계. 온콜(on-call) = 당번처럼 “이번 주는 내가 새벽 장애 전화를 받는다”는 교대 제도.

항목	내용
해결하는 문제	이상을 감지하면 누구에게 어떻게 알릴 것인가, 온콜 로테이션
슬롯이 없으면	새벽 장애를 아침에 출근해서 알게 됨
대표 도구	Alertmanager (Prometheus용) / PagerDuty / Opsgenie / Grafana OnCall / VictorOps
이 로드맵	→ Phase 10 (04-alerting-slo.md)

⑫ Security Scanning 슬롯

Security Scanning = “보안 검사”. 내 코드나 사용하는 라이브러리에 해킹당할 수 있는 구멍(취약점)이 없는지 자동으로 검사하는 것. 공항 보안 검색대처럼, 코드가 서버에 올라가기 전에 위험한 것이 없는지 걸러내는 역할.

항목	내용
해결하는 문제	내 코드와 의존성에 취약점이 있는가? 하드코딩된 시크릿은 없는가?
세부 4종	SAST(소스 코드) / SCA(의존성) / Container Scan(이미지) / Secret Scan(키 탐지)
슬롯이 없으면	log4j 같은 취약점이 프로덕션까지 흘러감
대표 도구	Snyk / Trivy / CodeQL / Dependabot / Gitleaks / Checkov (IaC) / Aqua
이 로드맵	→ 04-cicd.md (보안 스캔 섹션)

⑬ Identity / Access 슬롯

Identity = “신원, 정체”. “너 누구야?”를 확인하는 것(인증). Access = “접근 권한”. “너는 이것만 할 수 있어”를 정하는 것(인가). 회사 출입증에 비유하면, Identity = 출입증으로 본인 확인, Access = 출입증 등급에 따라 들어갈 수 있는 층이 다른 것.

항목	내용
해결하는 문제	누가 무엇을 할 수 있는가 — 사람·서비스·머신의 권한 관리
슬롯이 없으면	누구나 프로덕션 삭제 가능, 퇴사자 권한 회수 누락
대표 도구	AWS IAM / GCP IAM / Azure AD / Okta / Auth0 / Teleport / HashiCorp Boundary / OIDC (Keycloak)
이 로드맵	→ 05-cloud.md (IAM), 07-kubernetes.md (RBAC)

⑭ Backup / Disaster Recovery 슬롯

Backup = “백업, 예비 복사본”. 중요한 데이터를 미리 복사해두는 것. 스마트폰 사진을 클라우드에 올려두면 폰이 고장나도 사진이 살아있는 것과 같다. Disaster Recovery (DR) = “재해 복구”. 서버가 통째로 날아가거나 데이터센터에 불이 나는 최악의 상황에서 얼마나 빨리 서비스를 되살리느냐의 계획.

항목	내용
해결하는 문제	데이터 손실·리전 전체 다운 시 얼마나 빨리 복구하는가
핵심 지표	RPO(복구 시점 목표: 얼마만큼의 데이터를 잃어도 되는가) / RTO(복구 시간 목표: 얼마 안에 복구하는가)
슬롯이 없으면	DB 삭제 사고 = 회사 파산
대표 도구	Velero (K8s) / AWS Backup / RDS 스냅샷 / Multi-Region 복제 / S3 Versioning
이 로드맵	→ 아직 단독 섹션 없음 (향후 보강 후보)

선택적 슬롯 (조직이 커지면 필요해짐)

위 14개는 규모와 상관없이 거의 모든 서비스에 필요한 슬롯이다. 여기서부터는 선택적이다.

슬롯	해결하는 문제	대표 도구
Service Discovery	서비스 A가 서비스 B를 어떻게 찾는가 (IP 바뀜)	K8s Service, Consul, etcd
Service Mesh	서비스 간 통신의 재시도·암호화·관찰을 코드 밖으로	Istio, Linkerd, Consul Connect
Feature Flags	배포와 릴리즈 분리, A/B 테스트	LaunchDarkly, Unleash, GrowthBook
Cost / FinOps	클라우드 비용 추적·최적화	AWS Cost Explorer, Kubecost, Infracost
Policy as Code	”이 리소스는 프로덕션에 들어가면 안 됨” 같은 규칙 자동화	OPA, Kyverno, Sentinel
Image Signing	이미지가 위변조되지 않았음을 증명	Cosign, Notary, Sigstore
Chaos Engineering	”장애가 나도 살아남는가”를 일부러 테스트	Chaos Mesh, Gremlin, LitmusChaos

매핑 연습 — 새 도구를 만나면?

아래는 실제 이런 질문을 받았을 때의 사고 흐름이다.

예시 1: “AWS Systems Manager가 뭐야?”

AWS Systems Manager의 기능:
  - Session Manager: SSH 없이 서버 접속
  - Parameter Store: 설정값 저장
  - Run Command: 여러 서버에 명령 일괄 실행
  - Patch Manager: OS 패치 자동화

→ 슬롯 매핑:
  - Session Manager = ⑬ Identity/Access (Bastion 대체)
  - Parameter Store = ⑨ Secrets/Config
  - Run Command = ⑦ Configuration (Ansible의 가벼운 대안)
  - Patch Manager = ⑦ Configuration

→ 결론: "AWS가 여러 슬롯을 통합 제공하는 상품"

예시 2: “Consul이 뭐야?”

Consul의 기능:
  - 서비스 디스커버리
  - Key-Value 저장소
  - 헬스 체크
  - 서비스 메시 (Consul Connect)

→ 슬롯 매핑:
  - 서비스 디스커버리 = Service Discovery 슬롯 (K8s Service 대안)
  - KV 저장소 = ⑨ Secrets/Config 슬롯의 일부
  - Connect = Service Mesh 슬롯 (Istio 대안)

→ 결론: "K8s 없이 위 슬롯을 채우고 싶을 때 쓰는 통합 도구"

예시 3: “Packer가 뭐야?”

Packer의 기능: 코드로 머신 이미지(AMI, Docker 이미지) 빌드

→ 슬롯 매핑:
  - ② Build 슬롯 + ⑥ Provisioning 슬롯 사이에 위치
  - "서버를 만들기 전에 그 서버의 골든 이미지를 미리 굽는 도구"

→ 결론: Docker 이미지 빌드의 **VM 버전**. Terraform 이전 단계에 들어간다.

예시 4: “Crossplane이 뭐야?”

Crossplane의 기능: K8s 안에서 클라우드 리소스(RDS, S3 등)를 선언적으로 관리

→ 슬롯 매핑:
  - ⑥ Provisioning 슬롯 (Terraform의 대안)
  - 하지만 K8s 네이티브 방식

→ 결론: "Terraform을 K8s 매니페스트처럼 쓸 수 있게 한 것"

예시 5: “Honeycomb이 뭐야?”

Honeycomb의 기능: 고카디널리티 이벤트 기반 관찰가능성

→ 슬롯 매핑:
  - ⑩ Observability 슬롯 (Datadog·New Relic 대안)

→ 결론: 목적은 같음. 접근 방식(이벤트 기반)이 다를 뿐.

흔한 오해 — 슬롯이 헷갈릴 때

❌ “Ansible이 Terraform의 구버전/업그레이드판이다” → 아니다. 두 도구는 다른 슬롯에 있다.

Terraform = ⑥ Provisioning (서버 “생성”)
Ansible = ⑦ Configuration (서버 “설정”)
실무에서는 둘을 함께 쓰는 것이 정석.

❌ “K8s만 있으면 인프라 끝” → K8s는 ⑤ Orchestration 슬롯 하나일 뿐. 그 아래 ⑥ Provisioning, 그 옆 ⑨ Secrets, ⑩ Observability 등을 별도로 채워야 한다.

❌ “ArgoCD가 있으면 GitHub Actions 필요 없다” → ArgoCD = ④ Deploy 슬롯. GitHub Actions = ② Build 슬롯. 역할이 다르다. 이미지를 빌드해서 레지스트리에 올리는 건 여전히 CI의 몫이고, ArgoCD는 그 이미지를 클러스터에 적용할 뿐.

❌ “Docker Compose가 있으면 K8s 필요 없다” → Compose는 로컬 개발용 단순 오케스트레이션, K8s는 프로덕션 분산 오케스트레이션. 같은 슬롯이지만 쓰이는 환경이 다르다. 스타트업도 프로덕션엔 K8s(또는 ECS 등)를 쓴다.

❌ “Datadog가 있으면 Prometheus 필요 없다” → 맞는 말일 수도 있다. 두 도구 모두 ⑩ Observability 슬롯이다. 같은 슬롯의 다른 부품이므로 하나만 써도 된다. 다만 상용 vs 오픈소스, 비용, 데이터 저장 위치(SaaS vs 온프레미스) 등의 트레이드오프가 있다.

❌ “IAM은 AWS만의 개념이다” → IAM은 ⑬ Identity/Access 슬롯의 이름일 뿐이다. GCP는 Cloud IAM, Azure는 Azure AD, K8s는 RBAC, 사내 사용자는 Okta/OIDC. 슬롯은 같고 구현이 다르다.

로드맵 파일과 슬롯 매핑

이 로드맵의 각 파일이 어느 슬롯을 다루는지 정리하면 학습 동기가 명확해진다.

파일	다루는 슬롯
01-git.md	① Version Control
02-linux.md	모든 슬롯의 기초 지식(서버 안에서 일어나는 일 이해) + ⑬ Access 일부
03-docker.md	② Build + ③ Artifact + ⑤ Orchestration의 기초 단위
04-cicd.md	② Build/Test + ④ Deploy + ⑫ Security Scan
05-cloud.md	⑥ Provisioning의 대상(클라우드 자체) + ⑧ Networking + ⑬ IAM
06-iac.md	⑥ Provisioning(Terraform) + ⑦ Configuration(Ansible)
07-kubernetes.md	⑤ Orchestration + ⑧ Ingress + ⑨ Secret + ⑬ RBAC
Phase 10	⑩ Observability + ⑪ Alerting

💡 지금 이 문서(00)를 읽은 효과: 다른 파일에 들어가도 “이 파일은 어느 슬롯을 배우는지”를 먼저 알기 때문에 세부 내용이 훨씬 빨리 머리에 정리된다.

실무 시나리오 — 흐름으로 보는 서비스 운영 하루

개념만 봐서는 와닿지 않을 수 있다. “어느 슬롯이 언제 작동하는지”를 실제 시나리오로 본다.

시나리오: 풀스택 개발자가 새 기능(로그인 UI 개선)을 프로덕션에 배포한다.

[10:00] 개발자가 로컬에서 코드 수정
         ↓
[10:15] git commit → git push origin feat/login-ui
         ↓ (① Version Control 슬롯 동작)
[10:15] GitHub에서 PR 생성
         ↓
[10:16] ② CI 파이프라인 자동 시작
         - lint / type check / unit test / build
         - ⑫ SCA 스캔 (Dependabot, Trivy)
         - ⑫ SAST (CodeQL)
         ↓
[10:21] 모든 체크 통과, 리뷰어 승인
         ↓
[10:25] PR 머지 → main 브랜치 업데이트
         ↓
[10:25] ② main에서 Docker 이미지 빌드
         ↓
[10:27] ③ ECR에 이미지 push (태그: git SHA)
         ↓
[10:27] ④ ArgoCD가 Git 저장소 변화 감지
         - K8s manifest의 이미지 태그가 새로 갱신됨
         ↓
[10:28] ④ ArgoCD가 클러스터에 새 매니페스트 적용
         ↓
[10:28] ⑤ K8s가 Rolling Update 시작
         - Readiness Probe로 새 Pod 준비 확인 후 교체
         - 기존 Pod에서 새 Pod로 트래픽 이동
         - ⑨ Secret은 External Secrets Operator가 Vault에서 동기화
         ↓
[10:30] ⑧ Ingress가 새 Pod로 라우팅 시작
         ↓
[10:30] 배포 완료. 사용자가 새 UI를 본다.
         ↓
[10:30~] ⑩ Prometheus·Loki·Jaeger가 새 버전의 메트릭·로그·트레이스 수집
[14:00] 메트릭: 로그인 실패율 평소 0.5% → 2.3%로 증가
         ↓
[14:00] ⑪ Alertmanager가 이상 감지 → PagerDuty로 온콜 호출
         ↓
[14:01] 온콜 엔지니어가 대시보드 확인
         ↓ "새 로그인 UI 배포와 시점이 일치"
[14:02] ④ ArgoCD에서 이전 리비전으로 롤백 (git revert → 자동 재배포)
         ↓
[14:03] 메트릭 정상 복귀. 장애 시간 3분.
         ↓
[14:05] ⑭ 그동안의 로그인 실패 데이터는 DB 백업에 영향 없음 확인

이 하루에 14개 슬롯 중 10개가 동작했다. 이것이 인프라 관리의 실체다.

정리 및 체크리스트

□ 인프라 관리에는 정해진 "슬롯(역할 자리)"이 있고, 도구는 그 슬롯을 채우는 부품이라는 것을 이해한다
□ 14개 핵심 슬롯의 이름을 말할 수 있다
□ ⑥ Provisioning과 ⑦ Configuration의 차이를 설명할 수 있다 (Terraform vs Ansible)
□ ② Build(CI)와 ④ Deploy(CD) 슬롯이 분리되는 이유를 설명할 수 있다
□ K8s가 ⑤ Orchestration 슬롯이고 인프라 전부를 커버하지 않는다는 것을 이해한다
□ ⑩ Observability 슬롯의 3요소(Logs/Metrics/Traces)를 말할 수 있다
□ 새로운 도구를 들었을 때 "어느 슬롯에 속하는가"를 판단할 수 있다
□ 한 번의 배포에서 어떤 슬롯들이 순서대로 동작하는지 시나리오로 설명할 수 있다
□ RPO와 RTO가 무엇인지 설명할 수 있다 (⑭ Backup/DR)
□ "Ansible이 Terraform의 업그레이드다" 같은 흔한 오해를 바로잡을 수 있다

다음 단계

이 문서로 전체 흐름의 지도를 얻었다. 이제 각 슬롯을 깊이 들어간다.

→ 01-git.md (Version Control 슬롯부터 시작)

💡 각 파일을 읽기 전에 “지금 나는 어느 슬롯을 배우고 있는가?”를 먼저 떠올려보면, 세부 내용이 전체 그림과 연결되어 훨씬 오래 기억된다.

Comments

// 댓글을 불러오는 중...