CSV: 아무도 설계하지 않은 포맷
Source: Dev.to
By Design — Episode 02
명세서도, 스키마도, 데이터 타입도, 표준 인코딩도, 위원회도, 소유자도, 버전 번호도 없습니다.
1972년, IBM의 Fortran 컴파일러가 입력으로 콤마로 구분된 값을 받아들이기 시작했습니다. 설계 문서는 없었고, 표준을 제안한 사람도 없었습니다. 누군가가 데이터를 한 곳에서 다른 곳으로 옮겨야 했고, 값을 콤마로 구분했으며, 그것이 동작했습니다. 그것이 전부 사양이었습니다.
33년이 흐른 뒤, 야코프 샤프라노비치가 RFC 4180을 작성해 이미 널리 쓰이고 있던 방식을 공식화했습니다. 포맷이 표준화보다 더 빨리 퍼졌습니다.
“CSV는 실제 포맷이 아니다. 타입도, 스키마도, 검증도 없다. 한 번이라도 콤마가 잘못 놓이면 가져오기가 깨진다. 독일에서 온 세미콜론 구분 파일 하나 때문에 파이프라인이 폭발한다. 텍스트 파일 안에서 아마추어 시간이 벌어지는 것이다.”
모든 데이터 엔지니어가 이렇게 말했습니다. 대부분은 오늘도 그렇게 말합니다.
왜 설계가 없는가
- 위원회가 없으니 → 정치도 없다.
- 스키마가 없으니 → 버전 충돌도 없다.
- 타입이 없으니 → 지구상의 모든 시스템이 읽을 수 있다: 데이터베이스, 스프레드시트, 셸, 30년 된 메인프레임까지.
grep은 행을 찾고, awk는 열을 나누고, sort는 정렬합니다. 전체 Unix 툴체인은 CSV가 무엇인지 몰라도 CSV를 처리합니다.
“구분자를 기준으로 나누기”만 하면 파서가 필요 없고, “첫 번째 행이 헤더일 수도 있다”는 합의만 있으면 됩니다. 의존성도, 라이브러리도, 런타임도 필요 없습니다.
문제점
- 인코딩 혼란.
- 구분자 충돌.
- 이스케이프 표준 부재.
콤마로 구분된 파일 안에 콤마가 포함된 인용된 필드는 인용부호를 처리하지 못하는 시스템을 깨뜨릴 수 있습니다. 이러한 엣지 케이스는 취약성의 원천이며, 모든 놀라움은 금요일 오후에 찾아옵니다.
채택 현황
- 기업의 60 %가 시스템 간 데이터 교환에 CSV를 사용합니다.
- 모든 스프레드시트 애플리케이션, 데이터베이스 내보내기, CRM, ERP, 회계 도구가 CSV를 생성할 수 있습니다.
RFC 4180은 2005년에 발표되었으며, 그때쯤 이미 수십억 개의 CSV 파일이 존재했습니다.
경쟁 포맷
- XML: 대체 시도 → 너무 장황함.
- JSON: 대체 시도 → 표 형식이 없음.
- Parquet: 대체 시도 → 런타임 필요.
- Avro: 대체 시도 → 스키마 레지스트리 필요.
CSV는 텍스트 편집기와 콤마를 셀 수 있는 능력만 있으면 살아남았습니다.
거버넌스의 역설
합의를 필요로 하지 않는 포맷은 합의를 필요로 하는 포맷을 항상 앞섭니다. CSV는 거버넌스도, 권위도, 설계 문서도 없습니다. 이것이 결함이 아니라, 그것을 대체하려는 모든 포맷보다 오래 살아남은 이유입니다.
CSV는 아무도 설계하지 않았습니다. 53년이 지난 지금, 모두가 사용하고 있습니다.