ParserError: Error tokenizing data가 발생했다면 먼저 인코딩보다 구분자와 행 구조를 확인해야 합니다. 이 오류는 read_csv가 파일의 필드를 기대한 방식으로 나누지 못했을 때 나타나며, 오류 행을 바로 건너뛰기보다 원본을 보존한 채 원인을 좁히는 순서가 중요합니다.
ParserError와 인코딩 오류를 구분하기
ParserError는 파일 내용을 파싱하는 중 생기는 일반적인 오류입니다. 예외명이 인코딩 관련 오류인지 파싱 오류인지 먼저 구분해야 합니다. Error tokenizing data, Expected ... fields in line, saw ..., EOF inside string이 보인다면 구분자, 열 수, 따옴표, 줄바꿈을 먼저 의심하는 편이 합리적입니다.
오류 메시지만으로 실제 원인을 확정할 수는 없습니다. pandas 공식 문서도 특정 파일의 판단에는 원문과 문제가 난 행을 확인해야 한다고 설명합니다. 원본 파일과 오류 메시지를 함께 보관하고, 파일을 덮어쓰거나 확장자만 바꾸는 식으로 시작하지 않는 것이 좋습니다.
1. 구분자와 예상 열 수 확인
read_csv는 기본적으로 쉼표를 구분자로 사용하며 sep 또는 delimiter로 구분자를 지정할 수 있습니다. 탭이나 세미콜론으로 나뉜 파일을 쉼표 파일처럼 읽으면 한 행이 한 필드로 합쳐지거나 예상보다 많은 필드가 생길 수 있습니다.
운영에서는 헤더, 정상 행, 오류 행을 원문으로 비교하고, 실제 구분자로 나눴을 때의 열 수를 확인합니다. 예를 들어 Expected 6 fields in line, saw 8이라면 오류 행에 구분자가 실제 데이터의 일부로 들어갔는지부터 살펴봅니다. 따옴표로 감싸야 할 값이 제대로 감싸지지 않았거나 파일의 구분자와 코드의 sep가 다를 수 있습니다. 열 수가 다르다는 메시지는 인코딩을 자동으로 증명하지 않습니다.
2. 따옴표와 줄바꿈 점검
값 안에 쉼표가 들어가는 CSV는 해당 값을 따옴표로 감싸는 경우가 많습니다. pandas의 quotechar는 인용 필드의 시작과 끝을 나타내며, 인용 필드 안의 구분자는 필드 분리에 사용되지 않습니다. quoting, doublequote, escapechar도 파일이 따르는 규칙에 맞아야 합니다.
EOF inside string은 닫히지 않은 따옴표처럼 인용 구조가 끝나지 않은 상황에서 나타날 수 있습니다. 이때 on_bad_lines='skip'으로 감추면 데이터가 사라질 수 있으므로 오류 행의 따옴표와 줄바꿈을 먼저 확인해야 합니다.
import pandas as pd
df = pd.read_csv(
"input.csv",
sep=",",
quotechar='"',
doublequote=True,
on_bad_lines="error",
)
이 예제는 이 옵션 조합이 모든 CSV를 해결한다는 뜻이 아닙니다. 실제 파일 규칙과 맞지 않는 값을 추측해 넣기보다, 원문 형식에 맞춰 한 항목씩 명시하라는 뜻입니다.
3. on_bad_lines는 데이터 손실 정책
pandas는 on_bad_lines로 잘못된 행을 다루는 방식을 선택하게 합니다. error는 오류를 발생시키고, warn은 경고를 출력한 뒤 해당 행을 건너뛰며, skip은 경고 없이 해당 행을 건너뜁니다.
업무 데이터라면 기본 판단은 error에 두는 편이 안전합니다. 전체 적재가 중단되더라도 누락을 발견할 수 있기 때문입니다. 오류 행이 업무상 버려도 되는 데이터이고 누락 사실을 별도 기록하며 후속 집계가 이를 감안한다면 warn 또는 skip을 검토할 수 있습니다. 중요한 것은 옵션 이름이 아니라 빠진 행의 수와 내용을 확인하는 절차입니다.
오류 행을 허용할 때는 원본 파일과 수집 시점, 오류가 난 행 또는 식별 가능한 원문, 제외 사유와 제외 건수, 결과 판단에 미치는 영향을 남겨야 합니다. 필드가 너무 적은 행은 뒤쪽 필드에 결측값이 채워질 수 있지만 필드가 너무 많은 행은 기본적으로 오류가 될 수 있습니다. 따라서 dropna()만으로 행 구조 오류를 해결했다고 볼 수 없습니다.
4. 엔진 변경은 마지막에 확인
pandas 문서는 C·pyarrow 엔진과 Python 엔진의 특성이 다르며 Python 엔진이 더 다양한 기능을 제공할 수 있다고 설명합니다. 그렇다고 엔진을 바꾸면 잘못된 CSV가 정상 데이터가 되는 것은 아닙니다.
먼저 구분자와 인용 규칙을 확인한 뒤 현재 사용하는 pandas 버전과 필요한 옵션이 선택한 엔진에서 지원되는지 확인해야 합니다. 사용자 정의 on_bad_lines 처리기는 Python 엔진에서 사용할 수 있지만, 문서상 주로 필드가 너무 많은 행을 다루는 범위가 있습니다. 엔진 변경은 원인 확인을 대신하는 만능 처방이 아니라 파일 규칙과 기능 요구가 맞을 때 선택하는 단계입니다.
제가 따르는 판단 순서
저라면 예외 종류를 확인한 뒤 헤더, 정상 행, 오류 행을 확보합니다. 이어서 구분자와 예상 열 수를 비교하고, 값 안의 구분자·닫히지 않은 따옴표·줄바꿈을 점검합니다. 필요한 sep, quotechar, quoting, escapechar를 파일 규칙에 맞춰 명시한 다음, 수정이 불가능한 행만 별도 보존할 수 있을 때 on_bad_lines 정책을 선택합니다. 마지막으로 전체 행 수와 제외 행을 검증합니다.
이 순서를 거치면 “일단 skip하고 보자”는 편리함 때문에 데이터 누락을 정상 처리로 오해하는 일을 줄일 수 있습니다. 공급자가 파일을 다시 만들 수 있다면 오류 행을 조용히 버리기보다 원본과 진단 결과를 전달해 재수집하는 편이 낫습니다.
정리
파이썬 pandas ParserError의 핵심 확인 대상은 인코딩 하나가 아니라 구분자, 열 수, 따옴표, 줄바꿈, 행 구조입니다. on_bad_lines='skip'은 오류를 해결하는 옵션이 아니라 데이터를 제외하는 정책이므로, 누락을 허용할 근거와 기록 절차가 있을 때만 사용해야 합니다. 원문과 오류 행을 보존하고 read_csv 설정을 파일 형식에 맞춰 조정한 뒤 남은 행과 빠진 행을 검증하는 것이 안전한 처리 순서입니다.