Zig 창시자가 말한 시스템 언어의 방향

Zig 창시자가 말한 시스템 언어의 방향

AI 뉴스 썸네일

Zig 창시자 Andrew Kelley가 JetBrains 인터뷰에서 언어 설계, 재단 운영, AI 기여 정책을 길게 설명했어요. 이 인터뷰는 Zig가 단순히 C 대체 언어를 노리는 게 아니라, 빌드 도구와 커뮤니티 운영까지 한 묶음으로 다시 설계하려는 프로젝트라는 점을 보여줘요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
언어 설계	Zig는 C의 성능과 제어력을 유지하면서 메모리 오류와 디버깅 부담을 줄이려 해요	Rust와 다른 선택지를 찾는 시스템 개발자에게 비교 기준이 돼요
도구 체인	`zig build` 하나로 여러 운영체제와 아키텍처를 겨냥하는 빌드 경험을 강조해요	언어 자체보다 빌드·배포 경험이 채택을 좌우할 수 있다는 점을 보여줘요
1.0 전략	하위 호환성을 서둘러 약속하지 않고 긴 호흡으로 안정화를 택했어요	빠른 채택보다 오래 쓸 수 있는 기반을 우선하는 오픈소스 전략이에요
재단 운영	501(c)(3) 비영리 구조와 다양한 후원으로 단일 기업 의존을 낮추려 해요	언어 생태계가 기업 후원과 독립성 사이에서 어떤 균형을 잡는지 볼 수 있어요
AI 정책	이슈와 풀 리퀘스트에 no LLM, no AI 정책을 적용해요	AI 코딩 시대에 리뷰 시간과 멘토십을 어떻게 지킬지 묻는 사례예요

1. Zig는 C를 버리는 대신 C의 거친 부분을 덜어내려 해요

Andrew Kelley가 Zig를 설명할 때 가장 많이 붙잡는 기준은 “컴퓨터가 실제로 할 수 있는 일을 가리지 않는 언어”예요. Zig는 C처럼 CPU와 메모리를 직접 의식하게 두되, 정수 오버플로 처리나 스택 트레이스 같은 디버깅 경험을 더 명확하게 만들려 해요. 그래서 Rust처럼 강한 타입 시스템으로 안전성을 크게 끌어올리는 길과는 다른 방향을 택해요. 읽는 코드가 단순하고, 할당자와 메모리 수명을 개발자가 직접 드러내는 쪽에 무게를 둬요. 2

이 지점이 흥미로워요. 요즘 시스템 언어 논의는 대개 “C의 위험을 얼마나 자동으로 막을 수 있나”에 쏠려 있어요. Zig는 자동화보다 명시성을 더 믿어요. 개발자가 하드웨어와 실행 비용을 의식해야 하는 운영체제, 임베디드, 게임, WebAssembly 같은 영역에서는 이런 태도가 여전히 설득력을 가져요. 1

2. 진짜 승부처는 언어 문법보다 툴체인이에요

인터뷰에서 가장 또렷한 차별점은 도구 체인이에요. Kelley는 좋은 프로젝트라면 운영체제마다 다른 패키지를 설치하거나 Docker 환경을 맞추지 않아도, `zig build` 한 줄로 빌드돼야 한다고 말해요. 어느 OS에서 실행하든 다른 OS를 대상으로 빌드할 수 있는 경험을 목표로 잡고 있어요. 1

이건 개발자 경험 문제이면서 배포 전략 문제예요. 언어가 좋아도 빌드가 까다로우면 새 기여자가 들어오기 어려워요. 반대로 첫 빌드가 쉬우면 라이브러리 작성자와 애플리케이션 개발자가 같은 도구 위에서 움직일 수 있어요. Zig가 C 컴파일러처럼 쓰이는 Zigcc 사례나, Go 코드의 C 의존성을 크로스 컴파일하는 Uber 사례가 여기와 이어져요. 2

3. 1.0을 늦추는 이유는 하위 호환성 때문이에요

Zig는 오래 개발됐지만 아직 1.0을 붙이지 않았어요. Kelley는 1.0을 기능 완성의 숫자가 아니라 하위 호환성 약속으로 봐요. 한 번 약속하면 언어와 표준 라이브러리의 나쁜 결정을 오랫동안 끌고 가야 할 수 있어요. 그래서 빠른 채택보다 나중에 후회할 설계를 줄이는 데 시간을 쓰는 쪽을 택했어요. 1

이 선택은 스타트업식 성장 논리와 거리가 있어요. Zig Software Foundation은 501(c)(3) 비영리단체라 투자자 압박이나 매각 목표가 없어요. 2024년 총수입은 67만 달러였고, 여러 후원자와 기업 기부가 섞여 있어 특정 후원자가 방향을 강제하기 어렵다고 설명해요. 언어 생태계에서 “누가 돈을 내고, 누가 방향을 정하나”는 생각보다 큰 문제예요. Zig는 이 질문을 꽤 노골적으로 다루고 있어요. 1

4. GitHub를 떠난 이유도 개발 경험에 가까워요

Zig 메인 저장소는 GitHub에서 Codeberg로 옮겨졌어요. 이유는 정치적 선언보다 실용에 가까워요. Kelley는 지속적 통합 결과가 제대로 동작하지 않는 상황에서, 소프트웨어를 쓰려면 CI가 작동하는 게 먼저였다고 말해요. Codeberg는 독일 비영리단체가 운영하고, GitHub와 사용 경험이 비슷해 옮기기 쉬운 선택지였어요. 1

오픈소스 프로젝트에서 코드 포지는 단순한 저장소가 아니에요. 이슈, 리뷰, 릴리스, 후원, 커뮤니티 유입이 한곳에 묶여 있어요. 그래도 Zig는 마케팅보다 빌드와 CI를 우선했어요. 프로젝트를 발견하는 통로는 발표, 밋업, 영상 같은 곳에도 충분히 있고, 코드를 관리하는 장소는 개발이 잘 굴러가는 쪽이어야 한다는 판단이에요. 2

5. no LLM 정책은 AI 반대보다 리뷰 시간 보호에 가까워요

Zig는 이슈와 풀 리퀘스트에 no LLM, no AI 정책을 둬요. Kelley의 핵심 논리는 AI 기여가 “코드 한 조각”만의 문제가 아니라는 점이에요. 작은 팀이 200개 넘는 풀 리퀘스트를 검토할 때, 기여자가 코드를 이해하지 못하면 리뷰 시간이 빠르게 소진돼요. 리뷰는 버그를 잡는 절차이기도 하지만, 기여자를 더 나은 개발자로 키우는 멘토십이기도 해요. 1

이 대목은 AI 코딩 도구를 쓰는 팀에도 꽤 현실적인 질문을 던져요. 생성된 코드가 맞는지보다, 그 코드를 낸 사람이 피드백을 이해하고 다음 기여에서 나아질 수 있는지가 중요할 때가 있어요. Zig의 전면 금지는 거칠어 보이지만, 작은 유지보수 팀이 리뷰 병목을 줄이기 위해 택한 운영 규칙으로 읽을 수 있어요. 2

왜 중요한가요

Zig 인터뷰가 볼 만한 이유는 언어 기능 소개를 넘어 오픈소스 운영의 현실을 함께 보여주기 때문이에요. 시스템 언어는 성능, 안정성, 빌드 경험, 커뮤니티 신뢰가 따로 움직이지 않아요. `zig build` 같은 도구 체인 선택은 새 기여자의 진입 장벽을 낮추고, 1.0 지연은 장기 호환성 약속을 신중하게 다루는 방식이에요. 1

AI 기여 정책도 같은 맥락에 있어요. AI 도구가 코드를 더 많이 만들수록, 유지보수자는 “누가 이 코드를 이해하고 책임질 수 있나”를 더 자주 묻게 돼요. Zig의 답이 모든 프로젝트에 맞지는 않아요. 그래도 작은 팀이 리뷰 시간과 학습 문화를 지키기 위해 어떤 선을 그을 수 있는지 보여주는 사례예요. 2

참고 자료

1. Zig 창시자 Andrew Kelley와의 인터뷰 — GeekNews
2. Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn’t 1.0 - Andrew Kelley Explains — JetBrains YouTube