[2026.01.16 주간 개발 트렌드] Node.js 보안 패치와 Bun, 코딩 Agent API의 변화

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

# 이번주는 입력 데이터와 실행·저장 경계를 같이 보자

이번주에는 AI 서비스에 파일을 넣는 방법과 Kubernetes를 운영하는 방법에서 각각 변화가 있었다. 기능을 연결하기는 쉬워지지만 누가 무엇을 읽고 실행하는지, 실제 데이터가 어디에 있는지는 계속 확인해야하는 소식들이다.

1월 5일부터 9일까지 공개된 내용을 세가지로 나눠보았다.

| 분야 | 소식 | 먼저 확인할 부분 |
| --- | --- | --- |
| AI | Gemini API 파일 입력 확대 | 입력 경로와 파일 한도, 접근 권한 |
| 인프라·보안 | kuberc의 인증 플러그인 실행 정책 | kubeconfig가 로컬에서 실행하는 프로그램 |
| 인프라·스토리지 | PV Node Affinity 변경 | 실제 볼륨 접근 범위와 스케줄링 조건 |

첫번째는 데이터를 가져오는 경로, 두번째는 로컬 프로그램 실행, 세번째는 저장소와 노드의 연결에 관한 변화다. 이름만 보면 서로 다른 이야기인데, 설정을 적었다는것과 실제 권한이나 접근 가능성이 맞는지를 함께 봐야한다는 공통점이 있다.

# 1. AI — Gemini API의 파일 입력 경로가 넓어졌다

1월 8일 [Gemini API 변경 이력](https://ai.google.dev/gemini-api/docs/changelog)에 Cloud Storage와 외부 URL을 데이터 입력으로 사용하는 지원이 추가됐다. 파일 크기 한도도 20MB에서 100MB로 확대됐다고 안내됐다.

## 기존 파일을 다시 옮기는 작업을 줄일 수 있다

문서 분석 서비스를 만든다고 해보자. 사용자가 파일을 올리면 우리 저장소에 보관하고, 모델이 읽을 수 있는 경로로 다시 전달해야한다. 원래 파일과 분석용 사본을 각각 관리하는 구성이 생길 수 있다.

```text
기존에 생각할 수 있는 흐름
사용자 업로드 → 서비스 저장소 → 분석용 파일 전달 → 모델 처리

검토할 수 있는 흐름
서비스 저장소의 파일 → 접근 가능한 입력 경로 → 모델 처리
```

입력 경로가 넓어지면 중간 복사를 줄일 여지가 있다. 특히 이미 Cloud Storage에 쌓여있는 문서나 외부 시스템의 파일을 다룬다면 수집 단계의 구성이 달라질 수 있겠다.

그렇다고 URL 하나를 전달하면 문서 분석 서비스가 완성되는것은 아니다. 파일이 어느 버전인지, 실제로 읽을 수 있는지, 처리 결과를 원본과 어떻게 연결할지는 애플리케이션에서 관리해야한다.

사용자가 같은 이름으로 새 파일을 올리는 상황도 생각해보자. 경로만 기록해두면 분석 중인 파일과 나중에 화면에서 보여주는 파일이 달라질 수 있다. 객체 버전이나 별도의 문서 식별자를 같이 남기면 결과를 설명하기 쉽다.

## 100MB와 문맥 크기는 같은 의미가 아니다

파일의 바이트 크기와 모델이 처리하는 토큰, 페이지 수, 미디어 길이는 서로 다른 기준이다. 파일 입력 한도가 커졌다고 모든 형식과 모델에서 같은 문서를 같은 방식으로 처리한다는 뜻은 아니다.

압축된 파일 크기가 작아도 안의 정보량이 많을 수 있고, 스캔 PDF는 텍스트 PDF와 처리 방식이 다를 수 있다. 지원하는 MIME 형식과 선택한 모델의 조건을 따로 확인해야한다.

```text
파일 처리 전에 나눠서 확인할것
파일 크기 → 형식 → 페이지·미디어 길이 → 모델 지원 → 요청 비용
```

큰 파일을 한번에 보낼 수 있다는것과 그렇게 보내는게 좋은지는 별개의 문제다. 필요한 문서 구간만 처리할 수 있다면 지연과 비용을 줄일 수도 있다.

RAG를 만든다면 원본을 모델에 전달하는 단계와 검색 가능한 조각을 만드는 단계도 구분하자. 파일 입력 기능이 문서 분할, 임베딩 생성, 검색 품질 평가까지 대신하는것은 아니다.

예를 들어 계약서 전체를 요약하는 요청과 특정 조항을 반복 검색하는 요청은 필요한 처리 흐름이 다르다. 입력 편의성이 늘어난 부분을 현재 서비스의 작업 단위와 연결해서 보는게 좋겠다.

## Signed URL에는 유효 기간이 있다

외부 URL이나 서명된 URL을 사용할때는 접근 시점도 중요하다. 요청을 받은 순간에는 유효해도 작업 대기 후 실제 파일을 읽는 순간에는 만료될 수 있다.

```text
작업 생성 → 대기열 → 파일 읽기 → 분석 → 결과 저장
                     ↑
             이 시점에도 접근 가능한가
```

재시도할때도 같은 URL을 계속 재사용할지, 권한을 다시 확인하고 새 경로를 준비할지 정해야한다. 만료와 파일 삭제, 형식 오류를 전부 모델 실패로 기록하면 원인을 찾기 어렵다.

URL 자체에 접근 권한이 담기는 경우에는 로그에 그대로 복사하지 않도록 생각해보자. 분석 이력을 남기려면 파일 식별자와 작업 번호, 오류 종류가 필요한 경우가 많지 전체 서명 문자열이 항상 필요한것은 아니다.

사용자가 임의의 URL을 입력하는 서비스라면 허용하는 저장소와 경로도 정하면 좋겠다. 우리 서버가 먼저 내려받는 구조인지 제공자가 직접 읽는 구조인지에 따라 확인할 경계가 달라진다.

## 결과물까지 같은 문서에 연결하자

작업이 끝났을때는 파일을 읽었다는 사실보다 어떤 내용을 근거로 결과를 만들었는지가 중요하다. 문서 버전과 처리한 범위, 사용한 모델과 설정을 결과에 연결해두면 재분석할때 비교하기 쉽다.

표나 이미지가 많은 문서에서는 일부 페이지를 빠뜨리지 않았는지도 확인해보자. 업로드 성공 메시지가 전체 내용 이해를 보장하는것은 아니다.

작은 문서와 큰 문서, 접근할 수 없는 문서, 중간에 교체된 문서를 나눠서 시험하면 입력 기능의 편의성과 서비스의 실패 처리를 같이 확인할 수 있겠다.

# 2. 인프라·보안 — kubeconfig가 실행하는 프로그램을 제한한다

1월 9일에는 [kuberc의 인증 플러그인 실행 정책](https://kubernetes.io/blog/2026/01/09/kubernetes-v1-35-kuberc-credential-plugin-allowlist/)이 소개됐다. Kubernetes 1.35의 Beta 기능으로 kubectl이 실행할 인증 플러그인을 정책과 허용 목록으로 제한할 수 있다.

## kubeconfig는 주소와 인증서만 담는 파일이 아니다

kubeconfig의 users 항목에는 exec 설정이 들어갈 수 있다. 외부 프로그램을 실행해 인증 정보를 받는 기능으로, 클라우드 로그인 도구와 연동할때 유용하다.

하지만 이 프로그램은 명령을 실행한 로컬 사용자의 권한으로 동작한다. 클러스터에서 어떤 Pod를 볼 수 있는지와 로컬 컴퓨터에서 어떤 실행 파일이 시작되는지는 다른 경계다.

```text
kubectl 실행
    ↓
kubeconfig의 exec 설정 확인
    ↓
로컬 인증 플러그인 실행
    ↓
인증 정보로 Kubernetes API 접근
```

따라서 외부에서 받은 kubeconfig를 단순한 접속 주소 목록으로만 생각하면 놓치는 부분이 있다. 생성 경로와 exec.command가 무엇인지 확인할 필요가 있다.

## 정책은 클라이언트 쪽 실행을 다룬다

kuberc에는 credentialPluginPolicy와 credentialPluginAllowlist를 설정할 수 있다. 전체 허용과 거부, 지정된 프로그램만 허용하는 방식으로 실행 범위를 정한다.

```yaml
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: /opt/company/bin/cluster-login
```

위의 경로는 설명을 위한 예시다. 실제로 사용하는 로그인 프로그램의 설치 위치를 확인해서 정해야한다. 그대로 복사하면 기존 인증이 동작하지 않을 수 있다.

공식 설명에서는 이름만 지정하는것과 전체 경로를 지정하는것을 모두 지원한다. 이름만 지정하면 실행 파일 검색 경로의 영향을 받으므로 가능하면 정확한 경로를 확인하는게 좋겠다.

다만 전체 경로를 적었다고 바이너리의 내용까지 검증되는것은 아니다. 이번 허용 목록의 이름 제한을 서명이나 체크섬 검사와 같은 기능으로 이해하면 안된다.

## RBAC를 대신하는 기능도 아니다

이 정책은 어떤 프로그램을 로컬에서 실행할지에 관한 기능이다. API 서버에서 요청자의 권한을 제한하는 RBAC나 클라우드 계정의 권한과는 역할이 다르다.

| 경계 | 확인할 내용 |
| --- | --- |
| 로컬 클라이언트 | 어떤 인증 프로그램을 실행할 수 있는가 |
| 인증 과정 | 어떤 사용자나 계정으로 접속하는가 |
| 클러스터 | 그 계정이 어떤 리소스에 접근할 수 있는가 |

인증 플러그인이 허용 목록에 있다고 해당 계정에 넓은 권한을 줘도 된다는 뜻은 아니다. 반대로 클러스터에서 읽기 권한만 있다고 로컬 프로그램의 실행 위험까지 줄어드는것도 아니다.

팀에 적용한다면 개발자 컴퓨터와 CI에서 실제로 사용하는 프로그램부터 목록으로 정리해보자. 여러 클라우드를 오가는 팀에서는 필요한 플러그인이 한개가 아닐 수 있다.

## 적용 전에는 로그인 경로를 재현해보자

정상적인 로그인과 인증 갱신, 다른 클러스터로 전환하는 경우를 나눠서 확인하면 좋겠다. 처음 접속은 되는데 인증 만료 후 갱신에서 막히는 상황을 놓치지 않기 위해서다.

실행이 거부됐을때는 허용 목록을 무조건 넓히기보다 어떤 파일이 왜 필요한지 확인하자. 설치 경로가 달라진것인지, 예상하지 않은 프로그램이 추가된것인지 구분해야한다.

또한 같은 kubeconfig를 사용해도 다른 도구가 동일한 정책을 자동 적용한다고 가정하면 안된다. kubectl과 client-go를 사용하는 자체 도구의 버전과 설정을 각각 확인해야한다.

이 기능을 계기로 kubeconfig를 배포하는 과정도 살펴보면 좋겠다. 누가 생성하고 어디서 전달하며 변경을 어떻게 확인하는지 알 수 있어야 실행 정책도 관리하기 쉽다.

# 3. 인프라·스토리지 — PV Node Affinity를 수정할 수 있다

1월 8일에는 [PersistentVolume Node Affinity 변경](https://kubernetes.io/blog/2026/01/08/kubernetes-v1-35-mutable-pv-nodeaffinity/)이 소개됐다. Kubernetes 1.35의 Alpha 기능이며 MutablePVNodeAffinity feature gate로 활성화한다.

## 볼륨에 접근할 수 있는 노드를 표현한다

PV의 Node Affinity는 해당 볼륨에 접근할 수 있는 노드 조건을 표현한다. 특정 존이나 장치 조건에 묶인 저장소라면 아무 노드에서나 사용할 수 없기 때문이다.

저장소 쪽 접근 범위가 바뀌었는데 PV의 조건이 예전 상태라면 스케줄러는 여전히 이전 제약을 보고 판단할 수 있다. 이번 기능은 이 조건을 실제 저장소 상태와 맞춰 수정할 수 있도록 한다.

```text
실제 저장소의 접근 범위
          ↕ 일치해야함
PV의 Node Affinity
          ↓
Pod를 배치할 수 있는 노드 조건
```

여기서 PV 필드를 바꾸는것 자체가 디스크를 이동하거나 복제하는 작업은 아니다. 먼저 저장소 제공자가 지원하는 변경을 수행하고 실제 접근 범위를 확인해야한다.

## 조건을 넓히는것과 데이터를 옮기는것은 다르다

예를 들어 한 존에서만 접근하던 볼륨이 여러 존에서 접근 가능한 형태로 바뀌었다고 가정해보자. 저장소 변경이 완료됐다면 Kubernetes의 조건도 그 범위와 맞출 필요가 있을 수 있다.

하지만 저장소가 그대로인데 PV의 존 제한만 제거하면 새 노드에 Pod가 배치돼도 볼륨을 연결하지 못할 수 있다. YAML이 저장되는것과 실제 마운트 성공은 다른 결과다.

```text
확인할 단계
저장소 변경 완료 → 접근 가능한 노드 확인 → PV 조건 변경
                → 새 Pod 배치 → 실제 파일 읽기와 쓰기
```

실제 절차는 CSI 드라이버와 저장소 제품의 지원 방식에 맞춰 정해야한다. 이 기능을 범용 스토리지 마이그레이션 도구로 생각하면 안되겠다.

## 조건을 좁힐때는 전환 구간을 살펴보자

공식 설명에서는 Node Affinity를 더 좁게 바꾸는 경우 스케줄러 캐시와의 경쟁 조건도 다룬다. 변경 직후에는 이전 조건으로 판단한 배치가 발생할 수 있으므로 새 Pod의 위치와 볼륨 접근을 확인해야한다.

운영에서는 저장소 변경과 Pod 재생성이 겹치는 구간을 어떻게 관리할지가 중요하다. 필드를 수정하자마자 많은 Pod를 동시에 시작하는 자동화라면 실패 경로도 살펴보면 좋겠다.

기존 Pod가 계속 파일을 읽는 상황만 확인하면 새 노드에서 처음 연결하는 문제를 놓칠 수 있다. 재스케줄링과 볼륨 재연결을 포함해서 검증해야한다.

이때 테스트 데이터로 실제 읽기와 쓰기를 확인하고, 데이터의 내용과 접근 권한도 비교해보자. 볼륨이 연결됐다는 표시와 애플리케이션이 필요한 파일을 사용하는것은 다를 수 있다.

# 4. 세가지 변화를 서비스에 적용할때

이번주 기능들은 편의성이 늘어나는 부분과 경계를 확인해야하는 부분이 같이 있다. 데이터를 쉽게 넣을 수 있어도 접근 권한이 필요하고, 조건을 바꿀 수 있어도 실제 저장소가 따라와야한다.

## 성공과 실패를 따로 기록하자

Gemini 파일 입력에서는 파일 접근 실패와 모델 처리 실패를 나누면 좋겠다. kubectl에서는 프로그램 실행 거부와 클러스터 인증 실패를 구분하고, PV에서는 배치 실패와 마운트 실패를 나눠볼 수 있다.

```text
같은 실패처럼 보이는 다른 원인
파일: 접근 만료 / 지원 형식 / 모델 처리
접속: 실행 정책 / 로그인 / 클러스터 권한
저장소: 배치 조건 / 볼륨 연결 / 파일 권한
```

이 구분이 있어야 재시도할 위치도 정할 수 있다. 만료된 URL로 같은 요청을 반복하거나 마운트할 수 없는 노드에 계속 배치하는것은 기다리는 시간만 늘릴 수 있다.

## 한번에 한 경계부터 바꿔보자

입력 경로를 바꾸면서 문서 분할과 모델까지 바꾸면 결과 차이를 설명하기 어렵다. 파일 전달 경로부터 같은 문서로 비교하고 다음 변경을 적용하면 원인을 나누기 쉽다.

인프라도 마찬가지다. 실행 정책과 저장소 조건은 서로 다른 변경이므로 별도의 테스트와 담당 범위를 두면 좋겠다. Beta와 Alpha라는 상태도 구분해서 운영 적용 범위를 정해야한다.

검증한 버전과 설정, 정상 사례와 실패 사례를 남겨두면 이후 업데이트에서도 다시 확인할 기준이 된다. 새로운 기능을 켰다는 기록보다 어떤 경계에서 어떤 결과를 확인했는지가 중요하다.

# 5. 작은 검증 사례부터 만들어보자

실제 적용 전에 세가지 작은 실험을 준비하면 도입 판단이 쉬워질것 같다. 중요한건 기능을 한번 실행하는것보다 예상한 실패를 설명할 수 있는지다.

## 같은 문서를 두 경로로 분석하기

우선 내용과 버전이 같은 문서를 기존 입력 방식과 새로운 저장소 경로로 전달해보자. 파일 준비 시간과 전체 처리 시간, 결과에서 빠진 내용이 있는지 비교할 수 있다.

그 다음 접근이 만료된 문서와 삭제된 문서를 넣어본다. 사용자에게 다시 업로드를 요청할지, 작업을 다시 준비할지, 실패로 종료할지 정해두면 운영 중 대응도 분명해진다.

## 허용한 프로그램과 다른 프로그램 구분하기

kuberc는 정상 로그인 프로그램을 허용한 상태에서 인증 갱신까지 확인해보자. 테스트용 kubeconfig에서 허용하지 않은 실행 경로가 거부되는지도 격리된 환경에서 확인할 수 있다.

이때 사용자의 실제 로그인 도구를 임의로 교체하거나 운영 자격 증명을 넣을 필요는 없다. 실행 정책의 동작과 실제 계정 접속은 검증 목적을 나눠서 준비하면 된다.

## 볼륨을 새 노드에서 다시 연결하기

PV 변경은 데이터 손실 없이 되돌릴 수 있는 테스트 저장소에서 시작하자. 변경 전후의 접근 가능한 노드를 기록하고, 새로 만들어진 Pod가 예상한 위치에서 데이터를 읽는지 확인한다.

기존 Pod의 정상 동작만 보지말고 재생성 후 처음 연결하는 경로까지 포함하는것이 핵심이다. 데이터베이스처럼 저장소에 민감한 작업이라면 애플리케이션의 복구와 일관성 확인도 별도로 필요하다.

이 실험 결과를 성공과 실패, 추가 확인 항목으로 남겨두면 지금 사용할 기능과 더 기다릴 기능을 구분하기 쉽겠다.

# 마무리

이번주는 Gemini의 파일 입력, kubeconfig의 프로그램 실행, PV의 노드 조건처럼 서로 다른 경계에서 선택지가 넓어졌다.

개인적으로는 자동화가 편해질수록 실제로 무엇을 읽고 실행하며 어디에 접근하는지 설명하는 일이 중요해진다고 생각한다. 설정의 이름과 실제 자원의 동작이 항상 같은 수준의 이야기는 아니기 때문이다.

우선 우리 서비스의 파일 처리 흐름과 클러스터 접속 방식, 볼륨 배치 조건부터 정리해보면 좋겠다. 연결이 성공했다는것 다음에 의도한 범위에서 같은 결과를 만드는지 확인해야겠다..


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

독자의 메모