두 YAML 문서를 붙여넣고 정확한 좌우 diff를 확인하세요. Kubernetes 매니페스트, GitHub Actions 워크플로, Helm values, docker-compose 파일에 맞춰 만들었습니다.
두 YAML 문서를 비교하기 위한 무료 브라우저 내 도구입니다. 왼쪽에 이전 버전, 오른쪽에 새 버전을 붙여넣으면 차이가 문자 단위로 강조됩니다. 텍스트는 브라우저를 떠나지 않습니다. 시크릿 참조나 내부 호스트 이름을 포함한 매니페스트를 diff할 때 이 점이 중요합니다.
diff는 문자 수준에서 동작하며, 텍스트 diff 도구와 동일한 엔진을 사용합니다. 에디터의 YAML 모드는 YAML 1.2.2 specification에 따라 구문 강조를 처리하므로 block scalars, anchors, flow collections가 모두 올바르게 색칠됩니다.
Helm values.yaml의 pull request에서 chart를 망가뜨린 들여쓰기 한 칸을 찾아 400줄 diff를 노려본 적이 있다면, 이 도구가 그것을 몇 초 안에 찾아냅니다. Slack과 에디터 간의 복사 붙여넣기로 스페이스가 탭으로 변환되는 경우에도 유용합니다. YAML은 탭을 받아들이지 않습니다.
diff는 문자 수준에서 실행되고, 그 다음 의미적 정리 단계가 강조 표시를 흩어진 단일 문자가 아니라 의미 있는 덩어리로 묶습니다. 추가는 오른쪽 패널에 초록색, 삭제는 왼쪽에 빨간색으로 나타나며, 각 헤더의 라인 카운트는 diff가 찾은 별개의 편집 수를 알려줍니다.
YAML에는 너그러운 형식으로 취급하는 사람들을 무는 파싱 규칙이 있습니다. 들여쓰기는 YAML 1.2.2 spec에 따라 구조적이므로, 잘못 놓인 공백 하나가 문서 트리를 바꿉니다. 탭은 들여쓰기로 금지되어 있고, 파서는 그것을 단호히 거부합니다. implicit typing은 YAML 1.1에서 따옴표 없는 토큰 NO를 불리언 false로 변환합니다. 이것이 유명한 Norway problem입니다: 국가 코드 목록에서 노르웨이가 조용히 사라집니다. YAML 1.2는 규칙을 좁혀 true, false, null과 숫자 형태만 따옴표 없이 변환되지만, 여전히 많은 도구가 1.1로 파싱합니다.
다운스트림 컨슈머용으로 YAML을 이미 JSON으로 변환했다면, JSON diff 도구가 키 순서와 정규화 같은 구조적 문제를 처리합니다. JSON은 YAML 1.2의 엄격한 부분집합이므로 모든 유효한 JSON 문서는 유효한 YAML이기도 합니다. 이 호환성은 spec에 문서화되어 있고, js-yaml과 libyaml이 둘 다 놀라움 없이 JSON을 round-trip할 수 있는 이유입니다.
텍스트 패널 두 개, diff 하나. 가입 없음, 업로드 없음, 서버 왕복 없음.
이전 YAML을 왼쪽에, 새 YAML을 오른쪽에 붙여넣으세요. 또는 어느 한쪽의 업로드를 클릭해 .yaml 또는 .yml 파일을 직접 불러올 수 있습니다. 샘플 버튼은 양쪽 패널에 작은 Kubernetes Deployment를 채워서 도구가 어떻게 동작하는지 먼저 보여줍니다.
YAML은 들여쓰기에 스페이스만 사용하고 탭은 절대 사용하지 않습니다. 스페이스를 탭으로 변환한 채팅 클라이언트나 터미널에서 붙여넣으면 파서는 파일을 거부합니다. 에디터는 탭과 행 끝 공백을 강조하므로, 배포 실패의 원인이 되기 전에 발견할 수 있습니다.
삭제는 왼쪽에 빨간색, 추가는 오른쪽에 초록색으로 표시됩니다. 두 패널은 함께 스크롤되므로 긴 매니페스트도 위치를 잃지 않고 따라갈 수 있습니다. 각 헤더의 변경 카운트는 diff가 찾은 별개의 편집 수를 요약합니다.
두 클러스터에서 kubectl get deployment web -o yaml을 실행하고 출력을 diff합니다. 스프린트 말의 롤아웃이 도달하지 않아 prod에 여전히 replicas: 2와 오래된 이미지 태그가 남아 있는 경우가 흔하며, 텍스트 diff가 kubectl apply를 다시 실행하기 전에 이를 확인하는 가장 빠른 방법입니다. Kubernetes 객체 모델은 처음부터 끝까지 YAML이므로 이것은 일상적인 케이스입니다.
브랜치 이름 변경 후 워크플로가 트리거되지 않거나 잡이 갑자기 8분 더 걸리면, .github/workflows/ci.yml을 직전의 그린 커밋과 diff하세요. 범인은 보통 변경된 on: 필터, actions/setup-node에서 제거된 cache: 키, 또는 매트릭스 항목이 조용히 node-version: "18"(string)에서 node-version: 18(number)로 바뀌어 타입 체커를 건드린 경우입니다.
docker-compose.yml을 main의 버전과 diff해서 실제로 변경한 environment: 항목이 무엇인지 확인합니다. 사람들은 새 환경 변수 목록을 붙여넣고, 그 중 하나가 다른 서비스에 이미 설정되어 있었다는 것을 잊어버리기 쉽습니다. 그러면 오버라이드가 다른 곳의 플래그를 조용히 뒤집습니다. diff가 그것을 분명하게 만듭니다.
chart를 1.8.0에서 2.0.0으로 업그레이드할 때, values.yaml을 메인테이너가 발표한 새 기본값과 diff합니다. Helm은 값을 키별로 병합하므로, 이름이 바뀐 최상위 키(image.tag가 image.repository 아래로 이동)는 조용히 chart 기본값으로 떨어집니다. helm upgrade가 회귀를 롤아웃하기 전에 diff가 이름 변경을 드러냅니다.
코드 생성기가 paths를 알파벳순으로 재정렬하면, 3,000줄짜리 openapi.yaml diff는 읽을 수 없게 됩니다. 버전을 나란히 비교하면 실제 변경이 떠오릅니다: 요청 스키마에 추가된 required 필드, 또는 타입이 조용히 string에서 integer로 바뀐 응답입니다. 빌드가 깨진 이유를 찾기 위해 생성된 SDK를 파헤치는 것보다 쉽습니다.
플레이북이 dev에서 동작하고 prod에서 실패할 때, 둘 사이의 inventory나 role defaults/main.yml을 diff하세요. 흔한 원인은 복사되지 않은 hostvar, 또는 dev에서는 role에, prod에서는 단일 task에 설정된 become: yes입니다. diff가 그것을 몇 초 안에 찾아냅니다.
이 도구가 가장 자주 표면화하는 파싱 엣지 케이스에 대한 짧은 치트시트. 모두 YAML 사양과 실제 파서 동작에 기반합니다.
| Topic | What this tool does |
|---|---|
| 들여쓰기 | 스페이스만, 그리고 그 수는 구조적입니다. 두 칸과 네 칸 모두 흔합니다. 파일별로 하나를 선택하고 그것을 유지하세요. 역사를 알고 싶다면 Wikipedia의 YAML 개요에 좋은 요약이 있습니다. |
| 탭 | spec에 따라 들여쓰기로 금지됨. 스칼라 값 내부에서는 허용. 에디터가 Enter 시 탭을 삽입한다면, .yaml과 .yml 파일에서는 스페이스를 사용하도록 설정하세요. |
| anchors와 aliases | &name은 anchor를 정의하고, *name은 그것을 참조합니다. container env vars나 기본 service config 같은 큰 블록을 복사 붙여넣기 없이 반복하는 데 유용합니다. |
| merge keys | <<: *base는 참조된 매핑을 현재 매핑에 병합합니다. YAML 1.1 기능입니다. libyaml을 포함한 대부분의 파서가 여전히 받아들입니다. YAML 1.2 spec은 그것을 폐기했습니다. |
| 멀티 도큐먼트 파일 | 대시 세 개(---)가 단일 스트림 내의 도큐먼트를 구분합니다. 여러 Kubernetes 객체를 하나의 kubectl apply -f로 보내는 데 유용합니다. ...는 도큐먼트를 끝냅니다. |
| block scalars | |는 개행을 보존하고(literal), >는 그것을 공백으로 접습니다. 수정자 -와 +는 끝의 개행을 제어합니다. 셸 스크립트에는 |, 긴 사람용 산문에는 >를 사용하세요. |
| Norway problem | 따옴표 없는 NO, YES, ON, OFF는 YAML 1.1에서 불리언이 됩니다. 따옴표로 묶거나 1.2 파서를 사용하세요. 어떤 문자열이 변환되는지는 YAML 타입 정의를 참조하세요. |
| 인코딩 | UTF-8은 YAML 1.2 spec에서 요구합니다. UTF-16은 BOM과 함께 허용됩니다. 실제 도구는 BOM 없는 UTF-8을 기대하므로, 놀라움을 피하려면 그렇게 저장하세요. |
YAML은 공백에 민감하므로 일반 텍스트 diff도 이미 유용합니다: 모든 들여쓰기 변경은 구조적 변경이고 diff가 그것을 잡습니다. 차이는 표현 방식에 있습니다. YAML 모드는 anchors, tags, block scalars, flow collections를 구문 색상으로 강조하므로, 변경이 키, 문자열 값, 또는 리스트 항목 중 어디에 대한 것인지 한눈에 알 수 있습니다. 기반의 diff 알고리즘은 텍스트 diff 도구와 동일합니다.
들여쓰기만이 어떤 키가 어떤 매핑에 속하는지 파서에 알려주기 때문입니다. YAML 1.2.2 spec은 노드의 들여쓰기 수준을 선행 공백 수로 정의하고, 들여쓰기로 탭을 금지합니다. 추가 공백 하나가 키를 하위 매핑으로 승격시킵니다. 그 엄격함은 중괄호나 쉼표가 필요 없는 형식의 대가이며, JSON보다 YAML에서 들여쓰기 버그를 더 자주 보는 이유입니다.
YAML 1.1 implicit typing은 따옴표 없는 토큰 NO를 불리언 false로 변환합니다. 그래서 노르웨이를 나타내는 NO를 포함한 국가 코드 리스트는 한 항목이 false로 대체된 리스트가 조용히 됩니다. YES, ON, OFF 등에도 같은 일이 적용됩니다. StrictYAML이 자세히 문서화하고 있습니다. 해결책은 값을 따옴표로 묶거나("NO") YAML 1.2를 따르는 파서를 사용하는 것입니다. 1.2는 true, false, null만 암묵적으로 변환합니다.
anchor (&name)는 노드를 표시해서 나중에 alias (*name)로 참조할 수 있게 하여, 긴 파일에서 반복을 피합니다. merge key (<<: *name)는 YAML 1.1 확장으로, 참조된 매핑의 모든 키를 현재 매핑에 복사합니다. 서비스 간 공통 설정을 공유하는 데 유용합니다. merge key는 YAML 1.2의 일부가 아니지만, js-yaml을 포함한 대부분의 파서가 호환성을 위해 여전히 지원합니다. diff는 anchors와 aliases를 평문으로 취급하므로, 이름이 바뀐 anchor가 깔끔하게 보입니다.
네. JSON은 YAML 1.2의 엄격한 부분집합이므로, 유효한 JSON 문서는 유효한 YAML 문서이기도 합니다. 정말 원한다면 둘을 섞을 수도 있고, 블록 스타일 파일에 JSON 스타일 flow collection을 떨어뜨릴 수도 있습니다. 순수한 JSON 작업에는 JSON diff 도구에 JSON 인식 형식 및 검증 버튼이 있고, pretty-print와 sort-keys도 포함되어 있습니다.
YAML spec이 들여쓰기로 탭을 금지하기 때문입니다. 1.2.2 spec에서: "To maintain portability, tab characters must not be used in indentation." 탭은 스칼라 값 안에서는 허용됩니다(문자열은 탭을 포함할 수 있습니다), 단지 들여쓰기가 측정되는 줄 시작 부분에서만 금지됩니다. 해결책은 파일이 이미 사용하는 관습에 따라 탭을 두 칸 또는 네 칸 공백으로 빠르게 찾아 바꾸는 것입니다.
당신의 YAML은 브라우저를 떠나지 않습니다. 에디터, 구문 강조 도구, diff 모두 당신의 기기에서 로컬로 실행됩니다. 입력에 대한 분석, 로그, 클라우드 왕복 없음. 우리가 따르는 형식은 YAML 1.2.2 specification입니다. 아무것도 업로드되지 않는다는 것을 확인하려면, 비교하는 동안 DevTools를 열고 Network 탭을 보세요.