크롤링은 분명 잘 됐는데, 막상 CSV 파일을 열어보면 한글이 깨져서 당황하는 경우가 자주 있습니다. 처음에는 수집이 실패한 줄 알았는데, 데이터를 다시 확인해 보니 문제가 크롤링이 아니라 저장 방식에 있었습니다. 이번 글에서는 실제로 겪기 쉬운 한글 깨짐 문제를 어떻게 확인하고, 어떤 방식으로 저장하면 엑셀에서도 자연스럽게 열리는지 차근차근 정리해보겠습니다.
수집은 됐는데 결과물이 망가지는 이유
크롤링을 하다 보면 requests나 BeautifulSoup로 데이터를 잘 모아놓고도 마지막 저장 단계에서 문제가 생기는 일이 많습니다. 특히 CSV 파일은 가볍고 다루기 편해서 자주 쓰는데, 한글이 들어간 순간부터 이야기가 달라집니다. 파이썬 안에서는 멀쩡하게 보이는데 엑셀로 열었더니 글자가 이상하게 보이거나, 물음표로 바뀌거나, 아예 읽을 수 없는 문자처럼 출력되는 경우가 대표적입니다.
이럴 때 많은 분들이 크롤링 코드부터 다시 의심합니다. 하지만 실제 원인은 수집 단계보다 저장 단계에 있는 경우가 많습니다. 즉, 데이터는 이미 정상적으로 들어왔는데 파일을 어떤 인코딩으로 저장했느냐에 따라 결과가 달라지는 것입니다. 한글은 영어보다 문자 표현 방식이 복잡해서, 저장할 때와 열 때 사용하는 인코딩 방식이 맞지 않으면 금방 깨집니다.
예를 들어 파이썬에서는 기본적으로 UTF-8 환경을 많이 사용합니다. 그런데 사용자가 파일을 여는 환경이 엑셀이라면 이야기가 달라집니다. 엑셀은 운영체제나 버전에 따라 UTF-8을 바로 잘 읽지 못하는 경우가 있고, 특히 CSV 파일은 더 민감하게 반응합니다. 그래서 “파일은 잘 저장됐는데 엑셀에서만 깨진다”라는 현상이 자주 생깁니다. 이 문제를 이해하면 해결은 생각보다 단순합니다. 핵심은 데이터를 어디까지 쓸 것인지, 그리고 최종적으로 어떤 프로그램에서 열 것인지를 같이 고려하는 것입니다.
UTF-8-sig와 cp949를 구분해서 저장하는 방법
한글 CSV 저장 문제를 해결할 때 가장 많이 쓰는 방식은 UTF-8-sig와 cp949를 구분해서 사용하는 것입니다. 둘 다 한글을 다룰 수 있지만, 목적이 조금 다릅니다. UTF-8-sig는 웹, 파이썬, 다양한 프로그램 간 호환성이 좋고, 엑셀에서도 비교적 안정적으로 열릴 가능성이 높습니다. 반면 cp949는 윈도우 환경, 특히 한국어 엑셀과의 호환성을 고려할 때 여전히 유용한 방식입니다.
실무에서는 우선 UTF-8-sig로 저장해보고, 상대방이 윈도우 엑셀 중심으로만 파일을 쓴다면 cp949도 함께 고려하는 방식이 안전합니다. 중요한 것은 무조건 하나만 외우는 것이 아니라, 왜 이 방식을 쓰는지 알고 선택하는 것입니다.
아래는 가장 기본적인 예시입니다.
import pandas as pd
data = {
"상품명": ["텀블러", "머그컵", "보온병"],
"리뷰": ["디자인이 깔끔합니다", "생각보다 가볍습니다", "보온이 오래갑니다"]
}
df = pd.DataFrame(data)
# 엑셀 호환성을 고려한 저장
df.to_csv("review_utf8sig.csv", index=False, encoding="utf-8-sig")
# 윈도우 환경에서 필요할 때 사용하는 저장 방식
df.to_csv("review_cp949.csv", index=False, encoding="cp949")
여기서 중요한 부분은 encoding 값입니다. utf-8만 넣었을 때는 일부 환경에서 엑셀이 인코딩을 제대로 인식하지 못할 수 있습니다. 그래서 utf-8-sig를 쓰면 앞부분에 BOM이 포함되어 엑셀이 UTF-8 파일임을 더 잘 인식하게 됩니다. 반대로 cp949는 오래된 윈도우 기반 환경에서 잘 열리는 장점이 있지만, 웹이나 다른 시스템으로 파일을 넘길 때는 오히려 불편할 수 있습니다.
읽을 때도 마찬가지입니다. 저장은 cp949로 했는데 읽을 때 utf-8로 읽으면 오류가 날 수 있습니다.
import pandas as pd
df = pd.read_csv("review_cp949.csv", encoding="cp949")
print(df.head())
또 하나 자주 만나는 문제가 Unicode 관련 오류입니다. 예를 들어 UnicodeEncodeError나 UnicodeDecodeError가 뜬다면, 거의 대부분은 파일 인코딩과 읽기/쓰기 인코딩이 맞지 않는 상황입니다. 이럴 때는 데이터가 틀린 것이 아니라 문자 해석 방식이 맞지 않는 것이므로, 당황하지 말고 저장할 때와 읽을 때의 인코딩을 먼저 확인하면 됩니다.
엑셀까지 고려하면 저장 방식이 달라집니다
크롤링 작업은 단순히 데이터를 가져오는 데서 끝나지 않습니다. 실제로는 그 결과물을 사람이 열어보고, 정리하고, 보고서에 붙이고, 다시 공유하는 과정까지 이어집니다. 그래서 저장 결과가 깨지지 않도록 만드는 일은 생각보다 중요합니다. 오히려 이 부분이 제대로 되어야 크롤링 결과가 실무에서 바로 쓸 수 있는 형태가 됩니다.
제가 이 문제를 겪으면서 가장 크게 느낀 점은, “수집 성공”과 “활용 가능”은 다르다는 것이었습니다. 코드가 잘 돌아가는 것만으로는 충분하지 않았고, 저장된 파일이 상대방 컴퓨터에서도 자연스럽게 열려야 진짜 끝이었습니다. 그런 점에서 UTF-8-sig는 가장 먼저 시도해볼 만한 안전한 선택지입니다. 웹과 파이썬 환경에서도 무난하고, 엑셀에서도 깨짐이 줄어들기 때문입니다. 다만 특정 윈도우 환경에서는 cp949가 더 잘 맞을 수 있으니, 최종 사용 환경이 명확하다면 그쪽에 맞춰 저장하는 것이 더 실용적입니다.
정리하면 이렇게 생각하면 편합니다. 파이썬 안에서만 쓰거나 다양한 시스템과 연결할 예정이라면 UTF-8-sig를 우선 고려합니다. 반대로 한국어 윈도우 엑셀 사용자에게 바로 전달할 파일이라면 cp949도 충분히 좋은 선택입니다. 그리고 Unicode 오류가 발생했을 때는 코드 전체를 뜯어고치기보다, 저장과 읽기에서 사용한 인코딩 값을 먼저 확인하는 습관이 중요합니다. 크롤링 결과가 마지막 저장 단계에서 망가지지 않도록, 이제는 수집 코드만큼 저장 코드도 꼼꼼히 보는 것이 좋습니다.