[2026.01.09 주간 개발 트렌드] Gemini 파일 입력과 Kubernetes 접근·스토리지 관리

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# 2026년 첫주는 Kubernetes 운영 개선부터 살펴보자

새해 첫주에는 인프라의 복구와 동기화 비용을 줄이는 변화가 눈에 들어왔다. 장애때 어디까지 다시 만들고, 변화가 없을때도 외부 API를 호출해야하는지에 관한 이야기다.

이번주 범위는 2025년 12월 29일부터 2026년 1월 2일까지다. 지난달 공개된 Kubernetes 1.35의 세부 기능 중 두가지가 공식 블로그에서 소개됐다.

하나는 Pod를 삭제하지 않고 내부 컨테이너 전체를 다시 시작하는 기능이고, 다른 하나는 Cloud Controller Manager의 경로 동기화를 변경 이벤트 중심으로 실행하는 기능이다.

| 분야 | 이번주 소식 | 공개된 설명 | 1.35에서의 단계 |
| --- | --- | --- | --- |
| 인프라·장애 복구 | Pod 전체 제자리 재시작 | 1월 2일 | Alpha |
| 인프라·클라우드 네트워크 | CCM의 이벤트 기반 경로 동기화 | 12월 30일 | Alpha |

둘다 Kubernetes 운영과 관련되지만 해결하는 문제는 다르다. 첫번째는 장애 복구 과정의 재생성 비용을 줄이는 방향이고, 두번째는 변화가 없을때 반복하는 동기화 작업을 줄이는 방향이다.

각각의 동작과 적용 조건, 실제 운영에서 확인할 기준을 나눠서 살펴보려고 한다.

# 1. 인프라 — Pod 전체를 제자리에서 재시작한다

1월 2일에 소개된 [RestartAllContainers](https://kubernetes.io/blog/2026/01/02/kubernetes-v1-35-restart-all-containers/)는 컨테이너 종료 규칙에 따라 Pod 안의 컨테이너 전체를 제자리에서 다시 시작하는 기능이다. Kubernetes 1.35에서 Alpha로 제공된다.

## 컨테이너 하나의 재시작으로 부족한 경우

우선 하나의 Pod에 애플리케이션과 보조 컨테이너가 같이 들어있는 상황을 생각해보자. 초기화 컨테이너가 파일을 준비하고, 애플리케이션이 이를 읽으며, watcher가 상태를 확인하는 구조다.

```text
하나의 Pod
├── init container: 실행에 필요한 파일 준비
├── watcher: 오류 상태 확인
└── application: 실제 작업 수행
```

공유 상태가 잘못됐거나 보조 컨테이너와 연결을 다시 맞춰야한다면 애플리케이션 한개만 재시작해서는 같은 문제를 반복할 수 있다.

Pod를 새로 만들면 초기화부터 진행할 수 있지만 배치와 네트워크, 저장소 준비도 따라온다. 많은 Pod가 함께 복구해야한다면 이 과정의 비용도 커질 수 있다.

이번 기능은 Pod의 틀을 유지하면서 내부 실행 순서를 다시 시작할 수 있도록 하는 접근이다.

## 무엇을 유지하고 무엇을 다시 시작하나

제자리 재시작에서는 Pod의 UID와 IP, 네트워크 네임스페이스, sandbox와 연결된 장치, 볼륨이 유지된다. init container부터 시작 순서를 다시 실행하고 일반 컨테이너와 sidecar를 다시 시작한다.

이때 이미 성공하거나 실패한 컨테이너도 다시 시작하는 범위에 포함된다. 디버깅용 ephemeral container는 종료되며 같은 방식으로 재실행되는 대상으로 보면 안된다.

```text
Pod 삭제와 재생성
기존 Pod 제거 → 새 Pod 생성과 배치 → 실행 환경 준비 → 초기화

Pod 전체 제자리 재시작
기존 Pod와 자원 유지 → 컨테이너 종료 → 초기화부터 다시 실행
```

프로세스를 복구하면서 Pod의 기반 자원을 재사용하는 구조다. IP가 유지돼도 기존 프로세스의 메모리나 연결까지 이어지는것은 아니므로 재연결도 고려해야한다.

또한 노드 자체가 고장난 경우를 이 기능만으로 해결할 수는 없다. 정상 노드에서 내부 상태를 다시 맞추는 경우와 다른 노드로 옮겨야하는 경우를 구분해야한다.

## 어떤 조건에서 전체 재시작을 요청할까

1.35에서는 API server와 kubelet에 RestartAllContainersOnContainerExits feature gate를 활성화해야한다. 이를 기반으로 컨테이너의 restartPolicyRules에 RestartAllContainers 동작을 지정한다.

예를 들어 watcher가 특정 오류를 복구 가능한 상태로 판단했을때 정해둔 종료 코드를 반환하도록 구성할 수 있다.

```yaml
name: recovery-watcher
restartPolicy: Always
restartPolicyRules:
  - action: RestartAllContainers
    exitCodes:
      operator: In
      values: [75]
```

위의 코드는 이미지와 명령 등을 생략한 watcher 설정 일부다. 75는 설명을 위한 숫자이며 정해진 Kubernetes 오류 코드는 아니다.

중요한건 watcher가 왜 그 코드로 종료하는지다. 단순한 외부 요청 실패와 Pod 전체의 상태를 다시 맞춰야하는 오류를 같은 조건으로 처리하면 재시작 범위가 너무 커질 수 있다.

# 2. 인프라 — 전체 재시작을 실제 복구에 연결하려면

기능 이름만 보면 완전히 새로운 환경으로 돌아갈것처럼 느껴질 수 있다. 하지만 유지되는 상태가 있으므로 어떤 데이터를 다시 만들고 어떤 데이터를 이어서 사용할지부터 정해야한다.

## emptyDir도 그대로 남는다는 점이 중요하다

[1.35 Pod 생명주기 문서](https://v1-35.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-all-containers)에서도 볼륨이 보존되는 동작을 설명한다. emptyDir 역시 이번 재시작으로 자동 삭제되는 공간이 아니다.

예를 들어 init container가 작업 디렉터리에 설정 파일을 만든다고 해보자. 첫 실행에서는 디렉터리가 비어있지만 재시작할때는 이전 실행의 파일과 잠금 정보가 남아있을 수 있다.

```text
초기화 로직에서 생각할 상태
├── 정상적으로 준비된 파일
├── 작성 중에 끊긴 파일
├── 이전 실행의 임시 파일
└── 다시 사용해야하는 체크포인트
```

이 네가지를 모두 같은 방식으로 지우거나 재사용하면 문제가 생길 수 있다. 필요한 체크포인트까지 삭제하면 복구 시간을 줄이려던 목적과 달라지고, 불완전한 파일을 정상 결과처럼 읽으면 같은 오류를 반복할 수 있다.

그래서 초기화 코드도 여러번 실행해도 괜찮은지 확인하는게 좋겠다. 기존 결과를 검사하고 필요한 부분만 다시 준비하거나, 임시 위치에 작성한 뒤 완료된 결과로 바꾸는 방식을 생각할 수 있다.

## 종료 훅에만 정리를 맡기면 안된다

이번 전체 재시작에서는 preStop 훅을 실행하지 않는다. 일반적인 종료때 사용하던 정리 과정이 항상 실행될거라고 가정하면 안된다.

예를 들어 작업 완료 표시나 잠금 해제를 preStop에서만 처리하고있다면 갑작스러운 종료 후에도 정상적으로 다시 시작할 수 있는지 살펴봐야한다.

이 문제는 단순히 훅을 추가하는것보다 작업 상태를 어떻게 기록하는지와 연결된다. 외부 시스템에 요청을 보냈는데 결과를 기록하기 전에 종료됐다면, 다시 시작한 프로세스는 그 작업이 완료됐는지 판단할 근거가 필요하다.

```text
외부 작업 요청 → 외부에서 처리 완료 → 결과 기록 전 종료
                                      ↓
                         재시작 후 중복 실행 여부 판단
```

조회 작업과 결제·메시지 전송처럼 외부 상태를 바꾸는 작업은 재시도의 의미가 다르다. 작업 식별자와 중복 방지 기준을 두고 완료 상태를 확인할 수 있는지 봐야한다.

## AI 학습에서는 체크포인트 이후도 확인하자

학습 작업이라면 마지막 체크포인트를 읽는것과 전체 작업이 다시 전진하는것을 나눠서 확인하면 좋겠다. 모델 상태를 읽었어도 데이터 위치나 다른 worker와의 통신이 맞지 않으면 작업이 계속 멈춰있을 수 있다.

이 기능은 Pod 내부 재시작의 기반이다. 여러 노드의 worker를 언제 복구하고 어떻게 합류시킬지는 학습 프레임워크나 상위 컨트롤러와 함께 정해야한다.

복구 시간을 기록할때도 컨테이너가 실행된 순간에서 끝내지 말자. 다음 학습 step이나 배치 처리가 실제로 완료되는 순간까지 보면 사용 가능한 상태로 돌아온 시간을 비교하기 쉽다.

# 3. 인프라 — CCM의 경로 동기화가 이벤트를 따라간다

두번째 소식은 12월 30일에 소개된 [Cloud Controller Manager의 watch 기반 경로 재조정](https://kubernetes.io/blog/2025/12/30/kubernetes-v1-35-watch-based-route-reconciliation-in-ccm/)이다. 장애 후 실행 환경을 다시 시작하는 첫번째 기능과 달리, 클라우드 네트워크 설정을 확인하는 작업의 실행 시점을 바꾸는 기능이다.

## 여기서 말하는 경로는 HTTP URL이 아니다

[Cloud Controller Manager](https://v1-35.docs.kubernetes.io/docs/concepts/architecture/cloud-controller/)는 Kubernetes와 클라우드 제공자의 기능을 연결하는 구성 요소다. 그 안의 route controller는 노드 사이의 Pod 통신에 필요한 클라우드 경로를 다루는 역할을 맡는다.

여기서 경로는 /api/orders 같은 HTTP URL이 아니다. 클라우드 네트워크의 라우트와 노드 정보를 맞추는 제어 영역의 이야기다.

```text
Kubernetes의 Node 정보
        ↓
CCM의 route controller
        ↓
클라우드 제공자의 네트워크 경로
```

실제로 경로를 관리하는 구성 요소는 네트워크 플러그인과 클라우드 구현에 따라 확인해야한다.

## 일정 간격으로 보던것을 변경 이벤트로 실행한다

기존 k8s.io/cloud-provider 기반 route controller는 정해진 간격으로 경로를 재조정했다. 변화가 없는 동안에도 같은 확인 작업이 반복되므로 불필요한 클라우드 API 요청이 발생할 수 있다.

1.35의 Alpha 기능은 informer로 Node 변화를 감지해 동기화 루프를 실행하도록 한다. 대상은 노드 추가와 삭제, .spec.podCIDRs 또는 .status.addresses의 변경이다.

```text
주기 중심
시간 도달 → 상태 확인 → 동기화
시간 도달 → 같은 상태 확인 → 동기화

변경 중심
관련 Node 변화 감지 → 상태 확인 → 동기화
```

feature gate 이름은 CloudControllerManagerWatchBasedRoutesReconciliation이다. 실제 사용 여부는 실행중인 CCM 구현과 해당 기능의 지원, 설정을 확인해야한다.

바뀌는건 동기화 루프를 시작하는 계기다. 경로를 비교하고 맞추는 내부 로직은 유지된다.

## 주기적 확인이 완전히 사라지는것은 아니다

이벤트 기반이라고 계속 이벤트만 기다리는 구조로 이해하면 정확하지 않다. 컨트롤러가 시작할때 12~24시간 사이의 무작위 간격을 선택하고, 그 간격으로 추가 재조정도 수행한다.

즉 자주 반복하던 확인을 변화 중심으로 옮기면서, 별도의 주기적 재확인도 남겨두는 구성이다.

운영에서는 이 차이가 중요하다. Kubernetes의 Node 객체가 바뀌는 상황과 클라우드 쪽 설정이 별도로 달라지는 상황은 같은 경로로 감지되지 않을 수 있기 때문이다.

다른 자동화도 경로를 수정한다면 최종 책임을 정리하면 좋겠다. 같은 설정을 서로 덮어쓰고있다면 충돌 원인부터 찾아야한다.

# 4. 인프라 — API 호출 감소를 어떻게 확인할까

외부 API 호출이 줄어든다는 설명은 반갑지만, 실제로 얼마나 줄어드는지는 클러스터의 변화량과 구현에 따라 달라질것이다. 우선 평상시와 노드가 자주 바뀌는 상황을 나눠서 보면 좋겠다.

## 숫자는 가정과 실제 측정을 구분하자

예를 들어 어떤 확인 루프가 20초마다 실행된다고 가정해보자. 이 숫자는 이번 CCM의 기본값을 설명하는것이 아니라 반복 비용을 생각하기 위한 예시다.

```text
하루의 루프 실행 횟수
24 × 60 × 60 ÷ 20 = 4,320회
```

상태가 하루종일 같아도 루프는 반복된다. 이때 변경이 있을때 실행하는 방식으로 옮기면 줄일 수 있는 작업이 있을것이다.

다만 루프 한번을 클라우드 API 호출 한개로 계산하면 안된다. 한 루프에서 여러 요청을 할 수도 있고 캐시나 구현에 따라 외부 호출 없이 처리되는 부분도 있을 수 있다.

실제 효과는 요청 로그와 제공자의 사용량, 오류와 제한 응답으로 비교해야한다. 호출 감소가 같은 비율의 청구 금액 감소를 의미하는것도 아니다.

## 조용한 구간과 변경이 많은 구간을 같이 보자

노드가 거의 바뀌지 않는 구간은 불필요한 반복이 얼마나 줄었는지 보기 좋다. 반대로 자동 확장이나 노드 교체가 자주 일어나는 구간에서는 변화에 제때 반응하는지 확인해야한다.

| 상황 | 확인할 결과 |
| --- | --- |
| Node 변화가 거의 없음 | 경로 관련 요청과 불필요한 반복이 줄어드는가 |
| Node 추가 | 새 노드와 다른 노드의 Pod가 통신하는가 |
| Node 제거 | 필요없어진 경로가 정리되는가 |
| 주소나 Pod CIDR 변경 | 실제 통신 경로가 새 상태와 맞는가 |
| 클라우드 API 오류 | 실패를 확인하고 다시 수렴할 수 있는가 |

요청 수만 줄고 경로가 뒤늦게 맞춰진다면 운영 목표를 만족했다고 보기 어렵다. 외부 API의 사용량과 네트워크가 올바른 상태로 돌아오는 시간을 함께 확인해야한다.

이벤트가 몰리는 경우에도 살펴보면 좋겠다. 여러 노드를 교체하는 과정에서 오류나 대기가 쌓이는지, 최종적으로 필요한 경로가 모두 준비되는지 보는것이다.

CCM 버전과 네트워크 구성, 노드 규모도 기록하자. 다른 제공자에서 같은 결과가 나올거라고 가정하면 안된다.

# 5. 두 기능을 운영 환경에서 검토할 순서

이번주 두 기능은 모두 Alpha다. 기능 이름을 알았다는것에서 바로 운영 전체를 바꾸기보다는 현재 구성과 해결하려는 문제를 먼저 연결하면 좋겠다.

## 설정을 적용하는 위치부터 다르다

Pod 전체 재시작은 API server와 kubelet의 기능 지원, 컨테이너 종료 규칙과 연결된다. CCM의 변경 감지는 사용하는 cloud-provider 기반 구현과 그 설정을 확인해야한다.

클러스터 버전이 1.35라는 정보 하나로 두 기능의 준비가 모두 끝났다고 판단하면 안된다. 관리형 서비스라면 사용자가 feature gate를 변경할 수 있는 범위도 확인해야한다.

```text
현재 구성 파악
    ↓
해결하려는 비용이나 장애 정의
    ↓
기능 지원과 설정 위치 확인
    ↓
테스트 환경에서 한가지씩 적용
    ↓
정상 동작과 실패 후 복구 비교
```

한번에 한가지 가설로 비교하면 어느 변경의 효과인지 설명하기 쉽다.

## 완료 기준은 애플리케이션의 동작으로 잡자

재시작 기능이라면 Pod 이름이 남아있다는것보다 실제 작업이 다시 진행되는지가 중요하다. watcher가 계속 같은 종료 코드를 내보내면서 전체 Pod를 반복 재시작하는 상황도 구분해야한다.

한번의 오류를 복구하는데 재시작이 몇번 필요한지, 체크포인트에서 얼마나 작업을 다시 하는지, 중복 결과가 생기지 않는지 살펴보자. 재시작 횟수만 늘어나는 자동화는 복구와 다르다.

CCM이라면 로그가 조용해지는것과 네트워크가 정상이라는것을 함께 확인해야한다. 노드 추가 후 경로 준비와 실제 Pod 통신까지 이어지는 시간을 보면 사용자가 체감하는 결과와 연결하기 쉽다.

```text
Pod 재시작의 완료 기준
초기화 성공 → 주요 프로세스 준비 → 실제 작업 재개

CCM 변경의 완료 기준
Node 변화 → 경로 반영 → 실제 노드 사이 통신 확인
```

같은 워크로드와 비슷한 부하로 변경 전후를 비교하자. 정상 실행과 장애를 넣은 실행도 구분해서 기록하면 좋겠다.

## 되돌리는것과 이전 상태 복원은 구분하자

설정을 되돌려도 외부 작업의 결과나 볼륨 상태까지 복원되는것은 아니다. CCM 역시 실제 경로를 확인해야한다. 테스트에는 버전과 설정, 오류 조건, 정상화 기준을 남겨서 이후에도 같은 판단을 재현할 수 있게 하면 좋겠다.

# 마무리

이번주는 Kubernetes에서 불필요하게 다시 만드는 작업과 변화 없이 반복하는 작업을 줄이는 두가지 접근이 눈에 들어왔다. Pod 전체 재시작은 복구 경로를, CCM의 watch 기반 재조정은 동기화의 실행 시점을 개선하는 방향이다.

개인적으로는 둘다 운영 자동화를 더 구체적으로 표현하게 만든다는 점이 흥미롭다. 무엇을 유지한 채 다시 시작할지, 어떤 변화가 있을때 상태를 맞출지를 설정과 코드에서 이야기할 수 있기 때문이다.

다만 빠르게 재시작하는것과 작업이 정상으로 돌아오는것은 다르고, 호출이 줄어드는것과 네트워크가 올바른것도 다르다. 이 두 결과를 연결해서 확인해야 실제 이점을 판단할 수 있겠다.

우선 우리 환경에서 반복되는 복구 비용과 외부 API 사용량부터 살펴보면 좋겠다. 새해 첫 인프라 개선도 기능을 켜는것보다 무엇이 줄었고 무엇이 정상으로 돌아왔는지 설명하는 작업으로 시작해야겠다..


[2026.01.02 주간 개발 트렌드] Kubernetes의 Pod 복구와 클라우드 경로 동기화

독자의 메모