Data Validation Best Practices for CSV Files - CSV-X.com

나는 여전히 잘못된 쉼표 하나로 내 고객이 320만 달러를 잃었던 날을 기억한다. 2019년이었고, 나는 중규모 제약회사에서 데이터 통합 컨설턴트로 일하고 있었다. 그들은 여러 연구 사이트에서 임상 시험 데이터를 가져와서 모두 마스터 데이터베이스에 통합하고 있었다. CSV 파일은 깔끔해 보였고, 기본 검증 체크를 통과했으며, 오류 없이 로드되었다. 3개월 후, FDA 감사 중에 그들은 국제 사이트에서 일관되지 않은 소수점 구분 기호로 인해 용량 수치가 체계적으로 잘못 해석되었다는 사실을 발견했다. 유럽 사이트는 소수점으로 쉼표를 사용했지만 (10,5 mg), 시스템은 이것을 천 단위 구분 기호로 해석했다 (105 mg). 환자 안전은 결코 손상되지 않았으니 다행이지만, 규제 처벌과 조치 비용은 치명적이었다.

나는 마커스 천이고, 지난 14년 동안 데이터 파이프라인과 검증 프레임워크를 구축해왔다. 데이터가 잘못될 여유가 없는 조직들—의료 시스템, 금융 기관, 정부 기관을 위해서 말이다. 나는 CSV 파일이 거래 시스템을 마비시키고, 의료 기록을 망치고, 수백만 달러 규모의 프로젝트를 망치는 것을 보았다. 그러나 동시에 간단하고 체계적인 검증 관행이 이러한 재앙을 완전히 예방하는 것도 목격했다. 오늘, 나는 CSV 파일을 제대로 검증하는 방법에 대해 내가 배운 것을 공유하고 싶다. 이론적인 모범 사례가 아니라 실제 환경에서 효과가 있는 전투 검증 접근 방식을 말이다.

CSV 검증이 당신이 생각하는 것보다 중요한 이유

CSV 파일은 어디에나 있다. 2023년 데이터 관리 협회(Data Management Association)의 조사에 따르면 여전히 73%의 조직이 JSON이나 Parquet와 같은 더 강력한 대안이 있음에도 CSV를 데이터 교환의 주요 형식으로 사용하고 있다. 이유는 무엇일까? CSV는 보편적이고, 사람이 읽을 수 있으며, 특수 소프트웨어를 요구하지 않기 때문이다. 재무팀은 Excel에서 내보낼 수 있고, 개발자는 Python 스크립트에서 생성할 수 있으며, 1990년대의 구식 시스템도 여전히 CSV 파일을 생성할 수 있다.

하지만 이러한 보편성은 숨겨진 비용을 동반한다. CSV에는 공식적인 사양이 없다. RFC 4180 표준은 규칙이라기보다는 제안에 가깝다. 서로 다른 시스템이 CSV를 다르게 구현한다. 어떤 것은 쉼표를 구분 기호로 사용하고, 다른 것은 세미콜론이나 탭을 사용한다. 어떤 것은 필드를 따옴표로 묶고, 어떤 것은 그렇지 않다. 어떤 것은 헤더를 포함하고, 어떤 것은 데이터로 바로 시작한다. 이러한 유연성은 CSV를 믿을 수 없게 만든다.

내 경험상 대략 40%의 데이터 통합 문제는 CSV 파싱 문제에서 발생한다. 나는 지난 10년 동안 200개 이상의 프로젝트에서 이를 추적했다. 문제는 사소한 불편(문자열 일치 실패를 유발하는 여분의 공백)부터 엄청난 실패(잘못된 금액의 금융 거래, 잘못된 환자에게 할당된 의료 기록)까지 다양하다. 내 고객층에서 CSV 관련 데이터 사건의 중간 비용은 조사 시간, 수정 및 비즈니스 영향을 포함해 47,000달러이다.

실제 문제는 CSV 파일이 본질적으로 나쁜 것이 아니라, 대부분의 조직이 검증을 사후 고려사항으로 취급한다는 것이다. 그들은 "파일에 올바른 열 수가 있습니까?"와 같은 기본 검증만 구현하고 완료했다고 생각한다. 하지만 효과적인 CSV 검증은 파일 구조부터 비즈니스 로직까지 여러 수준에서 문제를 잡아내는 계층적 접근법이 필요하다. 그 방법을 보여주겠다.

1단계: 구조 검증

구조 검증은 첫 번째 방어선이다. CSV 내부의 데이터에 대해 생각하기 전, 파일이 실제로 유효한 CSV이며 예상하는 형식과 일치하는지 확인해야 한다. 이는 자명하게 들릴지 모르지만, 누군가 PDF 파일을 .csv 확장자로 업로드하여 생산 시스템이 충돌하는 것을 보았다.

가장 비싼 데이터 오류는 시스템을 충돌시키는 것이 아니라, 아무도 모르는 사이에 몇 달 동안 조용히 데이터를 망치는 것이다.

파일 수준의 검증부터 시작하자. 파일 크기가 예상되는 범위 내에 있는지 확인하라. 일일 거래 파일이 5-10MB 정도가 예상된다면, 2GB 파일이나 2KB 파일은 즉각적인 경고 신호가 되어야 한다. 문자 인코딩을 확인하라. 오늘날 표준은 UTF-8이지만, 구식 시스템은 종종 Latin-1 또는 Windows-1252로 인코딩된 파일을 생성한다. 불일치된 인코딩은 "이상한 문자" 문제를 야기하는데, 이로 인해 "José"와 같은 이름이 "José"로 변환된다.

다음으로 구분 기호 및 따옴표 문자를 검증하라. 가정하지 말고, 탐지하라. 나는 간단한 휴리스틱을 사용한다: 처음 10개 줄을 읽고 잠재적 구분 기호(쉼표, 세미콜론, 탭, 파이프)의 발생 횟수를 센다. 줄에서 가장 일관되게 나타나는 문자가 아마도 너의 구분 기호일 것이다. 따옴표 문자의 경우, 구분 기호를 포함하는 필드가 따옴표로 감싸져 있는지 확인하라. 따옴표 없이 필드 안에 쉼표가 있으면 잘못된 CSV이다.

헤더 검증이 중요하다. CSV에 헤더가 있어야 한다면, 그것이 존재하는지 확인하고 예상하는 내용과 정확히 일치하는지 검증하라. 나는 엄격한 일치를 사용한다—"CustomerID"는 "Customer ID"나 "customer_id"와 동일하지 않다. 대소문자 구분은 중요하다, 왜냐하면 코드가 "email"을 찾고 있는데 헤더가 "Email"이라면 미세한 버그를 유발할 수 있기 때문이다. 나는 예상되는 헤더와 정확한 맞춤법의 화이트리스트를 유지한다. 모든 일탈은 즉시 플래그가 지정된다.

열 수 일관성은 또 다른 구조적 검증으로 많은 문제를 조기에 잡아낸다. 모든 행은 헤더와 동일한 수의 열을 가져야 한다. 나는 마지막 열이 선택적이므로 일부 행에는 있고 일부 행에는 없는 파일을 보았다. 이는 대부분의 CSV 파서에서 오류를 일으킨다. 선택적 열이 필요하다면, 비어 있어야 하고(연속된 구분 기호로 표현된 "value1,value2,,value4") 여전히 존재해야 한다.

마지막으로 바이트 순서 표시(BOM)를 확인하라. Windows에서 Excel은 CSV 파일 시작 부분에 UTF-8 BOM(바이트 EF BB BF)을 추가한다. 많은 파서가 이로 인해 첫 번째 필드 이름의 일부로 간주해 choke를 일으킨다. 너의 검증은 BOM을 적절하게 감지하고 처리해야 하며, 이를 제거하거나 파서를 BOM을 예상하도록 구성해야 한다.

2단계: 데이터 타입 검증

파일이 구조적으로 올바르니 확인한 후, 각 필드가 올바른 타입의 데이터를 포함하는지 검증하라. 여기서 대부분의 검증 프레임워크는 멈추지만, 이는 실제로 시작에 불과하다. 타입 검증은 숫자 필드 내의 텍스트와 같은 명백한 오류를 잡지만, 더 깊이 들어가야 한다.

숫자 필드의 경우, 값이 숫자로 파싱될 수 있는지만 확인하지 말고, 형식이 예상과 일치하는지 검증하라. 정수나 소수를 예상하고 있는가? 소수점 자리는 몇 자리인가? 유효 범위는 무엇인가? 나는 한때 두 자리 소수만 허용해야 할 통화 필드에서 "1.23456789"를 허용하는 시스템을 디버깅했던 적이 있다. 여분의 정밀도가 수천 달러의 불일치를 초래하는 반올림 오류를 발생시켰다.

날짜 및 시간 필드는 특히 까다롭다. 유효한 날짜 형식은 수십 가지가 있다: "2024-01-15", "01/15/2024", "15-Jan-2024", "2024-01-15T14:30:00Z". 검증에서는 정확히 어떤 형식을 예상하는지 명시하고, 다른 것은 모두 거부해야 한다. 여러 형식을 수용하려다 모호해지는 시스템을 많이 보았다. "01/02/2024"가 1월 2일인지 2월 1일인지? 추측하지 말고 명확한 형식을 강제하라.

문자열 필드도 검증이 필요하다. 예상치 못한 문자가 있는지 확인하라, 특히 필드 내에서 널 바이트, 캐리지 리턴 또는 줄 바꿈과 같은 제어 문자를 체크하라. 이는 파서를 중단시키거나 보안 문제를 일으킬 수 있다. 문자열 길이도 검증하라—데이터베이스 열이 VARCHAR(50)이라면, CSV 수준에서 50자보다 긴 값을 거부하고 데이터베이스가 조용히 잘라내지 못하도록 해야 한다.

불리언 필드는 겉보기에는 복잡해 보인다. "true/false", "yes/no", "1/0", "Y/N", "T/F"를 모두 유효한 불리언 값으로 수용하는 시스템을 보았다. 이러한 유연성은 "Yes" (대문자 Y)를 입력하면 시스템이 "yes" (소문자)로 기대할 때 문제를 일으킨다. 하나의 표현을 선택하고 고수해야 한다. 나는 모호하지 않고 언어 중립적인 "true/false"를 선호한다.

빈 값은 특별한 주의가 필요하다. 빈 문자열과 시스템 내의 널 값은 다른가? 빈 숫자 필드는 0으로 처리해야 하는가, 아니면 널로 처리해야 하는가? 빈 날짜 필드는 거부해야 하는가, 수용해야 하는가? 이러한 결정은 비즈니스 의미를 가진다. 재무 데이터에서 빈 금액 필드는 "거래 없음"을 의미할 수도 있고 "금액 불명"을 의미할 수도 있다—이는 매우 다른 것이다. 빈 값 처리를 명시적으로 문서화하고 그에 따라 검증하라.