아티클
CSV, XML, JSON, YAML 형식 간 변환: 실용 가이드
CSV, JSON, XML, YAML은 데이터 파이프라인, 설정 파일, API에서 개발자가 가장 자주 접하는 네 가지 형식입니다. 데이터 모델이 일치할 때는 변환이 간단하지만, 그렇지 않을 때는 예상외로 많은 정보가 손실됩니다. 이 가이드는 각 형식이 무엇을 표현할 수 있고 없는지, 변환 중 정보가 어디서 사라지는지, 그리고 무결함 데이터 손상을 유발하는 인코딩 함정을 다룹니다. 이 사이트의 data-converter 도구는 네 형식 중 세 가지(CSV, JSON, YAML)를 완전히 브라우저 내에서 처리합니다. 여기서 다루는 XML 관련 내용은 직접 손으로 옮기거나 별도 도구를 쓸 때를 위한 배경 지식입니다.
네 가지 형식과 데이터 모델
CSV는 데이터를 행과 열의 평면 격자로 구성합니다. 첫 번째 행은 일반적으로 열 이름을 지정하고, 이후 각 행은 하나의 레코드입니다. 중첩 구조가 없고 타입 정보도 없으며, 셀의 일반 텍스트 외에는 표준이 없습니다. 소비 애플리케이션이 타입을 강제하지 않는 한 모든 값은 문자열입니다. JSON은 데이터를 객체(키-값 맵)와 배열의 트리로 모델링합니다. 값은 문자열, 숫자, 불리언, null, 중첩 객체, 또는 임의 깊이의 배열이 될 수 있습니다. 이를 통해 단일 JSON 문서로 주소 객체가 포함된 고객 레코드, 품목 배열, 타입이 지정된 숫자 합계를 표현할 수 있습니다. XML은 데이터를 요소의 트리로 모델링합니다. 각 요소는 명명된 속성을 가질 수 있고 자식 요소나 텍스트 콘텐츠를 포함할 수 있습니다. 숫자나 불리언 타입이 내장되어 있지 않으며 모든 것이 텍스트입니다. XSD 같은 스키마가 유효성 검사 시 타입을 강제할 수 있지만 와이어 형식은 항상 문자 데이터입니다. YAML은 들여쓰기를 사용하여 JSON과 동일한 객체-배열 모델을 표현하되 더 깔끔하고 읽기 쉬운 구문을 사용합니다. YAML은 JSON의 상위 집합입니다. 유효한 JSON 문서는 유효한 YAML이기도 합니다. 여기에 여러 줄 문자열, 주석, 반복 블록을 위한 앵커-앨리어스 참조가 추가됩니다. YAML은 설정 파일에서 흔히 사용되고, JSON은 API 응답에서 흔히 사용됩니다.
손실 변환: 평탄화와 XML 모호성
가장 일반적인 손실 변환은 중첩된 JSON이나 XML을 CSV로 평탄화하는 것입니다. 중첩된 주소 필드가 있는 JSON 객체는 CSV 행에 깔끔하게 매핑될 수 없습니다. 일반적인 해결 방법은 점 표기법 열 이름을 사용하는 것입니다. customer.address.city가 자체 열이 됩니다. 이 방법은 한 수준의 중첩에는 효과적이지만, 배열이 나타나면 완전히 깨집니다. 세 개의 전화번호를 가진 고객의 경우 세 개의 별도 열(최대 수를 하드코딩), 두 번째 CSV 파일로 분리, 또는 단일 셀 안에 구분된 문자열로 배열을 인코딩하는 방법 중 하나가 필요합니다. 이 옵션들 중 어느 것도 추가 메타데이터 없이 원래 JSON으로 되돌릴 수 없습니다. XML은 별도의 모호성을 도입합니다. 속성 대 자식 요소 선택의 문제입니다. Paris라는 값은 속성으로 저장될 수도 있고(<city name="Paris">) 자식 요소로 저장될 수도 있습니다(<city><name>Paris</name></city>). 변환기가 XML을 읽고 JSON을 생성할 때 속성을 어떻게 매핑할지 결정해야 합니다. 일반적인 관례로는 속성 키에 @ 접두사를 붙이거나 "_attributes" 키 아래에 배치하는 것이 있습니다. 이 선택이 표준화되어 있지 않기 때문에 동일한 XML을 읽는 두 변환기가 구조적으로 다른 JSON을 생성할 수 있습니다. XML과 JSON 사이에서 데이터를 왕복시킬 계획이라면 시작 전에 관례를 고정하세요.
CSV 함정: 구분자, 인용, 인코딩
CSV에는 단일 공식 표준이 없으며, RFC 4180만이 널리 인용되는 참조 문서입니다. 가장 일반적인 구분자는 쉼표이지만, 세미콜론(쉼표가 소수점 구분자로 사용되는 유럽 로케일에서 흔함), 탭(TSV), 파이프도 실제로 사용됩니다. .csv라는 이름의 파일은 어떤 것을 사용하는지 알려주지 않고 이 중 어느 것이든 사용할 수 있습니다. 필드 값에 구분자 자체가 포함된 경우 RFC 4180은 필드를 큰따옴표로 묶도록 요구합니다. "San Francisco, CA". 인용된 필드 안에 큰따옴표가 있으면 겹쳐 써서 이스케이프해야 합니다. "He said ""hello""". 리터럴 줄바꿈을 포함하는 필드도 인용되어야 합니다. 이 단계를 건너뛰는 파서는 추적하기 어려운 행 수 오류를 생성합니다. 인코딩은 별개의 함정입니다. Windows 도구의 CSV 파일은 종종 UTF-8 BOM(바이트 순서 표시: 파일 시작 부분의 세 바이트 EF BB BF)을 포함합니다. BOM은 Excel이 인코딩을 식별하는 데 도움이 되지만, 많은 프로그래밍 언어 파서는 BOM을 첫 번째 열 이름의 일부로 처리하여 "id" 대신 "id"라는 열을 생성합니다. 이는 이름으로 열을 조회하는 모든 다운스트림 코드를 깨뜨립니다. CSV 파일을 프로그래밍 방식으로 읽을 때는 파싱 전에 BOM을 제거하거나 명시적으로 처리하는 라이브러리를 사용하세요.
형식 선택: 설정, 교환, 스프레드시트
형식 선택은 보통 선호도가 아닌 맥락에 의해 결정됩니다. JSON은 REST API와 브라우저-서버 교환의 기본값입니다. 모든 프로그래밍 언어에서 기본적으로 파싱되고, 숫자와 불리언에 대한 타입 정보를 담습니다. 단점은 주석이 없다는 것으로, 개발자가 직접 읽고 편집하는 파일에는 적합하지 않습니다. YAML은 설정 파일(Kubernetes 매니페스트, CI 파이프라인 정의, Ansible 플레이북)에 선호됩니다. 인라인 주석을 허용하고 여러 수준의 들여쓰기가 있는 JSON보다 읽기 쉽기 때문입니다. 주요 위험은 들여쓰기 오류가 무언으로 발생한다는 점입니다. 잘못 들여쓰인 키가 파싱 오류 없이 다른 범위로 이동합니다. XML은 오래된 기업 시스템, SOAP 웹 서비스, 문서 형식(DOCX, SVG, RSS), 스키마 유효성 검사나 네임스페이스 구분이 필요한 맥락에서 여전히 표준입니다. 장황하지만 XPath와 XSLT 도구가 성숙해 있습니다. CSV는 데이터가 진정으로 평면적이고 소비자가 스프레드시트 애플리케이션이나 데이터 분석가인 경우에 적합한 선택입니다. 타입 시스템도 없고 중첩도 없기 때문에 설정이나 API 교환에는 적합하지 않습니다.
data-converter로 로컬에서 처리하기
이 사이트의 data-converter 도구는 CSV, JSON, YAML 사이를 완전히 브라우저 내에서 파싱하고 변환합니다. XML은 읽거나 쓰지 않습니다. 어떤 데이터도 서버로 전송되지 않습니다. 변환은 로컬 JavaScript 런타임에서 실행되며, 출력 결과는 기기를 벗어나지 않고 다운로드하거나 복사할 수 있습니다. 이는 공유해서는 안 되는 데이터에 중요합니다. 개인 정보가 포함된 API 응답, 내부 호스트명이 있는 설정 파일, 내부 데이터베이스의 CSV 내보내기 등이 해당됩니다. 그러한 데이터를 서버에서 실행되는 웹 기반 변환기에 붙여넣으면 콘텐츠가 네트워크를 통해 전송되어 사용자가 제어하지 못하는 하드웨어에서 처리됩니다. data-converter를 사용하면 브라우저 탭이 처리 환경입니다. 이 도구는 CSV를 읽거나 쓸 때 RFC 4180 인용 규칙을 적용하며, JSON이나 YAML을 CSV로 변환할 때는 평평한 객체 배열을 기대합니다. 키 아래에 중첩된 객체나 배열 값이 있으면 자동으로 점 표기법으로 평탄화되지 않으므로, 별도의 열로 만들고 싶다면 변환 전에 직접 그 필드를 평탄화하세요. XML로 또는 XML에서 데이터를 옮겨야 한다면, 먼저 전용 XML 도구로 JSON이나 YAML로 변환한 다음 그 결과를 여기로 가져오세요.
이 아티클의 도구
자주 묻는 질문
JSON을 CSV를 통해 왕복시켜 원래대로 복원할 수 있나요?
JSON이 중첩 필드도 없고 값으로 배열도 없는 평면적인 객체 배열인 경우에만 가능합니다. 중첩 객체나 배열 값이 있는 순간 CSV 표현은 자동으로 되돌릴 수 없는 구조적 결정(점 표기법 열, 여러 행, 또는 인코딩된 문자열)이 필요합니다. 데이터에 중첩이 있다면 JSON, XML, 또는 YAML은 왕복이 가능하지만 CSV는 그렇지 않습니다.
유럽 애플리케이션에서 내보낸 후 Excel에서 CSV가 이상하게 보이는 이유는 무엇인가요?
유럽 로케일은 쉼표가 소수 표기에 예약되어 있기 때문에 CSV 구분자로 세미콜론을 자주 사용합니다. 유럽 로케일의 Excel은 세미콜론을 기대합니다. 파일이 쉼표를 사용하면 Excel은 전체 행을 단일 열로 처리합니다. 해결책은 내보내기 설정에서 구분자를 변경하거나 Excel의 데이터 가져오기 마법사를 사용하여 구분자를 수동으로 지정하는 것입니다. UTF-8 BOM 문제는 별개입니다. BOM이 없으면 Excel이 악센트 문자를 깨진 텍스트로 잘못 읽을 수도 있습니다.
YAML과 JSON의 실용적인 차이점은 무엇인가요?
둘 다 동일한 기본 데이터 모델을 표현합니다. 객체, 배열, 문자열, 숫자, 불리언, null입니다. YAML은 주석(#로 시작하는 줄), 여러 줄 문자열 리터럴, 반복 블록을 위한 앵커 참조를 추가합니다. JSON은 유효한 YAML의 엄격한 부분 집합이지만 JSON 파서는 YAML을 읽지 않습니다. 실용적인 규칙은 다음과 같습니다. API 페이로드와 데이터 저장에는 JSON을 사용하고, 인간이 편집하고 인라인 주석이 도움이 되는 설정 파일에는 YAML을 사용하세요.