2025년 11월 06일·6분
Zig가 더 간단한 시스템 프로그래밍 선택지로 떠오르는 이유
간단한 언어 설계, 실용적 도구, 우수한 C 상호운용성, 쉬운 크로스컴파일 등으로 Zig가 저수준 시스템 작업에서 주목받는 이유를 살펴봅니다.
간단한 언어 설계, 실용적 도구, 우수한 C 상호운용성, 쉬운 크로스컴파일 등으로 Zig가 저수준 시스템 작업에서 주목받는 이유를 살펴봅니다.
저수준 시스템 프로그래밍은 코드가 기계에 가까이 머무르는 작업입니다: 메모리를 직접 관리하고 바이트 배치를 신경 쓰며, 운영체제나 하드웨어, C 라이브러리와 직접 상호작용하는 일이 많습니다. 전형적인 예로는 임베디드 펌웨어, 장치 드라이버, 게임 엔진, 높은 성능이 요구되는 커맨드라인 도구, 그리고 다른 소프트웨어가 의존하는 기초 라이브러리가 있습니다.
“간단한”은 “기능이 적다”거나 “초보용”이라는 뜻이 아닙니다. 대신 작성한 코드와 프로그램이 실제로 하는 일 사이에 숨겨진 규칙이 적고, 중간 레이어가 적다는 의미입니다.
Zig에서 ‘간단한 대안’은 보통 세 가지를 가리킵니다:
시스템 프로젝트는 종종 “우발적 복잡성”을 쌓습니다: 빌드가 깨지기 쉽고, 플랫폼 차이가 늘어나며, 디버깅이 고고학처럼 느껴집니다. 도구체인이 단순하고 언어 동작이 예측 가능하면, 수년간 소프트웨어를 유지하는 비용을 크게 줄일 수 있습니다.
Zig는 그린필드 유틸리티, 성능 민감 라이브러리, 깔끔한 C 상호운용성이나 신뢰할 수 있는 크로스컴파일이 필요한 프로젝트에 잘 맞습니다.
반면 고수준 라이브러리 생태계가 매우 성숙하거나 안정된 릴리스 역사가 필요하거나, 팀이 이미 Rust/C++ 도구와 패턴에 깊이 투자되어 있다면 항상 최선은 아닙니다. Zig의 매력은 의도와 제어의 명확성—필요 이상의 절차 없이 얻을 수 있다는 점입니다.
Zig는 2010년대 중반 Andrew Kelley가 만든 비교적 젊은 시스템 프로그래밍 언어로, 실용적인 목표를 가졌습니다: 저수준 프로그래밍을 더 간단하고 직관적으로 느끼게 하되 성능을 포기하지 않기. C와 유사한 느낌(명확한 제어 흐름, 메모리 직접 접근, 예측 가능한 데이터 레이아웃)을 차용하되, C와 C++ 주변에 쌓인 우발적 복잡성을 제거하려 합니다.
Zig의 설계는 명시성과 예측 가능성에 중심을 둡니다. 비용을 추상화 뒤에 숨기지 않고, 코드를 읽으면 무엇이 일어날지 알 수 있게 장려합니다:
이것은 Zig가 “저수준 전용”이라는 뜻이 아닙니다. 대신 저수준 작업을 덜 깨지기 쉽게 만들려는 시도입니다: 의도가 더 명확하고 암묵적 변환이 적으며 플랫폼 간에도 동작이 일관되게 유지되도록 합니다.
또 다른 주요 목표는 도구 체인 팽창을 줄이는 것입니다. Zig는 컴파일러 이상을 제공한다고 보고: 통합된 빌드 시스템과 테스트 지원을 포함하고, 워크플로우의 일부로 의존성을 가져올 수 있습니다. 의도는 프로젝트를 클론해 외부 전제 조건과 맞춤 스크립트를 적게 필요로 하면서 빌드할 수 있게 하는 것입니다.
Zig는 이식성을 염두에 두고 설계되어 있어 단일 도구 접근 방식과 자연스럽게 어울립니다: 같은 명령줄 도구로 다양한 환경을 목표로 빌드, 테스트, 타깃팅하는 절차를 간소화합니다.
Zig의 시스템 언어로서의 어필은 “마법 안전성”이나 “교묘한 추상화”가 아니라 명확성입니다. 언어는 핵심 아이디어 수를 작게 유지하려 하고, 암묵적 동작에 의존하기보다 명시적으로 적는 것을 선호합니다. C 대안이나 C++ 보다 차분한 대안을 고려하는 팀에게 이는 성능 민감 경로를 디버깅할 때 여섯 달 뒤에도 읽기 쉬운 코드로 이어집니다.
Zig에서는 코드 한 줄이 배후에서 무슨 일을 트리거할지 놀랄 일이 적습니다. 다른 언어에서 ‘보이지 않는’ 동작을 만드는 기능들—암묵적 할당, 프레임을 가로지르는 예외, 복잡한 변환 규칙—이 의도적으로 제한됩니다.
그렇다고 Zig가 불편할 정도로 최소화된 것은 아닙니다. 보통 코드만 읽어도 다음 질문들에 답할 수 있습니다:
Zig는 예외를 피하고 대신 에러 유니언을 사용합니다. 상위 수준에서 보면, error union은 “이 연산은 값 또는 에러 중 하나를 반환한다”는 의미입니다.
일반적으로 try를 사용해 에러를 위로 전파하거나(“실패하면 멈추고 에러를 반환”), catch로 로컬에서 실패를 처리합니다. 주요 이점은 실패 경로가 가시적이고 제어 흐름이 예측 가능하다는 점입니다—성능 민감 작업이나 규칙이 많은 Rust와 비교할 때 특히 유용합니다.
Zig는 일관된 규칙을 가진 간결한 기능 집합을 목표로 합니다. 규칙에 대한 “예외”가 적을수록 모서리 케이스를 암기하는 시간은 줄고, 실제 시스템 프로그래밍 문제(정확성, 속도, 의도 명료성)에 집중할 수 있습니다.
Zig는 명확한 거래를 합니다: 예측 가능한 성능과 이해하기 쉬운 정신 모델을 제공하는 대신, 메모리에 대한 책임은 개발자에게 있습니다. 가비지 컬렉터가 프로그램을 일시 중지시키지 않고, 자동 라이프타임 추적이 설계를 은근히 바꾸지 않습니다. 할당하면 누가 언제 어떤 조건에서 해제할지 결정해야 합니다.
Zig에서 “수동”은 “지저분”을 의미하지 않습니다. 언어는 명시적이고 읽기 쉬운 선택을 하도록 유도합니다. 함수는 종종 할당자를 인수로 받아서 해당 코드가 할당할 수 있는지, 얼마나 비용이 드는지 호출 지점에서 명확히 보이게 합니다. 그 가시성이 핵심입니다: 비용을 프로파일링 후에 놀라서 알게 되는 게 아니라 호출 지점에서 추론할 수 있습니다.
“힙”을 기본값으로 취급하는 대신, Zig는 작업에 맞는 할당 전략을 고르도록 장려합니다:
할당자가 일급 매개변수이기 때문에 전략 전환은 보통 리팩터링 수준으로 끝납니다. 간단한 할당자로 프로토타이핑한 뒤 실제 워크로드를 이해하면 아레나나 고정 버퍼로 옮길 수 있습니다.
GC 언어는 개발자 편의를 최적화합니다: 메모리가 자동으로 회수되지만 지연(latency)과 최대 메모리 사용량 예측이 어려울 수 있습니다.
Rust는 컴파일 타임 안전성을 최적화합니다: 소유권과 빌림이 많은 버그를 막지만 개념적 부담을 추가할 수 있습니다.
Zig는 실용적인 중간지점에 위치합니다: 규칙이 적고 숨겨진 동작이 적으며, 할당 결정을 명시화해 성능과 메모리 사용을 더 예측하기 쉽게 합니다.
Zig가 일상적인 시스템 작업에서 ‘간단하다’고 느껴지는 이유 중 하나는 언어가 빌드, 테스트, 타깃팅의 일반적인 워크플로우를 하나의 도구로 제공하기 때문입니다. 빌드 도구, 테스트 러너, 크로스컴파일러를 선택하고 연결하는 데 드는 시간을 줄이고 코드 작성에 더 집중할 수 있습니다.
대부분의 프로젝트는 생성물(실행 파일, 라이브러리, 테스트)과 구성 방법을 설명하는 build.zig 파일로 시작합니다. 이후 zig build로 모든 것을 실행하며, 이름 붙은 스텝을 제공합니다.
일반적인 명령 예:
zig build
zig build run
zig build test
이게 핵심 루프입니다: 스텝을 한 번 정의하면 Zig가 설치된 어떤 머신에서도 일관되게 실행할 수 있습니다. 작은 유틸리티의 경우 빌드 스크립트 없이 직접 컴파일할 수도 있습니다:
zig build-exe src/main.zig
zig test src/main.zig
Zig에서는 크로스컴파일을 별도 “설정 프로젝트”로 보지 않습니다. 타깃과 (선택적으로) 최적화 모드를 전달하면 Zig가 번들된 도구를 이용해 적절히 처리합니다.
zig build -Dtarget=x86_64-windows-gnu
zig build -Dtarget=aarch64-linux-musl -Doptimize=ReleaseSmall
이 기능은 윈도우나 musl로 링크된 빌드를 만드는 일이 로컬 개발 빌드만큼 일상적인 작업이 되어야 하는 팀에 중요합니다.
Zig의 의존성 이야기는 빌드 시스템에 통합되어 있습니다. 의존성은 보통 build.zig.zon과 같은 프로젝트 매니페스트에 버전과 콘텐츠 해시와 함께 선언될 수 있습니다. 이는 같은 리비전을 빌드하는 두 사람이 동일한 입력을 가져와 일관된 결과를 얻을 가능성을 높이며, Zig는 아티팩트를 캐시해 중복 작업을 피합니다.
“마법 같은 재현성”은 아니지만, 별도의 패키지 관리자를 먼저 채택하라고 요구하지 않고 기본적으로 반복 가능한 빌드로 유도합니다.
Zig의 comptime는 컴파일 시 특정 코드를 실행해 다른 코드를 생성하거나 함수 특수화, 배포 전 설정 검증을 하는 간단한 아이디어입니다. 텍스트 치환이 아닌 정상 Zig 문법과 타입을 사용하므로 디버깅과 유지보수가 쉬워집니다.
코드 생성: 컴파일 시점에 알 수 있는 입력(예: CPU 기능, 프로토콜 버전, 필드 목록)으로 타입, 함수, 룩업 테이블을 생성합니다.
설정 검증: 잘못된 옵션을 배포 전에 잡아내서 "컴파일 된다"는 것이 실제로 의미 있게 합니다.
C/C++ 매크로는 강력하지만 원시 텍스트 기반이라 디버깅이 어렵고 오용하기 쉽습니다. Zig의 comptime은 언어 내부에서 실행되므로 스코프 규칙, 타입, 도구가 그대로 적용됩니다.
다음은 몇 가지 일반적인 패턴입니다:
const std = @import("std");
pub fn buildConfig(comptime port: u16, comptime enable_tls: bool) type {
if (port == 0) @compileError("port must be non-zero");
if (enable_tls and port == 80) @compileError("TLS usually shouldn't run on port 80");
return struct {
pub const Port = port;
pub const TlsEnabled = enable_tls;
};
}
이렇게 하면 검증된 상수를 담은 설정 “타입”을 만들 수 있습니다. 잘못된 값이 들어오면 컴파일러가 명확한 메시지와 함께 중지합니다—런타임 검사나 숨겨진 매크로 논리가 아니라 컴파일 단계에서 바로 잡습니다.
Zig의 주장은 "모든 것을 재작성하라"가 아닙니다. 큰 매력 중 하나는 기존의 C 코드를 유지하면서 점진적으로 옮길 수 있다는 점입니다—모듈 단위, 파일 단위로 이전할 수 있어 ‘한번에 전환’할 필요가 없습니다.
Zig는 최소한의 절차로 C 함수를 호출할 수 있습니다. 이미 zlib, OpenSSL, SQLite, 플랫폼 SDK 같은 라이브러리에 의존한다면 새로운 로직은 Zig로 작성하고 기존 검증된 C 의존성은 유지할 수 있습니다. 위험을 낮게 유지하면서 Zig로 새 코드를 작성할 수 있습니다.
중요한 점은 Zig도 C가 호출할 수 있는 함수를 내보낼 수 있다는 것입니다. 따라서 기존 C/C++ 프로젝트에 작은 라이브러리로 Zig를 도입하는 것이 실용적입니다.
수동 바인딩을 유지하는 대신, Zig는 @cImport로 빌드 과정에서 C 헤더를 흡수할 수 있습니다. 빌드 시스템은 include 경로, 기능 매크로, 타깃 세부 정보를 정의해 가져온 API가 C 코드가 컴파일되는 방식과 일치하도록 합니다.
const c = @cImport({
@cInclude("stdio.h");
});
이 접근법은 원본 C 헤더를 “진실의 출처”로 유지해 의존성이 업데이트될 때 바인딩이 붕괴되는 것을 줄입니다.
대부분의 시스템 작업은 운영체제 API와 오래된 코드베이스를 건드립니다. Zig의 C 상호운용성은 그 현실을 장점으로 바꿉니다: 개발자 경험과 도구를 현대화하면서 시스템 라이브러리의 원어를 그대로 사용할 수 있습니다. 팀 관점에서 보면 수용 속도가 빠르고 리뷰 차이가 작으며, 실험에서 프로덕션으로 옮기는 경로가 더 명확해집니다.
Zig는 당신이 쓴 코드가 기계가 하는 일에 가깝게 매핑되도록 설계되었습니다. "항상 최고 속도"를 보장하진 않지만, 숨겨진 비용과 놀람이 적어 지연, 크기, 시작 시간 등을 추적할 때 유리합니다.
Zig는 일반 프로그램에 대해 런타임(예: GC나 필수 백그라운드 서비스)을 요구하지 않도록 합니다. 작은 바이너리를 배송하고 초기화를 제어하며 실행 비용을 통제할 수 있습니다.
유용한 사고 모델은: 어떤 것이 시간이나 메모리를 소모한다면, 그 비용을 선택한 코드 줄을 가리킬 수 있어야 한다는 것입니다.
Zig는 예측 불가능한 동작의 일반적인 원인을 명시적으로 만들려고 합니다:
이 접근법은 평균 동작뿐 아니라 최악의 경우 동작을 추정해야 할 때 유용합니다.
시스템 코드를 최적화할 때 가장 빠른 해결책은 빠르게 확인할 수 있는 것입니다. Zig의 명확한 제어 흐름과 명시적 동작 강조는 특히 매크로 트릭이나 불투명한 생성 레이어가 많은 코드베이스보다 추적(backtrace)을 따라가기가 수월한 경향이 있습니다.
실무에서는 프로그램을 “해석”하는 시간보다 실제로 중요한 부분을 측정하고 개선하는 데 더 많은 시간을 쓸 수 있음을 의미합니다.
Zig는 한 번에 모든 시스템 언어를 이기려 하지 않습니다. 실용적인 중간 지점을 차지합니다: C처럼 기계에 가까운 제어, 오래된 C/C++ 빌드 환경보다 깔끔한 경험, Rust보다 가파르지 않은 개념적 장벽—대신 Rust 수준의 안전 보장은 포기합니다.
작고 신뢰할 수 있는 바이너리를 위해 C를 이미 쓰고 있다면 Zig는 프로젝트 형태를 크게 바꾸지 않고도 대체할 수 있습니다.
Zig의 "쓴 만큼만 비용을 지불" 스타일과 명시적 메모리 선택은 플랫폼별 특이성을 다루는 취약한 빌드 스크립트에 지친 C 코드베이스에 합리적인 업그레이드 경로를 제공합니다.
Zig는 보통 C++이 선택되는 성능 중심 모듈에서 강력한 옵션이 될 수 있습니다:
현대 C++과 비교하면 Zig는 더 일관된 느낌입니다: 숨겨진 규칙이 적고 “마법”이 덜하며, 빌드와 크로스컴파일을 한곳에서 다루는 표준 도구체인이 있습니다.
주 목표가 컴파일 시점에 광범위한 메모리 버그를 막는 것이라면 Rust가 압도적입니다. 별칭(aliasing), 라이프타임, 데이터 경쟁에 대한 강력한 보장이 필요하면 Rust 모델이 큰 장점입니다.
Zig는 규율과 테스트를 통해 C보다 안전할 수 있지만, 일반적으로 컴파일러가 보장을 증명하는 대신 개발자가 올바른 선택을 하도록 의존합니다.
Zig 채택은 과장된 유행이 아니라 반복 가능한 시나리오에서 실용성을 발견한 팀들에 의해 추진되고 있습니다. 작은 언어와 도구 표면적을 유지하면서 저수준 제어를 원할 때 특히 매력적입니다.
Zig는 전체 운영체제나 표준 런타임을 전제로 하지 않는 "프리스탠딩" 환경에 친숙합니다. 임베디드 펌웨어, 부트타임 유틸리티, 취미용 OS 작업, 링크되는 내용과 내용을 엄격히 제어하고자 하는 작은 바이너리에 자연스럽게 어울립니다.
타깃과 하드웨어 제약을 알아야 하지만, Zig의 직관적 컴파일 모델과 명시성은 자원 제약 환경과 잘 맞습니다.
현실적인 사용처는 다음에 자주 나타납니다:
이런 프로젝트들은 러닝타임이나 프레임워크를 강제하지 않으면서도 메모리와 실행에 대한 명확한 제어를 원하는 경우 Zig의 장점을 누립니다.
Zig는 작고 빈틈이 적은 바이너리, 크로스타깃 빌드, C 상호운용성, 언어 모드가 적어 코드가 읽기 쉬운 경우에 좋은 선택입니다. 반대로 대형 Zig 생태계 패키지에 의존하거나 성숙한 도구 관습이 필수라면 약점이 될 수 있습니다.
실용적 접근법은 한 봉우리 컴포넌트(라이브러리, CLI 도구, 성능 핵심 모듈)에 Zig를 시범 적용해 빌드 단순성, 디버깅 경험, 통합 노력을 측정하는 것입니다.
Zig의 슬로건은 “단순하고 명시적”이지만 모든 팀이나 코드베이스에 최적이라는 뜻은 아닙니다. 도입 전 무엇을 얻고 무엇을 포기하는지 명확히 하는 것이 좋습니다.
Zig는 의도적으로 하나의 메모리 안전 모델을 강제하지 않습니다. 보통 라이프타임, 할당, 오류 경로를 명시적으로 관리하며, 원하면 unsafe한 코드를 쉽게 쓸 수 있습니다.
이는 제어와 예측 가능성을 중시하는 팀에는 장점이지만, 엔지니어링 규율(코드 리뷰 표준, 테스트 관행, 할당 패턴 소유권)이 더 중요해집니다. 디버그 빌드와 안전 검사로 많은 문제를 잡을 수 있지만 언어 수준에서의 안전 모델을 대체하지는 못합니다.
오래된 에코시스템과 비교하면 Zig의 패키지 및 라이브러리 세계는 아직 성숙하는 중입니다. "배터리 포함" 라이브러리가 적을 수 있고, 틈새 영역에는 공백이 있으며, 커뮤니티 패키지의 변경 주기가 더 잦을 수 있습니다.
Zig 자체도 언어와 도구가 변하면서 업그레이드나 소규모 리라이트가 필요했던 시기가 있었습니다. 관리 가능하지만 장기적 안정성, 엄격한 컴플라이언스, 큰 의존성 트리가 필요하다면 고려해야 합니다.
Zig의 내장 도구는 빌드를 단순화하지만 실제 워크플로우 통합(예: CI 캐싱, 재현 가능한 빌드, 릴리스 패키징, 다중 플랫폼 테스트)은 여전히 필요합니다.
에디터 지원은 개선 중이지만 IDE와 언어 서버 설정에 따라 차이가 날 수 있습니다. 디버깅은 표준 디버거로 일반적으로 양호하지만 크로스컴파일이나 드문 타깃을 다룰 때 플랫폼별 특이점이 나타날 수 있습니다.
평가 시에는 제한된 컴포넌트에서 시험해 필수 타깃, 라이브러리, 도구가 끝까지 작동하는지 확인하세요.
Zig는 실제 코드 조각으로 시도해 보는 것이 가장 쉽습니다—안전할 만큼 작지만 일상적 마찰을 드러낼 정도로 의미 있는 범위여야 합니다.
입출력이 명확하고 표면적이 제한된 컴포넌트를 선택하세요:
목표는 Zig가 모든 것을 할 수 있음을 증명하는 것이 아니라 명확성, 디버깅, 유지보수가 한 가지 구체적 작업에서 개선되는지 확인하는 것입니다.
코드를 바로 재작성하기 전에 도구로서 Zig를 채택해 즉각적인 효율을 평가할 수 있습니다:
이렇게 하면 빌드 속도, 에러, 캐싱, 타깃 지원 같은 개발자 경험을 코드 재작성 없이 평가할 수 있습니다.
흔한 패턴은 Zig를 성능 핵심(CLI 유틸리티, 라이브러리, 프로토콜 코드)에 집중시키고, 주변의 고수준 제품 부분(관리 대시보드, 내부 도구, 배포용 플러그인)은 더 빠른 플랫폼(웹, 고수준 언어)으로 구현하는 것입니다.
이 분업으로 Zig는 예측 가능한 저수준 동작에 집중하고, 비핵심 플러밍에는 더 빠른 개발 흐름을 유지할 수 있습니다.
실용적 기준에 집중하세요:
파일럿 모듈이 성공적으로 배포되고 팀이 같은 워크플로우를 계속 사용하고 싶어하면, 다음 경계로 Zig를 확장해도 좋은 신호입니다.
이 문맥에서 “간단한”은 당신이 작성한 코드와 프로그램이 실제로 하는 일 사이에 숨어 있는 규칙이 적다는 의미입니다. Zig는 다음을 지향합니다:
목표는 기능이 떨어지는 것이 아니라 예측 가능성과 유지보수성의 향상입니다.
Zig는 다음과 같은 경우에 잘 맞습니다:
요약하면, 엄격한 제어와 예측 가능한 성능, 장기 유지보수가 중요할 때 강력합니다.
Zig는 수동 메모리 관리를 사용하지만 이를 규율 있고 가시적으로 만들려고 합니다. 흔한 패턴은 할당자를 호출자에게 인수로 전달하는 것으로, 어느 코드가 메모리를 할당하는지 명확히 보이게 합니다.
실용적 요점: 함수가 할당자를 인수로 받는다면 해당 함수는 할당할 가능성이 있으므로 소유권과 해제 시점을 계획하세요.
Zig는 흔히 "할당자 매개변수" 패턴을 사용하여 작업별 전략을 선택할 수 있게 합니다:
이 방식은 전체 모듈을 다시 작성하지 않고도 할당 전략을 교체하기 쉽게 만듭니다.
Zig는 예외 대신 에러 유니언(error union)을 통해 에러를 값으로 취급합니다. 즉, 연산은 값이나 에러 중 하나를 반환합니다. 자주 쓰이는 연산자:
try: 에러가 발생하면 상위로 전파catch: 에러를 로컬에서 처리(선택적 대체 동작)실패 경로가 타입과 문법에 드러나기 때문에 코드만 읽어도 실패 지점을 파악하기 쉽습니다.
Zig는 zig라는 통합 워크플로우 도구를 제공합니다:
zig build: build.zig에 정의된 빌드 스텝 실행zig build test 또는 zig test file.zig: 테스트 실행zig fmt: 코드 포맷팅크로스컴파일이 일상적으로 설계되어 있어 대상(target)을 지정하면 Zig가 번들된 도구를 사용해 적절한 빌드를 만듭니다.
예시:
zig build -Dtarget=x86_64-windows-gnuzig build -Dtarget=aarch64-linux-musl -Doptimize=ReleaseSmall여러 OS/CPU/libc 조합에 대해 반복 가능한 바이너리를 유지해야 할 때 특히 유용합니다.
comptime는 컴파일 시점에 특정 코드를 실행해 다른 코드를 생성하거나 함수 특수화, 설정 검증을 하는 간단하지만 강력한 기능입니다. 텍스트 치환 방식의 전처리기 대신 언어의 정상 문법과 타입을 사용합니다.
흔한 사용 사례:
@compileError로 설정 검증 (컴파일 단계에서 실패)매크로식 트릭 대신 언어 안에서 안전하게 메타프로그래밍을 할 수 있습니다.
Zig는 기존 C 코드를 한꺼번에 재작성하라고 강요하지 않습니다. 상호운용성이 좋아 점진적 도입이 현실적입니다:
@cImport로 C 헤더를 빌드 시점에 가져와 바인딩을 유지이로써 모듈 단위로 Zig를 도입하거나 C 코드를 래핑하는 식의 점진적 마이그레이션이 가능합니다.
Zig가 최선이 아닐 때:
실무적 접근법: 제한된 컴포넌트에서 파일럿으로 시험한 뒤 빌드 단순성, 디버깅 경험, 타깃 지원을 기준으로 결정하세요.
실제 이득은 설치해야 할 외부 도구가 줄어들고, 기계와 CI 전반에서 일관된 단일 명령어 흐름을 유지할 수 있다는 점입니다.