2025년 10월 02일·7분
브렌던 번스와 쿠버네티스: 오케스트레이션을 형성한 아이디어
브렌던 번스 시대의 쿠버네티스 오케스트레이션 아이디어—선언적 상태, 컨트롤러, 스케줄링·스케일링, 서비스 운영—을 실용적으로 살펴보고 왜 표준이 되었는지 설명합니다.
브렌던 번스 시대의 쿠버네티스 오케스트레이션 아이디어—선언적 상태, 컨트롤러, 스케줄링·스케일링, 서비스 운영—을 실용적으로 살펴보고 왜 표준이 되었는지 설명합니다.
쿠버네티스는 단순히 새로운 도구를 도입한 것이 아니라, 수십~수백 개의 서비스를 운영할 때의 “일상 운영”이 무엇인지 자체를 바꿨습니다. 오케스트레이션 이전에는 팀들이 동일한 반복 질문에 답하기 위해 스크립트, 수동 런북, 그리고 전승된 노하우를 서로 엮어 사용하곤 했습니다. 이 서비스는 어디에 실행해야 하나? 어떻게 안전하게 변경을 배포하지? 새벽 2시에 노드가 죽으면 어떻게 하지?
핵심적으로 오케스트레이션은 당신의 의도(“이렇게 서비스 실행”)와 기계가 실패하고 트래픽이 변하며 배포가 계속되는 지저분한 현실 사이를 조정하는 계층입니다. 각 서버를 특별한 존재로 다루는 대신 오케스트레이션은 컴퓨팅을 풀(pool)로 보고, 워크로드를 이동 가능한 스케줄 단위로 취급합니다.
쿠버네티스는 팀들이 원하는 바를 기술하면 시스템이 지속적으로 현실을 그 설명과 일치시키려 노력하는 모델을 대중화했습니다. 이 전환은 운영을 영웅적 행위에서 반복 가능한 프로세스로 바꿨다는 점에서 중요합니다.
쿠버네티스는 대부분의 서비스 팀이 필요로 하는 운영 결과를 표준화했습니다:
이 글은 쿠버네티스(및 Brendan Burns 같은 리더들)와 관련된 아이디어와 패턴에 초점을 맞추며, 개인 전기는 아닙니다. "어떻게 시작되었나" 혹은 "왜 이렇게 설계되었나" 같은 주장은 컨퍼런스 발표, 설계 문서, 업스트림 문서 같은 공개 출처에 근거해야 신화가 아닌 검증 가능한 이야기로 남습니다.
Brendan Burns는 Joe Beda, Craig McLuckie와 함께 쿠버네티스의 초기 공동 창시자 중 한 명으로 널리 알려져 있습니다. 구글에서의 초기 쿠버네티스 작업에서 Burns는 기술적 방향뿐 아니라 사용자에게 "소프트웨어를 어떻게 운영할 것인지"를 설명하는 방식 형성에 기여했습니다(출처: Kubernetes: Up & Running, O’Reilly; 쿠버네티스 프로젝트 리포지토리의 AUTHORS/maintainers 목록).
쿠버네티스는 단순히 내부 시스템을 완성품으로 공개한 것이 아니라, 공개된 상태에서 기여자, 사용 사례, 제약이 늘어나는 가운데 구축되었습니다. 그 개방성은 다양한 환경에서 살아남을 수 있는 인터페이스로 프로젝트를 밀어 넣었습니다:
이런 협업 압력은 쿠버네티스가 무엇에 최적화했는지에 영향을 주었습니다: 많은 팀이 합의할 수 있는 공유 프리미티브와 반복 가능한 패턴입니다.
사람들이 쿠버네티스가 배포와 운영을 “표준화”했다고 할 때, 보통 모든 시스템을 동일하게 만들었다는 뜻은 아닙니다. 대신 공통 어휘와 여러 팀에서 반복해서 사용할 수 있는 워크플로를 제공했다는 의미입니다:
그 공통 모델 덕분에 문서, 도구, 팀 관행이 회사 간에 더 쉽게 전이될 수 있었습니다.
**쿠버네티스(오픈소스 프로젝트)**와 쿠버네티스 생태계를 구분하는 것이 유용합니다.
프로젝트는 플랫폼을 구현하는 핵심 API와 컨트롤 플레인 구성요소입니다. 생태계는 그 주위에 성장한 모든 것—배포판, 매니지드 서비스, 애드온, 인접 CNCF 프로젝트 등을 포함합니다. 많은 실사용 "쿠버네티스 기능"(관찰성 스택, 정책 엔진, GitOps 도구 등)은 핵심 프로젝트가 아니라 그 생태계 안에 존재합니다.
선언적 구성은 시스템을 설명하는 방식의 단순한 전환입니다: 수행할 단계를 나열하는 대신 원하는 최종 상태를 기술합니다.
쿠버네티스 관점에서는 플랫폼에 "컨테이너를 시작하고 포트를 열고 충돌 시 재시작하라"고 지시하지 않습니다. 대신 "이 앱의 복제본 3개가 이 포트로 도달 가능해야 하고 이 컨테이너 이미지를 사용해야 한다"고 선언합니다. 쿠버네티스는 현실을 그 선언과 일치시키는 책임을 집니다.
명령형 운영은 런북과 같습니다: 지난번에 통했던 일련의 명령을 환경이 변경될 때마다 다시 실행합니다.
원하는 상태는 계약에 가깝습니다. 구성 파일에 의도된 결과를 기록하고 시스템이 지속적으로 그 결과를 향해 작업합니다. 만약 드리프트가 발생하면(인스턴스가 죽거나 노드가 사라지거나 수동 변경이 끼어드는 경우) 플랫폼이 불일치를 감지하고 수정합니다.
이전(명령형 런북 사고):
이 접근법은 작동하지만, "스노우플레이크" 서버와 소수만 신뢰하는 긴 체크리스트가 생기기 쉽습니다.
이후(선언적 원하는 상태):
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout
spec:
replicas: 3
selector:
matchLabels:
app: checkout
template:
metadata:
labels:
app: checkout
spec:
containers:
- name: app
image: example/checkout:1.2.3
ports:
- containerPort: 8080
파일(예: image나 replicas)을 변경해 적용하면 쿠버네티스의 컨트롤러들이 실행 중인 상태를 선언과 맞추기 위해 조정합니다.
선언적 원하는 상태는 "이 17단계를 수행하라"를 "이 상태를 유지하라"로 바꿈으로써 운영의 고된 작업을 줄입니다. 또한 구성의 원천이 명시적이고 검토 가능(종종 버전 관리)에 있기 때문에 깜짝 상황을 찾고 감사하며 일관되게 롤백하기가 쉬워집니다.
쿠버네티스가 "스스로 관리하는" 느낌을 주는 이유는 간단한 패턴을 중심으로 설계되었기 때문입니다: 당신이 원하는 것을 기술하면 시스템이 지속적으로 현실을 그 기술과 일치시키려 작동합니다. 이 패턴의 엔진이 바로 컨트롤러입니다.
컨트롤러는 클러스터의 현재 상태를 감시하고 YAML(또는 API 호출)로 선언된 원하는 상태와 비교하는 루프입니다. 격차를 발견하면 그 격차를 줄이기 위한 행동을 취합니다.
한 번 실행되는 스크립트가 아니며 사람이 버튼을 누르길 기다리지도 않습니다. 반복적으로 실행됩니다—관찰, 결정, 행동—그래서 언제든지 변화에 반응할 수 있습니다.
이 반복적인 비교 및 수정 행동을 리컨실리에이션이라고 부릅니다. 이것이 흔히 말하는 "셀프히얼링(self-healing)"의 메커니즘입니다. 시스템이 실패를 마법처럼 막아주는 것은 아니지만, 드리프트를 감지하고 고칩니다.
드리프트는 평범한 이유로 발생합니다:
리컨실리에이션은 쿠버네티스가 이러한 사건들을 의도로 재점검하고 복원해야 할 신호로 취급한다는 뜻입니다.
컨트롤러는 익숙한 운영 결과로 이어집니다:
핵심은 수동으로 증상을 쫓아다니는 것이 아니라, 목표를 선언하면 제어 루프가 연속적으로 "유지하기" 작업을 수행한다는 점입니다.
이 접근법은 하나의 리소스 타입에 국한되지 않습니다. 쿠버네티스는 동일한 컨트롤러-리컨실리에이션 아이디어를 Deployment, ReplicaSet, Job, Node, Endpoint 등 여러 객체에 적용합니다. 이 일관성이 쿠버네티스를 플랫폼으로 만든 큰 이유입니다: 패턴을 이해하면 새 기능을 추가할 때 시스템이 어떻게 동작할지 예측할 수 있습니다(커스텀 리소스도 동일한 루프를 따릅니다).
쿠버네티스가 단지 "컨테이너를 실행"만 했다면, 여전히 가장 어려운 부분이 남습니다: 각 워크로드를 어디에 실행할지 결정하는 일. 스케줄링은 파드를 노드에 자동으로 배치하는 내장 시스템으로, 리소스 요구와 정의한 규칙에 따라 작동합니다.
배치 결정은 가용성과 비용에 직접적으로 영향을 줍니다. 혼잡한 노드에 걸린 웹 API는 느려지거나 실패할 수 있고, 지연 민감 서비스 옆에 배치된 배치 작업은 노이즈 문제를 일으킬 수 있습니다. 쿠버네티스는 이를 스프레드시트와 SSH 루틴 대신 반복 가능한 제품 기능으로 바꿉니다.
기본적으로 스케줄러는 파드의 요청을 만족할 수 있는 노드를 찾습니다.
이 한 가지 습관—현실적인 요청 설정—만으로도 중요한 서비스가 다른 것들과 경쟁하지 않게 되어 "무작위" 불안정성이 줄어드는 경우가 많습니다.
자원 외에도 대부분의 프로덕션 클러스터는 몇 가지 실용 규칙을 사용합니다:
스케줄링 기능은 팀들이 운영 의도를 코드화하게 도와줍니다:
실용적 핵심: 스케줄링 규칙을 제품 요구사항처럼 다루세요—문서화하고 검토하며 일관되게 적용하세요—그래야 신뢰성이 새벽 2시에 누군가의 "올바른 노드 기억력"에 의존하지 않습니다.
쿠버네티스의 가장 실용적인 아이디어 중 하나는 스케일링이 애플리케이션 코드를 변경하거나 새로운 배포 방식을 발명할 필요가 없어야 한다는 것입니다. 앱이 하나의 컨테이너로 실행될 수 있다면 동일한 워크로드 정의로 보통 수백~수천 복제로 성장할 수 있습니다.
쿠버네티스는 스케일링을 두 관련 결정으로 분리합니다:
이 분리는 중요합니다: 200개의 파드를 요청할 수 있지만 클러스터에 50개만 배치할 공간이 있다면 "스케일링"은 대기 중인 작업의 큐가 됩니다.
쿠버네티스는 보통 세 가지 오토스케일러를 사용합니다. 각기 다른 레버에 초점을 맞춥니다:
이들을 함께 사용하면 스케일링은 "대기시간을 안정적으로 유지"하거나 "CPU를 대략 X%로 유지" 같은 정책이 됩니다. 수동으로 사람을 호출하는 절차가 아닙니다.
스케일링은 입력이 잘못되면 효과가 떨어집니다:
반복되는 두 가지 실수: 잘못된 메트릭으로 스케일링(CPU가 낮은데 요청이 타임아웃됨)과 리소스 요청 누락(오토스케일러가 용량을 예측 못해 파드가 너무 빽빽하게 배치되어 성능 불안정).
쿠버네티스가 널리 퍼뜨린 큰 전환은 "배포"를 5시 금요일에 한 번 실행하는 스크립트가 아니라 지속적으로 제어해야 하는 문제로 본다는 점입니다. 롤아웃과 롤백은 일급 행동입니다: 어떤 버전을 원하는지 선언하면 쿠버네티스가 그 변경을 진행하면서 실제로 안전한지 계속 확인합니다.
Deployment를 사용하면 롤아웃은 오래된 파드를 새 것으로 점진적으로 교체하는 과정입니다. 모든 것을 멈추고 다시 시작하는 대신 쿠버네티스는 단계를 밟아 업데이트를 수행할 수 있어 가용성을 유지하면서 새 버전이 실제 트래픽을 처리할 수 있는지 검증합니다.
새 버전이 실패하기 시작하면 롤백은 비상 절차가 아니라 정상적인 작업입니다: 이전 ReplicaSet(마지막 알려진 정상 버전)으로 되돌리고 컨트롤러가 옛 상태를 복원하게 하면 됩니다.
헬스 체크는 롤아웃을 희망 기반이 아닌 측정 가능한 것으로 바꿉니다.
프로브를 잘 활용하면 파드는 시작되었지만 실제 요청을 실패하는 "겉보기 정상" 배포를 줄일 수 있습니다.
쿠버네티스는 기본적으로 롤링 업데이트를 지원하지만 팀들은 종종 다음을 덧붙입니다:
안전한 배포는 에러율, 지연, 포화도, 사용자 영향 같은 신호에 좌우됩니다. 많은 팀은 롤아웃 결정을 SLO와 에러 버짓에 연결합니다—카나리가 너무 많은 버짓을 소모하면 승격이 중단됩니다.
목표는 실패 시 자동 롤백 트리거(실패한 readiness, 증가하는 5xx, 지연 급상승)에 기반해 "롤백"이 예측 가능한 시스템 응답이 되게 하는 것입니다. 늦은 밤 영웅적 개입이 아니라 체계적 반응입니다.
컨테이너 플랫폼이 자동으로 느껴지려면 다른 시스템 구성 요소들이 앱이 이동한 뒤에도 여전히 찾을 수 있어야 합니다. 실제 프로덕션 클러스터에서 파드는 생성되고 삭제되며 재스케줄되고 스케일됩니다. 만약 모든 변화마다 IP 주소를 설정 파일에 업데이트해야 한다면 운영은 끊임없는 손일이 되고 다운타임은 일상적이 될 것입니다.
서비스 디스커버리는 변화하는 백엔드 집합에 클라이언트가 신뢰성 있게 도달할 수 있는 방법을 제공합니다. 쿠버네티스에서는 개별 인스턴스("10.2.3.4에 호출")를 대상으로 삼는 것을 멈추고 대신 이름("checkout")을 대상으로 삼습니다. 플랫폼이 어떤 파드가 그 이름에 응답하는지 관리합니다.
Service는 파드 집합을 위한 안정적인 정문입니다. 기본적으로 클러스터 내부에서 일관된 이름과 가상 주소를 가지며, 그 아래의 파드가 바뀌어도 그대로 유지됩니다.
Selector는 쿠버네티스가 어떤 파드를 그 정문 뒤에 둘지 결정하는 방식입니다. 보통 app=checkout 같은 라벨을 매칭합니다.
Endpoints(또는 EndpointSlices)는 현재 셀렉터와 일치하는 실제 파드 IP의 살아있는 목록입니다. 파드가 스케일 업/다운하거나 재스케줄되면 이 목록이 자동으로 업데이트되어 클라이언트는 동일한 Service 이름을 계속 사용합니다.
운영적으로 제공하는 것들:
클러스터 외부로의 north–south 트래픽은 보통 Ingress 또는 최신 Gateway 접근법을 사용합니다. 둘 다 호스트명이나 경로로 요청을 라우팅하고 TLS 종료 같은 문제를 중앙에서 처리할 수 있게 해줍니다. 핵심 아이디어는 같습니다: 외부 접근을 안정적으로 유지하면서 백엔드는 그 아래에서 바뀝니다.
쿠버네티스의 "셀프히얼링"은 마법이 아닙니다. 재시작, 재스케줄, 교체라는 자동 반응들의 집합입니다. 플랫폼이 당신이 원한다고 말한 상태(원하는 상태)를 감시하고 현실을 지속적으로 그쪽으로 밀어넣습니다.
프로세스가 종료되거나 컨테이너가 건강하지 않게 되면 쿠버네티스는 같은 노드에서 재시작할 수 있습니다. 이는 보통 다음에 의해 구동됩니다:
일반적인 프로덕션 패턴: 단일 컨테이너 충돌 → 쿠버네티스가 재시작 → 서비스는 헬시한 파드로만 라우팅 유지.
전체 노드가 내려가면(하드웨어 문제, 커널 패닉, 네트워크 단절) 쿠버네티스는 노드를 사용 불가로 감지하고 작업을 다른 곳으로 옮기기 시작합니다. 높은 수준에서:
이것이 클러스터 수준의 "셀프히얼링": 시스템이 용량을 대체하지 인간이 SSH로 들어가기를 기다리지 않습니다.
셀프히얼링은 그것이 작동한다는 것을 검증할 수 있어야 의미가 있습니다. 팀들은 보통 다음을 관찰합니다:
쿠버네티스가 있어도 "치유"가 실패할 수 있습니다:
셀프히얼링이 잘 설정되면 장애는 더 작고 짧아지며, 더 중요하게는 측정 가능해집니다.
쿠버네티스가 승리한 이유는 단지 컨테이너를 돌릴 수 있어서가 아닙니다. 가장 흔한 운영 필요(배포, 스케일링, 네트워킹, 관찰)에 대해 표준 API를 제공했기 때문입니다. 팀들이 동일한 객체 형태(예: Deployment, Service, Job)에 동의하면 도구를 조직 간에 공유할 수 있고, 교육이 쉬워지며 개발자와 운영 간 인수인계가 전승 지식에 의존하지 않게 됩니다.
일관된 API는 배포 파이프라인이 모든 앱의 특이사항을 알 필요 없게 합니다. 동일한 쿠버네티스 개념으로 생성, 업데이트, 롤백, 건강 검사 같은 동일한 작업을 수행할 수 있습니다.
또한 정렬을 개선합니다: 보안 팀은 정책으로 가드레일을 표현할 수 있고, SRE는 공통 헬스 신호에 대한 런북을 표준화할 수 있으며, 개발자는 공통 어휘로 릴리스를 이해할 수 있습니다.
플랫폼 전환은 **Custom Resource Definitions(CRDs)**로 명확해집니다. CRD는 클러스터에 Database, Cache, Queue 같은 새로운 객체 타입을 추가하게 해주고, 이를 내장 리소스와 동일한 API 패턴으로 관리할 수 있게 합니다.
Operator는 그 커스텀 객체와 컨트롤러를 결합해 원하는 상태를 지속적으로 리컨실리할 뿐 아니라 백업, 페일오버, 업그레이드 같은 수동 작업을 자동화합니다. 핵심 이득은 마법이 아니라 쿠버네티스가 다른 모든 것에 적용하는 동일한 제어 루프 방식을 재사용하는 것입니다.
쿠버네티스는 API 중심이기 때문에 현대 워크플로와 자연스럽게 통합됩니다:
더 실용적인 배포 및 운영 가이드가 필요하면 /blog를 둘러보세요.
브렌던 번스의 초기 프레이밍과 연관된 큰 쿠버네티스 아이디어들은 VM, 서버리스, 혹은 더 작은 컨테이너 환경에서도 잘 적용됩니다.
원하는 상태를 문서화하고 자동화가 그것을 강제하게 하라. Terraform, Ansible, CI 파이프라인 등 무엇이든 구성은 진실의 원천으로 다루세요. 결과는 수동 배포 단계 감소와 "내 환경에서만 작동" 문제 감소입니다.
일회성 스크립트가 아닌 리컨실리에이션을 사용하라. 한 번 실행되는 스크립트 대신 핵심 속성(버전, 구성, 인스턴스 수, 헬스)을 지속적으로 검증하는 루프를 만들면 반복 가능한 운영과 장애 후 예측 가능한 복구를 얻을 수 있습니다.
스케줄링과 스케일링을 명확한 제품 기능으로 만들어라. 언제 왜 용량을 늘리는지(CPU, 큐 깊이, 지연 SLO)를 정의하세요. 쿠버네티스 오토스케일링이 없어도 팀은 스케일 규칙을 표준화해 성장이 앱 재작성이나 호출로 이어지지 않게 할 수 있습니다.
롤아웃을 표준화하라. 롤링 업데이트, 헬스 체크, 빠른 롤백 절차는 변경 리스크를 줄입니다. 로드밸런서, 기능 플래그, 릴리스 파이프라인을 통해 실제 신호에 걸어 배포를 차단/진행하도록 구현할 수 있습니다.
이 패턴들이 잘못된 앱 설계, 안전하지 않은 데이터 마이그레이션, 비용 통제 같은 문제를 자체적으로 해결하지는 못합니다. 버전화된 API, 마이그레이션 계획, 예산/제한, 배포가 고객 영향과 어떻게 연결되는지 보여주는 관찰성이 여전히 필요합니다.
한 개의 고객 대상 서비스를 골라 체크리스트를 끝까지 적용해 보세요. 그 후 확장하십시오.
새 서비스를 더 빨리 "배포 가능한 상태"로 만들고 싶다면 Koder.ai는 채팅 기반 스펙에서 전체 웹/백엔드/모바일 앱을 생성하는 데 도움을 줄 수 있습니다—보통 프론트엔드는 React, 백엔드는 Go와 PostgreSQL, 모바일은 Flutter로 생성되며 소스 코드를 내보내 쿠버네티스 패턴(선언적 구성, 반복 가능한 롤아웃, 롤백 친화적 운영)을 적용할 수 있습니다. 비용과 거버넌스를 평가하는 팀은 /pricing을 검토할 수 있습니다.
오케스트레이션은 당신의 의도(무엇을 실행해야 하는지)와 실제 세계의 변화(노드 장애, 롤링 배포, 스케일링 이벤트)를 연결해 조정하는 역할을 합니다. 개별 서버를 관리하는 대신 워크로드를 관리하고 플랫폼이 자동으로 배치, 재시작, 교체하도록 맡깁니다.
실용적으로 줄여주는 항목:
선언적 구성은 당신이 원하는 최종 결과를 기술합니다(예: “이 이미지를 가진 인스턴스 3개를 이 포트로 노출”). 절차를 일일이 적는 대신 상태를 선언하면 시스템이 그 상태가 유지되도록 책임을 집니다.
즉시 활용할 수 있는 장점:
컨트롤러는 현재 상태와 선언된 원하는 상태를 비교하고 그 격차를 줄이기 위해 행동하는 지속 실행 제어 루프입니다.
이것이 쿠버네티스가 "스스로 관리하는" 결과를 내는 이유입니다:
스케줄러는 제약과 가용 용량을 기반으로 각 파드를 어느 노드에 둘지 결정합니다. 이를 안내하지 않으면 노이즈가 심한 이웃, 핫스팟, 복제본이 같은 노드에 몰리는 문제가 발생할 수 있습니다.
운영 의도를 코드화하는 일반 규칙:
요청(request)은 스케줄러에 파드가 필요로 하는 리소스를 알려주고, 리밋(limit)은 파드가 최대 사용할 수 있는 용량을 제한합니다. 현실적인 요청이 없으면 배치가 추측으로 이루어지고 안정성이 흔들리기 쉽습니다.
실용적 시작점:
Deployment의 롤아웃은 오래된 파드를 새 파드로 점진적으로 교체하는 제어된 전환입니다. 중단 없이 용량을 유지하면서 새 버전이 실제 트래픽을 소화하는지 검증할 수 있습니다.
안전한 롤아웃을 위해:
기본적으로 쿠버네티스는 롤링 업데이트를 제공하지만 팀들은 종종 다음과 같은 고수준 패턴을 추가합니다:
선택 기준은 리스크 허용치, 트래픽 형태, 회귀를 얼마나 빨리 탐지할 수 있는지에 달려 있습니다(에러율/지연/SLO 소모량 등).
서비스 디스커버리는 변화하는 백엔드 집합에 클라이언트가 안정적으로 도달할 방법을 제공합니다. 쿠버네티스에서는 개별 인스턴스(IP)를 직접 호출하는 대신 이름(예: checkout)을 호출하면 플랫폼이 어떤 파드가 그 이름에 응답하는지 관리합니다.
운영적으로 의미하는 것:
오토스케일링은 각 레이어가 명확한 신호를 가질 때 가장 잘 동작합니다:
흔한 실수:
CRD는 Database, Cache 같은 새로운 API 객체를 정의하게 해주어 더 높은 수준의 시스템을 쿠버네티스 API로 관리하게 합니다.
Operator는 이런 CRD와 컨트롤러를 묶어 원하는 상태를 실제 상태로 조정하면서 다음과 같은 작업을 자동화합니다:
운영에 도입할 때는 성숙도, 관찰성, 실패 모드를 평가하여 신중히 사용하세요.