JSON, XML, CSV? 작업에 맞는 데이터 포맷 고르기
2026년 10월 13일
JSON, XML, CSV는 모두 시스템 간에 구조화된 데이터를 옮기기 위해 존재하지만, 이들을 서로 바꿔 쓸 수 있다고 여기는 것이 통합 프로젝트에서 데이터 손실, 깨진 가져오기, 비대해진 파일이 생기는 경로입니다. 각 포맷은 자신이 해결하려던 문제와 시대에 맞춰 실질적인 설계 트레이드오프를 했으며, 그 트레이드오프를 알면 주어진 작업에 맞는 포맷을 고르는 일이 간단해집니다.
CSV는 실제로 무엇에 강하고, 어디에서 무너집니까?
CSV(쉼표로 구분된 값)는 구조화된 포맷 중 가장 단순한 축에 속합니다. 일반 텍스트, 한 줄에 한 행, 쉼표로 구분된 값들로 이루어져 스프레드시트 소프트웨어, 데이터베이스, 지금까지 만들어진 거의 모든 데이터 도구가 읽을 수 있습니다. 모든 행이 같은 필드를 가지는 레코드 목록 같은 평면적인 표 형태 데이터에 탁월합니다. 하지만 데이터가 평면 표를 넘는 실질적인 구조를 갖는 순간 무너집니다. 중첩 객체, 일대다 관계, 정당하게 쉼표나 줄바꿈을 포함하는 필드(CSV 구현마다 일관되지 않게 처리됨)는 모두 CSV를 설계 범위 밖으로 밀어냅니다.
JSON은 왜 특히 웹 API의 기본이 되었습니까?
JSON의 객체와 배열 구조는 대부분의 현대 프로그래밍 언어가 이미 메모리에서 데이터를 표현하는 방식에 거의 그대로 대응됩니다. 즉 JSON 페이로드는 최소한의 변환 작업으로 네이티브 데이터 구조로 직접 파싱될 수 있는 경우가 많으며, 이는 데이터를 만들고 소비하는 속도와 단순함이 모두 중요한 웹 API에 큰 실용적 이점입니다. 또한 비교적 간결하면서 사람이 읽을 수 있어서, 웹 API가 급증하면서 자연스러운 기본값이 되었고, XML이 먼저 등장했음에도 새 API 설계에서 XML을 대체로 밀어냈습니다.
XML이 할 수 있지만 JSON은 구조적으로 할 수 없는 것은 무엇입니까?
XML은 요소의 속성(내용과 별개로 태그 자체에 붙는 메타데이터), 네임스페이스(다른 출처의 어휘를 결합할 때 이름 충돌 방지), 그리고 유효한 문서가 정확히 무엇을 담아야 하는지 엄격하게 정의하고 강제하는 성숙한 공식 스키마 검증 생태계(XSD)를 지원합니다. JSON의 더 단순한 객체/배열 모델은 이런 기능을 기본으로 제공하지 않습니다(JSON Schema가 있지만 나중에 등장했고 보편적으로 채택되지는 않았습니다). 그래서 XML은 엄격한 문서 검증, 혼합 어휘 문서, 또는 JSON의 부상 이전에 확립된 오래된 기업 및 정부 데이터 표준이 필요한 영역에서 계속 쓰입니다.
CSV를 JSON 같은 중첩 포맷으로 변환하는 데 왜 기계적 변환 이상이 필요합니까?
CSV에는 중첩 개념이 없습니다. 모든 행이 평면적입니다. 따라서 CSV 데이터를 계층을 지원하는 포맷(예를 들어 여러 품목이 있는 주문을 표현하는 JSON)으로 변환하려면 평면 행이 중첩 구조에 어떻게 대응되는지 실제로 결정해야 합니다. 각 행이 별도의 최상위 객체가 됩니까, 아니면 같은 ID를 공유하는 여러 행이 중첩 배열을 가진 하나의 객체로 묶입니까? 이 매핑 결정은 CSV 데이터만으로는 복원할 수 없습니다. 데이터의 실제 관계를 이해해야 하며, 그래서 구조를 지정하지 않으면 '내 CSV를 JSON으로 그냥 변환해 줘'가 때로 기술적으로는 유효하지만 실제로는 쓸 수 없는 결과를 만들어 냅니다.
세 포맷 사이에 파일 크기나 파싱 속도가 의미 있게 다릅니까?
CSV는 레코드마다 반복되는 태그 이름이나 키 이름 같은 구조적 오버헤드가 거의 없기 때문에 정말 평면적이고 균일한 데이터에서는 일반적으로 가장 간결합니다. JSON은 XML의 닫는 태그 중복이 없어서 같은 중첩 데이터에서 XML보다 간결하지만, 더 간결한 배열 기반 인코딩을 쓰지 않는 한 모든 객체에서 키 이름이 반복되어 CSV보다 오버헤드가 큽니다. XML은 장황한 여는 태그와 닫는 태그 때문에 동등한 데이터에서 보통 셋 중 가장 크지만, 특정 통합에 실제로 필요한 구조적 기능과 도구 생태계에 비하면 이것이 결정적 요인이 되는 경우는 드뭅니다.