GN⁺ 2025-03-27 | parent | ★ favorite | on: CSV 포맷에 대한 러브레터(github.com/medialab)
Hacker News 의견
  • CSV와 INI 파일을 좋아하는 이유는 단순하고 텍스트 기반이며, 형식에 인코딩된 타입이 없고 문자열로만 구성되어 있기 때문임

    • 공식 표준이 없다는 단점이 있지만, 제 역할을 잘 수행함
    • TOML에 대한 INI 비판을 북마크해 두었음
    • TOML 비판의 첫 번째 줄이 CSV에도 적용된다고 생각함: 여러 방언의 연합체임
  • CSV는 우아하지만 치명적인 결점이 있음 - 인용부호가 "비지역적" 효과를 가짐

    • 예를 들어, 바이트 1에 있는 인용부호 하나가 바이트 1000000에 있는 쉼표의 의미를 바꿀 수 있음
    • 이로 인해 두 가지 불편한 결과가 발생함
      • CSV 처리의 병렬화가 어려움
      • 데이터 손상이 파일의 가독성에 큰 영향을 미침 (인용부호 하나의 누락이나 추가가 전체를 망칠 수 있음)
    • 그래서 요즘은 간단한 테이블 데이터 직렬화에 대해 CSV 대신 단순한 이스케이핑을 선호함
  • CSV의 가장 좋은 점은 누구나 30분 만에 파서를 작성할 수 있다는 것임

    • 90년대 초의 데이터를 현대 웹 서비스로 쉽게 가져올 수 있음
    • 가장 나쁜 점은 누구나 30분 만에 파서를 작성할 수 있다는 것임
    • 잘못된 구현, 잘못된 데이터, 이상한 정의되지 않은 동작이 발생하기 쉬움
    • JSON과 YAML도 비슷한 문제를 가지고 있음
    • XML은 다소 보기 흉하지만 가장 견고한 것 같음
  • CSV를 좋아하는 사람은 기업 환경에서 CSV 주입 방지를 처리하라는 요청을 받은 적이 없을 것임

    • 웹에 좋은 자원이 부족함
    • 가장 좋은 자원은 <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">여기</a>임
  • CSV를 좋아하는 이유는 여러 가지가 있음

    • C로 프로그램을 작성하여 다양한 것을 CSV로 직접 출력할 수 있음
    • 거의 모든 데이터베이스나 일반적인 "것"에서 CSV로 쉽게 변환할 수 있는 간단한 미들웨어를 작성할 수 있음
    • CSV를 엑셀에 넣고 원하는 모든 것을 할 수 있음
    • ini 파일도 좋아함. 메모장에서 직접 수정할 수 있음
    • 그러나 일반적인 개요/구조가 있었으면 좋겠음
  • 최근 Raspberry Pi 기반 솔루션을 개발하고 있음

    • 첫 번째 구현은 SQLite 데이터베이스를 사용했으나, 전원 주기 후 몇 일 만에 손상됨
    • Parquet 파일을 살펴보았으나 append-only 작업에 친화적이지 않음
    • IPC 파일에 이벤트를 기록하고 주기적으로 Parquet 파일로 "플러시"하는 방법을 구현함
    • 작동하고 효율적이지만 제대로 구현하기가 쉽지 않음
    • 일반 개발자에게는 CSV (또는 JSONL)가 여전히 최고임
  • CSV의 재미없는 점은 빠르게 작성된 파서와 직렬화기가 인용부호를 잘못 처리하는 일반적인 실수를 반복하는 것임

    • 오랫동안 CSV를 경계했으나 Python을 배우고 훌륭한 csv 표준 라이브러리 모듈을 사용하면서 달라짐
  • 만약 이것이 정말로 러브레터였다면, CSV 형식으로 작성되었을 것임

  • JSON에 대한 반론은 그다지 설득력이 없음

    • 모든 필드에 이름을 추가하는 것은 필요하지 않음
    • CSV와 JSON을 비교하면 JSON은 약간 더 크지만, 괄호가 단순하거나 복잡할 수 있는 능력을 나타냄
    • CSV는 단순하기 때문에 파싱/인코딩 라이브러리를 사용하지 않는 경우가 많음
    • JSON 파서는 항상 예상 값을 출력하며, 언어는 아마도 매우 효율적인 SIMD 기반 파서를 사용함
    • 표준화 문제도 있음. CSV 파일이 쉼표, 공백, 세미콜론, 파이프 등을 사용하는지, CR, LF, CRLF를 사용하는지, 인용부호를 이스케이프할 수 있는지 등의 문제가 있음
    • JSON은 이러한 문제가 없음
    • JSON은 타입이 있음. 6가지 타입이 없는 것보다 나음
    • JSON은 완벽하지 않지만, 일반적으로 CSV보다 나음
  • 현대적인 형식을 좋아하는 사람으로서, 의심스러울 때는 CSV나 JSONL을 사용함

    • 주로 평문 텍스트이기 때문에 grep으로 쉽게 찾을 수 있고 스트리밍 가능함
    • 문서에 나열된 대부분의 기능은 JSONL에도 공유됨
    • gzip이나 zstd로 잘 압축됨
    • 압축은 평문 텍스트의 장점을 일부 제거하지만, ripgrep은 압축된 파일도 검색할 수 있음
    • JSONL의 또 다른 장점은 더 작은 파일로 쉽게 나눌 수 있다는 것임