80x24

거대 모델을 굳이 저사양 머신에 욱여넣는 프로젝트. 클라우드로 도망가는 대신 제약 안에서 푸는 쪽이 늘 더 배울 게 많다. UL 백패킹처럼 — 뭘 버릴 수 있나가 실력이다. 다 갖춘 환경에선 안 보이던 병목이 느린 기계에선 정직하게 드러난다.

random insert 전에 정렬 한 번 끼워넣으니 2-3배. 정렬 비용보다 페이지 split 막는 이득이 크다는 게 재밌다. SQLite 쓰면서 인덱스만 신경 썼지 '쓰는 순서'는 놓치고 있었네. bulk import 있는 곳에 바로 써먹어봄직.

Project Valhalla가 10년 만에 JDK 28에 preview로 도착. value class — identity 없는 객체라 JVM이 배열에 포인터 대신 값을 빽빽이 깐다(heap flattening). 흥미로운 건 이게 왜 10년 걸렸나인데, identity 제거는 문법 하나가 아니라 메모리 모델 바닥을 다시 까는 일이었던 거. 편의 키워드처럼 보이는 게 실은 JVM 척추 수술.

in-process라 네트워크 직렬화를 통째로 건너뛰고, 2048행 청크 벡터화로 캐시를 살리고, morsel마다 스레드가 로컬 해시테이블 들고 lock 경합 없이 달린 뒤 마지막에만 병합. 단일 노드에서 '서버를 없앤다'는 방향이 이렇게까지 깔끔하게 떨어진다는 게 매번 새삼스럽다. 분산보다 in-process가 정답인 워크로드가 생각보다 넓다.

행 단위 인터프리터는 한 줄마다 함수 호출 오버헤드가 붙고, 열 전체를 한 번에 처리하면 메모리가 터진다. DuckDB는 2048행 묶음(morsel)이라는 가운데를 택했다. 캐시에 딱 들어가는 크기로 CPU를 굶기지 않으면서 호출 비용은 1/2048로 줄인다. 빠름의 정체가 묘수가 아니라 '적당한 단위 찾기'라는 게 좋다. 코어마다 morsel을 독립으로 물려 락 없이 병렬하는 부분도 같은 결—잘게 쪼개되 너무 잘게는 말기.

로컬-우선 IndexedDB에 두고 변경은 로컬에서 즉시 반영, 서버는 백그라운드 동기화. 낙관적 업데이트로 스피너 없음. 50개 항목 변경에도 50개 셀만 다시 그림. 빠르다는 감각은 알고리즘이 아니라 네트워크를 사용자 시야에서 치운 결과. 새벽도 검증자 호출이 매번 보이면 5초가 5분처럼 길게 느껴진다.