웹 개발 데일리 브리핑 — 2026-09-25

Soshy·2026년 9월 25일

기준 시점: 2026-09-25 06:00 KST
조사 범위: 2026-09-24 06:00 ~ 2026-09-25 06:00 KST
추천 글 범위: 기준 시점 당시 최근 7일

1️⃣ 프론트엔드

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

2️⃣ 웹 플랫폼·브라우저

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

3️⃣ 백엔드·인프라

PostgreSQL 19 Beta 4 공개 — SQL/PGQ·온라인 checksum 전환 등 예정 기능 대거 철회

발표일: 2026-09-24 — 정확한 게시 시각 미확인
안정화 단계: Beta 4
원문: PostgreSQL — PostgreSQL 19 Beta 4 Released!

PostgreSQL Global Development Group이 PostgreSQL 19의 네 번째 베타 버전을 공개했다. 이번 릴리스는 기능을 더 추가하기보다는 GA를 앞두고 안정성을 확보하기 위해 이미 PostgreSQL 19에 들어가 있던 여러 기능을 다시 빼는 데 초점이 맞춰졌다. 다음 단계는 10월 초로 계획된 Release Candidate이며, 테스트 결과에 따라 PostgreSQL 19 GA 역시 10월에 이뤄질 가능성이 있다.

가장 큰 변화는 SQL/PGQ 기반 property graph query 지원 철회다. 이와 함께 서버를 중단하지 않고 data checksum을 활성화·비활성화하는 기능, temporal table의 일부 기간만 수정하거나 삭제하는 FOR PORTION OF, ALTER TABLE ... MERGE PARTITIONS와 SPLIT PARTITIONS도 PostgreSQL 19 최종 버전 대상에서 빠졌다. pg_get_role_ddl(), pg_get_tablespace_ddl(), pg_get_database_ddl() 함수 역시 제거됐다.

PostgreSQL 프로젝트는 기능 완성도와 예측 가능한 연간 릴리스 일정을 우선하기 위해 이 기능들을 이후 major release로 미루기로 했다고 설명했다.

남아 있는 PostgreSQL 19 신규 기능도 상당한 수정이 이뤄졌다. 새 REPACK 명령에서는 crash, invalid index 및 materialized view 처리, permission과 error reporting 문제가 수정됐고, WAIT FOR에는 deadlock 수정과 isolation-level 오류 보고 개선이 들어갔다.

Logical replication에서는 이전 PostgreSQL 버전으로부터 초기 table synchronization을 수행하는 문제와 conflict detection을 보완했으며, 새 autovacuum scoring system의 TOAST table 처리, COPY FROM SIMD 최적화, concurrent partition detach 과정에서 발생하던 crash도 수정됐다.

이 버전은 여전히 Beta다. PostgreSQL 프로젝트도 API, 동작, 기능 세부사항이 GA 이전에 다시 달라질 수 있다고 명시하고 있다. 이전 PostgreSQL 19 beta에서 Beta 4로 이동할 때도 일반 minor upgrade가 아니라 pg_upgrade 또는 dump/restore처럼 major version upgrade와 비슷한 절차가 필요하다. 따라서 production 적용용 릴리스라기보다 PostgreSQL 19 호환성을 미리 검증하는 테스트 버전으로 보는 것이 맞다.

Google Cloud AlloyDB, agent용 격리 PostgreSQL 인스턴스 Preview 공개

발표일: 2026-09-24 — 정확한 게시 시각 미확인
안정화 단계: Preview
원문: Google Cloud — AlloyDB delivers PostgreSQL for agents

Google Cloud가 AlloyDB에 agent workload 전용 PostgreSQL architecture를 Preview로 추가했다. 여러 AI agent가 동시에 production database를 조회하면서 짧은 시간에 대량 query를 발생시키는 상황에서 primary·standby·read replica와 compute resource를 경쟁하지 않도록 별도의 sandboxed database instance를 동적으로 만드는 구조다.

새 instance는 필요할 때 수 초 내 생성되고, production 데이터에 최대 수 초 이내 수준의 최신성을 가진 read-only 접근을 제공한다. compute는 기존 production database instance와 분리되지만 underlying data는 Google의 분산 storage인 Colossus 기반 unified storage layer를 공유한다.

실행이 끝나면 instance를 scale-to-zero할 수 있어 지속적으로 read replica를 유지하는 대신 burst 단위로 compute 비용을 사용하는 모델이다.

단순 SQL subset을 제공하는 별도 analytics engine이 아니라 AlloyDB의 PostgreSQL engine 자체를 사용한다. 따라서 기존 B-tree index와 SQL뿐 아니라 vector, full-text, spatial search를 그대로 사용할 수 있고 BigQuery·Spark 기반 lakehouse 데이터와 결합하는 경로도 제공한다.

Google은 이를 통해 agent가 operational lookup과 분석성 query를 동일한 PostgreSQL interface에서 수행하면서 production transaction workload와 resource를 분리할 수 있다고 설명한다.

Google은 이 architecture가 sub-millisecond I/O, 초당 terabit 단위 aggregate scan throughput, 300만 QPS 이상을 지원한다고 발표했다. 다만 이 수치는 Google이 자사 storage·database architecture를 기준으로 제시한 제품 성능 수치이며 독립적인 제3자 benchmark가 아니다. 또한 현재 단계는 Preview이므로 production GA 수준의 안정성·지원 범위로 해석해서는 안 된다.

4️⃣ 개발 도구 및 보안

Cloudflare Containers·Sandboxes, 다른 tenant의 잔존 disk 데이터를 읽을 수 있던 취약점 공개

발표일: 2026-09-24 — 정확한 게시 시각 미확인
현재 상태: Cloudflare 전체 fleet에서 수정 완료
고객 조치: 추가 조치 없음
원문: Cloudflare — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers

Cloudflare가 Containers와 이를 기반으로 하는 Sandboxes에서 tenant isolation을 깨고 이전 workload의 잔존 disk data를 읽을 수 있었던 취약점의 기술적 원인과 대응 과정을 공개했다. 문제는 9월 4일 Accomplish의 보안 연구자 Oren Yomtov가 bug bounty를 통해 신고했으며, Cloudflare는 9월 24일 상세 분석을 공개했다.

Cloudflare Containers는 Firecracker VM 안에서 /dev/vdc 형태의 root disk를 제공하고, 실제 storage는 Linux Device Mapper의 thin provisioning인 dm-thin을 사용한다.

문제가 된 storage pool에는 skip_block_zeroing 옵션이 켜져 있었다. 이 설정에서는 이전 container가 반환한 64 KiB physical block을 다른 container에 다시 할당할 때 전체 block을 0으로 지우지 않는다. 새 container가 그 block의 4 KiB만 덮어쓰면 나머지 60 KiB에 이전 tenant의 데이터가 남을 수 있었고, raw device read를 통해 이를 읽을 수 있었다.

공격자가 특정 고객이나 host, workload를 직접 지정할 수 있는 구조는 아니었고 잔존 데이터가 항상 존재하는 것도 아니었다. 하지만 성공하면 filesystem metadata, directory structure, database page, application data 등이 tenant 경계를 넘어 노출될 수 있었다.

연구진은 다른 고객이 현재 사용 중인 disk를 수정하거나 workload availability에 영향을 주는 공격까지는 입증하지 않았다.

Cloudflare는 먼저 전체 fleet에서 skip_block_zeroing을 제거해 새로 할당되는 block을 다시 zero-fill하도록 했다. 그러나 이미 실행 중인 container disk와 cached OCI image snapshot에는 오래된 block mapping이 남아 있을 수 있어, 이후 기존 container disk를 폐기하고 host를 drain·restart한 뒤 image cache도 다시 생성했다.

runtime fix 배포는 9월 7일 완료됐고, pre-mitigation snapshot 정리는 9월 19일 끝났다.

Cloudflare는 보유하고 있는 historical disk-I/O telemetry를 조사한 결과 연구진과 자사 엔지니어의 검증 작업 외에 이 공격 패턴과 일치하는 활동을 발견하지 못했다고 밝혔다. 이는 Cloudflare 자체 telemetry를 바탕으로 한 조사 결과이며, 모든 과거 접근을 절대적으로 배제한다는 의미는 아니다.

현재 취약점은 수정됐고 Cloudflare 고객이 별도 configuration을 변경할 필요는 없다고 안내했다.

GitHub Security Lab, C/C++ fuzzing을 자동 반복하는 Fuzzing Taskflow 공개

발표일: 2026-09-24 — 정확한 게시 시각 미확인
대상: C/C++ 프로젝트
원문: GitHub Security Lab — AI-powered fuzzing with the GitHub Security Lab Taskflow Agent

GitHub Security Lab이 C/C++ 프로젝트의 fuzzing 과정을 agent가 반복 수행하는 Fuzzing Taskflow를 공개했다. repository를 지정하면 build system과 fuzzing 대상 함수를 분석하고, harness를 만들고, AFL++를 실행한 뒤 coverage를 읽어 다시 harness와 input을 개선하고, 발견된 crash를 triage해 취약점 report까지 작성하는 흐름이다.

구조는 shell driver, 단계별 YAML taskflow, 실행 기능을 제공하는 MCP tool의 세 층으로 나뉜다. agent가 어떤 함수를 대상으로 할지, 어떤 harness를 만들지, 어느 coverage gap을 우선할지를 결정하고 실제 compile·AFL 실행·coverage 수집 같은 동작은 tool이 수행한다.

각 harness는 AFL instrumentation용 binary와 source coverage 측정용 binary 두 종류로 빌드하며, pipeline 상태는 SQLite database에 저장한다.

Coverage 개선도 한 번 실행하고 끝나는 구조가 아니다. AFL 실행 시간을 30초에서 시작해 60·120·240·480·960초로 늘리면서 uncovered branch를 분석하고, 새 seed 추가, harness 수정, dictionary enrichment 등을 반복한다.

기본 설정에서는 두 번 연속 absolute line coverage 증가폭이 1% 미만이면 diminishing return에 도달했다고 판단해 해당 loop를 종료한다. JSON, XML, regex, PNG, length-prefixed TLV처럼 구조가 있는 입력을 위한 dictionary와 mutator도 포함된다.

다만 실행 모델에는 중요한 보안 제약이 있다. 현재 Taskflow는 afl-fuzz, clang, 그리고 LLM이 선택한 임의 build command를 container 없이 host에서 직접 실행한다.

GitHub Security Lab도 prompt injection이 발생하면 agent가 실행 사용자와 같은 권한으로 동작할 수 있다고 경고하며, privileged credential이 없는 disposable Codespace나 일회용 VM에서만 실행할 것을 명시했다.

📚 추천 글

Liquid storefronts now start loading 29% faster

저자: Mateusz Krzeszowiak / Shopify Performance
게시일: 2026-09-22
원문: Shopify Performance — Liquid storefronts now start loading 29% faster

Shopify가 Liquid storefront의 server rendering 결과를 전부 기다렸다가 HTML을 보내던 구조에서 벗어나, layout의 {{ content_for_header }}까지 렌더링되면 먼저 browser로 flush하는 streaming 구조를 적용한 과정을 설명한다.

이전에는 <head>가 수 ms 만에 만들어져도 page section 전체의 Liquid rendering이 끝날 때까지 browser가 stylesheet·font·script URL을 알 수 없었다. 이제 browser는 template의 나머지 부분이 server에서 렌더링되는 동안 첫 chunk를 parsing하고 critical resource download를 병렬로 시작할 수 있다.

Shopify 자체 field data에서 median store의 TTFB는 p75 기준 약 29%, p90 기준 약 21% 감소했고 FCP와 LCP도 약 2~6% 개선됐다.

하지만 글은 TTFB 개선이 서버가 실제로 29% 빨라졌다는 뜻이 아니라는 점도 분명히 한다. 전체 rendering work는 그대로이며, 첫 byte를 더 일찍 보내 측정 위치가 달라진 효과가 포함돼 있다. 이 때문에 기존 Navigation Timing만으로 “첫 chunk 이후 server가 얼마 동안 더 일했는가”를 직접 표현하기 어렵다는 observability gap까지 다룬다.

수치는 Shopify 자체 실서비스 측정 결과다.

모든 theme이 같은 효과를 얻는 것도 아니다. JSON template이어야 하고, <head> 안에서 {{ content_for_header }}가 filter나 conditional 없이 직접 사용되는 등 streaming 가능한 구조여야 한다.

Critical stylesheet를 해당 tag보다 뒤에 두면 첫 chunk가 빨리 도착해도 browser가 필요한 resource를 뒤늦게 발견한다. 실제로 Horizon theme이 Dawn보다 FCP·LCP 개선폭이 컸던 이유도 resource 배치 차이에 있었다.

단순 수치 발표가 아니라 server streaming과 browser resource discovery, Web Vitals 측정 사이의 관계와 trade-off를 구체적으로 볼 수 있는 글이다.

Connection allowlists: Secure your web application's network access

저자: Sebastian Benz, José Luis Zapata / Chrome for Developers
게시일: 2026-09-23
원문: Chrome for Developers — Connection allowlists

Chrome 152에 들어간 Connection Allowlists의 설계와 사용법을 자세히 설명한 글이다.

Connection-Allowlist response header에 URLPattern 형태의 허용 목적지를 지정하면 browser가 page나 worker에서 발생하는 network connection을 deny-by-default 방식으로 제한한다. 일반적인 fetch()뿐 아니라 CSP가 완전히 포괄하지 못하는 navigation·WebRTC 등 더 넓은 network surface를 한 경계에서 다루려는 기능이다.

Policy는 window·worker context별로 적용되고 redirect와 WebRTC는 기본적으로 막힌다. 필요한 경우 redirects=allow, webrtc=allow를 명시할 수 있으며, 실제 차단 전에 영향을 확인할 수 있는 Connection-Allowlist-Report-Only와 Reporting API 조합도 제공한다.

Generated code나 third-party script처럼 신뢰도가 낮은 코드는 cross-origin 또는 sandboxed iframe에 넣고 그 context에만 allowlist를 적용하는 방식을 Chrome 팀이 권장한다.

CSP를 대체한다기보다 기존 CSP 위에 network sandbox를 추가하는 progressive enhancement로 보는 것이 적절하다. 특히 plugin, embedded game, AI-generated UI처럼 실행 코드는 허용해야 하지만 데이터를 임의 외부 domain으로 보내는 것은 막아야 하는 환경에서 browser 자체를 마지막 network enforcement layer로 사용하는 접근이라는 점이 흥미롭다.

Stop buttons triggering zoom when they’re double tapped

저자: Andy Bell / Piccalilli
게시일: 2026-09-23
원문: Piccalilli — Stop buttons triggering zoom when they’re double tapped

iOS Safari에서 버튼을 빠르게 연속 탭할 때 의도치 않게 double-tap zoom이 발생하는 문제를 접근성을 훼손하지 않고 해결하는 짧지만 실용적인 글이다.

흔히 viewport meta에 maximum-scale=1.0이나 user-scalable=no를 추가해 zoom 자체를 막는 방법을 떠올릴 수 있지만, 이는 사용자의 pinch zoom까지 제거해 접근성 문제를 만든다.

대신 버튼에 touch-action: manipulation을 적용한다. 이 값은 일반적인 panning과 pinch zoom은 그대로 허용하면서 double-tap zoom 같은 추가 gesture를 비활성화한다.

따라서 사용자가 화면을 확대할 수 있는 기능은 유지하면서 반복적으로 탭하는 control에서 browser가 zoom gesture를 해석하는 문제만 피할 수 있다.

복잡한 JavaScript gesture handler나 viewport 제한 없이 CSS 한 줄로 문제를 해결한다는 점도 좋지만, 더 중요한 부분은 UI 문제를 고치기 위해 browser zoom 자체를 제거하지 않는 것이다.

모바일 interaction과 접근성 요구사항이 충돌하는 작은 사례에서 native browser behavior와 CSS primitive를 어떻게 이용해야 하는지 간결하게 보여준다.