DevOps 엔지니어가 Kubernetes 설정을 YAML로 내보냈지만 JSON만 받는 API에 보내야 합니다. 분석가가 JSON 형식의 API 응답 데이터를 받았지만 스프레드시트가 필요합니다. 데이터 과학자가 데이터베이스에서 CSV를 내보냈지만 웹 대시보드를 위한 구조화된 JSON이 필요합니다.
형식 변환은 단순한 기계적 작업이 아닙니다. 각 형식은 서로 다른 트레이드오프를 가지며, 변환 시 무엇이 손실되는지 이해하는 것은 변환 방법을 아는 것만큼 중요합니다.
세 가지 형식, 세 가지 철학
각 형식은 서로 다른 대상과 문제를 위해 설계되었습니다:
| 형식 | 탄생 | 설계 목적 | 핵심 철학 |
|---|---|---|---|
| CSV | ~1972 | 프로그램 간 데이터 교환 | 최대한의 단순함 — 행과 열뿐 |
| JSON | 2001 | 웹 데이터 교환 | 엄격한 규칙의 기계 판독 가능한 구조화 데이터 |
| YAML | 2001 | 설정 파일 | 최소 문법의 인간 판독 가능한 구조화 데이터 |
CSV는 데이터가 플랫 테이블이라고 가정합니다. 모든 값은 문자열입니다. 중첩, 타입 지정, 메타데이터 개념이 없습니다.
JSON은 데이터에 구조가 있다고 가정합니다 — 객체, 배열, 타입(문자열, 숫자, 불리언, null). 엄격하고 모호하지 않아 기계에는 이상적이지만 인간에게는 장황합니다.
YAML은 사람이 파일을 읽고 편집할 것이라고 가정합니다. 중괄호 대신 들여쓰기를 사용하고, 주석을 지원하며, 더 느슨한 구문을 가집니다. 기술적으로 YAML은 JSON의 상위 집합입니다 — 유효한 모든 JSON 문서는 유효한 YAML이기도 합니다.
YAML은 JSON의 상위 집합입니다 JSON 문서를 YAML 파서에 직접 붙여넣으면 작동합니다. 반대는 성립하지 않습니다 — 주석, 앵커, 여러 줄 문자열 같은 YAML 기능에는 JSON 대응물이 없습니다.
실제 변환 시나리오
설정 마이그레이션 (JSON에서 YAML로, YAML에서 JSON으로)
가장 흔한 변환입니다. 다른 도구는 다른 설정 형식을 기대합니다:
- Docker Compose, Kubernetes, GitHub Actions, Ansible은 YAML 사용
- package.json, tsconfig.json, ESLint는 JSON 사용
- 도구 간 마이그레이션에는 종종 설정 변환이 필요
이 변환은 데이터 내용에 대해 양방향으로 무손실입니다 — 단 JSON에 주석 구문이 없으므로 JSON으로 변환 시 YAML 주석은 손실됩니다.
데이터 분석 (JSON에서 CSV로)
API 응답은 JSON으로 옵니다. 분석가에게는 스프레드시트가 필요합니다. 이 변환은 플랫 JSON 배열에 잘 작동합니다 — 동일한 키를 가진 객체 배열은 자연스럽게 행과 열에 매핑됩니다.
하지만 중첩 데이터에서는 문제가 생깁니다. address.city 필드와 skills 배열이 있는 JSON 객체는 자연스러운 CSV 표현이 없습니다. 변환기는 선택해야 합니다: 중첩 키를 평탄화하거나(address.city가 열이 됨), 중첩 값을 문자열로 직렬화하거나, 버리거나.
데이터 임포트 (CSV에서 JSON으로)
반대 시나리오: 스프레드시트 데이터를 웹 애플리케이션이나 API로 임포트. CSV에서 JSON으로의 변환은 열 헤더를 키로 하는 객체 배열을 생성합니다. 문제는 CSV에 타입 정보가 없다는 것입니다 — 숫자 42, 문자열 "42", 불리언 true는 CSV에서 모두 텍스트일 뿐입니다. 변환기가 타입을 추측해야 합니다.
가독성 향상 (JSON에서 YAML로)
밀집된 JSON 설정 파일을 읽기 쉽게 만들어야 할 때가 있습니다. YAML로 변환하면 깔끔한 들여쓰기와 문서화를 위한 주석 추가가 가능합니다. 이는 팀이 유지보수할 대규모 설정 파일에 특히 유용합니다.
변환에서 무엇이 손실되는가
디버깅 시간을 절약하는 핵심 지식입니다:
| 변환 | 손실되는 것 |
|---|---|
| YAML에서 JSON으로 | 주석 (JSON에 주석 구문 없음) |
| JSON에서 CSV로 | 중첩 (CSV는 플랫), 타입 (모두 텍스트가 됨), 배열 |
| CSV에서 JSON으로 | 없음 (단 타입 추론 필요 — "42" vs 42) |
| CSV에서 YAML로 | 없음 (같은 타입 추론 문제) |
| JSON에서 YAML로 | 없음 (YAML은 JSON의 상위 집합) |
| YAML에서 CSV로 | 주석, 중첩, 타입, 앵커/별칭 |
패턴은 명확합니다: CSV 방향으로의 변환이 가장 많은 정보를 잃습니다. CSV가 가장 단순한 형식이기 때문입니다. JSON과 YAML 사이의 변환은 거의 무손실입니다. 그리고 YAML 주석은 YAML을 벗어날 때 항상 손실됩니다.
양방향과 단방향 JSON-YAML과 YAML-JSON 변환은 사실상 양방향입니다(주석 제외 왕복 안전). JSON-CSV와 YAML-CSV 변환은 복잡한 데이터에 대해 단방향입니다 — 플랫 CSV에서 중첩을 재구성할 수 없습니다.
변환 시 흔한 함정
YAML의 타입 강제 함정
YAML은 특정 문자열을 자동으로 비문자열 타입으로 해석합니다. no는 불리언 false가 됩니다. yes는 true가 됩니다. 문자열 1.0은 부동소수점이 됩니다. NO(노르웨이) 같은 국가 코드가 유명한 버그를 일으킨 바 있습니다. YAML에서는 모호한 값을 항상 따옴표로 감싸세요.
CSV 구분자와 인코딩 혼란
모든 CSV가 쉼표를 사용하지는 않습니다. 유럽 CSV는 세미콜론을 자주 사용합니다(많은 유럽 숫자 형식에서 쉼표가 소수점 구분자이기 때문). 탭 구분 값(TSV)도 또 다른 변형입니다. 그리고 문자 인코딩 불일치(UTF-8과 Latin-1)는 악센트 문자를 깨뜨립니다.
JSON의 후행 쉼표 문제
JSON은 후행 쉼표를 허용하지 않습니다. 이것은 유효한 JavaScript입니다: {"a": 1, "b": 2,} — 하지만 유효하지 않은 JSON입니다. 하나의 후행 쉼표가 파싱 오류를 일으킵니다.
대규모 데이터셋 성능
수백만 행의 데이터셋에서 CSV는 JSON이나 YAML보다 훨씬 효율적입니다. JSON은 모든 값에 중괄호, 대괄호, 따옴표를 추가합니다. 100만 행의 CSV가 50MB일 수 있는 반면, 동등한 JSON은 150MB가 될 수 있습니다.
처음부터 올바른 형식 선택하기
사후에 변환하는 대신 처음부터 올바른 형식을 선택하면 정보 손실을 피할 수 있습니다:
- 스프레드시트나 데이터베이스용 테이블 데이터 — CSV
- API나 웹 앱용 구조화 데이터 — JSON
- 사람이 편집할 설정 — YAML
- 주석이 있는 복잡한 중첩 데이터 — YAML
- 시스템 간 데이터 교환 — JSON
더 알아보기
브라우저 기반 도구로 JSON, YAML, CSV 사이를 즉시 변환하세요:
- 데이터 형식 변환 — 데이터를 붙여넣고 대상 형식을 선택하고 결과를 다운로드
- JSON 포매터 — JSON 검증, 정렬, 최소화
- JSON-CSV 변환기 — JSON 배열을 스프레드시트용 CSV로 변환
- YAML-JSON 변환기 — 주석을 고려한 YAML과 JSON 간 변환