성능Obs.js로 사용자가 있는 곳에서 만나기
Harry Roberts가 Obs.js를 소개합니다. 이 소형 라이브러리는 latency, bandwidth, Data Saver 모드, 배터리 잔량, CPU, 메모리 등 브라우저 신호를 읽어 html 요소의 CSS 클래스와 window.obs JavaScript 객체로 노출합니다. 라이브러리는 Status(실제 기기 상태)와 Stance(그로부터 도출한 판단)를 구분하며, deliveryMode, canShowRichMedia, shouldAvoidRichMedia 같은 고수준 속성을 제공합니다. Roberts 자신의 사이트에서는 Obs.js가 배포 모드에 따라 고해상도 이미지 스택과 LQIP 전용 버전을 전환하며, SpeedCurve 데이터상 LCP 차이는 80ms에 불과합니다. 또한 기기 등급별 INP나 Data Saver 비율 분석 같은 analytics 세분화 레이어로도 활용할 수 있습니다.
Read Articlearrow_forward Article · 성능READ TIME: 13m
지연에서 즉시로: GitHub Issues Navigation 성능 현대화
GitHub Issues 성능 팀은 세 가지 전략을 조합해 navigation 지연을 대폭 개선했습니다. 첫째, IndexedDB 기반 client-side cache에 stale-while-revalidate 방식을 적용해 React soft navigation의 instant 비율을 4%에서 22%로 끌어올렸습니다(cache-hit ratio 33%). 둘째, 최신성 갱신 없이 고의도 이슈 참조를 사전에 cache에 채우는 preheating을 통해 instant 비율이 전체 30%, React 경로는 70%까지 상승하고 cache-hit ratio는 96%에 달했습니다. 셋째, service worker가 hard navigation을 가로채 이슈 데이터가 이미 local에 캐시된 경우 서버가 얇은 HTML shell만 반환하도록 신호를 보내 cold start에서도 React가 로컬 데이터로 렌더링할 수 있게 했습니다. 성공 지표로는 LCP에 맞춘 내부 HPC 지표를 사용해 Instant(200ms 미만), Fast(1000ms 미만), Slow로 구분했으며, 전체 롤아웃 후 P10은 600ms에서 70ms, P50은 1200ms에서 700ms로 감소했습니다.
READ_FULL_LOGarrow_forwardArticle · 보안READ TIME: 17m
GitHub Actions Cache Poisoning이 오픈소스를 집어삼킨다
Neciu Dan은 GitHub Actions cache poisoning 공격 메커니즘과 방어 방법을 상세히 설명합니다. 이 공급망 공격은 Angular(2024년 연구 공개), tj-actions/changed-files(23,000개 이상의 downstream workflow, 2025년 3월), Cline(개발자 4,000명, 2026년 2월), TanStack(42개 패키지에 걸친 84개의 악성 버전, 2026년 5월)을 차례로 공격했습니다. 공격은 GitHub의 cache pool이 신뢰 경계를 넘어 공유된다는 점을 악용합니다. fork 코드를 checkout하는 낮은 권한의 pull_request_target workflow가 나중에 release workflow가 복원할 동일한 cache key로 poisoned 의존성 저장소를 기록할 수 있습니다. cache 쓰기는 workflow의 GITHUB_TOKEN과 별도인 runner 내부 토큰을 사용하기 때문에 workflow 권한을 제한해도 cache poisoning을 막을 수 없습니다. 10가지 remediation 체크리스트를 제공하며 주요 항목으로는 pull_request_target를 pull_request로 교체, id-token: write가 있는 workflow에서 caching 비활성화, 모든 서드파티 action을 commit SHA로 pin, zizmor 또는 actionlint를 필수 PR 체크로 추가 등이 있습니다.
READ_FULL_LOGarrow_forwardArticle · 아키텍처READ TIME: 10m
재고 예약에서 Redis를 MySQL로 교체했다 — 그리고 확장에 성공했다
Shopify 엔지니어링 팀은 MySQL 8의 SKIP LOCKED 기능을 활용해 Redis 기반 재고 예약 시스템을 MySQL로 전환하였습니다. 새로운 설계는 판매 가능한 단위당 하나의 row를 사용하며, 항목/위치 조합당 최대 1,000개로 제한된 pool을 유지해 Redis로는 원자적으로 처리할 수 없었던 예약과 재고 원장 간 ACID 트랜잭션을 보장합니다. 구현 과정에서 복합 primary key 도입으로 InnoDB lock 수를 row당 2개에서 1개로 줄이고, 트랜잭션 격리 수준을 READ COMMITTED로 변경해 보충 시 gap lock을 방지했으며, 예약과 claim 경로 간 lock 획득 순서를 통일해 deadlock을 제거했습니다. 실제 처리량 병목은 관련 없는 checkout 코드의 connection pool 고갈이었으며, SQL 구문에 비즈니스 프로세스 태그를 추가하고 ProxySQL 레이어에서 connection 보유 시간을 추적하는 방식으로 진단했습니다. 최종적으로 읽기 50%, 트랜잭션 33% 감소로 Black Friday 수준 트래픽을 writer CPU 50% 미만으로 처리할 수 있었습니다.
READ_FULL_LOGarrow_forwardArticle · 커리어READ TIME: 6m
배움을 외주화하지 마세요
Addy Osmani는 스펙을 붙여넣고 결과를 수락해 배포하는 기본 AI 보조 코딩 워크플로우가 지속적인 이해력 구축보다 작업 완료에 최적화되어 있다고 주장합니다. 세 가지 연구를 인용하는데, Anthropic의 무작위 실험에서는 AI가 생성한 코드를 그대로 복사한 엔지니어가 이해도 테스트에서 40%를 기록한 반면 개념적 질문에 AI를 활용한 엔지니어는 65%를 기록했습니다. MIT의 "Your Brain on ChatGPT" EEG 연구(arXiv 2506.08872)는 뇌 연결성 감소와 LLM 사용자의 83%가 방금 작성한 내용을 인용하지 못했음을 보여줍니다. CHI 2026 논문은 작업 초반의 LLM 앵커링이 인간이 이후 작업을 독립적으로 수행했더라도 의사결정 품질을 저하시켰음을 밝혔습니다. 실용적 개선책으로는 프롬프트 전 가설 수립, 코드 전 설명 요청, AI 출력을 주니어 개발자의 PR처럼 검토하기, 주기적으로 AI가 작성한 코드를 직접 재현해 스킬 변화를 확인하는 자세 전환을 제안합니다.
READ_FULL_LOGarrow_forwardArticle · 보안READ TIME: 18m
pull_request_target의 함정
Sascha Becker는 2025년 8월부터 2026년 5월 사이에 6건의 주요 오픈소스 공급망 공격을 가능하게 한 GitHub Actions의 pull_request_target 트리거를 심층 분석합니다. Nx(QUIETVAULT 자격증명 도용, 2025년 8월), PostHog(74일간 악용된 리뷰어 할당 workflow, 2025년 11월), Trivy/LiteLLM(poisoned upstream 스캐너, 2026년 2-3월), prt-scan 캠페인(500개 이상의 repo 대상, 2026년 3-4월), TanStack(84개의 악성 npm 버전, 2026년 5월)을 다룹니다. TanStack 공격 체인을 세 단계로 해부하는데, fork PR이 bundle-size 벤치마크 workflow를 통해 poisoned pnpm store를 심고, 캐시된 store가 release 권한이 있는 main 브랜치 push 시 복원되며, 악성 바이너리가 /proc/pid/mem을 통해 runner 프로세스 메모리에서 OIDC 토큰을 덤프합니다. 핵심 방어책은 두 workflow 패턴으로, secret이나 cache 없이 pull_request workflow에서 신뢰할 수 없는 fork 코드를 실행하고 artifact를 통해 elevated 권한을 가진 별도의 workflow_run workflow에 전달하는 방식입니다. contents: read 권한 제한이 cache 쓰기나 in-memory OIDC 토큰 스크래핑을 차단하지 못한다는 점도 명확히 설명합니다.
READ_FULL_LOGarrow_forwardArticle · 성능READ TIME: 16m
10MB API 응답은 코드가 실행되기도 전에 66ms를 소모한다
Ko-Hsin Liang은 Node.js v22에서 대용량 API payload의 실제 비용을 측정한 통제 벤치마크와 정적 분석 스캔 결과를 제시합니다. 5개 벤치마크 모듈(BM-01~BM-05)에 따르면 10MB payload의 JSON.parse는 66ms가 걸려 Node.js event loop를 완전히 차단하는 반면, 100KB 단위 청크 파싱은 6.38ms로 10배 개선됩니다. 쿼리 수준에서는 ORM의 무제한 fetch 대비 100KB 단위 paginated 쿼리가 10MB에서 1,246배 빠른데, 청크 방식은 V8의 young-generation heap 내에서 할당이 이루어져 대용량 단일 파싱이 유발하는 full Mark-Compact GC pause를 방지하기 때문입니다. 277개의 공개 Node.js API repo에 대한 Babel AST 스캔에서 64.6%가 최소 한 가지 대용량 payload anti-pattern을 가지고 있었으며, 무제한 findAll/findMany 호출 32,829건, 깊은 중첩 include 17,069건, SELECT * 2,112건이 발견됐습니다. 해결책은 아키텍처 수준의 접근이 필요하며, 모든 ORM 목록 호출에 명시적 limit 적용, 모든 목록 endpoint에 cursor pagination 도입, 중첩 include는 flat 구조가 객체 수를 실질적으로 줄일 때만 병합하는 방식을 권장합니다.
READ_FULL_LOGarrow_forwardsummarizeDigest_Summary
이번 주는 두 개의 임팩트 높은 성능 아티클이 주목을 받았습니다. Harry Roberts는 Obs.js를 소개했습니다. 이 소형 라이브러리는 latency, bandwidth, Data Saver 모드, 배터리, CPU, 메모리 등 브라우저 신호를 읽어 html 요소의 CSS 클래스와 window.obs 객체로 노출합니다. 실제 기기 상태인 Status와 deliveryMode, canShowRichMedia 같은 파생 Stance를 구분해 점진적 UI 적응을 가능하게 하며, SpeedCurve 데이터에서 8,742 페이지 뷰에 걸쳐 LCP 차이는 80ms에 불과합니다. 백엔드에서는 Shopify가 MySQL 8의 SKIP LOCKED 기능을 활용해 Redis 기반 재고 예약 시스템을 MySQL로 교체했고, Redis가 원자적으로 제공할 수 없었던 ACID 보장을 달성했습니다. 핵심 구현 교훈으로는 InnoDB lock 수를 절반으로 줄이는 복합 primary key, 보충 시 gap lock을 방지하는 READ COMMITTED 격리, deadlock을 제거하는 통일된 lock 획득 순서가 있습니다. 읽기 50%, 트랜잭션 33% 감소로 Black Friday 수준 트래픽을 writer CPU 50% 미만으로 처리했습니다.
GitHub의 Issues 팀은 세 겹의 navigation 성능 개선을 문서화했습니다. stale-while-revalidate 방식의 IndexedDB 클라이언트 캐시로 instant navigation을 4%에서 22%로, 고의도 이슈 참조에 대한 cache preheating으로 전체 30%, React 경로는 70%까지 향상시켰으며, service worker로 hard navigation을 가로채 데이터가 이미 캐시된 경우 thin HTML shell 응답을 신호로 보내는 방식을 적용했습니다. P10 지연은 전체 롤아웃 후 600ms에서 70ms로 감소했습니다. Node.js API 페이로드 연구에서는 10MB 페이로드의 JSON.parse가 이벤트 루프를 66ms 동안 차단하는 반면 100KB 청크 파싱은 6.38ms(10배 차이)임을 밝혔으며, 277개 공개 repo의 Babel AST 스캔에서 64.6%가 32,829건의 무제한 ORM findAll/findMany 호출을 포함한 최소 하나의 대용량 페이로드 안티 패턴을 갖고 있었습니다.
Addy Osmani는 기본 AI 코딩 워크플로우가 지속적인 학습보다 작업 완료에 최적화됐다는 연구 기반 에세이를 발표했습니다. Anthropic RCT(이해도 40% vs 65%), MIT Brain on ChatGPT EEG 연구(arXiv 2506.08872), CHI 2026 LLM 앵커링 논문을 인용합니다. 프롬프트 전 가설 수립, 코드 전 설명 요청, AI 출력을 주니어 PR처럼 검토하는 자세 전환을 실용적 교정책으로 제시합니다. 또 다른 아티클은 2025년 8월부터 2026년 5월까지 pull_request_target이 가능하게 한 6건의 오픈소스 공급망 공격을 분석하고 TanStack 공격 체인을 단계별로 설명하며 두 workflow 패턴으로의 전환을 포함한 10가지 remediation 체크리스트를 제공했습니다.
Key Takeaways- Obs.js는 deliveryMode, canShowRichMedia 같은 브라우저 신호 기반 CSS 클래스를 단 80ms의 LCP 트레이드오프로 제공합니다. 점진적 향상 레이어와 더불어 기기 등급별 INP 및 Data Saver 비율 분석을 위한 analytics 세분화 도구로도 활용할 수 있습니다.
- GitHub Issues navigation은 IndexedDB stale-while-revalidate 캐싱, 고의도 링크 preheating, thin HTML shell 응답을 신호하는 service worker를 조합해 instant 비율을 전체 4%에서 30%(React 경로 70%)로 끌어올렸으며,
P10 지연은 600ms에서 70ms로 감소했습니다. - 10MB JSON 페이로드는 Node.js 이벤트 루프를 66ms 동안 차단하지만 100KB로 청크하면 6.38ms로 줄어듭니다. 277개 공개 repo 스캔에서 64.6%가 무제한 ORM 목록 호출을 갖고 있었습니다. cursor pagination과 명시적 ORM limit는 선택이 아닌 필수입니다.
