모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
왼쪽에 YAML 문서를 붙여 넣으면 오른쪽 패널에 Valid / Invalid 상태와 함께 모든 에러·경고가 줄·열 번호로 함께 표시됩니다. `---`로 구분된 다중 문서도 지원되며 파싱된 문서 개수가 보입니다. 경고에는 파서가 자동 해결하는 중복 맵 키 같은 치명적이지 않은 문제가 포함됩니다.
이 도구는 구문 검증기이며 스키마 검증기가 아닙니다. "YAML 형식이 깨졌다"(들여쓰기 실수, 닫히지 않은 따옴표, 탭 혼용, 잘못된 앵커 참조 등)는 잡아내지만 "Kubernetes 매니페스트에 `metadata.name`이 필요하다"나 "GitHub Actions 워크플로에 알 수 없는 step이 있다" 같은 검증은 하지 않습니다. k8s, GitHub Actions, 자체 JSON Schema에 대한 스키마 검증이 필요하다면 `kubeval`·`actionlint`·`ajv`와 함께 사용하세요. 모든 처리는 `yaml` 파서를 사용해 브라우저 안에서 이루어지므로 설정에서 붙여 넣은 비밀 정보가 기기 밖으로 나가지 않습니다.
apiVersion: v1 kind: ConfigMap metadata: name: app-config data: database_url: postgres://localhost:5432/app retries: 3
Valid · 1 document
표준 2 스페이스 들여쓰기와 적절한 깊이에 배치된 키·값 쌍입니다. 검증기는 문서 개수도 표시하므로 `---`로 이어진 다중 리소스 매니페스트에서도 확인할 수 있습니다.
services:
web:
port: 8080
image: nginxInvalid · line 3, column 1: Tabs are not allowed as indentation in YAML
YAML 1.2 §5.1은 들여쓰기가 기대되는 위치에서 탭 문자를 명시적으로 금지합니다. 대부분의 에디터는 탭을 스페이스로 자동 변환하지만 다른 소스에서 붙여 넣을 때 `\t` 바이트가 그대로 섞여 들어올 수 있습니다. 검증기가 해당 줄을 짚어 주므로 수정이 즉시 가능합니다.
countries: - US - JP - NO - KR
Valid · 1 document (Note: NO is parsed as the boolean false in YAML 1.1)
YAML 1.1은 `yes`·`no`·`on`·`off`와 그 대문자 형태를 불리언으로 다루므로 국가 코드 리스트에서 노르웨이가 사라집니다. 이 도구가 쓰는 `yaml` 라이브러리는 1.2를 기본으로 하므로(불리언은 `true`·`false`만) 이 예시는 문자열로 유지됩니다. 그러나 PyYAML·libyaml·다수의 Ansible과 옛 Ruby 파서는 여전히 1.1을 기본으로 둡니다. 모호한 스칼라는 반드시 따옴표로 감싸세요(`- "NO"`).
내부의 `yaml` 패키지는 기본적으로 YAML 1.2를 사용합니다. 실무에서 가장 큰 차이는 1.1이 `yes/no/on/off/y/n/Y/N`와 그 대문자 형태를 불리언으로 다룬다는 점(노르웨이 문제)이고, 1.2는 불리언을 `true/false`로 좁혔습니다. 1.2는 8진수 리터럴의 혼란도 정리했습니다. 배포 대상이 1.1 파서(다수의 Ansible, 옛 PyYAML)라면 양쪽에서 검증하세요. 이 도구를 통과해도 그쪽에서는 동작이 다를 수 있습니다.
흔한 원인은 탭과 스페이스 혼용입니다. YAML은 들여쓰기 위치에서 탭을 금지하지만 많은 에디터가 탭을 4·8스페이스 폭으로 표시해 시각적으로 구분되지 않습니다. 파일을 16진수 뷰로 열거나 `cat -A`로 `\t` 바이트를 확인하세요. 다른 조용한 원인으로는 문서에서 붙여 넣은 비줄바꿈 공백(U+00A0), 파일 첫머리의 BOM, 플레인 스칼라 안에 섞여 들어간 제어 문자가 있습니다.
아니요. 이 도구는 YAML *구문*만 검증합니다. "`Deployment`에 `spec.template.spec.containers`가 필요하다", "워크플로의 `run:`은 `uses:`와 형제 관계가 될 수 없다" 같은 스키마 규칙에는 스키마 인식 도구가 필요합니다. Kubernetes에는 `kubeval`이나 `kubeconform`, GitHub Actions에는 `actionlint`, 임의의 JSON Schema에는 `ajv-cli`를 쓰세요. 이 도구들은 잘 정형된 YAML을 입력으로 받으므로 본 검증을 통과시킨 뒤 실행하는 순서가 맞습니다.
예. 다중 문서 스트림은 YAML 표준이며 검증기는 문서 개수를 보고합니다. 각 문서는 독립적으로 검증되며, 문서 2의 에러가 있어도 문서 3은 건너뛰지 않습니다. `kubectl apply -f manifest.yaml`도 같은 다중 문서 형식을 받으므로 Helm 차트 출력이나 `kustomize build` 결과가 이런 모양을 띱니다.
YAML 1.2 §6.7은 중복 키를 에러로 규정하지만, 실환경 파서(PyYAML·libyaml·관대 모드의 snakeyaml 등)는 파일을 받아들이고 조용히 마지막 값을 남기는 경우가 많습니다. `yaml` 라이브러리는 실정에 맞춰 복구 가능한 경고로 다룹니다. 문서는 계속 파싱되지만, 경고로 드러나기 때문에 버그가 숨지 않게 됩니다.
이 도구에서는 불가합니다. 검증만 합니다. 상호 변환이 필요하다면 본 사이트의 JSON ↔ YAML 변환기를 사용하세요. YAML은 JSON에 없는 타입(날짜, 집합, 줄바꿈을 보존하는 다중 줄 문자열, 앵커를 통한 참조 등)을 다루므로 YAML → JSON 일방향 변환에서는 이것들이 사라지거나 문자열화됩니다.
YAML(YAML Ain't Markup Language)은 Clark Evans·Ingy döt Net·Oren Ben-Kiki가 설계해 2001년에 처음 공개한, 사람의 편집에 최적화된 데이터 직렬화 언어입니다. 현행 버전은 YAML 1.2.2(2021년 10월). 핵심 데이터 모델은 JSON 호환의 스칼라·시퀀스·맵 트리이며, JSON으로 유효한 것은 모두 YAML로도 유효합니다. 추가로 YAML은 들여쓰기 기반 구조, 주석, 앵커·앨리어스, 다중 문서 스트림, 더 풍부한 스칼라 타입을 제공합니다.
걸려 넘어지는 부분은 표층 구문입니다. 들여쓰기는 스페이스 필수, 들여쓰기 위치에서의 탭 문자는 금지됩니다. 문자열은 플레인(따옴표 없음), 작은따옴표(`''` 외 리터럴), 큰따옴표(이스케이프 가능), 블록(`|`은 줄바꿈 보존, `>`는 접음) 중 하나입니다. 따옴표 없는 스칼라는 불리언(`true`·`false`), 정수, 부동소수, null(`null`·`~`·빈 값), 또는 문자열로 자동 타입화됩니다. 이 점이 YAML 1.1의 악명 높은 노르웨이 문제를 만들었습니다(`no`·`false`·`off`가 모두 불리언 false로 변함). 타입화 리터럴과 헷갈리는 스칼라는 따옴표로 감싸 모호함을 제거하세요.
인접 직렬화 형식은 각자 다른 영역을 담당합니다. **JSON**은 YAML 1.2의 엄격한 부분 집합으로 기계 처리에 적합하지만 사람의 편집에는 장황합니다. **TOML**은 설정 파일을 겨냥하며 더 평탄하고 모호함이 적은 구문을 가집니다. Rust의 `Cargo.toml`이나 Python의 `pyproject.toml`에서 흔합니다. **HCL**(HashiCorp Configuration Language)은 Terraform 구성을 받치며 블록 지향이고 식을 다룰 수 있는 구문을 갖습니다. YAML이 자리를 차지하는 영역은 다중 문서·앵커·사람의 주석이 들여쓰기 엄격함의 대가만큼 가치 있는 분야입니다. Kubernetes 매니페스트, GitHub Actions 워크플로, CI·CD 파이프라인, Ansible 플레이북 같은 곳이 그렇습니다.