YAML ↔ JSON 변환기
YAML을 JSON으로, JSON을 YAML로 양방향 변환합니다. 들여쓰기·탭 오류를 줄:칸으로 짚어 줍니다.
이 파서는 YAML 1.2 전체 스펙 구현이 아니라, 실무 설정 파일에서 실제로 쓰는 범위를 직접 구현한 것입니다.
됩니다 — 중첩 매핑·시퀀스, 문자열/숫자/불리언/null 스칼라, 작은따옴표·큰따옴표 인용(이스케이프 포함), 블록 스칼라
|(literal)·>(folded)와 chomping 지시자 -·+·들여쓰기 지시자,
인라인 flow {}·[], # 주석, 여러 줄 plain 스칼라,
- key: value 형태의 compact 매핑, 문서 시작 --- 1개.안 됩니다 — 앵커
&·별칭 *, 병합 키 <<, 태그 !!str,
? 명시적 키, 다중 문서, 날짜 자동 타입 변환. 이런 문법을 만나면 조용히 틀린 결과를 내는 대신 몇 번째 줄인지와 함께 오류로 알려 드립니다.불리언은 YAML 1.2 표준을 따라
true/false만 인정합니다. yes·no·on·off는 문자열이며, 발견되면 안내 메시지를 띄웁니다.
YAML ↔ JSON 변환기란?
YAML은 사람이 읽기 좋게 만든 설정 형식이라 도커 컴포즈, 쿠버네티스 매니페스트, GitHub Actions, 각종 서버 설정 파일에서 표준처럼 쓰입니다. 문제는 YAML이 들여쓰기로 구조를 표현한다는 점입니다. 공백 한 칸이 어긋나거나 탭이 섞여 들어가면 파일 전체가 다른 뜻이 되거나 아예 파싱에 실패하는데, 에디터에서는 눈으로 잘 보이지 않습니다. 이 도구는 YAML을 JSON으로 바꿔 실제로 어떤 구조로 해석되는지 눈으로 확인하게 해 주고, 문제가 있으면 몇 번째 줄 몇 칸에서 무엇이 잘못됐는지 알려 줍니다. 반대로 JSON을 YAML로 바꿔 설정 파일 초안을 만드는 것도 됩니다. 이때 따옴표가 꼭 필요한 문자열만 골라 인용하고, 줄바꿈이 들어간 값은 블록 스칼라(|)로 풀어 씁니다.
사용 방법
- 변환 방향을 고릅니다. "자동"으로 두면 입력 내용을 보고 YAML인지 JSON인지 알아서 판단합니다.
- 왼쪽 입력창에 YAML 또는 JSON을 붙여넣거나, .yaml/.yml/.json 파일을 끌어다 놓습니다.
- 입력하는 즉시 오른쪽에 변환 결과가 나오고, 문법 오류가 있으면 줄:칸 위치와 함께 표시됩니다.
- 들여쓰기 칸 수를 바꾸거나 JSON 키 정렬을 켜서 원하는 모양으로 다듬습니다.
- 결과를 복사하거나 파일로 저장합니다.
YAML ↔ JSON 변환기 사용 가이드
실제 작업에서 이 도구를 어떻게 쓰는지, 무엇을 조심해야 하는지 정리했습니다.
YAML이 설정 파일을 점령한 이유, 그리고 그 대가
JSON은 따옴표와 중괄호가 빽빽하고 주석을 못 답니다. 설정 파일은 사람이 매일 열어 고치고 "이 값 왜 이렇게 뒀는지" 메모를 남겨야 하는데, JSON은 그 두 가지를 못 합니다. 그래서 도커 컴포즈, 쿠버네티스, GitHub Actions, Ansible이 전부 YAML로 갔습니다.
대신 구조를 들여쓰기로 표현한다는 대가를 치릅니다. 공백 한 칸이 어긋나면 파일이 다른 뜻이 되는데, 에디터에서는 그게 안 보입니다. 이 도구의 쓸모는 "예뻐 보이는 YAML"이 실제로 어떤 구조로 해석되는지를 JSON으로 뒤집어 보여 주는 데 있습니다. 의심스러우면 JSON으로 바꿔서 중첩이 내 생각과 같은지 확인하세요.
노르웨이 문제 — NO 가 false 가 되는 사고
YAML 1.1에서는 yes/no/on/off/y/n 도 불리언이었습니다. 그래서 국가 코드 목록에 노르웨이(NO)를 적으면 문자열 "NO"가 아니라 false 로 읽히는 유명한 사고가 납니다. countries: [KR, JP, NO] 가 [KR, JP, false] 가 되는 식입니다.
YAML 1.2는 이 목록을 없애고 true/false 만 불리언으로 인정합니다. 이 도구는 1.2를 따르므로 NO 는 문자열 "NO"로 나옵니다. 하지만 여기서 더 중요한 사실이 있습니다 — 이 도구의 결과와 실제 서버의 해석이 다를 수 있습니다.
| 적은 값 | 이 도구 (YAML 1.2) | 1.1 규칙 파서 | 안전하게 쓰려면 |
|---|---|---|---|
| NO | "NO" (문자열) | false | "NO" 로 따옴표를 붙인다 |
| yes | "yes" (문자열) | true | true 로 적는다 |
| off | "off" (문자열) | false | false 로 적는다 |
| 05300 | "05300" (문자열) | 8진수로 읽히기도 함 | "05300" 으로 따옴표를 붙인다 |
| 1.20 | 1.2 (숫자) | 1.2 (숫자) | 버전 표기라면 "1.20" |
탭·들여쓰기 오류를 빨리 잡는 법
YAML은 들여쓰기에 탭을 쓸 수 없습니다. 이 도구는 탭이 들어간 줄을 찾아 몇 번째 줄 몇 칸인지 짚어 줍니다. 문제는 탭을 넣은 기억이 없는데 들어가 있는 경우인데, 대개 다른 문서에서 복사해 붙였거나 에디터가 Tab 키를 탭 문자로 넣도록 설정돼 있어서입니다.
- VS Code라면 우측 하단 "Spaces: 2" 표시를 눌러 Indent Using Spaces 로 바꾸고, .editorconfig 에 [*.yml] indent_style = space 를 넣어 두면 팀 전체가 안전해집니다.
- 오류가 난 줄에서 원인이 안 보이면 바로 위 줄을 보세요. 대괄호·중괄호를 안 닫았거나 콜론 뒤 공백을 빼먹은 앞 줄 때문에, 다음 줄에서 오류로 잡히는 일이 흔합니다.
- key:value 는 값이 아니라 통째로 하나의 문자열입니다. 콜론 뒤에는 반드시 공백이 있어야 합니다(key: value).
- 값 안에 콜론+공백이 들어가면(시각 표기, URL 설명 등) 따옴표로 감싸야 합니다. "예시 넣기"에 이 경우가 들어 있습니다.
앵커(&)·별칭(*)은 지원하지 않습니다
YAML에는 값을 한 번 정의하고 재사용하는 앵커·별칭 문법과 병합 키(<<)가 있습니다. docker-compose 의 x-common 패턴이나 GitLab CI 설정에서 자주 보입니다. 이 파서는 이 문법을 구현하지 않았고, 만나면 조용히 틀린 결과를 내는 대신 몇 번째 줄인지와 함께 오류로 멈춥니다.
조용히 넘기는 쪽이 더 위험하다고 판단해서입니다. 앵커를 무시하면 참조가 통째로 빠진 JSON이 나오는데, 겉보기엔 멀쩡해서 그대로 쓰다 배포 후에 발견됩니다.
# 이런 파일은 오류가 납니다
x-base: &base
restart: always
logging:
driver: json-file
services:
api:
<<: *base # 병합 키 · 별칭
image: myapi:1.0
# 이렇게 풀어서 넣으면 변환됩니다
services:
api:
restart: always
logging:
driver: json-file
image: myapi:1.0
JSON → YAML 로 뒤집을 때
반대 방향도 실무에서 자주 씁니다. API가 JSON으로 준 설정을 YAML 매니페스트 초안으로 옮기거나, 코드로 만들어 둔 설정 객체를 파일로 떨궈야 할 때입니다.
이 도구는 따옴표가 없으면 다른 뜻으로 읽힐 문자열에만 따옴표를 붙입니다. "123"·"true"·"null" 같이 숫자·불리언으로 오해될 값, 콜론이나 # 이 들어간 값, 앞뒤에 공백이 있는 값, 빈 문자열이 대상입니다. 줄바꿈이 들어간 긴 값은 따옴표 대신 블록 스칼라(|)로 풀어써서 읽기 좋게 만듭니다.
"짧은 배열은 한 줄로" 옵션을 켜면 [8080, 8443] 처럼 flow 스타일로 붙습니다. 포트 목록이나 태그처럼 짧은 배열이 많은 파일에서 줄 수가 확 줄어듭니다. 반대로 항목마다 주석을 달 계획이면 꺼 두는 편이 낫습니다.
"↔ 결과를 입력으로" 버튼은 왕복 검증에 씁니다. YAML → JSON → 다시 YAML 로 돌려 원본과 비교해 보면, 내가 의도한 구조와 파서가 읽은 구조가 같은지 눈으로 확인됩니다.
자주 묻는 질문
YAML 문법을 어디까지 지원하나요?
실무 설정 파일에서 쓰는 범위를 지원합니다. 중첩 매핑과 시퀀스, 문자열·숫자·불리언·null 스칼라, 작은따옴표/큰따옴표 인용, 블록 스칼라(| literal, > folded)와 chomping 지시자(-, +), 인라인 flow 표기({}, []), # 주석, 여러 줄에 걸친 plain 스칼라를 처리합니다. 반대로 앵커(&)·별칭(*)·병합 키(<<)·태그(!!) 및 ---로 구분된 다중 문서는 지원하지 않으며, 만나면 조용히 무시하지 않고 몇 번째 줄인지와 함께 명확한 오류로 알려 줍니다. YAML 1.2 전체 스펙을 구현한 것이 아니라는 점을 분명히 밝힙니다.
yes / no / on / off 는 왜 true, false 가 안 되나요?
YAML 1.2 표준에서 불리언은 true 와 false 뿐이고 yes·no·on·off 는 그냥 문자열입니다. 이 도구는 표준을 따르지만, 1.1 시절 동작을 기대하는 분이 많아서 이런 값이 보이면 안내 메시지를 띄웁니다. 불리언으로 쓰고 싶다면 true / false 로 적으세요.
탭을 썼더니 오류가 납니다.
YAML 표준은 들여쓰기에 탭을 쓸 수 없고 공백만 허용합니다. 이 도구는 들여쓰기에 탭이 들어가면 몇 번째 줄 몇 칸인지 짚어 주므로 그 자리를 공백으로 바꾸면 됩니다. 에디터에서 탭을 공백으로 변환하는 설정을 켜 두는 편이 좋습니다.
JSON을 YAML로 바꿀 때 따옴표는 어떤 기준으로 붙나요?
따옴표가 없으면 다른 뜻으로 읽히는 문자열에만 붙입니다. 예를 들어 "123", "true", "null" 처럼 숫자·불리언·null 로 오해될 값, 콜론과 공백이 들어간 값, # 로 시작하거나 앞뒤에 공백이 있는 값, 빈 문자열 등입니다. 줄바꿈이 들어간 긴 문자열은 따옴표 대신 블록 스칼라(|)로 풀어 써서 읽기 좋게 만듭니다.
입력한 내용이 서버로 전송되나요?
아니요. YAML 파서와 JSON 변환 모두 브라우저 안에서만 실행됩니다. 설정 파일에 접속 정보나 키가 들어 있어도 서버로 전송되거나 저장되지 않습니다.