[2026.09.25 주간 개발 트렌드] AI 비용 경쟁과 Next.js·PgBouncer 패치, Actions Node 20 종료

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

# 이번주는 기본값이 어떻게 바뀌는지 보고 싶다

이번주에는 새로운 기능의 이름보다 기본 동작과 정책이 눈에 들어왔다. Copilot은 모델을 고르는 기준을 제공하고, Java 27은 JVM의 기본 설정을 바꿨다. GitHub Actions도 Workflow가 실행되기 전부터 정책을 적용하는 방향으로 발전하고 있다.

9월 14일부터 18일까지의 소식이다. 코드가 그대로여도 모델과 Runtime, CI 환경에 따라 결과가 달라질 수 있다는 점에서 같이 볼만한 주제들이었다.

# 1. AI — 모델 선택도 작업에 맞춰 조절한다

9월 14일 [GitHub Copilot의 자동 모델 선택](https://github.blog/changelog/2026-09-14-configure-cost-and-quality-in-copilot-auto-model-selection/)에 Efficiency, Balance, Intelligence 세 단계가 추가됐다. 비용과 품질, 응답 시간 중 어떤 기준을 더 중요하게 볼지 정하면 요청별로 모델을 선택한다.

세 단계가 서로 다른 모델 목록을 사용하는것은 아니다. 동일한 모델 집합에서 선택 기준이 달라진다. Intelligence를 골라도 단순한 주석 추가라면 작은 모델을 사용할 수 있다. VS Code와 Copilot CLI, Copilot 앱에 순차 적용되며 사용량은 실제 선택된 모델을 기준으로 계산한다.

## 강한 모델을 고정하는것만이 답은 아니다

이 변화를 서비스 설계에 연결하면 아래처럼 생각해볼 수 있겠다. Copilot의 내부 구조를 설명하는 그림은 아니고 애플리케이션에서 적용해볼 구분이다.

```text
작업 요청 → Routing Policy → 선택한 모델 → 결과 검증
```

문의 내용을 분류하는 작업과 여러 시스템의 정보를 비교해 조치하는 작업에 같은 비용과 시간을 쓸 필요는 적다. 작업 종류별로 필요한 품질과 허용 지연을 정하면 모델 선택을 따로 다룰 수 있다.

다만 처음부터 난이도를 완벽하게 분류하는 Router를 만들려고 하면 일이 커질것같다. 내가 만든다면 정해진 형식의 분류와 요약처럼 검증하기 쉬운 작업부터 분리하고 싶다.

모델을 바꿀때는 응답 문장만 비교하면 부족하다. Tool 호출 형식과 출력 스키마, 실패율도 같이 봐야한다. 저렴한 모델이 여러 번 재시도해서 결국 더 비싸지는 경우도 기록해야겠다.

어떤 정책으로 어떤 모델을 골랐는지 남겨두면 품질이 달라졌을때 원인을 찾기 쉽다. 비즈니스 로직에 특정 모델 이름을 흩어놓기보다 선택하는 지점을 모아두는 편이 관리하기 좋겠다.

## 실시간 Agent는 말하는 동안에도 작업한다

9월 15일 Google은 [Gemini 3.8 Live와 Live Extended Thinking](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-live-gemini-3-8-live-extended-thinking/)을 발표했다. Live는 자연스러운 대화와 시각 문맥, 비용 효율을 강조하고 Extended Thinking은 복잡한 작업과 다단계 추론에 초점을 둔다.

대화하면서 뒤에서 Tool과 API를 실행하는 흐름이 흥미롭다. 음성으로 주문 상태를 물어보고 이어서 배송지 변경을 요청하는 상황이라면, 대화와 업무 처리가 동시에 진행될 수 있다.

여기서 음성 응답을 멈추는것과 이미 실행한 업무를 취소하는것은 구분해야한다. 사용자가 말을 끊었다고 외부 API에 반영된 변경까지 되돌아가지는 않는다.

내가 음성 Agent를 만든다면 요청 ID와 실행 상태를 연결하고 싶다. 대화가 끊기거나 다시 연결됐을때 완료된 작업을 다시 수행하지 않도록 하는것이 중요하겠다. 결제와 예약 같은 쓰기 작업은 실행 전 확인할 내용도 명확해야한다.

WebSocket이나 WebRTC 같은 연결 방식뿐 아니라 첫 응답까지의 시간, 중간 끼어들기와 취소, 재연결을 같이 설계해야한다. 말이 자연스러워지는만큼 백엔드가 처리 중인 상태도 정확하게 보여줘야할것같다.

# 2. 프론트엔드 — 지난주 기능을 우리 화면에서 확인해보자

이번주 React와 Next.js에서는 새 메이저 버전을 중심으로 정리할 소식은 크지 않다. [React 공식 블로그](https://react.dev/blog)의 최근 주요 릴리스는 지난주 React 19.3이고, [Next.js 블로그](https://nextjs.org/blog)에서도 이번주 새 메이저 발표보다는 기존 기능을 이어서 보면 되겠다.

그래서 이번주는 기술 목록을 늘리기보다 기존 프로젝트의 호환성을 확인해보고 싶다. React 19.3의 ViewTransition과 Fragment Refs를 검토한다면 사용하는 프레임워크와 UI 라이브러리가 지원하는지도 같이 봐야한다.

화면 전환은 자주 쓰는 경로 하나부터 비교하면 좋겠다. 목록에서 상세로 들어갔다가 돌아올때 스크롤과 포커스가 자연스러운지, 느린 네트워크에서도 사용자가 현재 상태를 이해할 수 있는지 보고 싶다.

Bundle도 초기 화면의 크기만 보기보다 다음 화면으로 이동할때 무엇을 추가로 받는지 같이 재보자. 지난주 새 API를 읽어봤다면 이번주는 실제 화면에 연결해보는 정도가 적당할것같다.

# 3. 백엔드 — Java 27은 코드를 바꾸지 않아도 달라질 수 있다

9월 15일 [Java 27이 정식 출시](https://inside.java/2026/09/15/jdk-27-available/)됐다. 이번 버전에서는 HotSpot의 G1 GC와 Compact Object Headers가 기본값이 되는 변화가 특히 눈에 띈다. TLS 1.3의 Post-Quantum Hybrid Key Exchange와 JFR 데이터 Redaction도 포함됐다. Structured Concurrency는 일곱 번째 Preview다.

## GC를 지정하지 않았다면 실제 선택을 확인하자

이제 HotSpot은 GC를 명령줄에서 지정하지 않은 모든 환경에서 G1을 선택한다. 이미 명시적으로 다른 GC를 사용하는 설정까지 무시하고 바꾼다는 뜻은 아니다.

큰 서버뿐 아니라 작은 Container와 개발·테스트 환경에서도 실제로 어떤 GC가 선택됐는지 확인할 이유가 생겼다. Dockerfile과 배포 설정에 옵션을 적어놓았더라도 최종 실행 인자에 반영됐는지 같이 보고 싶다.

내가 비교한다면 같은 메모리 제한과 트래픽에서 처리량, 긴 GC Pause와 응답 지연을 함께 기록할것같다. 평균 응답 시간이 같아도 일부 요청이 오래 기다리면 서비스 경험은 달라질 수 있다.

메모리도 Java Heap만 보지는 않아야겠다. 프로세스 전체 사용량과 Container 제한까지 같이 확인해야 운영에서 얼마나 여유가 생겼는지 판단할 수 있다.

## 객체 헤더가 작아져도 Heap 전체가 같은 비율로 줄지는 않는다

Compact Object Headers는 64비트 환경에서 객체 헤더를 96bit에서 64bit로 줄이는 기본 배치다. 작은 객체가 많이 만들어지는 서비스에서는 관심을 가질만한 변화다.

그렇다고 헤더의 감소 비율을 전체 메모리 절감률로 그대로 계산하면 안되겠다. 객체 안의 필드와 정렬, 배열과 실제로 살아있는 객체의 구성이 다르기 때문이다.

운영과 비슷한 요청을 보내면서 객체 생성량과 GC 이후 남는 메모리를 비교해보고 싶다. 한 번의 숫자보다 Warm-up 이후 같은 조건으로 반복했을때의 경향이 더 도움이 될것같다.

## 보안·진단 기능도 적용 범위를 구분하자

TLS Hybrid Key Exchange는 기존 알고리즘과 양자 내성 알고리즘을 결합한다. 실제 연결에서 무엇을 사용하는지는 상대 서버와 협상 조건도 함께 확인해야겠다. 새 JDK를 설치했다고 모든 연결의 암호 구성이 같아지는것은 아니다.

JFR Redaction은 명령줄 인자와 초기 환경 변수·시스템 속성 값 같은 진단 데이터를 프로세스 밖으로 나가기 전에 가릴 수 있게 하는 기능이다. 애플리케이션 로그나 모든 문자열의 Secret까지 자동으로 지운다고 생각하지는 않아야한다.

Java 27은 Non-LTS다. Java 25 등 현재 운영 중인 LTS를 바로 교체하기보다 Spring Boot와 드라이버, 모니터링 Agent의 지원 여부부터 확인하고 싶다. CI나 Staging에 비교 환경을 하나 두는것만으로도 다음 이전을 준비하는데 도움이 되겠다.

# 4. DevOps — Workflow 실행 전부터 권한을 판단한다

9월 17일 [GitHub Actions Workflow Execution Protections](https://github.blog/changelog/2026-09-17-workflow-execution-protections-in-github-actions-generally-available/)가 GA가 됐다. Enterprise와 조직, 저장소 수준에서 누가 어떤 이벤트로 Workflow를 시작할 수 있는지 Allowlist로 관리한다.

특정 Workflow 파일을 대상으로 규칙을 정할 수 있고 Insights와 REST API도 제공한다. Evaluate Mode에서는 실제로 막기 전에 어떤 실행이 차단될지 확인할 수 있다.

## CI와 배포의 실행 조건은 다를 수 있다

PR을 올린 사람의 변경을 테스트하는 작업과 운영 배포를 시작하는 작업은 필요한 신뢰 수준이 다르다. 같은 저장소에 있다는 이유만으로 같은 실행 조건을 줄 필요는 없다.

```text
실행 주체·이벤트 정책 → Workflow 실행 → Job 권한 → Secret·배포 대상 접근
```

각 단계의 역할을 나눠보면 이해하기 쉽다. `permissions:`를 줄이는것은 Job이 사용하는 토큰의 범위를 제한하는 일이고, 실행 정책은 그 앞에서 Workflow가 시작될 수 있는지를 판단한다.

내가 조직에 적용한다면 먼저 Evaluate Mode로 자동화 Bot과 정기 작업, 외부 기여의 실행 경로를 살펴볼것같다. 사람이 누르는 배포만 생각하다가 정기 보안 검사나 공통 Workflow가 함께 막히는 상황은 피하고 싶다.

## pull_request_target은 대상과 기본 정책을 확인해야겠다

적용 가능한 이벤트 정책이 없는 Public 저장소에는 `pull_request_target`을 제한하는 기본 규칙이 도입된다. 처음에는 Evaluate Mode로 동작하며 Private·Internal 저장소에는 이 기본 규칙이 적용되지 않는다.

따라서 모든 저장소에서 이미 실행이 차단됐다고 생각하면 안된다. 현재 정책과 평가 결과를 직접 확인해야겠다.

이 이벤트는 Base 저장소 문맥에서 실행되기 때문에 Fork의 신뢰하지 않는 코드를 실행하는 흐름과 섞이지 않는지가 중요하다. Label 처리에 필요한 권한과 외부 코드를 테스트하는 권한을 분리해서 보고 싶다.

## ubuntu-latest도 그대로인 환경은 아니다

같은 날 [Ubuntu 26.04 Runner 이미지의 정식 제공](https://github.blog/changelog/2026-09-17-ubuntu-26-generally-available-and-latest-migration/)이 발표됐다. `ubuntu-latest`는 10월 19일부터 11월 19일까지 24.04에서 26.04로 순차 전환될 예정이다.

미리 시험하려면 필요한 Job에서 아래처럼 명시할 수 있다.

```yaml
runs-on: ubuntu-26.04
```

ARM 이미지는 `ubuntu-26.04-arm`이다. 준비가 더 필요하면 `ubuntu-24.04`로 고정한 뒤 검증할 수 있다. 다만 OS Label을 고정하는것과 이미지 안의 모든 도구 버전을 영구 고정하는것은 다르다.

특히 사전 설치된 도구와 apt Package, Native Module에 암묵적으로 의존하는 Build를 확인하고 싶다. 애플리케이션 Runtime 버전을 직접 설치하는 작업과 OS가 제공하는 라이브러리를 구분해두면 실패 원인을 찾기 쉽겠다.

# 5. Kubernetes — 기본 활성화와 실제 메모리 정책은 다르다

이번주에는 1.37의 자원 관리 기능을 설명하는 글도 나왔다. 9월 14일 [Memory QoS Beta 안내](https://kubernetes.io/blog/2026/09/14/kubernetes-v1-37-memory-qos-graduates-to-beta/)에서 중요한 부분은 기본값이다.

`MemoryQoS` Feature Gate는 기본 활성화지만, 기본 Kubelet 설정은 새 Throttling이나 Reservation을 켜지 않는다. `memoryThrottlingFactor`는 `null`, `memoryReservationPolicy`는 `None`이며 명시적으로 설정하지 않으면 `memory.high`, `memory.min`, `memory.low`를 적용하지 않는다.

Linux의 cgroup v2가 전제다. 업그레이드만으로 모든 Pod에 메모리 보호가 자동 적용됐다고 판단하면 안되겠다.

내가 설정을 검토한다면 메모리를 많이 쓰는 Pod 하나보다 같은 노드에서 함께 실행되는 작업도 보고 싶다. 메모리 회수를 제한하거나 압박 시 속도를 늦추는 정책은 이웃한 작업의 지연에도 영향을 줄 수 있기 때문이다.

9월 15일 안내된 [Pod-Level Resource Managers](https://kubernetes.io/blog/2026/09/15/kubernetes-v1-37-pod-level-resource-managers-beta/)는 Beta지만 기본 비활성화다. Kubelet의 Topology·CPU·Memory Manager가 Pod의 `.spec.resources`를 자원 배치와 NUMA 정렬 판단에 사용한다.

주요 컨테이너에는 전용 자원을 두고 가벼운 Sidecar에는 Pod 안의 공유 자원을 쓰는 형태를 지원한다. 지연에 민감한 작업에서는 흥미롭지만, 일반 웹 서버 전체에 일괄 적용하기보다 대상 노드와 Workload를 좁혀서 비교해보고 싶다.

# 6. 데이터베이스 — PostgreSQL 이전 준비와 Redis 패치 대상을 보자

이번주 PostgreSQL 본체의 새 메이저·마이너 릴리스는 없다. [공식 발표](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/) 기준으로 18.6 계열과 19 Beta 3를 계속 확인하면 되겠다. PostgreSQL 14의 지원 종료는 11월 12일이다.

14를 운영 중이라면 차기 버전을 기다리는것과 별개로 지원되는 버전으로 이전할 준비가 필요하다. 사용 중인 확장과 드라이버, 백업 복구를 확인하고 실제 데이터로 이전 시간을 재보는 편이 좋겠다.

## Redis는 Operator가 관리하는 Active-Active DB 문제다

[Redis Software for Kubernetes 8.2.0-15 릴리스 노트](https://redis.io/docs/latest/operate/kubernetes/release-notes/8-2-0-releases/8-2-0-15-september2026/)는 Active-Active DB의 자격 증명이 지워질 수 있는 높은 심각도의 문제를 수정했다. 일반 Redis 전체에 같은 버그가 있다는 의미로 읽지는 않아야겠다.

Operator가 설정을 다시 보내면서 변경됐다고 판단한 Secret만 읽어 나머지 비밀번호를 빈 값으로 보낼 수 있었다. 8.2.0-12 이전 Operator에서는 mTLS Client Certificate도 제거될 수 있었다.

기존 연결은 살아있지만 새 비밀번호 연결은 실패하고, 반대로 자격 증명이 없는 연결이 허용될 수 있다는 점이 특히 문제다. DB가 Healthy로 표시돼도 인증 상태가 올바르다고 볼 수 없었다.

해당 8.2.0 계열에서는 Operator 8.2.0-15 이상으로 업데이트하도록 권고한다. 수정은 영향을 받은 DB도 자동 복구한다고 안내한다. 엔진 버전만 보고 끝내지 말고 Operator 이미지와 실제 인증 동작을 같이 확인해야겠다.

이 사례를 보면 연결 성공률과 DB의 상태 표시 외에 인증 조건도 운영 검증에 포함할 이유가 있다. 자격 증명을 바꾼 뒤 허용한 연결은 성공하고 허용하지 않은 연결은 거절되는지까지 확인하고 싶다.

# 이번주는 자동으로 바뀌는 부분을 하나씩 확인하자

Copilot은 선택한 단계와 실제 모델을, Java는 실행 옵션과 메모리를 확인해보면 좋겠다. Actions에서는 정책 평가 결과와 Runner 이미지를 먼저 살펴보고 싶다.

Kubernetes는 Feature Gate만으로 판단하지 않고 실제 설정을, Redis는 사용하는 제품과 Operator를 확인해야겠다. 기능이 추가됐다는 소식에서 한 걸음 더 들어가 우리 환경의 기본값이 무엇인지 알아두면 좋을것같다..


[2026.09.18 주간 개발 트렌드] AI 모델 라우팅과 Java 27, Actions 실행 정책·인프라 기본값

독자의 메모