Go 1.27의 encoding/json/v2 — 15년 된 JSON 패키지를 깨지 않고 다시 짓는 법

articles go json serialization api-design performance security streaming backward-compatibility
Go 공식 블로그 'A new Go API for JSON'(2026-11-04)을 분석한다. Go 1.27에서 정식 제공되는 encoding/json/v2와 encoding/json/jsontext가 v1의 동작 결함·API 결함·성능 한계를 어떻게 풀었는지, 그리고 v1을 v2 위에 다시 구현해 호환성을 지킨 설계를 코드 예제와 함께 정리한다.

문제는 메모리 레이턴시야 — 일을 더 시켜서 GROUP BY를 빠르게 만드는 radix partitioning

articles performance memory cpu-cache memory-latency hash-aggregation query-engine database rust
Pivot 블로그(Epsio Labs)에 Maor Kern이 쓴 'It's the memory latency, stupid'를 정리한다. CPU 100%가 실제로는 절반가량 메모리를 기다리며 멈춘 상태일 수 있다는 점을 perf 카운터로 보여 주고, 해시 집계를 4096개 파티션으로 쪼개는 radix partitioning으로 명령어는 더 많이 쓰면서...

sanstun: IO를 걷어낸 WireGuard — Firezone의 sans-IO·병렬 친화 Rust 구현 분석

articles rust wireguard sans-io vpn network api-design parallelism performance open-source
Firezone 공식 블로그에 Thomas Eizinger가 쓴 'Introducing sanstun'을 정리한다. 2년 넘게 boringtun 포크를 패치하며 얻은 교훈으로 만든 sans-IO WireGuard 상태 기계가, 프로토콜 불변식을 타입으로 강제하고 장부 정리와 암호 연산을 분리해 병렬 crypto를 여는 방식을 분석한다.

tar-codec: uv가 tar 파서를 처음부터 다시 쓴 이유 — 파서 차이(differential)와 싸우는 법

articles rust security performance supply-chain parser-differential uv
Astral 블로그에 William Woodruff가 쓴 'tar-codec: a fast and secure tar parser for the Rust ecosystem'을 정리한다. V7·UStar/pax·GNU로 갈라진 tar 포맷의 역사와 그 틈에서 생기는 파서 차이 공격, 그리고 이를 '보수적으로 받아들이고 층마다 제약을 조이는' 설계로 막아...

브라우저의 메인 스레드는 비싸다 — 아껴 쓰기와 안 쓰기의 성능 전략

articles performance frontend browser event-loop concurrency
kciter의 '브라우저의 메인 스레드는 비싸다'를 정리한다. 프론트엔드 성능 문제의 본질을 네트워크·번들 크기가 아닌 단일 메인 스레드의 시간 예산 문제로 재정의하고, '아껴 쓰기'(쪼개기·모으기·우선순위·미루기)와 '안 쓰기'(컴포지터·워커·일 자체 없애기)라는 두 축의 전략을 코드 수준에서 짚는다.

사용자가 10배 늘었다, 서버부터 사면 될까 — 증설 전에 측정하라

articles performance scalability slo bottleneck database
velog @gusdudco6(코헤)의 '사용자가 10배 늘었다. 일단 서버부터 사면 되나요?'를 정리한다. 사용자 증가는 부하 증가와 다르다는 전제에서 출발해, SLO로 상태를 정의하고 요청 여정에서 진짜 병목을 찾은 뒤에야 처방을 고르는 — 반사적 증설 대신 측정 기반 의사결정의 순서를 따라간다.

DuckDB는 왜 빠른가 (1부): 인프로세스 실행부터 컬럼 저장까지 — Greybeam 내부 구조 딥다이브

articles database olap query-engine columnar performance
Greybeam의 Kyle Cheung이 쓴 'DuckDB Internals: Why is DuckDB Fast? (Part 1)'를 정리한다. 인프로세스 실행, SQL→논리/물리 플랜 컴파일, 33개 옵티마이저, 파이프라인 기반 병렬 실행, 그리고 row group·zone map 중심의 컬럼 저장 계층까지 — DuckDB가 단일 노드에서 빠른 이유...