스프레드시트

CSV를 열었는데 열이 밀릴 때, 쉼표와 따옴표부터 확인하는 방법

CSV 데이터를 가져왔을 때 주소나 메모 열의 쉼표 때문에 열 개수가 달라지는 문제를 원본 구분자, 따옴표 처리, 내보내기 형식으로 구분하고 검증하는 방법입니다.

발행 2026년 10월 28일CSV 열 밀림 · CSV 쉼표 오류 · CSV 따옴표 처리

업무용 모니터의 CSV 원문과 스프레드시트 표에서 쉼표 때문에 어긋난 열을 돋보기로 비교하는 장면

CSV를 엑셀이나 다른 스프레드시트로 열었는데 어떤 행부터 주소가 옆 열로 넘어가거나 메모 내용이 여러 칸에 나뉘는 일이 있습니다. 파일이 완전히 깨졌다기보다 데이터 안의 쉼표를 열 구분자로 잘못 해석했거나, 내보내기 과정에서 따옴표 처리가 누락된 경우일 수 있습니다.

이 문제는 열 너비를 늘리거나 셀을 합쳐 해결할 일이 아닙니다. 원본 텍스트 한 행의 필드 경계가 어디인지와 가져오기 프로그램이 그 경계를 어떻게 해석하는지 비교해야 합니다.

모든 행이 밀리는지, 특정 행만 밀리는지부터 구분

처음 몇 행부터 열이 일관되게 어긋난다면 가져오기에서 선택한 구분 기호가 실제 파일과 다를 수 있습니다. 예를 들어 파일이 세미콜론으로 값을 구분하는데 프로그램이 쉼표 기준으로 읽으면 한 줄이 한 셀에 들어가거나 열 구조가 예상과 달라질 수 있습니다.

반면 대부분의 행은 정상인데 주소에 쉼표가 들어간 행, 메모에 줄바꿈이 있는 행만 밀린다면 해당 필드의 인용 부호 처리를 확인할 차례입니다.

표에서 보이는 열 개수만 세지 말고, 원본 CSV를 텍스트 편집기로 열어 문제 행과 정상 행을 나란히 살펴보세요. 자동 변환된 파일을 원본 위에 다시 저장하지 않고 복사본을 사용하는 것이 안전합니다.

주소 속 쉼표는 열 구분자와 구별돼야 한다

예를 들어 열이 이름, 주소, 상태 세 개라고 가정해 봅니다.

name,address,status
민지,서울, 강남구,완료

두 번째 줄에 있는 쉼표를 전부 열 경계로 보면 데이터는 네 조각이 됩니다. 원래 의도가 ‘서울, 강남구’라는 하나의 주소라면 CSV 원문은 다음처럼 표현돼야 합니다.

name,address,status
민지,"서울, 강남구",완료

이렇게 쉼표가 포함된 필드 전체를 큰따옴표로 감싸야 해당 쉼표를 필드 내부 글자로 취급할 수 있습니다. CSV의 대표적인 작성 관례는 RFC 4180에서 확인할 수 있습니다.

여기서 중요한 구분은 따옴표가 데이터 내용인지, 필드의 시작과 끝을 알리는 표기인지입니다. 텍스트 편집기에서 원문을 확인하지 않으면 열을 오른쪽으로 끌어오는 작업으로 문제를 가리게 됩니다.

메모 안에 큰따옴표가 있다면 두 번 써야 할 수 있다

CSV의 인용된 필드 안에서 문자 그대로 큰따옴표를 표현할 때는 큰따옴표를 두 개 연속 사용하는 방식이 일반적입니다.

name,note,status
민지,"고객이 ""빠른 배송"" 요청",진행

위에서 메모 필드의 실제 내용은 고객이 “빠른 배송” 요청입니다. 따옴표를 임의로 지우거나 한쪽만 추가하면 가져오기 프로그램에 따라 뒤쪽 열을 잘못 해석할 수 있습니다.

메모에 줄바꿈 자체가 들어 있는 경우에도 주의가 필요합니다. 인용된 필드 안의 줄바꿈은 같은 데이터 항목에 속할 수 있어 텍스트 파일의 한 줄이 반드시 스프레드시트의 한 행과 일치하지는 않습니다. 단순히 줄바꿈 개수만 세어 누락 행을 판단해서는 안 되는 이유입니다.

원본이 잘못됐는지 가져오기 설정이 잘못됐는지

이 둘은 복구 방식이 다릅니다.

원본을 열어 본 결과	다음 행동
쉼표가 포함된 값이 따옴표로 올바르게 감싸져 있음	가져오기 도구에서 구분자·텍스트 한정자 설정을 확인
쉼표가 포함된 값이 따옴표 없이 출력됨	원천 시스템의 CSV 내보내기 형식 수정 또는 재추출 요청
전체 행이 한 칸으로 들어감	실제 구분자가 쉼표·세미콜론·탭 중 무엇인지 확인
한글이 깨지지만 열 경계는 정상	열 밀림과 분리해 문자 인코딩을 점검

정상적인 원본이라면 가져오기 화면에서 열 미리보기, 구분자, 인용 부호 처리를 맞추고 작은 범위로 결과를 검증합니다. 원본 자체에서 인용 부호가 빠져 있다면 프로그램 설정만으로 모든 행의 의도한 열 경계를 완벽하게 추론할 수 없습니다.

특히 자유 입력 메모에 쉼표가 여러 번 들어간 파일은 무조건 오른쪽 열을 합치는 식의 자동 수정으로 처리하면 정상 행까지 손상될 수 있습니다. 가능하면 생성 시스템에서 올바른 CSV를 다시 내보내는 것이 우선입니다.

행 수만 맞아도 데이터가 틀릴 수 있다

열 밀림을 고친 뒤에는 몇 가지 기준을 별도로 점검해야 합니다.

헤더의 열 개수와 가져온 데이터 구조가 같은가?
쉼표가 들어간 주소·메모의 앞뒤 글자가 잘리지 않았는가?
큰따옴표가 포함된 필드가 원래 문구로 복원됐는가?
문제 행의 상태값과 식별번호가 원래 열에 들어갔는가?

작은 샘플 하나만 확인하지 말고 일반 행, 쉼표 포함 행, 큰따옴표 포함 행, 줄바꿈 포함 행을 각각 한 건씩 확인합니다. 다만 CSV의 줄 수와 레코드 수는 인용 필드 안의 줄바꿈 때문에 다를 수 있으므로 CSV 형식을 이해하는 파서의 레코드 수를 기준으로 비교해야 합니다.

또한 CSV를 다시 저장할 때 스프레드시트가 코드나 날짜의 데이터 형식을 자동으로 바꾸는 문제는 별개입니다. 고객코드의 앞자리 0이 사라지는 현상은 CSV의 식별번호를 문자 그대로 보존하는 방법을 참고해 열별 형식을 확인하세요.

반복 업무라면 수정보다 내보내기 규칙을 고정

매달 같은 시스템에서 받은 CSV가 같은 지점에서 밀린다면, 수동으로 셀을 고치는 것이 해결책이 되기 어렵습니다. 내보내기 시스템에서 필드 인용 규칙과 인코딩, 구분자를 일정하게 유지하고, 가져오는 쪽에서는 정해진 템플릿과 확인용 샘플을 사용하도록 하는 편이 재작업을 줄입니다.

검증을 통과한 원본 파일은 별도로 보관하고 변환된 작업 파일과 구분하세요. 그래야 다음 달에 숫자가 달라졌을 때 원천 데이터의 변화인지 가져오기 과정의 오류인지 되짚을 수 있습니다.

CSV 열 밀림에서 중요한 것은 보기 좋게 열을 다시 맞추는 속도가 아닙니다. 어떤 쉼표가 값의 일부이고 어떤 쉼표가 경계인지를 원본 수준에서 확인해야 후속 집계와 보고서까지 신뢰할 수 있습니다.