문서 작업 가이드

JSON과 YAML 설정 파일을 안전하게 변환하기

중복 key, 숫자 정밀도, 주석, anchor, alias, 다중 문서 stream과 목적지 schema를 확인하며 JSON과 YAML 설정 파일을 변환합니다.

작성 및 검수 게시일: 검토일:

이 작업 흐름을 검증한 방법

검토에서는 수정하지 않은 “작은 서비스 설정을 JSON에서 YAML로 변환” 샘플을 JSON을 YAML로, YAML을 JSON으로 변환에 불러왔습니다. “원본 표준과 목적지 확인”에서 “구조와 경계 값 비교”까지의 흐름을 실행해 화면 또는 다운로드 결과를 예시와 비교했습니다. 별도 조사 항목은 “유효한 YAML이면 Kubernetes나 CI 설정도 유효하다고 생각”, “중복 key의 승자를 parser에 맡김”였습니다.

service 객체, 숫자 포트 두 개, 날짜 형태 문자열과 boolean이 YAML에서도 의도한 구조를 유지했고 다시 동등한 JSON으로 변환됐습니다.

문제 상황

JSON과 YAML은 기본 mapping, sequence, 문자열, 숫자, boolean, null을 표현할 수 있지만 모든 세부 문법이 서로 바뀌는 것은 아닙니다. YAML 주석, anchor, alias, tag와 문서 stream에는 같은 JSON 문법이 없습니다. 약한 변환기는 중복 key의 마지막 값만 남기거나 긴 숫자를 반올림할 수도 있습니다. 이 작업 흐름은 원본을 검사하고 보존할 수 없는 문법을 확인한 뒤, 배포 전에 목적지 제품에서 결과를 다시 검증하도록 구성합니다.

공식 출처와 표준

다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.

이럴 때 사용하세요

  • 애플리케이션 JSON 설정을 YAML 기반 설정 체계로 옮겨야 할 때 사용합니다.
  • 하나의 Kubernetes, Docker Compose, CI YAML 예제를 점검 도구용 JSON으로 바꿀 때 적합합니다.
  • 다른 팀이 선호하는 형식으로 작은 재현 설정을 만들어 지원 요청에 첨부할 때 사용합니다.
  • 저장소 변경을 commit하거나 배포하기 전에 JSON과 YAML 표현을 함께 검토할 때 도움이 됩니다.

단계

  1. 1단계

    원본 표준과 목적지 확인

    YAML이 YAML 1.2 동작을 전제로 하는지, 원본에 문서가 하나인지 확인합니다. 결과를 사용할 kubectl, Docker Compose, CI 공급자, API client, 애플리케이션 설정 loader를 기록하세요. 형식 변환은 그 제품의 schema 검사를 대신하지 않습니다.

  2. 2단계

    옮겨야 할 설정만 남기기

    붙여넣기 전에 불필요한 secret, 생성된 구역, 비활성 예제, 환경 전용 값을 제거합니다. 주석, scalar style, anchor, alias는 목적지에서 같은 방식으로 표현되지 않을 수 있으므로 원본 백업을 보관하세요.

  3. 3단계

    하나의 문서를 손실 검사와 함께 변환

    JSON→YAML 또는 YAML→JSON을 고르고 2칸/4칸 들여쓰기를 선택합니다. 검토 중에는 보기 좋은 JSON을 사용하세요. 엄격한 문법 위치, 중복 key, collection YAML key, 지원하지 않는 tag, 달라지는 숫자를 임의로 넘기지 말고 원본에서 수정합니다.

  4. 4단계

    주석, anchor, alias와 scalar 타입 검토

    JSON에는 주석 문법이 없어 YAML 주석이 제거됩니다. 제한 내 anchor와 alias는 반복 값으로 펼쳐지므로 관계 자체는 사라집니다. 따옴표 날짜 문자열, 앞자리 0 ID, null, boolean, 여러 줄 문자열과 경고에 표시된 값을 모두 확인하세요.

  5. 5단계

    구조와 경계 값 비교

    최상위 key, 중첩 path, 배열 길이, 검토에 필요한 key 순서와 표시된 노드·최대 깊이를 비교합니다. __proto__, constructor, 숫자처럼 보이는 key, 큰 식별자, 음의 0, 유효 숫자가 긴 소수는 특히 직접 확인하세요.

  6. 6단계

    목적지에서 검증하고 시험

    현재 결과를 다운로드해 목적지 validator 또는 dry run을 실행합니다. Kubernetes는 schema 인식 도구, Docker Compose는 config 검사, CI와 애플리케이션 설정은 공급자 전용 parser를 사용하세요. Commit이나 배포 전에 실제 적용 설정이 원래 의도와 같은지 비교합니다.

예시

작은 서비스 설정을 JSON에서 YAML로 변환

입력

{
  "service": {
    "name": "api",
    "ports": [8080, 8081],
    "release": "2026-07-15",
    "enabled": true
  }
}

출력

service:
  name: api
  ports:
    - 8080
    - 8081
  release: 2026-07-15
  enabled: true

흔한 실수

유효한 YAML이면 Kubernetes나 CI 설정도 유효하다고 생각

YAML 문법은 데이터 형식만 설명합니다. 허용 key, 값 타입, version과 조합은 제품 schema가 따로 결정합니다.

주석과 anchor 경고 무시

주석에는 운영 맥락이 있고 anchor는 의도한 재사용을 나타낼 수 있습니다. 중요한 주석은 문서로 옮기고 원본을 버리기 전에 펼쳐진 값을 모두 확인하세요.

중복 key의 승자를 parser에 맡김

Parser마다 첫 값 유지, 마지막 값 유지, 문서 거부가 다를 수 있습니다. 변환 전에 중복 key를 명시적으로 바꾸거나 제거하세요.

식별자를 일반 숫자로 처리

계정 ID, image tag, 우편번호, 긴 build 번호는 정확한 문자나 앞자리 0이 필요할 수 있습니다. 수량이 아니라 식별자라면 원본에서 따옴표 문자열로 만드세요.

여러 YAML 문서를 한 객체로 변환

---로 나뉜 stream에는 root 문서가 여러 개지만 JSON 변환 결과는 하나의 root 값입니다. Stream을 나누고 각 문서를 의도에 맞게 따로 변환하세요.

자주 묻는 질문

모든 JSON 문서는 유효한 YAML인가요?

JSON 문법은 YAML 1.2 데이터 model과 호환되지만, 이 변환기는 JSON 구두점을 보존하는 대신 엄격하게 파싱한 뒤 깨끗한 YAML 표현으로 다시 작성합니다.

YAML 주석이 JSON에서 사라지는 이유는 무엇인가요?

JSON에는 표준 주석 문법이 없습니다. 중요한 설명은 변환 전에 문서나 명시적인 필드로 옮기세요.

YAML anchor와 alias는 어떻게 되나요?

안전 제한 안에서 alias를 반복 JSON 값으로 펼치고 경고를 표시합니다. 순환 alias와 과도한 확장은 거부됩니다.

왜 일부 큰 숫자를 거부하나요?

브라우저 숫자는 모든 긴 정수나 고정밀 소수를 보존할 수 없습니다. 출력 숫자가 달라지는 것을 막기 위한 조치이므로 식별자나 정확한 소수는 문자열로 감싸세요.

YAML 문서 여러 개를 한 번에 변환할 수 있나요?

아닙니다. 문서 구분자에서 stream을 나누고 각 root 문서를 따로 변환해 의도한 JSON 구조를 분명하게 만드세요.

변환된 설정은 어떻게 검증하나요?

경고와 구조 수치를 확인하고 민감한 경계 값을 비교한 뒤, 원본을 대체하기 전에 목적지 애플리케이션의 schema validator나 dry-run 명령을 실행하세요.