Zyber는 Ruby 프로젝트에서 오토로딩(Autoloading), 이저 로딩(Eager Loading), 리로딩(Reloading) 기능을 제공하는 Gem으로, Rails의 기존 오토로더가 가졌던 const_missing 기반의 근본적인 한계점을 해결하기 위해 개발되었습니다. 기존 방식은 상수 탐색 과정에서 컨텍스트 정보가 부족하여 예상치 못한 오류를 유발했으며, require 구문 자동화의 필요성 또한 Zyber 개발의 주요 동기가 되었습니다.
Zyber의 핵심 기능인 오토로딩은 require 없이 코드를 사용할 수 있게 하며, 이를 통해 코드 로딩 시점(온디맨드 또는 사전 로딩)을 유연하게 제어할 수 있습니다. 리로딩 기능은 코드 변경 사항을 즉시 반영하여 개발 생산성을 높입니다. Zyber는 2019년 첫 안정 버전을 출시한 이래 Shopify와 GitHub와 같은 대규모 Rails 애플리케이션에 성공적으로 도입되며 그 안정성과 효용성을 입증했습니다. 현재 약 600개 이상의 Gem에서 사용되고 있으며, 하루 약 50만 건 이상의 다운로드를 기록하고 있습니다. Zyber의 설계 목표 중 하나는 ‘투명성’으로, 사용자 코드가 Zyber의 존재를 인식하지 않고도 일반적인 Ruby 프로젝트처럼 작동하도록 하는 것입니다.
연사는 Zyber 개발 경험을 바탕으로 API 설계의 중요성을 강조합니다. 좋은 API는 사용성을 최우선으로 고려하며, 사용자의 실수를 사전에 방지하고, 모범 사례를 자연스럽게 유도해야 한다고 말합니다. 예를 들어, Zyber의 인플렉션(inflection) API는 파일 확장자나 불필요한 경로 정보를 제거하여 사용자가 핵심적인 이름 변환에만 집중하도록 설계되었습니다. 또한, logger 설정과 같이 사용 빈도가 높은 특정 시나리오에는 일반적인 API 외에 간편한 특수 API(loader.log!)를 제공하여 사용 편의성을 높였습니다. 이는 모든 API가 반드시 ‘대칭적’일 필요는 없으며, 사용 사례의 ‘비대칭성’을 인정하고 그에 맞는 인터페이스를 제공하는 것이 중요하다는 철학을 반영합니다.
Ruby에서 ‘공개 인터페이스’의 정의에 대한 논의도 이루어졌습니다. Ruby는 특정 메서드의 가시성(public, private)만 제공할 뿐, 라이브러리 내부에서만 사용되는 ‘내부 API’를 명확히 구분하는 메커니즘이 부족합니다. 연사는 Zyber에서 internal 매크로를 사용하여 내부 메서드를 명시적으로 표시하고, 외부에서 접근 시 경고를 발생시키거나 접근을 어렵게 함으로써 라이브러리 사용자가 의도치 않게 내부 구현에 의존하는 것을 방지하고자 했습니다.
소프트웨어 오류와 관련하여, 연사는 ‘버그는 피할 수 없는 것’이라는 일반적인 인식을 비판하며, 높은 수준의 품질과 ‘버그 없는’ 소프트웨어를 충분히 달성할 수 있음을 강조합니다. TeX, Jeremy Evans, Vladimir Dementyev의 프로젝트, 그리고 Elixir 언어를 예시로 들며, 문제 발생 시 근본 원인을 찾아 철저히 해결하고 이슈 트래커를 비워두는 것이 이상적인 상태라고 역설합니다. 이는 개발자들이 스스로 높은 기준을 설정하고 탁월함을 추구해야 한다는 메시지를 담고 있습니다.
마지막으로, Zyber의 향후 계획으로는 Ruby 3.2에서 도입된 Module#const_added 기능을 활용하여 기존 Zyber가 해결하지 못했던 ‘명시적 네임스페이스’의 특정 엣지 케이스를 완벽하게 처리하는 것을 목표로 합니다. 이를 통해 Zyber는 Ruby의 상수 탐색 방식과 100% 일치하는 오토로딩 기능을 제공하는 ‘미션 컴플리트’ 상태에 도달할 것으로 기대됩니다.