리컨실리에이션 루프 작동 원리 — 디플로이먼트 상태 일치를 위한 자가 치유

TL;DR — 리컨실리에이션 루프는 쿠버네티스 컨트롤러가 원하는 상태와 현재 상태의 차이를 관찰·비교·조정으로 끝없이 줄이는 반복 구조이며, 자가 치유와 선언형 배포가 모두 이 구조 위에서 동작합니다.

2026년 프로덕션 운영 환경에서 쿠버네티스를 도입하려는 인프라 담당자와 개발자가 왜 파드가 죽어도 서비스가 되살아나는지, 어떻게 매니페스트 한 장으로 수십 개의 파드가 유지되는지 이해하기 위한 열쇠가 리컨실리에이션 루프입니다. 이 글은 클라우드네이티브TV의 영상 ‘쿠버네티스 리컨실리에이션 루프란 — 선언형 설정이 동작하는 원리'(입문 9편, 5분 22초)를 주장 단위로 풀어 정리했습니다. 영상을 보지 않은 독자도 리컨실리에이션 루프가 무엇을 반복하고, 어떤 컨트롤러가 어떤 순서로 이어 달리는지 따라올 수 있도록 캡처 6장과 함께 설명합니다.

클라우드네이티브TV의 이 영상은 5분 22초 동안 쿠버네티스의 핵심 원리에 붙은 이름, 곧 리컨실리에이션 루프를 다섯 걸음으로 설명합니다. 먼저 스스로 낫는 동작을 보여 주고, 그 뿌리에 있는 제어 루프를 풀고, 매니페스트가 컨트롤러의 감시 대상이 되는 흐름을 따라간 다음, 숫자 예시와 컨트롤러 사슬로 안쪽을 들여다보며, 마지막에 네 가지 핵심 정리로 닫습니다.

영상에서 다루는 순서는 다음과 같습니다.

• 스스로 낫는 자가 치유 동작과 가로등 비유 (1:09)
• 컨트롤러가 들고 있는 두 값과 제어 루프 (1:49)
• 매니페스트를 감시하며 파드 수를 맞추는 컨트롤러 (2:47)
• 원하는 5개, 현재 2개로 따라가는 세 걸음 (3:25)
• 디플로이먼트에서 파드까지 이어 달리는 컨트롤러 (4:03)
• 지금까지의 내용을 묶는 네 가지 정리 (4:44)

리컨실리에이션 루프에 관한 영상의 설명을 질문으로 바꾸면 여섯 가지입니다. 아래 여섯 개 절이 이 순서대로 답하고, 뒤에 영상 밖의 보충 한 절을 더했습니다.

1. 쿠버네티스는 장애가 나면 어떻게 스스로 낫는가?
2. 자가 치유의 뿌리에 있는 제어 루프는 무엇을 반복하는가?
3. 매니페스트에 적은 선언은 어떻게 파드 수로 이어지는가?
4. 원하는 상태와 현재 상태의 차이는 어떤 세 걸음으로 메워지는가?
5. 디플로이먼트를 만들면 왜 파드까지 단계적으로 만들어지는가?
6. 이 모든 것을 영상은 어떤 네 가지로 묶는가?

쿠버네티스의 오케스트레이션은 잘 돌아가는지 계속 지켜보다가, 문제가 보이면 스스로 고치고, 다시 상태를 확인하는 일을 쉬지 않고 되풀이합니다. 영상은 이 동작을 ‘자가 치유(Self-Healing)’라 부르며 리컨실리에이션 루프의 가장 눈에 띄는 모습으로 소개합니다.

영상이 보여 주는 루프는 네 칸입니다. 정상 가동(Running) 상태에서 장애 감지(Detect)가 일어나고, 복구·재구성(Recover)을 거쳐, 상태 확인(Verify)으로 다시 정상 가동에 돌아옵니다. 한 바퀴가 끝나면 곧바로 다음 바퀴가 시작되므로, 운영자가 화면 앞에서 지켜보지 않아도 정상 상태로 돌아가는 일이 계속 이어집니다.

▲ 자가 치유 루프와 두 가지 복구 방식 (영상 1:09)

캡처 위쪽 노란 띠에는 ‘오케스트레이션은 장애를 감지하고 스스로 복구한다 — 운영자의 개입 없이 정상 상태를 되찾는다’는 요지가 적혀 있습니다. 왼쪽 원형 도식이 정상 가동, 장애 감지, 복구·재구성, 상태 확인의 순환을 보여 주고, 오른쪽에는 복구 방식이 두 갈래로 나뉩니다. 무상태(Stateless) 애플리케이션은 어느 복제본이든 똑같으므로 장애가 나면 즉시 동일한 복제본으로 교체합니다. 상태가 있는(Stateful) 애플리케이션은 데이터와 상태를 보존해야 하므로 영구 볼륨(Persistent Volume)과 함께 장애별 대응으로 동적으로 복구합니다.

영상은 이 구조를 마을의 가로등에 빗댑니다. 가로등이 나가면 자동으로 신고가 들어가는 마을에서는 사람이 일일이 살피지 않아도 불이 계속 켜져 있다는 이야기입니다. 여기서 눈여겨볼 점은 복구의 주체가 사람의 판단이 아니라 반복되는 확인 절차라는 것입니다. 무상태 애플리케이션은 교체가 곧 복구이고, 상태가 있는 쪽은 데이터를 안전하게 이어 붙이는 일이 복구의 핵심이므로, 같은 루프라도 대상에 따라 하는 일이 달라집니다.

자가 치유의 뿌리에는 제어 루프(Control Loop)가 있습니다. 영상은 컨트롤러가 두 가지 값을 들고 있다고 설명합니다. 하나는 원하는 상태(Desired State), 다른 하나는 현재 상태(Actual State)입니다.

예를 들어 매니페스트에 ‘파드 5개를 유지하라’고 적어 두었다고 해 봅시다. 이것이 원하는 상태입니다. 컨트롤러가 클러스터를 살펴보니 지금 파드가 3개만 실행 중이라면, 그것이 현재 상태입니다. 컨트롤러는 두 값이 얼마나 벌어졌는지 계산하고, 그 차이를 없애는 쪽으로 손을 씁니다. 그리고 두 값이 같아질 때까지 이 일을 끝없이 되풀이합니다.

▲ 제어 루프의 원하는 상태와 현재 상태 (영상 1:49)

캡처 왼쪽의 원형 도식은 관찰(Observe), 비교(Analyze), 조정(Act)의 세 칸이 맞물려 도는 모양이고, 각 칸 옆에는 ‘현재 상태 모니터링’, ‘원하는 상태와 현재 상태의 비교’, ‘현재 상태를 원하는 상태로 조정’이라는 설명이 붙어 있습니다. 오른쪽 위 상자는 원하는 상태가 ‘Pod 5개를 유지하라’는 매니페스트 선언이고 현재 상태가 ‘지금 Pod 3개 실행 중’이라는 클러스터 관찰 결과임을 나란히 보여 줍니다. 오른쪽 아래 목록은 컨트롤러가 하는 일을 네 줄로 정리합니다. 클러스터 상태를 관찰하고, 원하는 상태와 현재 상태의 차이를 계산하고, 차이를 없애도록 생성·삭제·변경을 요청하고, 두 값이 같아질 때까지 무한히 반복합니다.

영상의 비유는 에어컨입니다. 에어컨은 설정 온도를 향해 계속 켜고 끄기를 반복하며 방 안 온도를 그 값에 붙잡아 둡니다. 설정 온도가 원하는 상태이고 실내 온도가 현재 상태인 셈입니다. 이 비유가 알려 주는 것은 리컨실리에이션 루프가 한 번 실행하고 끝나는 명령이 아니라 계속 돌아가는 방식이라는 점입니다. 명령은 실행되면 끝나지만, 루프는 목표가 유지되는 동안 계속 상태를 확인합니다.

제어 루프가 실제로 어떻게 흐르는지는 매니페스트를 등록하는 장면에서 가장 잘 보입니다. 영상은 매니페스트를 등록하면 컨트롤러가 그것을 지켜보고, 선언한 상태에 맞춰 파드를 만들거나 지운다고 설명합니다.

영상의 예시는 홈페이지, 포탈, 모바일, 그룹웨어 네 가지 서비스입니다. 운영자는 각 서비스가 몇 개씩 필요한지만 적어 둡니다. 그러면 컨트롤러가 그 수를 늘 맞춰 놓습니다. 파드가 죽어도 곧바로 새로 만들어 빈자리를 채웁니다. 운영자가 한 일은 개수를 선언한 것뿐이고, 만들고 지우고 다시 채우는 일은 모두 컨트롤러가 맡습니다.

▲ 매니페스트를 감시하는 컨트롤러 (영상 2:47)

캡처 왼쪽에는 코드 창으로 표현된 매니페스트 파일이 있고, 가운데 쿠버네티스 로고 오른쪽에는 홈페이지·포탈·모바일·그룹웨어별로 파드가 줄지어 놓인 격자가 있습니다. 가장 아래에는 베어 메탈 서버가 받침대처럼 깔려 있고, 오른쪽에는 ‘컨트롤러’와 ‘컨테이너 관리(생성/삭제)’, 그리고 ‘Reconciliation Loop’라는 이름이 붙은 순환 도식이 그려져 있습니다. 화살표는 매니페스트가 ‘등록’되고 쿠버네티스가 ‘감시’하는 방향을 보여 줍니다.

영상은 이 장면을 가게 진열대에 빗댑니다. 물건이 팔려 빈자리가 생기면 직원이 바로 채워 넣는 모습입니다. 이 비유에서 직원의 일은 ‘지금 진열대에 몇 개가 비었는가’를 보고 ‘원래 몇 개가 있어야 하는가’와 비교해 채우는 것이며, 이것이 곧 리컨실리에이션 루프의 한 바퀴입니다. 또 하나 짚을 점은 선언은 구체적인 명령이 아니라 목표라는 것입니다. 운영자가 파드를 하나씩 만들라고 지시하지 않았는데도 결과가 맞춰지는 이유는, 목표와 현실의 차이를 줄이는 책임이 컨트롤러에 있기 때문입니다.

영상은 숫자를 하나 놓고 세 걸음을 따라가 봅니다. 원하는 컨테이너 수는 5개인데 지금은 2개입니다.

첫 걸음은 관찰(Observe)입니다. 지금 상태를 확인해 2개가 떠 있음을 알아냅니다. 둘째 걸음은 비교(Analyze)입니다. 원하는 값 5와 현재 값 2를 견주어 3개가 모자란다는 것을 계산합니다. 셋째 걸음은 조정(Act)입니다. 모자란 3개를 새로 만들어 5개로 맞춥니다. 영상은 이것을 ‘관찰하고, 따져 보고, 손을 쓰는 세 걸음’이라 부르고, 두 값이 같아지면 루프가 다시 처음으로 돌아간다고 덧붙입니다.

▲ 관찰, 비교, 조정 세 걸음 (영상 3:25)

캡처는 세 칸의 카드로 되어 있습니다. 왼쪽 파란 카드는 현재 상태 확인(Observe)으로, 원하는 컨테이너 5개와 현재 2개를 빈 칸과 채워진 칸으로 보여 줍니다. 가운데 카드는 비교(Analyze)로, 부족한 칸이 ‘3개 부족’이라는 큰 글자와 함께 표시됩니다. 오른쪽 초록 카드는 일치(Act)로, 3개를 새로 만들고 나면 5개가 모두 채워져 ‘상태 일치’ 표시가 뜨는 장면입니다. 카드 아래에는 actual과 desired가 같아지면 루프가 다시 반복된다는 설명이 붙어 있습니다.

이 세 걸음에서 실무에 중요한 것은 조정이 차이만큼만 일어난다는 점입니다. 5개를 원하는데 2개가 있으면 5개를 새로 만드는 것이 아니라 3개를 더합니다. 반대로 원하는 값이 줄면 남는 만큼을 지웁니다. 또한 루프는 조정이 끝난 뒤에도 멈추지 않습니다. 누군가 파드를 직접 지우거나 노드가 사라져 현재 상태가 바뀌면, 다음 관찰에서 다시 차이가 드러나고 같은 세 걸음이 이어집니다. 앞서 본 자가 치유가 따로 구현된 기능이 아니라 이 루프의 자연스러운 결과인 까닭이 여기에 있습니다.

영상은 조금 더 안쪽으로 들어가, 컨트롤러는 하나가 아니라 여럿이 이어 달린다고 말합니다. 디플로이먼트를 작성하면 디플로이먼트 컨트롤러가 그것을 지켜보고 레플리카셋을 만듭니다. 이번에는 레플리카셋 컨트롤러가 레플리카셋을 지켜보고 파드를 만듭니다. 각 단계가 저마다 독립된 리컨실리에이션 루프로 돕니다.

영상은 이를 계주에 빗댑니다. 주자들이 자기 구간만 책임지고 배턴을 넘기는 것처럼, 각 컨트롤러는 자기가 감시하는 리소스 하나만 책임집니다. 디플로이먼트 컨트롤러는 배포 선언이 레플리카셋으로 반영됐는지를, 레플리카셋 컨트롤러는 선언한 복제 수만큼 파드가 있는지를 봅니다.

▲ 디플로이먼트에서 파드까지 이어지는 컨트롤러 (영상 4:03)

캡처 위쪽 노란 띠의 요지는 ‘여러 컨트롤러가 각자의 리소스를 감시하며 단계적으로 조정한다 — Deployment → ReplicaSet → Pod’입니다. 왼쪽 위 Deployment(원하는 배포 선언)는 Deployment Controller가 감시(Watch)하고, 이 컨트롤러가 ReplicaSet(복제본 수 관리)을 만듭니다(Create). ReplicaSet은 다시 ReplicaSet Controller가 감시하며, 이 컨트롤러가 파드를 만듭니다. 오른쪽 상자는 선언한 복제 수만큼 파드가 스케줄·실행되고, 파드가 사라지면 컨트롤러가 다시 생성하며, 각 단계가 독립적인 Reconciliation Loop로 동작한다고 정리합니다.

아래 세 상자도 눈여겨볼 만합니다. 첫째 ‘컨트롤러의 역할’은 클러스터 리소스를 감시하고 원하는 상태를 유지하도록 조정하는 핵심 구성 요소라는 설명입니다. 둘째 ‘Level-Based API’는 중간 상태(이벤트)를 무시하고 항상 최신 Spec을 기준으로 상태를 조정한다는 뜻입니다. 영상 말로는 ‘언제나 가장 최신 선언을 기준으로 맞춘다’는 이야기입니다. 셋째 ‘핵심 구성 요소’는 Informer·WorkQueue·Reconciler로 효율적이고 안정적인 상태 관리를 수행한다는 내용입니다.

Level-Based라는 말은 해석이 필요합니다. 파드가 몇 번 죽었다 살아났는지 같은 사건의 이력을 따라가며 반응하는 것이 아니라, 지금 이 순간의 원하는 상태와 현재 상태만 비교해 반응한다는 의미입니다. 그래서 컨트롤러가 잠시 멈췄다 돌아와도 놓친 사건을 복원할 필요 없이 최신 선언만 보면 됩니다. 이 단순함이 루프를 안정적으로 만드는 기반입니다.

영상이 설명한 원리를 운영에 옮길 때는 몇 가지를 점검해야 한다는 사실이 따라옵니다. 쿠버네티스 공식 문서는 컨트롤러를 ‘클러스터의 상태를 지켜보다가 필요할 때 변경을 요청하거나 직접 수행하며, 현재 상태를 원하는 상태에 가깝게 만드는 제어 루프’로 설명합니다. 이 정의에서 곧바로 이어지는 운영 기준을 표로 묶으면 다음과 같습니다.

가장 흔한 함정은 선언과 다르게 손으로 고치는 일입니다. 루프는 매니페스트에 적힌 원하는 상태를 기준으로 현재 상태를 되돌리므로, 클러스터에서 파드를 직접 만들거나 지워 보아도 선언과 다르면 다음 조정에서 선언대로 돌아갑니다. 의도한 변경은 매니페스트를 고쳐 선언 자체를 바꾸는 것이 맞습니다. 이렇게 하면 변경 이력이 코드 저장소에 남아 깃옵스와도 자연스럽게 이어집니다.

또 하나는 루프가 만능이 아니라는 점입니다. 루프는 선언한 복제 수와 파드의 존재를 맞춰 주지만, 애플리케이션 안에서 일어나는 논리 오류까지 고쳐 주지는 않습니다. 컨테이너가 떠 있지만 요청에 응답하지 못한다면 그 상태를 알려 주는 상태 점검(헬스 체크) 설정을 따로 준비해야 합니다. 컨트롤러가 ‘현재 상태’를 정확히 읽을 수 있어야 비교가 의미를 갖기 때문입니다.

컨트롤러의 정의는 쿠버네티스 공식 문서의 컨트롤러 설명에서, 디플로이먼트가 레플리카셋을 거쳐 파드를 관리하는 방식은 디플로이먼트 문서에서 확인할 수 있습니다. 조정 루프를 컨트롤러와 오퍼레이터 패턴까지 넓혀 보려면 3.5.2 조정 루프 (Reconciliation Loop)를 함께 읽어 볼 만합니다. 쿠버네티스의 구성 요소를 먼저 이해하려면 쿠버네티스 아키텍처 완벽 정리를, 선언적 API가 자동화로 이어지는 흐름은 쿠버네티스가 제공하는 선언적 API와 자동화의 힘에서 이어 읽을 수 있습니다.

영상의 마지막 장면은 지금까지의 내용을 네 가지로 묶습니다. 첫째, 컨테이너는 어디서나 똑같이 돌아가게 해 줍니다. 둘째, 불변 인프라는 고쳐 쓰지 않고 통째로 갈아 끼우는 방식입니다. 셋째, 쿠버네티스는 오케스트레이션의 표준이면서 동시에 원하는 상태를 스스로 지켜 내는 시스템입니다. 넷째, 열린 거버넌스와 표준 규격 덕분에 한 회사에 묶이지 않습니다. 영상은 이를 ‘가볍게, 안전하게, 자동으로, 그리고 묶이지 않게’라는 말로 요약합니다.

▲ 영상의 네 가지 핵심 정리 (영상 4:44)

캡처의 노란 띠에는 ‘컨테이너로 가볍게, 불변으로 안전하게, Kubernetes로 자동으로, 오픈 표준으로 종속 없이’라고 적혀 있습니다. 아래 네 칸의 카드는 각각 컨테이너(이식성·일관성), 불변 인프라(교체 이식), Kubernetes(표준 + 자가 조정), 오픈 거버넌스(종속 회피)를 담고 있습니다. 세 번째 카드의 ‘자가 조정’이 바로 이 글이 다룬 리컨실리에이션 루프입니다.

네 가지가 한 흐름으로 읽힌다는 점이 중요합니다. 컨테이너가 같은 모양으로 돌아가고, 불변 인프라가 고치지 않고 갈아 끼우는 방식을 택하기 때문에, 리컨실리에이션 루프가 ‘원하는 모양과 다르면 새로 만든다’는 단순한 규칙으로 클러스터를 유지할 수 있습니다. 마지막 넷째의 열린 표준 덕분에 이 구조는 특정 공급자에 묶이지 않고 어느 환경에서든 같은 방식으로 동작합니다. 영상은 이 네 가지만 기억하면 충분하다고 마무리합니다.

리컨실리에이션 루프는 원하는 상태와 현재 상태의 차이를 관찰·비교·조정으로 끝없이 줄이는 반복이며, 운영자는 목표만 선언하면 됩니다.

리컨실리에이션 루프란 무엇인가요?

컨트롤러가 원하는 상태와 현재 상태의 차이를 관찰·비교·조정으로 끝없이 줄이는 반복 구조입니다. 영상은 이 이름을 쿠버네티스의 핵심 원리로 소개하며, 원하는 상태를 스스로 지켜 내는 구조라고 설명합니다. 두 값이 같아질 때까지 같은 일을 되풀이합니다.

자가 치유는 리컨실리에이션 루프와 어떤 관계인가요?

자가 치유는 리컨실리에이션 루프가 장애 상황에서 보여 주는 결과이며, 뿌리에 제어 루프가 있습니다. 영상은 정상 가동, 장애 감지, 복구·재구성, 상태 확인이 이어지는 순환으로 자가 치유를 보여 주고, 그 바탕에서 컨트롤러가 원하는 상태와 현재 상태를 계속 맞춘다고 설명합니다.

컨트롤러는 파드 수를 어떻게 맞추나요?

현재 상태를 관찰하고 원하는 값과 비교해 모자란 만큼만 만들거나 남는 만큼 지웁니다. 영상의 예시에서는 원하는 컨테이너가 5개이고 현재 2개이므로 3개가 부족하다고 계산해 3개를 새로 만들어 5개로 맞춥니다. 두 값이 같아지면 루프는 다시 처음으로 돌아갑니다.

디플로이먼트를 만들면 파드는 어떻게 생기나요?

디플로이먼트 컨트롤러가 레플리카셋을 만들고, 레플리카셋 컨트롤러가 파드를 만드는 순서로 생깁니다. 영상은 각 단계가 저마다 독립된 조정 루프로 돌며, 계주처럼 자기 구간만 책임지고 다음 단계로 배턴을 넘긴다고 설명합니다.

무상태와 상태가 있는 애플리케이션의 복구는 어떻게 다른가요?

무상태는 동일한 복제본으로 즉시 교체하고, 상태가 있는 쪽은 영구 볼륨과 함께 장애별로 복구합니다. 영상은 무상태 애플리케이션을 어느 복제본이든 똑같은 것으로 보고 교체가 곧 복구라고 설명하며, 데이터를 안고 있는 쪽은 영구 볼륨으로 데이터와 상태를 보존한 채 되살린다고 말합니다.

Level-Based API는 무슨 뜻인가요?

중간 이벤트를 따라가지 않고 항상 최신 선언을 기준으로 상태를 조정한다는 뜻입니다. 영상의 도식은 중간 상태(이벤트)를 무시하고 항상 최신 Spec을 기준으로 상태를 조정한다고 적고 있습니다. 사건의 이력 대신 지금의 원하는 상태와 현재 상태만 비교하면 된다는 의미입니다.

리컨실리에이션 루프를 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 공식 문서를 모았습니다.

• 쿠버네티스(Kubernetes)란 무엇인가 — 개념과 도입 이유
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 vs 도커 차이 완벽 정리 — 관계와 언제 무엇을 쓸까
• 컨테이너와 쿠버네티스 — 각각의 역할과 함께 쓰는 이유
• 쿠버네티스가 필요한 이유 — 구글 데이터센터에서 시작된 컨테이너 혁명
• 쿠버네티스 운영 자동화 — 이해해야 신뢰할 수 있는 이유
• 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화
• 쿠버네티스 도입을 막는 오해와 장벽 12가지
• 3.4.2 쿠버네티스가 제공하는 선언적 API와 자동화의 힘 — 선언적 API와 자동화
• 3.5 조정 루프, 컨트롤러, 그리고 오퍼레이터 패턴 — 컨트롤러와 조정 루프의 전체 맥락
• 3.5.2 조정 루프 (Reconciliation Loop) — 조정 루프의 동작
• 3.3.2 왜 컨테이너만으로는 부족한가? 오케스트레이션의 필요성 대두 — 오케스트레이션이 필요해진 배경
• 쿠버네티스 리컨실리에이션 루프란 — 선언형 설정이 동작하는 원리 | 입문 9 — 클라우드네이티브TV, 이 글이 정리한 원 영상
• 쿠버네티스 공식 문서: Controllers — 컨트롤러와 제어 루프의 정의
• 쿠버네티스 공식 문서: Deployment — 복제본 유지와 롤링 업데이트
• 쿠버네티스 공식 문서: ReplicaSet — 복제본 수를 지키는 리소스
• 쿠버네티스 공식 문서: Persistent Volumes — 상태를 가진 애플리케이션의 데이터 보존