검증할 Docker Compose, GitHub Actions, Kubernetes 설정 등 YAML 코드를 입력창에 붙여넣습니다.
개발자 유틸리티
YAML 검증기
YAML 코드를 붙여넣으면 문법 오류, 들여쓰기 문제, 콜론 누락, 배열 구조 문제를 확인하고 JSON 변환 결과까지 확인할 수 있습니다.
YAML 문법 검증
YAML 파서가 읽을 수 있는 문법인지 빠르게 확인합니다. 서비스별 설정 스키마는 별도 검사 대상입니다.
오류 위치 확인
파싱 오류 메시지를 통해 들여쓰기, 콜론, 따옴표 문제를 점검할 수 있습니다.
JSON 변환 지원
정상 YAML을 JSON 형태로 변환해 구조를 더 명확하게 확인할 수 있습니다.
YAML 입력
검증할 YAML 코드를 아래에 붙여넣으세요.
문법 검증 기준
입력한 YAML을 브라우저에서 파싱해 문법 오류를 확인합니다. Docker Compose·GitHub Actions·Kubernetes 규칙은 검증하지 않습니다.
구조 확인
검증이 성공하면 JSON 변환 결과를 함께 제공해 객체와 배열 구조를 확인할 수 있습니다.
검증 결과
YAML 문법 상태와 오류 메시지, JSON 변환 결과를 확인할 수 있습니다.
YAML 코드를 입력한 뒤 검증하기 버튼을 눌러주세요.
YAML 사용 예시
YAML은 설정 파일에서 자주 사용되며, 들여쓰기와 구조가 중요합니다.
Docker Compose
services, volumes, networks처럼 계층 구조가 많은 설정 파일에서 YAML 문법이 자주 사용됩니다.
GitHub Actions
workflow, jobs, steps, uses, run 같은 자동화 설정을 YAML로 작성합니다.
Kubernetes
Deployment, Service, ConfigMap 같은 리소스 정의 파일에 YAML 형식이 널리 사용됩니다.
사용 방법
JSON 변환 결과, 메타 정보 표시, 자동 검증 옵션을 필요에 맞게 켜거나 끕니다.
검증 버튼을 눌러 들여쓰기, 콜론, 따옴표, 배열 구조 오류를 확인합니다.
오류 위치와 메시지를 확인하고, 정상 YAML은 JSON 구조로 비교한 뒤 결과를 복사하거나 다운로드합니다.
도움말
YAML 검증기는 언제 사용하나요?
Docker Compose, GitHub Actions, Kubernetes 설정, CI/CD 설정, 서버 배포 설정처럼 YAML 문법이 중요한 파일을 작성할 때 오류를 빠르게 확인할 수 있습니다.
특히 YAML은 들여쓰기와 공백에 민감하므로, 배포 전 문법 검증을 한 번 거치면 설정 오류를 줄일 수 있습니다.
자주 발생하는 YAML 오류
- 들여쓰기 공백 수가 맞지 않는 경우
- 콜론(:) 뒤에 공백이 없는 경우
- 배열(-)과 객체 구조가 섞인 경우
- 따옴표가 닫히지 않은 경우
- 탭 문자와 공백을 섞어 사용한 경우
YAML에서 들여쓰기는 왜 중요한가요?
YAML은 중괄호 대신 들여쓰기로 계층 구조를 표현합니다. 같은 계층은 같은 공백 수를 가져야 하며, 하위 항목은 상위 항목보다 더 들여써야 합니다.
YAML에서 탭을 사용해도 되나요?
YAML에서는 들여쓰기에 탭보다 공백 사용을 권장합니다. 편집기에서 탭을 공백 2칸 또는 4칸으로 변환하도록 설정하는 것이 안전합니다.
콜론 뒤에는 반드시 공백이 필요한가요?
일반적인 key-value 구조에서는 name: value처럼 콜론 뒤에 공백을 넣는 것이 안전합니다. name:value처럼 붙여 쓰면 의도와 다르게 해석되거나 오류가 발생할 수 있습니다.
YAML을 JSON으로 변환하면 무엇이 좋은가요?
JSON 변환 결과를 보면 YAML의 객체, 배열, 문자열, 숫자 구조가 명확하게 보입니다. 설정 파일이 의도한 구조로 파싱되는지 확인할 때 유용합니다.
민감한 설정 파일을 입력해도 되나요?
이 도구는 브라우저에서 YAML을 검증하는 용도입니다. 그래도 비밀번호, API 키, 토큰, 서버 접속 정보가 포함된 값은 입력 전에 제거하거나 마스킹하는 것을 권장합니다.
YAML 문법 검증과 서비스별 설정 검증을 구분하는 법
YAML 파서가 문서를 읽을 수 있다는 사실은 Docker Compose, GitHub Actions나 Kubernetes가 그 설정을 받아들인다는 뜻이 아닙니다. 먼저 문법과 데이터 구조를 확인한 뒤 사용하는 서비스의 스키마와 명령으로 다시 검증해야 합니다.
이런 분께 유용합니다
- YAML 들여쓰기와 문법 오류를 빠르게 찾는 개발자
- CI/CD와 컨테이너 설정을 검토하는 운영자
- YAML이 어떤 JSON 구조로 해석되는지 확인하려는 사용자
대표 활용 상황
- 콜론·들여쓰기·따옴표 오류를 배포 전에 찾을 때
- 배열과 객체가 의도한 구조로 파싱되는지 볼 때
- 문법 검증 뒤 서비스별 공식 검증 명령을 실행하기 전 1차 점검할 때
처음부터 결과 확인까지
- 1
비밀번호, API 키와 토큰을 제거하거나 마스킹한 YAML을 준비합니다.
- 2
200,000자 이하의 코드를 입력하고 필요하면 JSON과 메타 정보 표시를 선택합니다.
- 3
검증을 실행해 파서 오류의 라인과 컬럼을 확인합니다.
- 4
성공한 경우 JSON 결과에서 문자열·숫자·불리언과 배열 구조가 의도와 같은지 확인합니다.
- 5
앵커·별칭과 병합 키가 과도하거나 순환하지 않는지 검토합니다.
- 6
Docker Compose config, GitHub Actions 편집기, kubectl dry-run 등 대상 서비스의 공식 검증을 추가로 실행합니다.
문법은 유효하지만 서비스 설정은 잘못된 경우
- 입력
- 오타가 있는 Docker Compose 키를 문법에 맞게 작성
- 결과
- YAML 문법 검증 성공
docker compose config 같은 서비스 스키마 검증에서 다시 오류를 찾아야 합니다.
들여쓰기 오류
- 입력
- 같은 계층 항목의 공백 수가 다른 YAML
- 결과
- 라인·컬럼이 포함된 파서 오류
오류 위치 주변의 상위 키와 배열 표시를 함께 확인합니다.
계산·처리 기준
브라우저에서 js-yaml 4.3.0으로 문서를 파싱하고 병합 키 총량 제한을 적용합니다. 입력은 200,000자, 파싱 뒤 고유 객체·배열 노드는 50,000개, 중첩은 100단계로 제한하며 반복 순회로 키 수를 계산합니다.
알아둘 한계
- YAML 문법과 파싱 결과만 검사하며 Docker Compose·GitHub Actions·Kubernetes 스키마는 검증하지 않습니다.
- js-yaml의 스키마와 대상 서비스 파서 사이에 자료형 해석 차이가 있을 수 있습니다.
- 앵커와 별칭이 만든 순환 구조는 유효할 수 있지만 JSON으로 변환할 수 없습니다.
- 브라우저 자원 보호 한도를 넘는 대형·복잡한 문서는 검사하지 않습니다.
개인정보 처리
입력 YAML은 브라우저에서 파싱하며 서버에 저장하지 않습니다. 파서 라이브러리는 외부 CDN에서 내려받으므로 네트워크 연결이 필요하지만 입력 내용은 CDN으로 전송하지 않습니다. 그래도 비밀값은 반드시 제거하세요.
참고 자료
함께 쓰면 좋은 도구
- Docker Compose 생성기
기본 Compose YAML 구조 초안을 만듭니다.
- JSON Formatter
변환한 JSON을 정렬하고 구조를 다시 확인합니다.
자주 묻는 질문
정상이라고 나오면 바로 배포해도 되나요?
아닙니다. YAML 문법만 유효한 상태이므로 대상 서비스의 스키마 검증과 테스트 환경 실행이 필요합니다.
왜 입력 크기와 중첩 깊이를 제한하나요?
의도치 않게 매우 복잡한 문서를 파싱하면서 브라우저가 오래 멈추거나 메모리를 과도하게 쓰는 상황을 줄이기 위한 보호 장치입니다.
민감한 설정도 브라우저 도구에 넣어도 되나요?
로컬 처리 여부와 별개로 복사 기록, 화면 공유와 확장 프로그램 위험이 있으므로 비밀번호와 토큰은 제거한 사본을 사용하세요.