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

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

# 이번주는 Agent의 실행 과정이 더 구체적으로 보인다

이번주에는 모델 이름뿐 아니라 모델을 어떤 과정 안에서 사용할지가 눈에 들어왔다. Sonnet 5.5와 GPT-6.1 Sol은 작업당 비용을 강조했고, Copilot은 여러 Agent의 실행 순서를 코드로 작성하는 기능과 데스크톱 앱 조작을 공개했다.

운영에서 먼저 확인할 소식도 있다. Next.js는 지난주에 이어 보안 패치가 나왔고 Self-hosted Runner는 버전을 오래 유지하면 Job을 받지 못할 수 있다.

9월 28일부터 10월 2일까지의 소식이다. 새 기능을 시험할 환경과 지금 업데이트할 환경을 구분해서 보면 좋겠다.

# 1. AI — 같은 단가에서도 작업 비용이 달라질 수 있다

9월 28일 [Claude Sonnet 5.5](https://www.anthropic.com/claude-sonnet-5-5)가 공개됐다. Anthropic은 Sonnet 5보다 출력이 30% 이상 빠르고 일반적인 작업의 비용을 최대 30% 줄였다고 설명한다. 범위가 명확한 기능 구현과 버그 수정 같은 일상 작업을 강조한다.

여기서 입력·출력 단가 자체는 Sonnet 5와 같은 100만 토큰당 $2·$10이다. 캐시 읽기는 $0.20에서 $0.10으로 내려갔고 같은 작업에 필요한 토큰이 줄었다는 설명이다. 모든 토큰 가격이 30% 인하된것으로 이해하면 안되겠다.

이번주 나온 [GPT-6.1 Sol](https://openai.com/index/introducing-gpt-6-1-sol/)도 비슷한 방향이다. OpenAI는 코딩과 Computer Use, 전문 업무 평가에서 Astra에 근접하면서 일반 입력·출력 단가는 Astra의 5분의 1이라고 발표했다. 입력 $2, 출력 $10, 캐시 입력 $0.10으로 단위는 100만 토큰이다.

[9월 29일 Copilot 제공 안내](https://github.blog/changelog/2026-09-29-gpt-6-1-sol-in-github-copilot/)에서는 초기 시험에서 이전 GPT 계열보다 적은 토큰과 단계로 작업을 마쳤다고 설명한다. 순차 적용되며 플랜과 조직의 모델 정책에 따라 사용 가능 여부를 확인해야한다.

이런 수치는 업체가 평가한 작업과 설정에서 나온 결과다. 같은 가격표를 쓴다고 우리 작업의 비용과 성공률까지 같지는 않다.

## 작은 모델을 먼저 부르는것도 비교 대상이다

작은 모델로 시작하고 실패하면 더 강한 모델을 부르는 방식은 합리적으로 보인다. 다만 실패를 뒤늦게 발견하면 첫 번째 실행과 두 번째 실행의 비용을 모두 내게 된다.

내가 라우팅을 만든다면 성공을 어떻게 판단할지 먼저 정할것같다. 코드가 실행되는지와 요구한 동작을 만족하는지, 변경 범위를 지켰는지는 다른 기준이다. Agent가 스스로 완료라고 답했다는것만으로 다음 단계를 통과시키지는 않아야겠다.

요청한 기능과 기대 결과가 명확한 작업부터 평가 묶음을 만들고 싶다. 동일한 저장소 상태에서 시작해 검증 통과율과 완료 시간, 총비용과 리뷰 수정량을 비교하면 선택하기 쉬워지겠다.

큰 모델을 낮은 추론량으로 사용하는 방식과 작은 모델을 오래 실행하는 방식도 함께 볼 수 있다. 모델의 크기만으로 비용 순서를 정하기보다 검증을 통과한 작업 하나에 실제로 얼마가 들었는지 보고 싶다.

# 2. AI·백엔드 — Dynamic Workflows가 실행 순서를 코드로 만든다

10월 1일 [Copilot Dynamic Workflows](https://github.blog/changelog/2026-10-01-dynamic-workflows-in-copilot-cli-and-the-copilot-app/)가 CLI와 앱, SDK에 공개됐다. 일반 프로그램 단계와 Agent의 작업을 섞고 순차·병렬 실행과 결과 전달을 코드로 정할 수 있다. Copilot Extension 안에 프로그램을 두는 방식이다.

현재 Public Preview다. 모든 Copilot 플랜에서 제공하며 앱에서는 별도 설정 없이 쓸 수 있고, CLI에서는 최신 버전과 Experimental 기능 활성화가 필요하다고 안내한다. 검토를 위해 멈췄다가 이어가는 Checkpoint도 지원한다.

## 반복할 절차와 판단할 부분을 나눠보자

장애 분석을 예로 들면 아래처럼 생각해볼 수 있겠다. 제품 API 문법을 그대로 옮긴 코드가 아니라 역할을 나눈 흐름이다.

```text
정해진 시간 범위의 로그·지표 수집
  ├─ API 오류 분석 Agent
  ├─ DB 지연 분석 Agent
  └─ 배포 변경 분석 Agent
       ↓ 구조화된 결과 취합
       ↓ 서로 모순되는 주장과 누락 확인
       ↓ 사람이 검토할 장애 보고서 작성
```

로그를 어느 시간 범위에서 가져올지와 결과 형식은 프로그램으로 정하고, 원인을 해석하는 부분은 Agent에 맡길 수 있다. 같은 일을 다시 실행할때 매번 절차를 설명할 부담이 줄어들겠다.

그렇다고 코드로 순서를 정하면 Agent의 답까지 매번 같아지는것은 아니다. 절차의 재현성과 판단 결과의 재현성은 구분해야한다. 보고서에 근거가 된 로그와 배포 ID를 연결해두면 검토할때 도움이 되겠다.

## 병렬 분석의 실패도 정상적인 결과로 다뤄야겠다

여러 Agent를 동시에 실행할때 하나가 실패하면 전체를 다시 시작할지, 성공한 결과는 보관할지 정해야한다. Timeout과 취소, 결과가 늦게 도착한 경우도 실행 상태에 포함하고 싶다.

쓰기 작업을 넣는다면 재시도할때 같은 변경이 두 번 반영되지 않도록 별도 기준이 필요하다. Checkpoint 지원이 외부 API의 부작용이나 DB 변경까지 자동으로 되돌린다는 의미는 아니다.

Spring이나 NestJS에서 Workflow를 만든다면 익숙한 문제들이다. API는 작업을 접수하고 Worker는 실행 상태를 관리하며 Tool은 기존 Service를 호출하게 나누면 권한과 검증 위치를 설명하기 쉽겠다.

간단한 질문이나 파일 하나의 수정까지 모두 Workflow로 만들 필요는 적을것같다. 여러 번 반복하거나 중간 확인이 필요한 절차부터 코드로 표현해보면 좋겠다.

# 3. Agent — Computer Use는 로그인된 앱의 권한과 연결된다

같은 날 [Copilot의 Computer Use](https://github.blog/changelog/2026-10-01-github-copilot-can-now-interact-with-desktop-apps/)도 Public Preview로 공개됐다. macOS와 Windows의 Copilot CLI·앱에서 앱의 내용과 화면을 읽고 클릭과 입력, 스크롤·드래그 등을 수행한다.

앱을 제어하기 전에 사용자 승인을 요청하고 항상 허용한 앱은 검토하거나 초기화할 수 있다. macOS에서는 접근성·화면 기록 권한도 필요하며 조직 설정에서 기능을 끌 수 있다.

API나 CLI가 없는 프로그램도 자동화할 수 있다는 점이 실용적이다. 다만 이때의 작업 범위는 Tool의 이름보다 현재 로그인된 앱이 할 수 있는 일에 가까워질 수 있다.

## 클릭 성공과 업무 완료는 다르다

예를 들어 설정 화면의 저장 버튼을 눌렀더라도 서버 반영이 실패했을 수 있다. 완료 메시지와 저장된 값을 다시 확인하는 과정이 필요하다. UI가 바뀌거나 대화상자가 생겼을때도 다음 동작을 새 상태에 맞춰 판단해야겠다.

내가 자동화를 맡긴다면 사용할 앱과 수정할 대상, 완료 기준을 구체적으로 적고 싶다. 조회와 문서 편집, 외부 제출처럼 결과의 영향이 다른 단계도 구분하면 좋겠다.

지난주 Shell Sandbox가 나왔다는 이유로 모든 GUI 작업까지 같은 경계로 보호된다고 생각하면 안된다. 앱 승인과 로그인 세션, 파일 접근 범위가 실제로 어떻게 연결되는지 따로 확인해야겠다.

특히 작업 지시와 앱 안에서 읽은 텍스트를 구분하는것이 중요해 보인다. 화면에 적힌 안내가 자동화의 원래 목적이나 허용 범위를 바꾸는 근거가 되어서는 안되겠다.

# 4. 프론트엔드 — Next.js는 지난주 패치 뒤에도 다시 올려야한다

9월 30일 [Next.js 16.3.8과 15.5.27 보안 릴리스](https://nextjs.org/blog/september-2026-security-release)가 나왔다. High 1건, Medium 5건, Low 1건을 수정했다. 지난주 사전 안내에 포함됐던 Critical 1건과 다른 High 1건은 기반 의존성의 지연으로 수정이 연기됐다.

지난주 16.3.6이나 15.5.26을 적용했어도 이번 패치는 별도로 확인해야한다. 16.3 계열의 패치 명령은 아래와 같다.

```bash
npm install next@16.3.8
```

15.5 계열은 `next@15.5.27`을 확인하면 된다. 앞으로도 추가 보안 공지를 이어서 봐야겠다.

## Image Optimization은 URL 허용 목록도 살펴보자

[Image Optimization의 SSRF 공지](https://github.com/vercel/next.js/security/advisories/GHSA-cjq9-62q9-8jv4)는 허용 목록에 있는 공격자 제어 URL을 통해 내부 IP 등으로 요청이 향할 수 있는 문제를 설명한다. `images.remotePatterns`를 설정하지 않았다면 이 SSRF의 영향은 없다고 안내한다.

내가 점검한다면 허용한 Host를 누가 제어하고 있는지 보고 싶다. 사용자가 전달한 이미지 주소와 서버가 실제 요청하는 대상을 같은것으로 가정하지 않는 설계가 필요하겠다.

다만 이 조건에 해당하지 않는다고 이번 릴리스 전체와 무관한것은 아니다. 나머지 캐시와 개발 서버 문제도 각각 조건을 확인해야한다.

## 캐시는 화면과 사용자의 경계를 넘어가면 안된다

이번 수정에는 SSG·ISR Cache Poisoning, 중첩된 `use cache`의 Root Param 구분 누락, Draft Mode 내용이 일반 응답에 섞이는 문제 등이 포함됐다.

특히 Draft Mode는 Cache Components 또는 `experimental.useCache`를 켜고 초안에 따라 달라지는 내용을 캐시 함수에서 반환하는 구성이 대상이다. 모든 캐시가 동일한 문제를 갖는것처럼 읽지는 않아야겠다.

업데이트 뒤에는 편집자의 미리보기와 일반 방문자 응답을 나눠 확인하고 싶다. 언어와 조직, Route 값이 달라졌을때 기존 응답이 섞이지 않는지도 애플리케이션에서 계속 검증할 부분이다.

## 개발 서버의 MCP Endpoint도 패치 대상이다

[개발 서버 MCP 정보 유출 공지](https://github.com/vercel/next.js/security/advisories/GHSA-39w2-rjm5-chcv)는 요청이 어느 웹사이트에서 왔는지 확인하지 않던 문제를 다룬다. 개발자가 방문한 악성 사이트가 프로젝트 위치와 오류의 코드 조각, Route 목록과 개발 로그를 읽을 수 있었다.

`next dev`가 대상이고 Production 배포는 이 Endpoint를 제공하지 않는다. 운영 서버만 업데이트하고 개발환경을 예전 버전으로 계속 쓰는 상황도 놓치지 않아야겠다.

개발 서버가 로컬에 있다는 이유만으로 브라우저를 통한 접근 경계까지 안전하다고 가정하면 안되겠다는 사례다. Agent를 위한 개발 정보가 많아지는만큼 누가 읽을 수 있는지도 중요해지는것같다.

# 5. DevOps — Runner의 등록 기준과 실행 기준을 따로 확인한다

9월 28일 [Self-hosted Runner 최소 버전 정책 일정](https://github.blog/changelog/2026-09-28-self-hosted-runner-version-enforcement-date-has-moved/)이 변경됐고 Enterprise Cloud에서는 9월 29일부터 본격 적용됐다.

`2.329.0` 미만은 등록·재등록할 수 없다. 이미 등록한 Runner도 Job 실행에 필요한 최소 버전을 충족하지 못하면 실행이 중단되는데, 이 실행 기준은 등록 기준보다 높은 별도 버전이다.

따라서 2.329.0을 넘겼으니 모든 조건을 충족했다고 생각하면 안되겠다. 버전별 등록·실행 지원 종료일을 조회하는 REST API로 실제 기한을 확인할 수 있다.

이 일정 변경은 GitHub Enterprise Cloud가 대상이다. Enterprise Server에는 해당하지 않고 Data Residency 환경은 7월 31일부터 적용이 시작됐다고 안내한다.

## Job 대기를 애플리케이션 문제로만 보지 말자

Runner가 오래된 버전이라 Job을 받지 못하는데 테스트 명령이나 소스 코드만 수정하면 해결되지 않는다. 내 환경에서는 Runner 버전과 지원 종료일, Label과 가용 수량을 먼저 묶어보고 싶다.

실행 중인 작업을 어떻게 마무리하고 새 Runner로 전환할지도 정해야겠다. 버전 확인을 수동 운영 메모에만 두기보다 정기 점검과 기한 알림에 연결하면 갑작스러운 중단을 줄일 수 있다.

## ARC 0.15.0은 Runner Fleet의 운영을 개선했다

10월 1일 [Actions Runner Controller 0.15.0](https://github.blog/changelog/2026-10-01-actions-runner-controller-release-0-15-0/)이 발표됐다. Patch 버전 업그레이드에서 리소스를 In-place로 갱신하고 Graceful Shutdown, Kubernetes API 요청과 상태 지표, Controller 동시 처리 설정 등을 개선했다.

리소스 갱신 과정의 중단을 줄이는 변화이지 모든 실행 Job이 어떤 업그레이드에서도 무중단이라는 뜻은 아니다. Controller와 Runner 이미지, Scale Set의 상태를 각각 확인해야겠다.

대규모 환경에서는 Controller의 처리량과 Kubernetes API 부하도 CI 대기 시간에 영향을 줄 수 있다. 내 작업량에 맞춰 설정을 조절하고 변경 전후의 대기 시간과 오류를 비교해보고 싶다.

## macos-14는 다음주부터 Brownout이 시작된다

[macOS 14 Hosted Runner 종료 공지](https://github.blog/changelog/2026-10-01-github-actions-macos-14-runner-image-retirement/)는 11월 2일 종료를 안내한다. `macos-14`와 `-large`, `-xlarge`가 대상이고 10월 5일부터 정해진 시간에 Job을 일시 실패시키는 Brownout이 시작된다.

iOS·macOS Build가 있다면 다음주 전에 대체 이미지에서 시험해보고 싶다. 안내된 `macos-15`·`macos-26` 계열을 검토할때는 Xcode와 SDK, 실행 아키텍처, Native 의존성도 같이 봐야겠다. Label 하나만 바꾸는 작업으로 끝날지 실제 Build로 확인하는 편이 좋겠다.

# 6. 데이터베이스 — PostgreSQL 19는 Beta 4를 기준으로 시험하자

PostgreSQL 19는 이번주에도 [Beta 4](https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/)를 기준으로 보면 되겠다. RC는 10월 초를 계획하며 GA 시점도 테스트 결과에 따라 달라질 수 있다. 운영 적용보다 분리된 환경의 호환성 검증이 먼저다.

지난주 빠진 SQL/PGQ와 온라인 Checksum 변경 등을 최종 기능으로 전제하지 않아야한다. `REPACK`과 `WAIT FOR` 관련 수정이 이어지고 있지만 기능이 남아있다는것과 우리 운영 조건에서 안전하게 쓸 수 있다는것도 별도로 확인해야겠다.

## 기능 시연보다 애플리케이션의 동작을 확인하고 싶다

내가 Staging에 비교 환경을 만든다면 주요 조회와 쓰기, 배치와 연결 Pool을 먼저 붙일것같다. 확장과 드라이버가 지원하는지, 같은 데이터에서 실행 계획과 응답 시간이 어떻게 달라지는지 보고 싶다.

Primary에 쓴 내용을 Replica에서 다시 읽어야하는 기능이라면 Primary와 Replica를 어떤 기준으로 선택하는지부터 정리해야한다. 대기 조건을 어디에 둘지와 Timeout 때의 응답도 애플리케이션 계약의 일부다.

Beta 사이의 이전도 단순 패치 교체처럼 생각하지 않아야겠다. 공식 안내는 이전 버전에서 Beta 4로 올릴때 `pg_upgrade`나 Dump·Restore 같은 메이저 이전 전략을 요구한다. 테스트 환경을 다시 만들 수 있는 절차까지 남겨두면 다음 검증에도 도움이 되겠다.

# 이번주는 결과와 그 결과를 만드는 절차를 같이 보자

새 모델은 내 작업의 품질과 비용으로 비교하고, 반복되는 Agent 작업은 단계와 중간 검토를 코드로 표현해보고 싶다. GUI 자동화도 완료 기준과 앱의 접근 범위를 먼저 정하면 좋겠다.

운영에서는 Next.js 패치와 Runner 지원 상태가 먼저다. 이번주에는 Runner 목록과 패치 버전부터 열어보고, 반복 작업 하나를 Workflow로 만드는 실험은 그다음에 해봐도 좋겠다..


[2026.10.02 주간 개발 트렌드] Agent 비용·Dynamic Workflows·Computer Use, Next.js 패치와 Runner 운영

독자의 메모