Rust를 주력 언어로 쓰던 한 개발자가 몇 년 만에 Zig로 돌아와 약 4개월을 보낸 경험을 정리했다. 그는 이 기간 동안 실제 소프트웨어를 작성하고 온라인과 오프라인 양쪽에서 커뮤니티에 다시 합류했다. 아직 1.0에 도달하지 못한 언어를 실무 관점에서 어떻게 받아들였는지, 그리고 어떤 지점에서 벽에 부딪혔는지를 균형 있게 보여준다는 점에서 Zig 도입을 저울질하는 팀에게 참고할 만하다.
그가 처음 손댄 프로젝트는 Gemini, Finger, Gopher, Spartan 같은 이른바 '스몰넷' 프로토콜을 다루는 라이브러리 snurl이다. 스몰넷판 curl 대안을 목표로, 테스트와 퍼징 요구사항을 비슷하게 가져가되 규모만 줄이고 TigerStyle을 가능한 범위에서 따르려 했다. 그런데 초기부터 걸린 문제가 퍼저였다. 흥미롭게 기대했던 Zig의 내장 퍼징 기능이 실제로는 아직 완성되지 않은 상태였던 것이다. zig init이 만들어 주는 main.zig 예제에 퍼징이 시연되어 있어 더 당황스러웠다고 한다. 이후 그는 아직 공개하지 않은 TUI 타자 게임과 raylib 기반 n체 항성 진화 시뮬레이터도 만들었다.
오프라인 커뮤니티라는 자산
지난 몇 달 중 가장 인상적인 경험으로 그는 8월 20일 열린 Zig Day Seattle을 꼽는다. Zig Day는 지역 단위 모임으로, 관심 있는 사람들이 모여 각자의 프로젝트를 함께 작업하고 Zig에 대해 이야기하는 자리다. 신청자가 몰려 Bellevue 도서관에서 Bothell 도서관으로 장소를 옮겨야 했는데, Zig 창시자 Andrew Kelley가 참석한다는 점이 영향을 미쳤다. 그는 이 자리에서 다른 개발자들과 프로젝트를 논의했고, 친구 Evin Yulo와 함께 snurl에 Zig 표준 라이브러리의 TLS 구현을 대체 백엔드로 통합하는 작업을 진행했다. Kelley에게 내장 퍼징이 빨리 고쳐지길 바란다는 이야기도 건넸다고 한다. 지역 그룹이 운영하는 이런 모임이 커뮤니티 전체에 연결된 느낌을 준다는 평가다.
여러 Zig 버전을 오가야 하는 상황에서는 anyzig가 큰 도움이 됐다. 그는 프로젝트마다 zig master와 0.16.0을 번갈아 써야 했는데 anyzig 덕분에 가능했다고 말한다. 다만 build.zig.zon이 없는 디렉터리에서는 동작하지 않아, zig 명령에 의존하는 도구는 프로젝트 디렉터리 안에서만 쓸 수 있다는 한계가 있다. 일회성 스크립트의 자동 포매팅이 깨지는 식이다. 그는 이런 경우 기본 Zig 버전을 지정할 수 있으면 좋겠다고 제안한다.
명시성이 만드는 추론 가능성
그가 가장 마음에 들어 한 부분은 함수에 할당자(allocator)와 IO를 명시적으로 넘기는 설계다. 전역이나 지역 컨텍스트로 기본 할당자를 바꾸는 다른 언어들과 달리, Zig는 함수마다 할당자를 명시적으로 받는다. 덕분에 어떤 부분은 아레나 할당자, 어떤 부분은 범용 할당자, 또 어떤 연산은 FixedBufferAllocator만으로 처리하는 식의 선택이 코드에 그대로 드러난다. 그는 Odin의 암묵적 컨텍스트 방식보다 명시적인 Zig 쪽을 선호하며, 메모리 고갈 시 패닉을 내는 Rust의 숨겨진 할당보다 추론하기 쉽다고 본다. 비교적 최근 도입된 IO 파라미터도 비슷한 맥락이다. OS와 상호작용하는 함수가 IO를 받도록 함으로써, 테스트 시 테스트용 IO 인스턴스를 넣어 입력 스트림을 바꾸거나 쓰기를 일부러 실패시키는 일이 쉬워진다. 함수가 순수한지 아닌지도 한눈에 구분된다.
의존성 문화와 에러 처리에 대한 평가도 후하다. Zig의 기본 정신은 '필요 없으면 추가하지 않는다'이며, 반사(reflection), 난수, 에러 처리, JSON 파싱 같은 기능이 언어나 표준 라이브러리에 내장돼 있어 Rust처럼 serde나 syn을 매번 끌어올 필요가 없다. 그의 Zig 프로그램 대부분은 직접 의존성 한두 개에 간접 의존성은 0인 반면, 가장 작은 Rust 프로젝트조차 직접 몇 개와 간접 수십 개를 끌고 온다고 한다. 에러 처리도 try 키워드와 반환 타입의 ! 하나로 기본값이 정해져, Box나 anyhow 같은 장치가 필요한 Rust보다 올바른 처리를 유도한다는 설명이다. 증분 컴파일 역시 강점으로 꼽힌다. zig build --watch -fincremental를 켜면 변경분만 링킹 단계까지 추적해 사람이 인지하기 전에 반영되는데, 다만 아직 Linux·macOS의 x86_64에서만 지원된다.
1.0 이전이 남긴 숙제
물론 그늘도 분명하다. 그가 Rust를 일부 프로젝트에 계속 쓰는 이유는 결국 안정성이다. 표준 라이브러리의 잦은 변경은 생태계 전반에 깨짐을 유발하고, 이것이 0.17.0 출시가 오래 걸린 배경으로 이해된다고 한다. 수명(lifetime) 관련 지원도 아쉽다. 지역 변수를 반환하거나 블록에서 스택 할당 버퍼를 반환하는 코드가 현재는 통과되지만 향후 Zig 버전에서 조용히 깨질 수 있어, 디버그 모드에서 이를 걸러 주는 린트나 메모리 무효화가 있으면 좋겠다는 바람이다. 가장 현실적인 걸림돌은 문서다. 시작하기엔 충분하지만 그 이상으로 나아가려면 드문드문 달린 주석에서 의도를 읽어내야 하고 예제도 드물다. 실제로 그와 친구는 버퍼 설정 방법을 알아내지 못해 snurl의 표준 라이브러리 TLS를 아직 작동시키지 못했다. 결국 견고한 Zig 프로그램을 만드는 지식이 웹 곳곳과 커뮤니티에 분산돼 있어, 커뮤니티에 깊이 들어가 있지 않은 개발자에게는 효과적으로 작업하기가 쉽지 않다는 것이 그의 결론이다.