YAML을 옹호하며

(opensource.posit.co)

1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개

YAML 1.2는 사람이 직접 작성하는 중첩 구성 파일을 위한 들여쓰기 기반 직렬화 형식이며, 오래된 PyYAML 경험에서 비롯된 불안정성 비판과 구분 필요
구성 파일 형식은 INI의 평면성, XML의 장황함, JSON의 주석·여러 줄 문자열 부재처럼 이전 세대의 한계를 바로잡는 흐름으로 변화해 왔음
TOML은 pyproject.toml과 Cargo.toml처럼 얕은 구조에서 명확하지만, 깊은 중첩 구조에서는 경로 반복과 배열 테이블 때문에 읽기·편집 부담 증가
YAML 1.2 Core Schema는 yes, no, on, off, y, n을 문자열로 처리하고 60진수 숫자와 핵심 타입으로서의 타임스탬프를 제거해 과거의 암시적 타입 추론 문제 축소
py-yaml12는 Python용 YAML 1.2 파서·포매터로, Rust 구현을 통해 안전한 기본값, yaml-test-suite 100% 준수, PyYAML C 확장과 경쟁 가능한 성능 제공

문제의식

최근 몇 년 사이 구성 파일 형식에 대한 분위기는 YAML은 나쁘고 TOML은 좋다는 쪽으로 이동했지만, YAML 평가는 역사, 명세 변화, 2026년 도구 상태를 함께 봐야 하는 문제
YAML 비판은 오랫동안 합리적이었고 신중한 사용자까지 예상 밖 동작을 겪었지만, 명세는 변화했고 도구 생태계도 따라잡는 중
현재의 YAML 비판은 구성 파일 형식의 계보를 함께 봐야 이해 가능하며, 이전 형식의 과잉을 다음 형식이 바로잡는 논쟁이 반복되어 온 흐름

구성 파일 형식의 간략한 역사

INI 파일은 1980년대 초 MS-DOS와 초기 Windows와 함께 등장했고, 키-값 쌍, 대괄호 섹션, 세미콜론 주석을 갖춘 평면적이고 읽기 쉬운 사람이 편집 가능한 형식
INI는 장치 드라이버 구성, 글꼴 경로 지정, 애플리케이션 설정 같은 당시 요구에는 충분했지만, 한 단계 이상 중첩할 수 없고 공식 명세가 없어 파서마다 방언을 구현하는 구조적 한계
XML은 1990년대 후반 엔터프라이즈 소프트웨어 세계에서 널리 채택됐고, 임의 계층, 스키마, 네임스페이스, 변환, 자기 설명 구조를 제공했지만 실제 구성 파일은 매우 장황해져 손으로 유지보수하기 어려운 형식
JSON은 XML에 대한 가벼운 반응으로 등장했고 JavaScript 객체 리터럴의 단순성을 바탕으로 2000년대 후반과 2010년대 초반 웹 API에서 XML을 대체했지만, 구성 파일로 쓰기에는 주석 부재, 여러 줄 문자열 부재, 후행 쉼표 금지라는 제약
YAML은 2001년, TOML은 2013년에 JSON이 남긴 틈을 메우기 위해 등장했으며, YAML은 들여쓰기 기반 문법으로 임의 중첩, 여러 문서, 참조, 사용자 정의 타입을 제공하고 TOML은 명시적 타입과 공식 명세를 갖춘 “표준화된 INI”를 지향
각 세대의 새 형식은 이전 형식의 과잉을 출발점으로 삼았고, 현재 YAML 문제의 상당 부분은 형식 설계 자체보다 특정 명세 버전과 그 버전에 묶인 파서의 산물

YAML 반대 근거였던 문제들

YAML 비판은 조작된 문제가 아니라 여러 해 동안 실제 프로그래머가 겪은 경험에 기반한 문제
가장 유명한 Norway 문제는 YAML 1.1에서 따옴표 없는 스칼라 NO가 불리언 false로 해석돼 국가 코드 목록의 no가 거짓값으로 바뀌는 동작
```
countries:
  - dk
  - fi
  - is
  - no
  - se
```
```
["dk", "fi", "is", false, "se"]
```
같은 규칙은 yes, on, off, y, n과 여러 대소문자 변형에도 적용됐고, 22:22 같은 포트 매핑은 60진수 정수로, 10.23 같은 버전 번호는 문자열이 아니라 부동소수점으로, 날짜처럼 보이는 값은 타임스탬프로 해석되는 문제
데이터 과학과 머신러닝 코드에서 자연스러운 변수명인 n과 y도 YAML 1.1의 암시적 불리언 규칙 아래에서는 문자열 키가 아니라 False, True 키로 해석될 수 있는 구조
```
{"variables": {"x": "features", False: "sample_size", True: "target"}}
```
YAML 1.1의 공격적인 암시적 타입 추론은 따옴표 없는 true를 불리언으로 읽는 가독성을 의도했지만, 실제 구성 파일에서는 예측 불가능성이 커지는 결과
구성 파일은 자주 편집되지 않고 원래 작성자가 아닌 사람이 수정하는 경우가 많으며, 조용한 오파싱이 수개월 동안 시스템 전반에 전파될 수 있어 예상 밖 동작을 가장 견디기 어려운 영역
전체 YAML 명세의 복잡성도 부담으로 작용했고, YAML 1.2.2 명세는 10개 장과 네 단계 번호가 붙은 섹션 구조를 가진 상당한 문서
여러 줄 문자열 표현 방식이 많고, 앵커와 별칭은 강력한 참조 시스템을 만들지만 대부분의 구성 작업에는 필요한 수준을 넘어서는 개념적 무게
태그 기반 객체 역직렬화의 보안 문제, 특히 Python의 yaml.load() 취약점은 잘 알려진 공격 벡터가 되었고, 이러한 비판은 YAML 1.1과 그 주변 도구 생태계에 대해 유효했던 지점

TOML이 잘하는 점

TOML은 평면적이거나 얕은 구성 구조에서 깔끔하고 읽기 쉬우며 모호하지 않은 형식
TOML 문법은 INI 파일을 본 사람에게 익숙하면서도 명시적 타입, 공식 명세, 점으로 구분한 키를 통한 중첩 테이블 지원을 추가한 구조
pyproject.toml과 Cargo.toml은 보통 한두 단계 깊이의 잘 정의된 섹션과 예측 가능한 내용을 갖기 때문에 TOML이 잘 맞는 사례
TOML에서는 문자열이 항상 따옴표로 감싸져 no가 불리언인지 단어인지 모호하지 않고, 정수·부동소수점·날짜가 1급 타입이며, 주석도 기대한 방식으로 동작
Python 패키징 생태계의 PEP 518 채택과 Rust 커뮤니티의 Cargo 사용은 이런 문제 범위에서 TOML이 적합한 선택이라는 근거
TOML 명세는 유능한 프로그래머가 주말에 호환 파서를 작성할 수 있을 정도로 짧고, 그 결과 파서 생태계가 크고 잘 테스트되며 일관적인 장점
TOML에는 YAML 1.1과 1.2 사이의 버전 분열에 해당하는 문제가 없고, TOML 1.0은 어디서나 TOML 1.0이라는 일관성

TOML이 버거워지는 지점

구성 파일이 깊이를 표현해야 할 때 TOML의 중첩 구조는 점으로 구분한 섹션 헤더([servers.alpha])나 테이블 배열([[products]])에 의존하며, 중첩이 늘어날수록 읽기 어려워지는 구조
PyTOML의 Martin Vejnár는 자신의 라이브러리가 pip 의존성이 되는 것을 거절하면서, 구성 스키마가 복잡해지자 TOML 문법이 보기 나쁘고 읽기 어렵다는 경험을 근거로 제시

YAML에서는 들여쓰기가 계층을 한눈에 전달하지만, TOML에서는 각 섹션 헤더에 전체 경로를 반복해야 하는 차이

services:
  web:
    image: nginx:latest
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
    resources:
      limits:
        memory: 512M
        cpu: "0.5"

[services.web]
image = "nginx:latest"

[services.web.environment]
DB_HOST = "postgres"
DB_PORT = 5432

[services.web.resources.limits]
memory = "512M"
cpu = "0.5"

TOML 독자는 평평한 한정 이름의 연속에서 트리 구조를 머릿속으로 재구성해야 하며, StrictYAML 문서의 측정에서는 같은 데이터를 표현할 때 TOML 파일이 반복 경로 접두사 때문에 약 50% 더 많은 문자를 사용
Python은 들여쓰기를 구조로 쓰는 방식이 약점이 아니라 강점임을 오래전에 보여줬고, 시각적 구조와 문법 구조가 어긋나는 버그 종류를 제거하는 효과
YAML은 이런 들여쓰기 구조의 장점을 물려받지만, TOML은 들여쓰기를 요구하지 않아 키와 포함 테이블의 관계가 파일의 물리적 배치가 아니라 섹션 헤더에만 존재
깊게 중첩된 구성 파일에서 TOML은 스캔하기 어렵고 확신을 갖고 편집하기 어려운 형식

YAML 1.2의 변경점

YAML 1.2 명세는 2009년에 발표됐고, 명확화 개정판인 1.2.2는 2021년 10월 완료
YAML 1.2 Core Schema에서는 true, false와 True, False, TRUE, FALSE만 불리언으로 인식하며, yes, no, on, off, y, n은 일반 문자열
22:22 문제를 만든 60진수 숫자 리터럴은 완전히 제거됐고, 타임스탬프는 더 이상 핵심 타입이 아니므로 Core Schema에서 따옴표 없는 2026-05-05는 자동 감지 날짜가 아니라 문자열
JSON은 YAML 1.2의 엄격하고 올바른 부분집합이 되었으며, 유효한 JSON 문서는 YAML로도 동일하게 파싱
태그 해석 규칙은 더 엄격하고 명확해졌고, 명세 자체도 더 분명하게 작성되며 GitHub에서 공개적으로 유지관리
사람들이 비판해 온 YAML은 YAML 1.1이고, 오늘날 언어를 지배하는 명세는 더 안전하고 예측 가능한 YAML 1.2
문제는 사용자의 YAML 경험이 명세가 아니라 파서를 통해 매개된다는 점이며, Python 사용자 대부분에게 그 파서는 YAML 1.1을 구현하고 2006년 이후 핵심 의미론을 바꾸지 않은 PyYAML

Python YAML 파서 지형

PyYAML은 Python의 사실상 표준 YAML 라이브러리이며, 성능을 위해 C 라이브러리 LibYAML을 감싸고 순수 Python 대체 경로도 제공
PyYAML은 매주 수백만 회 다운로드되고 수많은 패키지의 의존성이지만 YAML 1.1을 구현하며, Python 생태계에서 “YAML이 국가 코드를 불리언으로 파싱했다”는 경험의 뿌리
PyYAML 저장소에는 200개가 넘는 열린 이슈와 100개가 넘는 열린 풀 리퀘스트가 있고, 프로젝트는 유지관리 중이지만 느리게 움직이며 YAML 1.2 의미론으로의 주요 버전 전환은 실현되지 않은 상태
ruamel.yaml은 YAML 1.2 지원과 함께 주석, flow style, 키 순서를 보존하는 왕복 편집 기능을 제공하며, 주석 보존이나 형식 인식 편집에는 PyYAML보다 훨씬 강력한 선택지
ruamel.yaml은 기본 왕복 모드에서 주로 순수 Python 구현이기 때문에 PyYAML의 C 기반 빠른 경로보다 상당히 느리고, 네임스페이스 패키지 문제와 의존성 체인 때문에 배포 파이프라인을 혼란스럽게 한 패키징 이력
StrictYAML은 YAML의 의도적인 부분집합을 구현하며, 모든 암시적 타입 추론, 태그, 앵커, flow style을 제거한 형식
StrictYAML은 철학적으로 전체 YAML보다 TOML에 더 가깝고, YAML의 들여쓰기 문법을 쓰는 안전하고 단순한 형식이지만 Python 전용이며 다른 언어 구현도 없고 명세 준수도 목표가 아님
이 지형에서 빠르고, 완전한 YAML 1.2 준수를 제공하며, PyYAML의 기본 인터페이스를 대체하기 쉬운 라이브러리가 부족했던 상황

py-yaml12 소개

py-yaml12는 Python용 YAML 1.2 파서·포매터이며, 속도와 정확성을 위해 Rust로 구현한 라이브러리
py-yaml12는 Rust YAML 라이브러리인 saphyr 크레이트 위에 구축됐고, 로딩용 parse_yaml(), read_yaml(), 직렬화용 format_yaml(), write_yaml()라는 작고 집중된 API 제공
단순성
- 대부분의 사용 사례에서 dict, list, int, float, str, None 같은 기본 Python 내장 타입만으로 처음부터 끝까지 작업하는 설계
- 일반 경로에는 특별한 문서 클래스나 사용자 정의 노드 타입이 없고, YAML 1.2가 JSON의 상위집합이므로 모든 유효한 JSON은 동일하게 파싱
- py-yaml12는 커뮤니티가 유지관리하는 엣지 케이스와 적합성 테스트 모음인 yaml-test-suite에서 100% 준수 달성
- regions 목록의 no는 PyYAML의 YAML 1.1 동작에서는 조용히 False가 되지만, py-yaml12의 YAML 1.2 동작에서는 명세가 요구하는 문자열 "no"로 유지
- 파일 API도 직접적이며, Python 딕셔너리를 디스크에 쓰고 다시 읽으면 같은 객체가 나오는 무손실 왕복 동작
- 태그가 붙은 값 같은 고급 YAML 기능에는 Yaml 래퍼 타입을 제공하지만, 일반적인 구성 작업에서는 선택 사항
안전성
- py-yaml12의 기본값은 사용 편의성뿐 아니라 안전성도 높이며, PyYAML의 반대 접근은 태그를 명령처럼 취급해 YAML 파일을 읽는 것만으로 임의 Python 코드를 실행할 수 있는 위험
- PyYAML의 Python object-apply 태그 네임스페이스를 별칭으로 만든 YAML 파일을 yaml.load(f, Loader=yaml.Loader)로 읽으면 평범한 딕셔너리를 반환하기 전에 Python 코드가 먼저 실행되는 구조
- 예시에서는 파싱 결과가 {'debug': False, 'retries': 3}로 보이지만, 그 전에 환경 변수 YAML_PAYLOAD_RAN이 '1'로 설정되어 결과만 봐서는 실행 사실을 알 수 없는 문제
- py-yaml12는 명시적으로 선택하지 않은 태그를 실행하지 않고 데이터로 유지하며, 처리되지 않은 태그는 값과 태그를 담은 Yaml 래퍼로 반환
속도
- py-yaml12 벤치마크는 킬로바이트부터 메가바이트까지의 파일 크기에서 읽기와 쓰기 성능을 PyYAML의 기본 순수 Python 경로, LibYAML 기반 CSafeLoader·CSafeDumper, ruamel.yaml과 비교
- 핵심 파싱·포매팅 로직을 해석형 Python이 아니라 컴파일된 Rust로 구현했기 때문에, py-yaml12는 완전한 YAML 1.2 준수를 유지하면서 PyYAML의 C 확장과 경쟁 가능한 성능
- 현재 Python 라이브러리 중 완전한 YAML 1.2 준수와 PyYAML C 확장급 성능을 함께 제공하는 선택지는 많지 않은 상황

결론

일반적인 YAML 대 TOML 논쟁은 문제가 있던 형태로는 더 이상 존재하지 않는 형식을 상대로 한 논쟁에 가까우며, 비판은 실제였지만 역사적인 성격
YAML 비판은 명세와 제대로 구현된 YAML 1.2가 아니라 PyYAML을 통해 경험한 YAML 1.1을 가리키는 경우
TOML은 얕고 평평한 구성에는 여전히 좋은 선택이고 pyproject.toml도 그 역할에 잘 맞지만, YAML이 본질적으로 안전하지 않거나 예측 불가능하다는 주장은 호환 YAML 1.2 파서 앞에서는 성립하지 않음
중요한 질문은 추상적으로 어느 형식이 최고인지가 아니라, 어떤 형식과 어떤 도구가 특정 작업에 잘 맞는지의 문제
복잡하고 중첩된 사람이 작성하는 구성 파일에는 최신 파서를 갖춘 YAML 1.2가 강한 답이며, 형식은 이전 세대의 거친 부분을 다음 세대가 바로잡는 방식으로 개선
Python에서는 pip install py-yaml12로 현대적이고 명세를 준수하는 YAML 경험을 확인 가능
R 환경에서는 r-yaml12가 같은 이점을 제공하며, 완전한 YAML 1.2 준수, Rust 기반 성능, 안전한 기본값을 Python 패키지와 동일하게 제공

GN⁺ 20시간전 [-]

Lobste.rs 의견들

YAML이 JSON의 빈틈을 메우려고 나왔다는 설명은 이상함. 기억상으로 YAML은 Perl 커뮤니티에서 나왔고, JSON과 비슷하거나 더 오래됐을 가능성이 있음
실제 역사를 찾아보니 YAML 창시자 중 한 명인 Ingy dot Net의 흥미로운 글에서 기원을 1999년 11월~2001년 1월 사이로 잡고 있음
또 JSON 역사 글을 보면, 원시적인 JSON 형태는 2001년 4월에 숨겨진 iframe과 <script> 태그로 서버에서 클라이언트로 메시지를 보내던 방식에서 등장했고, Douglas Crockford가 json.org를 공개한 2002년에야 독립 형식이 됨
그래서 YAML은 JSON보다 약간 앞섰거나, 관대하게 봐도 둘은 동시에 발전한 쪽에 가까움. JSON에 대한 반응이나 JSON의 빈틈을 메우기 위해 생겼다는 설명은 정확하지 않고, YAML은 실제로 XML에 대한 반응이었음. JSON도 <script> 태그에 데이터를 그대로 넣는 실용적 이유에서 출발했지만, XML보다 단순한 대안으로 자리 잡으며 인기를 얻은 건 부정하기 어려움
글 자체도 LLM이 쓴 듯한 흔적이 보이고, 소개하는 프로젝트도 바이브 코딩된 것 같음
- YAML이 원래 XML에 대한 반응이자 대안이었다고 말하는 건 맞음
- YAML 복잡성을 비판하다가 나중에 새 YAML 명세를 칭찬하는 부분에서 나도 LLM 냄새를 느낌. 1.2.2 명세가 4단계 깊이에 길다고 비판하면서, 뒤에서는 1.2.2가 여전히 크지만 1.1보다는 훨씬 덜 복잡하다고 함
  문장 하나하나는 그럴듯하지만 전체적으로는 헷갈림. 또 TOML은 명세가 있는 언어라고 옹호하면서 YAML은 복잡한 명세가 있다고 비판하는 것도 좀 이상함. YAML은 원래 명세가 없고 TOML은 있었던 건가 싶기도 함
- 그 역사에 한 가지를 더 보태면, Crockford는 원래 E의 부분집합인 Data-E를 다루고 있었고, Data-E는 단순 데이터만 표현했음. E의 저자들은 자체 언어를 밀기보다 ECMAScript를 capability-safe하게 만드는 쪽으로 전환했고, 그 결과 WeakMap 같은 E의 여러 아이디어가 ECMAScript에 들어감
  JSON은 사실상 ECMAScript풍 Data-E에 가까움. Data-E의 보관된 페이지를 보면 그들 역시 XML에 반응하고 있었음을 알 수 있음
- 글을 선의로 다시 해석하면, YAML의 개발 자체가 아니라 YAML 채택이 JSON의 한계에 대한 반응이었다고는 말할 수 있을 듯함. 개인적으로도 JSON이 이미 널리 퍼진 뒤에야 YAML을 알게 됐음. 다만 이 인식을 뒷받침할 데이터는 없음

인라인 테이블을 쓰면 “나쁜” TOML 예시는 이렇게 됨

[services.web]  
image = "nginx:latest"

environment = {  
  DB_HOST = "postgres",  
  DB_PORT = 5432,  
}

resources.limits = {  
  memory = "512M",  
  cpu = "0.5",  
}

보기 괜찮고, 글자 수 따지기라면 YAML 예시보다도 더 짧아 보임

이 글의 목표가 YAML 방어라는 점에서는 범위 밖일 수 있지만, TOML 1.1과 새 인라인 테이블 기능도 다뤘으면 좋았겠음. JSON에서 싫었던 세 가지를 해결해 줌: 따옴표 없는 키 이름, 주석 문자열, 끝 쉼표를 지원함
- “YAML에 대한 비판은 이제 문제 있는 형태로는 존재하지 않는 형식을 공격하는 것”이라고 말하는 건 그럴 수 있지만, 그러고 나서 오래된 TOML 버전을 상대로 논박하는 건 좀 이상함
  Python 3.15는 TOML 1.1을 지원하고, TOML 1.1 채택은 YAML 1.2보다 훨씬 좋아 보임. TOML 1.0 파서를 1.1로 업데이트하는 건 거의 사소한 작업일 가능성이 크지만, YAML 1.1을 1.2로 올리는 건 그렇지 않을 것 같음. yaml.org에서 변경 목록도 잘 못 찾겠고, 거대한 명세 두 개만 보임
  “Norway Problem” 같은 건 내가 YAML을 싫어하는 이유 중 작은 각주에 가깝고, 진짜로는 편집이 까다롭고, 의미 있는 공백을 쓰며, 전체적으로 꽤 복잡해서 싫음
YAML, JSON, TOML은 각자 자기 영역이 있다고 봄. 오랫동안 비어 있다고 느낀 자리는 https://kdl.dev/ 가 채워줬음
JSON = 임의로 중첩되는 데이터 교환
YAML = 여러 줄 문자열을 담는 얕은 컨테이너 형식
TOML = 거의 평평한 설정 파일
KDL = Ruby 스타일 DSL을 데이터로 표현
- 새 프로젝트에서 설정이 필요하면 나도 KDL로 정착했음. 관련 없는 구분자 문법이나 들여쓰기 규칙을 많이 없애주기 때문임
- KDL은 정말 좋음. 쓸 기회를 계속 찾게 됨. XML처럼 속성과 자식 노드를 함께 가지면 마크업이 훨씬 읽기 좋아지는 상황이 있는데, 그런 선택지를 가벼운 문법으로 제공해서 좋음
- 예시를 보자마자 “이거 SDLang처럼 생겼네”라고 생각했는데, 우연이 아니었음. KDL을 알려줘서 좋았음
YAML은 Norway problem 같은 것 때문에 싫음. YAML 1.2가 조금 줄이긴 했지만, 따옴표 없는 문자열 때문에 "", "Null", "true", "FALSE" 같은 문자열도 여전히 문제가 되고 YAML을 아는 인코더가 필요함. 전반적인 복잡성도 싫지만, 내가 YAML을 혐오하는 진짜 이유는 이거임

tab characters must not be used in indentation
들여쓰기가 의미를 가지는 경우, 탭과 공백을 섞거나 일관되지 않게 쓰는 걸 금지하는 건 괜찮음. Python 3의 접근은 꽤 좋아 보임
Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.
하지만 YAML은 들여쓰기를 허용하거나 요구하면서도 탭과 공백을 모두 지원하지 않는 유일한 파일 형식처럼 보임
Make가 공백을 지원하지 않는다고 할 수도 있지만, .RECIPEPREFIX를 탭이 아닌 값으로 설정할 수 있음. 심지어 Make에서 탭은 들여쓰기가 아니라 Make가 쓰는 표식이라고도 볼 수 있음
- 지금은 못 찾겠지만, Guido van Rossum이 Python을 처음부터 다시 만든다면 반드시 바꾸고 싶은 것 중 하나가 들여쓰기의 실제 탭 문자 금지라고 말한 인용을 읽은 기억이 있음
  PEP-8도 들여쓰기에 탭을 쓰지 말라고 강하게 권장함
  
  Tabs should be used solely to remain consistent with code that is already indented with tabs.
  -- https://peps.python.org/pep-0008/#tabs-or-spaces
- 참고로 NestedText 명세도 이렇게 말함
  
  Only ASCII spaces are allowed in the indentation. Specifically, tabs and the various Unicode spaces are not allowed.
“YAML이 나쁜 게 아니라 YAML 1.1이 나빴고, 그런데 대부분은 1.1 파서다”라는 논리는 글이 원하는 만큼 잘 먹히지 않는다고 봄
절제해서 쓰는 YAML은 좋아하고, YAML 1.2용 고성능 파서가 새로 나오는 것도 반갑지만, “나쁜” 버전이 여전히 다수에서 쓰인다면 나는 다른 걸 쓸 것 같음. 어떤 파서가 쓰일지 통제할 수 없어서 내 YAML이 제대로 해석된다고 믿을 수 없다면, YAML 전체는 여전히 “나쁜” 상태임
모두가 1.2로 옮겨야겠지만, 그 전까지는 YAML을 조심스럽게 대하는 것이 괜찮다고 봄
“YAML 대 TOML 논쟁은 보통 더 이상 문제 있는 형태로 존재하지 않는 형식을 공격하는 논쟁이며, 불만은 실제지만 역사적인 것이다”라는 문장에는 GitHub Actions와 Kubernetes 앞에서 비명을 지르게 됨
방어 논리는 강함. 그래도 아주 단순한 문서에서는 TOML이 더 읽기 좋고, 사람들에게 YAML보다 TOML을 쓰게 하기가 더 쉬움
아쉽게도 도구에 대한 공개적인 개발자 인식을 바꾸는 데는 긴 관성의 꼬리가 있음. 사람들은 어떤 이야기를 읽고 마음을 정한 뒤, 공개적인 실수를 하지 않은 다른 도구로 넘어가 버림
- 배열까지 포함해서 조직화가 2단계를 넘어가면 그렇지 않음. 그 시점부터는 들여쓰기가 구조를 훨씬 이해하기 쉽게 만들어 줌
Ruby 인터프리터에 포함된 YAML 파서가 YAML 1.2.2를 지원했으면 좋겠음
하지만 생태계를 깨지 않고 새 버전을 기본값으로 전환하는 방법은 잘 모르겠음
설정 파일 형식이 표준화된 스키마를 지정할 수 있으면 좋겠음. 그러면 편집기가 임의의 설정 파일을 보고 오타 난 키나 타입 불일치를 알려줄 수 있음
키가 무엇을 위한 것인지 “hover” 힌트로 문서화하고, 유효한 키 자동완성도 쉽게 제공해야 함. 잘못된 값을 잡기 위한 간단한 단언이나 계약까지 지원하면 더 좋음. 예를 들어 "color" 키는 /#[a-fA-F0-9]{6}/에 맞아야 하는 식임
이상적으로는 이걸로 설정 파일 자료구조도 자동 생성할 수 있어야 함
- 그건 그냥 XML을 그대로 설명한 것임
  XSD나 Relax NG 같은 여러 검증 명세 형식이 있고, 나는 XML DTD에 가장 익숙해서 다른 것들은 말하기 어렵음
- JSON 파일에는 최상위 키로 $schema 속성을 두고, 올바른 스키마를 정의한 JSON Schema 파일을 참조하는 방식이 꽤 흔함. 본질적으로 JSON용 XSD임. 좋은 편집기는 보통 이걸 바탕으로 자동완성과 빨간 밑줄을 제공할 수 있음
  좋은 점은 TOML과 YAML이 대략 문법만 다른 JSON이라서, 보통 JSON Schema 파일도 함께 쓸 수 있다는 것임

답변달기

YAML을 옹호하며

문제의식

구성 파일 형식의 간략한 역사

YAML 반대 근거였던 문제들

TOML이 잘하는 점

TOML이 버거워지는 지점

YAML 1.2의 변경점

Python YAML 파서 지형

py-yaml12 소개

단순성

안전성

속도

결론

함께 보면 좋은 글 β

댓글과 토론

Lobste.rs 의견들