[2026.10.23 주간 개발 트렌드] PHP 긴급 패치와 tsrs, AI 리뷰 비용·패키지 공급망

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

# 이번주는 새 실행 모델과 보안 업데이트를 같이 챙기자

이번주에는 AWS Lambda Web Functions가 가장 새로운 선택지로 보였다. 일반 HTTP 서버를 그대로 가져가는 실행 모델과 활성 CPU 과금이 눈에 띈다. GitHub는 AI 보안 분석과 수정 기능을 정식 제공하고 Workflow 의존성을 고정하는 Lockfile도 공개했다.

한편 운영 중인 Next.js와 PgBouncer에서는 패치 확인이 먼저다. PostgreSQL 19는 RC1이 나왔지만 정식 출시 예정일이 뒤로 바뀌었다.

# 1. AI·보안 — 취약점 분석과 수정의 대상이 구체화됐다

10월 15일 [AI Scan for Pull Requests](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/)가 GA가 됐다. PHP와 Shell/Bash, Terraform HCL, Dockerfile 등 CodeQL이 현재 다루지 않는 영역의 PR 변경을 AI로 분석해 보완한다.

Code Scanning과 유효한 AI Scan 설정이 켜진 저장소에서 자동 실행되며 결과는 AI 표시로 구분된다. 다만 권고 결과이므로 Code Scanning Check를 실패시키거나 Ruleset으로 병합을 막지는 않는다. Fork와 Dependabot이 만든 PR에는 실행되지 않는다.

Public 저장소에서 사용할 수 있고 조직의 Private·Internal 저장소에는 Code Security 또는 Advanced Security가 필요하다. Copilot 라이선스는 필수가 아니지만 Code Security AI Credit을 사용한다.

## Agentic Autofix는 기본 브랜치의 경고를 수정한다

같은 날 [Code Scanning Agentic Autofix](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/)도 GA가 됐다. 기본 브랜치의 경고를 Copilot에 할당하면 관련 파일을 탐색하고 수정한 뒤 CodeQL을 재실행해 Draft PR을 만든다. 최대 25개 경고를 한 PR에서 처리할 수 있다.

PR이나 다른 브랜치에서만 발견된 경고는 할당 대상이 아니다. 앞의 AI Scan과 같은 입력을 받아 모든 결과를 바로 수정하는 하나의 기능으로 이해하지는 않아야겠다.

Enterprise Cloud의 관련 보안 제품과 관리자 정책, Copilot 과금 수단 설정이 필요하며 AI Credit과 Actions 실행 시간을 사용한다. 도입할때 분석과 수정의 비용을 따로 확인하면 좋겠다.

## 경고가 닫혔는지와 서비스가 정상인지는 따로 보자

CodeQL을 다시 실행해 경고가 사라졌다는것은 중요한 검증이다. 그래도 기존 업무의 정상 경로까지 유지됐는지는 애플리케이션 테스트와 리뷰에서 확인해야한다.

내가 수정을 맡긴다면 같은 종류의 경고와 비슷한 코드 영역부터 묶을것같다. 서로 다른 인증·결제·파일 처리 변경이 한 PR에 들어가면 숫자는 줄어도 검토가 어려워질 수 있다.

입력 검증을 강화하면서 정상 요청까지 막거나 권한 검사를 옮기면서 특정 경로를 빠뜨리지 않았는지 보고 싶다. AI가 작성한 설명과 실제 Diff, 실행한 테스트를 함께 확인하는 흐름이 필요하겠다.

10월 13일에는 [Gemini 4 Argon의 Copilot 제공](https://github.blog/changelog/2026-10-13-gemini-4-argon-in-github-copilot/)도 발표됐다. 복잡한 코딩과 Agent 작업을 강조하며 GitHub 초기 평가에서 이전 Gemini보다 개선됐다고 설명한다. 순차 적용과 플랜·조직 정책을 확인하고, 내 저장소의 같은 작업으로 성공률과 비용을 비교해보면 좋겠다.

# 2. 프론트엔드 — React 호환성과 Next.js 보안 패치를 함께 확인한다

10월 14일 [React 19.3.1](https://github.com/react/react/releases/tag/v19.3.1)이 공개됐다. 릴리스 노트는 React Server Components의 전송 프로토콜 개선을 안내한다. 새 API를 대거 익혀야하는 변화보다는 사용하는 프레임워크와의 호환성을 확인할 업데이트다.

## 지난주 예고된 Next.js 보안 업데이트도 나왔다

같은 날 [Next.js 16.4.1·15.5.28 보안 릴리스](https://nextjs.org/blog/nextjs-security-update-october-14-2026)가 나왔다. 기반 의존성의 Critical 2건과 High 1건을 다룬다. 지난주에 16.4 기능을 검토했더라도 이번 패치는 별도로 챙겨야겠다.

| 문제 | 공식 공지의 주요 조건 |
| --- | --- |
| `use cache` 관련 RCE | App Router·Cache Components에서 Typed Array 반환 처리와 관련 |
| 이미지 최적화 관련 RCE | glibc 기반 Linux에서 사용하는 기반 라이브러리 문제 |
| Server Actions DoS | Server Action이 있는 App Router에서 CPU 사용이 과도해질 수 있음 |

첫 번째 문제는 비슷한 함수를 쓰지 않더라도 즉시 업그레이드하도록 권고한다. 코드 검색 한 번으로 무관하다고 판단하지 않아야겠다. 세 번째는 Pages Router나 Server Actions를 사용하지 않는 앱에는 해당하지 않는다고 안내한다.

16.4 계열과 15.5 계열은 각각 아래 패치 버전을 확인하면 된다.

```bash
npm install next@16.4.1
# 15.5 계열은 next@15.5.28
```

내가 반영한다면 설치 버전뿐 아니라 새로 Build해서 배포한 Artifact까지 확인할것같다. 캐시 화면과 이미지 생성·최적화, Server Actions의 정상 요청을 같이 검증하고 싶다.

# 3. 백엔드 — Node.js LTS의 내장 API가 넓어졌다

10월 14일 [Node.js 24.22.0 LTS](https://nodejs.org/en/blog/release/v24.22.0)가 공개됐다. 인증서와 암호 처리, 성능 측정과 자원 정리 기능이 함께 추가됐다.

| 영역 | 주요 변화 |
| --- | --- |
| `crypto` | `parsePKCS12()`, Generic MAC API, SIV·GCM-SIV 지원 |
| `perf_hooks` | `SlidingWindowHistogram` 등 Histogram 확장 |
| `util` | `throttle`, `debounce` 추가 |
| SQLite | `StatementSync.close()`와 명시적 정리 지원 |

내장 API가 생겼다고 같은 이름의 외부 라이브러리를 바로 바꿀 필요는 없다. 인자와 반환값, 취소·오류 처리 같은 계약이 맞는지 먼저 비교해야겠다.

특히 인증서 컨테이너를 파싱할 수 있다는것과 그 인증서를 신뢰해도 된다는 판단은 별도다. 암호 기능도 알고리즘 지원 여부 외에 Key와 Nonce, 데이터 형식의 호환성을 확인해야한다.

Spring은 [10월 22일 새 Patch Train](https://spring.io/blog/2026/09/21/releasing-spring-for-modern-challenges/)을 앞두고 있다. 이번주에는 사용 중인 의존성과 통합 테스트 경로를 정리해두고, 공개되면 실제 영향 버전과 수정 내용을 확인하면 좋겠다.

# 4. Cloud — Lambda Web Functions는 일반 HTTP 서버를 받는다

10월 12일 [AWS Lambda Web Functions](https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/)가 출시됐다. Express·Fastify·Hono·Next.js 같은 HTTP 서버를 이벤트 핸들러로 재작성하지 않고 실행하는 모델이다. 지정된 Host와 Port에서 요청을 받도록 앱의 Listen 설정을 맞춘다.

| 항목 | 출시 시점 안내 |
| --- | --- |
| Runtime | Node.js 24, Arm64 |
| 동시 처리 | 실행환경 하나당 최대 128개 요청 |
| 과금 | 활성 CPU 시간과 실행환경 메모리 사용 |
| 배포 | 변경 불가능한 Revision과 Endpoint로 관리 |
| 여러 리전 | 코드 배포와 Best-effort 지연시간 기반 라우팅 지원 |

출시 리전은 버지니아 북부·오하이오·오리건·도쿄·아일랜드다. 서울은 포함되지 않는다. 일반 Lambda의 기존 이벤트 처리 모델을 모든 용도에서 대체한다기보다 HTTP 서비스의 선택지가 추가된것으로 보면 되겠다.

## I/O 대기 시간이 길다면 비용 구성을 다시 볼만하다

Web Functions는 코드가 사용하는 CPU 시간을 측정한다. DB나 외부 API를 기다리는 동안 CPU를 적게 쓰는 서비스에서는 관심을 가질만하다. 다만 메모리는 실행환경이 존재하는 동안 과금된다.

따라서 대기 시간이 길어졌다고 전체 실행 비용이 사라지는것은 아니다. 내 서비스에서는 CPU와 메모리, 외부 통신과 DB 연결 비용을 함께 비교하고 싶다. 요청당 평균 시간만으로 계산하기보다 실제 트래픽의 몰림과 유휴 구간을 재현하면 좋겠다.

## 동시 요청과 DB 연결 수는 같이 설계해야겠다

여러 요청이 같은 실행환경을 공유하면 요청별 정보를 전역 변수에 남기는 코드도 확인할 필요가 있다. 사용자 정보와 인증 상태가 요청을 넘어 섞이지 않는지가 중요하다.

최대 128개 요청을 받는다고 DB 연결도 그만큼 만들면 되는것은 아니다. 실행환경이 여러 개로 늘어났을때의 전체 Pool 크기와 DB 수용량을 같이 보고 싶다.

여러 리전에 코드를 배포하는 일과 업무 데이터의 위치도 별개다. 서울 DB를 유지한 채 Compute를 도쿄로 옮긴다면 DB 왕복 지연이 달라질 수 있다. 앱까지 빠르게 도착하는것과 전체 요청이 빠르게 끝나는것을 나눠서 봐야겠다.

기존 Node 백엔드를 가져갈 수 있다는 점은 반갑다. 다만 Native 의존성의 Arm64 지원과 연결·Streaming 동작, Revision 전환 뒤의 오류를 작은 서비스에서 먼저 확인해보고 싶다.

# 5. DevOps — Workflow 의존성도 Lockfile로 고정한다

10월 14일 [GitHub Actions Workflow Lockfile](https://github.blog/changelog/2026-10-14-github-actions-workflow-lockfiles-in-public-preview/)이 Public Preview로 공개됐다. Workflow의 태그·브랜치 참조를 유지하면서 실제 실행은 기록한 Commit으로 고정한다. Action의 전이 의존성과 Reusable Workflow도 대상이다.

```text
.github/workflows/
  ├─ deploy.yml
  └─ actions.lock
```

`gh actions-lock` 확장으로 생성·관리하며 Workflow별로 도입할 수 있다. 도입된 Workflow는 의존성의 Lockfile 항목이 필요하고 Actions가 기록된 Commit을 사용한다. 파일 하나를 두기만 하면 모든 Workflow가 자동 적용되는 방식으로 생각하지는 않아야겠다.

Enterprise Cloud와 Data Residency, Team·Free 플랜에서 Preview를 제공한다. 관리자가 Lockfile을 요구하는 정책도 제공하며, 이미 도입한 Workflow의 Dependabot 버전 업데이트는 대응하는 Lockfile 항목도 함께 갱신한다.

## 고정할 Commit을 검토하는 일은 남는다

태그가 이동해도 같은 코드를 실행할 수 있다는것과 그 코드가 안전하다는것은 다르다. 악성 코드를 고정하면 악성 코드가 재현 가능하게 실행될 뿐이다.

내가 도입한다면 배포와 클라우드 인증 권한을 사용하는 Workflow부터 확인하고 싶다. 참조 이름이 그대로여도 Lockfile에서 Commit이 바뀌면 실제 실행 코드의 변경으로 리뷰해야겠다.

# 6. 데이터베이스 — PgBouncer 패치와 PostgreSQL 출시 연기를 구분하자

10월 14일 [PgBouncer 1.26.1](https://www.pgbouncer.org/2026/10/pgbouncer-1-26-1)이 공개됐다. 세 CVE를 수정하며 이번주 운영 DB 연결 경로에서 우선 확인할 업데이트다.

| CVE | 주요 조건과 영향 |
| --- | --- |
| CVE-2026-107350 | SCRAM 사용자 비밀번호를 아는 공격자가 다른 SCRAM 사용자로 인증할 수 있음 |
| CVE-2026-107349 | 특정 `ignore_startup_parameters` 설정에서 인증 전 Client가 무한 반복을 유발 |
| CVE-2026-107348 | `max_packet_size`를 기본값보다 크게 설정한 경우의 무한 반복 문제 |

첫 번째는 아무 자격 증명 없이 누구나 모든 계정에 접근한다는 의미는 아니다. [상세 Changelog](https://www.pgbouncer.org/changelog.html)는 공격자가 `auth_file`에 등록된 사용자의 비밀번호를 알고 있고 양쪽 사용자가 SCRAM 인증을 사용하는 조건을 설명한다. 대상에는 관리자와 백엔드 Superuser도 포함될 수 있다.

두 번째는 설정이 비어있지 않으면서 `options`를 포함하지 않는 경우다. 세 번째는 기본 `max_packet_size`에는 해당하지 않는다. 각각의 조건을 확인하되 한 문제와 무관하다고 전체 릴리스까지 건너뛰지는 않아야겠다.

PostgreSQL 서버가 살아있어도 Pooler의 인증이나 요청 처리가 무너지면 서비스 전체가 영향을 받는다. 엔진 버전만 보지 말고 실제 접속 경로와 PgBouncer 설정, 패치 뒤의 신규 연결을 확인하고 싶다.

## PostgreSQL 19는 RC1이 나왔고 GA는 뒤로 바뀌었다

10월 15일 [PostgreSQL 19 RC1](https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/)이 공개됐다. `REPACK`, 병렬 Autovacuum과 Planner, 논리 복제 등의 수정이 포함됐다. 지난주 적었던 10월 29일 GA 계획은 이번 공지에서 변경됐다.

| 단계 | 이번주 기준 상태·예정일 |
| --- | --- |
| PostgreSQL 19 RC1 | 10월 15일 공개 |
| PostgreSQL 19 RC2 | 11월 12일 예정 |
| PostgreSQL 19 GA | 11월 19일 예정 |
| PostgreSQL 14 지원 종료 | 11월 12일 |

지원 버전의 11월 12일 업데이트에 들어갈 많은 수정을 19에도 반영하기 위한 결정이다. RC 기간에 문제가 발견되면 최종 일정은 다시 달라질 수 있다.

중요한 점은 19 GA 예정일이 [14 지원 종료일](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/)보다 늦다는것이다. 14 운영 서비스가 19 정식 출시만 기다리는 계획이라면 지원 공백이 생길 수 있다. 현재 지원되는 목표 버전과 확장·드라이버 호환성, 복구 절차를 기준으로 일정을 다시 확인해야겠다.

19 RC는 분리된 환경에서 실제 쿼리와 배치, 이전 절차를 시험할 대상으로 보면 좋겠다. 정식에 가깝다는 설명과 지금 운영에 적용해도 된다는 판단은 별도로 봐야한다.

# 이번주는 자동화의 범위와 운영 버전을 먼저 확인하자

AI 보안 분석은 어떤 PR에 실행되는지, 자동 수정은 어떤 경고를 처리하는지부터 확인하면 좋겠다. Lambda Web Functions는 작은 HTTP 서비스의 지연과 비용을 함께 비교해보고 싶다.

운영에서는 Next.js와 PgBouncer 패치, PostgreSQL 이전 일정이 먼저다. CI의 Lockfile까지 연결하면 코드뿐 아니라 어떤 도구로 검증하고 배포했는지도 더 분명하게 관리할 수 있을것같다..


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

독자의 메모