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

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

# 이번주는 운영 중인 버전부터 확인해야겠다

이번주에는 새 기능을 공부하기 전에 확인할 업데이트가 많았다. Next.js와 PgBouncer에는 보안 패치가 나왔고 GitHub Actions에서는 Node 20 실행 환경이 종료됐다. Spring도 패치를 내놓는 주기를 바꾼다고 발표했다.

AI 쪽에서는 새 모델의 성능만큼 가격과 실제 작업 비용이 눈에 띄었다. 9월 21일부터 25일까지의 소식이다. 사용하는 제품에 따라 우선순위가 다르니 내 서비스와 연결되는 부분부터 보면 좋겠다.

# 1. AI — 토큰 단가와 작업 비용을 같이 보자

이번주 OpenAI가 [GPT-6 Sol과 Luna](https://openai.com/index/introducing-gpt-6-sol-and-luna/)를 공개했다. Sol의 입력·출력 단가는 GPT-5.6 Sol의 프로모션 가격 대비 절반으로 내려갔다. 코딩과 Agent 작업의 성능 개선도 발표했지만 업체의 평가 조건과 우리 서비스의 조건은 구분해서 봐야겠다.

9월 22일 나온 [Claude Opus 5.5](https://www.anthropic.com/claude-opus-5-5)도 비용과 속도를 강조한다. Anthropic은 기본 설정의 일반적인 Workload에서 Opus 5보다 비용이 약 40% 낮고 출력은 30% 이상 빠르다고 설명한다.

발표된 일반 입력·출력 가격을 나란히 놓으면 아래와 같다. 단위는 100만 토큰당 달러다.

| 모델 | 입력 | 출력 |
| --- | ---: | ---: |
| GPT-6 Sol | $2 | $10 |
| GPT-6 Luna | $0.10 | $0.50 |
| Claude Opus 5.5 | $4 | $20 |

이 표만으로 어떤 모델이 더 저렴하게 일을 끝내는지 결정할 수는 없다. 캐시와 추론량, 재시도 횟수가 다르면 최종 비용도 달라진다.

Opus 5.5의 입력·출력 단가 인하는 20%이고 캐시 읽기 가격은 60% 낮아졌다. 발표의 약 40%는 작업당 토큰 사용량 등을 함께 반영한 결과다. 모든 요청의 청구액이 똑같이 40% 줄어든다는 뜻은 아니다.

## 지난주 모델 라우팅을 실제 평가로 연결해보자

지난주에는 요청별로 모델을 고르는 흐름을 봤다. 이번주 가격 변화까지 보면 작업마다 선택 기준을 두는 설계가 더 현실적으로 느껴진다.

```text
작업 종류 → 품질·지연 기준 → 모델·추론량 선택 → 결과 검증 → 비용 기록
```

내가 비교한다면 같은 코드 수정 요청을 여러 모델에 주고 테스트 통과 여부와 리뷰에서 고친 양을 같이 기록할것같다. 단가가 낮아도 결과를 다시 만드는 시간이 길면 실제 절감은 작을 수 있다.

처음에는 정해진 형식의 분류나 추출과 여러 파일을 바꾸는 작업 정도로 나눠볼 수 있겠다. 모든 요청에 정교한 난이도 판정을 붙이기보다 검증할 수 있는 작업부터 기준을 만들고 싶다.

모델 선택과 Cache Hit 여부, 재시도를 작업 ID로 연결해두면 비용이 늘어난 이유를 찾는데 도움이 된다. 가격이 내려간 기회를 호출 수를 늘리는데만 쓰기보다 성공한 작업 하나의 비용을 확인하는데 써보고 싶다.

# 2. 프론트엔드 — Next.js 긴급 패치는 정기 릴리스와 따로 챙기자

9월 22일 [Next.js 긴급 보안 업데이트](https://nextjs.org/blog/nextjs-security-update-september-22-2026)가 나왔다. 영향을 받는 버전은 `>=16.2.0 <16.3.6`이다.

문제는 Node.js 환경의 `next/og` `ImageResponse` 구현에 있다. 특정 조건에서 Satori가 만든 SVG의 Escaping 문제와 다른 상위 의존성의 취약점이 결합하면 원격 코드 실행으로 이어질 수 있다. 패치는 관련 의존성을 업데이트한다.

| 사용 환경 | 이번 RCE 공지의 구분 |
| --- | --- |
| 영향 버전의 Node.js ImageResponse | 영향 범위 확인 후 16.3.6으로 업데이트 |
| Edge ImageResponse | 해당 RCE의 영향 없음 |
| Next.js 15.x | 해당 RCE의 영향 없음, 15.5.26에 관련 Hardening 제공 |

16.3 계열이라면 공지의 패치 버전은 다음과 같다.

```bash
npm install next@16.3.6
```

15.5 계열은 15.5.26을 확인하면 된다. 15.x까지 동일한 RCE가 있다고 생각하거나 모든 Next.js 화면이 같은 실행 경로를 사용한다고 넓혀서 해석하지는 않아야겠다.

## 설치한 버전과 배포한 버전을 맞춰보자

내가 점검한다면 OG 이미지 생성 코드를 찾고 실제로 어떤 Runtime에서 실행되는지 보겠다. 프로젝트에 Edge 설정이 하나 있다는것만으로 해당 경로까지 Edge라고 판단하면 안된다.

Lockfile과 Build 결과에 반영된 버전도 확인하고 싶다. 로컬에서 패키지를 올렸더라도 이전 Artifact를 다시 배포하면 운영 버전은 그대로일 수 있다. 이미지 생성 경로를 직접 호출해 정상 결과와 오류 처리를 확인하면 좋겠다.

[9월 30일 정기 보안 릴리스 사전 공지](https://nextjs.org/blog/upcoming-nextjs-security-release-september-2026)도 나왔다. 지금 나온 긴급 패치를 적용하고 정기 릴리스가 공개되면 최종 버전과 영향 범위를 다시 확인하는 순서가 좋겠다. 다음 패치가 예정됐다는 이유로 현재 패치를 미룰 필요는 없다.

# 3. 백엔드 — Spring 패치를 하루의 Release Train으로 묶는다

9월 21일 [Spring의 릴리스 방식 변경](https://spring.io/blog/2026/09/21/releasing-spring-for-modern-challenges/)이 발표됐다. 의존성 계층에 따라 약 2주에 걸쳐 나오던 릴리스를 하루의 Train으로 모은다.

정기 Patch Train은 매달 세 번째 월요일 다음 목요일에 제공하고 다음 정상 패치 일정은 10월 22일이다. 이번달 9월 24일 Train은 Milestone 릴리스만 진행한다고 안내한다. 이번주부터 정기 패치가 모두 새 방식으로 나온것으로 이해하지는 않아야겠다.

Spring 팀은 3월 이후 커뮤니티 보안 보고가 월평균 약 80건 들어왔고 신규 CVE를 160개 이상 수정했다고 설명한다. 이 수치를 특정 서비스가 160개 취약점에 모두 노출됐다는 의미로 읽을 수는 없다.

## 패치를 받는 주기를 팀 일정에도 넣어보자

여러 프로젝트의 패치를 같이 받을 수 있다면 팀에서는 적용과 검증 시점을 잡기 쉬워지겠다. 다만 공개일에 맞춰 무조건 운영에 반영하기보다 사용하는 Boot 계열과 지원 범위, 실제 포함된 의존성을 확인해야한다.

```text
Patch Train 확인 → 의존성 업데이트 → 통합 테스트 → 배포·운영 확인
```

내가 정기 작업으로 만든다면 외부 연동과 인증, 메시지 처리처럼 회귀 영향이 큰 경로부터 확인할것같다. 보안 공지에는 프로젝트와 영향 버전, 필요한 조건을 연결해서 기록하고 싶다.

정기 일정이 생겨도 긴급 공지를 그날까지 기다려도 된다는 뜻은 아니다. 일반 유지보수와 긴급 대응의 판단 기준을 따로 두면 업데이트를 계속 미루는 일을 줄일 수 있겠다.

# 4. DevOps — Action의 Node와 애플리케이션의 Node는 다르다

9월 23일 [GitHub Actions의 Node 20 종료](https://github.blog/changelog/2026-09-23-node-20-is-no-longer-available-in-github-actions/)가 최종 공지됐다. Runner는 JavaScript Action에 Node 24를 사용하고 임시 우회 변수였던 `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION`도 더 이상 사용할 수 없다.

직접 Action을 관리한다면 `action.yml`의 해당 부분을 바꾸고 호환성을 검증한 새 버전을 배포해야한다.

```yaml
runs:
  using: node24
```

외부 Action을 사용한다면 Node 24를 지원하는 버전을 확인하면 된다. 이번 변경은 github.com과 GitHub Data Residency에 적용된다고 안내한다.

## setup-node만 바꿔서는 해결되지 않을 수 있다

Workflow에서 애플리케이션을 Build할 Node를 설치하는 단계와 Runner가 Action 자체를 실행하는 Node는 별도다. 서비스가 Java나 Python이어도 Checkout과 Upload 등에 JavaScript Action을 사용하면 영향을 받을 수 있다.

내가 실패한 CI를 본다면 어느 Step이 애플리케이션 실행 전에 끝났는지부터 확인할것같다. Workflow의 `uses:`와 그 Action의 메타데이터를 보고, 공통 Reusable Workflow나 Composite Action 안의 참조도 같이 살펴보면 좋겠다.

Self-hosted Runner에서는 OS와 아키텍처도 확인해야한다. Node 24는 macOS 13.4 이하와 호환되지 않고 ARM32를 공식 지원하지 않는다. 해당 환경은 이번 공지에서 더 이상 지원되는 Runner 구성으로 보지 않는다.

버전 태그를 올린 뒤에는 실제 참조가 바뀌었는지도 봐야겠다. SHA로 고정해서 사용했다면 태그의 최신 버전이 나왔다는것만으로 내 Workflow가 업데이트되지는 않는다.

# 5. Agent 운영 — Sandbox와 Trace는 각각 설정한다

9월 23일 [Copilot 앱의 로컬 Sandbox](https://github.blog/changelog/2026-09-23-local-sandboxing-in-the-github-copilot-app/)가 Public Preview로 공개됐다. 로컬 저장소·Working Tree 세션에서 파일과 네트워크, Git·GitHub CLI 자격 증명 접근을 프로젝트별로 제한할 수 있다.

기본값은 꺼짐이다. 프로젝트의 새 세션 기본 설정과 현재 세션에서 `/sandbox on`을 실행하는것도 구분된다. 클라우드 Sandbox나 원격 호스트 세션에는 적용되지 않고 Copilot CLI 설정과도 별개다.

요청한 정책을 OS에서 강제할 수 없다면 격리 없이 실행하는 대신 Shell이 오류로 끝난다고 안내한다. 팀의 관리 정책이 있으면 실제 적용 범위는 더 좁을 수 있다.

## 실행 범위와 실행 기록을 같이 보고 싶다

9월 22일 [Copilot 앱의 OpenTelemetry](https://github.blog/changelog/2026-09-22-opentelemetry-in-the-github-copilot-app/) 지원도 발표됐다. 기업 관리 설정에서 모델 요청과 Tool 사용 흐름을 기존 모니터링 도구로 보낼 수 있다. Prompt와 응답 내용은 기본 수집 대상에서 제외된다.

Sandbox는 접근 범위를 제한하고 Trace는 실행 과정을 확인하는데 쓰인다. Trace를 남긴다고 권한이 줄어들지는 않고, 격리했다고 잘못된 작업을 자동으로 구분하는것도 아니다.

내가 팀에 적용한다면 먼저 테스트와 Build에 필요한 폴더·네트워크를 정하고 새 세션에서 실제 정책을 확인할것같다. 실행 기록에는 작업 ID와 Tool 실패, 재시도 흐름을 연결하고 싶다. 내용 수집을 켤때는 코드와 자격 증명이 기록되지 않는지도 별도로 봐야겠다.

# 6. 데이터베이스 — PgBouncer 패치와 PostgreSQL Beta는 우선순위가 다르다

9월 23일 [PgBouncer 1.26.0](https://www.pgbouncer.org/2026/09/pgbouncer-1-26-0)이 공개됐다. 인증 전 Client가 Crash를 유발하는 CVE-2026-19888과 무한 반복을 유발하는 CVE-2026-6668을 수정했다. CVE-2026-6669는 악의적이거나 침해된 PostgreSQL 서버가 로그인 중 과도한 작업을 유발하는 문제다.

두 Client 문제와 서버 측 문제의 조건을 구분해서 봐야겠다. PgBouncer가 Single-threaded로 처리하는 경로가 멈추면 다른 Client까지 영향을 받을 수 있다는 점에서 사용하는 환경은 패치를 우선 확인할 필요가 있다.

## DB 엔진 버전만 확인하면 놓칠 수 있다

애플리케이션 앞의 연결 Pooler가 멈추면 PostgreSQL 자체가 살아있어도 서비스는 DB를 사용하지 못할 수 있다. 실제 요청 경로에 어떤 PgBouncer 인스턴스가 있는지와 관리형 서비스의 패치 적용 범위를 확인하고 싶다.

이번 버전에는 [기존 Online Restart `-R` 기능 제거](https://www.pgbouncer.org/changelog.html)도 포함됐다. 기존 재시작 절차가 이를 사용한다면 패키지 업데이트와 함께 운영 절차도 검토해야겠다.

내가 검증한다면 새 연결의 인증과 Pool 대기, 재연결을 확인하고 싶다. 기존 연결이 유지된다는것만으로 업데이트 뒤의 새 연결까지 정상이라고 판단하기는 어렵다.

## PostgreSQL 19 Beta 4에서는 일부 기능을 되돌렸다

9월 24일 [PostgreSQL 19 Beta 4](https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/)가 나왔다. SQL/PGQ와 실행 중 Checksum 변경, `FOR PORTION OF`, Partition Merge·Split 등이 이번 버전에서 빠졌다. 안정성과 릴리스 일정을 고려해 추가 검토 시간을 두는 결정이다.

앞선 글에서 관심 있게 봤던 기능도 최종 제공을 전제로 설계하면 안되겠다는 사례다. 차기 버전에 반드시 들어간다는 보장도 없으니 필요 기능은 실제 제공되는 버전을 기준으로 확인해야겠다.

이번 Beta에서는 `REPACK`과 `WAIT FOR`, 논리 복제 등의 수정도 이어졌다. 특히 읽기 일관성 관련 명령은 `WAIT FOR`라는 이름으로 확인하면 된다.

다음 RC는 10월 초를 계획하고 GA도 테스트 결과에 따라 10월에 나올 수 있다고 안내한다. 이번주에는 운영 교체보다 분리된 환경에서 애플리케이션 쿼리와 이전 절차를 검증하는 대상으로 보면 좋겠다.

# 이번주는 패치할것과 시험할것을 나눠보자

Next.js와 PgBouncer를 쓴다면 실제 배포 버전과 영향 경로부터 확인하고 싶다. CI는 Action의 Node 24 지원을, Spring은 새 Patch Train을 반영한 검증 일정을 챙기면 되겠다.

새 모델과 PostgreSQL Beta는 비교할 기준을 정한 뒤 시험해보자. 새로운 선택지가 많았지만 이번주는 운영 중인 연결과 실행 환경을 놓치지 않는게 더 중요한것같다..


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

독자의 메모