YAML 명세의 잘못은 아니지만…

no를 불리언으로 읽는 ‘노르웨이 문제’는 YAML이 반드시 요구하는 동작이 아니며, 초기 명세 설계자들은 스칼라를 기본적으로 문자열로 처리하기를 권장했음 YAML 1.0·1.1은 암묵적 타입 결정을 애플리케이션에 맡겼고, 1.2의 권장 Core 스키마에는 yes·no 불리언이나 60진수 변환이 없음 2002년 타입 정책 변경이 구현체에 제대로 반영되지 않은 채, 기존 동작을 유지한 Syck가 2003년 8월 Ruby 표준 라이브러리에 들어가면서 명세보다 구현체의 동작이 사용자 기대를 굳힘 Space Station 14는 YAML 노드를 코드에 정의된 모델에 따라 직접 역직렬화하고, 불리언 필드에서만 불리언으로 변환해 잘못된 타입 추론을 피함 명세 개선만으로 실제 동작이 바뀌지는 않음을 YAML의 역사가 보여주며, YAML 조직이 관리하는 PyYAML조차 여전히 YAML 1.2를 지원하지 않음 YAML 비판의 세 축과 실제 사용 경험 YAML은 동적 프로그래밍 언어의 일반적인 자료형을 바탕으로 한, 사람이 읽기 쉬운 유니코드 기반 데이터 직렬화 언어임 설정 파일부터 메시징, 객체 영속화, 데이터 감사·시각화까지 폭넓은 용도를 목표로 함 YAML 반대 사이트, 문제 사례 분석, StrictYAML의 암묵적 타입 비판에서 반복되는 문제는 거대한 명세, 제각각인 라이브러리 구현, 암묵적 타입 결정의 세 가지임 9년 전 만든 Python Discord 봇은 설정 파일을 yaml.safe_load()로 읽었으며, 흔히 비판받는 YAML 문제는 겪지 않았지만 설정·직렬화 구조에는 문제가 있었음 config.yml로 기본 구조와 기본값을 만든 뒤 override.yml을 병합해야 했으며, 이는 YAML 자체의 잘못은 아님 영속 데이터용 pickle에서는 사실상 람다를 저장하는 defaultdict 인스턴스의 직렬화도 문제가 됨 이 경험은 Python 같은 동적 언어의 객체 직렬화에 대한 비판과, 코드에 정의된 모델을 기준으로 직렬화해야 한다는 접근으로 이어짐 Space Station 14가 타입 추론을 피하는 방법 Space Station 14는 엔티티·레시피와 약 200가지 다른 항목의 데이터 정의인 ‘프로토타입’ 등에 YAML을 사용함 초기 XML 형식에서 YAML로 전환한 결과는 대체로 성공적임 가장 큰 어려움은 새 기여자가 공백에 민감한 문법을 놓쳐 구문 오류를 내는 경우였음 객체 역직렬화는 처음부터 자체 코드가 담...