# Zig 창시자 Andrew Kelley와의 인터뷰 > Clean Markdown view of GeekNews topic #29949. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29949](https://news.hada.io/topic?id=29949) - GeekNews Markdown: [https://news.hada.io/topic/29949.md](https://news.hada.io/topic/29949.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-28T15:09:40+09:00 - Updated: 2026-05-28T15:09:40+09:00 - Original source: [youtube.com](https://www.youtube.com/watch?v=iqddnwKF8HQ) - Points: 2 - Comments: 1 ## Topic Body - **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는 깊은 충족감, 독립성, 자기 가치감, 사회에 기여한다는 감각을 줬음 - 자신은 기본적으로 고용되기 어려운 사람이라고 느끼며, 행복해지기 위해서는 자기 자신의 보스가 되어야 했고, 그 상태가 된 뒤 행복을 얻었음 ## Comments ### Comment 58444 - Author: neo - Created: 2026-05-28T15:09:41+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/yjwa9q/interview_with_zig_creator_andrew_kelley) - 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의 핵심 기능에 해당해서 팀이 더 많은 통제권을 가져야 하는 부분을 잘 다뤘음