Skip to content
Published on

설정 언어 2026 — CUE / Pkl (Apple) / KCL / Dhall / Jsonnet / HCL / Nix / Starlark / Pulumi (TS) 심층 비교

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — YAML 천 줄을 들여다본 어느 SRE의 한숨

2026년 봄, 어느 플랫폼팀 회의실.

SRE: "이 Helm values.yaml이 1,400줄이에요. 한 줄 띄어쓰기 잘못해서 어제 prod 배포 망가졌어요." PM: "왜 그렇게 길어요?" SRE: "환경 3개 × 마이크로서비스 47개 × 리전 4개. 곱하면 564 조합인데, 차이는 5% 정도예요. 근데 YAML은 추상화가 없으니까 다 복붙해요." PM: "그럼 다른 거 쓰면 되잖아요?" SRE: "뭘로요? Jsonnet? Helm template? Kustomize? CUE? Pkl? Terraform이면 HCL? Bazel이면 Starlark? Pulumi로 TypeScript? Nix? 6개 다 회사에서 쓰고 있어요. 어느 거 권장해야 하는지가 정해진 적이 없어요."

이게 2026년의 풍경이다. 우리는 설정 폭증 시대에 산다. 쿠버네티스 YAML, Terraform HCL, Helm values, Backstage 카탈로그, ArgoCD ApplicationSet, GitHub Actions, CircleCI orbs, Buildkite pipeline, Dockerfile, Bazel BUILD, devcontainer.json, dprint config, biome.json, package.json, pyproject.toml — 어느 마이크로서비스를 켜도 설정 파일 30개는 기본이다. JSON/YAML/TOML로 부족해서 새 언어들이 나오기 시작했고, 2026년 현재 CUE·Pkl·KCL이 빅3가 됐다. 거기에 Jsonnet·HCL·Nix·Starlark·Dhall이 각자 영역을 지키고 있고, Pulumi 진영은 "그냥 TypeScript 써라"고 외친다.

이 글은 2026년 설정 언어 지도를 그린다. 각 언어가 어디서 왔고, 어떤 문제를 풀고, 어디서 실패하고, 우리 팀이 무엇을 골라야 하는지까지.

1장 · 2026년 설정 언어 지도 — 4분류

먼저 한눈에 보는 분류표.

카테고리대표 언어핵심 아이디어
데이터 + 제약 통합CUE, Pkl, KCL값과 스키마가 같은 언어. 타입 = 부분 데이터
함수형 / 람다Dhall, Jsonnet순수 함수, 데이터를 계산해서 만든다
도메인 특화(IaC)HCL, NixTerraform / NixOS 같은 단일 도메인
빌드 결정론StarlarkBazel용 Python sandbox
일반 언어 = 설정Pulumi(TS/Py/Go), CDK일반 프로그래밍 언어가 IaC를 만든다
태스크 러너Mage, Earthfile, Just, TaskfileMake 대체, 작업 정의
클래식 데이터JSON, YAML, TOML그냥 직렬화. 추상화 없음

각 카테고리가 푸는 문제가 다르다는 게 핵심이다. CUE는 "YAML이 100개로 늘어났을 때 검증과 합성을 어떻게 할 것인가"를 풀고, Pulumi는 "왜 우리는 ML 엔지니어처럼 IDE 자동완성과 단위 테스트를 못 쓰는가"를 풀고, Starlark는 "빌드가 왜 매번 다른 결과를 내는가(비결정성)"를 푼다. 한 언어가 모든 걸 풀지는 못한다.

또 한 가지 축: 튜링 완전성. Jsonnet·Dhall·CUE는 의도적으로 비-튜링 완전(또는 약한 형태)이다. 무한 루프를 못 만들어서 평가가 반드시 끝난다. Pulumi(TS), Starlark, Pkl은 더 풍부하지만 무한 루프 가능하다. 이 트레이드오프가 "설정에 어디까지 로직을 넣어도 되는가" 논쟁의 핵심이다.

2장 · "왜 JSON/YAML로는 부족한가" — 동기 분석

2026년에도 여전히 "그냥 YAML 써라" 진영이 강력하다. 그들의 주장은 다음과 같다.

"YAML은 모든 언어가 읽을 수 있다. 추가 도구 체인이 필요 없다. 사람이 읽을 수 있다. 충분하다."

맞는 말이다. 작은 프로젝트는 YAML로 끝난다. 하지만 다음 5가지 증상이 나타나면 YAML이 한계에 부딪힌다.

증상 1 · 중복. 환경별 values-dev.yaml / values-stg.yaml / values-prod.yaml에 같은 키가 95% 반복된다. 한 군데 고치면 세 군데 다 고쳐야 한다. 휴먼 에러가 폭증한다.

증상 2 · 검증 부재. replicas: "3"(문자열)이 통과돼서 k8s가 거부할 때까지 모른다. 스키마(JSON Schema, OpenAPI)로 외부 검증하지만 IDE에서 즉시 안 잡힌다.

증상 3 · 합성. 베이스 + 오버레이를 합쳐야 한다. Helm은 Go template, Kustomize는 strategic merge patch, Jsonnet은 객체 합성으로 푼다. YAML 자체는 못 한다.

증상 4 · 변수. "이 값을 5군데에서 참조"가 안 된다. YAML anchors(&/*)는 한 파일 안에서만 작동한다.

증상 5 · 조건/반복. "환경이 prod면 replicas 5, 아니면 1"이 YAML로 안 된다. 그래서 결국 Go template(Helm)이나 Jinja 같은 텍스트 치환을 얹는다. 그러면 들여쓰기에 민감한 YAML을 들여쓰기를 모르는 텍스트 엔진으로 생성하는 사태가 벌어진다. 이게 Helm chart 디버깅의 90%다.

이 5가지가 "설정 언어"가 등장한 이유다. 추상화·검증·합성·변수·로직을 언어 수준에서 푸는 게 목적이다. 그리고 2026년에 그 자리를 두고 CUE·Pkl·KCL이 경쟁한다.

3장 · CUE — Marcel van Lohuizen의 데이터 + 제약 통합

CUE(Configure, Unify, Execute)는 구글 전 엔지니어 Marcel van Lohuizen이 만들었다. 그는 Go의 핵심 기여자였고, Protocol Buffers의 설계자 중 한 명이었다. 그가 구글에서 본 건 설정 파일이 수억 줄로 늘어났을 때 어떻게 검증과 합성을 할 것인가라는 문제였다. CUE는 그 문제에 대한 답이다.

CUE의 핵심 통찰: 타입과 값은 같다. int는 "모든 정수의 집합"이고, 42는 "오직 42만 들어있는 집합"이다. 둘 다 같은 종류의 객체(constraint)다. 두 constraint를 합치는 연산이 unification이다.

// 스키마
#Server: {
    name:     string
    port:     int & >0 & <65536
    replicas: int | *3  // 기본값 3
    env:      "dev" | "stg" | "prod"
}

// 값
server: #Server & {
    name: "api"
    port: 8080
    env:  "prod"
}
// replicas는 명시 안 했으므로 기본값 3

여기서 int & >0 & <65536는 "정수이고, 0보다 크고, 65536보다 작은 값들의 집합"이라는 제약이다. server에 port: 70000을 넣으면 unification이 실패해서 CUE가 에러를 낸다. 이게 스키마와 데이터를 같은 언어로 쓰는 CUE의 매력이다.

또 하나의 핵심: commutativity. A & B = B & A다. 어느 순서로 합쳐도 결과가 같다. 그래서 Helm의 "values 우선순위" 같은 골치 아픈 룰이 없다.

2026년 CUE 생태계:

  • Cuelang 공식 도구: cue eval, cue export, cue vet, cue mod
  • Holos: CUE 기반 k8s GitOps
  • Dagger CI/CD: 초기에 CUE 기반이었으나 2024년 Go SDK로 이전
  • kpt + CUE: 구글 클라우드의 k8s 설정 도구
  • Istio: 내부 설정 검증에 CUE 일부 사용

CUE의 약점: 러닝 커브가 가파르다. unification, disjunction, definitions, hidden fields, optional, default — 개념이 많다. "왜 그냥 YAML 안 쓰는데?"를 설득하는 데 6개월 걸린다. 또 에러 메시지가 어렵다. unification 실패 시 어디서 충돌이 났는지 찾기 어렵다.

4장 · Pkl (Apple, 2024년 2월) — Apple의 오픈소스 설정 언어

2024년 2월, Apple이 갑자기 오픈소스 설정 언어 Pkl(Pickle, pkl.dev)을 공개했다. 이건 충격이었다. Apple은 OSS를 거의 안 하는 회사로 유명한데, "우리가 내부에서 수년간 써온 설정 언어를 공개한다"고 발표한 것이다.

Pkl의 디자인 철학:

  • 객체 지향: 클래스, 모듈, 상속이 있다. Scala 영향이 강하다(설계자 중 하나가 Scala 출신).
  • 타입 시스템 풍부: Listable, Mapping, Listing, Class, 제약(Constraints), null safety
  • 다양한 출력 포맷: pcf(pkl 자체), JSON, YAML, plist, .properties, XML
  • IDE 통합 강력: 공식 IntelliJ / VS Code 플러그인, LSP 지원, 즉시 검증
class Server {
    name: String
    port: Int(this > 0 && this < 65536)
    replicas: Int = 3
    env: "dev" | "stg" | "prod"
}

api = new Server {
    name = "api"
    port = 8080
    env = "prod"
}

문법이 CUE보다 친숙하다. Java/Kotlin/Scala 출신이면 5분 안에 읽힌다. 그리고 에러 메시지가 매우 좋다. 어디서 제약이 깨졌는지 정확히 찍어준다. Apple이 내부에서 수년간 다듬은 흔적이 보인다.

Pkl의 강력한 기능: 언어 바인딩. Java, Kotlin, Swift, Go, Python에 SDK가 있어서 Pkl 설정을 그 언어의 객체로 바로 읽을 수 있다. Spring Boot가 application.properties / application.yml을 읽는 것처럼 application.pkl을 읽는다. 이게 "Apple이 왜 이걸 만들었나"의 답이다 — Swift/Java/Kotlin 백엔드의 타입 안전한 설정.

2026년 Pkl 채택 현황:

  • Apple 내부: 광범위(공개 안 하지만 발표에서 언급)
  • AWS, Booking.com, ING 등이 평가 중이라고 보고됨
  • 한국에서는 토스가 일부 백엔드 설정에 Pkl 도입을 PoC했다고 컨퍼런스 발표(2025)
  • 일본에서는 Sansan, Mercari 일부 팀이 Java/Kotlin 백엔드 설정에 사용

약점: 상대적으로 새 언어. 2024년 공개라 생태계가 아직 작다. 그리고 Apple이 주도하는 만큼 Apple의 정책에 묶인다(개발 속도, 거버넌스). Kubernetes 같은 인프라 도메인에는 약하다(YAML/JSON 변환은 되지만 k8s 도구체인 통합이 약함).

5장 · KCL (Kusion Stack, CNCF Sandbox 2024)

KCL(Kusion Configuration Language)은 중국 Ant Group에서 시작해 2023년 Kusion Stack 프로젝트의 일부로 오픈소스화됐고, 2024년 CNCF Sandbox에 들어갔다. 2026년 현재 CNCF Incubation을 노리는 단계다.

KCL의 디자인:

  • Python 문법 기반: 들여쓰기, 콜론, 친숙
  • 정적 타입: type checking 강력
  • OOP: 클래스, 상속, 믹스인
  • k8s 특화: KRM(Kubernetes Resource Model) 친화
schema Server:
    name: str
    port: int
    replicas: int = 3
    env: "dev" | "stg" | "prod"

    check:
        port > 0 and port < 65536, "port out of range"

api = Server {
    name = "api"
    port = 8080
    env = "prod"
}

읽기 가장 쉽다. Python 개발자가 5분 안에 쓴다. 에러 메시지도 명확하고, 컴파일러가 빠르다(Rust + LLVM 기반). 무엇보다 k8s에 집중한다 — kcl-operator, kclvm-go, KCL-as-Crossplane-composition, KCL-as-Argo-CD-plugin 등 k8s 생태계 통합이 가장 활발하다.

2026년 KCL 위치:

  • CNCF Sandbox (2024 진입), Incubation 준비 중
  • Ant Group, Alibaba 내부 광범위 사용
  • KubeCon China 2025에서 KCL 트랙 단독 운영
  • 한국 기업 중 일부 메가코프(통신사)가 사내 표준으로 PoC
  • 일본은 아직 채택 사례 적음

약점: k8s 외 도메인에서 약하다. 일반 백엔드 설정용은 Pkl이 강하고, 정통 데이터+제약은 CUE가 정교하다. 그리고 중국 기업 주도라는 정치적 변수가 일부 서구 기업에서 채택을 늦춘다(KCL은 100% OSS이고 CNCF 거버넌스를 따르지만, 인식의 문제).

6장 · Dhall — 함수형, 오래됐고 단단하다

Dhall(dhall-lang.org)은 2017년 Gabriel Gonzalez(Haskell 커뮤니티 거장)가 만든 함수형 설정 언어다. 2026년 기준 가장 오래된 "현대 설정 언어"다.

Dhall의 디자인 철학:

  • 총체적(total): 모든 평가가 반드시 끝난다. 무한 루프 불가능
  • 순수 함수형: Haskell 영향 매우 강함
  • 의존 타입 일부: 함수 시그니처에 값 제약 가능
  • 임포트가 1급 시민: URL/파일에서 import, 해시로 무결성 검증
let Env = < Dev | Stg | Prod >
let Server =
    { name : Text
    , port : Natural
    , replicas : Natural
    , env : Env
    }

let api : Server =
    { name = "api"
    , port = 8080
    , replicas = 3
    , env = Env.Prod
    }
in api

Dhall은 신뢰의 언어다. URL에서 import한 코드의 해시를 검증할 수 있어서, 누군가 원본을 바꿔도 즉시 탐지된다. 임포트 캐싱도 해시 기반이다. 이게 "공급망 보안" 시대에 다시 주목받고 있다.

또 하나: 변환기. Dhall은 dhall-to-yaml, dhall-to-json, dhall-to-bash, dhall-to-nix 등 거의 모든 포맷으로 변환된다. 그래서 "한 번 Dhall로 쓰고 여러 출력 만들기" 패턴이 가능하다.

2026년 Dhall 위치: 사용자는 적지만 광적이다. Haskell/PureScript 커뮤니티가 주로 쓰고, 일부 보안 의식이 강한 팀이 GitOps에 쓴다. 새 채택은 둔화됐지만 유지보수는 안정적이다. 한국/일본 사용 사례는 거의 없다(소수 함수형 프로그래머만).

Dhall의 약점: 러닝 커브가 매우 가파르다. 함수형 개념(monad는 없지만 fold/recurse)이 익숙하지 않으면 어렵다. 그리고 에코시스템이 작다 — IDE 지원이 CUE/Pkl/KCL보다 약하다.

7장 · Jsonnet — Google의 데이터 템플릿 + Sjsonnet, Tanka, Grafonnet

Jsonnet(jsonnet.org)은 2014년 Google이 BCL(Borg Configuration Language)을 단순화해서 오픈한 것이다. 2026년에도 여전히 가장 널리 쓰이는 "JSON 위의 추상화" 언어다.

Jsonnet의 디자인:

  • JSON의 확장: 모든 JSON은 유효한 Jsonnet
  • 함수, 객체, 상속, 패치: 객체 합성이 강력
  • 튜링 완전: 함수형 + 객체 지향, 재귀 가능
  • 순수: 부작용 없음, 같은 입력 → 같은 출력
local Server(env) = {
    name: "api",
    port: 8080,
    replicas: if env == "prod" then 5 else 1,
    env: env,
};

{
    dev: Server("dev"),
    prod: Server("prod"),
}

Jsonnet 생태계가 2026년에도 강한 이유 3가지:

1. Tanka (Grafana Labs): Jsonnet으로 k8s를 관리하는 도구. Grafana 자사가 모든 인프라를 Tanka로 운영한다고 공개. Helm 대안으로 가장 진지하게 쓰인다.

2. Grafonnet: Jsonnet으로 Grafana 대시보드를 코드로 정의하는 라이브러리. 대시보드 수십 개가 있는 팀의 표준 도구.

3. Sjsonnet (Databricks): Scala로 다시 짠 Jsonnet 인터프리터. 공식 C++ 인터프리터보다 5~50배 빠르다. 대규모 Jsonnet 코드베이스에서 빌드 시간을 극적으로 줄인다.

또: Bazel + Jsonnet 조합도 인기다. Bazel 빌드 정의는 Starlark지만, 생성하는 설정(k8s manifest 등)은 Jsonnet으로 만드는 패턴.

2026년 Jsonnet 사용 사례:

  • Grafana Labs: 전사 인프라 (수백만 줄 Jsonnet)
  • Databricks: 클러스터 설정 (Sjsonnet 자체 개발)
  • Red Hat: OpenShift 설정 일부
  • 카카오: 일부 인프라팀이 Jsonnet으로 k8s GitOps
  • 메르카리: 광고 플랫폼 일부에서 사용 보고

약점: 타입 시스템 없음. CUE/Pkl/KCL과 달리 Jsonnet은 동적 타입이다. 큰 코드베이스에서 리팩토링이 어렵다. 그리고 에러 메시지가 자주 깊은 스택트레이스로 나와 어디서 잘못됐는지 찾기 어렵다.

8장 · HCL (HashiCorp) — Terraform의 언어

HCL(HashiCorp Configuration Language)은 2014년 HashiCorp이 만들었다. 2026년 현재 세계에서 가장 많이 쓰이는 IaC 언어다(Terraform이 압도적). HCL2 기준으로 본다.

variable "env" {
    type = string
}

resource "kubernetes_deployment" "api" {
    metadata {
        name = "api"
    }
    spec {
        replicas = var.env == "prod" ? 5 : 1
        template {
            spec {
                container {
                    name  = "api"
                    image = "myapi:latest"
                }
            }
        }
    }
}

HCL의 디자인:

  • 선언적: 리소스 = 원하는 상태
  • 표현식 가능: for, conditional, function 호출
  • 모듈: 재사용 가능 단위
  • JSON 호환: HCL은 모두 JSON으로 표현 가능(하지만 사람은 HCL 형식 선호)

2024년 HashiCorp의 IBM 인수와 라이선스 변경(BSL) 이후, OpenTofu(Linux Foundation, 2023년 fork)가 빠르게 성장해 2026년 현재 OSS Terraform 대체재로 자리잡았다. 둘 다 HCL을 쓰지만 OpenTofu는 일부 추가 기능을 더 빠르게 도입한다(provider-defined functions, state encryption 등).

HCL의 강점: Terraform 생태계 자체다. 모든 클라우드의 provider가 HCL로 정의되고, 모든 모듈 마켓이 HCL이다. "Terraform 쓰면 HCL 써야 한다"는 사실상 강제다.

약점: Terraform 밖에서는 약하다. Nomad, Vault, Packer 같은 HashiCorp 도구도 HCL을 쓰지만, 그 외 도메인에서는 거의 안 쓰인다. 그리고 튜링 완전 아님(의도적)이라 복잡한 로직은 어렵다 — 그래서 CDK for Terraform(CDKTF)이 나왔다.

9장 · Nix Lang + NixOS — 선언적 시스템의 정수

Nix는 2003년 Eelco Dolstra의 박사 논문에서 시작됐다. 2026년 현재 Nix Lang은 가장 광신적인 사용자 그룹을 가진 설정 언어다. NixOS, nixpkgs, Nix Flakes 생태계가 모두 Nix Lang으로 쓰여 있다.

{ config, pkgs, ... }:
{
    services.nginx = {
        enable = true;
        virtualHosts."example.com" = {
            forceSSL = true;
            enableACME = true;
            locations."/" = {
                root = "/var/www";
            };
        };
    };

    environment.systemPackages = with pkgs; [
        vim
        git
        htop
    ];
}

Nix Lang의 디자인:

  • 순수 함수형, lazy evaluation: 필요한 부분만 평가
  • 재현성: 같은 입력 → 같은 출력, 비트 단위로
  • 변하지 않는 store: /nix/store에 모든 빌드 결과가 해시 디렉터리로
  • Nix Flakes: 입력 잠금(lock), 모듈화

Nix의 매력은 시스템 전체를 코드로다. NixOS는 OS 전체가 Nix 설정으로 정의된다. nix-darwin은 macOS 환경을 그렇게 한다. home-manager는 사용자 dotfiles를 그렇게 한다.

2026년 Nix 위치:

  • Determinate Systems(Nix 창업자 Eelco가 공동 창업): 엔터프라이즈 Nix 서비스
  • NumTide, Tweag 등 Nix 컨설팅 회사가 안정적
  • Jane Street, Anduril 같은 회사가 내부 표준
  • 카카오의 일부 인프라팀이 NixOS 실험을 공개 발표(2025)
  • 일본은 함수형 커뮤니티 일부(Mercari 일부 엔지니어)가 채택

Nix Lang의 악명: 러닝 커브가 잔혹하다. "Nix는 90% 어렵고 10% 마법"이라는 농담이 있다. 에러 메시지가 거의 도움이 안 되고, 문서는 흩어져 있고, 마법 같은 함수가 너무 많다. 하지만 한번 깨우치면 다른 어떤 시스템도 어색해진다고 신도들이 증언한다.

10장 · Starlark — Bazel의 결정론적 Python

Starlark(원래 Skylark)는 Google이 Bazel용으로 만든 Python의 결정론적 서브셋이다. 2020년 사양이 분리되어 오픈됐다. Bazel, Buck2(Meta), Tilt, Pants 같은 빌드 시스템의 설정 언어다.

def deploy_target(name, env, replicas = 3):
    return struct(
        name = name,
        env = env,
        replicas = 5 if env == "prod" else replicas,
    )

api_prod = deploy_target("api", "prod")
api_dev = deploy_target("api", "dev")

Starlark의 디자인 결정:

  • Python 서브셋: 문법은 Python, 의미는 다름
  • 무한 루프 가능하지만 sandbox: while True 가능하지만 시간/메모리 제한
  • 부작용 없음: 파일 I/O, 네트워크, 시계 접근 불가
  • 동결 가능한 객체: 빌드 그래프의 결정론을 보장
  • 재귀 제한: 깊이 제한으로 무한 재귀 방지

핵심 사상: 빌드는 결정적이어야 한다. 같은 입력(소스 + 의존성)이면 같은 출력. 그래야 캐시가 의미 있고, 분산 빌드가 가능하고, 보안 감사가 가능하다. Python을 그대로 쓰면 import 시점에 외부 API를 호출하거나 시계를 읽거나 환경변수를 봐서 결과가 달라진다. Starlark는 그걸 막는다.

2026년 Starlark 위치:

  • Bazel (구글, 광범위): Pinterest, Stripe, Two Sigma, Adobe 등
  • Buck2 (Meta, Rust로 다시 씀, 2023 오픈소스)
  • Tilt (k8s 로컬 개발)
  • Pants (Python/Java 모노레포)
  • 한국: 토스가 일부 모노레포에 Bazel 도입(Starlark) 보고
  • 일본: 메르카리·LINE이 Bazel 광범위 사용

Starlark의 약점: 빌드 도메인 밖에서는 안 쓰인다. "그냥 Python 같은데 왜 따로?" 진입 장벽. 그리고 Bazel 자체의 무게(BUILD 파일, WORKSPACE, MODULE.bazel)가 크다.

11장 · TypeScript-as-config (Pulumi) — 일반 언어로 설정

Pulumi(2018년 창립)는 가장 도발적인 입장을 취한다 — "설정 언어 따위 필요 없다. 그냥 TypeScript/Python/Go/Java를 써라." Pulumi는 일반 프로그래밍 언어로 IaC를 쓰게 해주는 도구다.

import * as k8s from "@pulumi/kubernetes";

const env = process.env.ENV || "dev";
const replicas = env === "prod" ? 5 : 1;

const deployment = new k8s.apps.v1.Deployment("api", {
    spec: {
        replicas: replicas,
        selector: { matchLabels: { app: "api" } },
        template: {
            metadata: { labels: { app: "api" } },
            spec: {
                containers: [{
                    name: "api",
                    image: "myapi:latest",
                }],
            },
        },
    },
});

Pulumi의 주장:

  • IDE 자동완성 무료: TS의 모든 도구 사용
  • 단위 테스트 가능: Jest로 IaC 코드 테스트
  • 추상화 무한: 진짜 프로그래밍 언어다. 라이브러리, 모듈, 상속 모두 가능
  • 타입 안전: provider가 자동 생성된 TS 타입을 제공

또 다른 진영:

  • AWS CDK (TypeScript/Python/Java/Go): AWS CloudFormation을 코드로
  • CDKTF: Terraform을 일반 언어로
  • CDK8s: 쿠버네티스를 일반 언어로
  • SST: AWS 풀스택 TS

2026년 Pulumi 채택:

  • Snowflake, BMW, Mercedes: 엔터프라이즈 표준
  • 2023년 Sapphire Ventures C 라운드 $41M
  • 한국에서는 토스·당근마켓이 일부 도입 보고
  • 일본은 Mercari·SmartHR 등이 Pulumi/CDK 활용

비판: 일반 언어는 너무 강력하다. 무한 루프, 부작용, 비결정성이 가능하다. "어제 plan했는데 오늘 같은 코드가 다른 결과를 내요" 사례가 발생한다. 그래서 Pulumi는 순수성 가드레일(상태 잠금, preview-vs-apply)을 강화하는 방향이다.

12장 · 태스크 러너 — Mage, Earthfile, Just, Taskfile

설정 언어 옆 자리에 태스크 러너 언어가 있다. Make의 후계자 자리를 노리는 4개 강자.

Mage (Go): Go 코드로 빌드 태스크 정의. magefile.go에 함수를 쓰면 그게 태스크다.

//go:build mage
package main

import "github.com/magefile/mage/sh"

func Build() error {
    return sh.Run("go", "build", "./...")
}

func Test() error {
    return sh.Run("go", "test", "./...")
}

Go 개발자에게 친숙. 타입 안전. 하지만 비-Go 프로젝트엔 과하다.

Earthfile (Earthly): Dockerfile + Makefile의 결합. 컨테이너 안에서 빌드 단계 정의.

VERSION 0.7
FROM golang:1.21
WORKDIR /app

build:
    COPY . .
    RUN go build -o myapp .
    SAVE ARTIFACT myapp /myapp

docker:
    FROM alpine
    COPY +build/myapp /myapp
    ENTRYPOINT ["/myapp"]
    SAVE IMAGE myapp:latest

장점: 재현성. 매번 깨끗한 컨테이너에서 빌드해서 "내 머신에선 되는데"가 사라진다. 단점: 컨테이너 빌드 오버헤드가 항상 든다.

Just (justfile): Make의 단순화 버전. 의존성 그래프보다 명령 별칭에 가깝다.

default:
    just --list

build:
    cargo build --release

test:
    cargo test

deploy ENV="dev":
    ./scripts/deploy.sh {{ENV}}

Just는 Rust로 짜여 빠르고, 문법이 깔끔하고, cross-shell이다. 작은 프로젝트에 인기. 한국·일본 개발자에게 빠르게 퍼지고 있다.

Taskfile (Task): YAML 기반 태스크 러너. Go로 작성됨.

version: '3'
tasks:
  build:
    cmds:
      - go build -o myapp .
  test:
    cmds:
      - go test ./...
  deploy:
    deps: [build, test]
    cmds:
      - ./scripts/deploy.sh

YAML이라 학습 부담 적음. 의존성, 변수, watch 모드 지원. Make와 Just의 중간.

2026년 태스크 러너 채택은 언어 친화도로 갈린다. Go 팀 → Mage·Taskfile, Rust 팀 → Just, 컨테이너 우선 팀 → Earthfile, 전통 팀 → Make 유지.

13장 · "그냥 TOML/JSON/YAML 써라" 반대 의견

설정 언어 전쟁의 반대편에는 강력한 보수파가 있다. 그들의 논리는 단순하다.

1. 모든 새 언어는 부채다. 팀이 배워야 하고, 도구가 부족하고, 유지보수자가 떠나면 마이그레이션 지옥이다. YAML/JSON/TOML은 영원하다.

2. 설정은 단순해야 한다. 설정에 로직이 들어가면 그건 코드다. 코드는 코드 저장소에 있어야 한다. 설정 파일이 if/else/for로 가득해지면 그건 잘못된 추상화의 신호다.

3. 도구는 직교: 검증은 JSON Schema, 합성은 Kustomize/Helm, 변수는 환경변수 — 각 문제를 작은 도구로 풀어라. 한 언어가 모든 걸 풀려고 하면 그 언어가 거대해진다.

4. 학습 비용 > 절감 효과: 100명 팀이 CUE를 배우는 데 한 사람당 2주 잡으면 200주 = 4명 분기. 그 시간에 얼마나 많은 기능을 출시할 수 있나?

이 논리는 작은 팀, 단순 도메인에서 매우 맞다. 그래서 2026년에도 새 마이크로서비스의 80%는 그냥 YAML로 시작한다. 설정 언어는 "이게 한계"를 느낀 팀이 도입한다.

흥미로운 절충안:

  • YAML + JSON Schema + 강력한 IDE 검증: 추상화는 없지만 IDE에서 즉시 잡힌다. 2026년 VS Code의 YAML/JSON 확장은 매우 좋아졌다.
  • YAML + Kustomize: 합성을 도구 수준에서 처리. k8s 진영에서 여전히 강력.
  • YAML + cue vet: CUE를 검증만 하는 도구로 쓰고, 데이터는 YAML로 유지. CUE 도입 진입점.

14장 · 한국 / 일본 — 토스, 카카오, 메르카리의 설정 운용

한국 / 일본 기업의 설정 언어 채택 현황을 정리한다(공개 컨퍼런스 발표 + 블로그 기반).

토스 (Toss): 백엔드 마이크로서비스 1,000개 이상 운영. 기본 설정은 application.yml(Spring Boot 관행) + Spring Cloud Config Server. 일부 결제·뱅킹 백엔드는 Pkl PoC를 발표(2025 SLASH 컨퍼런스). 인프라는 Terraform(HCL) + 일부 Pulumi(TS). 모노레포 일부에 Bazel(Starlark) 도입.

카카오 (Kakao): 멀티 클라우드 환경. Jsonnet + Tanka로 일부 인프라 GitOps 운영(2025 if(kakao) 발표). NixOS 실험도 일부 인프라팀이 공개. Terraform(HCL) + ArgoCD ApplicationSet(YAML) 조합이 표준.

네이버 (Naver): 사내 표준은 YAML + Helm + Kustomize. ClovaX 등 AI 인프라 일부에서 Pulumi 도입 발표. nGrinder 같은 도구의 설정은 여전히 properties + YAML.

라인 (LINE): 글로벌 메신저 인프라. Bazel 광범위 사용(Starlark). 일부 팀이 Jsonnet 도입. 메인 IaC는 Terraform(HCL).

메르카리 (Mercari): 마이크로서비스 200개+. 광고·검색 일부에서 Jsonnet 사용 보고. 일부 Java/Kotlin 백엔드가 Pkl 평가 중. Terraform(HCL) + Helm(YAML) 표준.

Sansan, SmartHR, Cybozu 등 일본 SaaS: 대체로 YAML + Helm + Terraform 보수적 조합. 일부가 Pulumi/CDK 도입.

공통 패턴: 하이브리드. 한 언어가 모든 걸 정복하지 못한다. IaC는 HCL, 빌드는 Starlark/Make, k8s는 YAML+Kustomize/Helm, 백엔드 설정은 YAML/Pkl. 팀이 큰 만큼 표준이 여러 개다.

15장 · 누가 무엇을 골라야 하나 — 의사결정 가이드

마지막으로, 우리 팀이 무엇을 골라야 하는지에 대한 실용적 가이드.

Case 1 · k8s YAML이 천 줄 넘는다, 환경 다섯이다

  • 가장 빠른 길: Kustomize. YAML 유지, 도구만 추가. 학습 1일.
  • 다음 단계: Helm. 템플릿이 있다. 학습 1주.
  • 더 본격적: CUE 또는 KCL. 데이터 + 검증 통합. 학습 1개월.
  • 결정 기준: 환경이 단순(3개 이하)이면 Kustomize, 복잡(10개+ 리전·환경 조합)이면 CUE/KCL.

Case 2 · 멀티 클라우드 IaC, 팀에 TS 능숙

  • 정답: Pulumi (TypeScript) 또는 CDK. IDE 자동완성, 단위 테스트, 모듈화.
  • 대안: Terraform(HCL) + CDKTF. HCL 기반이지만 TS로 쓴다.
  • 피해야 할 것: HCL을 모르는 팀이 무리해서 Terraform 도입.

Case 3 · 모노레포 빌드, 100개 패키지

  • 정답: Bazel + Starlark 또는 Buck2 + Starlark. 결정론적 빌드, 캐시.
  • 대안: Pants(Python 중심), Nx(JS/TS 중심).
  • 피해야 할 것: Make로 의존성 그래프 손으로 관리.

Case 4 · Spring Boot 백엔드, application.yml 너무 길다

  • 정답: Pkl. Java/Kotlin SDK 강력, 타입 안전.
  • 대안: 그냥 YAML + Spring Cloud Config + 환경별 프로파일.
  • 학습 비용 1주.

Case 5 · NixOS 매니악, 시스템 전체 재현성

  • 정답: Nix Lang. 다른 선택지 없음.
  • 경고: 학습 1개월~6개월. 팀 동의 필수.

Case 6 · 그냥 GitHub Actions / Docker Compose

  • 정답: YAML 유지. 설정 언어 도입 ROI 안 나옴.
  • 보조: JSON Schema 검증 추가, IDE에서 즉시 잡기.

Case 7 · 단순 CLI 도구 설정

  • 정답: TOML. Rust 진영의 사실상 표준. 사람이 읽기 좋다.
  • 대안: JSON(JS 친화), YAML(파이썬 친화).

Case 8 · Grafana 대시보드 수십 개

  • 정답: Grafonnet (Jsonnet). 대시보드 = 코드.
  • 대안: Terraform Grafana provider.

원칙: 작게 시작. 한 언어로 모든 걸 정복하려 하지 마라. 하이브리드가 정상이다.

16장 · 참고 / References

핵심 사양과 문서:

태스크 러너:

생태계 / 도구:

CNCF 및 표준:

한국 / 일본 컨퍼런스 사례:

배경 / 인터뷰:

토론 / 비판:

이 글은 2026년 5월 시점의 정보이며, 설정 언어 생태계는 빠르게 진화한다. 특히 Pkl(Apple)과 KCL(CNCF)의 채택률은 분기마다 바뀐다. 도입 전 최신 상태 확인을 권장한다.

Discuss on Twitter • View on GitHub