엔지니어가 알아야 할 YAML Norway 문제와 JSON ↔ YAML 차이점

평범한 Helm 배포 작업이었습니다. 팀은 멀티 리전 배포를 위한 values.yaml 파일을 조정하는 데 이틀을 보냈습니다. 차트는 로케일 메타데이터를 포함한 Kubernetes ConfigMap을 템플릿화했는데, 여기에는 Norwegian 데이터 센터의 국가 코드가 포함되었습니다. 누군가 country: NO를 입력하고 커밋했습니다. CI 파이프라인은 성공했습니다. 배포가 실행되었습니다.

그러고 나서 알람이 울리기 시작했습니다.

ConfigMap에는 country: "NO" 대신 country: false가 담겨 있었습니다. country 필드를 읽는 모든 다운스트림 서비스는 문자열 대신 불리언을 받았습니다. 문자열 비교가 실패했습니다. 라우팅 로직이 기본값으로 떨어졌습니다. Norway에 머물러야 할 트래픽이 잘못된 지역 엔드포인트에서 처리되었습니다.

근본 원인은 YAML 파일의 인용되지 않은 단일 문자열이었습니다. 사실상 모든 Kubernetes 도구가 사용하는 YAML 1.1은 NO를 불리언 false로 처리합니다. YES, ON, OFF, Y, N, no, yes, on, off, y, n 및 수십 가지 변형도 동일하게 처리됩니다. 경고도 없습니다. 오류도 없습니다. 조용히 잘못됩니다.

JSON은 이 문제가 없습니다. {"country": "NO"}는 항상 문자열입니다. YAML의 암묵적 타입 강제 변환은 가장 큰 편의 기능이자 가장 위험한 함정입니다.

이 가이드는 전체 그림을 다룹니다. Norway 문제가 존재하는 이유, YAML 1.2에서 무엇이 변경되었는지(그리고 대부분의 도구가 왜 무시하는지), 올바른 인용 전략을 작성하는 방법, 초보자가 넘어지는 들여쓰기 규칙, 숫자 정밀도 함정, Kubernetes 매니페스트부터 Terraform 플랜까지 네 가지 실제 변환 시나리오를 다룹니다. 이 함정 없이 JSON 값을 YAML로 안전하게 변환해야 할 때 JSON to YAML 변환기가 Norway 문제 문자열을 자동으로 인용합니다.

JSON vs YAML — 언제 무엇을 사용해야 하나?

Norway 문제를 깊이 살펴보기 전에 각 형식이 실제로 무엇을 위해 최적화되었는지 이해하는 것이 도움됩니다. 두 형식은 서로 대체 가능하지 않습니다 — 각각 특정 맥락에서 더 나은 선택이 되는 설계 중심이 있습니다.

기준	JSON	YAML
구문	엄격 — 중괄호, 인용 부호, 쉼표 필수	유연 — 들여쓰기 기반, 최소 구두점
타입 시스템	명시적: 문자열, 숫자, 불리언, null, 배열, 객체	암묵적 — YAML 1.1은 값 형태로 타입을 추론
사람 가독성	개발자 친화적, 기계 검증 가능	사람 친화적, 직접 편집 쉬움
인용 요건	문자열은 항상 인용	대부분의 스칼라는 인용 없이 가능(Norway의 원인)
주석	미지원	`#`으로 지원
주요 용도	API, 데이터 교환, 현대 설정 시스템	Kubernetes, Docker Compose, Ansible, CI 파이프라인
놀라운 파싱	없음 — 엄격한 파싱	있음 — Norway, 8진수, 타임스탬프
스키마 적용	JSON Schema 생태계	YAML Schema(도구 지원 적음)

JSON이 우세한 경우: 데이터가 시스템 경계를 넘을 때 — REST API, 메시지 큐, 데이터베이스 직렬화. 기계가 파싱하고 기계가 생성하며, 엄격한 구문이 유효성 검사를 간단하게 만듭니다. 전송 전에 구조를 검증하려면 JSON 포맷터를 사용하세요.

YAML이 우세한 경우: 사람이 주요 작성자일 때. Kubernetes 매니페스트, GitHub Actions 워크플로, Helm 차트, Ansible 플레이북 — 이것들은 개발자가 수십 번 읽고 편집하는 파일입니다. 줄어든 구두점과 주석 지원으로 JSON 대비 실제로 더 유지 관리하기 쉽습니다.

문제는 경계에서 발생합니다: 도구가 JSON을 생성하고(kubectl get deploy -o json 또는 terraform show -json처럼) 사람이 결과를 YAML로 버전 관리하거나 편집해야 할 때. 그 변환 지점이 Norway 문제가 사는 곳입니다. 역방향이 필요할 때는 YAML to JSON 변환기가 처리합니다.

Norway 문제 — 깊이 파고들기

Norway 문제는 버그가 아닙니다. 설계된 대로 정확히 동작하는 YAML 1.1 명세의 기능입니다. 왜 이렇게 설계되었는지, 그리고 왜 많은 시스템이 여전히 1.1을 구현하는지 이해하는 것이 이를 피하는 핵심입니다.

”no”, “yes”, “on”, “off”, “y”, “n”이 잘못 파싱되는 이유

YAML 1.1 명세는 사람 친화적이도록 의도된 광범위한 불리언 타입을 정의했습니다. 다음을 모두 true 또는 false로 인식합니다:

True: y, Y, yes, Yes, YES, true, True, TRUE, on, On, ON

False: n, N, no, No, NO, false, False, FALSE, off, Off, OFF

의도는 좋았습니다: 설정 파일은 종종 true/false 대신 yes/no를 사용하며, YAML은 사람들이 설정을 작성하는 자연스러운 방식을 지원하고자 했습니다. 문제는 yes, no, on, off, y, n이 대부분의 애플리케이션에서 완전히 다른 의미를 가진 완벽하게 유효한 문자열 값이기도 하다는 것입니다.

구체적인 YAML에서의 불일치:

# YAML 1.1 (대부분의 파서가 구현하는 버전)
country: NO        # 파싱 결과: country: false   ← 위험
enabled: yes       # 파싱 결과: enabled: true
restart: off       # 파싱 결과: restart: false
language: y        # 파싱 결과: language: true
shell: n           # 파싱 결과: shell: false

# 올바른 예시 — 명시적 문자열 인용으로 타입 추론 무시
country: "NO"      # 파싱 결과: country: "NO"    ← 안전
enabled: "yes"     # 파싱 결과: enabled: "yes"
restart: "off"     # 파싱 결과: restart: "off"
language: "y"      # 파싱 결과: language: "y"
shell: "n"         # 파싱 결과: shell: "n"

JSON과 비교:

{"country": "NO"}

JSON에서 인용 부호 안의 NO는 항상 무조건적으로 문자열입니다. 암묵적 타입 추론이 없습니다. JSON이 장황하게 느껴지게 만드는 엄격함이 동시에 안전하게 만드는 것이기도 합니다.

불리언 강제 변환 외에도 YAML 1.1은 암묵적으로 다음도 변환합니다:

123e4 → 숫자 1230000 (과학적 표기법)
0x1A → 숫자 26 (16진수)
0755 → 숫자 493 (8진수 — Unix 파일 권한 문자열을 망가뜨림)
2024-05-04 → 많은 파서에서 날짜 객체(단순 문자열이 아님)
1_000_000 → 숫자 1000000 (밑줄 구분자)

Norway 문제는 YAML 암묵적 타입 강제 변환 전체 패밀리에서 가장 유명한 사례일 뿐입니다.

YAML 1.1 vs 1.2 — 무엇이 바뀌었나

YAML 1.2는 2009년 출판되었습니다 — YAML 1.1 이후 4년 후입니다. 주요 목표는 YAML을 JSON과 엄격하게 정렬시키고(JSON이 실제로 유효한 YAML 1.2의 부분집합이기 때문에) 놀라운 암묵적 타입 변환을 줄이는 것이었습니다.

YAML 1.2에서:

불리언은 정확히 true와 false(대소문자 구분)로 좁혀졌습니다. 그것뿐입니다. yes, no, on, off는 단순 문자열입니다.
8진수 리터럴은 0o 접두사가 필요합니다(0o755) — 구형 0755는 문자열입니다.
타임스탬프는 암묵적으로 파싱되지 않습니다 — 2024-05-04는 명시적으로 태그하지 않으면 문자열로 유지됩니다.
명세 자체가 JSON의 상위집합이어서 모든 유효한 JSON 문서가 유효한 YAML 1.2입니다.

이론상으로는 YAML 1.2가 Norway 문제를 완전히 해결합니다. 실제로는 생태계가 거의 이동하지 않았습니다.

라이브러리	기본 명세	Norway 위험
PyYAML (Python)	YAML 1.1	있음 — `yaml.safe_load`가 여전히 `NO`를 `False`로 파싱
ruamel.yaml (Python)	YAML 1.2 (선택적)	설정 가능 — 기본적으로 더 안전
js-yaml (Node.js)	YAML 1.1	구버전에서 있음; 새 버전은 `FAILSAFE_SCHEMA` 옵션 제공
eemeli/yaml (Node.js)	YAML 1.2	없음 — 기본 1.2, 또는 명시적 버전 선택 가능
gopkg.in/yaml.v2 (Go)	YAML 1.1	있음
gopkg.in/yaml.v3 (Go)	YAML 1.2	상당히 안전
Kubernetes / Helm	YAML 1.1 (Go yaml.v2 경유)	있음 — 역사적, 마이그레이션 매우 어려움
Ansible	YAML 1.1 (PyYAML 경유)	있음

마이그레이션이 느린 이유는 하위 호환성입니다. 10년 동안 yes/no가 불리언으로 파싱되는 것에 의존해온 시스템은 기존 설정을 망가뜨리지 않고 이 동작을 조용히 변경할 수 없습니다. 특히 Kubernetes는 YAML 파싱 의미론을 변경하면 클러스터 전체에 영향을 미치는 방대한 설치 기반을 가지고 있습니다.

실용적 결론: 명시적으로 구성하지 않은 도구에서는 YAML 1.1 의미론을 가정하세요. 불리언, 타임스탬프, 숫자로 잘못 읽힐 수 있는 문자열은 항상 인용하세요.

프로덕션 시스템이 당하는 방식

Norway 국가 코드가 가장 많이 인용되는 예시인 이유는 직관에 반하기 때문입니다 — NO는 분명한 약어처럼 보이지, 불리언처럼 보이지 않습니다. 하지만 이 패턴은 많은 실제 시나리오에서 반복됩니다:

IATA 공항 코드. Norwegian 공항 Harstad/Narvik의 코드는 EVE입니다. 안전합니다. Oslo Gardermoen은 OSL입니다. 역시 안전합니다. 하지만 YAML을 사용하여 지역 공항 코드를 저장하는 모든 애플리케이션은 no 노선 코드 하나만으로 프로덕션에서 불리언 false가 될 수 있습니다.

환경 변수 이름. ON은 일부 레거시 시스템에서 “활성화됨”을 의미하는 완벽히 유효한 환경 변수 값입니다. OFF가 그 반대입니다. 이 값들을 인용하지 않고 쉘 스크립트에서 YAML로 설정을 마이그레이션하면 조용한 타입 강제 변환이 발생합니다.

이메일 사용자 필드. 이름이나 사용자 이름이 문자 그대로 n, y, 또는 트리거 단어인 사용자는 애플리케이션이 올바른 인용 없이 YAML을 덤프하면 잘못 직렬화됩니다. 이것은 일부 사용자에게만 실패하기 때문에 특히 교묘합니다.

Docker Compose 재시작 정책. restart_policy 필드의 값 "no"는 “재시작하지 않음”을 의미합니다. YAML 왕복 변환에서 인용 부호를 잃으면 값이 false가 되고, Docker Compose는 이를 “재시작 정책 없음”으로 해석하거나 유효성 검사 오류를 발생시킬 수 있습니다 — 어느 쪽이든 컨테이너 재시작 동작이 잘못됩니다.

GitHub Actions shell: 필드. 유효한 쉘 값은 bash, pwsh, python, sh, cmd, powershell입니다. 이들 중 어느 것도 Norway 단어가 아닙니다. 하지만 초안 편집 중에 shell: yes나 shell: on을 입력한 사람은 검증기가 보기도 전에 YAML이 불리언으로 변환되는 것을 보고 놀랄 수 있습니다.

모든 경우에 수정 방법은 동일합니다: 의미론적으로 문자열인 문자열은 사람이 키워드로 인식하는지 여부와 관계없이 인용하세요. JSON to YAML 변환기가 자동으로 이를 적용합니다 — Norway 단어 목록의 모든 값이 출력에서 인용됩니다.

문자열 인용 전략

Norway 단어가 왜 불일치하는지 이해하면 해결책은 사용 사례에 맞는 올바른 인용 전략을 선택하는 것입니다. YAML은 세 가지 모드를 지원하며 각각 다른 트레이드오프가 있습니다.

자동 vs 큰따옴표 vs 작은따옴표

자동 인용(대부분의 변환에 권장)은 라이브러리가 인용이 필요한 때를 결정하도록 합니다. 인용 없이 잘못 읽힐 수 있는 값 — Norway 단어, 숫자, 타임스탬프, YAML 구문처럼 보이는 문자열 — 은 자동으로 인용됩니다. 그 외는 단순 스칼라로 유지됩니다. 이것은 안전하면서도 가장 읽기 좋은 출력을 생성합니다.

# 자동 모드 출력
name: Alice          # 단순 — 모호함 없음
country: "NO"        # 인용됨 — Norway 단어
age: 30              # 단순 — 명확한 숫자
created: "2024-05-04" # 인용됨 — 그렇지 않으면 날짜로 파싱됨
port: "8080"         # 라이브러리에 따라 다름 — 일부는 숫자처럼 보이는 문자열 인용

큰따옴표 문자열은 모든 문자열 값을 큰따옴표로 감쌉니다. 명시적이고 감사 가능합니다 — 모든 독자는 명세를 추론할 필요 없이 이 값들이 문자열임을 알 수 있습니다. 트레이드오프는 장황함과 줄어든 가독성, 특히 깊이 중첩된 설정에서 두드러집니다.

# 큰따옴표 모드
name: "Alice"
country: "NO"
replicas: "3"         # 숫자조차 문자열이 됨 — 스키마 오류를 유발할 수 있음

주의: 대상 스키마가 숫자를 기대하는데 인용된 문자열로 직렬화하면 YAML 파서는 올바르게 문자열 타입으로 파싱하지만 Kubernetes나 다른 엄격한 소비자는 필드를 잘못된 타입으로 거부할 수 있습니다.

작은따옴표 문자열은 YAML 전용 기능입니다 — JSON에는 작은따옴표 구문이 없습니다. 작은따옴표는 리터럴입니다: 내부에 이스케이프 시퀀스가 없습니다. 유일한 특수 케이스는 작은따옴표 안의 작은따옴표를 두 배로 써야 한다는 것입니다(''). 작은따옴표는 백슬래시나 큰따옴표에서 이스케이프가 필요한 특수 문자를 포함하는 문자열에 이상적입니다.

# 작은따옴표 모드
pattern: 'C:\Users\alice\Documents'  # 이스케이프 불필요
regex: '\d+\.\d+'                    # 백슬래시 리터럴

JSON으로 다시 왕복 변환할 JSON-YAML 변환에는 자동 또는 큰따옴표 모드를 선호하세요. 작은따옴표 문자열은 반환 시 YAML 인식 파서가 필요한 YAML 전용 구문을 도입합니다.

블록 스칼라(| 와 >)

YAML의 블록 스칼라 구문은 여러 줄 문자열에 실제로 유용합니다 — JSON이 \n 이스케이프 시퀀스로 어색하게 처리하는 것입니다.

**리터럴 블록 스칼라 |**는 개행을 정확히 유지합니다:

# 리터럴 블록 — 개행 유지
script: |
  #!/bin/bash
  set -euo pipefail
  echo "Starting deployment"
  kubectl apply -f manifest.yaml

# 동등한 JSON 표현(읽기 어려움)
# {"script": "#!/bin/bash\nset -euo pipefail\necho \"Starting deployment\"\nkubectl apply -f manifest.yaml\n"}

**폴딩 블록 스칼라 >**는 줄을 공백으로 합칩니다, 각 개행을 공백으로 변환합니다(빈 줄은 개행이 됨):

# Folded block — newlines become spaces
description: >
  This service handles authentication
  for the entire platform. Supports
  OAuth2, SAML, and API key auth.

# Result: "This service handles authentication for the entire platform. Supports OAuth2, SAML, and API key auth.\n"

블록 스칼라는 TLS 인증서, 여러 줄 쉘 스크립트, YAML 설정의 SQL 쿼리를 삽입하는 데 유용합니다 — JSON 대신 사람이 읽을 수 없는 긴 이스케이프된 한 줄이 되는 시나리오에서 특히 그렇습니다.

JSON에서 YAML로 변환할 때 대부분의 변환기(우리 도구 포함)는 자동 모드를 사용하고 내장된 개행을 감지할 때만 블록 스칼라로 여러 줄 문자열을 표현합니다. 한 줄 문자열은 플로우 스칼라(인용되거나 단순)를 사용합니다. 매니페스트에 커밋하기 전에 출력을 확인하려면 JSON to YAML 변환기를 사용하세요.

들여쓰기 — 2칸 vs 4칸, 탭 금지

YAML의 들여쓰기 규칙은 보이는 것보다 더 엄격합니다. 명세에는 하나의 절대적 규칙과 생태계에 따라 다른 하나의 관례가 있습니다.

절대적 규칙: 탭은 금지됩니다. 모든 들여쓰기 수준은 공백을 사용해야 합니다. YAML 파일의 탭 문자는 대부분의 파서에서 파싱 오류입니다:

# 잘못된 예시 — 탭은 파싱 오류 유발
apiVersion: apps/v1
kind: Deployment
metadata:
	name: my-app     # ← 여기 탭 문자 → ParseError

# 올바른 예시 — 공백만 사용
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app      # ← 두 칸 공백

오류 메시지는 라이브러리마다 다릅니다. Python의 PyYAML에서:

yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token

Go의 yaml.v3에서:

yaml: line 4: found character that cannot start any token

YAML 파일에서 탭을 공백으로 확장하도록 편집기를 설정하세요. VS Code에서는 워크스페이스 설정에 추가하세요: "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2 }.

관례: 2칸 vs 4칸. 둘 다 유효합니다. 생태계 관례는 다릅니다:

생태계	관례	이유
Kubernetes 매니페스트	2칸	공식 문서와 예시가 2칸 사용
Helm 차트	2칸	K8s 관례를 따름
Docker Compose	2칸	공식 compose 명세 예시
GitHub Actions	2칸	공식 워크플로 예시
Ansible 플레이북	2칸	공식 문서
전통적 설정	4칸	JSON 기본 포매팅과 일치

Kubernetes 또는 Docker Compose가 사용할 파일에는 2칸을 사용하세요. 사람과 커스텀 도구만 읽는 독립 설정 파일에는 어느 것이든 작동합니다 — 단, 파일 내에서 일관성을 유지하세요. JSON to YAML 변환기는 기본적으로 2칸 들여쓰기를 사용하며 4칸으로 전환할 수 있습니다.

한 가지 더: 자식 요소는 부모보다 더 들여써야 하지만 추가 공백 수는 임의의 양수(1, 2, 3, 4…)일 수 있습니다 — 블록 내에서 일관성만 유지하면 됩니다. 실제로는 가독성을 위해 항상 2칸 또는 4칸을 사용하세요.

JSON ↔ YAML에서 숫자 처리

두 형식 모두 숫자를 지원하지만 엣지 케이스가 프로덕션 버그를 유발할 만큼 다릅니다.

큰 숫자의 정밀도 손실

자바스크립트의 Number 타입은 64비트 IEEE 754 부동소수점입니다. 2^53 − 1 = 9,007,199,254,740,991까지 정수를 정확히 표현할 수 있습니다. 그 이상에서는 정수 정밀도가 손실됩니다:

// 자바스크립트 정밀도 손실 — YAML 문제가 아니라 JSON 파싱에 영향을 미침
JSON.parse('{"v": 9007199254740993}').v
// → 9007199254740992   (3이 2가 됨 — 1비트 손실)

// 안전 — 2^53 범위 내
JSON.parse('{"v": 9007199254740991}').v
// → 9007199254740991   (정확)

이것이 자바스크립트 환경에서의 JSON-YAML 변환에 중요한 이유는 YAML 직렬화가 시작되기 전에 정밀도가 이미 손실되기 때문입니다. Kubernetes metadata.resourceVersion은 리소스 버전이 안전한 정수 범위를 초과할 수 있기 때문에 특별히 문자열 필드입니다. 작은 숫자처럼 보이는 다른 필드들 — observedGeneration, uid 구성 요소 — 은 더 안전하지만, K8s 응답의 모든 int64 필드는 잠재적으로 영향을 받습니다.

해결 방법:

큰 숫자가 포함된 변환 파이프라인에는 Python이나 Go를 사용하세요 — 둘 다 임의 정수를 네이티브로 처리합니다.
Node.js에서는 BigInt를 지원하는 JSON 파서를 사용하세요: JSON.parse(text, (_, v) => typeof v === 'number' && !Number.isSafeInteger(v) ? BigInt(v) : v).
손실 없이 왕복 변환해야 하는 필드에는 소스에서 문자열로 직렬화하세요.
변환된 YAML을 검토할 때 resourceVersion, generation, 타임스탬프 파생 값 같은 필드를 살펴보세요.

8진수 및 16진수 특이 사항

YAML 1.1은 특정 숫자처럼 보이는 문자열을 10진수가 아닌 정수로 처리합니다:

# YAML 1.1 파싱 놀라움
permissions: 0755   # 8진수 493으로 파싱, 소수점 755가 아님
value: 0x1A         # 16진수 26으로 파싱, 문자열 "0x1A"가 아님

# YAML 1.2 동작
permissions: 0755   # 정수 755로 유지(소수점) — 8진수는 0o 접두사 필요
permissions: 0o755  # 1.1과 1.2 모두에서 8진수 493으로 파싱

# 두 명세 모두에서 안전 — 선행 0이 있는 값은 인용
permissions: "0755"  # 항상 문자열 "0755"

8진수 함정은 Unix 파일 권한, 선행 0이 있는 IP 주소 구성 요소(일부 네트워크 장치), 패딩에 선행 0을 사용하는 모든 숫자 코드(우편번호, 제품 코드)에 특히 위험합니다. YAML을 직접 작성할 때는 항상 이러한 값을 인용하거나, 변환기가 인용하는지 확인하세요 — JSON to YAML 변환기는 JSON의 숫자 문자열을 감지하고 문자열 타입을 유지합니다.

실제 변환 시나리오

Norway 문제와 인용 전략은 실제 변환 시나리오에 적용할 때 구체적으로 다가옵니다.

JSON에서 Kubernetes 매니페스트로

표준 워크플로: kubectl get deploy my-app -o json은 라이브 오브젝트를 JSON으로 제공합니다. status, creationTimestamp, 관리 필드를 제거하고 YAML 매니페스트로 git에 체크인하려 합니다.

소스 JSON (축약):

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "my-app",
    "namespace": "production",
    "labels": {
      "app": "my-app",
      "region": "NO"
    }
  },
  "spec": {
    "replicas": 3,
    "selector": {
      "matchLabels": { "app": "my-app" }
    },
    "template": {
      "spec": {
        "containers": [{
          "name": "app",
          "image": "registry.example.com/my-app:v1.2.3",
          "env": [
            { "name": "REGION", "value": "NO" },
            { "name": "ENABLE_FEATURE", "value": "yes" }
          ]
        }]
      }
    }
  }
}

예상 YAML 출력 (Norway 보호 포함):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
    region: "NO"          # 인용됨 — Norway 단어
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/my-app:v1.2.3
          env:
            - name: REGION
              value: "NO"           # 인용됨 — Norway 단어
            - name: ENABLE_FEATURE
              value: "yes"          # 인용됨 — Norway 단어

replicas: 3이 인용되지 않았음을 주목하세요 — Kubernetes가 숫자로 기대하는 합법적인 정수입니다. labels와 env 값의 Norway 단어는 인용됩니다. YAML 1.1 불리언을 처리하지 않는 단순한 변환기는 조용히 region: false와 value: false를 생성합니다.

변환 후 다음으로 검증하세요: kubectl apply --dry-run=client -f manifest.yaml. 클러스터에 영향을 주지 않고 스키마 오류를 잡습니다.

JSON to YAML 변환기에서 변환을 시도하세요 — 위의 JSON을 붙여넣으면 Norway 안전 출력을 즉시 확인할 수 있습니다. 왕복 변환을 검증하려면 YAML to JSON 변환기를 사용하세요.

JSON에서 Docker Compose로

CI/CD 파이프라인은 때때로 JSON 설정 저장소에서 프로그래밍 방식으로 Docker Compose 설정을 생성한 후 개발자가 읽을 YAML로 디스크에 씁니다.

중요한 함정 — 재시작 정책:

{"restart_policy": "no"}

Compose에서 restart_policy: "no"는 “컨테이너를 재시작하지 않음”을 의미하는 유효한 값입니다. YAML에서 인용 부호 없이는 restart_policy: false가 되며, Docker Compose는 같은 의미(falsy = 재시작 없음)로 처리하거나 타입 유효성 검사 오류를 발생시킬 수 있습니다 — Compose 버전에 따라 동작이 다릅니다. 인용이 필수입니다.

주의해야 할 사항도 있습니다: Compose v3 deploy.restart_policy.condition: "on-failure" — on-failure 값에는 on이라는 단어가 포함되어 있지만 하이픈이 있어 트리거 목록에 없으므로 실제로 안전합니다. 하지만 condition: on(-failure 없이)은 불일치가 발생합니다. environment: 블록의 환경 변수 값이 Norway 단어일 수 있다면 인용하세요.

변환 후 Compose 파일을 검증하세요: docker-compose config가 표준 형식으로 파싱하고 다시 출력하여 타입 오류를 표시합니다.

GitHub Actions 워크플로

GitHub Actions 워크플로는 개발자가 직접 편집하는 YAML 파일입니다. 가장 일반적인 변환 시나리오는 GitHub API에서 워크플로 데이터를 읽어(JSON으로 반환) 편집을 위해 로컬 YAML 파일로 변환하는 것입니다.

주의해야 할 주요 필드:

# 안전 — 표준 GitHub Actions에는 Norway 단어 없음
on:                        # "on"은 여기서 값이 아닌 YAML 키 — 다르게 처리됨
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          npm install
          npm test
        env:
          NODE_ENV: production   # 안전 — Norway 단어 아님
          DEBUG: "off"           # 값의 Norway 단어 — 인용 필요

참고: YAML 키로서 on:은 특별합니다 — Norway 문제는 키가 아닌 값에 적용됩니다. 하지만 값으로서 on(예: DEBUG: on)은 강제 변환을 트리거합니다. env: 블록은 환경 변수 값이 문자열이지만 Norway 단어와 충돌할 수 있는 짧은 플래그가 많기 때문에 특별히 주의가 필요합니다.

shell: 명세가 포함된 워크플로의 경우 유효한 값(bash, pwsh, sh, python)은 모두 Norway 강제 변환으로부터 안전합니다. 커스텀 값은 사전에 인용해야 합니다.

Terraform JSON 플랜 → YAML

terraform show -json tfplan > plan.json은 Terraform이 생성, 수정, 삭제할 계획을 상세한 JSON으로 출력합니다. 이를 YAML로 변환하면 풀 리퀘스트 검토와 컴플라이언스 감사를 위해 더 읽기 쉬워집니다.

terraform plan -out=tfplan
terraform show -json tfplan > plan.json
# 그런 다음 도구 또는 라이브러리로 변환

Terraform 플랜 JSON은 복잡하고 깊습니다. 변환 시 주요 고려 사항:

큰 정수 ID. 클라우드 리소스 ID(AWS 계정 ID, GCP 프로젝트 번호)와 계산된 속성 값은 큰 숫자일 수 있습니다. float64 정밀도 손실을 피하려면 Python이나 Go를 통해 변환하세요.
버전 제약 문자열. Terraform은 공급자 버전 제약에 ~>, >=, <=를 사용합니다. 이것들은 Norway 단어가 아닌 한 YAML이 올바르게 처리하는 문자열 값입니다 — ~>는 안전합니다.
공급자 설정 값. Terraform 플랜 출력에는 리소스의 설정 값이 포함될 수 있습니다. 불리언 필드가 기본적으로 false이고 일부 공급자 스키마에서 "no"로 표현된다면 YAML로 돌아갈 때 Norway 위험이 있습니다.
.sensitive_values 블록. 민감한 값은 플랜 JSON에서 true 불리언으로 수정됩니다. 이것들은 true가 두 YAML 버전 모두에서 Norway 단어가 아니므로 변환을 깔끔하게 통과합니다.

Terraform-YAML 변환은 주로 사람 검토용이지 Terraform에 다시 입력하기 위한 것이 아닙니다. Terraform 입력으로 YAML 매니페스트를 사용하지 마세요 — Terraform의 네이티브 형식은 HCL이며 JSON 입력 형식은 별도로 문서화되어 있습니다.

코드 예시 — 4개 언어

Node.js (eemeli/yaml + js-yaml)

Node.js 생태계에는 Norway 처리가 의미 있게 다른 두 가지 주요 YAML 라이브러리가 있습니다:

// eemeli/yaml — 권장, 기본 YAML 1.2, Norway 안전
import { stringify } from 'yaml';
import { readFileSync } from 'fs';

const jsonInput = readFileSync('input.json', 'utf8');
const data = JSON.parse(jsonInput);

// 기본: YAML 1.2 — "NO"는 "NO"로 유지, 불리언 강제 없음
const yamlOutput = stringify(data);
console.log(yamlOutput);
// region: NO      ← 1.2에서 안전하지만 최대 호환성을 위해 명시적으로 인용

// YAML 1.1 동작 강제 (1.1을 파싱하는 K8s/Helm 환경용)
const yamlForK8s = stringify(data, { version: '1.1' });
// region: 'NO'    ← NO가 false로 파싱되기 때문에 자동 인용
console.log(yamlForK8s);

// js-yaml — 광범위하게 사용되지만 YAML 1.1 의미론, 주의하지 않으면 Norway 위험
import yaml from 'js-yaml';
import { readFileSync } from 'fs';

const data = JSON.parse(readFileSync('input.json', 'utf8'));

// 기본 덤프 — Norway 단어가 인용되지 않을 수 있음
const unsafe = yaml.dump(data);
// region: NO    ← 1.1 파서로 다시 읽으면 false로 파싱됨!

// 더 안전: 커스텀 스키마 사용 또는 인용 강제
const safer = yaml.dump(data, {
  schema: yaml.JSON_SCHEMA,   // JSON 호환 타입으로 제한
  noCompatMode: false,
  lineWidth: -1,
  quotingType: '"',
  forceQuotes: false,         // JSON 스키마당 필요할 때만 인용
});

새 프로젝트에는 eemeli/yaml을 선호하세요. YAML 1.2 기본이 더 안전하고, Document API가 인용에 대한 세밀한 제어를 제공하며, 왕복 변환 충실도를 더 잘 처리합니다. 이미 js-yaml을 사용하는 프로젝트에는 JSON 안전 타입으로 제한하는 JSON_SCHEMA 옵션을 사용하세요.

Python (PyYAML + ruamel.yaml)

Python은 Kubernetes 도구, Ansible, 데이터 엔지니어링 파이프라인의 주요 언어입니다 — 모두 YAML을 많이 사용합니다.

import json
import yaml
import sys

# PyYAML — 간단, 표준이지만 기본 YAML 1.1
with open('input.json') as f:
    data = json.load(f)

output = yaml.dump(data, default_flow_style=False, allow_unicode=True)
# country: 'NO'   ← PyYAML은 Norway 단어를 자동 인용할 만큼 스마트
# 하지만 모든 설정에서 "yes", "no"(소문자)를 인용하지 않음:
# enabled: 'yes'   ← 인용됨
# tag: y           ← 버전에 따라 인용될 수도 있고 아닐 수도 있음

print(output)

import json
import sys
from ruamel.yaml import YAML

# ruamel.yaml — 왕복 충실도, YAML 1.2 지원, 프로덕션에 권장
yaml_rt = YAML()
yaml_rt.default_flow_style = False
yaml_rt.width = 4096              # 원치 않는 줄 바꿈 방지
yaml_rt.best_map_flow_style = False

with open('input.json') as f:
    data = json.load(f)

yaml_rt.dump(data, sys.stdout)
# 키 순서 유지, Norway 단어 올바르게 처리, 왕복 변환 시 앵커 지원

JSON API 응답을 YAML 매니페스트로 변환하는 Ansible 및 Kubernetes 자동화 스크립트에는 ruamel.yaml이 더 안전한 선택입니다. PyYAML은 입력 데이터를 제어하고 Norway 단어가 없음을 확인한 간단한 스크립트에 적합합니다.

Go (gopkg.in/yaml.v3)

Go는 Kubernetes 생태계 자체의 언어입니다 — kubectl, Helm, Argo, Flux, 대부분의 K8s 운영자가 Go로 작성되었습니다.

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    // JSON 입력 읽기
    jsonBytes, err := os.ReadFile("input.json")
    if err != nil {
        panic(err)
    }

    // JSON을 제네릭 맵으로 언마샬링
    var data map[string]interface{}
    if err := json.Unmarshal(jsonBytes, &data); err != nil {
        panic(err)
    }

    // YAML로 마샬링 — yaml.v3는 YAML 1.2 의미론 사용
    yamlBytes, err := yaml.Marshal(data)
    if err != nil {
        panic(err)
    }

    fmt.Println(string(yamlBytes))
    // country: "NO"     ← yaml.v3는 Norway 단어를 올바르게 인용
    // replicas: 3       ← 정수는 정수로 유지
    // enabled: true     ← 불리언은 불리언으로 유지
}

yaml.v3는 Norway 안전성 면에서 yaml.v2의 큰 개선입니다. v2 라이브러리는 YAML 1.1을 따라 NO를 인용 없이 썼습니다. v3는 모호한 값을 올바르게 인용합니다. v2를 사용하는 구버전 Go 프로젝트를 유지 관리 중이라면 v3로 업그레이드하세요 — API가 대부분 호환되고 안전성 개선이 마이그레이션 가치가 있습니다.

Go 구조체를 사용한 타입 안전 변환(map[string]interface{} 대신)에는 구조체 태그를 사용하세요:

type DeploymentLabels struct {
    App    string `yaml:"app" json:"app"`
    Region string `yaml:"region" json:"region"`
}
// v3에서 "NO"를 포함하는 구조체 필드의 yaml.Marshal은 올바르게 인용함

Bash CLI (yq + jq)

쉘 스크립트와 빠른 일회성 변환에는 yq(Mike Farah 버전, mikefarah/yq)가 단일 명령으로 JSON을 YAML로 변환합니다:

# yq 설치
brew install yq                         # macOS
sudo wget -qO /usr/local/bin/yq \
  https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
chmod +x /usr/local/bin/yq              # Linux

# JSON 파일을 YAML로 변환
yq -P < input.json > output.yaml

# kubectl JSON 출력에서 변환
kubectl get deploy my-app -o json | yq -P > manifest.yaml

# 먼저 jq로 필터/변환 후 YAML로 변환
kubectl get deploy my-app -o json \
  | jq 'del(.status, .metadata.creationTimestamp, .metadata.managedFields)' \
  | yq -P > clean-manifest.yaml

jq | yq 파이프라인은 강력한 패턴입니다: JSON 조작(필드 필터링, 구조 변형, 값 쿼리)에는 jq를, 최종 YAML 직렬화에는 yq -P를 사용하세요.

yq의 Norway 주의 사항: yq(mikefarah)는 JSON의 입력 타입을 존중합니다 — 입력의 JSON 문자열 "NO"는 인용 부호가 있는 YAML 문자열로 직렬화됩니다. 하지만 JSON 입력이 아닌 yq로 직접 YAML을 생성하면 Norway 단어 값을 명시적으로 인용해야 합니다. yq 출력 후 왕복 변환을 검증하려면 YAML to JSON 변환기를 사용하세요.

엣지 케이스와 함정

Norway 문제 외에도 JSON ↔ YAML 변환에는 숙련된 엔지니어도 넘어지는 여러 엣지 케이스가 있습니다:

다중 문서 YAML(--- 구분자). 단일 YAML 파일은 ---로 구분된 여러 문서를 포함할 수 있습니다. JSON에는 동등한 개념이 없습니다. 다중 문서 YAML을 JSON으로 변환할 때 대부분의 도구는 첫 번째 문서만 가져오거나, 모든 문서를 배열로 병합하거나, 오류를 발생시킵니다. JSON을 YAML로 변환할 때는 관례적으로 단일 --- 문서 헤더가 추가됩니다. 다중 문서 파일을 만날 수 있는 파이프라인에 대해 동작을 명시적으로 결정하고 문서화하세요.
YAML 앵커와 별칭. YAML은 DRY 설정을 위해 &anchor 정의와 *alias 참조를 지원합니다. YAML을 JSON으로 변환할 때 앵커를 확장해야 합니다 — 결과 JSON이 소스 YAML보다 훨씬 클 수 있습니다. JSON을 YAML로 변환할 때 변환기는 원본에 없었던 앵커를 재구성할 수 없습니다. 별칭은 YAML 전용 기능입니다.
타임스탬프 암묵적 파싱. YAML 1.1 파서는 2024-05-04와 2024-05-04T12:00:00Z를 문자열이 아닌 언어 네이티브 날짜 객체로 변환합니다. 이 날짜 객체를 JSON으로 다시 직렬화할 때 출력은 라이브러리에 따라 다릅니다: 일부는 ISO 문자열을 출력하고, 일부는 Unix 타임스탬프를 출력하고, 일부는 null을 출력합니다. 명시적 문자열 인용("2024-05-04") 없이 YAML을 통해 날짜를 왕복 변환하면 형식이 조용히 변경될 수 있습니다.
!!binary 태그. YAML은 !!binary 태그로 base64 인코딩된 이진 데이터를 삽입할 수 있습니다. JSON에는 이진 타입이 없습니다 — 이진은 base64 문자열이어야 합니다. !!binary 필드가 있는 YAML을 JSON으로 변환할 때 base64 문자열로 디코딩하세요. 역변환할 때 스키마를 알지 못하면 이진 태그를 재구성할 수 없습니다. Kubernetes는 일부 시크릿 값에 !!binary를 사용합니다.
키 타입 충돌. JSON은 객체 키가 문자열이어야 합니다. YAML은 모든 타입의 키를 허용합니다 — 정수 키, 불리언 키, 심지어 복잡한 객체 키. true: value 또는 1: value를 키로 가진 YAML 파일은 JSON으로 충실하게 표현할 수 없습니다. 대부분의 변환기는 키를 문자열화하지만 의미론이 변경됩니다.
Null 표현 변형. YAML에서 null, ~, Null, NULL, 빈 값은 모두 null을 의미합니다. JSON에서는 null만 null입니다. YAML을 JSON으로 변환할 때 이것들 모두 null로 정규화됩니다. 하지만 JSON을 YAML로 역변환할 때 null 표현 선택이 중요합니다 — ~가 더 간결하고 null이 더 명시적입니다. 하나를 선택하고 일관성을 유지하세요.
정렬 순서 변경. JSON 객체는 기술적으로 정의된 키 순서가 없습니다(대부분의 파서가 삽입 순서를 유지하지만). YAML 매핑도 마찬가지로 필수 순서가 없습니다. 하지만 일부 YAML 라이브러리는 직렬화 시 기본적으로 키를 알파벳순으로 정렬합니다. 소스 JSON이 다른 순서를 사용했다면 버전 관리에서 큰 diff가 발생할 수 있습니다. PyYAML에서 sort_keys=False(default_flow_style=False만으로는 정렬을 방지하지 못함)를 설정하고 다른 라이브러리에서도 동등한 옵션을 설정하세요.

변환하지 말아야 할 때

변환이 항상 정답은 아닙니다. 원본 형식을 유지하는 것이 더 나은 선택인 시나리오:

비즈니스 로직을 문서화하는 주석이 포함된 YAML을 JSON으로 변환하지 마세요. YAML 주석은 데이터 모델의 일부가 아닙니다 — JSON으로의 직렬화에서 사라집니다. Kubernetes 매니페스트에 특정 리소스 제한이 선택된 이유나 보안 정책 예외가 만들어진 이유를 설명하는 주석이 있다면 JSON으로 변환하면 해당 문서가 파괴됩니다. YAML을 유지하세요.

왕복 변환 테스트 없이 CI 파이프라인에서 설정을 자동 변환하지 마세요. 파이프라인이 JSON을 YAML로 변환하고 YAML을 클러스터에 적용하면 왕복 검증 단계를 추가하세요: YAML을 다시 JSON으로, 그런 다음 원본과 비교합니다. 이것은 타입 강제 변환 놀라움이 프로덕션에 도달하기 전에 잡습니다.

도구가 JSON을 출력한다는 이유만으로 변환하지 마세요. kubectl, aws, terraform, docker inspect는 모두 JSON을 출력하지만 이러한 도구 대부분은 YAML도 입력으로 허용합니다. 변환 단계를 구축하기 전에 대상 도구가 YAML 입력을 직접 허용하는지 확인하세요 — 대부분의 현대 DevOps 도구가 그렇습니다. YAML to JSON 변환기는 YAML을 허용하지 않는 도구에 특별히 JSON이 필요할 때 가장 유용합니다.

스키마가 다른 경우 변환하지 마세요. JSON은 camelCase 키를 사용하고 YAML 소비자는 snake_case를 기대하는 경우(또는 반대로), 형식 변환 외에도 변환 단계가 필요합니다. 단순 형식 변환은 구문적으로 올바르지만 의미론적으로 잘못된 YAML을 생성합니다. 스키마 매핑을 명시적으로 처리하세요.

두 형식을 수동으로 동기화 상태로 유지하지 마세요. config.json과 동등해야 하는 config.yaml을 유지 관리하고 있다면 서로 달라질 것입니다. 하나의 표준 형식을 선택하고 다른 것을 자동으로 파생하거나 — 더 나은 방법은 하나의 형식을 선택하고 중복을 제거하는 것입니다.

자주 묻는 질문

YAML Norway 문제가 현대 시스템에 여전히 영향을 미치나요?

그렇습니다 — 생태계에 만연합니다. Kubernetes와 Helm은 코드베이스의 상당 부분에서 Go의 yaml.v2 라이브러리(YAML 1.1 의미론)를 사용합니다. Ansible은 PyYAML(YAML 1.1)을 사용합니다. GitHub Actions 워크플로는 GitHub의 내부 YAML 파서가 파싱하며 자체 동작이 있습니다. 실제 대부분의 CI/CD YAML 파일은 YAML 1.1 파서로 처리됩니다. 명시적으로 구성하지 않았다면 1.1 의미론을 가정하세요.

YAML이 파싱하기 더 어려운데 왜 JSON을 YAML로 변환하나요?

변환은 파서 어려움에 관한 것이 아닙니다 — 사람이 편집하기 용이함에 관한 것입니다. JSON은 기계에 이상적이고, YAML은 설정 파일을 읽고, 편집하고, 검토해야 하는 사람에게 이상적입니다. git에 체크인되고, 풀 리퀘스트에서 검토되고, 엔지니어가 직접 조정하는 Kubernetes 매니페스트는 YAML이어야 합니다. 프로그래밍 방식의 처리를 위해 API에서 가져온 동일한 매니페스트는 JSON이어야 합니다. JSON to YAML 변환기가 두 가지를 연결합니다.

JSON ↔ YAML을 손실 없이 왕복 변환할 수 있나요?

주의 사항이 있지만, JSON 호환 데이터에 대해서는 그렇습니다. JSON은 YAML 1.2의 부분집합이므로 모든 유효한 JSON 문서가 유효한 YAML 1.2입니다. JSON → YAML → JSON은 암묵적 타입 강제 변환이 없는 모든 데이터에 대해 손실 없이 이루어져야 합니다. Norway 문제는 JSON 문자열 "NO"가 변환기가 인용하는 경우에만 순방향 패스를 통과하고, YAML 파서가 인용을 존중하는 경우에만 역방향 패스를 통과한다는 것을 의미합니다. 손실 없는 왕복 변환을 보장하려면 두 방향 모두 YAML 1.2 라이브러리를 사용하세요.

프로덕션에서 가장 안전한 YAML 라이브러리는 무엇인가요?

Python: YAML 1.2용으로 구성된 ruamel.yaml. Node.js: eemeli/yaml(npm의 yaml 패키지). Go: gopkg.in/yaml.v3. 세 가지 모두 YAML 1.2 의미론을 구현하거나 명시적 YAML 1.2 모드가 있으며 Norway 단어를 올바르게 처리합니다. 새 프로젝트에서는 YAML 1.1 라이브러리를 피하세요. 호환성 이유로 1.1 라이브러리(PyYAML, js-yaml, yaml.v2)를 사용해야 한다면 항상 Norway 문제 문자열을 명시적으로 인용하세요.

JSON 변환 후 Kubernetes 매니페스트 YAML에 주석을 추가할 수 있나요?

아니요 — 주석은 JSON에서 복구할 수 없습니다. JSON에는 주석 구문이 없으므로 변환할 것이 없습니다. kubectl get deploy -o json을 실행하고 출력을 git 저장을 위해 YAML로 변환하면 결과 YAML에는 주석이 없습니다. Kubernetes 매니페스트의 주석은 변환 후 사람이 작성해야 합니다. 이것이 JSON API를 통해 왕복 변환하는 것보다 직접 작성한 YAML을 표준 소스로 유지하는 것이 종종 더 나은 이유입니다.

resourceVersion이나 나노초 타임스탬프 같은 큰 정수를 어떻게 처리하나요?

Kubernetes metadata.resourceVersion은 의도적으로 문자열 필드입니다 — Kubernetes 팀은 자바스크립트 및 다른 float64 기반 런타임의 JSON 파서가 큰 정수에서 정밀도를 잃는다는 것을 알고 있었습니다. 항상 문자열로 처리하세요. 진정으로 수치적인 큰 정수(일부 추적 시스템의 나노초 에폭 타임스탬프)에는 Python의 int 타입, Go의 int64, Node.js의 BigInt를 사용하세요. 커스텀 reviver 함수 없이 자바스크립트의 JSON.parse()에 통과시키지 마세요. YAML로 변환할 때 이러한 큰 정수는 안전합니다 — YAML에는 정수의 정밀도 제한이 없습니다. 위험은 자바스크립트의 JSON 파서를 통한 왕복 변환에 있습니다.

YAML 1.2가 이미 널리 채택되었나요?

고르게 채택되지 않았습니다. 주요 언어 라이브러리들이 마이그레이션 중입니다: Go의 yaml.v3, Python의 ruamel.yaml, Node.js의 eemeli/yaml이 모두 YAML 1.2를 지원하거나 기본값으로 사용합니다. 하지만 Kubernetes, Ansible, DevOps 생태계의 많은 부분이 하위 호환성 비용 때문에 여전히 YAML 1.1 파서에서 실행됩니다. 새 프로젝트에서 YAML 1.2 채택을 권장하지만, 직접 구성하지 않은 시스템에서는 1.1을 가정하세요.

팀이 설정에 JSON과 YAML 중 무엇을 표준화해야 하나요?

형식이 아닌 목적에 따라 표준화하세요. 코드가 소비하는 설정(API 요청 본문, SDK 설정 파일, 프로그래밍 방식의 도구)에는 JSON을 사용하세요. 사람이 소비하는 설정(Kubernetes 매니페스트, CI 파이프라인, 배포 설정, Ansible 플레이북)에는 YAML을 사용하세요. 같은 설정에 두 가지를 혼용하지 마세요 — 설정 유형별로 하나의 표현을 선택하고 필요하면 변환을 자동화하세요. 변환이 필요할 때 JSON to YAML과 YAML to JSON 변환기 모두 브라우저에서 완전히 실행됩니다 — 데이터가 기기를 벗어나지 않습니다.

지금 바로 사용해보기

실제 파일을 변환할 준비가 되셨나요? JSON to YAML 변환기로 JSON을 안전한 Kubernetes YAML로 변환하세요 — Norway 단어(NO, yes, on, off 및 전체 YAML 1.1 불리언 목록)를 자동으로 인용하고 2칸 또는 4칸 들여쓰기를 선택할 수 있습니다. 역방향의 경우 YAML to JSON 변환기가 앵커, 별칭, 다중 문서 YAML을 처리합니다. 두 도구 모두 브라우저에서 완전히 실행됩니다 — 프로덕션 Kubernetes 매니페스트나 민감한 리소스 설정이 포함된 Terraform 플랜 작업 시 데이터가 기기를 벗어나지 않습니다.

엔지니어를 위한 온라인 YAML Norway 문제와 JSON-YAML 차이점 가이드