[2026.10.16 주간 개발 트렌드] AI 보안 자동화와 Lambda Web Functions, Actions Lockfile·DB 패치

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

# 이번주는 실행 환경과 변경 범위를 같이 보고 싶다

이번주에는 Next.js 16.4가 나오면서 캐싱과 렌더링을 다루는 기준이 더 구체화됐다. Copilot 로컬 Sandbox는 정식 제공으로 넘어갔고, Java·Kotlin의 코드 분석 도구는 VS Code와 Cursor 쪽으로 확장되고 있다.

Kubernetes에서는 오래된 노드의 cgroup 설정과 Swap 활용을 함께 볼만하다. GitHub의 Stacked PR까지 묶어보면 자동화가 일하는 환경뿐 아니라 사람이 변경을 검토하는 단위도 중요해지는것같다.

10월 5일부터 9일까지의 소식이다. 기능이 많아도 우리 프로젝트에서 확인할 지점은 나눠서 잡아보면 좋겠다.

# 1. AI — Copilot 로컬 Sandbox가 정식 제공됐다

10월 7일 [GitHub Copilot Local Sandboxing GA](https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/)가 발표됐다. CLI와 Copilot 앱, Agent Host를 사용하는 VS Code 세션이 대상이다.

Agent가 실행한 명령과 도구에 파일·네트워크·자격 증명 접근 정책을 적용한다. Microsoft eXecution Container(MXC)가 공통 정책을 Windows·macOS·Linux의 운영체제 제어로 연결한다. MXC라는 이름을 보고 모든 환경에서 같은 VM이나 Docker Container를 띄우는 구조로 생각하지는 않아야겠다.

로컬 MCP와 Language Server 같은 도구도 지원되는 경우 격리를 적용할 수 있다. 기업 관리 설정으로 사용자가 완화할 수 없는 정책을 요구하는것도 가능하다. 다만 정식 제공됐다는 사실만으로 내 세션의 실제 적용 범위까지 확인한것은 아니다.

## 모델을 바꾸는것과 실행 권한은 별도다

내가 팀 환경을 정리한다면 저장소와 테스트에 필요한 폴더부터 정하고 패키지 설치에 필요한 네트워크를 구분하고 싶다. 자격 증명도 개발 작업에 필요한 계정과 운영 권한을 나눠봐야겠다.

정상 작업이 되는지만 확인하면 정책이 너무 넓어도 알아채기 어렵다. 허용하지 않은 폴더나 외부 연결이 실제로 거절되는지도 검증할 부분이다. Sandbox 안에서 실행되는 도구와 밖에서 실행되는 보조 프로세스의 범위도 확인하고 싶다.

## Haiku 5.5는 짧고 많은 작업에 맞춘 선택지다

같은 날 [Claude Haiku 5.5의 Copilot 제공](https://github.blog/changelog/2026-10-07-claude-haiku-5-5-in-github-copilot/)도 발표됐다. Subagent와 빠른 수정, 터미널 작업처럼 빈도가 높은 업무를 강조한다. GitHub는 초기 시험에서 여러 코딩 작업을 Sonnet 5와 비슷한 수준으로 적은 토큰·단계에 수행했다고 설명한다.

모든 복잡한 설계를 같은 수준으로 처리한다는 의미는 아니다. 플랜과 조직 정책, 순차 적용 상태도 확인해야한다. 내 작업에서는 파일 분류와 변경 요약, 범위가 좁은 수정부터 비교해보고 싶다.

# 2. 프론트엔드 — Next.js 16.4가 캐싱 의도를 더 명확하게 만든다

10월 6일 [Next.js 16.4](https://nextjs.org/blog/next-16-4)가 정식 출시됐다. Next.js 팀은 Cache Components를 모든 앱에 권장하고 새 `create-next-app` 프로젝트에서는 기본 활성화한다고 안내한다. Next.js 17의 기본 모델로도 계획하고 있다.

기존 프로젝트가 버전만 올리면 새 모델로 전부 바뀐다고 생각하면 안되겠다. 캐시할 부분을 명시하는 모델이고 모든 데이터가 자동으로 캐시된다는 뜻도 아니다.

## 정적으로 유지할 페이지는 Build에서 확인한다

이번에 추가된 [`ensureStatic`](https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config/ensureStatic)은 선택한 렌더링 단계가 정적 결과를 사용하도록 요구한다. Cache Components를 활성화한 서버 페이지나 Layout에서 사용할 수 있다.

예를 들어 소개 페이지의 서버 렌더링을 정적으로 유지하려면 아래처럼 표현할 수 있다.

```tsx
export const ensureStatic = 'navigation';

export default function Page() {
  return <main>서비스 소개</main>;
}
```

`navigation`은 전체 서버 렌더링 결과에 가장 강한 정적 조건을 건다. 여기에 요청 시점의 서버 처리가 필요한 내용을 추가하면 검증에 실패하고 Build에서도 발견할 수 있다. 브라우저의 버튼과 입력까지 금지한다는 의미는 아니다.

내가 이 기능을 쓴다면 블로그와 마케팅 페이지처럼 정적 구성을 의도한 곳부터 적용할것같다. 로그인 사용자별 화면까지 Root Layout에서 한 번에 제한하기보다는 Route의 요구를 먼저 나눠보고 싶다.

## 미리 가져올것과 클릭한 뒤 가져올것을 구분한다

`navigation()`은 일부 내용을 실제 이동 시점까지 미루고, `prefetch()`는 Shell 단계에서 더 뒤의 명시적 Prefetch나 이동 시점으로 미루는데 사용한다. 데이터를 어느 단계에서 가져올지 세밀하게 정하는 변화다.

상품 목록에서 모든 상세 화면의 무거운 데이터를 미리 가져온다고 생각해보자. 클릭 후에는 빠를 수 있어도 열어보지 않은 상품까지 서버와 DB 작업이 생긴다. 반대로 아무것도 미리 가져오지 않으면 실제 이동에서 오래 기다릴 수 있다.

그래서 전환 속도만 보지는 않아야겠다. 실제 클릭률과 Prefetch 요청 수, DB 조회량을 같이 확인하면서 어디까지 앞당길지 정하고 싶다.

## 기존 서비스는 캐시 경계부터 검증하자

Turbopack 디스크 캐시는 별도 설정 없이 20~25% 작아졌다고 발표했고 React 19.3도 통합됐다. 이 수치를 전체 Build 시간의 동일한 감소율로 받아들이지는 않아야겠다.

`next upgrade --agent`는 버전별 가이드와 Codemod, 검증 절차를 Agent가 활용하도록 돕는다. 그래도 업데이트가 완료됐다는 응답과 서비스 동작 검증은 구분해야한다.

내가 기존 앱에 적용한다면 사용자·조직별 응답과 데이터 갱신, 로그아웃 뒤 화면을 우선 확인하고 싶다. 새 캐시 모델을 사용해도 인증과 권한 검사는 애플리케이션의 책임으로 남는다.

추가로 [10월 8일 보안 업데이트 예고](https://nextjs.org/blog/upcoming-nextjs-security-update-october-2026)도 나왔다. 다음주 수요일인 10월 14일에 기반 의존성의 Critical 2건·High 1건을 수정할 계획이다. 아직 공개 전이니 새 기능 검토와 별개로 당일 최종 영향 범위와 패치 안내를 확인해야겠다.

# 3. 백엔드 개발 도구 — IntelliJ의 코드 이해를 다른 편집기에서도 쓴다

10월 6일 [Java and Kotlin by IntelliJ IDEA RC](https://blog.jetbrains.com/idea/2026/10/java-and-kotlin-by-intellij-idea-the-lsp-based-extension-reaches-release-candidate/)가 공개됐다. IntelliJ의 언어 분석 기술을 LSP로 제공해 VS Code와 Cursor 같은 편집기에서 활용하는 확장이다.

코드 탐색과 검사, 프로젝트 단위 Refactoring과 DAP 기반 디버깅, Maven·Gradle·Bazel 지원, 테스트 실행과 Spring 도구 연동 등이 포함된다. Cursor Agent도 같은 Language Server로 의미 기반 검색과 분석을 수행할 수 있다고 설명한다.

## 같은 이름을 찾는것과 같은 심볼을 찾는것은 다르다

Java 코드에서 메서드 이름이 같아도 타입과 상속 관계에 따라 수정할 대상은 달라질 수 있다. 문자열 검색 결과만 보고 변경하면 무관한 호출까지 바꾸거나 실제 참조를 놓칠 수 있다.

이런 분석 정보를 Agent가 쓸 수 있다는 점이 반갑다. 다만 Language Server가 프로젝트를 올바르게 불러왔는지도 중요하다. 잘못된 JDK나 누락된 Module 상태로 분석한 결과는 기대와 다를 수 있다.

내가 시험한다면 큰 Refactoring부터 맡기기보다 사용처 찾기와 작은 이름 변경을 비교해보고 싶다. Build와 테스트가 통과하는지, 생성 코드와 멀티 모듈 구성까지 탐색되는지도 볼만하다.

현재는 정식 1.0이 아닌 RC다. 이번 RC는 EAP 조건으로 30일 동안 라이선스 없이 사용할 수 있고, 정식 버전은 신규 사용자에게 30일 체험 후 IntelliJ IDEA Ultimate 구독을 요구한다고 안내한다. 기능과 함께 팀의 사용 조건도 확인해야겠다.

# 4. 인프라 — cgroup 전환과 Swap은 노드 단위로 보자

10월 6일 [Kubernetes의 cgroup v2 전환 안내](https://kubernetes.io/blog/2026/10/06/kubernetes-cgroups-v2-shift/)가 나왔다. cgroup v2 지원은 1.25부터 Stable이고 v1은 1.31부터 유지보수 단계로 넘어갔다.

핵심은 1.35부터 `failCgroupV1` 기본값이 `true`라는 점이다. 기본 설정에서는 v1 노드의 Kubelet이 시작하지 않는다. 이번주 갑자기 전체 v1 지원을 제거한것과는 구분해야겠다.

Linux 노드에서 확인하는 명령은 다음과 같다.

```bash
stat -fc %T /sys/fs/cgroup
```

`cgroup2fs`라면 해당 경로는 cgroup v2 파일 시스템이다. 이 확인만으로 OS와 Container Runtime, Kubelet의 모든 설정이 맞는것까지 보장되지는 않는다.

## Pod 설정을 바꾸기 전에 노드가 시작하는지 보자

업그레이드 후 Kubelet이 시작하지 않는다면 Pod의 Limit보다 OS의 cgroup 구성과 Runtime·Kubelet 호환성을 먼저 확인해야겠다.

내가 전환한다면 대표 노드 한 대에서 Drain과 재시작, Pod 재배치와 모니터링을 시험할것같다. 버전 번호만 올리는 작업으로 보지 않고 노드를 다시 운영에 넣을 수 있는 절차까지 확인하고 싶다.

## Node Swap의 3배 수치는 Workload 조건과 함께 보자

10월 5일 [Node Swap 활용 사례](https://kubernetes.io/blog/2026/10/05/scaling-kubernetes-workloads-with-node-swap/)도 공개됐다. Swap을 사용하는 노드 지원은 이미 1.34에서 GA가 됐다. 이번주 자료는 빠른 Local SSD와 Swap을 활용한 실험 결과다.

격리된 Python Sandbox의 동시 실행 수가 80개에서 240개로 늘어난 사례가 소개됐다. 특정 Runtime과 데이터, 노드 조건의 결과이므로 모든 서비스의 처리량이 3배가 된다는 의미는 아니다.

처음에는 큰 메모리가 필요하지만 이후에는 입력을 기다리는 Sandbox라면 관심을 가질만하다. 계속 사용하는 메모리를 디스크로 밀어내면 오히려 지연이 커질 수 있다.

내가 비교한다면 동시 실행 수뿐 아니라 P95·P99 지연과 디스크 I/O, OOM과 재시작을 같이 기록하고 싶다. 일반 API 서버와 Agent Sandbox를 같은 기준으로 튜닝하기보다 Workload를 나눠서 보면 좋겠다.

# 5. 데이터베이스 — PostgreSQL 19는 예정일과 이전 계획을 분리하자

이번주에는 [9월 28일 공지된 PostgreSQL 19 일정](https://www.postgresql.org/message-id/915517c4-d0ee-49f9-bbeb-c683ef2b9d3f%40postgresql.org)을 기준으로 준비하면 되겠다. 다음 일정은 모두 계획이며 RC 기간에 중요한 문제가 나오면 달라질 수 있다.

| 단계 | 이번주 기준 예정일 |
| --- | --- |
| PostgreSQL 19 RC1 | 10월 15일 |
| PostgreSQL 19 GA | 10월 29일 |

내 서비스에서는 ORM의 버전뿐 아니라 실제 쿼리와 확장, 연결 Pool과 배치를 함께 시험하고 싶다. DB가 바뀌어도 같은 업무 결과를 내는지가 기준이 되겠다.

한편 [PostgreSQL 14 지원 종료](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/)는 11월 12일이다. 현재 14를 운영한다면 19 정식 출시를 기다리는 일과 지원 버전으로 이전할 계획을 따로 관리해야겠다. 드라이버·확장 지원과 복구 리허설에 필요한 시간을 먼저 확보하고 싶다.

# 6. 개발 워크플로 — Stacked PR은 변경을 이해할 단위로 나눈다

10월 6일 [GitHub Stacked Pull Requests](https://github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available/)가 GA가 됐다. 의존하는 변경을 여러 PR로 나눠 검토하고 묶어서 병합하는 흐름을 지원한다. github.com의 모든 플랜이 대상이고 Enterprise Server는 향후 릴리스 제공을 안내한다.

GitHub는 Preview 기간의 사용 저장소에서 비교군보다 병합 코드량이 9% 늘었다고 발표했다. 이 수치만으로 코드 품질과 생산성이 똑같이 9% 좋아졌다고 결론내릴 수는 없다.

## Agent가 만든 큰 변경에도 적용해볼 수 있겠다

예를 들어 기능 하나를 아래처럼 나누면 앞 단계의 의미를 확인하고 다음 변경을 볼 수 있다.

```text
PR 1: 기존 코드와 호환되는 DB 변경
  → PR 2: API와 Service 구현
  → PR 3: UI 연결과 사용자 흐름 검증
```

단순히 파일 수만 나누는것보다 각 PR이 무엇을 보장하는지 설명할 수 있어야겠다. 중간 상태에서도 Build와 테스트가 가능하면 검토하기 더 좋다.

또 병합 순서와 배포 순서는 따로 설계해야한다. Stack으로 관리한다고 DB 변경과 여러 서비스 배포가 자동으로 하나의 Transaction이 되지는 않는다. 이전 애플리케이션이 새 스키마와 함께 동작할 수 있는지도 확인할 부분이다.

내가 Agent에게 기능을 맡긴다면 구현 전에 변경 단위를 먼저 제안받고 싶다. 완성된 거대한 Diff를 나중에 잘라내기보다 리뷰할 흐름을 앞에서 정하면 좋겠다.

# 이번주는 적용할 범위를 작게 정해보자

코드가 빨리 만들어지는만큼 검토와 운영까지 감당할 수 있는 단위로 나누는 일이 필요해 보인다. 이번주는 기능을 많이 켜는것보다 무엇을 기대하고 적용했는지 분명하게 남겨보고 싶다..


[2026.10.09 주간 개발 트렌드] Next.js 16.4와 Copilot Sandbox, Kubernetes 메모리·Stacked PR

독자의 메모