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

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

# 이번주는 Agent에게 어디까지 맡길지 정하는 주다

이번주에는 GitHub의 Agent 권한 정책과 Actions 캐시 권한이 같이 눈에 들어왔다. 자동화가 실제 파일을 수정하고 명령을 실행하는만큼, 무엇을 할 수 있는지 개발환경에서 강제하는 기능도 구체화되고 있다.

9월 7일부터 11일까지의 소식이다. 이번주는 새 기능을 써보는 재미와 운영에서 확인해야할 부분이 적당히 섞여있는것같다.

# 1. AI — Agent 권한을 조직 정책으로 관리한다

9월 9일 [GitHub Copilot의 기업 관리 권한](https://github.blog/changelog/2026-09-09-enterprise-managed-permissions-for-github-copilot-agent-operations/)이 정식 제공됐다. Copilot Business와 Enterprise 관리자는 Shell 명령, 파일 읽기·수정, 네트워크 도메인에 대해 차단과 사람 승인, 자동 허용을 정할 수 있다.

관리자가 설정한 제한은 사용자의 로컬 설정이나 Auto-approval, 이전에 저장한 승인으로 약하게 만들 수 없다. 팀별로 다른 정책도 줄 수 있다. 적용 대상은 Copilot 앱과 CLI, Agent Host를 사용하는 VS Code 세션이다. 모든 IDE의 모든 Agent 실행에 동일하게 적용된다고 넓혀서 생각하지는 않아야겠다.

## 프롬프트와 실행 정책은 역할이 다르다

Agent에게 운영 DB를 건드리지 말라고 적어두는것과, 실제로 운영 DB에 연결할 수 없게 만드는것은 다른 일이다. 모델이 지침을 잘 따르는지도 중요하지만 실행 가능한 범위를 환경에서 제한할 수 있어야한다.

```text
업무 요청
  → 필요한 작업 범위 결정
  → 조직의 실행 정책 확인
  → 허용된 Tool 수행 또는 승인 대기
  → 변경 결과와 실행 기록 검토
```

## Code Quality 수정도 묶어서 맡길 수 있다

같은 날 [Code Quality의 Agentic Autofix](https://github.blog/changelog/2026-09-09-remediate-code-quality-findings-with-agentic-autofix/)도 공개됐다. 한 페이지에서 Standard Finding을 최대 25개 선택하면 Copilot이 브랜치에서 수정하고 자체 검증한 뒤 PR을 만든다.

GitHub Code Quality가 활성화된 Team·Enterprise Cloud 저장소가 대상이고 AI Credit을 사용한다. 기존 Code Quality 정책을 따르므로 별도 정책을 새로 관리하는 구조는 아니다.

내가 맡긴다면 같은 규칙이나 비슷한 코드 영역의 문제부터 묶을것같다. 서로 다른 모듈의 변경을 한 PR에 많이 넣으면 수정량은 줄어도 리뷰가 어려워질 수 있다. 수정 전후의 동작을 설명할 수 있는 단위가 좋겠다.

# 2. 프론트엔드 — React 19.3에서 화면 전환을 다루기 쉬워졌다

9월 9일 [React 19.3](https://react.dev/blog/2026/09/09/react-19-3)이 출시됐다. 이번 버전에서는 `<ViewTransition>`과 Fragment Refs가 Stable이 됐다. Trusted Types 지원과 Server Component에서 Context를 직접 렌더링하는 변화도 포함됐다.

## ViewTransition은 화면 변화의 연결을 표현한다

`<ViewTransition>`은 브라우저의 View Transition API와 React의 업데이트를 연결한다. 요소가 나타나고 사라지거나 위치와 크기가 달라지는 상황을 다룰 수 있다.

중요한 조건이 하나 있다. 모든 상태 변경이 자동으로 애니메이션이 되는것은 아니다. Transition으로 처리하는 업데이트가 대상이고 `startTransition`, Suspense에서 준비된 내용의 표시, `useDeferredValue` 등의 흐름과 연결된다.

나는 처음부터 페이지 전체를 감싸기보다 목록이나 상세 카드처럼 변화의 의미가 명확한 영역부터 적용해보고 싶다. 모달을 닫았는데 배경 전체가 움직이거나 빠르게 누를때 전환이 반복되면 오히려 피곤할 수 있다.

## Fragment Refs는 불필요한 Wrapper를 줄일 수 있다

Fragment에 Ref를 전달하면 `FragmentInstance`를 통해 자식 DOM을 묶어서 다룰 수 있다. 포커스 이동과 이벤트, 관찰 기능 등을 위해 Ref를 둘 Wrapper를 추가하던 상황에서 유용하겠다.

다만 Fragment가 실제 DOM 요소가 되는것은 아니다. Ref로 제공되는 기능과 일반 Element에서 가능한 작업을 같다고 생각하면 안되겠다. 접근성 의미가 필요한 그룹이라면 그 의미에 맞는 HTML 요소를 사용하는 판단도 여전히 필요하다.

## 보안 설정과 프레임워크 호환성도 같이 보자

Trusted Types 지원은 정책이 만든 객체를 React가 DOM으로 전달할 수 있게 하는 변화다. React를 업데이트했다는 이유만으로 HTML 정제가 자동으로 완성되거나 XSS가 사라지는것은 아니다. 서비스의 CSP와 정제 정책을 함께 점검해야겠다.

Server Component에서는 Client 모듈에서 가져온 Context를 별도의 Provider Wrapper 없이 렌더링할 수 있다. Server Component 자체에서 Context를 생성하고 소비하는 제한까지 사라졌다는 뜻은 아니다.

Next.js 같은 프레임워크에서는 지원하는 React 버전과 Router, UI 라이브러리 호환성도 확인해야겠다. React API의 안정화가 우리 배포 환경 전체의 호환성을 보장하지는 않는다.

# 3. 백엔드 — Node.js LTS와 Spring 개발 도구를 챙겨보자

9월 8일 [Node.js 24.21.0 LTS](https://nodejs.org/en/blog/release/v24.21.0)가 공개됐다. OpenSSL 3.5.8과 Undici 7.29.1, Root Certificate 갱신이 포함됐고 OpenSSL STORE Loader를 통한 Private Key 로딩도 지원한다. `net.BlockList`와 Histogram 구현 개선도 들어갔다.

## 새 API보다 먼저 우리 연결 경로를 확인하고 싶다

내가 Staging에서 올린다면 정상 요청만 보내지는 않을것같다. 연결이 늦어지는 경우와 응답 도중 끊기는 경우, Streaming을 취소하는 경우도 확인하고 싶다. 실패했을때 연결과 작업이 제대로 정리되는지도 백엔드 동작의 일부다.

## Spring Tools 5.4는 프로젝트를 이해하는 도구의 변화다

9월 9일 [Spring Tools 5.4.0](https://spring.io/blog/2026/09/09/spring-tools-5-4-0-released/)도 나왔다. Claude Code 플러그인이 프로젝트의 논리 구조를 보여주도록 개선됐고 Annotation 관련 검증과 Quick Fix, 인덱싱 안정성·성능 개선 등이 포함됐다.

Spring Boot의 새로운 Runtime 릴리스와는 구분해서 볼 소식이다. 애플리케이션 의존성을 올리는 작업과 IDE·플러그인을 업데이트하는 작업은 영향 범위가 다르다.

# 4. 인프라 — Kubernetes가 Pod보다 작업 전체를 보기 시작한다

9월 8일 공개된 [Kubernetes 1.37의 Workload-aware Scheduling 설명](https://kubernetes.io/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/)이 이번주 인프라에서 눈에 띈다. 이번주에 1.37이 새로 출시됐다는 소식과는 구분해야한다.

핵심은 여러 Pod의 배치를 하나의 작업 조건으로 판단하는것이다. Gang Scheduling과 Workload-aware Preemption, PodGroup의 DRA ResourceClaim 공유가 Beta로 올라왔고 계층적인 그룹을 표현하는 CompositePodGroup도 소개됐다.

## Pod 몇 개가 실행됐는지와 작업이 가능한지는 다르다

분산 학습에 Driver 하나와 Worker 여덟 개가 필요하다고 생각해보자. Worker 두 개만 배치할 수 있는 상황에서 일부 Pod가 실행됐다고 학습을 시작할 수 있는것은 아니다.

```text
하나의 학습 작업
  ├─ Driver 그룹
  └─ Worker 그룹
       └─ 작업에 필요한 최소 인원과 배치 조건
```

Gang Scheduling은 이런 최소 조건을 그룹으로 표현하는 방향이다. 여기서 All-or-nothing은 정한 배치 조건에 대한 이야기다. 모든 프로세스가 같은 순간에 시작되거나 작업 도중 장애가 절대 발생하지 않는다는 보장은 아니다.

애플리케이션에는 여전히 준비 상태 확인과 Worker 연결, 중도 이탈 처리와 Checkpoint가 필요하다. 스케줄러가 자리를 잡아주는것과 분산 프로그램이 올바르게 실행되는것을 나눠서 봐야겠다.

## 같은 버전 안에서도 안정화 단계가 다르다

| 기능 | 1.37에서의 단계 |
| --- | --- |
| Workload·PodGroup, Gang Scheduling, Workload-aware Preemption | Beta |
| PodGroup의 DRA ResourceClaim 공유 | Beta |
| CompositePodGroup | Alpha |
| Topology-aware Workload Scheduling | Alpha |

이 글에서 다루는 Beta·Alpha 기능은 기본 비활성화이며 필요한 Feature Gate를 직접 켜야한다. API Server만 바꾸는것이 아니라 기능에 따라 Controller Manager와 Scheduler, Kubelet 설정도 함께 확인해야겠다.

CompositePodGroup과 다단계 Topology는 전체 작업은 같은 Zone에 두고 각 하위 그룹은 특정 Rack에 배치하는 요구를 표현할 수 있다. PodGroup의 Claim 공유는 그룹용 장치 요청을 Pod마다 중복 생성하는 문제를 줄이는 방향이다.

테스트할때는 GPU 사용률과 함께 작업 대기 시간, 완료 시간과 다른 팀의 작업이 밀린 정도도 보고 싶다. 일부 Pod의 실행보다 전체 작업의 진척을 확인하는게 중요하겠다.

# 5. DevSecOps — Actions 캐시도 읽기와 쓰기를 나눈다

9월 10일 [GitHub Actions의 cache-mode](https://github.blog/changelog/2026-09-10-control-github-actions-cache-access-with-cache-mode/)가 모든 플랜에 정식 제공됐다. Workflow나 Job별로 캐시에 접근할 수 있는 범위를 정할 수 있다.

| 설정 | 캐시 복원 | 캐시 저장 |
| --- | --- | --- |
| `read` | 가능 | 불가 |
| `write` | 가능 | 가능 |
| `write-only` | 불가 | 가능 |
| `none` | 불가 | 불가 |

`write`가 쓰기 전용이라는 뜻은 아니다. 읽기와 쓰기를 모두 허용한다. Job 설정은 Workflow 설정을 덮어쓰며, Reusable Workflow는 호출자가 허용한 범위보다 더 넓은 캐시 권한을 받을 수 없다.

## 기본값을 직접 넓힐 수 있다는 점이 중요하다

`pull_request_target` 같은 낮은 신뢰도의 이벤트는 기본적으로 `read`, 신뢰되는 `push` 등은 `write`를 사용한다. 다만 낮은 신뢰도의 이벤트에도 `write`나 `write-only`를 명시하면 기본 읽기 전용 제한을 덮어쓸 수 있고 경고가 표시된다.

어떤 입력으로 만든 캐시를 이후 누가 복원하는지 연결해서 봐야한다.

## 캐시 권한과 저장소 권한은 각각 설정한다

[공식 Workflow 문법](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#cache-mode)을 기준으로 필요한 부분만 적으면 아래처럼 구분할 수 있다.

```yaml
permissions:
  contents: read

cache-mode: read
```

`permissions`는 저장소 토큰 권한이고 캐시 권한과는 별도다. 금지된 캐시 작업은 건너뛰어도 Job이 실패하지 않으므로 적용 여부는 로그에서 확인해야겠다.

캐시를 읽기 전용으로 바꿔도 Secret과 네트워크, 실행한 Action의 출처는 별도로 점검해야한다. 캐시는 다시 만들 수 있는 가속 수단으로 두고 배포 Artifact와 구분해서 관리하고 싶다.

# 6. 데이터베이스 — PostgreSQL 19는 기다리면서 검증할 시점이다

이번주 PostgreSQL에서는 새 메이저 출시보다 개발 버전 검증을 이어가면 좋겠다. 현재 공개된 개발 버전은 [19 Beta 3](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/)이고 운영 적용 대상으로 보기는 어렵다.

[9월 3일 개발자 메일링리스트의 일정 안내](https://www.postgresql.org/message-id/f515cc05-67ee-4295-bc79-41c48ce2589d%40postgresql.org)는 Beta 4를 9월 24일에 내고 10월 말까지 정식 출시하는것을 목표로 설명한다. 따라서 이번달 GA를 전제로 일정을 잡기보다는 테스트 결과와 추가 공지를 확인해야겠다.

SQL/PGQ와 REPACK 같은 개발 중 기능은 흥미롭다. 다만 기능 이름을 보고 도입 결정을 끝내기에는 아직 이르다. Beta 3에서도 `GROUP BY ALL`이 되돌려졌고 Sequence 논리 복제 등 새 기능의 수정이 이어졌다. 개발 버전의 기능 구성이 고정됐다고 생각하지 않아야겠다.

REPACK 계열 기능은 정리 중의 Lock 대기와 추가 공간, 복제 지연을 같이 시험해보고 싶다. Concurrent라는 이름을 완전한 무중단으로 받아들이지는 않아야겠다.

운영 DB에서 지원 버전의 유지보수 패치를 적용하는 일은 별도로 계속 챙겨야한다. 차기 메이저를 기다린다고 현재 버전의 업데이트를 미루지는 않아야겠다.

# 이번주에는 사용할 수 있는 범위를 구체적으로 보자

React를 쓴다면 작은 화면 한 곳에서 전환과 포커스를 확인해보고 싶다. Node 서비스는 실제 배포 Runtime과 외부 연결을 점검하고, 팀의 Agent 환경에서는 어떤 작업이 자동 허용되는지부터 살펴보면 좋겠다.

Kubernetes는 기능별 단계와 활성화 조건을, Actions는 캐시를 만들고 가져가는 실행의 관계를 확인해볼 주다. 새 기능이 많았지만 각자 필요한 부분부터 골라서 이해하면 될것같다. 자동화가 편해질수록 내가 허용한 범위를 설명할 수 있는게 더 중요해지는것같다..


[2026.09.11 주간 개발 트렌드] Agent 권한 통제와 React 19.3, Kubernetes 작업 스케줄링

독자의 메모