JSON ↔ YAML 변환기

JSON과 YAML은 같은 자료를 담는 두 가지 표기입니다

JSON은 객체를 중괄호 { }로, 배열을 대괄호 [ ]로 묶고 키와 글자를 큰따옴표로 감쌉니다. YAML은 같은 구조를 들여쓰기와 줄 앞의 하이픈(-)으로 나타내고, 대부분의 따옴표를 생략합니다. JSON의 객체는 YAML의 매핑이 되고, 배열은 시퀀스가 됩니다. 숫자·참거짓·null도 서로 대응합니다. YAML 1.2 명세는 이 판의 주된 목표가 YAML을 JSON의 엄격한 상위 집합으로 만드는 것이었다고 밝히며, 그래서 올바른 JSON 문서는 대부분 그대로 YAML로도 읽힙니다.

이 변환기는 두 칸을 모두 편집할 수 있게 열어 두었습니다. JSON 칸을 고치면 YAML 칸이 다시 만들어지고, YAML 칸을 고치면 JSON 칸이 다시 만들어집니다. 가운데 화살표는 지금 어느 칸이 원본인지 가리킵니다. 줄을 클릭하거나 방향키로 옮기면 반대쪽 칸에서 같은 값이 있는 줄이 밝아지고, 아래 경로 줄에 owner › name 같은 위치와 값의 종류가 나옵니다. 들여쓰기만 보고는 어느 항목 아래에 속한 줄인지 헷갈리는 긴 YAML에서 특히 쓸모가 있습니다.

JSON과 YAML을 오가야 하는 때

사람이 고치는 설정 파일은 YAML로, 프로그램끼리 주고받는 자료는 JSON으로 쓰는 경우가 많습니다. 그래서 한 작업 안에서 두 형식을 오가게 됩니다.

• 쿠버네티스 매니페스트: 쿠버네티스 문서는 설정 파일을 JSON보다 YAML로 쓰라고 권합니다. 둘 다 동작하지만 사람이 읽기 쉽다는 이유입니다. 클러스터에서 JSON으로 받아 본 리소스를 YAML 파일로 고쳐 두거나, 반대로 YAML 매니페스트를 JSON만 받는 API나 스크립트에 넘길 때 변환이 필요합니다.
• Docker Compose·GitHub Actions: 두 도구 모두 설정을 YAML로만 받습니다. 예제나 API 응답이 JSON으로 되어 있으면 YAML로 옮겨 붙여 넣어야 하고, 이때 따옴표를 빼먹으면 값의 자료형이 바뀔 수 있습니다.
• 검사와 비교: JSON Schema 검사기나 jq처럼 JSON을 받는 도구로 YAML 설정을 확인하려면 먼저 JSON으로 바꿔야 합니다. 앵커와 병합 키가 많은 Compose 파일은 JSON으로 펼쳐 보면 서비스마다 실제로 어떤 값이 들어가는지 한눈에 보입니다.
• 읽기 전에 함정 확인: 같은 YAML이라도 읽는 프로그램이 YAML 1.1 방식이면 no가 false로, 0755가 493으로 바뀝니다. 설정을 배포하기 전에 아래 해석 점검에서 그런 값이 있는지 확인할 수 있습니다.

쓰는 법

1. JSON이나 YAML 가운데 가지고 있는 쪽 칸에 붙여 넣습니다. 파일 열기 버튼이나 끌어다 놓기로 .json·.yaml·.yml 파일을 열면 확장자에 맞는 칸에 들어갑니다.
2. 반대쪽 칸에 결과가 바로 나옵니다. 결과 칸을 고치면 그 칸이 원본이 되어 처음 칸이 다시 만들어집니다.
3. 줄을 고르면 반대쪽에서 같은 값이 있는 줄이 밝아지고, 나란히 놓인 화면에서는 두 줄 사이에 연결선이 그려집니다. 한쪽을 스크롤하면 반대쪽도 같은 위치로 따라갑니다.
4. 칸 위 옵션에서 들여쓰기(JSON 2칸·4칸·한 줄, YAML 2칸·4칸), YAML 해석 기준(1.2·1.1), 배열을 YAML 문서 여러 개로 나눌지를 고릅니다.
5. 칸 아래 버튼으로 복사하거나 파일로 저장합니다. 연 파일이 app.yaml이었다면 JSON은 app.json으로 저장됩니다.

YAML 1.1과 1.2가 다르게 읽는 값

YAML은 따옴표 없이 쓴 값의 자료형을 글자 모양으로 판단합니다. 그런데 그 규칙이 판마다 다릅니다. YAML 1.2의 Core 스키마는 참거짓을 true·false(대소문자 변형 포함)로만 인정하고, 8진수는 0o로 시작하는 표기만 받습니다. 그보다 앞선 YAML 1.1의 타입 규칙은 yes·no·on·off·y·n을 참거짓으로, 0으로 시작하는 정수를 8진수로, 콜론으로 이은 숫자를 60진수로, 2024-03-01 꼴을 날짜로 읽습니다. 반대로 1.1의 실수 규칙에는 소수점이 있어야 하므로 1e5는 1.1에서 글자가 됩니다.

문제는 지금도 1.1 방식으로 읽는 프로그램이 많다는 점입니다. 파이썬의 PyYAML은 스스로를 완전한 YAML 1.1 해석기라고 소개합니다. Go의 yaml v3는 1.2를 대부분 따르지만 8진수는 1.1처럼 0777로 읽고 쓰며, yes·no·on·off는 불리언 자료형에 담을 때만 참거짓으로 받아들입니다. 쿠버네티스 문서도 불리언 값에는 true나 false만 쓰고 yes·no·on·off는 쓰지 말라고 하며, 불리언처럼 보이는 값은 따옴표로 감싸라고 권합니다. Docker Compose 문서 역시 포트를 HOST:CONTAINER 형식으로 쓸 때는 YAML 60진수와 충돌하지 않도록 늘 따옴표로 감싼 글자로 쓰라고 안내합니다.

마지막 열은 JSON에서 글자였던 값을 YAML로 쓸 때의 모양입니다. 두 판 가운데 어느 한쪽에서라도 글자가 아닌 값으로 읽힐 수 있으면 큰따옴표로 감쌉니다. 8080:80은 뒤쪽 80이 60진수 한 자리(0~59)를 넘어 어느 판에서도 글자라서 따옴표가 필요 없지만, 2222:22처럼 뒤가 59 이하인 포트는 1.1에서 숫자가 됩니다.

YAML 칸이 원본일 때 아래 해석 점검은 문서 안에서 두 판이 다르게 읽는 값을 모두 찾아 줄 번호와 함께 보여 줍니다. 칩을 누르면 그 줄로 이동합니다. 해석 기준을 1.1로 바꾸면 JSON 결과도 1.1 규칙으로 다시 만들어지므로, PyYAML 같은 프로그램이 실제로 받게 될 값을 미리 볼 수 있습니다.

YAML에만 있는 기능은 이렇게 바뀝니다

JSON을 YAML로 바꿀 때는 키 순서를 입력 그대로 지킵니다. 브라우저의 기본 JSON 해석은 "2024"처럼 정수 모양인 키를 객체 맨 앞으로 옮기기 때문에, 이 변환기는 순서를 지키는 자체 해석기로 JSON을 읽습니다. 줄바꿈이 든 글자는 | 블록으로, 빈 객체와 빈 배열은 {}·[]로 씁니다.

숫자는 쓴 글자 그대로 옮깁니다

JSON 명세(RFC 8259)는 배정밀도(IEEE 754 binary64)보다 큰 정밀도를 기대하지 않는 구현끼리 숫자를 잘 주고받을 수 있다고 설명합니다. 브라우저도 숫자를 이 방식으로 다루므로, 보통의 변환기는 9007199254740993을 9007199254740992로, 4.50을 4.5로 바꿔 버립니다. 이 변환기는 숫자를 계산하지 않고 쓴 글자를 그대로 옮겨 이런 변화가 없습니다. YAML 쪽 0o17이나 0x1F처럼 JSON에 없는 표기만 같은 값의 10진수로 바꿉니다.

예외가 하나 있습니다. JSON의 1e5는 YAML 1.2에서는 숫자지만 YAML 1.1에서는 소수점이 없어 글자가 됩니다. 그래서 JSON → YAML에서는 지수 표기를 1.0e+5처럼 소수점과 부호를 넣어 씁니다. 두 판 모두 이 글자를 숫자 100000으로 읽습니다. 해석 점검에 바꿔 쓴 숫자가 표시됩니다.

자주 틀리는 경우

• 들여쓰기에 탭: YAML 명세는 시스템마다 탭을 다르게 다루므로 들여쓰기에 탭 문자를 쓰면 안 된다고 정합니다. 편집기에서 탭을 공백으로 바꾸세요.
• 콜론 뒤 공백: port:8080은 키가 아니라 글자 하나입니다. 키와 값 사이에는 port: 8080처럼 콜론 뒤에 공백이 있어야 합니다.
• 같은 키 두 번: YAML 명세는 매핑의 키가 유일해야 한다고 정하고, JSON 명세는 이름이 겹친 객체를 받은 프로그램의 동작을 예측할 수 없다고 경고합니다. 이 변환기는 어느 쪽이든 겹친 키를 오류로 알립니다. YAML의 1:과 "1":도 JSON에서는 같은 키라서 겹칩니다.
• JSON의 느슨한 문법: 마지막 항목 뒤 쉼표, 작은따옴표, 따옴표 없는 키, // 주석은 표준 JSON이 아닙니다. JSON5나 JSONC로 쓴 설정은 이런 부분을 고친 뒤 넣으세요.
• GitHub Actions의 on:: 워크플로의 on: 키는 YAML 1.2에서 글자 "on"이지만 1.1 방식 해석기에서는 참거짓 true가 됩니다. 워크플로 파일을 파이썬 스크립트로 읽어 고칠 때 키가 사라진 것처럼 보이는 이유입니다.
• 시간·포트 모양 값: 18:30이나 2222:22는 1.1에서 60진수 숫자가 됩니다. 시간과 포트는 따옴표로 감싸 두는 편이 안전합니다.

한계와 주의

• 입력은 5 MB(5,242,880바이트)까지, 결과는 10 MB까지 변환합니다. 파일은 UTF-8(BOM 포함)과 UTF-16 BOM 파일을 엽니다.
• YAML 주석과 따옴표 모양, 빈 줄은 다시 만들 때 남지 않습니다. YAML을 원본으로 쓰다가 JSON 칸을 고치면 YAML이 새로 써지므로, 주석이 있던 YAML은 상태 줄의 되돌리기로 한 번 되살릴 수 있습니다.
• CloudFormation의 !Ref 같은 사용자 태그는 떼고 값만 옮깁니다. CloudFormation이 JSON에서 쓰는 {"Ref": …} 꼴로 바꾸지는 않습니다.
• 별칭을 펼친 양이 지나치게 많으면(별칭 하나가 다시 별칭 묶음을 가리키는 식) 자원 고갈을 막기 위해 멈춥니다.
• YAML 1.1 해석은 yaml.org의 1.1 타입 규칙을 따릅니다. 실제 1.1 방식 프로그램과 다른 경계도 있습니다. 예를 들어 y·n은 이 규칙에서 참거짓이지만 PyYAML은 글자로 읽습니다. JSON → YAML 결과는 이런 값을 모두 따옴표로 감싸므로 어느 쪽에서 읽어도 글자로 남습니다.
• 변환은 문법만 다룹니다. 쿠버네티스나 Compose가 요구하는 키 이름과 값의 종류가 맞는지는 각 도구의 검사 명령으로 확인하세요.

출처

• 01YAML — YAML Ain't Markup Language version 1.2.2§1.2 JSON의 엄격한 상위 집합이 주목표, §3.2.1.1 매핑 키는 유일, §6.1 들여쓰기에 탭 금지, §10.3.2 Core 스키마(null·bool·int·float 해석 표) — 2026-10-20 확인
• 02YAML 1.1 타입 — Boolean, Integer, Floating-Point, Timestamp, Merge Keybool(y·yes·on 등), int(8진수 0…, 60진수), float(소수점 필수, 지수는 부호), timestamp, merge(<<) 규칙 — type/int.html·float.html·timestamp.html·merge.html 함께
• 03IETF — RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format§4 이름은 고유해야 함(SHOULD)·겹치면 동작 예측 불가, §6 binary64 정밀도와 상호 운용, §8.1 UTF-8
• 04Kubernetes — Configuration Overview설정은 JSON보다 YAML로, 불리언은 true·false만, yes·no·on·off 금지, 불리언처럼 보이는 값은 따옴표
• 05Docker Docs — Compose file reference: services(ports)HOST:CONTAINER는 YAML 60진수와 충돌하지 않도록 늘 따옴표로 감싼 글자로
• 06Docker Docs — Fragments앵커(&)·별칭(*)과 YAML 병합 타입(<<)을 쓰는 Compose 파일
• 07go-yaml v3 READMEYAML 1.2 대부분 지원, 1.1 불리언은 불리언 자료형으로 읽을 때만, 8진수는 1.1처럼 0777
• 08PyPI — PyYAML"complete YAML 1.1 parser"
• 09yaml (JavaScript) 문서이 변환기가 쓰는 해석기(2.9.1, ISC). 별칭 펼침 제한, 병합 키는 1.2 명세에 없는 1.1 기능
• 10GitHub Docs — Workflow syntax for GitHub Actions워크플로 파일은 YAML 문법, 확장자 .yml 또는 .yaml

자주 묻는 질문

함께 쓰는 도구