Zig는 C의 성능과 제어력을 유지하면서 footgun과 디버깅 약점을 줄이고, CPU와 메모리를 직접 의식하는 시스템 언어를 지향함
핵심 차별점은 도구 체인으로, 시스템 의존성 없이 어느 OS에서 실행하든 어느 OS 대상으로든 zig build 하나로 빌드하는 것을 목표로 함
1.0 지연은 하위 호환성을 성급히 약속하지 않기 위한 선택이며, 501(c)(3) 비영리 구조 덕분에 장기 개선에 집중할 수 있음
Zig Software Foundation은 2024년 67만 달러 수입과 다양한 후원 구조를 갖췄고, CI 동작을 우선해 GitHub에서 Codeberg로 이동함
이슈와 풀 리퀘스트에는 no LLM, no AI 정책을 적용하며, AI 기여는 리뷰 시간과 멘토십을 해쳐 음의 가치가 된다고 봄
Zig의 출발점과 언어 설계
탄생 배경
Andrew Kelley는 디지털 오디오 워크스테이션을 만들기 위해 JavaScript, Go, Rust, C++를 차례로 시도했지만, 원하는 사용자 경험을 만들기에는 각각 한계가 있었다고 봄
JavaScript는 브라우저 안에서 너무 고수준이라 컴퓨터의 능력을 충분히 활용하기 어렵다고 판단함
Go는 C 라이브러리와의 상호운용이 좋지 않았고, 오디오처럼 정해진 시간 안에 처리가 끝나야 하는 실시간 작업에서 가비지 컬렉터가 글리치나 스킵을 만들 수 있어 부적합하다고 봄
Rust는 1.0 이전 시점에 규칙을 만족시키기 어렵고, 작은 변경도 컴파일 오류 연쇄를 만들었으며, 글꼴 렌더링을 한 달 동안 맞춘 뒤에도 더 진행하기 어렵다고 느낌
C++는 처음에는 생산적이었지만 작은 오타나 실수가 메모리 손상 버그로 이어져 몇 주씩 디버깅해야 했고, C++ 컴파일러와 C 링커를 쓰는 “C 스타일 C++”에서도 footgun 문제는 남았다고 봄
Zig의 출발점은 도구 체인이 허용하는 범위가 아니라 컴퓨터가 근본적으로 할 수 있는 일을 기준으로 사용자 경험을 타협하지 않겠다는 관점이었음
C를 대체할 수 있다고 보는 이유
Zig는 C의 힘을 포기하지 않으면서 C의 결함과 약점을 개선하기 때문에 C보다 낫다고 봄
C를 대체하려던 다른 시도들은 C가 가진 무언가를 포기했지만, Zig는 C가 할 수 있는 일을 모두 하면서 footgun은 줄이고 디버깅 가능성은 높임
C는 signed integer에는 최적화 정수만 있고 unsigned integer에는 wraparound 의미만 있지만, Zig는 signed/unsigned 모두에서 wraparound 또는 overflow 없음 보장을 선택할 수 있어 C보다 더 “C답다”고 표현됨
운영체제 커널, 임베디드 장치, 비디오 게임, WebAssembly 등 어디서나 재사용 가능한 코드를 작성할 수 있어야 C를 대체할 수 있으며, Zig가 C 수준의 기능과 안정성을 제공하면 성능이 더 좋고 버그가 적은 쪽을 선택하게 된다고 봄
Rust와의 차이
Rust와 Zig의 핵심 차이는 타입 시스템임
Rust는 함수 매개변수가 clone을 지원하는지, 어떤 인터페이스를 지원하는지, 어떤 타입을 넘길 수 있는지 같은 규칙을 메타 언어로 서술해야 함
Zig는 그런 장치 없이 구체 타입을 넘기거나 C++ 템플릿처럼 동작하는 제네릭 타입을 넘김
Rust 코드는 타입 시스템 보장이 더 많고, Zig 코드는 읽는 코드의 단순성이 더 크다는 트레이드오프가 있음
Rust는 C++와 비슷한 RAII 스타일로 이어지며, 객체가 다른 객체를 참조하고 참조 수가 0이 되면 자동으로 해체되는 방향이 자연스러움
Zig는 할당자가 훨씬 명시적이며, 참조 카운팅도 가능하지만 해당 코드를 명시적으로 작성해야 함
Zig에서는 애플리케이션에 맞춘 메모리 할당 방식을 자주 쓰며, arena allocator로 할당을 묶고 한 번에 버리거나, 일반 목적 할당자를 객체 지향 접근에 쓰거나, 특정 용도에 맞춘 혼합 방식을 만들 수 있음
CPU가 무엇을 하길 원하는지 생각하고 그대로 실행하게 만드는 코드를 쓰는 방식은 Rust보다 Zig에서 더 자연스럽다고 봄
킬러 기능과 도구 체인
Zig의 킬러 기능은 도구 체인임
시스템 의존성이 없는 소프트웨어 제품군으로, 어떤 운영체제에서 실행하든 동작하고 어떤 운영체제를 대상으로도 코드를 빌드할 수 있음
프로젝트 해킹 난이도는 README에서 시스템 패키지를 많이 설치해야 하는지, 운영체제마다 절차가 다른지, 환경 구성을 위해 명령을 몇 개 실행해야 하는지, Docker나 특정 하드웨어가 필요한지로 판단할 수 있음
최선의 기준은 한 줄, 한 의존성, 모두에게 항상 동작하는 것이며, Zig 프로젝트 README의 빌드 단계는 zig build 하나면 충분해야 함
언어 규칙과 IO 인터페이스
사용하지 않는 변수를 컴파일 오류로 처리하는 규칙은 대규모 리팩터링에서 버그를 잡아 시간을 절약하며, 변수를 버리는 주석을 추가하는 비용은 크지 않다고 봄
ZLS 팀의 에디터 지원 덕분에 설정을 켜면 사용하지 않는 변수를 자동으로 discard하고, 다시 사용하면 discard를 제거할 수 있음
새 IO reader / IO writer 인터페이스는 이미지 로딩 라이브러리나 데이터 포맷 직렬화 코드처럼 재사용 가능한 코드를 한 번 쓰기 위한 추상화임
소비하는 데이터에는 reader, 출력하는 데이터에는 writer를 매개변수로 받아 패키지로 분리하고 여러 애플리케이션에서 같은 로직을 쓰는 것이 목표임
추상화 레이어 아래에서 읽기와 쓰기가 이뤄지면 컴파일러가 로직을 파악해 최적화하기 어려워 성능을 잃을 수 있음
인터페이스 안에 버퍼를 포함시키는 설계가 컴파일러가 좋은 코드를 만들게 하면서 재사용성도 달성하는 최적점이라고 봄
사용 사례, 1.0, LLVM 이후의 방향
실제 사용 사례
Zig는 컴퓨터를 완전히 제어하고, 성능과 메모리 사용을 최대한 끌어내며, 설득력 있는 사용자 경험을 만들고 싶을 때 쓰는 언어로 제시됨
Ghostty는 Mitchell Hashimoto가 만든 터미널 에뮬레이터이며, 코드 품질, 커뮤니티 관리, 퍼즈 테스트 측면에서 좋은 프로젝트로 평가됨
TigerBeetle은 금융 트랜잭션 데이터베이스로, PostgreSQL 같은 관계형 데이터베이스 위에 OLTP를 얹는 전략과 달리 특수 목적 데이터베이스를 만들었고, 그런 전략보다 “천 배 빠르다”고 표현됨
TigerBeetle은 실행 시 앞으로 사용할 모든 메모리를 미리 할당한 뒤 동적 할당을 하지 않아 지연시간을 예측 가능하고 일관되게 유지함
Bun은 JavaScriptCore와 여러 C++ 라이브러리를 쓰는 JavaScript 엔진이며, 접착 코드가 Zig로 작성됨
Bun은 최근 Anthropic에 매각된 것으로 알고 있으며, 그 결과 AI 용도로 Zig를 쓰려는 사람이 많아졌다고 봄
Uber는 Go 코드가 의존하는 C 코드를 함께 크로스 컴파일하기 위해 Zigcc를 C 컴파일러로 사용하고, ARM64 대상 빌드에 활용함
1.0이 늦어지는 이유
Zig는 10년이 지나도 1.0이 없지만, 1.0은 본질적으로 하위 호환성 약속이며 프로젝트마다 의미가 다르다고 봄
Go는 1.0 이후 오랫동안 언어를 건드리지 않았고, Rust는 1.0을 비교적 일찍 달았지만 에디션을 통해 하위 호환성을 유지하면서도 언어를 꽤 바꿀 수 있었다고 비교함
Zig Software Foundation은 스타트업이 아니라 501(c)(3) 비영리단체라 투자자 압박, 매각, 엑시트 계획이 없고 장기적으로 개선할 시간이 있음
1.0을 찍을 때는 서둘러 잠근 나쁜 결정에 갇히지 않는 “타협 없는 애정의 산물”이 되길 원함
“worse is better”에 대해서는 표현 자체가 언어적으로 말이 안 된다고 보고, Zig는 more with less를 추구함
적은 복잡도의 comptime 기능에서 큰 효용을 얻고, 하나의 플래그로 완전히 다른 운영체제와 아키텍처를 대상으로 컴파일할 수 있는 도구 체인을 지향함
1.0이 나오면 채택이 급증할 것은 확실하다고 보지만, 목표는 향후 50년을 위한 언어를 만드는 것임
upcoming 0.16 릴리스에서 이런 선택의 성과가 보이기 시작할 것으로 봄
LLVM에서 벗어나는 이유
LLVM에서 벗어나는 이유는 핵심 제품에 대한 핵심 의존성을 피해야 한다는 판단 때문임
10인 경쟁 아케이드 게임 Killer Queen에서 개발자가 물리 엔진에 Unity를 사용해, 물리 엔진의 작은 변경이나 버그 수정만으로도 경쟁 플레이 감각이 달라져 새 Unity 버전으로 업데이트할 수 없게 된 상황을 예로 듦
핵심 제품에 대한 의존성을 둔 것이 실수였다고 보고, Zig도 LLVM과 관련해 이를 바로잡는 과정이라고 봄
LLVM은 “자전거 보조바퀴”처럼 비유되며, Zig를 10년 넘게 만들며 컴파일러 개발을 더 많이 알게 됐고 이제 보조바퀴를 떼고 LLVM과 경쟁할 수 있다고 봄
자체 x86 백엔드에서는 대규모 백만 줄 코드베이스에서도 변경 후 50ms 이하로 새 바이너리를 얻는 증분 컴파일이 가능함
이름과 학습 경로
Zig라는 이름은 “Zig programming language” 검색 결과가 0개인 짧은 단어를 찾다가 Python 스크립트로 임의 단어를 출력하던 중 선택한 이름임
마스코트 이구아나는 “ziguana”라고 불림
초보자에게는 Ziglings를 강하게 추천함
Ziglings는 거의 작동하는 코드에 문제가 들어 있고, 고장 난 프로그램을 고치며 새 언어 기능을 배우는 일련의 연습으로 구성됨
C에서 Zig로의 전환은 특히 매끄럽고, C에서 할 수 있는 모든 것을 Zig에서도 할 수 있으며 footgun이 더 적음
C에서 segmentation fault가 나면 보통 “segmentation fault” 외에는 출력이 없고 디버거 사용 능력에 의존해야 하지만, Zig에서는 각 코드 줄을 가리키는 전체 스택 트레이스를 받을 수 있음
Zig를 첫 프로그래밍 언어로 배울지는 사람에 따라 다르지만, 컴퓨터가 어떻게 작동하는지 배우려는 사람에게는 CPU와 메모리를 배우게 해주는 좋은 언어라고 봄
재단 운영, 거버넌스, 플랫폼 선택
재정과 후원 구조
2024년 Zig Software Foundation의 총수입은 67만 달러임
수입원은 개인 후원자와 여러 회사의 기부로 다양하며, 단일 주체가 개발 방향을 강제할 수 없는 구조임
특정 후원자가 “이걸 하라”고 요구하면 거절할 수 있고, 그 후원자가 돈을 끊어도 생존할 수 있다고 봄
후원자는 버그 트래커 참여, 풀 리퀘스트 제출, 개발 채널 대화처럼 다른 사람과 같은 방식으로만 영향을 줄 수 있으며, 별도의 비밀 고우선순위 채널은 없음
Andrew Kelley의 연봉은 15만 4천 달러이며, 첫 이사회에서 비영리단체가 설립된 도시의 시니어 소프트웨어 엔지니어 중간 연봉을 기준으로 정했다고 함
재단에는 직원 1명과 전일제로 보수를 받는 계약자 약 5명이 있으며, 전년도 수입의 91% 가 프로젝트 작업을 하는 계약자에게 지급됨
조건 없는 1억 달러 제안에는 받을 수는 있지만 성장에 쓰지 않고 은행에 넣어 100년 동안 모금하지 않아도 되게 할 것이라고 답함
현재 5명 팀을 관리하고 있으며, 10명을 넘기면 부담이 클 수 있고 100명 조직의 관리자가 될 생각은 없다고 밝힘
501(c)(3)와 투명성
501(c)(3) 는 501(c)(6)와 다르다고 구분함
501(c)(6)는 비즈니스 리그이며, Rust Foundation은 Amazon, Netflix, Microsoft, Meta 같은 회사들이 Rust 성공에 공동 이해관계를 갖고 기부하는 형태로 언급됨
501(c)(3)는 정부 로비가 허용되지 않고, 사업자들의 이해관계가 아니라 미션 선언문만을 위해 존재함
수입과 지출을 상세히 공개하는 블로그 글은 의무가 아니라 자발적 투명성이며, 지표가 좋기 때문에 신뢰와 모금에도 도움이 된다고 봄
GitHub와 소셜미디어를 떠난 이유
Reddit과 Twitter를 떠난 이유는 해당 사이트에 글을 올리는 것이 Slashdot이나 Digg에 올리는 것처럼 점점 관련성이 낮아졌고, 소프트웨어 엔지니어로서 마케팅에 쓰는 시간을 최소화하고 싶었기 때문임
알고리듬이 무엇이 보이는지 통제하거나 트롤과 상호작용하는 소셜미디어보다, 대면 행사와 meetup에 더 집중하는 것이 커뮤니티 성장에 더 나은 투자라고 봄
2025년 말 Zig의 메인 저장소를 GitHub에서 Codeberg로 옮긴 이유는 GitHub가 지속적 통합 결과를 더 이상 제대로 제공하지 않아 “그냥 작동하지 않았기” 때문임
Codeberg로 옮긴 뒤 지속적 통합 서버가 다시 작동하게 됨
GitHub Sponsors를 떠나는 것은 수입원을 잃을 수 있어 어려운 선택이었지만, 소프트웨어를 작성하려면 CI가 동작하는 것이 최우선이라고 판단함
GitHub를 떠난 뒤 재정적으로는 “완전히 괜찮다”고 표현함
Zig는 MIT 라이선스 소프트웨어로, 소프트웨어 세계에 조건 없는 기부이며 후원도 조건 없는 기부라고 봄
Codeberg를 택한 이유는 GitHub와 본질적으로 유사해 전환이 쉬웠고, 독일 비영리단체이기 때문임
코드 포지는 프로젝트의 마케팅 수단이 아니며, 사람들은 GitHub나 Codeberg가 아니라 발표, meetup, YouTube 영상, Zigday meetup 그룹 같은 곳에서 언어를 발견한다고 봄
BDFL과 장기 거버넌스
소프트웨어 프로젝트는 계층적 통제와 민주적 절차 중 하나를 선택해야 하는 경우가 많고, 많은 프로젝트가 단순함 때문에 BDFL 방식을 택함
한 사람이 통제하면 그 사람은 모든 것을 이해하고 프로젝트에 대한 일관된 비전을 가져야 하는 책임을 짐
위원회에서는 서로 다른 유효한 사용 사례와 비전이 충돌할 수 있고, 두 사용 사례를 동시에 만족하는 단일 설계가 없을 때 타협이 더 나쁜 제품으로 이어질 수 있음
Andrew Kelley가 떠나도 소프트웨어 엔지니어링 관점에서는 동료들이 매우 유능해 프로젝트 운영을 이어갈 수 있다고 봄
조직과 재단의 정치적 관점에서는 아직 해야 할 일이 남아 있으며, 돈이 흐르는 시스템은 부패한다는 관점에서 돈의 영향에 저항하려는 강한 계층적 리더십이 현재는 필요하다고 봄
한 명의 강한 리더가 모든 것을 통제하는 방식은 지속 가능하지 않으므로, 장기 지속 가능성을 위해서는 민주주의가 필요하지만 돈의 영향으로 시간이 지나며 부패하지 않도록 설계하는 것이 과제임
성공 기준
Zig의 성공은 한 관점에서는 이미 달성됨
다양한 수입원이 있어 단일 주체로부터 재정적으로 독립되어 있고, 만족하며 계속 사용하는 사용자들이 있으며, 매년 약 두 번 릴리스하며 지속적으로 개선하고 있음
다른 관점에서는 더 많은 채택을 원하며, 성공의 한 측정 기준은 Go와 Rust 수준의 채택임
상업적 채택은 기업 기부를 받을 수 있어 유용하지만, 기업 기부도 다양성을 유지하도록 조심해야 함
일반적으로 유용한 것을 만들면 기업에도 유용해지고, 사람들이 Zig를 AI에 쓰는 모습에서도 그 점이 드러난다고 봄
AI 정책, 개발 도구, 프로그래밍의 미래
no LLM, no AI 기여 정책
Zig는 이슈와 풀 리퀘스트에 대해 엄격한 no LLM, no AI 정책을 둠
AI 기여는 “변함없이 쓰레기”이며 가치가 없을 뿐 아니라 리뷰 시간을 빼앗아 음의 가치를 만든다고 봄
현재 열린 풀 리퀘스트가 200개 이상이고, 작은 개발팀과 많은 기여자 사이에서 리뷰 시간이 병목임
AI로 만든 기여는 몇 차례 리뷰 뒤 기여자가 내용을 이해하지 못하고, 리뷰 피드백을 채팅에 붙여넣은 뒤 다시 돌려받은 답을 자기 말처럼 세탁하는 패턴이 드러난다고 봄
코드 리뷰와 기여를 받는 핵심 이유는 멘토십이며, 기여자가 나중에 핵심 팀원이 되거나 더 가치 있는 기여자가 되도록 성장시키는 것이 목표임
“contributor poker”는 제한된 시간을 누구에게 투자해 더 나은 프로그래머와 기여자로 만들지 판단하는 과정임
AI를 쓰는 사람은 항상 투자 가치가 낮은 일회성 기여자 범주에 속하며 배우지도 않고 핵심 팀이 될 가능성도 없다고 봄
Zig 프로젝트는 교육 프로젝트이기도 하며, 학생에게 지도와 교육을 제공하는 것이 미션의 일부임
“좋은 AI PR만 허용”하면 판단자가 필요하지만, 전면 금지는 집행하기 쉬운 정책임
AI 생성 여부 탐지는 항상 쉽지는 않으며 일부는 들어왔을 수 있다고 인정하지만, 많은 풀 리퀘스트를 리뷰하다 보면 피드백을 받았을 때 인간이 보이는 행동이 아니라는 점에서 명확해지는 경우가 있음
MIT 라이선스와 AI 학습
Zig 코드베이스는 MIT 라이선스이며, 소프트웨어 라이선스에 익숙하지 않은 사람에게는 사실상 퍼블릭 도메인에 가까움
거의 모든 용도로 쓸 수 있고, 코드를 복사할 때 라이선스를 재현해야 하며, 보증이 없고 문제에 대해 Zig 쪽에 책임을 물을 수 없음
대기업이 Zig 코드를 AI 학습에 쓰는 것은 가능하지만, Zig에 AI가 기여하는 것은 금지하는 점은 아이러니함
Zig가 세계에 주는 조건 없는 선물이라는 생각을 확고히 갖고 있어 AI 학습에 사용해도 괜찮다고 봄
LLM이 Python이나 JavaScript보다 Zig 코드에서 더 어려움을 겪는지는 직접 많이 시도하지 않았지만, Mitchell Hashimoto는 Ghostty에서 AI 코딩을 광범위하게 사용한다고 함
Rocker라는 화면 이름의 인물은 Zig에서 AI가 더 잘 작동하게 하는 도구를 만들었고 성공을 봤다고 함
바이브 코딩과 프로그래밍의 미래
프로젝트를 오래 수행하며 기술을 익히고 문제를 해결한 내용을 읽는 것은 상상력을 자극하고, 스스로 무엇을 만들 수 있을지 생각하게 하며, 뭔가를 가르치고 감정적으로 연결됨
“Claude의 이 버전이나 OpenAI의 저 버전을 써봤더니 놀랄 만큼 잘 됐다”는 식의 바이브 코딩 블로그는 영감을 주지 않는다고 봄
소프트웨어 품질 기준은 “버그가 없어서 놀랍다”가 아니라 타협 없는 완벽함이어야 한다고 강조함
Richard Feldman과의 비공개 통화에서 바이브 코딩을 시도해봤고, 기술 자체는 근본적으로 흥미롭다고 봄
다만 약 네 개 회사가 중앙에서 통제하고, 모델과 동작에 대해 완전한 통제권을 갖는 점에 강한 거부감을 느낌
자기 컴퓨터와 전기를 써서 코드를 작성하는 방식에서, 네트워크 너머 다른 사람의 컴퓨터에서 폐쇄 소스 프로그래밍을 월 구독으로 쓰는 방식으로 넘어가고 싶지 않다고 함
어떤 사람은 월 300달러를 내고 있으며, 이런 제안은 본인에게 미친 일처럼 보인다고 표현함
10년, 20년 뒤에도 인간은 코드를 계속 쓸 것이며, 코딩은 재미있고 최소한 취미로는 항상 남을 것이라고 봄
휴대폰과 컴퓨터에서 가장 좋은 앱은 사람들이 여가 시간에 취미로 만든 앱이고, 자유·오픈소스 소프트웨어와 자기 장치의 주인이 되고 싶은 욕구는 사라지지 않을 것이라고 봄
편집 환경과 리팩터링 도구
Zig의 문법이 바뀌어도 코드를 계속 편집할 수 있는 회복력 있는 작업 환경이 필요함
tree-sitter, 언어 서버 같은 고급 도구는 안정적인 구문 트리나 안정적인 언어를 전제로 하기 때문에 언어가 깨지면 함께 깨질 수 있음
개인적으로 Zig를 작성할 때는 고도화된 환경보다 터미널과 Vim을 사용하며, Vim은 변화에 매우 잘 견딤
ZLS는 Zig language server의 약자로, Zig를 위한 Language Server Protocol 구현체이며, Zig Software Foundation이 운영하지 않는 제3자 프로젝트임
Zig 웹사이트가 JetBrains 제품을 추천하지만, Andrew Kelley는 JetBrains 제품이 닫힌 소스라서 사용해 본 적이 없음
과거 JetBrains나 Eclipse가 제공하던 함수 추출, 함수 매개변수 재정렬, 전역 이름 변경 같은 고수준 리팩터링 도구를 좋게 봤음
장기적으로는 타입 정보와 다른 단서를 기반으로 큰 변경을 수행하는 질의 언어 같은 리팩터링 도구를 원함
변수 이름 변경처럼 범위가 명확한 작업은 신뢰할 수 있는 도구가 처리하면 커밋을 만들고 검토하지 않아도 될 정도로 결과를 100% 확신할 수 있음
같은 작업을 AI 도구에 요청하면 여전히 코드를 검토해야 하므로, 신뢰 가능한 리팩터링 도구보다 더 오래 걸리고 더 나쁜 선택이 됨
개인 동기와 오픈소스 관점
Zig를 계속하는 동기와 어려움
Zig 작업은 컴퓨터를 사랑하고 컴퓨터가 사람을 섬기게 만들고 싶다는 동기에서 나옴
Zig는 훌륭한 프로그래밍 언어와 툴체인이 그런 결과로 이어질 것이라는 낙관적 선물로 표현됨
사용자를 만족시키고 강력한 사용자 경험을 만드는 일이 큰 만족을 주며, 좋은 소프트웨어를 만드는 감각을 음악가가 무대에서 공연할 때 얻는 감각에 비유함
비영리단체 운영에 필요한 세금과 서류 작업이 가장 힘든 부분으로 꼽힘
법적으로 문제없이 운영하고 큰 기부를 받기 위해 반드시 필요하지만, 현재 그 일을 Andrew Kelley가 맡고 있음
어떤 날은 회계 업무를 하고, 어떤 날은 프로그래밍을 하며, 프로그래밍하는 날을 좋은 날로 봄
Zig 0.15의 IO reader / IO writer 인터페이스 변경은 최적점을 찾고 API를 만들고 테스트하고 다른 프로그래밍 언어와 비교해 새로운 해법을 찾은 결과였지만, 이후 6개월 동안 표준 라이브러리와 생태계 프로젝트를 고쳐야 했음
번아웃과 조언
번아웃은 많은 노력을 들이지만 그 노력에 대한 보상을 많이 보지 못할 때 생긴다고 봄
Andrew Kelley는 많은 노력을 들이지만 행복한 사용자, Zig 릴리스, 릴리스 노트, 개선 사항 같은 보상을 보기 때문에 대체로 번아웃에서 보호받고 있음
IO 변경처럼 보상이 여러 달 지연되는 작업은 번아웃처럼 느껴질 수 있지만, 결국 보상이 오면 나아짐
번아웃을 겪는 사람에게는 먼저 운동, 충분한 수면, 건강한 식사를 챙기라고 권함
하는 일이 싫거나 회사가 세상에 가치 있는 일을 하지 않는다고 느끼는데 열심히 일해야 한다면 번아웃의 조건이 됨
그 경우 다른 직장을 찾거나 창업처럼 자기 일을 만드는 어려운 길이 하나의 선택지이며, “영혼 없는 기업”에서 일한다면 오후 5시에 집에 가서 다른 일을 하고 너무 열심히 하지 말라고 조언함
존경하는 프로젝트와 브라우저 다양성
존경하는 프로젝트 첫 번째로 Linux가 꼽힘
독점 운영체제만 있는 세상은 훨씬 나쁠 것이며, Linux는 자유·오픈소스 개발자뿐 아니라 전 세계 국가와 기업이 무료로 사업을 구축할 수 있게 해 경제에도 좋았다고 평가함
두 번째는 Blender이며, 전문적으로 쓰이고 많은 돈과 개발 인력을 가진 회사들과 경쟁하면서도 이기고 있는 오픈소스 프로젝트이자 비영리단체라는 점을 높게 평가함
세 번째는 VLC이며, 예전에 FFmpeg에 기여했을 때 VLC나 의존 라이브러리에 기여한 사람의 VideoLAN Dev Days 여행 비용을 VLC 조직이 부담했다고 회상함
Firefox를 사용하는 이유는 브라우저 다양성에 대한 우려 때문임
Microsoft가 Internet Explorer를 종료한 뒤 남은 주요 브라우저는 Chromium, Safari, Firefox뿐이고, Chromium이 시장 대부분을 차지하는 것은 웹에 문제가 된다고 봄
최근 Mozilla에는 만족하지 못하며, 비영리단체임에도 부패가 많고 사용자와의 정렬이 맞지 않는 사례처럼 느껴진다고 표현함
Chromium은 Google, Safari는 Apple, Firefox는 하락세로 보여 대안이 부족하고, 새 브라우저 프로젝트들이 성숙하기 전까지 무엇을 해야 할지 모르겠다고 봄
2015년으로 돌아가도 Zig를 시작할지
2015년으로 돌아가도 반드시 Zig를 시작한다고 답함
OkCupid를 그만두고 Zig를 풀타임으로 시작한 날은 이후 삶의 궤적을 기준으로 인생 최고의 날이었음
Zig는 깊은 충족감, 독립성, 자기 가치감, 사회에 기여한다는 감각을 줬음
자신은 기본적으로 고용되기 어려운 사람이라고 느끼며, 행복해지기 위해서는 자기 자신의 보스가 되어야 했고, 그 상태가 된 뒤 행복을 얻었음
Zig Software Foundation 밖의 사람들도 Andrew와 핵심 팀이 프로젝트를 앞으로 밀고 나갈 때 가진 열정과 철학을 알아줬으면 함
JetBrains가 인터뷰를 더 자극적으로 만들어 바이럴을 노린 건 탓할 수 없지만, 결과적으로 최고의 질문은 Zig 대 Rust가 아니라 비영리, 지속 가능성, 애정으로 만드는 Zig에 관한 질문들이었음
Andrew가 프로젝트 뒤에서 조용히 타오르는 인간적인 면을 세상에 잘 보여줬다고 봄
솔직히 JetBrains가 딱히 자극적인 방향으로 몰아간 것 같지도 않음
영상은 Zig를 꽤 써본 사람보다 Zig가 궁금한 사람들과 프로젝트 운영에 관심 있는 사람들을 훨씬 더 겨냥한 듯하고, 그 청중이 알고 있을 만한 주제를 피하지 않고 꺼냈을 뿐임
인터뷰어도 불을 지피기보다 Andrew의 말이 스스로 드러나게 뒀고, 이런 형식의 인터뷰치고는 매우 사려 깊었음
다만 자막으로 넣기로 한 단어들을 보며 웃긴 했는데, Zig에는 관심이 있지만 Linux나 추상화의 정의를 모르는 사람이 얼마나 있을지는 모르겠음
전반적으로 Zig를 보여주는 방식으로도, JetBrains 마케팅 팀에 대한 인상으로도 굉장히 긍정적이었음
Andrew가 중간쯤에서 Zig와 AI 사용을 돕기 위해 내가 만든 도구를 언급했는데, 써보고 싶은 사람을 위해 말하면 그 도구는 zigdoc임: github.com/rockorager/zigdoc
기본적으로 Zig 표준 라이브러리와 빌드 그래프에서 발견된 의존성의 문서를 명령줄에서 보는 도구임
영상 마지막 몇 초에 Andrew가 행복하다고 말하는 부분이 정말 좋았음
“타협 없는 애정 노동”이라는 표현이 맞음 1.0을 서두르지 않는 프레이밍이 매력적이지만, Zig는 생태계 변화의 흔들림을 감수해 주는 사용자들이 있어서 운이 좋은 편임
임베디드 쪽에서는 몇 년 동안 C가 주력 도구였음
C++가 아니라 그냥 C였음
다음 임베디드 프로젝트를 Zig로 할지 Rust로 할지 계속 고민 중이었는데, 이제 “때가 왔다”는 느낌이 듦
이 인터뷰가 내게는 결정적인 계기가 될 수도 있고, 여기에는 강하게 공감되는 전체적인 결이 있음
Zig가 LLVM에서 벗어나려는 이유에 대한 답변이 정말 좋았음
Zig의 핵심 기능에 해당해서 팀이 더 많은 통제권을 가져야 하는 부분을 잘 다뤘음