돌아온 페인트공 Shlemiel: Zig의 libc 재작성이 SQLite를 느리게 만든 과정

Rust 기반 체스 분석 서비스에서 약 4만 건의 JSON 레코드를 SQLite에 저장하는 데 수 분이 걸리고 CPU 코어 하나가 포화되는 문제가 발생함 원인은 Linux용 SQLite를 컴파일할 때 사용한 Zig의 libc 재구현에 있었으며, strspn이 호출될 때마다 문자열 전체 길이를 측정해 토큰화 과정에서 문자열을 반복 순회함 토큰화가 진행될 때마다 남은 문자열 길이를 다시 측정해 이차 시간 복잡도가 발생했으며, 해당 사례에서 1.2MB 파일의 토큰화는 약 12,000배 느려짐 SQLite 컴파일에 Zig를 사용하지 않은 Mac에서는 문제가 나타나지 않았으며, Linux에서도 작은 규모의 테스트에서는 드러나지 않다가 대량 레코드 처리에서 심각한 병목이 됨 JSON의 공백을 미리 제거해 비용을 줄였지만, 다른 경로에서도 문제가 생길 수 있어 Linux 빌드를 Linux 컨테이너로 이전함 기본 알고리듬에서 되풀이되는 함정 추상화 수준이 높아져도 기본 알고리듬이 프로젝트에 예상 밖의 큰 영향을 줄 수 있으므로 이를 이해해야 함. Joel Spolsky의 2001년 글 Back to Basics가 다룬 주제임 페인트공 Shlemiel은 페인트통을 옮기지 않은 채 도로의 선을 칠해, 작업이 진행될수록 페인트통까지 왕복하는 시간이 길어지는 비유임 사소해 보이는 선택이 이차 시간 복잡도로 이어지는 패턴이며, 2026년에도 같은 문제가 반복됨 체스 분석 서비스에서 드러난 CPU 병목 체스 분석 서비스는 주로 Rust와 SQLite로 구성되며, 실행 노드에 분석 작업을 배분함 각 실행 노드는 수백 개 이상의 체스 게임을 처리한 뒤 대량의 JSON 묶음을 반환하고, 메인 서비스가 이를 가공해 SQLite에 저장함 분석은 실행 노드의 코어 24개를 수 분간 최대한 사용하지만, 데이터 저장은 밀리초 또는 그 미만에 끝날 것으로 예상했음 처음으로 큰 게임 묶음을 처리하자 약 4만 건의 레코드 삽입에 수 분이 걸림 기존 테스트에서는 핵심 병목으로 드러나지 않았으나, 데이터가 커지자 서비스 진행을 막는 문제가 됨 저장 과정에서 CPU 코어 하나가 완전히 포화돼, 단순한 JSON 삽입이 왜 이처럼 많은 CPU 시간을 쓰는지 추적하게 됨 서비스는 개인적인 체스 실력 향상에 유용했던 작업을 공개한 것으로, 생계 수익보다는 운영비를 충당하는 수준을 목표로 함 Rust 프로젝트에 들어온 Zig의 표준 라이브러리 프로젝트 자체는 Zig가 ...