Skip to content
Published on

2026 시스템 언어와 패키지 매니저 - Zig, C++26, Carbon, Mojo, Swift 서버, Kotlin, C# .NET 9, uv, pnpm, Bun 심층 분석

Authors

2026년 시스템 언어 생태계는 변곡점을 지났습니다. Zig 0.14가 점진적 컴파일과 새 빌드 시스템을 안정화했고, C++26은 P2900 contracts와 P2300 std::execution을 표준에 포함시켰으며, Mojo 1.x는 MLIR을 기반으로 Python 슈퍼셋을 표방하면서 GPU 커널 작성까지 한 언어로 처리하려 합니다. Swift는 Linux 서버에서 Vapor와 Hummingbird를 통해 자리잡았고, Kotlin은 Ktor 3과 GraalVM 네이티브 이미지로 서버 런타임을 가볍게 만들었습니다. C# 13/.NET 9은 네이티브 AOT와 primary constructor로 컨테이너 친화적으로 진화했습니다. 패키지 매니저도 마찬가지로, uv가 pip와 Poetry를 사실상 대체하기 시작했고, pnpm 10과 Bun이 npm 생태계를 양분하기 시작했습니다.

시스템 언어 지형 한눈에 보기

2026년 5월 기준 주류와 차세대 시스템 언어를 단순화하면 다음과 같습니다. C와 C++은 여전히 OS 커널, 게임 엔진, 데이터베이스의 절대 다수를 차지하지만 Rust, Zig, Carbon, Mojo가 분야별로 침투하는 중입니다. JVM 진영에서는 Kotlin이 Spring과 Ktor 양쪽에서 자바를 대체하고 있고, Scala 3와 Clojure 1.13은 데이터/금융 도메인에서 살아남았습니다. .NET 9는 클라우드 네이티브 워크로드에서 Go에 가까운 시작 시간과 메모리 사용량을 달성했습니다.

Zig 0.14 - 점진적 컴파일과 빌드 시스템

Zig 0.14는 점진적 컴파일(incremental compilation)을 베타에서 안정화 단계로 끌어올렸고, async 모델을 다시 설계했으며, build.zig 빌드 시스템에 패키지 매니저(zig fetch)를 통합했습니다. comptime은 여전히 Zig의 핵심 특징입니다.

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    var list = std.ArrayList(u32).init(allocator);
    defer list.deinit();

    try list.appendSlice(&[_]u32{ 1, 2, 3, 4, 5 });

    var sum: u64 = 0;
    for (list.items) |x| sum += x;

    std.debug.print("sum = {d}\n", .{sum});
}

comptime 제네릭은 매크로 없이도 안전한 추상화를 만듭니다. comptime 키워드는 컴파일 시점에 평가되는 코드를 의미하며, 타입 자체를 일급 값으로 다룹니다.

C++26 - contracts와 std::execution

C++26은 ISO 표준에서 P2900 contracts(pre/post-condition, assertion)와 P2300 sender/receiver(std::execution)를 받아들였습니다. 더불어 정적 리플렉션의 일부가 포함되어 컴파일 시점 메타프로그래밍이 비약적으로 쉬워졌습니다.

#include <execution>
#include <expected>
#include <print>

std::expected<int, std::string> parse_port(std::string_view s) {
    int port = 0;
    auto [ptr, ec] = std::from_chars(s.data(), s.data() + s.size(), port);
    if (ec != std::errc{}) return std::unexpected("invalid number");
    if (port < 1 || port > 65535) return std::unexpected("out of range");
    return port;
}

int main() {
    auto result = parse_port("8080")
        .transform([](int p) { return p + 1000; });
    if (result) std::println("port = {}", *result);
    else std::println("error: {}", result.error());
}

C++23에서 도입된 std::expected<T, E>std::print는 이미 LLVM/Clang, GCC 14+, MSVC 2024+에서 안정적이며, deducing this(Self)는 CRTP 패턴을 단순화했습니다.

Carbon - Google의 "C++ 후속" 실험

Carbon은 2026년에도 여전히 실험 단계(experimental)이며, 0.x 버전에서 toolchain이 부분적으로 동작합니다. 목표는 기존 C++ 코드와 양방향 상호 운용성을 유지하면서 더 안전하고 현대적인 문법을 제공하는 것입니다. Rust와 달리 borrow checker를 채택하지 않고, generics, interfaces, ADT 같은 현대 언어 기능에 집중합니다.

package Sample api;

fn Fibonacci(n: i32) -> i32 {
  if (n < 2) { return n; }
  return Fibonacci(n - 1) + Fibonacci(n - 2);
}

fn Main() -> i32 {
  Core.Print("fib(10) = {0}", Fibonacci(10));
  return 0;
}

현재 Carbon은 대규모 채택보다는 "C++ 진화의 방향성"을 제시하는 청사진에 가깝습니다.

Mojo 1.x - Python 슈퍼셋과 MLIR

Modular의 Mojo는 2026년 1.x 정식 버전을 발표하면서 Python 슈퍼셋 호환성을 더 넓게 확보했습니다. MLIR(다중 단계 IR) 위에 만들어졌고, CPU SIMD와 GPU 커널을 같은 언어로 작성할 수 있다는 점이 차별점입니다.

from tensor import Tensor

fn dot_product(a: Tensor[DType.float32], b: Tensor[DType.float32]) -> Float32:
    var acc: Float32 = 0.0
    for i in range(a.num_elements()):
        acc += a[i] * b[i]
    return acc

fn main():
    var x = Tensor[DType.float32](1024)
    var y = Tensor[DType.float32](1024)
    print(dot_product(x, y))

Mojo는 Python 코드를 그대로 import할 수 있으면서도 fn 키워드로 정의된 함수는 정적 타입과 SIMD 최적화를 자동으로 받습니다.

Swift 6 서버 - Vapor 4와 Hummingbird 2

Swift 6는 strict concurrency를 기본값으로 강제했고, Linux 빌드와 정적 링킹이 한층 안정적입니다. Vapor 4와 Hummingbird 2는 둘 다 SwiftNIO 기반의 HTTP 서버 프레임워크입니다.

import Vapor

let app = try Application(.detect())
defer { app.shutdown() }

app.get("hello", ":name") { req async throws -> String in
    let name = req.parameters.get("name") ?? "world"
    return "Hello, \(name)!"
}

try await app.execute()

Mercari는 자사 일부 백엔드를 Swift 서버로 운영한다고 알려져 있으며, Apple은 swift.org/server 워킹 그룹을 통해 표준 라이브러리와 패키지 관리(SwiftPM)를 발전시키고 있습니다.

Kotlin 서버 - Ktor 3과 Spring Boot 3 네이티브

Kotlin 2.1은 K2 컴파일러를 기본값으로 사용하고, multiplatform 안정성을 강화했습니다. Ktor 3은 코루틴 기반의 가벼운 HTTP 서버를 제공하며, Spring Boot 3은 GraalVM Native Image로 빌드하면 50MB 미만의 정적 바이너리를 만들 수 있습니다.

import io.ktor.server.application.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*
import io.ktor.server.response.*
import io.ktor.server.routing.*

fun main() {
    embeddedServer(Netty, port = 8080) {
        routing {
            get("/health") { call.respondText("ok") }
            get("/users/{id}") {
                val id = call.parameters["id"] ?: "0"
                call.respondText("user $id")
            }
        }
    }.start(wait = true)
}

Toss는 Spring Boot + Kotlin을 메인 백엔드 스택으로 사용하고, Coupang은 Java에서 Kotlin으로 점진적 마이그레이션을 진행했습니다. LINE Yahoo도 메시징과 광고 서버에 Kotlin을 적극적으로 도입했습니다.

C# 13 / .NET 9 - 네이티브 AOT와 primary constructor

.NET 9는 네이티브 AOT를 prod-ready로 끌어올렸고, primary constructor와 collection expression이 정착했습니다. ASP.NET Core minimal API는 Spring보다 가벼운 시작 시간을 제공합니다.

var builder = WebApplication.CreateSlimBuilder(args);
builder.Services.AddAuthorization();

var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.MapGet("/users/{id:int}", (int id) =>
    Results.Ok(new { id, name = $"user{id}" }));

app.Run();

CreateSlimBuilder는 reflection을 줄여 AOT 컴파일에 적합하며, PublishAot=true로 빌드하면 10MB 안팎의 단일 실행 파일을 얻을 수 있습니다.

JVM 언어 생태계 - Scala 3, Clojure 1.13, Groovy 4

Scala 3는 indentation 기반 문법과 union type을 정착시켰고, Akka의 라이선스 변경 후 Pekko가 사실상 후속 표준이 되었습니다. Clojure 1.13은 deps.edn과 tools.build를 통해 빌드 경험을 개선했고, REPL 중심 워크플로는 여전히 강력합니다. Groovy 4는 Gradle DSL이라는 자리 덕분에 명맥을 유지하지만 신규 채택은 거의 없습니다.

Crystal, Nim, V - 소규모 컴파일 언어

Crystal 1.13은 Ruby와 거의 같은 문법에 정적 타입과 LLVM 백엔드를 결합했습니다. Nim 2.x는 Python 유사 문법에 ARC/ORC GC, 메타프로그래밍을 더했습니다. V(Vlang)는 빠른 컴파일과 단순함을 강조하지만 생태계는 아직 작습니다. 세 언어 모두 작은 CLI 도구나 임베디드 서비스에서 실용적입니다.

Bazel 8, Buck2, Pants - 모노리포 빌드 시스템

Bazel 8은 bzlmod를 기본값으로 사용하며 외부 의존성 관리를 단순화했습니다. Buck2는 Rust로 다시 쓴 Meta의 빌드 시스템으로 원격 실행 성능이 뛰어납니다. Pants 2.20은 Python/Java/Go를 폭넓게 지원하며 디지털 광고와 금융 회사에서 인기를 끕니다.

# BUILD file (Bazel)
load("@rules_rust//rust:defs.bzl", "rust_binary", "rust_library")

rust_library(
    name = "core",
    srcs = glob(["src/lib.rs", "src/**/*.rs"]),
    edition = "2024",
)

rust_binary(
    name = "server",
    srcs = ["src/main.rs"],
    deps = [":core"],
    edition = "2024",
)

Gradle 9과 Mill - JVM 빌드의 두 갈래

Gradle 9는 Kotlin DSL을 기본 권장 문법으로 명시하고 configuration cache를 안정화했습니다. Mill은 Scala 기반의 새 JVM 빌드 도구로, Bazel 스타일의 task graph와 Maven 호환성을 결합합니다.

plugins {
    kotlin("jvm") version "2.1.0"
    application
}

repositories { mavenCentral() }

dependencies {
    implementation("io.ktor:ktor-server-core:3.0.0")
    implementation("io.ktor:ktor-server-netty:3.0.0")
    testImplementation(kotlin("test"))
}

application {
    mainClass.set("com.example.MainKt")
}

uv - Python 패키지 매니저의 새 표준

Astral의 uv는 Rust로 쓰여졌고, pip, pip-tools, Poetry, virtualenv를 한 도구로 통합합니다. 2026년에는 사실상 신규 Python 프로젝트의 기본값이 되었습니다. 의존성 해결 속도는 pip 대비 10-100배 빠르고, 단일 정적 바이너리로 배포됩니다.

[project]
name = "my-app"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "fastapi>=0.115",
    "pydantic>=2.9",
    "httpx>=0.27",
]

[dependency-groups]
dev = [
    "pytest>=8.3",
    "ruff>=0.7",
    "mypy>=1.13",
]

[tool.uv]
managed = true

Poetry에서 uv로 마이그레이션할 때는 poetry export로 requirements.txt를 만든 뒤 uv add로 옮기는 패턴이 일반적입니다.

pnpm 10, Yarn 5(Berry), Bun - npm 생태계 분기

pnpm 10은 디스크 효율적인 content-addressable store와 workspace 기능으로 모노리포의 사실상 표준이 되었습니다. Bun은 자체 패키지 매니저(bun install)와 번들러, 런타임을 한 바이너리에 묶었습니다. Yarn 5(Berry)는 Plug'n'Play로 node_modules 자체를 없애는 방향을 유지합니다.

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'
catalog:
  react: ^19.0.0
  typescript: ^5.7.0

설치 속도 벤치마크는 일반적으로 Bun > pnpm > Yarn Berry > npm 순서이지만, 모노리포 규모와 캐시 상태에 따라 달라집니다.

Bun 1.x - JavaScript 런타임 통합

Bun 1.x는 Node 호환성을 확보하면서 bun install, bun test, bun build, bun run을 단일 바이너리로 제공합니다. esbuild 대비 번들 속도가 빠르고, TypeScript와 JSX를 네이티브로 실행합니다.

# 새 프로젝트 생성
bun init -y

# 의존성 추가
bun add hono zod
bun add -d @types/node

# 서버 실행
bun --hot src/server.ts

# 단일 실행 파일 빌드
bun build --compile --target=bun-linux-x64 src/server.ts --outfile server

Pixi - 다언어 과학 컴퓨팅 패키지 매니저

Prefix.dev의 Pixi는 Conda 생태계 기반이지만 Cargo 스타일의 lock 파일과 task runner를 제공합니다. Python, R, C++, CUDA 의존성을 한 manifest에 묶을 수 있어 ML/과학 컴퓨팅에서 빠르게 보급되고 있습니다.

[project]
name = "ml-experiment"
channels = ["conda-forge", "pytorch", "nvidia"]
platforms = ["linux-64", "osx-arm64"]

[dependencies]
python = ">=3.12,<3.13"
pytorch = ">=2.5"
numpy = ">=2.0"

[tasks]
train = "python train.py"
eval = "python eval.py --checkpoint=last"

Nix와 Nix Flakes - 재현 가능한 빌드

Nix는 함수형 패키지 관리자로, 의존성과 빌드를 해시 기반으로 고정합니다. Flakes는 입력과 출력을 명시적으로 선언하는 모던 인터페이스입니다.

{
  description = "Polyglot dev shell";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  outputs = { self, nixpkgs }:
  let
    system = "x86_64-linux";
    pkgs = import nixpkgs { inherit system; };
  in {
    devShells.${system}.default = pkgs.mkShell {
      packages = with pkgs; [ zig rustup nodejs_22 bun uv go_1_23 ];
    };
  };
}

NixOS는 여전히 진입 장벽이 높지만, 단일 nix develop으로 모든 팀원이 동일한 환경을 갖는 가치는 큽니다.

Conan, vcpkg - C/C++ 패키지 매니저

Conan 2.x와 Microsoft의 vcpkg는 C/C++ 의존성 관리의 양대 축입니다. Conan은 프로파일 기반의 ABI 추적이 정밀하고, vcpkg는 manifest mode와 CMake 통합이 자연스럽습니다. 둘 다 1000개 이상의 잘 알려진 라이브러리를 패키징합니다.

Spack과 HPC

Spack은 고성능 컴퓨팅(HPC) 분야에서 BLAS, MPI 같은 라이브러리를 다중 컴파일러/MPI 구현체 조합으로 빌드해야 할 때 표준 도구입니다. 미국 국립 연구소와 슈퍼컴퓨터 사이트에서 광범위하게 사용됩니다.

go mod, Cargo, Mix, opam, Hex - 언어별 표준 도구

Go의 go mod, Rust의 Cargo, Elixir의 Mix, OCaml의 opam, Erlang/Elixir의 Hex는 각 언어의 사실상 표준 도구로 자리잡았습니다. 셋 모두 lock 파일, 워크스페이스, 빌드 캐시를 기본 지원합니다.

Maven, Gradle, sbt - JVM 패키지 관리

Maven은 여전히 자바 생태계에서 가장 보수적인 선택이고, Gradle은 Android와 Kotlin 진영의 기본값이며, sbt는 Scala 진영에서 살아남았습니다. 신규 자바 프로젝트도 Maven보다 Gradle Kotlin DSL을 채택하는 비율이 늘었습니다.

brew, Linuxbrew - 개발자 머신 패키지

macOS에서는 Homebrew(brew)가 시스템 관리자 없는 의존성 설치의 사실상 표준이며, Linux에서는 Linuxbrew와 함께 Nix, asdf, mise가 경쟁합니다. 대부분의 백엔드 개발자는 brew로 언어 런타임을 설치한 뒤, 프로젝트별로 uv/pnpm/cargo로 의존성을 잠급니다.

한국 기업 사례

Naver는 일부 인프라 도구를 Zig로 실험하고 있으며, Coupang은 Kotlin 비중을 늘려 Java + Spring Boot에서 Kotlin + Spring Boot로 이전하고 있습니다. Toss는 처음부터 Kotlin + Spring을 메인으로 잡았고, 카카오는 Go와 Kotlin을 함께 사용합니다. Naver는 swift.org/server에 일부 기여하면서 Swift 서버 실험을 진행했다고 알려져 있습니다.

일본 기업 사례

Mercari는 일부 백엔드를 Swift on Linux로 운영하고 Apple과 협력하여 swift-nio에 기여했습니다. CyberAgent는 ML 추론 파이프라인의 일부를 Mojo로 실험합니다. LINE Yahoo는 광고 플랫폼과 메시징 서버에 Kotlin을 적극 채택했고, DeNA와 SmartNews도 Kotlin/JVM 비중이 큽니다.

속도 비교 - uv vs pip, pnpm vs npm, Bun vs esbuild

벤치마크는 머신과 캐시 상태에 따라 다르지만 일반적인 경향은 다음과 같습니다. uv의 cold install은 pip 대비 10-100배 빠르고, pnpm의 모노리포 install은 npm 대비 2-5배 빠릅니다. Bun bundle은 esbuild보다 빠를 때가 많지만 옵션과 plugin 호환성에서 차이가 있습니다. 직접 측정할 때는 time uv pip installtime pip install을 같은 캐시 상태에서 비교하면 차이가 명확합니다.

어느 언어와 매니저를 골라야 하는가

OS 커널, 게임 엔진, HFT처럼 마지막 사이클까지 짜야 한다면 여전히 C++26과 Rust가 선택지입니다. ML 추론과 GPU 커널이라면 Mojo와 CUDA C++을 함께 고려할 만합니다. 서버 백엔드라면 Kotlin/Ktor, Go, Swift 서버, .NET 9 minimal API가 모두 합리적입니다. CLI 도구와 단순한 데몬은 Zig, Nim, Crystal이 매력적입니다. 패키지 매니저는 언어별 표준(Cargo, go mod, uv, pnpm)을 따르되, 모노리포에서는 Bazel/Buck2를, 다언어 과학 컴퓨팅에서는 Pixi/Nix를 사용하는 패턴이 자리잡고 있습니다.

결론 - 2026년 시스템 언어와 매니저의 풍경

2026년은 어느 한 언어가 모두를 대체하는 해가 아니라, 도메인별 최적의 도구가 분명해진 해입니다. C++26과 Rust가 시스템 코어를 지키고, Zig가 비교적 단순한 시스템 코드를 가져가며, Mojo가 ML 가속을, Swift와 Kotlin이 서버를, .NET 9이 클라우드 백엔드를 점유합니다. 패키지 매니저는 Cargo의 단순함과 정교함이 다른 언어에 영향을 주면서 uv, Bun, pnpm처럼 빠르고 결정론적인 도구가 표준이 되고 있습니다. 다언어 모노리포에서는 Bazel/Buck2/Pants와 Pixi/Nix가 공존하면서 재현 가능한 빌드를 만들고 있습니다.

References