YAML 문법 마스터 완벽 가이드

DevOps와 클라우드 환경에서 필수적으로 사용되는 YAML 문법을 기초부터 실무 활용까지 체계적으로 다룹니다. Kubernetes 매니페스트 작성에 필요한 핵심 문법을 쉬운 비유와 실전 예제로 설명합니다.

1. YAML vs JSON 비교

어느 날 김개발 씨가 새로운 프로젝트에 투입되었습니다. 설정 파일을 보니 어떤 것은 JSON으로, 어떤 것은 YAML로 작성되어 있었습니다.

"둘 다 비슷해 보이는데, 왜 굳이 다른 형식을 쓰는 걸까요?" 궁금증이 생긴 김개발 씨는 선배에게 질문했습니다.

YAML은 "YAML Ain't Markup Language"의 약자로, 사람이 읽기 쉬운 데이터 직렬화 형식입니다. JSON과 동일한 데이터를 표현할 수 있지만, 중괄호와 따옴표 대신 들여쓰기를 사용하여 훨씬 깔끔하게 작성할 수 있습니다.

특히 설정 파일처럼 사람이 자주 읽고 수정해야 하는 경우에 YAML이 더 적합합니다.

다음 코드를 살펴봅시다.

# JSON 형식
{
  "server": {
    "host": "localhost",
    "port": 3000,
    "enabled": true
  }
}

# YAML 형식 (동일한 데이터)
server:
  host: localhost
  port: 3000
  enabled: true

김개발 씨는 입사한 지 얼마 되지 않은 주니어 개발자입니다. 오늘 처음으로 Kubernetes 프로젝트에 투입되었는데, 설정 파일들을 보니 머리가 어지러웠습니다.

어떤 파일은 중괄호로 가득하고, 어떤 파일은 깔끔하게 정리되어 있었습니다. 선배 개발자 박시니어 씨가 다가와 설명해 주었습니다.

"JSON과 YAML은 형제 같은 존재야. 같은 내용을 담을 수 있지만, 옷을 다르게 입고 있는 거지." YAML을 이해하려면 먼저 JSON을 떠올려 보면 됩니다.

JSON은 자바스크립트에서 태어난 데이터 형식으로, 중괄호와 대괄호, 따옴표로 구조를 표현합니다. 프로그램이 읽기에는 완벽하지만, 사람이 직접 작성하기에는 조금 번거롭습니다.

반면 YAML은 마치 깔끔하게 정리된 메모장 같습니다. 서랍장을 생각해 보세요.

JSON은 모든 서랍에 라벨을 붙이고 잠금장치까지 달아놓은 느낌이라면, YAML은 한눈에 보이도록 열어둔 서랍장과 같습니다. 어떤 칸에 무엇이 있는지 바로 알 수 있습니다.

왜 DevOps 세계에서는 YAML을 선호할까요? 설정 파일은 개발자가 수시로 읽고 수정해야 합니다.

Docker Compose, Kubernetes, GitHub Actions, Ansible 등 거의 모든 현대적인 도구들이 YAML을 채택한 이유가 바로 여기에 있습니다. 위의 코드 예제를 살펴보면 차이가 명확하게 드러납니다.

JSON에서는 중괄호, 쉼표, 따옴표가 필수입니다. 하나라도 빠지면 오류가 납니다.

하지만 YAML에서는 들여쓰기만으로 계층 구조를 표현합니다. 따옴표도 대부분의 경우 생략할 수 있습니다.

실무에서 GitHub Actions 워크플로우를 작성한다고 가정해 봅시다. 수십 줄의 설정을 JSON으로 작성하면 중괄호 짝 맞추기에만 시간을 허비하게 됩니다.

YAML로 작성하면 마치 목록을 정리하듯 직관적으로 작성할 수 있습니다. 하지만 주의할 점도 있습니다.

YAML은 들여쓰기에 민감합니다. 스페이스 하나가 잘못되면 전혀 다른 의미가 될 수 있습니다.

JSON은 들여쓰기가 문법과 무관하지만, YAML에서는 들여쓰기 자체가 문법입니다. 또한 JSON은 모든 프로그래밍 언어에서 기본적으로 지원하지만, YAML은 별도의 파서가 필요한 경우가 많습니다.

API 응답에는 JSON이, 설정 파일에는 YAML이 적합한 이유입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 Kubernetes 설정은 YAML이고, REST API 응답은 JSON인 거군요!" 두 형식의 특성을 이해하면 상황에 맞는 적절한 선택을 할 수 있습니다.

사람이 자주 수정하는 설정 파일에는 YAML을, 프로그램 간 데이터 교환에는 JSON을 사용하는 것이 일반적인 관례입니다.

실전 팁

💡 - YAML은 JSON의 상위 집합입니다. 모든 JSON은 유효한 YAML이지만, 그 반대는 아닙니다.

설정 파일 작성 시에는 YAML을, API 통신에는 JSON을 사용하는 것이 업계 표준입니다.

2. 기본 문법 키값 리스트 중첩

김개발 씨가 첫 번째 Kubernetes 설정 파일을 작성하려고 합니다. 빈 파일을 열어놓고 막막해하던 그때, 박시니어 씨가 "YAML의 세 가지 기본 요소만 알면 어떤 설정 파일이든 읽을 수 있어"라고 말했습니다.

그 세 가지란 무엇일까요?

YAML의 기본 구성 요소는 키-값 쌍, 리스트, 그리고 중첩 구조 세 가지입니다. 키-값은 사전처럼 이름과 값을 연결하고, 리스트는 순서가 있는 항목들의 모음이며, 중첩은 이들을 조합하여 복잡한 구조를 만듭니다.

이 세 가지만 이해하면 어떤 YAML 파일이든 읽고 쓸 수 있습니다.

다음 코드를 살펴봅시다.

# 키-값 쌍: 콜론으로 구분
name: my-application
version: 1.0.0

# 리스트: 하이픈으로 시작
dependencies:
  - express
  - lodash
  - axios

# 중첩 구조: 들여쓰기로 계층 표현
database:
  primary:
    host: db.example.com
    port: 5432
  replicas:
    - host: replica1.example.com
    - host: replica2.example.com

김개발 씨는 YAML 파일 앞에서 한숨을 쉬었습니다. 복잡해 보이는 설정 파일이 수백 줄에 달했기 때문입니다.

하지만 박시니어 씨는 웃으며 말했습니다. "걱정 마.

아무리 복잡한 YAML도 세 가지 기본 요소의 조합일 뿐이야." 첫 번째 요소는 키-값 쌍입니다. 마치 사전에서 단어와 뜻을 찾는 것과 같습니다.

"name"이라는 단어를 찾으면 "my-application"이라는 뜻이 나오는 식입니다. YAML에서는 키와 값 사이에 콜론과 공백을 넣습니다.

이때 콜론 뒤에 반드시 공백이 있어야 한다는 점을 기억하세요. 두 번째 요소는 리스트입니다.

장보기 목록을 생각해 보세요. 우유, 빵, 계란처럼 여러 항목을 나열할 때 앞에 점을 찍거나 번호를 붙이듯이, YAML에서는 하이픈과 공백으로 시작합니다.

각 항목이 순서대로 나열되어 있다는 것을 한눈에 알 수 있습니다. 세 번째 요소는 중첩 구조입니다.

이것은 서류 캐비닛을 떠올리면 됩니다. 큰 서랍 안에 작은 폴더가 있고, 그 폴더 안에 문서가 있는 것처럼, YAML에서도 들여쓰기를 통해 계층을 표현합니다.

들여쓰기가 깊어질수록 더 안쪽에 있는 데이터입니다. 위의 코드 예제를 천천히 살펴보겠습니다.

맨 위의 name과 version은 단순한 키-값 쌍입니다. 파일의 최상위 레벨에 있어서 들여쓰기가 없습니다.

dependencies 부분을 보면 키-값과 리스트가 결합되어 있습니다. dependencies라는 키 아래에 세 개의 항목이 하이픈으로 나열되어 있습니다.

하이픈으로 시작하는 각 줄이 리스트의 한 요소입니다. database 부분은 가장 복잡한 중첩 구조입니다.

database 안에 primary와 replicas가 있고, primary 안에는 다시 host와 port가 있습니다. replicas는 리스트인데, 각 요소가 또다시 키-값 쌍을 가지고 있습니다.

이처럼 세 가지 요소를 자유롭게 조합할 수 있습니다. 실무에서 Docker Compose 파일을 작성한다고 생각해 봅시다.

services라는 키 아래에 여러 서비스를 정의하고, 각 서비스는 image, ports, environment 같은 키-값 쌍을 가집니다. ports는 리스트 형태로 여러 포트를 매핑할 수 있습니다.

모든 것이 세 가지 기본 요소의 조합입니다. 초보자가 흔히 하는 실수 중 하나는 콜론 뒤에 공백을 빼먹는 것입니다.

host:localhost처럼 쓰면 오류가 납니다. 반드시 host: localhost처럼 공백을 넣어야 합니다.

또 다른 실수는 리스트와 키-값을 혼동하는 것입니다. 하이픈으로 시작하면 리스트, 콜론이 있으면 키-값입니다.

하이픈 뒤에 콜론이 오면 리스트 요소가 키-값 쌍인 것입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

"정말 세 가지밖에 없네요!" 김개발 씨는 복잡해 보이던 설정 파일을 다시 보았습니다. 이제는 구조가 눈에 들어왔습니다.

키-값 쌍이 모여 객체를 이루고, 하이픈이 리스트를 만들고, 들여쓰기가 계층을 나타내고 있었습니다. 이 세 가지 기본 요소만 확실히 이해하면 어떤 YAML 파일이든 분석하고 작성할 수 있습니다.

복잡해 보이는 Kubernetes 매니페스트도 결국은 이 세 가지의 조합일 뿐입니다.

실전 팁

💡 - 키-값에서 콜론 뒤에는 반드시 공백이 필요합니다.

리스트 항목의 하이픈 뒤에도 공백이 필요합니다.
복잡한 YAML을 읽을 때는 들여쓰기 레벨별로 구분해서 보면 구조가 명확해집니다.

3. 들여쓰기 규칙

김개발 씨가 작성한 YAML 파일이 자꾸 오류를 뱉었습니다. 문법은 맞는 것 같은데 파서가 계속 에러를 던집니다.

한참을 들여다보던 박시니어 씨가 "여기 스페이스가 세 칸인데?"라고 물었습니다. YAML에서 들여쓰기는 생각보다 까다로운 규칙을 가지고 있었습니다.

YAML에서 들여쓰기는 문법의 핵심입니다. 반드시 스페이스만 사용해야 하며, 탭은 허용되지 않습니다.

같은 레벨의 요소는 반드시 같은 수의 스페이스로 들여써야 합니다. 일반적으로 2칸 스페이스를 표준으로 사용하지만, 일관성만 유지된다면 다른 숫자도 가능합니다.

다음 코드를 살펴봅시다.

# 올바른 들여쓰기 (2칸 스페이스 사용)
server:
  host: localhost
  port: 3000
  ssl:
    enabled: true
    certificate: /path/to/cert

# 잘못된 들여쓰기 (혼합 사용 - 오류 발생)
server:
  host: localhost    # 2칸 스페이스
   port: 3000        # 3칸 스페이스 - 오류!
	ssl:              # 탭 사용 - 오류!
    enabled: true

김개발 씨는 좌절감에 빠졌습니다. 분명히 문법대로 작성했는데 왜 오류가 날까요?

박시니어 씨는 에디터의 "공백 문자 표시" 기능을 켜주었습니다. 그러자 숨어 있던 탭 문자들이 드러났습니다.

"아, 탭을 섞어 썼구나." YAML에서 들여쓰기는 단순한 가독성의 문제가 아닙니다. 들여쓰기 자체가 문법입니다.

JSON에서 중괄호가 하는 역할을 YAML에서는 들여쓰기가 합니다. 따라서 들여쓰기가 잘못되면 완전히 다른 의미가 되거나 오류가 발생합니다.

첫 번째 규칙은 탭 금지입니다. YAML 명세에서 탭 문자는 들여쓰기에 사용할 수 없다고 명시되어 있습니다.

많은 개발자가 다른 언어에서 탭을 사용하다가 YAML에서 실수합니다. 에디터 설정에서 YAML 파일의 탭을 스페이스로 자동 변환하도록 설정하는 것이 좋습니다.

두 번째 규칙은 일관성입니다. 한 파일 내에서는 같은 수의 스페이스를 사용해야 합니다.

2칸이든 4칸이든 상관없지만, 섞어 쓰면 안 됩니다. 업계 표준은 2칸 스페이스입니다.

Kubernetes, Docker Compose, GitHub Actions 모두 2칸을 사용합니다. 세 번째 규칙은 같은 레벨, 같은 들여쓰기입니다.

형제 요소들은 반드시 같은 칸에서 시작해야 합니다. 위의 예제에서 host, port, ssl은 모두 server의 자식이므로 같은 레벨입니다.

따라서 모두 2칸으로 들여써야 합니다. 마치 책의 목차를 생각해 보세요.

1장, 2장, 3장은 같은 레벨이므로 같은 위치에 있습니다. 1-1절, 1-2절은 1장의 하위이므로 더 안쪽에 있습니다.

YAML의 들여쓰기도 이와 같습니다. 실무에서 대규모 YAML 파일을 다룰 때 들여쓰기 실수는 찾기가 어렵습니다.

수백 줄짜리 파일에서 스페이스 하나가 잘못된 곳을 찾으려면 시간이 많이 걸립니다. 그래서 YAML 린터를 사용하는 것이 좋습니다.

yamllint 같은 도구는 들여쓰기 오류를 자동으로 잡아줍니다. 에디터 설정도 중요합니다.

VS Code를 사용한다면 YAML 파일에 대해 "Tab Size"를 2로, "Insert Spaces"를 true로 설정하세요. 이렇게 하면 탭 키를 눌러도 자동으로 스페이스 2칸이 입력됩니다.

주의할 점이 하나 더 있습니다. 복사 붙여넣기를 할 때입니다.

다른 곳에서 YAML 코드를 복사해오면 들여쓰기가 깨지는 경우가 많습니다. 붙여넣은 후에는 반드시 들여쓰기를 확인하세요.

김개발 씨는 에디터 설정을 바꾸고 다시 파일을 작성했습니다. 이번에는 오류 없이 파싱되었습니다.

"스페이스 하나 때문에 이렇게 고생할 줄은 몰랐네요." 박시니어 씨가 웃으며 대답했습니다. "YAML은 깐깐해.

하지만 그 덕분에 일관된 스타일을 유지할 수 있지." 들여쓰기 규칙은 처음에는 까다롭게 느껴질 수 있지만, 익숙해지면 오히려 코드를 깔끔하게 유지하는 데 도움이 됩니다. 에디터 설정과 린터만 잘 활용하면 실수를 미리 방지할 수 있습니다.

실전 팁

💡 - 에디터에서 YAML 파일의 탭을 스페이스로 자동 변환하도록 설정하세요.

yamllint 같은 도구를 사용하면 들여쓰기 오류를 자동으로 검출할 수 있습니다.
복사 붙여넣기 후에는 반드시 들여쓰기를 확인하는 습관을 들이세요.

4. 멀티라인 문자열 처리

김개발 씨가 Kubernetes ConfigMap에 여러 줄의 설정 파일을 넣으려고 합니다. 한 줄짜리 값은 쉬운데, 긴 문장이나 여러 줄의 텍스트는 어떻게 처리해야 할까요?

YAML은 이를 위한 두 가지 특별한 문법을 제공합니다.

YAML에서 여러 줄의 문자열을 처리하는 방법은 두 가지입니다. **파이프(|)**는 줄바꿈을 그대로 보존하고, **꺾쇠(>)**는 줄바꿈을 공백으로 변환합니다.

이 두 가지를 상황에 맞게 사용하면 긴 문장이나 코드 블록을 깔끔하게 YAML에 포함시킬 수 있습니다.

다음 코드를 살펴봅시다.

# 파이프(|): 줄바꿈 보존 - 코드, 스크립트에 적합
script: |
  #!/bin/bash
  echo "Hello World"
  npm install
  npm run build

# 꺾쇠(>): 줄바꿈을 공백으로 - 긴 문장에 적합
description: >
  이것은 매우 긴 설명입니다.
  여러 줄로 작성했지만
  실제로는 한 줄로 합쳐집니다.

# 마지막 줄바꿈 제어
keep_newline: |
  마지막에 줄바꿈 있음

strip_newline: |-
  마지막에 줄바꿈 없음

김개발 씨는 CI/CD 파이프라인을 설정하던 중 난관에 부딪혔습니다. 셸 스크립트를 YAML 파일에 넣어야 하는데, 여러 줄의 명령어를 어떻게 작성해야 할지 막막했습니다.

한 줄에 모두 쓰자니 가독성이 떨어지고, 그냥 줄바꿈을 하자니 YAML 문법이 깨졌습니다. 박시니어 씨가 해답을 알려주었습니다.

"YAML에는 리터럴 블록과 폴디드 블록이라는 두 가지 특별한 문법이 있어." 첫 번째는 파이프(|) 문법입니다. 이것을 리터럴 블록이라고 부릅니다.

마치 "있는 그대로 넣어줘"라고 말하는 것과 같습니다. 파이프 다음에 오는 모든 줄은 줄바꿈을 포함해서 그대로 보존됩니다.

셸 스크립트나 프로그램 코드처럼 줄바꿈이 의미를 가지는 경우에 사용합니다. 두 번째는 꺾쇠(>) 문법입니다.

이것을 폴디드 블록이라고 부릅니다. "접어서 한 줄로 만들어줘"라는 의미입니다.

여러 줄로 작성하더라도 실제로는 줄바꿈이 공백으로 변환되어 한 줄이 됩니다. 긴 설명문이나 메시지처럼 가독성을 위해 줄을 나누지만 실제로는 이어지는 텍스트에 적합합니다.

비유하자면, 파이프는 시를 쓰는 것과 같습니다. 시에서 줄바꿈은 의미가 있습니다.

반면 꺾쇠는 편지를 쓰는 것과 같습니다. 편지지의 줄이 끝나서 다음 줄로 넘어갔을 뿐, 문장은 계속 이어집니다.

위의 코드 예제를 자세히 보겠습니다. script 부분은 파이프를 사용했습니다.

셸 스크립트에서 각 줄은 별개의 명령어이므로 줄바꿈이 반드시 보존되어야 합니다. echo 다음에 npm install이 같은 줄에 오면 오류가 납니다.

description 부분은 꺾쇠를 사용했습니다. 세 줄로 작성했지만 실제 값은 "이것은 매우 긴 설명입니다.

여러 줄로 작성했지만 실제로는 한 줄로 합쳐집니다."가 됩니다. 코드에서 가독성은 유지하면서 데이터로는 한 줄을 원할 때 유용합니다.

추가로 마지막 줄바꿈을 제어하는 방법도 있습니다. 기본적으로 블록 스타일은 마지막에 줄바꿈 하나를 추가합니다.

이것을 원하지 않으면 **하이픈(-)**을 붙입니다. |-(리터럴 스트립), >-(폴디드 스트립)처럼 사용합니다.

실무에서 Kubernetes ConfigMap을 작성할 때 이 문법이 자주 사용됩니다. 설정 파일 전체를 ConfigMap에 넣어야 할 때, 파이프 문법으로 여러 줄의 텍스트를 그대로 저장할 수 있습니다.

GitHub Actions에서 run 스크립트를 작성할 때도 마찬가지입니다. 주의할 점은 들여쓰기입니다.

블록 내용은 파이프나 꺾쇠가 있는 줄보다 더 들여써야 합니다. 첫 번째 줄의 들여쓰기가 기준이 되어 그만큼이 제거됩니다.

따라서 모든 줄을 일관되게 들여쓰면 됩니다. 김개발 씨는 파이프 문법을 사용해서 빌드 스크립트를 깔끔하게 작성했습니다.

"이렇게 편한 방법이 있었군요!" 박시니어 씨가 덧붙였습니다. "DevOps 엔지니어라면 이 문법은 매일 쓰게 될 거야." 멀티라인 문자열은 YAML의 강력한 기능 중 하나입니다.

상황에 맞게 파이프와 꺾쇠를 선택하면 복잡한 텍스트도 우아하게 처리할 수 있습니다.

실전 팁

💡 - 코드나 스크립트는 파이프(|), 긴 문장은 꺾쇠(>)를 사용하세요.

마지막 줄바꿈이 불필요하면 |- 또는 >- 를 사용하세요.
블록 내용의 들여쓰기는 최소 한 레벨 이상 들여써야 합니다.

5. 앵커와 별칭 활용

김개발 씨가 마이크로서비스 설정 파일을 작성하는데, 여러 서비스에서 동일한 데이터베이스 설정이 반복되고 있었습니다. 복사 붙여넣기를 하자니 나중에 수정할 때 모든 곳을 바꿔야 하고, DRY 원칙에도 어긋납니다.

이런 상황을 해결할 방법이 있을까요?

YAML의 **앵커(&)**와 **별칭(*)**은 데이터를 재사용할 수 있게 해주는 강력한 기능입니다. 앵커로 특정 값에 이름을 붙이고, 별칭으로 그 값을 참조하면 중복 없이 같은 데이터를 여러 곳에서 사용할 수 있습니다.

또한 **병합 키(<<)**를 사용하면 기존 값에 새로운 값을 추가하거나 덮어쓸 수 있습니다.

다음 코드를 살펴봅시다.

# 앵커 정의: &로 이름 붙이기
defaults: &default_settings
  timeout: 30
  retries: 3
  log_level: info

# 별칭 사용: *로 참조하기
production:
  <<: *default_settings
  log_level: warn    # 기본값 덮어쓰기

development:
  <<: *default_settings
  timeout: 60        # 개발 환경은 타임아웃 늘리기

# 결과: production은 timeout=30, retries=3, log_level=warn
# 결과: development는 timeout=60, retries=3, log_level=info

김개발 씨는 세 개의 마이크로서비스 설정을 작성하고 있었습니다. 문제는 데이터베이스 연결 설정이 세 곳 모두 동일하다는 것이었습니다.

호스트, 포트, 타임아웃, 풀 사이즈까지 모두 같았습니다. 복사해서 붙여넣으면 간단하지만, 나중에 포트가 바뀌면 세 곳을 모두 수정해야 합니다.

박시니어 씨가 말했습니다. "YAML에는 앵커와 별칭이라는 기능이 있어.

프로그래밍에서 변수를 사용하는 것과 비슷하지." 앵커는 **앰퍼샌드(&)**로 표시합니다. 특정 값에 이름을 붙이는 것입니다.

마치 책갈피를 꽂아두는 것과 같습니다. 나중에 그 페이지로 돌아가고 싶을 때 책갈피를 찾으면 됩니다.

별칭은 **별표(*)**로 표시합니다. 앞서 정의한 앵커를 참조합니다.

책갈피를 꽂아둔 페이지를 다시 펴는 것과 같습니다. 별칭을 사용하면 앵커에서 정의한 모든 값을 그대로 가져옵니다.

더 강력한 기능은 **병합 키(<<)**입니다. 단순히 값을 참조하는 것을 넘어서, 기존 값을 가져온 후 일부를 수정하거나 새로운 값을 추가할 수 있습니다.

객체 지향 프로그래밍에서 상속을 떠올리면 됩니다. 부모 클래스의 속성을 물려받되, 필요한 것만 재정의하는 것처럼요.

위의 코드 예제를 분석해 보겠습니다. defaults에 &default_settings라는 앵커를 붙였습니다.

이 앵커는 timeout, retries, log_level 세 가지 값을 가지고 있습니다. production 섹션에서는 <<: *default_settings로 기본 설정을 모두 가져옵니다.

그런 다음 log_level을 warn으로 재정의합니다. 결과적으로 production은 timeout=30, retries=3, log_level=warn을 가지게 됩니다.

development 섹션도 마찬가지로 기본 설정을 가져오지만, timeout만 60으로 변경합니다. log_level은 재정의하지 않았으므로 기본값인 info가 그대로 유지됩니다.

실무에서 이 기능은 정말 유용합니다. Docker Compose 파일에서 여러 서비스가 비슷한 설정을 공유할 때, 공통 부분을 앵커로 정의하고 각 서비스에서 참조할 수 있습니다.

Kubernetes에서도 여러 컨테이너가 동일한 리소스 제한을 가질 때 활용됩니다. 주의할 점이 있습니다.

앵커와 별칭은 같은 파일 내에서만 작동합니다. 다른 파일의 앵커를 참조할 수는 없습니다.

또한 별칭은 앵커가 먼저 정의된 후에만 사용할 수 있습니다. 순서가 중요합니다.

또 하나 알아둘 점은, 모든 YAML 파서가 앵커와 별칭을 지원하지만, 일부 도구에서는 **병합 키(<<)**를 지원하지 않을 수 있습니다. 대부분의 주요 도구들은 지원하지만, 사용 전에 확인하는 것이 좋습니다.

김개발 씨는 앵커와 별칭을 사용해서 설정 파일을 정리했습니다. 300줄이던 파일이 100줄로 줄었습니다.

무엇보다 나중에 공통 설정을 변경할 때 한 곳만 수정하면 되니 유지보수가 훨씬 쉬워졌습니다. 앵커와 별칭은 YAML을 더욱 강력하게 만드는 기능입니다.

DRY 원칙을 지키면서도 가독성을 해치지 않는 우아한 방법입니다. 복잡한 설정 파일을 다룬다면 꼭 활용해 보세요.

실전 팁

💡 - 공통 설정은 파일 상단에 앵커로 정의하고, 아래에서 별칭으로 참조하세요.

병합 키(<<)를 사용하면 상속처럼 기본값을 가져와서 일부만 수정할 수 있습니다.
앵커 이름은 의미 있게 지어야 나중에 이해하기 쉽습니다.

6. K8s 매니페스트 파일 구조

김개발 씨가 드디어 첫 Kubernetes 배포를 앞두고 있습니다. 지금까지 배운 YAML 문법을 실제로 적용해 볼 시간입니다.

Kubernetes 매니페스트 파일은 어떤 구조로 이루어져 있을까요? 한 번도 본 적 없는 필드들이 가득하지만, 기본 구조만 알면 어떤 매니페스트든 이해할 수 있습니다.

Kubernetes 매니페스트 파일은 네 가지 핵심 필드로 구성됩니다. apiVersion은 사용할 API 버전을, kind는 리소스 종류를, metadata는 이름과 라벨 같은 메타 정보를, spec은 원하는 상태를 정의합니다.

이 네 가지 필드는 거의 모든 Kubernetes 리소스에 공통으로 존재합니다.

다음 코드를 살펴봅시다.

apiVersion: apps/v1           # API 버전
kind: Deployment              # 리소스 종류
metadata:                     # 메타 정보
  name: my-app
  labels:
    app: my-app
    version: "1.0"
spec:                         # 원하는 상태 정의
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: nginx:1.21
          ports:
            - containerPort: 80

김개발 씨는 처음으로 Kubernetes 매니페스트 파일을 열어보았습니다. 수십 줄의 YAML이 눈앞에 펼쳐졌습니다.

막막했지만, 박시니어 씨의 말이 떠올랐습니다. "Kubernetes 리소스는 모두 같은 뼈대를 가지고 있어.

그 뼈대만 알면 나머지는 세부사항일 뿐이야." Kubernetes 매니페스트의 뼈대는 네 가지 핵심 필드입니다. 마치 사람의 주민등록증처럼, 모든 리소스는 이 네 가지 정보를 반드시 가지고 있습니다.

첫 번째는 apiVersion입니다. 이것은 "어떤 버전의 Kubernetes API를 사용할 것인가"를 선언합니다.

Kubernetes는 계속 발전하므로 API도 버전이 있습니다. apps/v1, v1, networking.k8s.io/v1 등 리소스 종류에 따라 다른 API 버전을 사용합니다.

두 번째는 kind입니다. 이것은 "무엇을 만들 것인가"를 지정합니다.

Deployment, Service, ConfigMap, Pod 등 Kubernetes가 지원하는 다양한 리소스 종류 중 하나를 선택합니다. 마치 서류 양식에서 "이 서류는 신청서입니다" 또는 "이 서류는 보고서입니다"라고 표시하는 것과 같습니다.

세 번째는 metadata입니다. 리소스의 신분증이라고 생각하면 됩니다.

name은 필수이며, 클러스터 내에서 이 리소스를 식별하는 고유한 이름입니다. labels는 선택사항이지만 매우 유용합니다.

라벨을 사용하면 리소스들을 그룹으로 묶거나 선택할 수 있습니다. 네 번째는 spec입니다.

이것이 핵심입니다. "이 리소스가 어떤 상태이기를 원하는가"를 상세하게 기술합니다.

Deployment라면 몇 개의 복제본을 원하는지, 어떤 컨테이너를 실행할지, 어떤 포트를 열지 등을 정의합니다. spec의 내용은 kind에 따라 완전히 달라집니다.

위의 코드 예제는 Deployment 매니페스트입니다. 천천히 분석해 보겠습니다.

apiVersion: apps/v1은 Deployment가 apps 그룹의 v1 API를 사용함을 나타냅니다. kind: Deployment는 이것이 배포 리소스임을 선언합니다.

metadata에서는 my-app이라는 이름과 두 개의 라벨을 정의했습니다. spec 부분이 가장 복잡합니다.

replicas: 3은 이 앱의 복제본을 3개 실행하겠다는 의미입니다. selector는 이 Deployment가 관리할 Pod를 어떻게 찾을지 정의합니다.

app: my-app 라벨을 가진 Pod를 찾습니다. template 부분은 실제로 생성될 Pod의 청사진입니다.

여기에도 metadata와 spec이 중첩되어 있습니다. Pod의 metadata에서 라벨을 정의하고, Pod의 spec에서 컨테이너 설정을 정의합니다.

containers는 리스트입니다. 하나의 Pod에 여러 컨테이너가 들어갈 수 있기 때문입니다.

각 컨테이너는 name, image, ports 등의 설정을 가집니다. 실무에서 Kubernetes 매니페스트를 작성할 때는 보통 공식 문서를 참조합니다.

모든 필드를 외울 필요는 없습니다. 네 가지 핵심 필드 구조만 이해하면, 나머지는 필요할 때 찾아보면 됩니다.

처음에는 복잡해 보이지만, 패턴을 알면 금방 익숙해집니다. Deployment는 Pod 템플릿을 가지고 있고, Service는 selector와 ports를 가지고 있고, ConfigMap은 data를 가지고 있습니다.

각 리소스마다 spec의 형태가 다를 뿐, 전체 구조는 동일합니다. 김개발 씨는 첫 매니페스트를 성공적으로 작성했습니다.

kubectl apply -f 명령어로 배포하니 세 개의 Pod가 떠올랐습니다. "YAML 문법을 제대로 배워두길 잘했어요!" 박시니어 씨가 고개를 끄덕였습니다.

"이제 어떤 Kubernetes 리소스든 두렵지 않을 거야." Kubernetes 매니페스트는 결국 YAML입니다. 지금까지 배운 키-값, 리스트, 중첩, 들여쓰기 규칙이 모두 적용됩니다.

기본기를 탄탄히 다져두면 어떤 복잡한 매니페스트도 읽고 작성할 수 있습니다.

실전 팁

💡 - 모든 Kubernetes 리소스는 apiVersion, kind, metadata, spec 네 가지 필드를 가집니다.

kubectl explain 명령어로 각 필드의 의미를 터미널에서 바로 확인할 수 있습니다.
처음 작성할 때는 공식 문서의 예제를 복사해서 수정하는 방식이 효율적입니다.

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#YAML#DevOps#Kubernetes#ConfigurationManagement#Infrastructure#YAML,DevOps

YAML 문법 마스터 완벽 가이드

# YAML 문법 마스터 완벽 가이드 DevOps와 클라우드 환경에서 필수적으로 사용되는 YAML 문법을 기초부터 실무 활용까지 체계적으로 다룹니다. Kubernetes 매니페스트 작성에 필요한 핵심 문법을 쉬운 비유와 실전 예제로 설명합니다. --- ## 목차 1. [YAML_vs_JSON_비교](#yaml-vs-json-비교) 2. [기본_문법_키값_리스트_중첩](#기본-문법-키값-리스트-중첩) 3. [들여쓰기_규칙](#들여쓰기-규칙) 4. [멀티라인_문자열_처리](#멀티라인-문자열-처리) 5. [앵커와_별칭_활용](#앵커와-별칭-활용) 6. [K8s_매니페스트_파일_구조](#k8s-매니페스트-파일-구조) --- ## 1. YAML_vs_JSON_비교 어느 날 김개발 씨가 새로운 프로젝트에 투입되었습니다. 설정 파일을 보니 어떤 것은 JSON으로, 어떤 것은 YAML로 작성되어 있었습니다. "둘 다 비슷해 보이는데, 왜 굳이 다른 형식을 쓰는 걸까요?" 궁금증이 생긴 김개발 씨는 선배에게 질문했습니다. **YAML**은 "YAML Ain't Markup Language"의 약자로, 사람이 읽기 쉬운 데이터 직렬화 형식입니다. JSON과 동일한 데이터를 표현할 수 있지만, 중괄호와 따옴표 대신 들여쓰기를 사용하여 훨씬 깔끔하게 작성할 수 있습니다. 특히 설정 파일처럼 사람이 자주 읽고 수정해야 하는 경우에 YAML이 더 적합합니다. 다음 코드를 살펴봅시다. ```typescript # JSON 형식 { "server": { "host": "localhost", "port": 3000, "enabled": true } } # YAML 형식 (동일한 데이터) server: host: localhost port: 3000 enabled: true ``` 김개발 씨는 입사한 지 얼마 되지 않은 주니어 개발자입니다. 오늘 처음으로 Kubernetes 프로젝트에 투입되었는데, 설정 파일들을 보니 머리가 어지러웠습니다. 어떤 파일은 중괄호로 가득하고, 어떤 파일은 깔끔하게 정리되어 있었습니다. 선배 개발자 박시니어 씨가 다가와 설명해 주었습니다. "JSON과 YAML은 형제 같은 존재야. 같은 내용을 담을 수 있지만, 옷을 다르게 입고 있는 거지." **YAML**을 이해하려면 먼저 **JSON**을 떠올려 보면 됩니다. JSON은 자바스크립트에서 태어난 데이터 형식으로, 중괄호와 대괄호, 따옴표로 구조를 표현합니다. 프로그램이 읽기에는 완벽하지만, 사람이 직접 작성하기에는 조금 번거롭습니다. 반면 **YAML**은 마치 깔끔하게 정리된 메모장 같습니다. 서랍장을 생각해 보세요. JSON은 모든 서랍에 라벨을 붙이고 잠금장치까지 달아놓은 느낌이라면, YAML은 한눈에 보이도록 열어둔 서랍장과 같습니다. 어떤 칸에 무엇이 있는지 바로 알 수 있습니다. 왜 DevOps 세계에서는 YAML을 선호할까요? 설정 파일은 개발자가 수시로 읽고 수정해야 합니다. Docker Compose, Kubernetes, GitHub Actions, Ansible 등 거의 모든 현대적인 도구들이 YAML을 채택한 이유가 바로 여기에 있습니다. 위의 코드 예제를 살펴보면 차이가 명확하게 드러납니다. JSON에서는 중괄호, 쉼표, 따옴표가 필수입니다. 하나라도 빠지면 오류가 납니다. 하지만 YAML에서는 **들여쓰기**만으로 계층 구조를 표현합니다. 따옴표도 대부분의 경우 생략할 수 있습니다. 실무에서 GitHub Actions 워크플로우를 작성한다고 가정해 봅시다. 수십 줄의 설정을 JSON으로 작성하면 중괄호 짝 맞추기에만 시간을 허비하게 됩니다. YAML로 작성하면 마치 목록을 정리하듯 직관적으로 작성할 수 있습니다. 하지만 주의할 점도 있습니다. YAML은 들여쓰기에 민감합니다. 스페이스 하나가 잘못되면 전혀 다른 의미가 될 수 있습니다. JSON은 들여쓰기가 문법과 무관하지만, YAML에서는 들여쓰기 자체가 문법입니다. 또한 JSON은 모든 프로그래밍 언어에서 기본적으로 지원하지만, YAML은 별도의 파서가 필요한 경우가 많습니다. API 응답에는 JSON이, 설정 파일에는 YAML이 적합한 이유입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 Kubernetes 설정은 YAML이고, REST API 응답은 JSON인 거군요!" 두 형식의 특성을 이해하면 상황에 맞는 적절한 선택을 할 수 있습니다. 사람이 자주 수정하는 설정 파일에는 YAML을, 프로그램 간 데이터 교환에는 JSON을 사용하는 것이 일반적인 관례입니다. **실전 팁** 💡 - YAML은 JSON의 상위 집합입니다. 모든 JSON은 유효한 YAML이지만, 그 반대는 아닙니다. - 설정 파일 작성 시에는 YAML을, API 통신에는 JSON을 사용하는 것이 업계 표준입니다. --- ## 2. 기본_문법_키값_리스트_중첩 김개발 씨가 첫 번째 Kubernetes 설정 파일을 작성하려고 합니다. 빈 파일을 열어놓고 막막해하던 그때, 박시니어 씨가 "YAML의 세 가지 기본 요소만 알면 어떤 설정 파일이든 읽을 수 있어"라고 말했습니다. 그 세 가지란 무엇일까요? YAML의 기본 구성 요소는 **키-값 쌍**, **리스트**, 그리고 **중첩 구조** 세 가지입니다. 키-값은 사전처럼 이름과 값을 연결하고, 리스트는 순서가 있는 항목들의 모음이며, 중첩은 이들을 조합하여 복잡한 구조를 만듭니다. 이 세 가지만 이해하면 어떤 YAML 파일이든 읽고 쓸 수 있습니다. 다음 코드를 살펴봅시다. ```typescript # 키-값 쌍: 콜론으로 구분 name: my-application version: 1.0.0 # 리스트: 하이픈으로 시작 dependencies: - express - lodash - axios # 중첩 구조: 들여쓰기로 계층 표현 database: primary: host: db.example.com port: 5432 replicas: - host: replica1.example.com - host: replica2.example.com ``` 김개발 씨는 YAML 파일 앞에서 한숨을 쉬었습니다. 복잡해 보이는 설정 파일이 수백 줄에 달했기 때문입니다. 하지만 박시니어 씨는 웃으며 말했습니다. "걱정 마. 아무리 복잡한 YAML도 세 가지 기본 요소의 조합일 뿐이야." 첫 번째 요소는 **키-값 쌍**입니다. 마치 사전에서 단어와 뜻을 찾는 것과 같습니다. "name"이라는 단어를 찾으면 "my-application"이라는 뜻이 나오는 식입니다. YAML에서는 키와 값 사이에 콜론과 공백을 넣습니다. 이때 **콜론 뒤에 반드시 공백이 있어야** 한다는 점을 기억하세요. 두 번째 요소는 **리스트**입니다. 장보기 목록을 생각해 보세요. 우유, 빵, 계란처럼 여러 항목을 나열할 때 앞에 점을 찍거나 번호를 붙이듯이, YAML에서는 **하이픈과 공백**으로 시작합니다. 각 항목이 순서대로 나열되어 있다는 것을 한눈에 알 수 있습니다. 세 번째 요소는 **중첩 구조**입니다. 이것은 서류 캐비닛을 떠올리면 됩니다. 큰 서랍 안에 작은 폴더가 있고, 그 폴더 안에 문서가 있는 것처럼, YAML에서도 **들여쓰기를 통해 계층**을 표현합니다. 들여쓰기가 깊어질수록 더 안쪽에 있는 데이터입니다. 위의 코드 예제를 천천히 살펴보겠습니다. 맨 위의 name과 version은 단순한 키-값 쌍입니다. 파일의 최상위 레벨에 있어서 들여쓰기가 없습니다. dependencies 부분을 보면 키-값과 리스트가 결합되어 있습니다. dependencies라는 키 아래에 세 개의 항목이 하이픈으로 나열되어 있습니다. 하이픈으로 시작하는 각 줄이 리스트의 한 요소입니다. database 부분은 가장 복잡한 중첩 구조입니다. database 안에 primary와 replicas가 있고, primary 안에는 다시 host와 port가 있습니다. replicas는 리스트인데, 각 요소가 또다시 키-값 쌍을 가지고 있습니다. 이처럼 세 가지 요소를 자유롭게 조합할 수 있습니다. 실무에서 Docker Compose 파일을 작성한다고 생각해 봅시다. services라는 키 아래에 여러 서비스를 정의하고, 각 서비스는 image, ports, environment 같은 키-값 쌍을 가집니다. ports는 리스트 형태로 여러 포트를 매핑할 수 있습니다. 모든 것이 세 가지 기본 요소의 조합입니다. 초보자가 흔히 하는 실수 중 하나는 **콜론 뒤에 공백을 빼먹는 것**입니다. host:localhost처럼 쓰면 오류가 납니다. 반드시 host: localhost처럼 공백을 넣어야 합니다. 또 다른 실수는 **리스트와 키-값을 혼동**하는 것입니다. 하이픈으로 시작하면 리스트, 콜론이 있으면 키-값입니다. 하이픈 뒤에 콜론이 오면 리스트 요소가 키-값 쌍인 것입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. "정말 세 가지밖에 없네요!" 김개발 씨는 복잡해 보이던 설정 파일을 다시 보았습니다. 이제는 구조가 눈에 들어왔습니다. 키-값 쌍이 모여 객체를 이루고, 하이픈이 리스트를 만들고, 들여쓰기가 계층을 나타내고 있었습니다. 이 세 가지 기본 요소만 확실히 이해하면 어떤 YAML 파일이든 분석하고 작성할 수 있습니다. 복잡해 보이는 Kubernetes 매니페스트도 결국은 이 세 가지의 조합일 뿐입니다. **실전 팁** 💡 - 키-값에서 콜론 뒤에는 반드시 공백이 필요합니다. - 리스트 항목의 하이픈 뒤에도 공백이 필요합니다. - 복잡한 YAML을 읽을 때는 들여쓰기 레벨별로 구분해서 보면 구조가 명확해집니다. --- ## 3. 들여쓰기_규칙 김개발 씨가 작성한 YAML 파일이 자꾸 오류를 뱉었습니다. 문법은 맞는 것 같은데 파서가 계속 에러를 던집니다. 한참을 들여다보던 박시니어 씨가 "여기 스페이스가 세 칸인데?"라고 물었습니다. YAML에서 들여쓰기는 생각보다 까다로운 규칙을 가지고 있었습니다. YAML에서 **들여쓰기는 문법의 핵심**입니다. 반드시 **스페이스만 사용**해야 하며, 탭은 허용되지 않습니다. 같은 레벨의 요소는 반드시 같은 수의 스페이스로 들여써야 합니다. 일반적으로 2칸 스페이스를 표준으로 사용하지만, 일관성만 유지된다면 다른 숫자도 가능합니다. 다음 코드를 살펴봅시다. ```typescript # 올바른 들여쓰기 (2칸 스페이스 사용) server: host: localhost port: 3000 ssl: enabled: true certificate: /path/to/cert # 잘못된 들여쓰기 (혼합 사용 - 오류 발생) server: host: localhost # 2칸 스페이스 port: 3000 # 3칸 스페이스 - 오류! ssl: # 탭 사용 - 오류! enabled: true ``` 김개발 씨는 좌절감에 빠졌습니다. 분명히 문법대로 작성했는데 왜 오류가 날까요? 박시니어 씨는 에디터의 "공백 문자 표시" 기능을 켜주었습니다. 그러자 숨어 있던 탭 문자들이 드러났습니다. "아, 탭을 섞어 썼구나." YAML에서 들여쓰기는 단순한 가독성의 문제가 아닙니다. **들여쓰기 자체가 문법**입니다. JSON에서 중괄호가 하는 역할을 YAML에서는 들여쓰기가 합니다. 따라서 들여쓰기가 잘못되면 완전히 다른 의미가 되거나 오류가 발생합니다. 첫 번째 규칙은 **탭 금지**입니다. YAML 명세에서 탭 문자는 들여쓰기에 사용할 수 없다고 명시되어 있습니다. 많은 개발자가 다른 언어에서 탭을 사용하다가 YAML에서 실수합니다. 에디터 설정에서 YAML 파일의 탭을 스페이스로 자동 변환하도록 설정하는 것이 좋습니다. 두 번째 규칙은 **일관성**입니다. 한 파일 내에서는 같은 수의 스페이스를 사용해야 합니다. 2칸이든 4칸이든 상관없지만, 섞어 쓰면 안 됩니다. 업계 표준은 **2칸 스페이스**입니다. Kubernetes, Docker Compose, GitHub Actions 모두 2칸을 사용합니다. 세 번째 규칙은 **같은 레벨, 같은 들여쓰기**입니다. 형제 요소들은 반드시 같은 칸에서 시작해야 합니다. 위의 예제에서 host, port, ssl은 모두 server의 자식이므로 같은 레벨입니다. 따라서 모두 2칸으로 들여써야 합니다. 마치 책의 목차를 생각해 보세요. 1장, 2장, 3장은 같은 레벨이므로 같은 위치에 있습니다. 1-1절, 1-2절은 1장의 하위이므로 더 안쪽에 있습니다. YAML의 들여쓰기도 이와 같습니다. 실무에서 대규모 YAML 파일을 다룰 때 들여쓰기 실수는 찾기가 어렵습니다. 수백 줄짜리 파일에서 스페이스 하나가 잘못된 곳을 찾으려면 시간이 많이 걸립니다. 그래서 **YAML 린터**를 사용하는 것이 좋습니다. yamllint 같은 도구는 들여쓰기 오류를 자동으로 잡아줍니다. 에디터 설정도 중요합니다. VS Code를 사용한다면 YAML 파일에 대해 "Tab Size"를 2로, "Insert Spaces"를 true로 설정하세요. 이렇게 하면 탭 키를 눌러도 자동으로 스페이스 2칸이 입력됩니다. 주의할 점이 하나 더 있습니다. 복사 붙여넣기를 할 때입니다. 다른 곳에서 YAML 코드를 복사해오면 들여쓰기가 깨지는 경우가 많습니다. 붙여넣은 후에는 반드시 들여쓰기를 확인하세요. 김개발 씨는 에디터 설정을 바꾸고 다시 파일을 작성했습니다. 이번에는 오류 없이 파싱되었습니다. "스페이스 하나 때문에 이렇게 고생할 줄은 몰랐네요." 박시니어 씨가 웃으며 대답했습니다. "YAML은 깐깐해. 하지만 그 덕분에 일관된 스타일을 유지할 수 있지." 들여쓰기 규칙은 처음에는 까다롭게 느껴질 수 있지만, 익숙해지면 오히려 코드를 깔끔하게 유지하는 데 도움이 됩니다. 에디터 설정과 린터만 잘 활용하면 실수를 미리 방지할 수 있습니다. **실전 팁** 💡 - 에디터에서 YAML 파일의 탭을 스페이스로 자동 변환하도록 설정하세요. - yamllint 같은 도구를 사용하면 들여쓰기 오류를 자동으로 검출할 수 있습니다. - 복사 붙여넣기 후에는 반드시 들여쓰기를 확인하는 습관을 들이세요. --- ## 4. 멀티라인_문자열_처리 김개발 씨가 Kubernetes ConfigMap에 여러 줄의 설정 파일을 넣으려고 합니다. 한 줄짜리 값은 쉬운데, 긴 문장이나 여러 줄의 텍스트는 어떻게 처리해야 할까요? YAML은 이를 위한 두 가지 특별한 문법을 제공합니다. YAML에서 여러 줄의 문자열을 처리하는 방법은 두 가지입니다. **파이프(|)**는 줄바꿈을 그대로 보존하고, **꺾쇠(>)**는 줄바꿈을 공백으로 변환합니다. 이 두 가지를 상황에 맞게 사용하면 긴 문장이나 코드 블록을 깔끔하게 YAML에 포함시킬 수 있습니다. 다음 코드를 살펴봅시다. ```typescript # 파이프(|): 줄바꿈 보존 - 코드, 스크립트에 적합 script: | #!/bin/bash echo "Hello World" npm install npm run build # 꺾쇠(>): 줄바꿈을 공백으로 - 긴 문장에 적합 description: > 이것은 매우 긴 설명입니다. 여러 줄로 작성했지만 실제로는 한 줄로 합쳐집니다. # 마지막 줄바꿈 제어 keep_newline: | 마지막에 줄바꿈 있음 strip_newline: |- 마지막에 줄바꿈 없음 ``` 김개발 씨는 CI/CD 파이프라인을 설정하던 중 난관에 부딪혔습니다. 셸 스크립트를 YAML 파일에 넣어야 하는데, 여러 줄의 명령어를 어떻게 작성해야 할지 막막했습니다. 한 줄에 모두 쓰자니 가독성이 떨어지고, 그냥 줄바꿈을 하자니 YAML 문법이 깨졌습니다. 박시니어 씨가 해답을 알려주었습니다. "YAML에는 **리터럴 블록**과 **폴디드 블록**이라는 두 가지 특별한 문법이 있어." 첫 번째는 **파이프(|) 문법**입니다. 이것을 **리터럴 블록**이라고 부릅니다. 마치 "있는 그대로 넣어줘"라고 말하는 것과 같습니다. 파이프 다음에 오는 모든 줄은 줄바꿈을 포함해서 그대로 보존됩니다. 셸 스크립트나 프로그램 코드처럼 줄바꿈이 의미를 가지는 경우에 사용합니다. 두 번째는 **꺾쇠(>) 문법**입니다. 이것을 **폴디드 블록**이라고 부릅니다. "접어서 한 줄로 만들어줘"라는 의미입니다. 여러 줄로 작성하더라도 실제로는 줄바꿈이 공백으로 변환되어 한 줄이 됩니다. 긴 설명문이나 메시지처럼 가독성을 위해 줄을 나누지만 실제로는 이어지는 텍스트에 적합합니다. 비유하자면, 파이프는 시를 쓰는 것과 같습니다. 시에서 줄바꿈은 의미가 있습니다. 반면 꺾쇠는 편지를 쓰는 것과 같습니다. 편지지의 줄이 끝나서 다음 줄로 넘어갔을 뿐, 문장은 계속 이어집니다. 위의 코드 예제를 자세히 보겠습니다. script 부분은 파이프를 사용했습니다. 셸 스크립트에서 각 줄은 별개의 명령어이므로 줄바꿈이 반드시 보존되어야 합니다. echo 다음에 npm install이 같은 줄에 오면 오류가 납니다. description 부분은 꺾쇠를 사용했습니다. 세 줄로 작성했지만 실제 값은 "이것은 매우 긴 설명입니다. 여러 줄로 작성했지만 실제로는 한 줄로 합쳐집니다."가 됩니다. 코드에서 가독성은 유지하면서 데이터로는 한 줄을 원할 때 유용합니다. 추가로 **마지막 줄바꿈을 제어**하는 방법도 있습니다. 기본적으로 블록 스타일은 마지막에 줄바꿈 하나를 추가합니다. 이것을 원하지 않으면 **하이픈(-)**을 붙입니다. |-(리터럴 스트립), >-(폴디드 스트립)처럼 사용합니다. 실무에서 Kubernetes ConfigMap을 작성할 때 이 문법이 자주 사용됩니다. 설정 파일 전체를 ConfigMap에 넣어야 할 때, 파이프 문법으로 여러 줄의 텍스트를 그대로 저장할 수 있습니다. GitHub Actions에서 run 스크립트를 작성할 때도 마찬가지입니다. 주의할 점은 **들여쓰기**입니다. 블록 내용은 파이프나 꺾쇠가 있는 줄보다 더 들여써야 합니다. 첫 번째 줄의 들여쓰기가 기준이 되어 그만큼이 제거됩니다. 따라서 모든 줄을 일관되게 들여쓰면 됩니다. 김개발 씨는 파이프 문법을 사용해서 빌드 스크립트를 깔끔하게 작성했습니다. "이렇게 편한 방법이 있었군요!" 박시니어 씨가 덧붙였습니다. "DevOps 엔지니어라면 이 문법은 매일 쓰게 될 거야." 멀티라인 문자열은 YAML의 강력한 기능 중 하나입니다. 상황에 맞게 파이프와 꺾쇠를 선택하면 복잡한 텍스트도 우아하게 처리할 수 있습니다. **실전 팁** 💡 - 코드나 스크립트는 파이프(|), 긴 문장은 꺾쇠(>)를 사용하세요. - 마지막 줄바꿈이 불필요하면 |- 또는 >- 를 사용하세요. - 블록 내용의 들여쓰기는 최소 한 레벨 이상 들여써야 합니다. --- ## 5. 앵커와_별칭_활용 김개발 씨가 마이크로서비스 설정 파일을 작성하는데, 여러 서비스에서 동일한 데이터베이스 설정이 반복되고 있었습니다. 복사 붙여넣기를 하자니 나중에 수정할 때 모든 곳을 바꿔야 하고, DRY 원칙에도 어긋납니다. 이런 상황을 해결할 방법이 있을까요? YAML의 **앵커(&)**와 **별칭(*)**은 데이터를 재사용할 수 있게 해주는 강력한 기능입니다. 앵커로 특정 값에 이름을 붙이고, 별칭으로 그 값을 참조하면 중복 없이 같은 데이터를 여러 곳에서 사용할 수 있습니다. 또한 **병합 키(<<)**를 사용하면 기존 값에 새로운 값을 추가하거나 덮어쓸 수 있습니다. 다음 코드를 살펴봅시다. ```typescript # 앵커 정의: &로 이름 붙이기 defaults: &default_settings timeout: 30 retries: 3 log_level: info # 별칭 사용: *로 참조하기 production: <<: *default_settings log_level: warn # 기본값 덮어쓰기 development: <<: *default_settings timeout: 60 # 개발 환경은 타임아웃 늘리기 # 결과: production은 timeout=30, retries=3, log_level=warn # 결과: development는 timeout=60, retries=3, log_level=info ``` 김개발 씨는 세 개의 마이크로서비스 설정을 작성하고 있었습니다. 문제는 데이터베이스 연결 설정이 세 곳 모두 동일하다는 것이었습니다. 호스트, 포트, 타임아웃, 풀 사이즈까지 모두 같았습니다. 복사해서 붙여넣으면 간단하지만, 나중에 포트가 바뀌면 세 곳을 모두 수정해야 합니다. 박시니어 씨가 말했습니다. "YAML에는 **앵커와 별칭**이라는 기능이 있어. 프로그래밍에서 변수를 사용하는 것과 비슷하지." **앵커**는 **앰퍼샌드(&)**로 표시합니다. 특정 값에 이름을 붙이는 것입니다. 마치 책갈피를 꽂아두는 것과 같습니다. 나중에 그 페이지로 돌아가고 싶을 때 책갈피를 찾으면 됩니다. **별칭**은 **별표(*)**로 표시합니다. 앞서 정의한 앵커를 참조합니다. 책갈피를 꽂아둔 페이지를 다시 펴는 것과 같습니다. 별칭을 사용하면 앵커에서 정의한 모든 값을 그대로 가져옵니다. 더 강력한 기능은 **병합 키(<<)**입니다. 단순히 값을 참조하는 것을 넘어서, 기존 값을 가져온 후 일부를 수정하거나 새로운 값을 추가할 수 있습니다. 객체 지향 프로그래밍에서 상속을 떠올리면 됩니다. 부모 클래스의 속성을 물려받되, 필요한 것만 재정의하는 것처럼요. 위의 코드 예제를 분석해 보겠습니다. defaults에 &default_settings라는 앵커를 붙였습니다. 이 앵커는 timeout, retries, log_level 세 가지 값을 가지고 있습니다. production 섹션에서는 <<: *default_settings로 기본 설정을 모두 가져옵니다. 그런 다음 log_level을 warn으로 재정의합니다. 결과적으로 production은 timeout=30, retries=3, log_level=warn을 가지게 됩니다. development 섹션도 마찬가지로 기본 설정을 가져오지만, timeout만 60으로 변경합니다. log_level은 재정의하지 않았으므로 기본값인 info가 그대로 유지됩니다. 실무에서 이 기능은 정말 유용합니다. Docker Compose 파일에서 여러 서비스가 비슷한 설정을 공유할 때, 공통 부분을 앵커로 정의하고 각 서비스에서 참조할 수 있습니다. Kubernetes에서도 여러 컨테이너가 동일한 리소스 제한을 가질 때 활용됩니다. 주의할 점이 있습니다. 앵커와 별칭은 **같은 파일 내에서만** 작동합니다. 다른 파일의 앵커를 참조할 수는 없습니다. 또한 별칭은 앵커가 **먼저 정의된 후에만** 사용할 수 있습니다. 순서가 중요합니다. 또 하나 알아둘 점은, 모든 YAML 파서가 앵커와 별칭을 지원하지만, 일부 도구에서는 **병합 키(<<)**를 지원하지 않을 수 있습니다. 대부분의 주요 도구들은 지원하지만, 사용 전에 확인하는 것이 좋습니다. 김개발 씨는 앵커와 별칭을 사용해서 설정 파일을 정리했습니다. 300줄이던 파일이 100줄로 줄었습니다. 무엇보다 나중에 공통 설정을 변경할 때 한 곳만 수정하면 되니 유지보수가 훨씬 쉬워졌습니다. 앵커와 별칭은 YAML을 더욱 강력하게 만드는 기능입니다. DRY 원칙을 지키면서도 가독성을 해치지 않는 우아한 방법입니다. 복잡한 설정 파일을 다룬다면 꼭 활용해 보세요. **실전 팁** 💡 - 공통 설정은 파일 상단에 앵커로 정의하고, 아래에서 별칭으로 참조하세요. - 병합 키(<<)를 사용하면 상속처럼 기본값을 가져와서 일부만 수정할 수 있습니다. - 앵커 이름은 의미 있게 지어야 나중에 이해하기 쉽습니다. --- ## 6. K8s_매니페스트_파일_구조 김개발 씨가 드디어 첫 Kubernetes 배포를 앞두고 있습니다. 지금까지 배운 YAML 문법을 실제로 적용해 볼 시간입니다. Kubernetes 매니페스트 파일은 어떤 구조로 이루어져 있을까요? 한 번도 본 적 없는 필드들이 가득하지만, 기본 구조만 알면 어떤 매니페스트든 이해할 수 있습니다. Kubernetes 매니페스트 파일은 네 가지 핵심 필드로 구성됩니다. **apiVersion**은 사용할 API 버전을, **kind**는 리소스 종류를, **metadata**는 이름과 라벨 같은 메타 정보를, **spec**은 원하는 상태를 정의합니다. 이 네 가지 필드는 거의 모든 Kubernetes 리소스에 공통으로 존재합니다. 다음 코드를 살펴봅시다. ```typescript apiVersion: apps/v1 # API 버전 kind: Deployment # 리소스 종류 metadata: # 메타 정보 name: my-app labels: app: my-app version: "1.0" spec: # 원하는 상태 정의 replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-container image: nginx:1.21 ports: - containerPort: 80 ``` 김개발 씨는 처음으로 Kubernetes 매니페스트 파일을 열어보았습니다. 수십 줄의 YAML이 눈앞에 펼쳐졌습니다. 막막했지만, 박시니어 씨의 말이 떠올랐습니다. "Kubernetes 리소스는 모두 같은 뼈대를 가지고 있어. 그 뼈대만 알면 나머지는 세부사항일 뿐이야." Kubernetes 매니페스트의 뼈대는 **네 가지 핵심 필드**입니다. 마치 사람의 주민등록증처럼, 모든 리소스는 이 네 가지 정보를 반드시 가지고 있습니다. 첫 번째는 **apiVersion**입니다. 이것은 "어떤 버전의 Kubernetes API를 사용할 것인가"를 선언합니다. Kubernetes는 계속 발전하므로 API도 버전이 있습니다. apps/v1, v1, networking.k8s.io/v1 등 리소스 종류에 따라 다른 API 버전을 사용합니다. 두 번째는 **kind**입니다. 이것은 "무엇을 만들 것인가"를 지정합니다. Deployment, Service, ConfigMap, Pod 등 Kubernetes가 지원하는 다양한 리소스 종류 중 하나를 선택합니다. 마치 서류 양식에서 "이 서류는 신청서입니다" 또는 "이 서류는 보고서입니다"라고 표시하는 것과 같습니다. 세 번째는 **metadata**입니다. 리소스의 신분증이라고 생각하면 됩니다. name은 필수이며, 클러스터 내에서 이 리소스를 식별하는 고유한 이름입니다. labels는 선택사항이지만 매우 유용합니다. 라벨을 사용하면 리소스들을 그룹으로 묶거나 선택할 수 있습니다. 네 번째는 **spec**입니다. 이것이 핵심입니다. "이 리소스가 어떤 상태이기를 원하는가"를 상세하게 기술합니다. Deployment라면 몇 개의 복제본을 원하는지, 어떤 컨테이너를 실행할지, 어떤 포트를 열지 등을 정의합니다. spec의 내용은 kind에 따라 완전히 달라집니다. 위의 코드 예제는 Deployment 매니페스트입니다. 천천히 분석해 보겠습니다. apiVersion: apps/v1은 Deployment가 apps 그룹의 v1 API를 사용함을 나타냅니다. kind: Deployment는 이것이 배포 리소스임을 선언합니다. metadata에서는 my-app이라는 이름과 두 개의 라벨을 정의했습니다. spec 부분이 가장 복잡합니다. replicas: 3은 이 앱의 복제본을 3개 실행하겠다는 의미입니다. selector는 이 Deployment가 관리할 Pod를 어떻게 찾을지 정의합니다. app: my-app 라벨을 가진 Pod를 찾습니다. template 부분은 실제로 생성될 Pod의 청사진입니다. 여기에도 metadata와 spec이 중첩되어 있습니다. Pod의 metadata에서 라벨을 정의하고, Pod의 spec에서 컨테이너 설정을 정의합니다. containers는 리스트입니다. 하나의 Pod에 여러 컨테이너가 들어갈 수 있기 때문입니다. 각 컨테이너는 name, image, ports 등의 설정을 가집니다. 실무에서 Kubernetes 매니페스트를 작성할 때는 보통 **공식 문서**를 참조합니다. 모든 필드를 외울 필요는 없습니다. 네 가지 핵심 필드 구조만 이해하면, 나머지는 필요할 때 찾아보면 됩니다. 처음에는 복잡해 보이지만, 패턴을 알면 금방 익숙해집니다. Deployment는 Pod 템플릿을 가지고 있고, Service는 selector와 ports를 가지고 있고, ConfigMap은 data를 가지고 있습니다. 각 리소스마다 spec의 형태가 다를 뿐, 전체 구조는 동일합니다. 김개발 씨는 첫 매니페스트를 성공적으로 작성했습니다. kubectl apply -f 명령어로 배포하니 세 개의 Pod가 떠올랐습니다. "YAML 문법을 제대로 배워두길 잘했어요!" 박시니어 씨가 고개를 끄덕였습니다. "이제 어떤 Kubernetes 리소스든 두렵지 않을 거야." Kubernetes 매니페스트는 결국 YAML입니다. 지금까지 배운 키-값, 리스트, 중첩, 들여쓰기 규칙이 모두 적용됩니다. 기본기를 탄탄히 다져두면 어떤 복잡한 매니페스트도 읽고 작성할 수 있습니다. **실전 팁** 💡 - 모든 Kubernetes 리소스는 apiVersion, kind, metadata, spec 네 가지 필드를 가집니다. - kubectl explain 명령어로 각 필드의 의미를 터미널에서 바로 확인할 수 있습니다. - 처음 작성할 때는 공식 문서의 예제를 복사해서 수정하는 방식이 효율적입니다. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: YAML,DevOps

언어: TypeScript

태그: YAML, DevOps, Kubernetes, ConfigurationManagement, Infrastructure, YAML,DevOps

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

YAML 문법 마스터 완벽 가이드

목차

1. YAML vs JSON 비교

2. 기본 문법 키값 리스트 중첩

3. 들여쓰기 규칙

4. 멀티라인 문자열 처리

5. 앵커와 별칭 활용

6. K8s 매니페스트 파일 구조

이 카드뉴스가 포함된 코스

Kubernetes 완전 정복

댓글 (0)

함께 보면 좋은 카드 뉴스

Istio 보안 완벽 가이드

Istio 트래픽 관리 완벽 가이드

Istio 설치와 구성 완벽 가이드

서비스 메시 완벽 가이드

Helm 마이크로서비스 패키징 완벽 가이드