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 위에 다시 구현해 호환성을 지킨 설계를 코드 예제와 함께 정리한다.

JavaScript 프레임워크의 'AI 비용' — 같은 앱을 12개 프레임워크로 5번씩 에이전트에게 만들게 한 벤치마크 (Nolan Lawson)

articles ai coding-agent agentic-engineering javascript frontend benchmark evaluation performance mcp skills
Nolan Lawson의 블로그 글 'The AI cost of JavaScript frameworks'를 분석·정리한다. 같은 Pokémon 앱을 12개 JavaScript 프레임워크·메타 프레임워크로 코딩 에이전트(Opus 5.5)에게 5번씩 만들게 하고, 빌드 비용·Lighthouse 품질·코드 줄 수를 비교한 실험을 읽고, '에이전트에게 더 좋...

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

성능·운영·트러블슈팅 (지연·대역폭 · 패킷 분석 · CDN · 관측)

network performance latency bandwidth tcpdump wireshark cdn observability troubleshooting
배운 것을 현장에서 따져 묻고 고치는 마지막 단계. 지연과 대역폭의 차이, RTT·처리량·버퍼블로트가 체감 속도를 가르는 법, tcpdump·Wireshark로 패킷을 읽는 법, CDN과 캐싱으로 지연을 줄이는 법, 그리고 네트워크를 관측하는 지표·도구까지.

사용자가 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가 단일 노드에서 빠른 이유...