Zig로 HTTP 서비스 만들려다 실패한 후기 — 2배 빠르지만 아직 갈 길이 멀다

Zig 0.15.2로 SQLite 기반 HTTP 서비스를 만들려고 몇 주간 시도했지만 결국 포기한 개발자의 경험담임. http.zig와 zig.sqlite 라이브러리를 사용했고, 여전히 Zig를 좋아하지만 프로덕션 HTTP 서비스에는 아직 이르다는 결론임.

좋았던 점

• 속도가 미친 수준임 — fly.io에서 동일한 Go 서비스 대비 2배 빠름
• Allocator 개념이 이해하기 쉽고, arena allocator를 HTTP 콜마다 쓰면 메모리 관리 스트레스가 줄어듦
• 메모리 누수도 프로그램 종료 시 미해제 메모리를 리포트해서 찾기 쉬운 편
• 쓰레드 기반 동시성이 mutex, Signal, Event로 비교적 직관적임
• comptime이 진짜 강력함 — 정적 파일용 HTTP 핸들러, DB 마이그레이션 struct, prepared SQL statement 등을 컴파일 타임에 코드 생성함
• 학습 곡선이 생각보다 가파르지 않고, 막혔다가 이해하면 언어에 대한 호감이 오히려 늘어남

문제점

• 문자열 타입이 없는 것 자체는 괜찮은데 []const u8, []u8, [_]u8, [:0]const u8가 전부 다른 타입이라 혼란스러움
• 패키지 생태계 부족이 치명적 — SQLite 커넥션 풀, .env 파서, rate limiter를 전부 직접 만들어야 했음. AWS S3 클라이언트 같은 건 신뢰할 만한 패키지 찾기가 거의 불가능
• http.zig에서 트래픽이 많을 때 server.stop 호출 시 segfault 발생 — 처리 중인 요청의 메모리를 해제해서 생기는 것으로 추정
• zig build run이 SIGTERM을 먹어버려서 zig build && ./zig-out/bin/cmd로 실행해야 함
• 0.16.0에서 IO 레이어 리라이트하면서 gzip 기능이 빠짐 — 정적 파일 압축 전송 구현이 어려워짐
• 쓰레드 mutex 범위를 약간만 넓게 잡아도 성능이 확 떨어지는데, 이런 실수를 찾기가 쉽지 않음
• 메모리 사용량이 예상의 2배인데 누수는 아니고, 런타임에 allocator를 인스펙션할 방법이 마땅치 않음
• AI/LLM 자동완성 도구의 Zig 지원이 빈약함 — 표준 라이브러리가 빠르게 변해서 학습 데이터가 부족
• Mac에서 Docker 빌드가 안 되는데 커뮤니티 반응은 "Zig에 Docker 필요 없잖아" — fly.io 배포하려면 필요함

결론적으로 아직 Zig로 프로덕션 HTTP 서비스는 시기상조이지만, 언어 자체는 여전히 매력적이라는 입장임.