YAML 설정 파일, JSON으로 바꿔야 할 때

설정 파일은 YAML로 작성해두는 경우가 많습니다. 들여쓰기만으로 구조가 보이고 주석도 자유롭게 달 수 있어서, 사람이 읽고 고치기에는 YAML이 훨씬 편합니다. 그런데 그 값을 자바스크립트 코드 안에서 쓰거나 API 요청 본문에 그대로 넣으려는 순간, YAML 그대로는 쓸 수 없다는 걸 알게 됩니다.

요약 ① YAML은 사람이 읽고 쓰기 편하지만, 자바스크립트 객체나 API 요청 본문은 JSON 형식을 기대합니다 ② 들여쓰기 기반 구조를 중괄호·대괄호 기반 구조로 옮기는 규칙만 알면 손으로도 바꿀 수 있습니다 ③ 중첩이 깊거나 목록이 섞인 YAML은 손 변환에서 실수가 잦아, 결과를 눈으로 검증하는 과정이 필요합니다

YAML 설정, 코드에서는 왜 막힐까

YAML은 들여쓰기로 계층을 표현하고 콜론 뒤에 값을 적는 방식이라 사람이 읽기 편합니다. 주석(#)도 자유롭게 달 수 있어서 설정 파일 형식으로 널리 쓰입니다.

문제는 자바스크립트의 JSON.parse나 fetch 요청 본문 같은 곳은 YAML 문법을 이해하지 못한다는 점입니다. 이 함수들은 오직 JSON 문법인 중괄호, 대괄호, 쌍따옴표로 감싼 키만 해석합니다.

그래서 설정 파일에 있는 값을 테스트용 API 요청에 그대로 붙여넣거나, 프론트엔드 코드 안에 상수로 옮기려 하면 구문 오류가 납니다. YAML 자체는 문법적으로 멀쩡한데도 JSON을 기대하는 자리에서는 오류가 나는 것입니다.

확인하는 방법 — 직접 변환하는 규칙과 검증

손으로 변환할 때 규칙은 세 가지입니다. 첫째, key: value는 쌍따옴표로 감싼 형태로 바꿉니다. 둘째, 들여쓰기로 표현된 하위 항목은 중괄호로 묶습니다. 셋째, 줄 앞에 붙는 리스트 항목은 대괄호 배열로 바꿉니다.

규칙은 단순하지만 계층이 두세 단계를 넘어가면 괄호의 짝을 손으로 맞추기가 쉽지 않습니다. 리스트 안에 다시 객체가 들어있는 구조라면 괄호가 겹치면서 실수가 나기 더 쉽습니다.

저희 도구로 확인하기. YAML을 입력창에 붙여넣으면 아래쪽에 JSON 결과가 바로 만들어지고, 들여쓰기 폭을 2칸·4칸·한 줄(압축) 중에서 골라 그대로 복사해 코드에 붙여넣을 수 있습니다.

직접 해보기 →

자주 막히는 지점

표에 정리된 상황은 눈으로 훑어서는 잘 드러나지 않고, 실제로 파싱을 시도해야 오류 위치가 보입니다. 변환 후에는 구조가 원본과 같은지 한 번 확인하는 습관이 필요합니다.

정리

YAML은 설정을 사람이 읽고 고치기 편한 형식이고, JSON은 코드와 API가 이해하는 형식입니다. 콜론을 따옴표로, 들여쓰기를 중괄호로, 목록을 대괄호로 바꾸면 손으로도 옮길 수 있습니다.

다만 계층이 깊어지거나 리스트와 객체가 섞이면 괄호 짝을 맞추다 실수하기 쉽습니다. 그럴 때는 변환 결과를 바로 눈으로 검증할 수 있는 도구를 쓰는 편이 빠릅니다.

자주 묻는 질문

YAML의 모든 문법을 JSON으로 바꿀 수 있나요?

key-value, 중첩된 맵, 리스트처럼 설정 파일에서 흔히 쓰는 구조는 JSON으로 그대로 옮길 수 있습니다. 다만 앵커나 참조 같은 YAML 고유 문법은 JSON에 대응하는 개념이 없어서, 먼저 값이 펼쳐진 상태로 바꾼 뒤 변환해야 합니다.

변환한 JSON을 API 요청 본문에 그대로 써도 되나요?

표준 JSON 구조로 바뀌었다면 fetch나 axios 요청의 본문에 그대로 넣을 수 있습니다. 다만 API가 기대하는 필드 이름과 값 타입이 원본 YAML의 키와 일치하는지는 별도로 확인해야 합니다.

들여쓰기 간격은 2칸과 4칸 중 무엇을 골라야 하나요?

파싱된 데이터 자체는 들여쓰기 폭과 무관하게 동일합니다. 협업 중인 코드베이스에 붙여넣을 계획이라면 그 프로젝트가 쓰는 간격과 맞추면 되고, API 요청 본문처럼 공백이 중요하지 않은 곳에는 한 줄(압축) 옵션이 더 편합니다.