같은 데이터, 아주 다른 두 형식
YAML과 JSON은 같은 데이터 모델, 맵, 시퀀스, 스칼라, 을 기술하므로 둘 사이의 변환은 대체로 기계적입니다. 다른 것은 누구를 위해 설계되었느냐입니다. JSON은 모호하지 않고 기계가 다루기 쉽습니다. YAML은 구두점을 걷어 내고 대신 들여쓰기를 쓰는데, 덕분에 손으로 고치기 좋지만 JSON에는 없는 고장 방식들을 함께 갖게 됩니다.
이 변환기는 들여쓰기를 설정할 수 있는 양방향 변환을 제공하고, 파싱 오류를 발생한 줄과 함께 알려 줍니다.
변환하는 방법
방향마다 버튼이 따로 있어, 타이핑할 때마다가 아니라 의도한 시점에 변환합니다.
- 왼쪽 창에 YAML을, 오른쪽 창에 JSON을 붙여넣으세요.
- 들여쓰기를 정하세요. YAML은 2칸이 보통의 관례이며, JSON 쪽에는 탭도 고를 수 있습니다.
- 필요한 방향으로 변환하세요. 결과가 반대편 창에 나타납니다.
- 상태 줄을 확인하세요. 성공 여부나 파싱 오류와 그 위치를 알려 줍니다.
- 두 창을 각각 따로 복사할 수 있습니다. 각자 복사 버튼을 가지고 있습니다.
- YAML 방향에서 탭은 파싱 오류라는 점을 유념하세요. 이 형식은 들여쓰기에 탭을 금지합니다.
변환에서 잃는 것
JSON에서 YAML로는 사실상 무손실입니다. 모든 JSON 구성 요소에 대응하는 YAML이 있기 때문입니다. 반대 방향은 그렇지 않습니다. YAML 주석은 사라집니다. JSON에는 그것을 둘 자리가 없기 때문이고, 설정 파일에서 주석은 가장 값진 부분인 경우가 많습니다. 다른 곳에 정의된 블록을 참조하게 해 주는 앵커와 별칭은 중복된 내용으로 펼쳐집니다. `---`로 구분된 한 스트림 안의 여러 문서는 하나의 JSON 값으로 표현할 수 없습니다.
YAML에는 JSON에 없는 스칼라 타입도 있습니다. 날짜, 명시적 태그, 그리고 악명 높은 암묵적 변환입니다. `yes`, `on`, `off`로 쓴 값은 YAML 1.1 파서에서 불리언이 되고, 따옴표 없는 `1.0`은 의도했을지 모를 문자열이 아니라 실수가 됩니다. 버전 번호와 국가 코드가 흔한 희생자입니다.
왕복에서 살아남지 못하는 구성 요소
각 YAML 기능이 JSON이 될 때 어떻게 되는지입니다.
| YAML 기능 | JSON에서는 | 결과 |
|---|---|---|
| # 주석 | 대응 없음 | 버려짐 |
| &앵커 / *별칭 | 대응 없음 | 중복으로 펼쳐짐 |
| --- 여러 문서 | 값 하나만 | 첫 번째만 남음 |
| 여러 줄 블록 스칼라 | \n이 든 문자열 | 보존되지만 서식은 평탄해짐 |
| 따옴표 없는 날짜 | 날짜 타입 없음 | 문자열이 됨 |
| yes / no / on / off | true / false | 불리언으로 변환 |
실무에서 문제가 되는 것은 주석 행입니다. 설명이 달린 설정 파일을 JSON으로 바꿨다가 되돌리면, 동작은 하지만 더 이상 스스로를 설명하지 않는 설정이 남습니다. 앞으로도 손으로 고칠 파일을 재정렬하는 수단으로 이 왕복이 부실한 이유입니다.
둘 사이에서 고르기
기계가 쓰거나 전송하는 것이라면 JSON이 낫습니다. 모호하지 않고 어디서나 지원되며 잘못 다룰 공백 민감성이 없습니다. YAML은 사람이 고치는 파일, CI 파이프라인, 쿠버네티스 매니페스트, 애플리케이션 설정, 에서 제 몫을 합니다. 그런 곳에서는 주석과 가독성이 들여쓰기가 요구하는 주의를 치를 만한 값을 합니다.
이 도구는 MIT 라이선스 파서인 js-yaml을 사용하며 전적으로 브라우저에서 실행됩니다. 붙여넣은 것은 전송되거나 저장되지 않는데, YAML 설정에 자격 증명이 담기는 일이 얼마나 흔한지를 생각하면 중요한 점입니다. 아주 큰 문서는 한 번에 메모리로 파싱되므로, 수 메가바이트 파일은 사양이 빠듯한 기기에서 느릴 수 있다는 점도 유념하세요.