웹 개발 데일리 브리핑 — 2026-09-24
Soshy·
기준 시점: 2026-09-24 06:00 KST
조사 범위: 2026-09-23 06:00 ~ 2026-09-24 06:00 KST
추천 글 범위: 기준 시점 당시 최근 7일
1️⃣ 프론트엔드
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
2️⃣ 웹 플랫폼·브라우저
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
3️⃣ 백엔드·인프라
Vercel Blob, 모든 플랜에서 store 개수 제한 제거
- 발표일: 2026-09-23 — 정확한 게시 시각 미확인
- 적용 대상: Vercel Blob을 사용하는 Hobby·Pro·Enterprise 프로젝트
- 원문: Vercel — Unlimited Vercel Blob stores on every plan
Vercel이 Blob storage에서 생성할 수 있는 store 개수 제한을 모든 플랜에서 제거했다. 기존에는 Hobby에서 최대 100개, Pro에서 500개, Enterprise에서 1,000개의 Blob store만 만들 수 있었지만 이제 필요에 따라 제한 없이 store를 생성할 수 있다.
이번 변경에서 중요한 부분은 단순한 quota 확대보다 store를 storage namespace의 강한 격리 단위로 활용할 수 있게 됐다는 점이다. 하나의 store 안에서 pathname 규칙으로 데이터를 나누는 대신 production·staging·preview 환경마다 별도의 store와 credential을 만들거나, multi-tenant 서비스에서 고객별 store를 생성하는 구조를 사용할 수 있다.
예를 들어 고객별로 store를 분리하면 특정 tenant의 데이터를 export하거나 삭제할 때 하나의 storage 영역만 대상으로 작업할 수 있다. Git branch나 migration 작업을 위해 임시 store를 만들었다가 작업이 끝난 후 제거하는 방식도 가능하다. preview 환경이 production data와 같은 storage credential을 공유하지 않도록 구성하기도 쉬워진다.
다만 store 생성 자체는 무료 operation으로 바뀐 것이 아니다. 새 store 생성은 put(), copy(), list() 등과 함께 Blob Advanced Operation으로 집계된다. Pro에서는 100만 회당 5달러이며, Hobby에서는 매달 제공되는 2,000회의 무료 operation에 포함된다. store 삭제에는 비용이 부과되지 않는다.
기존 storage·operation·data transfer 사용량 과금 구조는 그대로다. 따라서 동일한 양의 데이터를 여러 store로 분리했다고 해서 저장 비용 자체가 증가하는 것은 아니지만, store 생성 operation은 별도로 계산된다.
4️⃣ 개발 도구 및 보안
Drupal Webform 등 contributed module 대규모 보안 릴리스 — Critical RCE 포함
- 발표일: 2026-09-23 — 정확한 게시 시각 미확인
- 주요 위험도: Critical
- 원문: Drupal — Security advisories for contributed projects
- Webform Critical RCE: SA-CONTRIB-2026-175
Drupal Security Team이 9월 23일 다수의 contributed module에 대한 보안 advisory를 한꺼번에 공개했다. 특히 널리 사용되는 Webform에는 여러 취약점이 동시에 공개됐으며, 그중 가장 높은 위험도를 가진 SA-CONTRIB-2026-175는 Critical 18/25 등급의 Remote Code Execution 취약점이다.
Webform의 Critical 취약점 CVE-2026-96355는 일부 format template에서 token replacement를 충분히 제한하지 않는 데서 발생한다. 공격자가 Webform에 제출한 값이 이후 submission을 렌더링하는 과정에서 template code로 평가될 수 있으며, 사이트 구성과 활성화된 module에 따라 정보 유출, stored XSS 또는 원격 코드 실행으로 이어질 수 있다.
모든 Webform 설치가 동일한 조건으로 즉시 RCE에 노출되는 것은 아니다. 취약한 Webform이 submission-value token을 포함하는 custom multiple-value item format을 사용하도록 구성돼 있어야 하며 일부 영향은 다른 module이나 사이트별 설정에도 의존한다.
영향 버전은 Webform 6.2.12 미만과 6.3.0 이상 6.3.1 미만이다. 6.2 계열 사용자는 6.2.12, 6.3 계열 사용자는 6.3.1로 업데이트해야 한다.
Webform에 대해서만 이번에 RCE 외에도 XSS, access bypass, SSRF, DoS, JSON:API cache와 사용자별 접근 제어 문제 등 다수의 별도 advisory가 함께 공개됐다. 예를 들어 Submission Export/Import의 remote URL 경로에서는 권한 검증 부족으로 SSRF가 가능했고, JSON:API를 사용하는 특정 구성에서는 사용자에 맞게 cache가 충분히 vary되지 않아 다른 사용자의 submission response가 반환될 수 있는 문제도 포함됐다.
Webform 외의 contributed module에서도 Critical 문제가 공개됐다. Cloud module의 CVE-2026-96376은 Kubernetes integration이 사용자가 제어할 수 있는 Git branch 및 repository URL을 shell command로 전달하기 전에 충분히 sanitize하지 않아 운영체제 명령을 실행할 수 있는 RCE다.
- 영향 버전: Cloud
<7.0.1 - 수정 버전: Cloud
7.0.1 - 원문: Drupal — Cloud Critical RCE SA-CONTRIB-2026-177
Cloud 취약점은 Kubernetes submodule이 활성화·설정돼 있고 서버에 Git이 설치돼 있어야 하며, 공격자에게 cloud server template을 추가하거나 수정할 권한이 있어야 하는 등 exploitation 조건이 존재한다. 같은 Cloud module에는 remote API의 TLS certificate 검증 문제로 credential이 노출될 수 있는 별도의 Critical advisory도 함께 공개됐다.
Project Browser에서도 administrative action에 대한 CSRF 검증 부족이 Critical 15/25로 평가됐다. 영향 버전은 <2.0.3 또는 2.1.0 이상 2.1.5 미만이며 수정 버전은 각각 2.0.3과 2.1.5다.
Drupal용 tawk.to live chat module 역시 특정 request를 충분히 검증하지 않아 인증된 사용자가 공격자가 의도한 action을 수행하도록 유도할 수 있는 Critical CSRF 취약점 CVE-2026-96388이 공개됐다. 3.0.4 미만이 영향을 받으며 3.0.4로 업데이트한 뒤 Drupal cache를 비워야 한다.
이번 공개는 Drupal Core의 단일 보안 패치가 아니라 여러 contributed project에 걸친 보안 릴리스다. 따라서 Drupal을 사용하는 서비스에서는 core 버전만 확인하는 것으로 끝나지 않고 실제 설치된 contributed module과 각 advisory의 영향 버전을 대조해야 한다.
GitHub Actions, Node.js 20 완전 제거 — JavaScript Action 실행 환경을 Node.js 24로 전환
- 발표일: 2026-09-23 — 정확한 게시 시각 미확인
- 상태: Node.js 20 지원 종료 완료
- 원문: GitHub — Node 20 is no longer available in GitHub Actions
GitHub가 GitHub Actions runner에서 Node.js 20 지원을 최종적으로 제거했다. JavaScript로 작성된 Action은 이제 Node.js 24 환경에서 실행되며, 전환 기간 동안 제공됐던 ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION opt-out 역시 더 이상 사용할 수 없다.
JavaScript Action을 직접 개발하는 maintainer는 action.yml 또는 action.yaml의 runs.using 값을 node24로 변경하고 새로운 release를 배포해야 한다. workflow에서 다른 사람이 만든 JavaScript Action을 사용하는 경우에는 해당 Action의 Node.js 24 지원 버전으로 업데이트해야 한다.
GitHub가 관리하는 first-party Action의 최신 버전들은 이미 Node.js 24로 전환됐다. 따라서 일반적인 workflow에서 최신 major version을 사용하고 있다면 직접 runtime을 수정할 필요가 없는 경우도 있지만, 오래된 Action version을 고정해 사용하거나 자체 Action을 운영하는 환경은 영향을 받을 수 있다.
self-hosted runner에는 운영체제와 architecture 제한도 생긴다. GitHub에 따르면 Node.js 24는 macOS 13.4 이하와 호환되지 않으며 ARM32를 공식 지원하지 않는다. 해당 운영체제 또는 architecture에서 self-hosted runner를 실행하고 있었다면 이번 전환 이후 더 이상 지원 대상이 아니다.
이번 변경은 github.com뿐 아니라 GitHub Enterprise Cloud with Data Residency에도 적용된다. 단순한 향후 deprecation 예고가 아니라, 9월 23일을 기준으로 Node.js 20 runtime을 실제 runner에서 제거한 최종 전환 단계다.
GitHub Copilot app, 로컬 agent 실행을 위한 sandboxing 공개 프리뷰
- 발표일: 2026-09-23 — 정확한 게시 시각 미확인
- 상태: Public Preview
- 기본값: 비활성화
- 원문: GitHub — Local sandboxing in the GitHub Copilot app
GitHub가 Copilot app에서 coding agent가 로컬 shell command를 실행할 때 접근 가능한 자원을 제한하는 local sandboxing을 public preview로 공개했다. repository 또는 working tree를 대상으로 하는 local session에 project 단위 정책을 적용하는 방식이다.
filesystem 정책에서는 agent가 추가로 읽고 쓸 수 있는 folder, read-only로만 접근할 수 있는 folder, 접근 자체를 금지할 folder를 지정할 수 있다. network에서는 outbound internet과 local network 접근을 제어하고, credential 영역에서는 authenticated HTTPS Git operation에 사용하는 Git credential과 GitHub CLI authentication credential의 사용 여부를 설정할 수 있다.
이 설정은 단순한 UI상의 권고가 아니라 session을 생성할 때 요청하는 sandbox policy다. 조직에서 enterprise-managed policy를 사용하는 경우에는 project가 요청한 설정보다 실제 적용되는 권한이 더 제한적일 수 있다.
또한 운영체제가 요청한 sandbox policy를 기술적으로 강제할 수 없는 경우 sandbox 없이 그대로 실행하는 fallback을 사용하지 않고 shell 실행 자체를 실패시킨다. agent 실행 제약이 제대로 적용됐는지 알 수 없는 상황에서 자동으로 unrestricted mode로 내려가는 것을 방지한 설계다.
기능은 기본적으로 꺼져 있으며 project 설정에서 Sandbox new sessions를 활성화해야 한다. 이미 실행 중인 session에는 자동 적용되지 않고, 설정을 변경한 뒤 생성되거나 재시작된 session부터 반영된다. 실행 중인 local session에서는 /sandbox on 명령으로 해당 session에만 활성화할 수도 있다.
범위에도 제한이 있다. 이번 기능은 local repository와 local working-tree session만 대상이며 cloud sandbox나 remote host에서 실행되는 session에는 적용되지 않는다. GitHub Copilot app과 Copilot CLI의 sandbox 설정 역시 서로 별개로 관리된다.
📚 추천 글
Rendering huge pull requests in the GitHub Copilot app
- 저자: Alberto Gimeno / GitHub
- 게시일: 2026-09-23
- 원문: GitHub Engineering — Rendering huge pull requests in the GitHub Copilot app
GitHub Copilot app의 pull request diff 화면을 다시 설계하면서 2,200개 파일, 100만 줄 이상의 변경, 400개가 넘는 inline review comment가 있는 실제 대형 PR을 어떻게 렌더링했는지 설명하는 기술 글이다.
코드 diff 자체는 virtualization으로 해결하기 비교적 쉽다. 화면에 보이는 line과 주변 영역만 DOM에 올리고, 각 code row의 높이가 일정하다는 전제에서 전체 scroll geometry를 미리 계산할 수 있다. GitHub 구현은 React component를 line마다 생성하는 대신 imperative하게 재사용되는 row renderer와 typed-array 기반 geometry를 사용한다.
문제는 review comment다. Markdown wrapping, <details> 확장, reply composer, 이미지 로딩 등에 따라 높이가 runtime에 계속 달라지기 때문에 code line처럼 사전에 높이를 확정할 수 없다. 높이를 지나치게 크게 추정하면 빈 공간이 생기고, 작게 추정하면 clipping이 발생한다. 실제 높이를 측정한 뒤 전체 offset을 바로 다시 계산하면 사용자가 보고 있던 위치가 갑자기 움직인다.
GitHub는 comment block의 높이를 먼저 estimate하고 실제로 viewport에 가까워졌을 때 lazy measurement를 수행한다. ResizeObserver는 크기가 바뀌었다는 사실을 기록하고 대부분의 correction은 batch 처리하지만, 사용자가 직접 <details>를 열거나 reply composer를 띄워 화면에 보이는 block이 커지는 경우에는 같은 frame 안에서 correction을 적용한다.
높이 correction으로 scroll 위치가 움직이지 않도록 pixel 좌표가 아니라 사용자가 보고 있는 row 또는 block의 identity와 내부 offset을 anchor로 저장한다. 높이 변경 후 같은 anchor의 새 pixel 위치를 계산해 viewport를 다시 맞춘다. 반면 active wheel·pointer scrolling 중에는 correction이 사용자의 scroll momentum과 충돌하지 않도록 지연한다.
data pipeline도 함께 최적화했다. file tree와 metadata 같은 구조를 content보다 먼저 streaming하고, syntax highlighting은 main thread 밖에서 처리한다. 큰 Markdown body와 suggested-change context 역시 viewport에 접근하기 전에는 만들지 않는다.
특히 성능 문제를 사람이 계속 scroll하면서 눈으로 찾지 않고 instrumentation과 자동화된 flow로 재현한 부분이 흥미롭다. 실제 desktop app을 자동으로 움직이며 cold·warm 상태, comment expansion, reply composer, sidebar toggle, window resize 등을 반복하고 render count와 frame jank, 빈 영역 발생 여부를 기록했다.
단순한 “virtual list를 사용했다” 수준을 넘어 variable-height content, scroll anchoring, ResizeObserver, streaming data pipeline, off-main-thread processing, 실제 성능 검증 방식이 하나의 대형 UI에서 어떻게 연결되는지 볼 수 있는 글이다.
Run an LLM Inside a Browser Tab: WebGPU and Local Inference in 2026
- 발행: Pinggy Blog
- 게시일: 2026-09-20
- 원문: Pinggy — Run an LLM Inside a Browser Tab: WebGPU and Local Inference in 2026
WebGPU를 이용해 서버 API 없이 browser tab 안에서 직접 language model inference를 실행하는 현재 선택지와 실제 제약을 비교한 글이다. WebLLM, Transformers.js, Chrome의 built-in Prompt API를 각각 어떤 상황에서 사용할 수 있는지 구체적으로 비교한다.
WebLLM은 WebGPU를 직접 사용하고 OpenAI API와 유사한 interface를 제공해 browser chatbot을 만들기 쉬운 반면, model weight를 사용자가 처음 방문할 때 내려받아야 한다. 글에서 예로 든 4-bit Llama 3.2 1B model은 약 695MB download와 약 880MB의 GPU memory를 요구한다.
Transformers.js는 text generation뿐 아니라 embedding, speech recognition, image model, classification 등 더 넓은 workload를 지원하고 WebGPU가 없을 때 WebAssembly CPU backend로 fallback할 수 있다. 반대로 WebLLM은 GPU 기반 chat workload에 더 집중된 선택지다.
Chrome Prompt API는 model을 browser가 관리하기 때문에 application bundle이나 별도의 수백 MB model download를 직접 운영하지 않아도 된다는 장점이 있지만 browser와 hardware 조건에 강하게 묶인다. 글에서는 desktop 중심 지원, GPU memory와 disk-space requirement, browser vendor 종속성을 주요 trade-off로 짚는다.
WebGPU 자체에도 배포 조건이 있다. secure context가 필요해 HTTPS나 localhost가 아니면 navigator.gpu를 사용할 수 없고, browser별 지원 범위 차이도 여전히 존재한다. Firefox에서는 service worker 안에서 WebGPU를 사용하는 데 제한이 있다는 점도 다룬다.
성능 수치도 외부 연구 결과와 함께 설명한다. 글이 인용한 WebLLM 연구에서는 M3 Max에서 Llama 3.1 8B decoding이 약 41.1 token/s, 동일 장비의 native MLC-LLM 성능의 약 71% 수준으로 측정됐다. 이는 Pinggy 자체 benchmark가 아니라 글에서 인용한 WebLLM 연구 결과다.
브라우저 AI 기능을 단순 demo 수준으로 소개하지 않고 첫 방문 download 비용, GPU memory, browser compatibility, cache, privacy, fallback 전략까지 포함해 실제 web application architecture 관점에서 비교한다는 점이 읽을 만하다.
Reproducing, disclosing, and fixing the libheif vulnerability with Hacktron and the maintainers
- 저자: Karim Rahal / Vercel
- 게시일: 2026-09-18
- 원문: Vercel — Reproducing, disclosing, and fixing the libheif vulnerability with Hacktron and the maintainers
Next.js image optimization에서 발견된 RCE가 실제로는 Next.js 자체가 아니라 AVIF decoder인 libheif까지 이어지는 dependency chain에서 발생했다는 사실을 재현하고 수정한 과정을 정리한 보안 글이다.
Next.js의 <Image>는 image optimization 과정에서 sharp를 사용하고, sharp는 libvips, AVIF decoding에서는 다시 libheif에 의존한다. 따라서 application layer에서 발견된 문제라도 실제 취약한 코드는 여러 단계 아래 native image-processing library에 있을 수 있다.
Hacktron이 8월 11~12일 Vercel에 문제를 신고한 뒤 양측은 현재 Next.js build에서 동작하는 RCE proof of concept을 재현했다. Vercel은 8월 13일 중앙 Image Optimization Service에서 AVIF optimization과 resizing을 차단해 자사 platform 전체에 먼저 mitigation을 적용했다.
그다음 sharp·libvips·libheif maintainer들과 coordinated disclosure를 진행했다. 8월 19일 Next.js 팀과 libvips maintainer가 수정 방향을 논의했고, libheif 측은 GitHub Security Advisory를 통해 remediation을 진행했다. 8월 25일 libheif 1.23.2가 RCE를 수정했다.
Vercel에 배포된 Next.js와 self-hosted Next.js의 대응 방식이 달랐다는 점도 흥미롭다. Vercel에서는 모든 image optimization request가 중앙 service를 통과하기 때문에 platform 측에서 AVIF 처리를 즉시 비활성화할 수 있었다. 반면 self-hosted application은 Vercel이 중앙에서 차단할 수 없기 때문에 Next.js 자체 security release가 필요했고, 해당 릴리스에서는 AVIF optimization을 비활성화하는 mitigation이 포함됐다.
하나의 frontend framework 기능이 JavaScript framework → Node native module → image-processing library → codec library로 이어지는 공급망에 의존하고, 취약점이 발견됐을 때 hosting provider와 framework, 여러 upstream maintainer가 각각 어떤 계층에서 mitigation해야 하는지 보여주는 좋은 사례다.