YAML의 숨은 오류를 미리 막아주는 7가지 팁

YAML는 쿠버네티스(Kubernetes), 앤서블(Ansible), 서클CI(CircleCI), 솔트(Salt)를 포함한 많은 최신 애플리케이션의 중심에 서 있는 언어다. YAML Ain't Markup Language라는 문장의 앞 자를 따서 만든 YAML은 가독성과 유연성이 좋고 JSON 파일로 변환하기 쉽다는 등의 장점을 제공한다. 그러나 YAML에 대한 경험이 없고 부주의한 사람이라면, 몇 가지 문제를 맞닥뜨릴 수 있을 것이다. 

YAML의 기능 중 일부는 편리해 보이지만 사용하다 보면 예상치 못한 문제를 야기하곤 한다. YAML 어셈블링과 배포 경험이 풍부한 사람들도 대수롭지 않게 생각해 그냥 넘긴 문제로 낭패를 보기도 한다. 다음은 YAML에서 나타나는 가장 골치 아픈 문제와 그로부터 빠져나올 수 있는 7가지 팁이다.
 

 

의심스러우면 따옴표로 문자열 묶기

YAML에서 오류를 줄이는 가장 강력한 방법은 문자열이 되어야 하는 모든 것을 따옴표로 묶는 것이다. YAML은 독특하게 따옴표 없이 문자열을 쓸 수 있다. 다음 예처럼 키 movie, title, year과 값인 Blade Runner은 모두 문자열로 해석된다. 1982 값은 숫자로 파싱된다.

- movie:
    title: Blade Runner
    year: 1982

하지만 다음과 구조에서는 조금 달라진다. 즉 영화 제목이 숫자로 해석된다 

- movie:
    title: 1979
    year: 2016

심지어 이것보다 더 나쁜 상황도 존재한다. 다음처럼 ‘No’라는 영화 제목은 부울 값으로 해석될 수도 있다. 

- movie:
    title: No
    year: 2012

따라서 키와 값을 무조건 문자열로 해석해야 한다면, 잠재적인 모호성을 미리 없애야 한다. 문자열을 다음과 같이 따옴표로 묶으면 된다.

- "movie":
    "title": "Blade Runner"
    "year": 1982

따로 이유가 있어서 문자열을 따옴표로 묶지 못하는 상황이라면, 다음처럼 줄임 접두어로 문자열 타입을 지정할 수 있다. 따옴표로 묶은 문자열에 비해 가독성이 약간 떨어지지만, 모호성을 없애면서 따옴표를 이용한 효과를 누릴 수 있다. 

movie: !!str Blade Runner

멀티라인 문자열 주의하기

YAML에서 멀티라인 문자열은 그 형식에 따라 다양하게 표현할 수 있다. 예를 들어 따옴표 없는 문자열은 다음과 같이 앞에 >를 붙여 여러 줄로 나눌 수 있다. 이때 >를 사용하면 문자열 끝에 자동으로 \n이 붙는다는 점에 유의하자. 후행 줄 바꿈을 원하지 않는다면 > 대신 >-를 사용하면 된다.

long string: >
    This is a long string
    that spans multiple lines.

따옴표로 묶은 문자열을 사용할 경우, 각각의 줄 바꿈 앞에서는 백슬래시를 붙여야 한다. 참고로 줄바꿈 뒤에 오는 공백은 문자열의 일부가 아닌 YAML 서식으로 해석된다. 다음 예시처럼 백슬래시 앞에 공백을 일부러 넣어두면 string과 that이라는 두 단어가 붙지 않는다.

long string: "This is a long string \
    that spans multiple lines."

부울값 확인하기

YAML에서 가장 큰 골칫거리는 부울 값이다. YAML에서는 부울 값을 지정하는 방법이 너무 많아서 문자열이 되어야 하는 것까지 자칫 부울로 해석되기 쉽다. 가장 악명 높은 문제는 두 자리로 표현하 국가 코드다. 국가가 US 또는 UK라면 상관없다. 하지만 노르웨이라면 국가 코드는 NO이고, 이런 경우 노르웨이는 문자열이 아니라 부울 값이 되면서 false로 계산된다. 따라서 부울 값과 부울 값으로 잘못 해석될 소지가 있는 짧은 문자열은 명시적으로 표현하자. YAML에서 부울의 단축형 접두어는 !!bool이다. 
 

8진수 형태 살펴보기

YAML 1.1과 YAML 1.2의 8진수 표기 방법은 서로 다르다. YAML 1.1에서 8진수는 0777과 같이 표현되지만 YAML 1.2에서는 0o777이다. 즉 훨씬 덜 모호한 방식으로 변했다. 

YAML가 자주 사용되는 쿠버네티스에서는 YAML 1.1을 사용한다. 버전 1.2를 사용하는 다른 애플리케이션과 함께 YAML을 사용하는 경우라면, 잘못된 8진수 표기법을 사용하지 않도록 각별히 주의해야 한다. 요즘에는 8진수는 보통 파일 권한에만 사용되므로 이런 유형의 문제는 많이 발생하지 않는다. 그렇다고 해도 조심하지 않으면 8진수 부분으로 오류가 생길 수 있다. 
 

실행 가능한 YAML 조심하기

실행 가능한 YAML이라고 하면 어색하게 들릴 수 있겠지만, 파이YAML(PyYAML) 같은 YAML 라이브러리 상당수가 역직렬화될 때 임의 명령 실행이 가능하다. 놀랍게도 이건 버그가 아니라 YAML에서 의도한 기능이다. 파이YAML의 경우 오류를 방지하기 위해 YAML의 안전한 하위 집합만 지원하도록 역직렬화의 기본 동작이 변경됐다. 원래의 동작을 수동으로 되살릴 수 있지만 가능하다면 이 기능은 사용하지 말아야 한다. 만약 비활성화되지 않은 상태라면 미리 비활성화해두자.
 

직렬화와 역직렬화에 나타나는 비일관성 주의하기

서로 다른 언어로 이루어지면서 YAML를 처리하는 라이브러리를 이용할 경우, 가끔 결과가 일관적이지 않을 수 있다. 예를 들어 YAML 파일에 true와 false로 표현되는 부울 값이 있는 경우, 부울 값을 y와 n 또는 on과 off로 표현하는 다른 라이브러리를 사용해 다시 직렬화할 수 있으며 예상치 못한 결과를 얻을 수 있다. 기능적으로 코드는 동일하지만 완전히 달라 보일 수 있다.
 

직접적인 YAML 사용을 피하기

YAML의 문제를 피하는 가장 일반적인 방법은은 사용하지 않는 것이다. 정확히 말해 직접적으로는 사용하지 않는 것이다. 구성 프로세스의 일부로 YAML을 꼭 써야 한다면 JSON 또는 네이티브 코드(예를 들어 파이썬 사전)로 쓴 다음 YAML로 직렬화하는 것이 더 안전할 수 있다. 이렇게 하면 개체의 유형에 대해 더 많은 부분을 제어할 수 있고 이미 익숙한 언어를 사용하는 데서 오는 편안함도 얻을 수 있다.

이런 방식도 선택할 수 없는 상황이라면, yamllint와 같은 린터를 사용해서 일반적인 YAML 문제를 검사할 수 있다. 이런 도구는로 YES나 off와 같은 모호한 값을 금지하고 true와 false를 사용하도록 하거나 문자열 따옴표로 묶기를 강제할 수 있다.
editor@itworld.co.kr