CSV Best Practices for Developers — csv-x.com

나는 여전히 누군가가 Excel에서 CSV 파일을 열고 "빠른 수정"을 한 후 저장하여 우리의 전체 데이터 파이프라인이 다운된 날을 기억합니다. 5분이면 끝날 작업이 6시간의 사건으로 변했고, 그로 인해 우리 회사는 약 47,000달러의 수익 손실과 엔지니어링 시간을 잃었습니다. 그것은 7년 전, 내가 핀테크 스타트업의 주니어 데이터 엔지니어였을 때의 일입니다. 오늘날 포춘 500대 기업의 수석 데이터 엔지니어로서, 나는 다양한 조직에서 이와 동일한 시나리오가 수십 번 발생하는 것을 보았고, CSV 파일이 소프트웨어 개발에서 가장 보편적이면서도 가장 오해받는 데이터 형식이라는 것을 배웠습니다.

아이러니하게도 CSV(Comma-Separated Values) 파일은 단순해야 합니다. 이 파일은 사람이 읽을 수 있고, 보편적으로 지원되며, 1970년대부터 존재해왔습니다. 그러나 내 데이터 시스템에서 12년을 일하는 동안, 매일 수십억 건의 레코드를 처리하는 ETL 파이프라인을 구축하는 것부터 기업 클라이언트를 위한 데이터 레이크를 설계하는 것까지, 나는 CSV 처리 문제로 인한 생산 사고가 다른 데이터 형식보다 더 많이 발생하는 것을 목격했습니다. 문제가 있는 것은 CSV가 본래 나쁜 것이 아니라, 개발자들이 그 복잡성을 지속적으로 과소평가하고 단순성을 과대평가한다는 것입니다.

"단순한" 텍스트 파일 뒤의 숨겨진 복잡성

대부분의 개발자가 CSV 파일에 대해 생각할 때, 그들은 값을 쉼표로 구분하고 한 줄에 하나의 레코드가 있는 간단한 형식을 떠올립니다. 이 정신 모델은 매우 불완전합니다. 실제로 CSV "표준"은 수많은 에지 케이스와 구현 변형이 뒤섞인 느슨하게 합의된 규칙 모음에 가깝습니다.

이 점을 고려해 보십시오: CSV 파서는 줄 바꿈이 포함된 따옴표 필드를 처리하는 방법이 최소 15가지가 있습니다. 나는 데이터가 한 시스템에서 내보내기 되었지만 다른 시스템에 가져올 수 없는 문제를 디버그한 경험이 있습니다. 이 문제는 따옴표 필드 내에서 이스케이프된 따옴표 처리 방식의 미세한 차이로 인해 발생했습니다. 2005년 발표된 RFC 4180 사양은 CSV 형식을 표준화하려고 했지만 진정한 표준이 아닌 "정보"로 라벨이 붙어 있으며, 많은 도구들이 그 이전에 등장했거나 단순히 무시합니다.

기억에 남는 프로젝트 중 하나에서, 우리는 여러 출처에서 고객 피드백 데이터를 처리하고 있었습니다. 한 공급업체의 CSV 내보내기는 구분자로 쉼표를 사용했지만, 다른 하나는 세미콜론(쉼표가 소수점을 구분하는 유럽 지역에서 흔함)을 사용했으며, 세 번째는 탭을 사용했지만 여전히 "CSV 파일"이라고 불렀습니다. 우리의 초기 파서는 약 23%의 수신 파일에서 실패하여 180,000개의 처리되지 않은 레코드가 쌓이는 결과를 초래했습니다. 이후 우리는 적절한 형식 탐지를 구현했습니다.

여기서 얻은 교훈은 근본적입니다: CSV 파일이 무엇을 포함하고 있는지 아는 것은 실제로 검사하기 전까지는 가정하지 마십시오. 나는 항상 프로그램적으로 처음 몇 줄을 점검하며, 바이트 순서 마크(BOM)를 확인하고, 실제 사용된 구분자를 감지하며, 인코딩을 검증하는 것으로 시작합니다. 이러한 방어적 접근 방식은 나를 무수한 디버깅 시간에서 구해주었고, 여러 생산 문제를 예방했습니다.

문자 인코딩: 조용한 데이터 킬러

만약 내가 생산 시스템에서 CSV 관련 버그의 가장 일반적인 원인을 하나만 꼽아야 한다면, 그것은 문자 인코딩 문제일 것입니다. 내 경험에 따르면 CSV 처리 문제의 약 40%가 인코딩 불일치에서 발생하지만, 대부분의 개발자는 이 측면에 최소한의 고려만 합니다.

CSV 파일은 데이터 형식의 바닥나는 곤충과 같아서—모든 것에서 살아남고, 어디에서나 작동하며, 예상치 못한 문제를 일으킵니다. 이들을 보편적으로 만드는 단순함이 생산 시스템에서 그들을 위험하게 만드는 동일한 단순함입니다.

내 작업에서의 실제 예: 우리는 국제 공급업체의 제품 카탈로그 데이터를 처리하고 있었습니다. CSV는 Windows에서 Excel로 열었을 때 완벽해 보였지만, 우리의 Python 기반 수집 파이프라인은 제품 이름을 손상시켜 "Café"를 "Café"로, "naïve"를 "naïve"로 변형했습니다. 근본 원인은 무엇인가요? 파일이 Windows-1252(구식 Windows 인코딩)로 인코딩되었지만, 우리의 파이프라인은 UTF-8을 가정했습니다. 이로 인해 47개의 다른 카탈로그에서 약 12,000개의 제품 레코드에 영향을 미쳤습니다.

수정하려면 다단계 인코딩 탐지 전략을 구현해야 했습니다. 먼저 UTF-8 BOM(바이트 순서 마크: 16진수로 EF BB BF)을 확인합니다. 존재하면 UTF-8임을 알 수 있습니다. 그렇지 않으면, chardet 라이브러리를 사용하여 합리적인 확신으로 인코딩을 감지합니다. 중요한 데이터에 대해서는 인코딩 문제를 나타낼 수 있는 의심스러운 문자 시퀀스를 플래그하는 검증 규칙도 구현합니다.

CSV 파일을 읽을 때는 항상 인코딩을 명시적으로 지정하는 것을 권장합니다. Python에서는 시스템 기본값에 의존하기보다는 encoding='utf-8'(혹은 감지된 인코딩)을 사용해야 합니다. 나는 개발 및 생산 환경 간의 기본 시스템 인코딩이 달라서 서로 다른 서버에 배포될 때 생산 시스템이 다르게 작동하는 것을 본 적이 있습니다.

또 하나의 중요한 실천: CSV 파일을 작성할 때는 Excel을 사용할 수 있는 소비자가 있다면 항상 UTF-8과 BOM을 사용해야 합니다. Windows에서 Excel은 BOM 없이 UTF-8 인코딩을 제대로 감지하지 못해 비ASCII 문자의 경우 엉망이 된 텍스트를 초래합니다. 이 작은 세부사항은 수출된 데이터가 손상된 것처럼 보이는 이유를 알지 못하는 비즈니스 사용자로부터 수많은 지원 티켓을 방지해 주었습니다.

구분자 탐지 및 처리

CSV의 "C"는 "쉼표"를 의미하지만, 실제로 나는 쉼표, 세미콜론, 파이프, 탭, 심지어 ASCII 단위 구분자 문자(0x1F)와 같은 더 이국적인 구분자를 사용하는 CSV 파일을 만났습니다. 구분자의 선택은 종종 지역, 파일을 생성한 도구 또는 데이터의 성질에 따라 다릅니다.

유럽 국가에서는 세미콜론을 구분자로 사용하는 경우가 많습니다. 왜냐하면 숫자에서 쉼표가 소수점 구분자로 사용되기 때문입니다 (예: "1.234,56" 대신 "1,234.56"). 나는 23개의 서로 다른 유럽 은행의 재무 데이터를 통합하는 프로젝트에서 작업하던 중, 그 출처들 사이에서 일곱 가지 다른 구분자 규칙을 만난 적이 있습니다. 강력한 구분자 탐지 시스템을 구축하는 것이 필수적이었습니다.

내 구분자 탐지 접근 방식은 파일의 처음 몇 줄을 분석하는 것입니다 (나는 일반적으로 통계적 중요성을 위해 10-20줄을 사용합니다) 및 잠재적인 구분자 발생 횟수를 계산합니다. 각 줄에서 같은 횟수로 나타나는 구분자가 올바른 것일 가능성이 높습니다. 그러나 이 휴리스틱은 데이터가 필드 내에서 구분자 문자를 포함할 때 실패하므로, 적절한 따옴표 처리가 필수적입니다.

나는 간단한 규칙을 개발했습니다: 데이터가 구분자 문자를 포함할 수 있는 경우, 반드시 따옴표 필드를 사용하여야 합니다. 데이터가 따옴표를 포함할 수 있는 경우, 반드시 이스케이프(일반적으로 두 배로 작성: ""는 따옴표 필드 내의 리터럴 따옴표를 나타냄)를 해야 합니다. 나는 개발자들이 "|||" 또는 "^|^"와 같은 불분명한 구분자를 선택하여 그들의 데이터에 이러한 시퀀스가 절대 포함되지 않을 것이라고 생각하는 것을 본 적이 있습니다. 이 접근 방식은 결국 항상 실패합니다. 나는 개발자들이 발명한 모든 "안전한" 구분자 시퀀스를 포함하는 데이터를 직접 경험했습니다.

생산 시스템에서는 반드시 사용자 정의 구문 분석 로직을 작성하는 것보다 잘 시험된 CSV 라이브러리를 사용합니다. Python에서는 표준 라이브러리의 csv 모듈이 대부분의 에지 케이스를 올바르게 처리합니다. 성능 요구 사항이 더 높은 경우, 나는 pandas를 사용하여 표준 라이브러리보다 대규모 데이터세트에 대해 5-10배 빠르게 CSV 파일을 처리할 수 있도록 합니다. 핵심은 이러한 라이브러리를 올바르게 구성하는 것입니다: 구분자, 따옴표 문자, 이스케이프 문자 및 줄 종료 문자를 기본값에 의존하지 않고 명확히 지정하는 것입니다.

메모리 관리 및 대용량 파일 스트리밍

내가 개발자들이 자주 저지르는 가장 일반적인 실수 중 하나는 전체 CSV 파일을 메모리에 로드하는 것입니다. 이는 작은 파일에서는 잘 작동하지만, 파일 크기가 기가바이트 또는 테라바이트로 커지면 심각한 문제가 됩니다. 나는 누군가가 CSV 파일이 항상 "합리적인 크기"일 것이라고 생각하여 메모리 부족 오류로 인해 충돌하는 생산 시스템을 디버그한 경험이 있습니다.

12년의 데이터 엔지니어링 동안, 나는 CSV 인코딩 문제, 따옴표 이스케이프 및 Excel 자동 서식으로 인한 생산 사고를 실제 애플리케이션 코드의 버그로 인한 사고보다 더 많이 보았습니다. 이 형식의 진정한 표준의 부재는 모든 파서가 잠재적인 지뢰가 될 수 있음을 의미합니다.

특히 도전적인 프로젝트에서, 우리는