YAML lint
YAML 검사기
YAML의 어디가 왜 잘못되었는지 찾아냅니다.
YAML을 여기에 붙여넣거나 파일을 페이지에 놓으세요
입력하면 JSON이 여기에 표시됩니다
무료 · 무제한 · 가입 불필요 · 모든 오류에 정확한 줄과 열, 쉬운 설명, 제안된 해결책이 함께 제공됩니다.
검사 항목
문법
들여쓰기, 탭, 닫히지 않은 괄호와 따옴표, 잘못된 매핑과 시퀀스.
구조
YAML이 거부하고 JSON에서는 조용히 합쳐져 버릴 중복 키.
참조
존재하지 않는 앵커를 가리키는 별칭과 이름 없이 선언된 앵커.
안전성
페이지를 멈추게 하기 전에 잡아내는 폭주하는 별칭 확장("billion laughs" 형태).
이식성
YAML 1.1과 YAML 1.2 사이에서 의미가 바뀌는 값을 각 버전의 해석 결과와 함께 표시.
태그
!Ref나 !GetAtt처럼 고유 도구 밖에서는 표준 의미가 없는 사용자 정의 태그.
유효한 YAML이 항상 올바른 YAML은 아닙니다
문서는 완벽하게 파싱되면서도 의도와 다른 의미를 가질 수 있습니다. 전형적인 예가 country: no로, 두 YAML 버전 모두에서 유효하지만 한쪽에서는 문자열 "no", 다른 쪽에서는 불리언 false가 됩니다.
그래서 이 검증기는 두 가지를 구분해 보고합니다. 오류는 문서를 전혀 파싱할 수 없다는 뜻입니다. 경고는 파싱은 되지만 다른 도구에서는 값이 다르게 읽힌다는 뜻입니다 — Kubernetes 매니페스트가 클러스터에 도달하기 전에 알아 둘 가치가 있습니다.
고치기 전에 오류를 이해하고 싶다면 흔한 YAML 오류와 해결 방법 가이드가 거의 모든 파싱 실패 뒤의 여섯 가지 실수 — 탭, 따옴표 없는 콜론, 닫히지 않은 괄호, 중복 키, 없는 앵커, 고르지 않은 들여쓰기 — 를 수정 전후 예시와 함께 설명합니다.
자주 묻는 질문
이 YAML 검사기는 무엇을 확인하나요?
먼저 문법입니다. 들여쓰기, 탭, 닫히지 않은 괄호와 따옴표, 형식이 잘못된 매핑과 시퀀스를 찾습니다. 다음은 구조입니다. 중복된 키, 선언된 적 없는 앵커를 가리키는 별칭, 무한히 확장되는 별칭을 찾습니다. 마지막은 이식성입니다. !Ref처럼 자기 도구 밖에서는 의미가 없는 사용자 정의 태그와, YAML 1.1과 YAML 1.2가 다르게 읽는 따옴표 없는 값을 모두 보고합니다. 각 문제에는 줄과 열, 쉬운 설명, 수정 제안, 편집기 표시가 함께 제공됩니다.
YAML이 유효한데 왜 의도대로 동작하지 않나요?
유효하다는 것과 올바르다는 것은 다르기 때문입니다. country: no는 두 YAML 버전 모두에서 오류 없이 파싱되지만 YAML 1.2에서는 문자열 "no", YAML 1.1에서는 불리언 false입니다. 이렇게 오류 하나 없이 목록에서 나라가 사라집니다. 022, 12:30, 1e3도 마찬가지입니다. 이 검사기는 이런 값을 오류가 아닌 경고로 보고합니다. 문서는 파싱되지만 다른 도구는 값을 다르게 읽기 때문입니다. 값을 따옴표로 감싸면 모호함이 사라집니다.
"mapping values are not allowed in this context"는 무슨 뜻인가요?
파서가 이미 값을 읽고 있는 자리에서 콜론과 공백을 발견했다는 뜻입니다. 흔한 원인은 title: Deploy: production처럼 값 자체에 콜론이 들어 있는 따옴표 없는 값이나, 따옴표 없이 쓴 URL입니다. 값을 따옴표로 감싸세요. 다른 원인은 주변 키와 들여쓰기가 다른 키인데, 파서는 이를 이전 값의 일부로 읽습니다.
"found character that cannot start any token"은 무슨 뜻인가요?
거의 항상 들여쓰기에 탭 문자를 쓴 경우이며, YAML은 이를 금지합니다. 탭을 공백으로 바꾸는 편집기에서는 파일을 다른 곳에서 편집하기 전까지 문제가 숨어 있습니다. 탭을 공백으로 바꾸고 같은 계층의 키는 모두 같은 너비로 맞추세요. 검사기가 정확한 줄을 가리킵니다. 잘못 들어간 제어 문자나 값 맨 앞의 @ 또는 백틱에도 같은 메시지가 나타납니다.
"did not find expected key"는 무슨 뜻인가요?
파서가 매핑을 읽는 중에 다음 줄에도 같은 들여쓰기의 키가 있을 것으로 기대했지만 다른 것을 발견했다는 뜻입니다. 보고된 줄의 바로 앞 줄을 보세요. 형제 키보다 공백 하나만큼 더 들여쓴 값, 키가 와야 할 자리에서 목록을 시작하는 하이픈, 따옴표로 감쌌어야 하는 값 중 하나입니다. 닫히지 않은 괄호와 따옴표는 대부분의 파서가 이 메시지로 잘못 보고하지만, 이 검사기는 실제 원인을 찾아냅니다.
Kubernetes나 OpenAPI 같은 스키마에 대해 검증하나요?
아니요. 문서가 올바른 형식의 YAML인지, 모든 파서에서 같은 의미인지를 확인할 뿐, Deployment나 OpenAPI 문서에 어떤 키가 허용되는지는 알지 못합니다. Kubernetes라면 kubectl apply --dry-run=client -f file.yaml이 클러스터 스키마에 대해 매니페스트를 확인합니다. OpenAPI, GitHub Actions, JSON Schema는 여기서 통과한 뒤 해당 형식의 스키마 검증기로 확인하세요.
검증할 때 YAML이 업로드되나요?
아니요. 검증은 브라우저 안에서 실행됩니다. 문서를 보낼 서버 엔드포인트가 없으며 연결을 끊어도 페이지는 계속 동작합니다. 설정 파일에는 호스트 이름, 내부 경로, 때로는 비밀 정보가 들어 있기 때문에 도구를 이렇게 만들었습니다.
명령줄에서 YAML을 검증하려면 어떻게 하나요?
yamllint file.yaml은 문법 오류와 스타일 문제를 보고하며 CI에서 흔히 쓰입니다. yq . file.yaml은 문서를 출력하거나 파싱 오류로 실패합니다. Python에서는 python -c "import sys, yaml; yaml.safe_load(sys.stdin)" < file.yaml이 잘못된 YAML에서 실패하지만, PyYAML은 YAML 1.1을 읽으므로 no도 false로 취급합니다. 어느 것도 위의 검사기처럼 오류를 설명해 주지는 않습니다. 파이프라인을 실패시키는 데는 이 도구들을, 이유를 알아내는 데는 이 페이지를 쓰세요.