L5 플랫폼 엔지니어링 & 자동화 입구
L5 플랫폼 엔지니어링 & 자동화 입구
섹션 제목: “L5 플랫폼 엔지니어링 & 자동화 입구”핵심 질문
섹션 제목: “핵심 질문”코드 변경 하나가 운영 서비스가 되기까지, 사람이 매번 절차를 기억하고 여러 팀에 요청하지 않아도 같은 안전 기준으로 반복되는 경로를 어떻게 만들 수 있을까?
3줄 요약
섹션 제목: “3줄 요약”- 플랫폼 엔지니어링은 인프라 도구를 모으는 일이 아니라, 개발자가 코드를 검증하고 배포하고 운영하는 공통 경로를 내부 제품으로 만드는 일이다.
- Docker, CI/CD, 브랜치 전략, Terraform, Kubernetes, GitOps는 각각 패키징·검증·협업·인프라·런타임·상태 수렴의 서로 다른 책임을 맡는다.
- IDP(Internal Developer Platform, 내부 개발자 플랫폼)는 조직의 실제 병목에 필요한 capability를 Golden Path로 제품화하는 선택지다. 모든 팀이 같은 완성형 스택을 구축해야 하는 것은 아니다.
1. 정의 — 플랫폼 엔지니어링이 만드는 것
섹션 제목: “1. 정의 — 플랫폼 엔지니어링이 만드는 것”플랫폼 엔지니어링은 개발자가 인프라, 배포, 권한, 관측 같은 공통 작업을 승인된 경로 안에서 스스로 처리할 수 있도록, 반복 운영 지식을 자동화하고 그 경로를 제품처럼 개선하는 엔지니어링이다.
이 정의에서 중요한 대상은 특정 도구가 아니라 개발자 경로다. 예를 들어 새 서비스를 출시하려면 실행 환경을 고정하고, 변경을 검증하고, 인프라를 준비하고, 여러 서버에서 원하는 상태를 유지하고, 운영 상태를 추적해야 한다. 이 단계들이 팀마다 다른 문서·티켓·수동 명령으로 흩어져 있으면 도구가 많아도 플랫폼은 아니다.
플랫폼이 제공하는 Golden Path는 “이 방식만 허용한다”는 강제 표준과도 다르다. 자주 반복되는 요구에는 가장 쉽고 안전한 기본 경로를 제공하고, 특수한 요구에는 경로를 벗어날 수 있는 조건과 추가 책임을 설명해야 한다. 셀프서비스도 무제한 권한이 아니라 입력 검증, 권한 경계, 감사 기록, 실패 메시지가 포함된 안전한 실행 경로다.
선행 단계의 한계와 L5의 등장
섹션 제목: “선행 단계의 한계와 L5의 등장”L3의 AWS 인프라 문서는 IAM, VPC, ECS처럼 클라우드 자원과 권한이 어떤 역할을 하는지 설명한다. L4의 OS·Linux 문서는 프로세스, 파일, 자원, 격리가 실제 실행을 어떻게 떠받치는지 설명한다. 하지만 각 부품을 안다고 해서 여러 개발자가 변경을 같은 방식으로 패키징하고 검증하고 배포하는 경로가 자동으로 생기지는 않는다.
작은 팀에서는 숙련자가 서버를 설정하고 배포를 도우며 권한 요청을 처리할 수 있다. 서비스와 팀이 늘면 같은 방식은 대기열, 환경 편차, 수동 변경, 지식 독점으로 바뀐다. 제품 개발자는 기능과 무관한 운영 절차를 계속 기억해야 하고, 인프라 담당자는 같은 요청을 반복해서 처리하게 된다.
L5는 이 간극에서 등장한다. 실행 환경을 재현 가능한 산출물로 만들고, 변경을 작은 검증 단위로 흘리고, 인프라와 런타임의 원하는 상태를 선언하고, 각 상태를 누가 수렴시킬지 책임을 나눈다. 마지막에는 이 경로를 개발자가 실제로 사용할 수 있는 셀프서비스 제품으로 묶는다.
2. 등장 문제 — 한 번의 성공을 반복 가능한 전달 경로로 바꾸기
섹션 제목: “2. 등장 문제 — 한 번의 성공을 반복 가능한 전달 경로로 바꾸기”한 번 배포에 성공하는 것과 누구나 같은 기준으로 계속 배포할 수 있는 것은 다른 문제다. 반복 가능한 경로에는 다음 질문에 대한 소유자가 필요하다.
| 반복해서 생기는 문제 | L5가 묻는 질문 | 주로 맡는 책임 |
|---|---|---|
| 개발자와 서버의 실행 환경이 다르다 | 무엇을 동일한 불변 배포 단위로 보낼 것인가? | Docker 이미지와 컨테이너 |
| 변경을 늦게 합쳐 통합 실패가 커진다 | 어떤 검증·전달 계약을 언제 통과해야 하는가? | CI/CD 파이프라인 |
| 여러 변경의 충돌·리뷰·릴리즈 경계가 흐리다 | 변경을 어디서 격리하고 언제 통합할 것인가? | Git 브랜치 전략 |
| 콘솔에서 만든 인프라를 재현하거나 리뷰하기 어렵다 | 클라우드 자원의 원하는 상태와 변경 계획은 어디에 남는가? | Terraform과 IaC |
| 여러 서버의 컨테이너 배치와 복구를 사람이 맞춘다 | 런타임의 현재 상태를 누가 원하는 상태로 돌려놓는가? | Kubernetes 컨트롤러 |
| CI가 운영 권한을 쥐고 배포하며 수동 변경이 누적된다 | 승인된 운영 상태와 실제 상태의 차이를 누가 계속 줄이는가? | GitOps 컨트롤러 |
| 개발자가 이 모든 도구의 세부사항을 직접 조립한다 | 반복 요청을 어떤 최소 입력과 가드레일로 제공할 것인가? | IDP와 Golden Path |
이 표를 도구 도입 순서로만 읽으면 안 된다. 각 도구는 앞 도구를 대체하기보다 다른 실패 경계와 책임을 맡는다. Docker가 있어도 CI/CD는 필요하고, CI/CD가 있어도 여러 호스트의 현재 상태를 계속 맞춰 주지는 않는다. Kubernetes가 있어도 클라우드 기반 자원과 승인된 변경 이력의 소유권은 별도로 정해야 한다.
3. 핵심 철학 — 반복은 자동화하고 책임은 더 선명하게
섹션 제목: “3. 핵심 철학 — 반복은 자동화하고 책임은 더 선명하게”L5 전체를 관통하는 철학은 복잡성을 감추는 것보다 반복 가능한 계약으로 옮기는 것에 가깝다.
- 명령보다 리뷰 가능한 선언과 산출물을 남긴다. Docker 이미지는 실행 환경을 고정한 불변 산출물이고, HCL(HashiCorp Configuration Language)은 Terraform에서 인프라를 선언하는 언어다. manifest는 배포할 원하는 상태를 적은 선언 파일이다. 이미지와 CI/CD 파이프라인 자체는 원하는 상태 수렴기가 아니므로, 선언·검증·수렴의 책임을 섞지 않는다.
- 변경을 작고 추적 가능한 단위로 만든다. 코드 변경, 이미지, 인프라 plan, 배포 manifest가 어떤 커밋과 승인에서 나왔는지 연결되어야 한다.
- 한 리소스에는 한 최종 소유자를 둔다. 같은 Kubernetes Deployment를 Terraform과 Argo CD가 함께 고치면 두 수렴 루프가 서로를 되돌린다. 자동화가 많아질수록 소유권 경계는 더 명시적이어야 한다.
- 자동화는 실패를 숨기지 않는다. 성공 여부만 보여 주는 포탈은 개발자를 독립시키지 못한다. 어느 단계가 실패했고, 어떤 상태가 실제로 만들어졌으며, 어디에서 더 낮은 층으로 내려가야 하는지 보여 줘야 한다.
- 플랫폼을 내부 제품으로 운영한다. 기능 수보다 첫 성공까지 걸리는 시간, 반복 티켓 감소, 변경 실패율, 개발자가 표준 경로를 계속 선택하는지를 본다.
플랫폼 팀이 모든 운영 책임을 대신 가져가는 것도 목표가 아니다. 제품팀은 서비스의 동작, 용량 요구, 배포 결과를 이해하고 운영한다. 플랫폼팀은 여러 팀이 반복해서 풀던 실행 방법, 기본 보안, 변경 경로, 관찰 지점을 표준화한다. 즉 책임을 없애는 것이 아니라 제품팀이 결정할 What과 플랫폼이 구현할 How의 경계를 선명하게 만든다.
4. 레이어 사고 모델 — 산출물, 계약, 수렴, 제품 경계
섹션 제목: “4. 레이어 사고 모델 — 산출물, 계약, 수렴, 제품 경계”L5의 도구를 외우기 전에 아래 여섯 경계로 나누어 본다.
| 사고 경계 | 핵심 질문 | 연결되는 토픽 |
|---|---|---|
| 불변 산출물 경계 | 어떤 코드와 실행 환경을 같은 단위로 이동시키는가? | Docker |
| 검증·전달 경계 | 어떤 변경과 산출물이 어느 검증을 거쳐 승격되는가? | CI/CD, Git 브랜치 전략 |
| 인프라 수렴 경계 | 어떤 클라우드 자원의 원하는 상태를 누가 계획하고 적용하는가? | Terraform |
| 런타임 수렴 경계 | 클러스터의 실제 상태를 누가 원하는 상태로 계속 되돌리는가? | Kubernetes |
| Git 수렴 경계 | 승인된 Git 상태와 운영 상태의 차이를 누가 계속 줄이는가? | GitOps |
| 제품 경계 | 어떤 반복 능력을 입력·가드레일·피드백이 있는 제품으로 내놓는가? | 플랫폼 엔지니어링, IDP |
실제 prerequisite graph는 하나의 직선이 아니다.
L4 Linux + cgroups ── Docker ─┬─ CI/CD ── Git 브랜치 전략 ─┐ └─ Kubernetes ────────────────┤ ↑ ├─ GitOps ─┐ L3 ECS vs EC2 │ │L3 IAM + VPC ── Terraform ─────────────────────────────────┘ ├─ 필요할 때 IDP capability로 제품화 └─────────────────────────────────────────────┤What is Platform Engineering ────────────────────────────────────────┘Docker 이미지는 CI/CD가 검증하고 전달할 불변 산출물이면서 Kubernetes가 실행할 배포 단위다. 그래서 Docker 뒤에서 CI/CD와 Kubernetes가 갈라진다. CI/CD는 코드를 빌드·테스트하고 산출물을 전달·승격하는 계약이지, 운영 상태를 계속 원하는 상태로 되돌리는 수렴기는 아니다.
Terraform은 Docker의 다음 단계가 아니라 L3의 IAM과 VPC 이해에서 독립적으로 진입한다. 호출될 때 HCL 선언과 현재 state의 차이를 plan하고 apply해 VPC, IAM, EKS 같은 장기 수명 기반 인프라를 바꾼다. EKS(Amazon Elastic Kubernetes Service)는 AWS가 Kubernetes control plane을 관리하는 서비스다. Kubernetes는 Docker와 L3의 오케스트레이션 맥락을 바탕으로 Deployment 같은 manifest의 원하는 상태와 클러스터 실제 상태를 컨트롤러가 계속 비교하고 복구한다.
GitOps는 이 분기들이 합류하는 지점이다. CI/CD와 브랜치 전략이 승인된 변경을 만들고, Terraform이 기반 인프라의 상태를 소유하며, Kubernetes가 클러스터 런타임을 수렴시킨다는 전제 위에서 GitOps 컨트롤러가 Git의 승인 상태와 실제 클러스터 상태를 계속 맞춘다. 같은 리소스를 Terraform과 GitOps가 함께 고치지 않도록 “Terraform은 기반 인프라, GitOps는 클러스터 안 애플리케이션 상태”처럼 최종 소유권을 나누어야 한다.
IDP는 이 그래프의 필수 종착점이나 완성형 스택이 아니다. 권한 발급이 병목이면 승인된 권한 요청 capability를, 서비스 생성이 병목이면 저장소·파이프라인·배포 골격을 잇는 capability를 먼저 제품화할 수 있다. Terraform 모듈과 승인 워크플로만으로 병목이 풀린다면 포탈이나 서비스 카탈로그까지 만들 필요는 없다. 반복 요청의 빈도, 사용자 범위, 인지 부하가 충분할 때만 필요한 capability를 Golden Path로 묶는다.
5. 실제 읽기 순서
섹션 제목: “5. 실제 읽기 순서”아래 순서는 L5 파일의 실제 learning_order를 따른다. 이는 문서를 읽기 위한 교육적 내비게이션이지, 모든 기술이 앞 기술의 필연적 진화 결과이거나 모든 인접 토픽이 직접 prerequisite라는 뜻은 아니다.
L5 추천 학습 순서
- 10. What is Platform Engineering
반복 티켓과 외재적 인지 부하가 왜 셀프서비스, Golden Path, 가드레일, Platform as a Product를 요구하는지 먼저 잡는다.
- 20. Docker Basics
코드와 실행 환경을 불변 이미지로 고정해 이후 CI/CD와 Kubernetes가 공유할 배포 단위를 만든다.
- 30. CI/CD Basics
작은 변경을 자동 검증하고, Docker 이미지를 한 번 만든 뒤 같은 산출물을 환경 사이에서 승격하는 전달 경로를 배운다.
- 40. Git Flow & Branching
CI가 검증할 변경 단위와 main·release의 품질 경계를 팀의 릴리즈 모델에 맞게 설계한다.
- 50. Terraform / IaC Basics
Docker 경로와 별개로 L3 IAM·VPC에서 진입해, 콘솔 변경을 HCL, plan, state, DAG로 옮기고 클라우드 인프라를 재현 가능한 소유 대상으로 만든다.
- 60. Kubernetes Basics
Docker가 남긴 다중 호스트 배치·복구 문제를 선언형 API와 컨트롤러 수렴 모델로 해결하는 방법을 배운다.
- 70. GitOps Basics
CI/CD·Git 전략, Terraform, Kubernetes 분기가 합류해 승인된 desired state, pull 권한 경계, 지속 reconciliation을 이루는 관계를 정리한다.
- 80. Internal Developer Platform
조직 병목이 요구할 때 필요한 자동화 capability만 최소 입력, 정책, 단계별 관찰, 피드백을 가진 셀프서비스 내부 제품으로 묶는다.
Docker는 CI/CD의 산출물 경로와 Kubernetes의 런타임 경로로 분기한다. Terraform은 L3 IAM·VPC에서 별도로 진입하고, 이 흐름들은 GitOps에서 승인 상태와 실제 상태의 소유권 관계로 합류한다. IDP는 그 뒤에 반드시 구축하는 완성 단계가 아니라, 조직의 반복 병목이 충분히 클 때 필요한 capability를 사용 가능한 제품으로 제공하는 선택이다.
6. 첫 회독과 선택 심화의 경계
섹션 제목: “6. 첫 회독과 선택 심화의 경계”첫 회독의 목표는 각 도구를 운영할 수 있는 수준이 아니라, 어떤 문제가 어느 책임 경계에 속하는지 설명하는 것이다.
| 토픽 | 첫 회독에서 붙잡을 것 | 선택 심화는 해당 본문에서 볼 범주 |
|---|---|---|
| 플랫폼 엔지니어링 | 인지 부하, 셀프서비스, Golden Path, 가드레일, 내부 제품 | 시장·구현 생태계와 성과 측정 |
| Docker | 이미지와 컨테이너의 차이, 재현 가능한 산출물, Linux 커널 공유 | 파일시스템, 빌드 최적화, 런타임 보안 메커니즘 |
| CI/CD | CI와 CD의 경계, 작은 통합, 불변 아티팩트, 실패 단계 | 클라우드 인증, 캐시, 배포 전략, 공급망 검증 |
| Git 전략 | 격리 → 검증 → 통합, 제품 릴리즈 모델에 맞는 전략 선택 | 병합 메커니즘, 병합 대기열, 기능 노출 제어와 운영 지표 |
| Terraform | desired state, plan, state, 소유권과 destroy/replace 위험 | 선언 언어, state 생명주기, import, 모듈·환경 분리 |
| Kubernetes | 선언과 수렴, Pod·Deployment·Service 책임, Docker 이후 문제 | 제어면, 자원·상태 검사, 접근 제어, 네트워크, 확장 |
| GitOps | desired/actual state, pull 모델, sync와 health, 단일 소유권 | 구현 도구, 다중 앱, 비밀 관리 연동, 점진적 전달 |
| IDP | 포탈과 IDP의 차이, What/How 경계, 필요한 capability 제품화 | 포탈 구현, scorecard, 직접 구축과 제품 도입 판단 |
Docker의 커널 내부나 Kubernetes의 제어면이 첫 회독에서 완전히 이해되지 않아도 다음 토픽으로 넘어갈 수 있다. 다만 “이미지와 실행 인스턴스”, “검증과 배포”, “인프라 plan과 런타임 reconciliation”, “sync와 실제 health”를 서로 구분하지 못하면 해당 경계의 선수 문서로 돌아가는 편이 낫다.
7. 막힐 때 돌아갈 곳
섹션 제목: “7. 막힐 때 돌아갈 곳”| 막히는 느낌 | 보통 부족한 전제 | 돌아갈 문서 |
|---|---|---|
| 컨테이너가 VM과 어떻게 다른지, 프로세스·파일·권한이 낯설다 | Linux의 실행·관찰 모델 | content/topics/L4/linux-basics.mdx |
| Namespace와 cgroups가 너무 추상적이고 OOM·CPU 제한이 연결되지 않는다 | Linux 격리와 자원 제한 | content/topics/L4/cgroups-namespace.mdx |
| Terraform의 Role, Policy, CI 클라우드 권한, AccessDenied가 어렵다 | AWS 권한의 주체·작업·리소스 모델 | content/topics/L3/iam.mdx |
| VPC, Subnet, Security Group의 관계 때문에 Terraform plan을 읽기 어렵다 | AWS 네트워크의 주소·경로·허용 규칙 | content/topics/L3/vpc-subnet-sg.mdx |
| Kubernetes가 Docker와 무엇이 다른지, ECS와 왜 비교되는지 모르겠다 | 컴퓨트와 오케스트레이션의 층 구분 | content/topics/L3/ecs-vs-ec2.mdx, content/topics/L5/docker-basics.mdx |
| CI/CD에서 이미지·레지스트리·승격이 한 흐름으로 보이지 않는다 | 배포 산출물의 정체 | content/topics/L5/docker-basics.mdx |
| GitOps가 CI/CD의 새 이름처럼 보인다 | 빌드·승격과 지속 수렴의 차이 | content/topics/L5/cicd-basics.mdx, content/topics/L5/kubernetes-basics.mdx |
| Terraform과 GitOps가 같은 리소스를 관리해도 될 것 같다 | desired state 소유권 경계 | content/topics/L5/terraform-iac-basics.mdx, content/topics/L5/gitops-basics.mdx |
| IDP가 포탈이나 도구 모음으로만 보인다 | 플랫폼의 등장 문제와 제품 철학 | content/topics/L5/what-is-platform-engineering.mdx |
Git의 branch, commit, merge, push, pull이 낯설다면 Git Flow & Branching 전에 기본 Git 사용 경험을 먼저 보완한다. 이는 해당 토픽의 external_prerequisites다. 반면 이 도입부 자체는 특정 CLI나 클라우드 실습 경험을 요구하지 않는다.
8. 들을 준비가 된 상태
섹션 제목: “8. 들을 준비가 된 상태”Readiness check
- 플랫폼 엔지니어링을 도구 도입이 아니라 반복 가능한 개발자 경로와 내부 제품의 문제로 설명할 수 있다.
- Docker 이미지는 불변 산출물이고 CI/CD는 그 산출물의 검증·전달 계약이라고 구분할 수 있다.
- Terraform의 plan·apply, Kubernetes의 지속 컨트롤러, GitOps의 Git 기준 조정이 서로 다른 desired-state 수렴 모델임을 설명할 수 있다.
- GitOps를 CI 대체제가 아니라 Git의 승인 상태와 클러스터 실제 상태를 계속 맞추는 운영 방식으로 설명할 수 있다.
- learning_order는 읽기 순서이고, Docker 분기·Terraform 독립 진입·GitOps 합류가 실제 prerequisite 관계임을 안다.
- IDP가 필수 종착점이 아니라 조직 병목에 필요한 capability를 제품화하는 선택임을 설명할 수 있다.
- 같은 리소스를 두 자동화 시스템이 함께 소유하면 두 수렴 루프가 충돌할 수 있음을 안다.
- 막히는 개념이 Linux, AWS 권한·네트워크, Docker, CI/CD, Kubernetes 중 어디에 속하는지 골라 돌아갈 수 있다.
이 체크는 모든 항목을 깊게 구현할 수 있는지 묻지 않는다. 다음 토픽을 읽을 때 낯선 용어를 어느 책임 경계에 놓을 수 있으면 충분하다.
9. Lineage — 분절된 운영에서 셀프서비스 경로까지
섹션 제목: “9. Lineage — 분절된 운영에서 셀프서비스 경로까지”L5의 lineage는 도구가 차례로 유행한 역사가 아니라, 앞 단계가 남긴 운영 책임을 다음 단계가 더 반복 가능한 계약으로 옮긴 흐름이다.
| 선행 단계가 남긴 한계 | 다음 단계가 추가한 해결 메커니즘 | 그래도 남는 경계 |
|---|---|---|
| 서버마다 런타임과 패키지가 다르다 | Docker가 실행 환경을 불변 이미지로 패키징한다 | 이미지를 언제 검증하고 전달할지는 정하지 않는다 |
| 사람이 빌드·테스트·배포를 순서대로 실행한다 | CI/CD가 작은 통합과 불변 아티팩트의 검증·전달 계약을 자동화한다 | 팀의 격리·리뷰·릴리즈 규칙은 별도다 |
| 병렬 변경의 위험을 늦게 흡수한다 | 브랜치 전략이 격리·검증·통합 시점을 정한다 | 클라우드 자원과 런타임 상태는 관리하지 않는다 |
| 콘솔과 스크립트 변경이 재현되지 않는다 | Terraform이 인프라를 plan·state·graph로 관리한다 | 클러스터 안 앱 상태의 상시 복구는 맡지 않는다 |
| 컨테이너의 다중 호스트 배치와 복구가 수동이다 | Kubernetes가 선언형 API와 컨트롤러로 런타임을 수렴시킨다 | 승인된 상태가 Git과 실제 클러스터 사이에서 어긋날 수 있다 |
| CI 권한과 수동 변경 때문에 운영 상태 추적이 흐려진다 | GitOps가 Git 기준 상태와 클러스터 actual state를 지속 조정한다 | 개발자가 여러 자동화를 직접 조립하면 인지 부하는 남는다 |
| 자동화는 있지만 특정 반복 요청의 경로가 분절되어 있다 | 필요할 때 IDP가 해당 capability를 Golden Path로 제품화한다 | 채택·피드백·예외·폐기까지 계속 제품으로 운영해야 한다 |
10. 이 레이어의 핵심 한 문장
섹션 제목: “10. 이 레이어의 핵심 한 문장”플랫폼 엔지니어링은 운영 복잡성을 개발자에게 떠넘기거나 포탈 뒤에 숨기는 일이 아니다. 반복되는 전달 과정을 선언·검증·수렴 가능한 경로로 만들고, 각 층의 소유권과 실패 신호를 선명하게 한 뒤, 조직의 병목에 필요한 capability를 개발자가 안전하게 사용할 수 있는 제품으로 제공하는 일이다.