# Zig – io_uring 및 Grand Central Dispatch std.Io 구현 추가 > Clean Markdown view of GeekNews topic #26700. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26700](https://news.hada.io/topic?id=26700) - GeekNews Markdown: [https://news.hada.io/topic/26700.md](https://news.hada.io/topic/26700.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-15T09:49:07+09:00 - Updated: 2026-02-15T09:49:07+09:00 - Original source: [ziglang.org](https://ziglang.org/devlog/2026/#2026-02-13) - Points: 2 - Comments: 1 ## Topic Body - Zig 표준 라이브러리의 **`std.Io.Evented`** 모듈에 **io_uring**과 **Grand Central Dispatch(GCD)** 기반 구현이 새로 통합됨 - 두 구현 모두 **사용자 공간 스택 전환(fibers, stackful coroutines, green threads)** 방식으로 동작 - 현재는 **실험적 단계**로, 오류 처리 개선·로깅 제거·성능 저하 원인 분석·테스트 보강 등의 후속 작업이 필요함 - 동일한 애플리케이션 코드에서 **I/O 백엔드만 교체**해 io_uring 또는 GCD를 손쉽게 전환 가능함 - Zig 컴파일러에서도 두 구현이 동작하며, 향후 안정화 시 **플랫폼별 비동기 I/O 통합 기반**으로 발전 가능성 있음 --- ### io_uring 및 GCD 기반 std.Io.Evented 구현 - Zig 0.16.0 릴리스 주기 말기에 **`std.Io.Evented`** 가 최신 API 변경 사항을 반영해 업데이트됨 - 새로 추가된 구현은 **io_uring**(Linux)과 **Grand Central Dispatch(GCD)** (macOS) - 두 구현 모두 **사용자 공간 스택 전환(fibers, stackful coroutines, green threads)** 기술을 사용 - 두 구현은 현재 **실험적 상태**로, 안정적 사용을 위해 여러 개선 과제가 남아 있음 - **오류 처리 개선** 필요 - **로깅 제거** 및 **성능 저하 원인 진단** 필요 (`IoMode.evented` 사용 시 컴파일러 성능 저하 발생) - 일부 **미구현 함수 존재** 및 **테스트 커버리지 확충 필요** - **함수별 최대 스택 크기 확인용 내장 함수** 추가 필요 (`overcommit` 비활성 시 실용성 확보 목적) ### I/O 구현 교체 예시 - 동일한 애플리케이션 코드에서 **I/O 백엔드만 교체**해 동작 가능함 - 예시 코드에서 `std.Io.Threaded` 대신 `std.Io.Evented`를 사용하면 io_uring 기반으로 실행 - `app` 함수는 동일하며, 출력 결과(`Hello, World!`)도 동일 - `strace` 결과 비교를 통해 두 실행 방식의 차이를 확인 가능 - `hello_threaded`는 일반 스레드 기반 I/O 호출 - `hello_evented`는 **io_uring 시스템 호출(io_uring_setup, io_uring_enter 등)** 을 사용 ### Zig 컴파일러 적용 및 현황 - Zig 컴파일러 자체도 **`std.Io.Evented`** 를 사용해 정상 동작함 - io_uring 및 GCD 모두에서 컴파일러 실행 가능 - 단, **성능 저하 원인 미확인 상태**로 추가 분석 필요 - 이 변경으로 Zig 코드가 **I/O 구현을 손쉽게 교체할 수 있는 구조**에 근접 - 플랫폼별 비동기 I/O 모델을 통합적으로 다룰 수 있는 기반 마련 ### 향후 과제 - 안정적 사용을 위한 **성능 개선 및 테스트 강화** 필요 - **스택 크기 관리 기능** 추가 시, 오버커밋이 비활성화된 환경에서도 실용적 사용 가능 - 완성 시 Zig의 **비동기 I/O 추상화 계층**이 한층 강화될 전망 ### 결론 - 이번 업데이트는 Zig의 **표준 I/O 시스템 확장**에서 중요한 진전 - io_uring과 GCD를 통합함으로써 **플랫폼 간 비동기 처리 일관성**을 확보할 기반 마련 - 향후 안정화 작업 완료 시, Zig의 **고성능·유연한 I/O 모델** 구현 가능성 확대 ## Comments ### Comment 51193 - Author: neo - Created: 2026-02-15T09:49:07+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47012717) - 나는 Zig 팬은 아니지만, **작은 팀이 꾸준히 발전하는 모습**이 보기 좋음 완성보다는 실험과 점진적 개선을 중시하는 태도가 인상적임 1.0을 서둘러 내는 대신 장기적인 목표를 향해 나아가는 게 더 중요하다고 생각함 한 명 중심의 프로젝트치고는 놀라운 성취이며, 노력하는 사람들에게 정당한 **인정**이 필요함 - 나는 새로운 언어를 배울 때마다 TCP/UDP 멀티플레이 서버가 있는 게임 엔진을 만들어보는데, 최근엔 Zig로 시도했음 지금까지 중 **가장 재미있고 생산적인 경험**이었음 Rust의 엄격한 메모리 관리보다 Zig의 단순함이 훨씬 잘 맞음 인생은 짧고, 나는 그저 빠르고 잘 정리된 소프트웨어를 만들고 싶음 - Zig 관련 글마다 비판이 많지만, 왜 그렇게 신경 쓰는지 모르겠음 Andrew와 팀이 믿는 바를 실현하려는 **엔지니어링 정신**이 오히려 영감을 줌 Zig가 주류가 될지 걱정할 필요 없음, 문제 해결에 도움이 되면 그걸로 충분함 언어를 정체성처럼 대할 필요는 없음 - 이런 현상을 없애려면 프로그래머들이 받는 **경제적 인센티브**를 바꿔야 함 언어와 라이브러리는 곧 ‘팔 수 있는 기술’이기 때문에, 사람들은 자신이 쓰는 도구의 시장성을 의식함 게다가 의사결정권자들이 엔지니어를 교체 가능한 자산으로 보는 경향도 문제임 - 이런 언어 논쟁은 Zig만의 일이 아님 Lisp, Ruby, Rust 등에서도 반복되어 왔고, **정체성 싸움**이 업계의 고질적인 문제임 - 새로운 언어 스택은 리눅스 배포판에서 **유지보수 부담**을 늘림 보안·아키텍처 지원 등 장기 관리가 필요함에도, 개발자들은 그 비용을 간과함 Zig는 아직 안정적이지 않아 특정 버전에서만 패키지가 컴파일됨 다른 언어 개선으로도 해결 가능한 문제를 굳이 새 언어로 풀 필요가 있는지 의문임 - 주류 언어가 되려면 대부분의 사용 사례를 커버할 **예측 가능한 라이브러리 생태계**가 필요함 - Zig가 1.0이 되기 전까지는 따라가 봐야 의미 없다고 느낌 지금 구조는 여러 번 다시 짜일 가능성이 높음 나도 한때 관심 있었지만, 내 생애에 1.0을 볼 수 있을지 모르겠음 - 실제로 Zig의 **호환성 깨짐**은 대부분 표준 라이브러리(stdlib)에서 발생함 파일 입출력 같은 기본 기능은 거의 동일하고, 네임스페이스만 바뀜 나는 ‘살아 있는 언어’가 더 낫다고 생각함 1.x 이후에도 stdlib을 **슬림하게 유지**하기 위해 버전별 인터페이스 관리 전략이 있으면 좋겠음 - Zig 언어 자체는 좋아하지만 stdlib 품질에 의문이 생김 I/O 프레임워크를 직접 만들다 보니 테스트 부족과 **잘못된 어셈블리 코드**를 발견했음 여러 번 지적했지만 수정되지 않아 신뢰가 떨어짐 - 대규모 프로젝트에는 망설여질 수 있지만, **Zig는 이미 비즈니스적으로 가치 있음** 특히 클라우드 환경에서 성능 최적화로 서버 비용을 90% 이상 절감할 수 있음 Python이나 Node로는 한계가 있어 결국 C, C++, Rust, Zig 중 하나로 내려가야 함 그중 Zig는 배우기 쉽고, 읽기·테스트하기 편함 - 참고로 [Bun](https://bun.sh/)도 Zig로 작성되어 있음 이미 실무 수준에서 쓰이고 있는 언어임 - 우리 팀(ZML)은 std.Io 도입 이후 Zig master 브랜치를 계속 따라가고 있음 대부분의 변경이 실제로 **언어 개선**으로 느껴짐 - Rust의 io_uring 지원이 아직 완성되지 않은 상황에서 Zig가 먼저 구현을 시도하는 게 흥미로움 Rust에서는 안전하고 제로코스트인 추상화를 설계하기가 어려움 - 이번 소식은 아직 **미완성 구현**에 대한 것임 예를 들어 GCD 버전에는 네트워킹이 없음 인터페이스가 점점 커지고 있어 완성형이라기보다 현재 스냅샷에 가까움 - 하지만 글의 서두에서 이미 실험적 단계임을 명시했고, 앞으로 해야 할 **6가지 주요 과제**를 구체적으로 나열했음 - 스택 메모리 최적화 관련 [이슈](https://github.com/ziglang/zig/issues/23475#issuecomment-2795855793)가 있음 서로 다른 블록에서 `[500]u8`을 사용해도 스택 프레임에 500바이트만 차지하도록 하는 기능이 필요함 이는 **그린 스레드 코루틴 스택**과 관련해 특히 중요함 - 나는 Zig의 **지속적인 개선 노력**을 긍정적으로 봄 현재 io_uring을 제대로 다루는 언어는 없음 Zig가 이 부분을 잘 해결하면 큰 우위를 점할 것임 안정성보다 학습과 실험을 중시하는 태도가 더 가치 있다고 생각함 - 저수준 언어에서까지 async를 원한다는 게 흥미로움 나는 Zig에서 libxev를 사용해 io_uring을 직접 제어하는 방식을 선호함 - 나도 긍정적이지만, Zig가 C처럼 **장기 안정 버전(LTS)** 을 내놓을 시점이 궁금함 C의 성공 요인은 안정성과 일관된 개발 문화였음 - Zig가 **freestanding 타깃**을 진지하게 다루는 점이 좋음 0.16 버전에서 코드 재사용성이 더 높아질 것으로 기대함 - macOS 내부를 오랜만에 살펴봤는데, GCD를 유지한 게 반가움 병렬화의 **균형 잡힌 접근**이라 생각함 - 다른 언어들이 논쟁만 하는 동안 Zig는 직접 시도하고, 필요하면 되돌림 **실전에서 검증된 API**가 최고의 설계라고 믿음 구버전을 유지할 수도 있고, 최신 버전으로 가면 더 깔끔하고 빠른 도구를 얻을 수 있음 - Jai는 게임 개발 중심이라 범용성이나 **안전성** 측면에서 부족함 C++처럼 복잡하지만 Zig는 C 수준의 단순함을 유지함 Carbon은 아직 실체가 없는 상태임 - Zig가 1.0이 아니라고 비판하는 건 이상함 Jai는 11년째 클로즈드 베타인데, Zig는 이미 여러 **실제 프로젝트**에서 사용 중임 - 언어는 20년이 걸리더라도 제대로 완성되는 게 낫다고 생각함 Python 2→3, Rust async, Go 제네릭, C++ 등에서 본 **무분별한 변화**가 오히려 해로움