YAML편집자 확인

YAML 문서의 구조는 공백 문자, 특히 들여쓰기에 의해 정의된다. 들여쓰기는 탭 문자 대신 공백을 사용해야 하며, 동일한 수준의 요소는 동일한 열에서 시작해야 한다. 일반적으로 각 들여쓰기 수준은 2개의 공백을 사용하지만, 문서 내에서 일관성만 유지된다면 다른 개수도 허용된다.

YAML은 세 가지 기본 컬렉션 구조를 제공한다. 첫째는 시퀀스로, 하이픈과 공백(- )으로 시작하는 항목들의 순서 있는 목록이다. 둘째는 매핑으로, 키-값 쌍의 모음이며, 콜론과 공백(: )으로 키와 값을 구분한다. 셋째는 블록 시퀀스/매핑과 플로우 스타일의 차이이다. 블록 스타일은 들여쓰기를 사용하여 구조를 나타내는 반면, 플로우 스타일은 JSON과 유사하게 대괄호([])와 중괄호({})를 사용하여 인라인으로 표현한다.

복잡한 구조는 이러한 컬렉션을 중첩하여 만들 수 있다. 예를 들어, 시퀀스 안에 매핑을 포함하거나, 매핑의 값으로 또 다른 시퀀스를 사용할 수 있다. 이때 각 중첩 수준은 부모 요소보다 더 깊은 들여쓰기로 표현된다.

YAML에서 스칼라는 문자열, 숫자, 불리언, 널과 같은 단일 값을 지칭하는 용어이다. 이는 컬렉션인 시퀀스와 매핑과 구분되는 기본 데이터 타입이다. 스칼라 값은 일반적으로 들여쓰기를 통해 구조 내에서 표현되며, 따옴표 사용 여부와 서식에 따라 여러 가지 스타일로 작성될 수 있다.

가장 일반적인 스칼라 타입은 문자열이다. 문자열은 따옴표 없이, 작은따옴표(')로, 또는 큰따옴표(")로 감싸 표현한다. 따옴표 없이 작성된 문자열은 플레인 스타일이라고 하며, 특수 문자가 없을 때 주로 사용된다. 작은따옴표는 이스케이프를 거의 허용하지 않아 문자열을 있는 그대로 표현하고, 큰따옴표는 이스케이프 시퀀스(예: \n, \t)를 사용할 수 있다. 숫자 타입은 정수(예: 42), 부동소수점수(예: 3.14159), 지수 표기법(예: 1.2e+34) 등을 그대로 작성하여 인식한다. 불리언 값은 true와 false로 표현하며, 널 값은 null 또는 물결표시(~)로 나타낸다.

YAML은 추가로 몇 가지 특별한 스칼라 형식을 자동으로 인식한다. 예를 들어, 시간과 날짜를 ISO 8601 형식으로 표현하면 자동으로 해당 타입으로 해석된다[3]. 또한, yes, no, on, off와 같은 값은 불리언으로 해석될 수 있으며, 숫자로 시작하는 문자열(예: 123abc)이나 특정 기호(예: :, -, {, })를 포함하는 문자열은 명시적으로 따옴표로 감싸야 문자열로 처리된다. 이는 YAML 파서의 자동 타입 추론 규칙에 따른 것이다.

YAML 문서에서 주석은 # 기호로 시작하며, 해당 줄의 끝까지 유효하다. 주석은 설정값에 대한 설명, 임시로 비활성화하는 용도, 또는 문서 작성자 정보를 기록하는 데 사용된다. 주석은 파서에 의해 완전히 무시되며, 직렬화 과정에서도 제거된다.

문서 구분자는 ---와 ...이다. ---는 단일 파일 내에서 여러 문서의 시작을 표시하는 문서 시작 표시자로 사용된다. ...은 문서의 끝을 표시하지만, 파일의 마지막 문서에서는 생략하는 것이 일반적이다. 하나의 스트림에 여러 YAML 문서를 포함할 수 있는 이 기능은 로그 파일이나 구성 항목을 스트리밍할 때 유용하다.

예를 들어, 하나의 파일에 서로 독립된 두 개의 설정 문서를 포함할 수 있다.

```

# 이 파일은 두 개의 설정을 포함한다.

---

server: app1

port: 8080

# 첫 번째 설정 끝

...

---

server: app2

port: 9090

# 두 번째 설정. '...'은 생략 가능하다.

```

이 구조는 도커 컴포즈나 쿠버네티스 매니페스트 파일처럼 여러 리소스 정의를 단일 파일에 배치할 때 자주 활용된다.

YAML 문서 내에서 동일한 데이터를 재사용하거나 순환 참조를 생성하기 위해 앵커와 별칭 기능을 제공한다. 앵커는 & 기호로 표시하여 특정 노드에 이름을 부여하고, 별칭은 * 기호로 표시하여 해당 이름이 붙은 노드를 참조한다. 이를 통해 데이터의 중복을 제거하고 문서 구조를 간결하게 유지할 수 있다.

예를 들어, 공통된 설정 값을 여러 곳에서 사용할 경우, 한 번 정의하고 여러 번 참조하는 방식으로 작성한다.

```yaml

# 앵커로 기본 설정 정의

defaults: &base_settings

api_version: v1

timeout: 30

retry: false

# 별칭으로 기본 설정 참조

service_a:

<<: *base_settings

endpoint: /api/a

service_b:

<<: *base_settings

endpoint: /api/b

timeout: 60 # 기본값 오버라이드

```

위 예제에서 &base_settings는 defaults 노드에 앵커를 설정한다. service_a와 service_b 정의에서 <<: *base_settings는 해당 앵커의 내용을 병합한다. service_b는 timeout 값을 오버라이드하여 재정의한다.

이 기능은 복잡한 객체나 리스트를 반복해서 정의해야 할 때 특히 유용하다. 순환 데이터 구조를 표현할 수도 있으나, 일부 파서나 도구에서는 지원에 제한이 있을 수 있다[5]. 앵커와 별칭을 사용할 때는 참조 대상이 문서 내에 명확하게 정의되어 있어야 하며, 무한 순환 참조를 방지해야 한다.

YAML의 태그는 노드에 명시적 데이터 타입을 지정하는 데 사용되는 선택적 기능이다. 태그는 느낌표(!)로 시작하며, 단일 문서 내에서 앵커와 별칭 시스템과 결합하여 복잡한 사용자 정의 타입 구조를 정의할 수 있다.

YAML 사양에는 정수, 부동소수점, 불리언, 널, 시퀀스, 매핑과 같은 일반적인 스칼라 타입을 위한 내장 태그 집합이 정의되어 있다[6]. 사용자는 애플리케이션 특화 타입을 나타내기 위해 커스텀 태그를 정의할 수 있다. 태그는 보통 !<tag-name> 형태로 사용되며, 특정 언어의 클래스나 데이터 구조에 매핑된다. 예를 들어, 파이썬의 datetime 객체를 직렬화하기 위해 !python/datetime과 같은 태그를 사용할 수 있다.

사용자 정의 타입을 처리할 때는 주의가 필요하다. 태그 해석은 YAML 파서나 로더의 구현체와 사용 중인 프로그래밍 언어 바인딩에 크게 의존한다. 하나의 애플리케이션에서 정의한 커스텀 태그는 다른 시스템에서 자동으로 인식되지 않을 수 있다. 따라서 상호 운용성이 중요한 경우, JSON 스키마와 같은 외부 검증 메커니즘을 함께 사용하거나, 가능한 한 표준화된 태그와 데이터 표현을 사용하는 것이 모범 사례로 간주된다.

멀티라인 문자열은 긴 텍스트나 여러 줄로 구성된 데이터를 YAML 문서 내에서 표현하는 방법이다. YAML은 이를 위해 몇 가지 스타일을 제공하며, 각 스타일은 줄바꿈과 들여쓰기 처리가 다르게 동작한다.

주요 스타일은 리터럴 스타일(|)과 접기 스타일(>)이다. 리터럴 스타일은 문자열 내의 모든 줄바꿈과 들여쓰기를 그대로 보존한다. 이는 코드 스니펫이나 형식이 중요한 문서를 포함할 때 유용하다. 접기 스타일은 각 줄의 끝에 있는 공백을 제거하고, 연속된 줄을 하나의 공백으로 접어서 단일 줄로 만든다. 단, 빈 줄은 줄바꿈으로 유지되어 단락을 구분하는 데 사용된다. 이는 긴 설명문이나 단락을 자연스럽게 표현하는 데 적합하다. 각 스타일 뒤에는 블록 키머리(Block Chomping) 지시자를 추가하여 문자열 끝부분의 줄바꿈 처리를 제어할 수 있다. | 또는 >만 사용하면 마지막 줄바꿈을 유지하고, |- 또는 >-는 마지막 줄바꿈을 제거하며, |+ 또는 >+는 모든 줄바꿈(빈 줄 포함)을 보존한다.

멀티라인 문자열 블록의 들여쓰기는 해당 블록의 시작을 나타내는 들여쓰기 수준에 의해 결정된다. 블록 내에서 더 깊은 들여쓰기를 가진 줄은 그대로 유지되지만, 블록 시작보다 적은 들여쓰기를 가진 줄은 새로운 YAML 노드의 시작으로 해석되어 파싱 오류를 일으킬 수 있다.

YAML은 인간 친화적 특성 덕분에 설정 파일 형식으로 널리 채택되었다. 특히 소프트웨어 구성 관리와 애플리케이션 설정 분야에서 두드러지게 사용된다. 계층적 구조를 들여쓰기로 표현하는 방식은 복잡한 설정을 직관적으로 정의하고 가독성을 높이는 데 유리하다.

주요 사용 사례로는 웹 애플리케이션 프레임워크, 컨테이너 오케스트레이션 도구, 정적 사이트 생성기 등이 있다. 예를 들어, Ruby on Rails의 database.yml, Docker Compose의 docker-compose.yml, Kubernetes의 매니페스트 파일(deployment.yml, service.yml 등), Jekyll의 _config.yml이 대표적이다. 이러한 도구들은 YAML을 통해 환경 변수, 데이터베이스 연결 정보, 서비스 의존성, 빌드 설정 등을 관리한다.

YAML 설정 파일의 구조는 일반적으로 다음과 같은 패턴을 따른다.

설정 파일로 사용될 때의 주요 장점은 주석 지원, 앵커와 별칭을 통한 설정 재사용, 그리고 멀티라인 문자열을 이용한 긴 값의 편리한 기입이다. 그러나 들여쓰기에 민감하여 공백과 탭을 혼용하면 파싱 오류가 발생할 수 있으므로 주의가 필요하다.

YAML은 사람이 쉽게 읽고 쓸 수 있는 형식으로 계층적 데이터를 표현하기 위해 설계되었으며, 이 특성은 데이터 직렬화 용도로 널리 사용되는 주요 이유가 된다. 데이터 직렬화는 데이터 구조나 객체 상태를 저장하거나 전송할 수 있는 형식(예: 파일, 메모리 버퍼, 네트워크 연결)으로 변환하는 과정을 의미한다. YAML은 JSON이나 XML과 같은 다른 직렬화 형식에 비해 가독성이 높고, 주석을 지원하며, 복잡한 데이터 관계를 표현하는 데 유연한 문법을 제공한다.

주요 프로그래밍 언어들은 대부분 YAML 데이터를 파싱하고 생성할 수 있는 라이브러리를 제공한다. 예를 들어, Python의 PyYAML이나 ruamel.yaml, Java의 SnakeYAML, JavaScript의 js-yaml 등이 널리 사용되는 구현체이다. 이를 통해 애플리케이션은 YAML 형식의 설정 파일을 읽거나, 내부 객체의 상태를 YAML 문서로 내보내어 로그 기록이나 데이터 교환에 활용할 수 있다. 아래 표는 몇 가지 언어와 해당 YAML 처리 라이브러리를 보여준다.

YAML을 직렬화 형식으로 사용할 때의 장점은 인간 친화적인 문법과 앵커와 별칭 같은 참조 기능을 통해 중복을 제거할 수 있다는 점이다. 그러나 단점으로는 파싱 속도가 JSON에 비해 상대적으로 느리고, 과도하게 복잡한 표현이 가능하다는 점 때문에 구현체 간 호환성 문제가 발생할 수 있다는 점을 들 수 있다. 따라서 네트워크 프로토콜이나 고성능 API에서는 JSON을, 구성 관리나 복잡한 데이터 구조를 사람이 직접 작성해야 하는 경우에는 YAML을 선택하는 것이 일반적인 관행이다.

YAML은 CI/CD 파이프라인에서 구성 파일을 정의하는 데 널리 사용된다. 특히 지속적 통합과 지속적 배포를 자동화하는 도구들의 설정 표준 형식으로 자리 잡았다. 대표적인 예로 GitHub Actions의 워크플로우 파일(.github/workflows/*.yml), GitLab CI/CD의 .gitlab-ci.yml 파일, CircleCI의 config.yml 파일, 그리고 Jenkins 파이프라인을 정의하는 데 사용되는 Declarative Pipeline 문법 등이 있다. 이들 도구는 YAML 파일을 읽어 빌드, 테스트, 배포 단계를 순차적 또는 병렬로 실행한다.

YAML이 CI/CD 설정에 적합한 이유는 가독성이 높은 계층적 구조 덕분이다. 파이프라인은 일반적으로 여러 단계(예: build, test, deploy)로 구성되며, 각 단계는 다시 여러 작업(예: 특정 스크립트 실행, 도커 이미지 사용)을 포함한다. YAML의 들여쓰기 기반 블록 구조는 이러한 중첩 관계를 명확하게 표현한다. 또한 멀티라인 문자열 기능을 활용해 인라인 스크립트를 깔끔하게 작성할 수 있다.

다음은 간단한 CI 파이프라인 YAML 구성의 예시다.

YAML을 CI/CD에 사용할 때는 몇 가지 주의점이 있다. 들여쓰기에 공백과 탭을 혼용하면 파싱 오류가 발생할 수 있다. 또한 복잡한 로직이나 조건문을 표현하기에는 한계가 있어, 일부 도구들은 템플릿 언어나 특수한 키워드를 추가로 도입하기도 한다. 이러한 구성 파일은 보통 버전 관리 시스템에 저장되어 파이프라인의 변경 내역을 추적하고 팀원들과 공유한다.

YAML 파서는 YAML 문서를 읽어 해당 프로그래밍 언어의 네이티브 데이터 구조로 변환하는 소프트웨어 구성 요소이다. 다양한 프로그래밍 언어를 위한 공식 및 비공식 구현체가 존재하며, 각각의 특징과 성능이 다르다.

가장 널리 알려진 공식 구현체는 C로 작성된 libyaml("Syck"의 후속)과 libyaml을 기반으로 한 여러 언어 바인딩이다. Python의 경우 PyYAML 라이브러리가 사실상의 표준으로 자리 잡았으며, ruamel.yaml은 YAML 1.2 규격을 더 잘 지원하고 주석 보존 등의 고급 기능을 제공한다. JavaScript/Node.js 환경에서는 js-yaml 라이브러리가 일반적으로 사용된다. Java 진영에는 SnakeYAML 라이브러리가, Ruby에는 Psych(libyaml 기반)가 내장되어 있다. Go 언어에는 go-yaml 및 yaml.v3 패키지가 널리 사용된다.

파서 라이브러리를 선택할 때는 YAML 사양 버전(1.1 vs 1.2) 지원, 성능, 보안 취약점(예: 신뢰할 수 없는 입력으로부터의 코드 인젝션 방지), 고급 기능(앵커/별칭, 사용자 정의 태그 처리) 지원 여부를 고려해야 한다. 일부 파서는 스트리밍(큰 파일을 청크 단위로 처리)을 지원하지만, 대부분은 문서 전체를 메모리에 로드하는 방식을 사용한다.

YAML 파일의 구조와 내용이 사양을 준수하는지 확인하고, 일관성과 모범 사례를 따르도록 도와주는 도구들이 존재합니다. 이러한 도구는 복잡한 설정 파일이나 데이터 파일을 다룰 때 오류를 사전에 방지하고 가독성을 높이는 데 필수적입니다.

유효성 검사 도구는 주로 YAML 문법의 정확성을 검증합니다. 예를 들어, 들여쓰기 오류, 잘못된 앵커와 별칭 참조, 지원되지 않는 타입 사용 등을 감지합니다. 일부 도구는 JSON 스키마나 YAML 자체로 작성된 스키마 정의 파일을 사용하여 데이터의 구조와 값의 유효성(예: 필수 필드 존재 여부, 문자열 패턴, 숫자 범위)을 검사할 수 있습니다. 이는 특히 CI/CD 파이프라인에서 자동화된 테스트의 일환으로 활용됩니다.

린팅 도구는 문법적 오류보다는 스타일과 모범 사례에 초점을 맞춥니다. 일관되지 않은 들여쓰기, 불필요한 따옴표 사용, 중복된 키, 권장되지 않는 구문 사용 등을 지적하여 코드의 품질과 유지보수성을 향상시킵니다. 일부 인기 있는 린터는 사용자 정의 규칙을 설정할 수 있어 팀이나 프로젝트별 코딩 컨벤션을 강제하는 데 유용합니다.

이러한 도구들은 명령줄 인터페이스(CLI)로 실행하거나 편집기 및 통합 개발 환경(IDE)에 플러그인 형태로 통합되어 작업 흐름 내에서 실시간 피드백을 제공합니다.