JSON ↔ YAML 변환기

YAML / JSON 변환기란?#

YAML과 JSON은 같은 종류의 데이터(중첩 맵, 목록, 문자열, 숫자, 불리언, null)를 적는 두 가지 방식입니다. JSON은 엄격하고 구두점이 많으며(모든 문자열이 큰따옴표, 어디나 괄호), YAML은 그 따옴표와 중괄호를 들여쓰기와 대시로 바꾸어, 사람이 설정 파일·CI 파이프라인·컨테이너 매니페스트를 손으로 쓸 만큼 읽기 쉽게 만듭니다.

두 양식을 오가야 하는 일은 계속 생깁니다. 도구마다 선호하는 형식이 다르기 때문입니다. Kubernetes 차트는 YAML로 작성되지만 API는 JSON을 씁니다. CI 설정은 YAML인데, 먹이려는 린터는 JSON을 기대합니다. 팀원이 채팅에 YAML 덩어리를 붙여넣지만, 스크립트는 JSON.parse를 원합니다. 손으로 하면(다시 들여쓰기, 다시 따옴표, 대시를 괄호로) 군더더기 쉼표나 어긋난 공백이 들어가 아무것도 파싱되지 않는, 바로 그런 까다로운 일입니다.

이 페이지는 브라우저에서 양방향 으로 변환합니다. 기계 친화적 엄격함이 필요할 때 YAML을 JSON으로, 사람이 읽을 수 있는 설정 파일이 필요할 때 JSON을 YAML로. YAML 1.2 코어 스키마로 파싱하고(위험한 객체 인스턴스화 없음), 오류를 정확한 행과 열로 짚어내며, 긴 줄을 접지 않아 출력이 diff 친화적으로 남습니다.

사용 방법#

1. 도구 모음 왼쪽 위의 두 단추 토글에서 방향 을 고르세요.
   • YAML → JSON (기본값): 왼쪽에 YAML을 붙여넣고 오른쪽에 엄격한 JSON을 얻습니다.
   • JSON → YAML: 왼쪽에 JSON을 붙여넣고 오른쪽에 들여쓰기된 YAML을 얻습니다.
2. 들여쓰기 를 고르세요. 2 또는 4 칸. 양쪽 모두에서 출력의 중첩 깊이를 결정합니다.
3. 동작을 직접 보려면 예제 로 짧은 예시를 불러오거나, 지우기 로 양쪽 패널을 비우세요.
4. 오른쪽 패널은 변환이 실행되면서 갱신됩니다. 아래 상태 표시줄은 세 가지 중 하나를 보고합니다. 출력 바이트 크기가 있는 성공 줄, 빈 입력 힌트, 또는 정확한 범인 토큰을 가리키는 1 기반 행과 열이 붙은 파싱 오류.
5. 출력 헤더의 복사 로 결과를 가져가세요.

변환은 입력이 파싱되는 순간 실행됩니다. 누를 생성 버튼은 없습니다. 입력을 고치면 출력이 새로고침됩니다.

주요 기능#

• 한 쌍의 패널로 양방향. 같은 입력/출력 레이아웃이 양방향을 처리하며, 토글이 어느 파서를 실행할지 결정합니다.
• YAML 1.2 코어 스키마. null, true/false, 정수, 부동소수, 따옴표 문자열이 모두 표준 준수 파서가 풀어내는 그대로 풀립니다. 느슨한 휴리스틱이 아닙니다.
• 줄 접기 비활성화. 긴 출력 줄은 결코 감싸지거나 생략되지 않아 커밋된 파일에 대한 diff가 실제 변경만 보여줍니다.
• 정확한 오류 위치. 어긋난 들여쓰기나 군더더기 :는 “파싱할 수 없음”이 아니라 행:열로 보고됩니다.
• 깊이 가드. 깊이 중첩된 입력(고전적인 “YAML billion-laughs” 전개)은 상한이 걸려, 적대적이거나 우연히 재귀적인 파일이 탭을 멈추지 않습니다.
• 로컬 전용. 설정은 페이지를 떠나지 않습니다. 보낼 백엔드가 없습니다. 1메가바이트를 넘으면 무거운 파싱은 백그라운드 워커로 넘겨 UI가 반응성을 유지합니다.

실전 예시#

흔한 실제 작업 하나: YAML로 쓰인 서비스 설정을 JSON 요청 본문에 넣어야 합니다. YAML → JSON 과 2 들여쓰기를 선택한 채 왼쪽 패널에 이것을 붙여넣으세요.

name: api-gateway
port: 8080
replicas: 3
targets:
  - host: example.com
    port: 443
  - host: cdn.example.com
    port: 8443
features:
  retries: true
  timeout_ms: 2500

오른쪽 패널은 엄격하고 파싱 준비된 JSON을 만들어냅니다.

{
  "name": "api-gateway",
  "port": 8080,
  "replicas": 3,
  "targets": [
    {
      "host": "example.com",
      "port": 443
    },
    {
      "host": "cdn.example.com",
      "port": 8443
    }
  ],
  "features": {
    "retries": true,
    "timeout_ms": 2500
  }
}

따옴표 없는 YAML 값 8080, true, 3이 각각 JSON 숫자, 불리언, 숫자가 되었습니다. 코어 스키마가 타입을 매겼고, 사용자가 할 필요가 없었습니다. 방향을 JSON → YAML 로 바꾸고 그 JSON을 다시 붙여넣으면 같은 중첩 구조가 목록 항목에 대시를 쓰는 들여쓰기 형태로 돌아옵니다. 설정 저장소에 커밋할 형태입니다.

FAQ#

왕복에서 내 YAML 주석은 보존되나요?#

아니요. JSON에는 주석 구문이 아예 없어서 YAML의 # comment는 JSON으로 가는 길에 읽힌 뒤 버려집니다. 둘 곳이 없기 때문입니다. 주석은 입력에서 허용됩니다(결코 오류를 일으키지 않음)지만, 건너편에 살아남을 수는 없습니다. 주석이 중요하다면 YAML을 진실의 원천으로 두고 매번 JSON을 생성하세요.

다중 문서 YAML(---로 구분)을 처리하나요?#

문서 스트림을 처리하고 선행 문서를 반환합니다. 대부분의 설정과 매니페스트 파일은 단일 문서이므로 거의 문제가 안 됩니다. 다중 문서 스트림이 있다면 --- 구분자로 나누어 각 부분을 변환하세요.

내 설정 파일엔 YAML과 JSON 중 어느 쪽을 써야 하나요?#

사람이 손으로 편집하고 들여쓰기 중첩과 앵커, 주석 비슷한 가독성을 원하면 YAML을 쓰세요. 기계가 만들고 파서가 소비하거나, 엄격함이 중요할 때(JSON은 각 값을 적는 합법적 방식이 정확히 하나라 디버깅할 애매함이 없음) JSON을 쓰세요. 이 도구는 한쪽만 택하지 않아도 되도록 있습니다.

오류가 “행 4, 열 5”라고 하는데 그 줄은 멀쩡해 보입니다. 무엇이 문제인가요?#

거의 항상 들여쓰기입니다. YAML은 구조를 선행 공백에서 결정하므로, 자식이 한 칸 너무 왼쪽이나 오른쪽이거나 탭과 공백이 섞이면, 파서가 다음 토큰을 읽을 때 비일관성을 알아챈다는 점에서 실제 범인 다음 줄에 오류로 나타납니다. 보고된 행 바로 윗줄의 들여쓰기를 먼저 확인하세요.