CSV vs JSON vs Excel: I've Wasted Hours Using the Wrong Format

지난 화요일 새벽 3시, 나는 이번 주 세 번째로 47MB CSV 파일을 처리하다 내 Python 스크립트가 멈추는 광경을 지켜보았다. 오류 메시지가 나를 조롱했다: "메모리 할당에 실패했습니다." 그때까지 나는 데이터 엔지니어로 8년을 보냈고, 여전히 파일 형식에 대한 루키 실수를 하고 있었다.

그 잠 못 이루는 밤은 내 팀에게 6시간의 처리 시간을 잃게 만들었고, 우리의 분기 분석 파이프라인을 거의 탈선시켰다. 최악의 부분? 나는 더 잘할 수 있었던 것이다. 나는 그냥 게으름을 피우고 "단순하니까" CSV를 선택했다. 그 결정은 인코딩 문제, 메모리 문제, 그리고 전혀 피할 수 있었던 데이터 유형 혼란으로 이어졌다.

나는 마커스 천이고, 지난 10년간 핀테크 스타트업부터 포춘 500 리테일러까지 다양한 데이터 파이프라인을 구축해왔다. 나는 수천 개 프로젝트를 통해 수십억 개의 행을 처리했고, 어렵게 배운 것이 있다: 잘못된 데이터 형식을 선택하는 것은 단순히 불편한 것이 아니다—비용이 많이 든다. 정말 많이 든다. 나는 한 번 열악한 형식 선택이 이전 회사에 매년 약 180,000달러의 불필요한 컴퓨팅 시간, 개발자 시간, 실패한 배치 작업 비용을 초래했다고 계산해본 적이 있다.

이 기사는 또 다른 건조한 기술 비교가 아니다. 이것은 형식 결정이 실제 결과를 초래하는 전선에서 작성된 현장 가이드이다. CSV, JSON 또는 엑셀을 사용할 정확한 순간을 보여주고, 내가 직면한 특정 시나리오와 중요한 지표로 뒷받침할 것이다. 끝나면 내가 수백 시간을 잃게 만든 실수를 피할 수 있는 방법을 알게 될 것이다.

CSV의 함정: 단순함이 복잡해질 때

CSV 파일은 그 단순함으로 당신을 유혹한다. 인간이 읽을 수 있으며, 보편적으로 지원되고, 안전한 선택인 것처럼 느껴진다. 데이터 분석가로서 첫 3년 동안 나는 거의 모든 것을 CSV로 기본 설정했다. 그러다 환자 기록을 처리하는 헬스케어 분석 팀에 합류했는데, CSV가 우리를 거의 망치게 했다.

문제는 순순히 시작되었다. 우리는 데이터베이스에서 230만 개의 환자 방문 기록을 내보내고 있었다. CSV는 완벽해 보였다—가볍고, 생성이 빠르며, 연구 파트너와 쉽게 공유할 수 있었다. 2주 만에 우리의 분석이 중단된 다섯 가지 중요한 문제가 발생했다.

첫째, 인코딩 악몽. 환자 이름에는 47개 언어에서 온 문자가 포함되어 있었다. 우리의 CSV 수출은 기본적으로 ASCII로 설정되어 있어, "José García" 같은 이름이 "Jos? Garc?a"로 엉망이 되었고, 한자로, 아랍어로, 키릴 문자로 된 이름을 완전히 파괴했다. 우리는 Excel 호환성을 위해 UTF-8 BOM (Byte Order Mark)이 필요하다는 것을 깨닫기까지 4일 동안 디버깅을 했다. 그러나 Python 스크립트를 위해서는 BOM 없는 UTF-8이 필요했다. 맞다—각기 다른 도구를 위해 서로 다른 CSV 변형이 두 가지 필요했다.

둘째, 데이터 유형 재앙. CSV는 데이터 유형의 개념이 없다. 모든 것이 분석할 때까지 텍스트이다. 우리의 "patient_id" 열에는 "00123" 같은 값이 포함되어 있는데, 엑셀은 이를 "123"으로 변환해버려져, 데이터베이스 조회에 필요한 선행 0이 파괴되었다. 날짜는 더 심각했다—"03/04/2023"는 지역 설정에 따라 3월 4일 또는 4월 3일일 수 있었다. 우리는 왜 18%의 날짜 조인이 실패했는지 추적하느라 주말을 모두 잃었다.

셋째, 구분자 혼란. 의학 노트에는 쉼표, 세미콜론, 탭이 포함되어 있었다. 우리는 쉼표로 구분, 세미콜론으로 구분, 그리고 탭으로 구분해보았다. 각 변경은 누군가의 가져오기 스크립트를 망가뜨렸다. 결국 우리는 파이프 구분자 (|)로 정착했다. 왜냐하면 그것은 우리의 텍스트 필드에서 고작 0.003%만 나타났기 때문이다. 하지만 그때까지 우리는 12시간을 낭비하고 호환되지 않는 파일 버전을 6개 생성해버렸다.

내가 배운 것은 다음과 같다: CSV는 일관된 유형과 특별한 문자가 없는 단순하고 평면적인 데이터에 대해 훌륭하게 작동한다. 그것은 깨끗한 숫자 ID, ISO 형식의 날짜 (YYYY-MM-DD), 한 문장을 넘지 않는 텍스트 필드가 있는 50,000개의 판매 거래 행을 내보낼 때 완벽하다. 복잡성을 추가하는 순간—중첩 데이터, 혼합 유형, 국제 문자 또는 대량 텍스트 블록—CSV는 책임이 된다.

성능 수치는 이야기를 전한다. 10MB 파일에 100,000개의 간단한 숫자 데이터가 있을 경우, CSV 파싱은 pandas를 사용하여 Python에서 약 0.8초 걸린다. 그러나 텍스트 필드에 이스케이프된 따옴표와 쉼표를 추가하면 3.2초로 증가한다. 인코딩 감지가 추가되면 5.1초가 된다. 수천 개 파일을 배치 처리할 경우, 이 초들이 시간으로 누적된다.

JSON의 숨겨진 비용: 유연성이 부풀어 오를 때

내 CSV 재앙 이후, 나는 JSON 쪽으로 크게 치우쳤다. 그것은 CSV가 처리할 수 없는 모든 것을 해결해주었다: 중첩 데이터, 명시적 유형, 유니코드 지원, 그리고 명확한 사양. 나는 2년 동안 JSON 전도사였다. 그러다 전자상거래 플랫폼을 위한 실시간 분석 대시보드를 구축했고, JSON은 나에게 몇 가지 비용이 많이 드는 교훈을 안겨주었다.

"잘못된 데이터 형식을 선택하는 것은 단순한 기술적 결정이 아니다—재정적 결정이다. 나는 개발자들이 습관적으로 CSV를 기본으로 사용하는 바람에 연간 6자리 수를 태우는 회사를 보아왔다."

이 프로젝트는 간단해 보였다: 20만 명의 일일 활성 사용자로부터 클릭스트림 데이터를 수집하고, 이를 실시간으로 처리하며, 대시보드에 메트릭을 표시하는 것이었다. 각 클릭 이벤트는 중첩된 사용자 속성, 제품 세부사항, 세션 메타데이터를 포함한 약 30개 필드가 있는 JSON 객체였다. 아름답고, 구조화되어 있으며, 스스로 문서화된 데이터.

첫 번째 문제는 3주째 나타났다: 파일 크기 폭발. 우리의 동등한 CSV 파일은 데이터 1시간당 평균 2.1MB였다. JSON 버전은? 8.7MB였다. 동일한 정보를 위해 4.1배 더 컸다. 범인은 JSON의 장황함이었다—각 필드 이름이 모든 레코드에 대해 반복되었기 때문이다. CSV에서 "user_id"는 헤더에 한 번만 나타난다. JSON에서는 50,000개의 레코드가 있을 경우 50,000번 나타난다.

이것은 단순한 저장 문제에 그치지 않았다. 우리는 네트워크를 통해 서비스 간에 이 파일들을 전송하고 있었다. 1시간당 8.7MB, 하루 24시간, 30일이면 우리는 1.5GB 대신 6.3GB를 옮기고 있었다. 우리의 AWS 데이터 전송 비용은 월 $47에서 $201로 증가했다. 15개의 마이크로서비스에 이를 곱하면, JSON을 써서 월 $2,310의 인프라 비용이 추가되었다.

두 번째 문제는 파싱 성능이었다. JSON 파싱은 메모리에 객체 트리를 작성해야 하기 때문에 계산적으로 비용이 많이 든다. 클릭스트림 데이터의 경우, 표준 json 라이브러리를 사용하여 100MB JSON 파일을 파싱하는 데 Python에서 12.3초가 걸렸다. 동등한 CSV는? pandas로 3.1초였다. 매 5분마다 파일을 처리할 때, 파일마다 9.2초의 차이는 매월 26.5시간의 컴퓨팅 시간으로 누적된다.

하지만 여기서 흥미로워지는 부분이 있다: JSON은 CSV가 처리할 수 없는 특정 시나리오에서 빛난다. 결제 API를 구축하는 핀테크 스타트업으로 옮겼을 때, JSON은 필수불가결해졌다. 우리는 청구 주소를 포함한 거래 데이터를 깊게 중첩한 웹훅 페이로드를 처리하고 있었다—결제 방법에 지리적 좌표가 포함된 주소가 있었다. 이걸 CSV로 평평하게 만들려면 40개 이상의 열이 필요했을 것이며, 대부분의 경우 비어있었다.

JSON의 진정한 힘은 API와 구성 파일에 있다. 우리의 결제 웹훅에서 JSON의 자기 설명적 특성 덕분에 API 소비자가 문서 없이도 응답을 파싱할 수 있었다. 중첩 구조는 우리의 도메인 모델과 완벽하게 일치했다. 그리고 새로운 필드를 추가해야 할 때, 기존 통합을 깨뜨리지 않고도 할 수 있었다—위치 기반 CSV 형식에서는 불가능한 일이다.

내가 개발한 규칙: 시스템 간 데이터 교환, 특히 API에 JSON을 사용하라, 그리고 인간 가독성과 유연성이 크기나 속도보다 더 중요한 구성 파일에 대해 JSON을 사용하라. 대규모 데이터 저장 또는 반복적으로 동일한 구조를 이동하는 배치 처리에는 JSON을 피하라. 그런 경우, 장황함 세금이 너무 비싸진다.

엑셀: 모두가 싫어하지만 비밀리에 필요한 형식

나는 수년간 엑셀 파일을 "실제 데이터 형식이 아니다"라고 치부해왔다. 그것들은 비즈니스 사용자가 더 나은 방법을 모르고 만들었던 것들이었다. 그러다 소매 분석 회사에서 데이터 팀 리더가 되었고, 엑셀 파일 (.xlsx)이 종종 실제 세계에서는 제대로 작동하는 유일한 형식이라는 것을 배우게 되었다.

각성의 순간은 우리의 상품 기획 팀과의 프로젝트 중에 일어났다. 그들은 지역, 카테고리 및 SKU별로 구분된 주간 판매 보고서가 필요했으며, 성능이 떨어지는 제품을 강조하기 위한 조건부 서식이 필요했다. 나는 CSV 파일을 생성하는 아름다운 자동화 파이프라인을 구축했다.