Zig 창시자 Andrew Kelley와의 인터뷰

• 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는 깊은 충족감, 독립성, 자기 가치감, 사회에 기여한다는 감각을 줬음
  • 자신은 기본적으로 고용되기 어려운 사람이라고 느끼며, 행복해지기 위해서는 자기 자신의 보스가 되어야 했고, 그 상태가 된 뒤 행복을 얻었음