데이터 직렬화 언어 YAML(Yet Another Markup Language)에서 'no'와 같은 문자열이 의도치 않게 불리언(boolean) 값으로 해석되는 현상, 즉 '노르웨이 문제'는 사실 YAML 명세(specification)의 잘못이 아니라는 흥미로운 분석이 나왔습니다. 초기 YAML 설계자들은 스칼라(scalar) 값을 기본적으로 문자열로 처리하도록 강력히 권장했지만, 일부 라이브러리 구현체가 이 권고를 따르지 않으면서 사용자들의 잘못된 기대가 굳어졌다는 지적입니다.
YAML 1.0과 1.1은 따옴표 없는 스칼라의 암묵적 타입 결정(implicit type determination)을 애플리케이션에 맡겼습니다. 2002년에는 이 타입 정책이 '강한 암묵적 타입'에서 '애플리케이션 선택'으로 변경되어, 기본적으로 모든 스칼라를 문자열로 처리하고 필요한 경우에만 특정 타입으로 변환하도록 권고했습니다. 그러나 2003년 8월, 이러한 변경 사항이 제대로 반영되지 않은 Syck 라이브러리가 Ruby 표준 라이브러리에 포함되면서, 명세의 의도와 다르게 'yes', 'no' 등을 불리언으로 자동 해석하는 기존 동작이 사실상 표준처럼 자리 잡았습니다. 심지어 YAML 1.2의 권장 코어 스키마(Core Schema)에는 'yes', 'no' 불리언이나 60진수 변환 규칙이 포함되어 있지 않습니다. 이는 명세가 바뀌어도 기존 구현체의 영향력이 얼마나 큰지를 보여주는 사례입니다.
이러한 배경은 오늘날 YAML이 설정 파일 용도로 주로 사용되면서도 '거대한 명세', '제각각인 라이브러리 구현', '암묵적 타입 결정'이라는 세 가지 비판을 받는 이유를 설명합니다. Space Station 14와 같은 프로젝트에서는 이러한 문제를 피하기 위해 YAML 노드를 코드에 정의된 모델에 따라 직접 역직렬화(deserialization)하고, 불리언 필드에서만 불리언으로 변환하는 방식을 채택하고 있습니다. 이는 입력값의 형태에 따라 타입을 추측하는 대신, 프로그램 코드의 모델을 기준으로 직렬화/역직렬화하는 것이 더 견고하다는 교훈을 줍니다. 결국 YAML의 역사는 명세 개선만으로는 실제 동작이 바뀌지 않을 수 있으며, 라이브러리 구현과 사용자 기대 관리의 중요성을 강조합니다.