[2025.12.26 주간 개발 트렌드] 데이터베이스 MCP 정리 (Oracle, Agent 도구, 접근 권한)

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

# Kubernetes는 계속 관리해야하는 실행 플랫폼이다

Kubernetes에 애플리케이션을 올리면 배포와 복구를 일정한 방식으로 다룰 수 있다. 대신 클러스터와 주변 구성 요소의 버전도 계속 관리해야한다.

이번주 12월 17일에 [Kubernetes 1.35 Timbernetes](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/)가 출시됐다. 공식 발표는 총 60개의 개선과 17개의 Stable 기능을 소개했다.

이번주에는 실행중인 Pod의 자원을 조절하는 변화와 새 버전을 운영 환경에서 검토할때 확인할 부분을 정리해보려고 한다.

# 1. Pod 자원을 실행중에 바꾸는 기능이 Stable이 됐다

서비스의 CPU나 메모리를 조절하고싶을때 Pod를 다시 만드는 방식은 익숙하다. 그런데 오래 실행되는 작업이나 상태가 있는 서비스라면 재생성 자체가 부담일 수 있다.

이번 버전에서는 Pod 자원을 제자리에서 변경하는 기능이 GA가 됐다. CPU와 메모리를 조절할때 Pod 재생성에 의존하는 범위를 줄이는 방향이다.

```text
자원 조절 요청
    ↓
현재 노드의 여유와 적용 조건 확인
    ↓
가능한 경우 실행중인 컨테이너에 반영
    ↓
상태와 실제 동작 확인
```

다만 어떤 변경이든 항상 중단 없이 즉시 적용된다는 뜻은 아니다. 노드에 여유가 있어야하고 컨테이너의 resize 정책과 애플리케이션 동작도 고려해야한다.

자원을 더 요청한다고 물리적인 CPU와 메모리가 새로 생기는것은 아니다. 현재 노드에서 가능한 요청인지 확인하는 과정은 여전히 필요하다.

# 2. 메모리는 애플리케이션의 동작도 봐야한다

[1.35의 리소스 조절 문서](https://v1-35.docs.kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/)에서는 CPU와 메모리에 대해 재시작 정책을 설정할 수 있다고 설명한다.

```yaml
resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer
```

위의 코드는 컨테이너 설정에 들어가는 일부 예시다. CPU 변경은 재시작 없이 처리하고 메모리 변경에는 재시작을 요구하도록 구분한것이다. 완전한 Pod 정의는 아니다.

특히 메모리는 런타임이 처음 시작할때 크기를 결정하는 설정과 연결될 수 있다. 컨테이너의 제한을 늘렸다고 애플리케이션의 내부 설정까지 모두 자동으로 달라지는지 따로 확인해야한다.

제한을 줄일때도 현재 사용량과의 관계를 봐야한다. 원하는 숫자를 API에 썼다는것과 실제 프로세스가 그 조건에서 안정적으로 실행되는것은 다르다.

자원 변경 요청이 대기하거나 진행중일 수 있으므로 Pod 상태와 실제 적용된 값을 함께 확인하면 좋겠다. 선언한 값만 보고 작업이 끝났다고 판단하면 적용되지 않은 상태를 놓칠 수 있다.

테스트할때는 자원이 충분한 경우와 부족한 경우를 나눠보자. 정상 경로에서 한번 성공하는것만큼 적용되지 않을때 원인을 찾을 수 있는지도 중요하다.

# 3. 새 기능의 단계는 각각 다르다

이번 발표에는 Pod 인증서가 Beta로, 스케줄링 전에 노드 지원 기능을 알리는 기능이 Alpha로 소개됐다. 같은 1.35 기능이라고 모두 Stable인것은 아니다.

| 기능 | 이번 릴리스의 단계 |
| --- | --- |
| 실행중인 Pod 자원 변경 | Stable |
| Pod 인증서 | Beta |
| Node declared features | Alpha |

기능을 검토할때는 기본 활성화 여부와 feature gate, 구성 요소의 지원 조건을 같이 확인해야한다. 릴리스 목록에 있다는 이유만으로 현재 클러스터에서 바로 동작한다고 보기는 어렵다.

특히 컨트롤 플레인과 노드의 버전이 다른 전환 구간을 생각해보자. 새로운 API를 이해하는것과 실제 노드가 기능을 수행할 수 있는것은 구분해서 확인해야한다.

운영에서는 필요한 기능을 먼저 정하고 그 기능의 상태를 확인하면 좋겠다. 새로운 항목을 전부 켜는것보다 어떤 문제를 해결하려는지 설명할 수 있어야한다.

# 4. 클러스터 버전만 확인하면 부족하다

애플리케이션은 Kubernetes 본체만으로 실행되지 않는다. 네트워크와 저장소, 인증과 배포를 담당하는 구성 요소들이 함께 연결된다.

```text
클러스터의 실제 구성
├── 컨트롤 플레인과 노드
├── 컨테이너 런타임
├── CNI와 CSI
├── Ingress와 트래픽 처리
└── CRD, Operator, Webhook
```

따라서 버전을 올리기 전에 사용하는 플러그인과 컨트롤러의 지원 조합을 확인해야한다. CRD 객체가 남아있다고 해당 Operator까지 정상적으로 동작한다는 뜻은 아니다.

Webhook이 요청을 처리하지 못하면 애플리케이션 생성이나 변경 자체가 막힐 수도 있다. 정상 실행중인 Pod만 보는것보다 새 Pod를 만들고 설정을 바꾸는 경로도 확인하면 좋겠다.

사용하지 않는 API와 오래된 설정도 점검 대상이다. 이번 버전에서는 kube-proxy의 ipvs 모드가 deprecated로 안내됐다. 당장 제거된것으로 이해하기보다는 현재 사용 여부와 전환 계획을 확인할 항목으로 보는게 맞다.

# 5. 업그레이드는 서비스 동작으로 확인하자

먼저 테스트 환경에서 실제 운영과 비슷한 구성으로 확인하면 좋겠다. 단순한 예제 Pod보다 우리 서비스의 네트워크와 볼륨, 권한을 사용하는 작업이 중요하다.

```text
배포 생성 → Pod 준비 → 서비스 통신 → 볼륨 사용
                               ↓
                 노드 교체와 재스케줄링 확인
```

기존 Pod가 잘 실행되는것뿐 아니라 노드가 바뀌어도 다시 준비되는지 살펴보자. 이미 연결된 볼륨과 새로 연결하는 볼륨에서 다른 문제가 드러날 수도 있다.

배포할때 필요한 여유 자원과 PodDisruptionBudget도 함께 확인해야한다. 평소에는 정상인 클러스터가 노드 하나를 비우는 과정에서 작업을 진행하지 못할 수 있다.

관리형 Kubernetes를 사용한다면 해당 서비스가 1.35를 제공하는 일정과 업그레이드 경로를 확인하면 된다. 오픈소스가 출시된 날과 모든 클라우드에서 같은 구성을 사용할 수 있는 날은 다를 수 있다.

전환 중 장애가 나면 어떤 범위를 복구할 수 있는지도 정해두자. 애플리케이션 롤백과 클러스터 버전 복구는 같은 작업으로 볼 수 없다.

# 마무리

이번 Kubernetes 1.35에서는 실행중인 자원 조절이 Stable로 올라오면서 운영 중 워크로드를 다루는 방법이 넓어졌다.

개인적으로는 새 기능만큼 현재 클러스터의 구성과 지원 조합을 알고있는지가 중요해보인다. 표준 API 위에서 실행하더라도 실제 네트워크와 저장소, 컨트롤러의 차이는 남아있기 때문이다.

우선 우리 환경의 구성 목록과 업그레이드 검증 경로부터 정리해보면 좋겠다. 한번 구축한 결과보다 계속 변경하면서 안정적으로 운영하는 과정으로 봐야겠다..


[2025.12.19 주간 개발 트렌드] Kubernetes 1.35 정리 (Pod 리소스, 기능 단계, 업그레이드)

독자의 메모