Platform Series를 마치며

이 글의 목적

플랫폼 · DevOps · Cloud 본편 21편을 마쳤다. 이 글은 시리즈 전체를 압축·연결하고 다음에 어디로 갈지 짚는 에필로그다.

• 21편 동안 본 개념을 한 장 지도로 다시 본다
• 플랫폼·배포에서 뻗어 나가는 주제와 블로그 내 다른 시리즈를 연결한다
• 플랫폼 지식이 어떤 직업·역할과 맞닿는지 정리한다
• 손으로 확인하는 방법과 읽을거리를 남긴다

1. 21편이 만든 큰 그림

플랫폼은 도구 이름이 아니라 코드에서 프로덕션까지의 전달·운영 체계다.

Part	핵심 질문	기억할 키워드
0 오리엔테이션	누가 무엇을 운영하나	DevOps, SRE, Platform Eng, 파이프라인
1 컨테이너	앱을 어떻게 묶나	이미지, 레이어, namespace, cgroup
2 Kubernetes	desired state를 어떻게 유지하나	Pod, Deployment, Service, Ingress, HPA
3 DevOps	어떻게 자동 배포하나	CI/CD, Actions, canary, IaC, GitOps
4 Cloud	인프라를 어떻게 쓰나	IaaS/PaaS, VPC, RDS/S3, Well-Architected
5 플랫폼 확장	규모·위치는 어떻게 늘리나	service mesh, multicluster, K3s edge

한 줄로 묶으면:

컨테이너 이미지로 앱을 패키징하고(컨테이너)
  K8s manifest로 desired state를 선언하고(오케스트레이션)
  CI/CD·GitOps로 변경을 PR·sync하고(DevOps)
  VPC·관리형 서비스 위에 올리고(클라우드)
  mesh·멀티클러스터·엣지로 확장한다(플랫폼)

2. 실무에서 다시 만나는 지점

교과서 개념은 배포·장애·비용으로 확인할 때 살아난다.

플랫폼 개념	실무에서 보는 곳	도구·명령
이미지·레이어	빌드 느림, 취약점 스캔	docker build, Trivy
Pod·probe	Running인데 502	kubectl describe pod, readiness
Service·Ingress	내부 OK 외부 NG	kubectl get endpoints, Ingress annotation
rolling·canary	배포 후 error spike	Deployment status, mesh weight
GitOps drift	누가 kubectl edit 했나	argocd app diff, selfHeal
Terraform state	이중 생성·lock	terraform plan, remote state
VPC·SG	DB public 노출	subnet, security group audit
RDS Multi-AZ	failover 시간	writer/reader endpoint
mesh mTLS	평문 내부 통신	istioctl analyze, PeerAuthentication
multicluster	리전 DR 미검증	failover drill, ApplicationSet
K3s edge	현장 링크 끊김	local buffer, sync retry

• "배포했는데 안 된다" — 이미지 태그·manifest·sync·probe·Ingress가 겹쳐 있다. 시리즈가 준 레이어 분해로 첫 실패 지점을 찾는 게 출발점
• 선언적 상태 — K8s·IaC·GitOps는 같은 철학: Git·YAML이 진실의 원천, 런타임은 reconcile

3. 이후 확장되는 개념

본 시리즈는 컨테이너·K8s·CI/CD·클라우드·확장 패턴 공통 기반까지다.

확장 영역	플랫폼에서 온 질문	더 깊이 가면
IaC·CD	Terraform·Argo 개요	CDK, Helm chart, Flux, Crossplane
관측성	probe·mesh metric	SLO, OpenTelemetry, on-call
보안	Secret·mTLS	Zero Trust, SBOM, OPA/Kyverno
아키텍처	MSA·배포 전략	DDD, event-driven, CQRS
네트워크	Ingress·VPC	CNI, BGP, eBPF
데이터베이스	RDS·연결	replication lag, CDC, pool tuning
플랫폼 엔지니어링	GitOps·클러스터	IDP, golden path, Backstage
FinOps	NAT·인스턴스 비용	cost allocation, Graviton, rightsizing

블로그 내 이어읽기 (권장 순)

1. IaC — Terraform·CDK·CD 심화 (14편 GitOps 이후)
2. 관측성 기초 — SLO·메트릭·트레이스 (배포 후 검증)
3. 애플리케이션 보안 — Secret·AuthN/Z·OWASP (8편·19편 확장)
4. 소프트웨어 아키텍처 — MSA·내고장성·이벤트 (13편·19편 연계)
5. 네트워크 기초 — DNS·TLS·VPC (7편·16편 밑바닥)
6. 데이터베이스 따라잡기 — 복제·트랜잭션 (17편 RDS 이후)
7. ELK · Elastic Cloud — 로그·APM (운영 관측 심화)

4. 관심 있게 지켜볼 직업·직업군

플랫폼·DevOps는 백엔드·인프라·SRE 전반의 공통 언어다.

역할	하는 일	플랫폼 시리즈와의 연결
백엔드 엔지니어	API·비즈니스 로직	Dockerfile, health probe, 12-factor
DevOps 엔지니어	CI/CD·릴리스	Actions, canary, artifact
SRE	가용성·장애·용량	rolling, SLO, runbook
플랫폼 엔지니어	내부 개발자 경험	K8s·GitOps·IDP
클라우드 엔지니어	VPC·관리형·비용	Well-Architected, IAM
보안 엔지니어	취약점·인증	Secret, mTLS, image scan
아키텍트	품질·트레이드오프	MSA, mesh, ADR
엣지·IoT	현장 배포·오프라인	K3s, buffer sync, OTA

지켜볼 만한 방향 (2020s~)

• Platform engineering / IDP — 개발팀용 셀프서비스 플랫폼
• GitOps everywhere — 앱·인프라·관측 규칙까지 Git
• eBPF·Cilium — sidecar 없는 네트워크·관측
• AI infra — GPU scheduling, model serving, batch on K8s
• FinOps + sustainability — 비용·탄소를 설계 단계 지표로
• Wasm on K8s — 경량 런타임·엣지 워크로드 (speculative)

역할마다 깊이는 다르다. 백엔드는 Dockerfile·probe를, SRE는 배포 전략·SLO를, 플랫폼 엔지니어는 클러스터·GitOps·개발자 UX를 최소로 갖추면 시너지가 난다.

5. 앞으로의 학습 루틴

개념만으로는 부족하다. 짧은 루프를 권한다.

주기	활동	예
매주	한 manifest·workflow 읽기	Deployment spec, Actions job
매월	미니 배포 실습	kind/minikube + Argo CD demo
분기	장애·배포 시뮬레이션	canary rollback, argocd app sync
연 1회	스택·비용 review	Well-Architected lens, idle resource

추가 읽을거리

수준	자료
입문·복습	Production Kubernetes — Berkus, Box (본 시리즈 기준)
K8s 공식	kubernetes.io — Concepts, Tasks
DevOps 문화	The Phoenix Project — Kim et al.
클라우드	AWS Well-Architected Framework
GitOps	Argo CD docs, OpenGitOps principles
실습	kind, k3d, kube-prometheus-stack, local Terraform
트렌드	CNCF landscape, KubeCon recap, Platform Engineering 커뮤니티

6. 시리즈 색인 (21편 요약)

필요할 때 해당 편으로 바로 점프한다.

#	제목	거기서 답하는 질문
1	플랫폼 오리엔테이션	DevOps·SRE·Platform Eng, 로드맵
2~4	컨테이너	VM vs 컨테이너, Docker, 런타임·보안
5~10	Kubernetes	Pod, Service, Ingress, 스토리지, 스케줄링
11~14	DevOps	CI/CD, Actions, 배포 전략, IaC·GitOps
15~18	Cloud	클라우드 모델, VPC, 관리형, Well-Architected
19~21	플랫폼 확장	서비스 메시, 멀티클러스터, 엣지

7. 마치며

처음에는 docker run과 kubectl apply만으로도 배포가 됐을지 모른다. 시리즈를 지나며 그 한 줄 아래에 이미지 레이어·control plane·rolling update·GitOps reconcile·VPC 경계·mesh mTLS·엣지 버퍼가 겹겹이 있다는 걸 봤다.

플랫폼을 안다는 건 모든 YAML을 외운다는 뜻이 아니다. 배포·장애·설계 대화에서 "그건 probe다 / OutOfSync다 / NAT 비용이다 / subset weight다"고 위치를 잡고, 다음 명령·PR을 고를 수 있다는 뜻에 가깝다.

---

해당 내용은 Production Kubernetes (Josh Berkus, Craig Box), AWS Well-Architected Framework, 및 시리즈 1~21편을 바탕으로 정리했습니다.