JSON ↔ YAML 변환기
JSON을 YAML로, YAML을 다시 JSON으로 브라우저에서 바로 변환하세요. 두 형식 중 어느 것이든 붙여넣으면 들여쓰기가 깔끔하게 정리된 결과를 얻을 수 있어, 설정 파일과 CI 파이프라인, Kubernetes 매니페스트에 안성맞춤입니다.
들여쓰기
위에 데이터를 입력하면 변환된 결과가 여기에 표시됩니다.
JSON ↔ YAML 변환기 사용 방법
- 1
변환 방향 선택
토글을 사용해 ‘JSON을 YAML로’ 또는 ‘YAML을 JSON으로’를 선택하세요. 바꾸기 버튼을 누르면 결과가 입력란으로 옮겨져 반대 방향으로 다시 변환할 수 있습니다.
- 2
데이터 붙여넣기
JSON이나 YAML을 입력란에 붙여넣으세요. 입력하는 즉시 변환이 자동으로 실행되며, 구조와 중첩, 데이터 타입이 그대로 유지됩니다.
- 3
들여쓰기 선택
프로젝트 스타일에 맞게 2칸 또는 4칸 들여쓰기를 선택하세요. 어느 형식이든 결과는 깔끔하고 정확한 들여쓰기를 유지합니다.
- 4
결과 복사
변환된 결과를 확인하고 클립보드에 복사하면 설정 파일이나 파이프라인, 코드에 바로 붙여넣을 수 있습니다.
JSON에서 YAML로: 함정 없이 더 깔끔한 설정 만들기
YAML은 JSON의 상위 집합입니다
모든 유효한 JSON 문서는 동시에 유효한 YAML이기도 합니다. 이는 우연이 아니라 YAML 명세의 보장입니다. YAML은 그 위에 더 사람 친화적인 층을 더합니다. 중괄호와 대괄호 대신 들여쓰기로 구조를 나타내고, 쉼표 대신 항목들이 저마다의 줄에 놓이며, JSON과 달리 YAML은 주석을 지원합니다. 그 결과는 데이터 더미라기보다 개요처럼 읽히며, 그래서 설정 파일을 지배합니다.
데이터 모델이 워낙 가깝게 들어맞으므로, 즉 둘 다 맵, 시퀀스, 문자열, 숫자, 불리언, null 을 가지므로, 둘 사이의 변환은 기계적이며 값 자체에 대해서는 무손실입니다. 변환은 같은 트리를 다른 표면 문법으로 다시 표현합니다. JSON 왕복에서 살아남지 못하는 단 한 가지는 주석인데, JSON에는 그것을 둘 자리가 없기 때문입니다.
들여쓰기가 곧 문법입니다
YAML에서 공백은 겉모습이 아니라 구조 그 자체입니다. 중첩은 자식 키를 부모보다 더 들여 써서 나타내고, 같은 깊이의 항목들은 같은 들여쓰기를 공유해야 합니다. 어떤 키 아래에 중첩된 맵은 그 아래의 들여 쓴 줄들의 집합이 되고, 목록은 각각 대시로 시작하는 줄들이 됩니다. 들여쓰기를 틀리면 겉모습만이 아니라 의미가 바뀌는데, 이는 JSON이 공백을 다루는 방식과 정반대입니다.
일관된 들여쓰기 너비를 고르고(설정 파일에는 두 칸이 흔한 기본값이고, 일부 사내 스타일에는 네 칸입니다) 어디에나 적용하세요. 변환기는 깔끔하고 균일한 들여쓰기를 내보내므로, 여러분은 줄을 손으로 맞추는 대신 올바른 기준선에서 출발하게 됩니다.
탭은 금지되어 있습니다
이것은 처음 접하는 거의 모든 사람을 걸려 넘어지게 하는 규칙입니다. YAML 명세는 들여쓰기에 탭 문자를 쓰는 것을 명시적으로 금지합니다. 반드시 공백을 써야 합니다. Tab 키를 누르면 탭을 삽입하도록 설정된 편집기는 파싱에 실패하는 파일을 소리 없이 만들어 내며, 파서는 한두 줄 뒤에 가서야 구조가 깨진 것을 알아채기 때문에 흔히 엉뚱한 곳을 가리키는 오류 메시지가 뜹니다.
YAML 파일이 로드되기를 거부하는데 들여쓰기는 올바라 보인다면, 먼저 탭이 있는지 확인하세요. YAML 파일에 대해 공백을 표시하거나 탭을 공백으로 변환하도록 편집기를 설정하세요. JSON에서 변환하면 이 문제를 통째로 비껴가는데, 생성된 출력이 처음부터 공백으로 들여 써지기 때문입니다.
노르웨이 문제와 그 밖의 뜻밖의 불리언들
오래된 YAML 파서는 놀랄 만큼 다양한 맨 단어를 불리언으로 해석합니다. true 와 false 뿐 아니라 여러 대소문자 표기의 yes, no, on, off 까지 말이죠. 고전적인 재앙은 국가 코드 목록에서 노르웨이의 항목이 맨 글자 n 과 o 로 적혀 불리언 false 로 읽히고는 여러분의 데이터에서 소리 없이 사라지는 것입니다. on 이나 off 로 적힌 토글 플래그도 같은 식으로 타입이 뒤바뀔 수 있습니다.
방어책은 따옴표 처리입니다. 불리언, 숫자, 날짜, 또는 null 로 오인될 수 있는 모든 문자열은 파서가 텍스트로 유지하도록 따옴표로 감싸야 합니다. 안전한 스키마를 중심으로 만들어진 현대 파서는 더 엄격해 이런 일에 훨씬 덜 취약하지만, 모호한 스칼라를 따옴표로 감싸는 습관은 특히 짧은 코드, 버전 같은 문자열, 그리고 사용자가 제공한 모든 것에 대해 지킬 가치가 있습니다.
더 많은 스칼라 함정: 숫자, 앞자리 0, null
몇 가지 다른 맨 값들도 사람들을 놀라게 합니다. 앞자리에 0이 붙은 우편번호나 부품 번호는 숫자로 읽혀 0을 잃거나, 일부 파서에서는 8진수로 해석될 수 있습니다. 1.20 같은 버전 문자열은 숫자 1.2 로 강제 변환되어 끝의 0이 떨어질 수 있습니다. 단어 null, 빈 값, 그리고 홀로 있는 물결표는 모두 null 을 뜻합니다. 불리언 함정에서와 마찬가지로, 처방은 같습니다. 텍스트 형태가 중요한 것은 무엇이든 따옴표로 감싸세요.
이 도구는 안전한 스키마로 파싱하므로 표준 데이터 타입만 로드하고 임의의 객체를 만들거나 코드를 실행하지 않으며, 그래서 신뢰할 수 없는 YAML을 붙여넣어도 아무것도 실행될 수 없습니다. 그 덕분에 변환이 예측 가능하게 유지됩니다. 여러분이 돌려받는 것은 평범한 맵, 시퀀스, 스칼라이며, 태그를 통해 몰래 들어온 뜻밖의 사용자 정의 타입은 없습니다.
YAML이 실제로 사는 곳
YAML의 가독성은 그것을 인프라와 CI 도구의 공용어로 만들었습니다. Docker Compose 파일, Kubernetes 매니페스트, GitHub Actions와 GitLab CI 파이프라인, Ansible 플레이북, 그리고 수많은 애플리케이션 설정 파일이 모두 YAML입니다. 이들 하나하나에서, 사람이 운영 설정에 대한 변경을 검토해야 할 때 YAML이 허용하는 주석과 깔끔한 diff는 진정한 이점입니다.
대조적으로 JSON은 API를 통한 기계 대 기계 교환에 여전히 더 잘 들어맞는데, 그 엄격함과 공백 민감성의 부재가 모호함을 줄여 주기 때문입니다. 흔한 패턴은 사람의 편의를 위해 YAML로 작성하고 편집한 뒤, 도구나 엔드포인트가 요구할 때 JSON으로 변환하는 것입니다. 이 변환기가 양방향으로 실행되는 이유가 바로 이것입니다.
블록 스타일, 플로 스타일, 그리고 출력 읽기
YAML은 같은 데이터를 두 가지 방식으로 표현할 수 있습니다. 블록 스타일은 맵과 목록을 들여 쓴 줄들에 펼치며, 읽기 쉬운 설정에 원하는 것입니다. 플로 스타일은 인라인 중괄호와 대괄호를 써서 JSON과 거의 똑같아 보이는데, 더 큰 문서 안에 박힌 짧고 압축된 값에 이따금 편리합니다. 둘 다 알아 두면 다른 사람이 쓴 YAML을 혼란 없이 읽는 데 도움이 됩니다.
여기서 변환할 때는 JSON을 붙여넣고, 들여쓰기 너비를 고른 뒤, 저장소에 넣기 전에 블록 스타일 출력을 검토하세요. 모든 것이 여러분의 브라우저에서 로컬로 일어나므로, 설정 파일 안의 비밀, 즉 토큰, 연결 문자열, 내부 호스트 이름이 결코 여러분의 기기를 떠나지 않으며, 그래서 정제된 예시가 아니라 실제 배포 매니페스트를 변환해도 안전합니다.
자주 묻는 질문
JSON과 YAML은 어떻게 다른가요?
JSON을 YAML로 어떻게 변환하나요?
YAML을 다시 JSON으로 변환할 수도 있나요?
신뢰할 수 없는 YAML을 파싱해도 안전한가요?
내 데이터가 서버로 전송되나요?
관련 도구
이런 편리한 도구도 함께 사용해 보세요