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

# 이번주는 비용을 줄이는 일과 실행 경로를 지키는 일이 같이 보였다

이번주에는 PHP 보안 업데이트를 먼저 확인해야겠다. 런타임 내부의 RCE 문제라서 애플리케이션의 인증 코드만 보고 안전하다고 판단하기 어렵다. GitHub Package Firewall과 Cloudflare WAF도 설치·실행 경로의 위험을 줄이는 변화다.

개발 도구에서는 tsrs의 Rust 포팅, AI에서는 Cloudflare의 코드 리뷰 비용 최적화가 눈에 띄었다.

10월 19일부터 23일까지의 소식을 분야별로 정리해보자.

# 1. AI — 코드 리뷰 한 번을 끝내는 비용을 봐야한다

10월 19일 [Cloudflare가 AI 코드 리뷰 비용 최적화 사례](https://blog.cloudflare.com/obsessive-inference-optimization/)를 공개했다. 리뷰당 평균 추론 비용을 2.43달러에서 0.77달러로 약 68% 줄였고, 소요시간 중앙값은 4분 9초에서 1분 32초로 줄였다고 한다.

여기서 2.43달러는 최적화 전 비용이 가장 높았던 2주의 평균이다. 처음 서비스를 만들었을때와 비교한 숫자는 아니다. 절감분의 약 40%는 리뷰 시스템 코드 개선, 나머지는 모델과 추론 노력 설정을 바꾸는 실험에서 나왔다.

공통 프롬프트를 캐시할 수 있도록 배치를 고치고 불필요한 모델 호출을 줄이는 작업이 포함됐다. 특히 캐시 적중률이 높아져도 전체 토큰이 더 크게 늘어나면 비용이 증가할 수 있다는 설명이 인상적이었다.

## 캐시 적중률 하나만으로 효율을 판단하기 어렵다

내가 리뷰 자동화를 만든다면 아래 항목을 같이 기록할것같다.

| 항목 | 확인하고 싶은 내용 |
| --- | --- |
| 리뷰당 비용 | 재시도와 하위 Agent까지 합친 비용 |
| 완료 시간 | 평균뿐 아니라 오래 걸리는 요청의 분포 |
| 호출·토큰 수 | 불필요한 탐색과 같은 내용의 반복 전송 |
| 품질 | 실제 문제를 찾았는지, 정상 코드를 오탐하지 않는지 |

작은 Diff라도 인증 로직이라면 가볍게 분석하지는 않을것같다. 같은 PR 묶음으로 비용과 오탐·누락을 함께 비교해야겠다.

## Claude Duet은 능동적으로 일하는 Agent의 Preview다

10월 21일 [Claude Duet](https://claude.com/resources/articles/claude-duet)이 공개됐다. 연결된 앱을 살피고 필요한 일을 알려주며 사용자가 자리를 비워도 작업을 이어가는 Agent 앱이다. 미국 Pro·Max 사용자를 대상으로 대기자 명단을 받는 Research Preview이며 기존 플랜의 사용량 한도를 공유한다.

민감한 행동을 하기 전에 사용자에게 확인하도록 설계됐다는 설명도 있다. 지금 누구나 바로 사용할 수 있는 정식 서비스로 이해하지는 않아야겠다.

이벤트로 일을 시작한다면 중복 처리와 오래된 승인, 취소된 작업도 관리해야겠다.

승인 대기 중 문서가 바뀌었다면 예전 미리보기의 승인으로 새 문서를 보내면 안 될것같다. 승인 대상 버전과 실행 상태를 함께 저장해야겠다.

# 2. 프론트엔드 — tsrs와 WebMCP는 서로 다른 개발 비용을 줄인다

10월 20일 [tsrs](https://blog.cloudflare.com/typescript-rust-port/)가 소개됐다. Cloudflare와 VoidZero가 Owner.com의 Max Schwenk와 함께 작업하는 TypeScript 컴파일러의 Rust 포팅 프로젝트다. TypeScript 팀과 협력하며 Oxc Toolchain 안에서 진행한다.

TypeScript의 언어 설계를 따로 바꾸려는 프로젝트는 아니라고 설명한다. Microsoft가 공식 컴파일러를 Rust로 교체한다고 발표한것과는 구분해야겠다.

초기 벤치마크에서는 타입 검사 Worker 수를 맞췄을때 TypeScript 7.0 대비 최대 8배 빠르고 메모리를 약 70% 적게 사용했다고 한다. 특정 조건의 초기 결과이며, 내 Monorepo에서도 같은 배수가 나오는것을 보장하지는 않는다. 현재 제공하는 릴리스도 실험적이다.

## 빠르게 끝나는것만큼 같은 결과가 나오는지도 중요하다

타입 검사 도구를 바꾼다면 속도 전에 기존 오류를 같은 방식으로 찾는지 확인하고 싶다. 잘못된 코드를 빠르게 통과시키면 CI 시간이 줄어도 도움이 되지 않는다.

내 프로젝트에서는 기존 타입 검사를 유지한 상태로 별도 작업에서 비교해볼것같다. 같은 Commit과 설정으로 오류 위치·메시지, 종료 상태와 메모리를 비교하고 에디터에서의 경험도 확인하면 좋겠다.

Rust와 Wasm으로 작은 메모리 환경이나 브라우저에 개발 도구를 가져가는 가능성도 강조한다. 당장 CI를 교체하기보다 비교 후보로 지켜보고 싶다.

## WebMCP는 화면의 기능을 Tool로 제공하는 사례가 나왔다

10월 21일 [Cloudflare와 Commerce.com의 WebMCP 적용 사례](https://blog.cloudflare.com/webmcp-commerce/)도 공개됐다. 거의 10만 개 Storefront에 적용하기 위한 구조로, 백엔드 MCP 서버의 Tool 정의와 호출을 브라우저로 연결한다.

Agent가 버튼 위치를 추측하는 대신 상품 검색과 장바구니 추가 같은 기능을 호출하는 흐름이다. 소개된 구매 흐름에서는 마지막 Checkout은 사용자가 진행한다. 상점별 제외 설정과 미지원 브라우저·MCP 서버 장애 시 일반 화면을 유지하는 Fallback도 설명한다.

아직 실험적으로 발전하는 표준과 Preview 적용 사례다. 모든 브라우저에서 같은 방식으로 사용할 수 있다고 전제할 단계는 아니다.

내가 도입한다면 UI 버튼을 그대로 Tool 이름으로 옮기기보다 어떤 업무 기능을 공개할지부터 정할것같다. 상품 조회와 장바구니 변경은 권한과 부작용이 다르다. 브라우저가 보내는 가격을 믿지 않고 서버가 다시 계산하는 기존 원칙도 그대로 필요하다.

# 3. 백엔드 — PHP는 런타임 패치, Spring은 실제 사용 경로를 확인하자

10월 21일 PHP가 두 Critical RCE 취약점의 수정 버전을 공개했다. [공식 보안 안내](https://www.php.net/archive/2026.php)는 웹 요청을 처리하는 PHP 환경의 즉시 업데이트를 권고한다.

| 취약점 | 핵심 문제 |
| --- | --- |
| [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) | 메모리 부족으로 요청 처리가 중단될때 불완전한 내부 상태가 정리 과정에서 사용될 수 있음 |
| [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) | 해제된 요청 메모리를 가리키는 상태가 남아 같은 Worker의 후속 요청에서 사용될 수 있음 |

CVSS v4.0 점수는 두 건 모두 9.2다. 다만 PHP-FPM과 mod_php의 실행 흐름이 같지는 않다. 첫 번째 문제는 mod_php에서 애플리케이션 코드 실행 전 공격이 확인됐으며, FPM에는 조건과 영향을 별도로 설명한다. 같은 PHP라는 이유로 모든 환경의 공격 성립 조건이 같다고 적으면 부정확하겠다.

## 애플리케이션 인증보다 앞에서 문제가 생길 수 있다

Controller에서 JWT를 검사하고 있다는 사실만으로 이번 런타임 문제를 막았다고 판단할 수는 없다. 요청 데이터를 처리하는 과정 자체에서 메모리 상태가 손상될 수 있기 때문이다.

공식 수정 버전은 다음과 같다.

| PHP 계열 | 두 취약점의 수정 버전 |
| --- | --- |
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |

8.1 이하는 PHP 프로젝트의 정규 지원이 끝났다. 배포판이나 LTS 공급자가 백포트한 패키지는 해당 보안 공지를 확인해야한다. 이번에 제공한 일부 구버전용 최소 소스 백포트를 장기 지원의 재개로 받아들이면 안 되겠다.

내가 운영 환경을 확인한다면 터미널의 `php -v`만 보고 끝내지는 않을것같다. 웹 서버가 사용하는 PHP-FPM Pool과 컨테이너 이미지가 별도일 수 있으므로 실제 요청을 처리하는 프로세스까지 확인하고 싶다. 패키지를 설치한 뒤 기존 Worker가 계속 남아있는지도 점검해야겠다.

## 금요일에 나온 추가 설정 안내도 같이 보자

23일에는 PHP가 Session Upload Progress에 대한 추가 안내를 냈다. `session.upload_progress.enabled=0` 설정을 다음 정기 버그 수정 릴리스까지 권고한다. 런타임에 Session Serialize Handler를 특정 방식으로 바꾸는 특수한 조합에서 남는 위험이며 CVE-2026-115560의 상세 권고는 다음 릴리스에 공개할 예정이다.

앞의 두 CVE 패치를 하지 않아도 된다는 의미는 아니다. 패치와 추가 설정 안내를 함께 확인하고, 업로드 진행률 기능을 사용 중이라면 설정 변경의 영향도 살펴봐야겠다. WAF나 임시 설정만으로 런타임 업데이트를 대신하지는 않아야한다.

## Spring Boot는 종료 처리와 인증 설정의 회귀 테스트를 챙기자

이번주에는 [Spring Boot 4.1.2](https://spring.io/blog/2026/10/23/spring-boot-4-1-2-available-now/)와 [4.0.9](https://spring.io/blog/2026/10/23/spring-boot-4-0-9-available-now/)도 나왔다. 공식 블로그는 23일 공개됐으며, 각각 버그 수정·문서·의존성 업데이트를 포함한다.

[4.1.2 릴리스 노트](https://github.com/spring-projects/spring-boot/releases/tag/v4.1.2)에서는 빈 `issuer-uri`와 설정된 `jwk-set-uri` 조합의 JWT 거부 문제, Tomcat·Jetty의 종료 콜백과 Netty 종료 정지 문제 등이 보인다. gRPC의 특정 Load Balancing 설정에서 발생하는 예외와 사용자 설정을 덮어쓰는 문제도 수정했다.

패치 뒤에는 인증의 정상·거부 경로와 배포 중 진행 중인 요청이 안전하게 끝나는지 확인하고 싶다. 종료 시간도 배포 환경의 제한과 맞춰보면 좋겠다.

# 4. Cloud·DevOps — 설치할때 막고 응답을 보낼때도 확인한다

10월 20일 [GitHub Package Firewall](https://github.blog/changelog/2026-10-20-github-package-firewall-in-public-preview/)이 Public Preview로 공개됐다. CI나 Coding Agent의 패키지 요청을 Registry로 바로 보내는 대신 중간에서 정책을 검사한다. 메타데이터 조회와 실제 다운로드가 모두 대상이다.

```text
CI Runner / Coding Agent
          ↓
    Package Firewall
          ↓
       npm Registry
```

새로 게시된 패키지의 대기 기간, Advisory Database의 악성·취약 패키지 정보, Attestation Downgrade 같은 공급망 검사를 제공한다. 잘못 차단된 패키지는 예외를 요청하는 흐름도 있다.

현재 npm만 지원하며 Enterprise Cloud와 Data Residency 고객 대상이다. Preview는 무료이고 GA 이후에는 사용량 기반 과금을 예정하고 있다. 기본으로 모든 설치 경로를 지켜주는것은 아니고, Endpoint가 Firewall을 통해 요청하도록 설정해야한다.

## Lockfile과 설치 정책은 서로 다른 문제를 다룬다

지난주에는 Actions Workflow Lockfile을 봤다. 어떤 Action Commit을 실행할지 고정하는 기능이었다. 이번 Package Firewall은 다운로드할 패키지를 정책상 허용할지 판단한다.

앱의 패키지 Lockfile은 설치할 의존성을 기록하고, Firewall은 현재 위험 정보와 정책을 적용한다.

Lockfile이나 게시 후 대기 기간이 패키지의 안전성을 보장하지는 않는다. 여러 단계에서 다른 위험을 줄이는 구조로 보면 좋겠다.

내가 도입한다면 우선 CI와 Agent가 실제 사용하는 Registry 경로부터 확인할것같다. 정책을 추가해놓고 별도 Script가 다른 주소로 설치하면 기대한 보호 범위와 달라질 수 있다. 급한 보안 패치를 대기 기간 때문에 못 받는 상황의 예외 승인도 함께 정해두고 싶다.

## Cloudflare WAF는 요청과 응답을 연결해서 본다

21일 [Full Transaction Detection과 Response Rules](https://blog.cloudflare.com/full-transaction-waf/)도 정식 공개됐다. 수상한 요청과 Origin의 응답을 연결해 공격이 실제 영향을 냈는지 판단하고, 규칙에 따라 응답 전달을 막는 기능이다.

예를 들어 같은 파일 조회 요청이라도 서버가 거부한 경우와 민감한 내용을 반환한 경우의 의미는 다르다. 요청의 모양에 응답의 결과를 더해 판단 근거를 넓히는 방향이다.

Free를 포함한 모든 플랜에 Managed·Custom Response Rules를 제공한다. Custom Rule은 최대 3개이며 Log·Block을 지원한다. 다만 탐지 결과 필드를 Custom Rule에 활용하는 권한은 유료 고객 대상이고, 응답 Body를 직접 조건으로 쓰는 Custom Rule은 아직 지원하지 않는다.

여기서 주의할 점은 응답을 막았다고 Origin의 작업까지 되돌아가지는 않는다는것이다. 이미 변경된 DB 데이터나 실행된 코드는 응답 차단만으로 복구되지 않는다.

# 5. 데이터베이스 — PostgreSQL 14의 남은 지원 기간을 먼저 보자

이번주 PostgreSQL은 새 정식 버전보다 기존 일정 확인이 중요하다. 지난주 공개된 [19 RC1 공지](https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/) 기준으로 RC2는 11월 12일, GA는 11월 19일 예정이다. 문제 발견 여부에 따라 일정은 달라질 수 있다.

[PostgreSQL 14 지원 종료](https://www.postgresql.org/support/versioning/)는 11월 12일이다. 이번 금요일 기준으로 약 3주가 남았다. 19 정식 출시를 기다렸다가 14에서 옮기는 일정이라면 지원 종료일을 지나게 된다.

복원한 환경에서 확장과 Driver, 주요 쿼리와 배치를 확인하고 전환 소요시간도 재보면 좋겠다. 19 RC 테스트와 현재 운영 서비스의 지원 종료 대응은 일정을 구분해야겠다.

# 이번주는 실제로 실행되는 경로부터 확인하자

AI 리뷰는 모델 가격과 함께 한 작업의 호출·토큰·품질을 보고, tsrs는 속도와 호환성을 같이 비교하고 싶다. PHP는 실제 웹 요청을 처리하는 런타임에 패치가 적용됐는지부터 확인해야겠다.

패키지 설치 경로와 WAF의 응답 처리, DB 지원 일정도 같이 챙기자. 서비스가 무엇을 실행하고 어디에서 막을 수 있는지 알아야할 한 주였다..


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

독자의 메모