본문 바로가기
클라우드/쿠버네티스

📝 YAML의 진화: 쿠버네티스 사용자를 위한 KYAML 톺아보기! ✨

by gasbugs 2025. 9. 9.

안녕하세요, 쿠버네티스 커뮤니티 여러분! 🚀 복잡한 인프라를 코드(IaC)로 관리하는 시대에, 우리는 설정 파일을 작성할 때 YAML을 매우 빈번하게 사용합니다. 하지만 YAML이 가진 유연성만큼이나, 때로는 모호함과 예상치 못한 문제들로 인해 골머리를 앓기도 하는데요.

 

이번 쿠버네티스 v1.34 릴리스에서는 바로 이러한 YAML의 단점들을 보완하고, 쿠버네티스 환경에서 더욱 안전하고 명확하게 설정 파일을 작성할 수 있도록 돕는 KYAML(Kubernetes YAML)이 새롭게 소개될 예정입니다. 오늘은 KYAML이 무엇이며, 왜 필요한지, 그리고 우리의 워크플로우를 어떻게 개선할 수 있는지 자세히 알아보겠습니다!

 

 


🤷‍♀️ YAML, JSON, 그리고 우리가 겪는 어려움

쿠버네티스 매니페스트나 Helm 차트를 작성할 때 우리는 주로 YAML이나 JSON 형식을 사용합니다. 각각의 장단점을 간단히 살펴볼까요?

🧩 YAML의 양날의 검: 유연성과 모호함

YAML은 가독성이 뛰어나고 사람이 읽기 쉬운 형식으로 설계되었습니다. 주석을 지원하며, 텍스트가 풍부하여 복잡한 설정도 직관적으로 표현할 수 있습니다. 하지만 이러한 유연성 때문에 다음과 같은 문제들이 발생하기도 합니다.

  • 들여쓰기(Indentation) 지옥: YAML은 스페이스나 탭 같은 들여쓰기로 구조를 정의하기 때문에, 작은 들여쓰기 오류 하나로 파싱(Parsing) 문제가 발생할 수 있습니다. 😫
  • 모호한 타입 변환: 따옴표 없이 숫자로 보이는 문자열(123)이나 부울 값으로 보이는 문자열(yes, no)은 파싱 시 의도치 않게 숫자나 부울 타입으로 변환될 수 있습니다. (예: "The Norway Bug"라고 불리는, NO가 false로 인식되는 현상) 🤯
  • 맵(Map)과 리스트(List)의 다양한 표기법: 중괄호 {}나 대괄호 [] 없이 들여쓰기로만 맵과 리스트를 표현할 수 있어, 경우에 따라 가독성을 해치고 혼란을 줄 수 있습니다.

 

🧱 JSON의 엄격함: 명확하지만 불편함

JSON은 YAML보다 훨씬 엄격한 문법 규칙을 가지고 있어 모호함이 적고 기계가 파싱하기에 용이합니다. 하지만 개발자 입장에서는 다음과 같은 불편함이 있습니다.

  • 주석 미지원: 설정 파일에 대한 설명을 추가할 수 없어, 파일 자체만으로는 이해하기 어려운 경우가 많습니다. 🥲
  • 엄격한 문법: 모든 키는 반드시 큰따옴표로 묶어야 하고, 후행 쉼표(trailing comma)를 허용하지 않는 등 엄격한 규칙을 준수해야 합니다.

이처럼 YAML과 JSON 모두 쿠버네티스 환경에서 설정 파일을 관리할 때 각자의 장단점과 함께 불편한 지점들이 존재했습니다. 그리고 KYAML은 이러한 문제점들을 해결하기 위해 탄생했습니다!


🌟 KYAML이란 무엇인가?

KYAML은 "Kubernetes YAML"의 약자로, YAML의 안전하고 모호하지 않은 하위 집합입니다. 쿠버네티스 설정 파일을 작성하는 데 특화되어 설계되었으며, YAML의 장점은 유지하면서 단점을 보완하고자 합니다.

가장 중요한 점은, 모든 KYAML 파일은 유효한 YAML 파일이라는 것입니다! 즉, 기존의 어떤 YAML 파서로도 KYAML 문서를 문제없이 파싱할 수 있습니다. 이는 kubectl v1.34부터 KYAML 출력을 요청할 수 있게 되더라도, 기존 YAML 워크플로우에 아무런 영향을 주지 않는다는 것을 의미합니다. (물론, JSON이나 일반 YAML 형식으로도 출력을 요청할 수 있습니다.)


🔑 KYAML의 핵심 규칙 및 장점

KYAML은 YAML의 일부 규칙을 표준화하여 모호함을 줄이고 일관성을 높입니다. 마치 JSON의 명확성에 YAML의 유연함을 더한 느낌이랄까요?

KEP-5295에서 정의된 KYAML의 주요 규칙은 다음과 같습니다.

  1. 값 문자열은 항상 큰따옴표로 묶습니다:
    • YAML (모호할 수 있음): count: 123, status: No
    • KYAML (명확): count: "123", status: "No"
    • 장점: No 같은 문자열이 false로 오인되거나, 숫자로 보이는 문자열이 실제 숫자로 변환되는 것을 방지합니다. 항상 문자열로 명확하게 처리됩니다.
  2. 키(Key)는 모호할 가능성이 없다면 따옴표 없이 사용합니다:
    • YAML (유연): apiVersion: v1, "my-key": value
    • KYAML (유연): apiVersion: v1, "my-key": value (키가 특수 문자를 포함하거나 모호한 경우에만 따옴표 사용)
    • 장점: JSON처럼 모든 키에 따옴표를 강제하지 않아 YAML의 가독성을 유지합니다.
  3. 맵(Mappings/Associative Arrays)은 항상 {} 중괄호를 사용합니다:
    • YAML (다양한 표현):
      metadata:
        name: my-pod
        labels:
          app: nginx
      
    • KYAML (명확):
      metadata: {
        name: "my-pod",
        labels: {
          app: "nginx"
        }
      }
      
    • 장점: 들여쓰기 오류 가능성을 줄이고, 맵의 시작과 끝을 명확히 하여 구조를 시각적으로 쉽게 파악할 수 있습니다.
  4. 리스트(Lists)는 항상 [] 대괄호를 사용합니다:
    • YAML (다양한 표현):
      containers:
        - name: app
          image: myapp:v1
        - name: sidecar
          image: sidecar:v1
      
    • KYAML (명확):
      containers: [
        {name: "app", image: "myapp:v1"},
        {name: "sidecar", image: "sidecar:v1"}
      ]
      
    • 장점: 맵과 동일하게 들여쓰기 문제를 방지하고 리스트의 범위를 명확히 합니다.

❤️‍🔥 KYAML의 추가적인 이점 (JSON 대비)

KYAML은 JSON의 명확성을 따르지만, JSON이 가지지 못한 YAML의 장점도 함께 가져옵니다.

  • 주석 지원: JSON에는 없는 주석 기능을 KYAML은 그대로 지원합니다! 덕분에 설정 파일에 대한 설명을 자유롭게 추가할 수 있습니다. 💬
  • 후행 쉼표 허용: JSON은 문법적으로 후행 쉼표를 허용하지 않지만, KYAML은 허용하여 개발 편의성을 높입니다.

 

📝 KYAML의 주석 사용: 코드에 설명을 더하다

JSON이 가지지 못한 YAML의 큰 장점 중 하나는 바로 **주석(Comments)**입니다. 설정 파일 내에 코드에 대한 설명을 직접 추가할 수 있어, 시간이 지난 후에도 혹은 다른 팀원이 보더라도 쉽게 내용을 이해할 수 있게 돕습니다.

KYAML은 이러한 YAML의 강점을 그대로 계승합니다. JSON과 달리 KYAML에서는 YAML과 동일하게 # 기호를 사용하여 주석을 작성할 수 있습니다.

# 이 부분은 Pod의 API 버전을 정의합니다.
apiVersion: "v1"

# Pod의 종류를 나타냅니다.
kind: "Pod"

# 메타데이터 섹션입니다.
metadata: {
  name: "my-nginx-pod", # Pod의 이름을 지정합니다.
  labels: {             # Pod에 할당될 레이블들입니다.
    app: "nginx"        # 애플리케이션 이름 레이블
  }
}

# 컨테이너 정의 섹션입니다.
containers: [
  {
    name: "nginx-container",  # 컨테이너 이름
    image: "nginx:latest",    # 사용할 Nginx 이미지
    ports: [                  # 컨테이너가 노출할 포트
      {containerPort: 80}     # 80번 포트 노출
    ]
  } # 여기는 컨테이너 정의의 끝입니다.
]

 

위 예시에서 볼 수 있듯이, KYAML은 라인 전체 주석은 물론, 코드 라인 끝에 붙는 인라인(inline) 주석도 완벽하게 지원합니다. 덕분에 apiVersion: "v1"처럼 항상 따옴표로 묶이는 값 형식이나, 중괄호를 사용하는 맵/리스트 형식에서도 주석을 통해 코드의 의도를 명확하게 전달할 수 있습니다.

 

장점:

  • 가독성 향상: 복잡한 설정도 주석 덕분에 쉽게 이해할 수 있습니다.
  • 유지보수 용이: 나중에 설정 파일을 수정하거나 문제 해결 시 주석이 큰 도움이 됩니다.
  • 협업 효율 증대: 팀원 간에 설정 파일의 목적과 동작 방식을 명확히 공유할 수 있습니다.

 


🛠️ KYAML, 어떻게 사용하게 되나요?

쿠버네티스 v1.34부터 kubectl 명령어를 통해 KYAML 형식으로 출력된 리소스를 요청할 수 있을 것으로 예상됩니다. 예를 들어, kubectl get pod my-pod -o kyaml과 같은 명령을 사용할 수 있겠죠.

중요한 점은, 쿠버네티스가 KYAML 형식의 입력을 필수로 요구하지는 않는다는 것입니다. 기존처럼 YAML이나 JSON 형식의 매니페스트를 계속해서 사용할 수 있으며, 쿠버네티스는 앞으로도 이 정책을 변경할 계획이 없다고 밝혔습니다. KYAML은 개발자들이 더 안전하고 명확하게 설정 파일을 작성하고 싶을 때 선택적으로 활용할 수 있는 새로운 옵션이 될 것입니다.


💡 결론: 더 스마트한 쿠버네티스 설정 관리의 시작

KYAML은 YAML의 유연함과 JSON의 명확함을 결합하여, 쿠버네티스 설정 파일 관리의 오랜 난제들을 해결하고자 하는 시도입니다. 특히 휴먼 에러를 줄이고, 복잡한 설정의 가독성을 높이며, 더욱 안전한 타입 처리를 가능하게 함으로써 우리의 개발 경험을 한 단계 끌어올릴 것입니다.

아직 모든 기능이 100% 확정된 것은 아니지만, KYAML의 등장은 쿠버네티스 환경에서 설정 파일을 다루는 방식을 더욱 효율적이고 안정적으로 만들 중요한 변화가 될 것으로 기대됩니다.

앞으로 KYAML이 어떻게 발전하고 사용될지 지속적으로 관심을 가져주세요!


태그: Kubernetes, KYAML, YAML, JSON, 설정 파일, 쿠버네티스 v1.34, KEP-5295, 개발자 도구, Cloud Native, DevOps