더블클릭은 '여는' 게 아니라 '해석하는' 겁니다
- 데이터
- CSV
- 일하는방식
- AI활용
들어가며 — 저장을 누르기 전까지는 멀쩡했습니다
개인적으로 쓰는 운동 기록을 구글 시트에 두고 있습니다. 체육관에서 기록하고, 집에서 CSV로 받아 엑셀로 열어 정리하고, 저장합니다. 늘 하던 일이에요.
그날도 똑같이 했습니다. 더블클릭으로 열고, 몇 칸 고치고, Ctrl+S. 그런데 다음에 다시 열어보니 칼럼명이 ?좎쭨 二쇱감 遺꾪븷이 되어 있었습니다.
“인코딩 문제겠거니” 했습니다. 흔한 일이니까요. 그런데 파일을 바이트 단위로 뜯어보니, 인코딩만 깨진 게 아니었습니다. 데이터가 죽어 있었어요. 피해는 세 겹이었습니다.
| 무슨 일이 | 얼마나 |
|---|---|
한글이 ?로 사라짐 (되돌릴 수 없음) | 398자 |
4-6, 2-3 같은 반복 범위가 날짜로 자동 변환 (4월 6일) | 624셀 |
| 쉼표까지 먹혀서 칼럼 두 개가 하나로 합쳐짐 | 표의 뼈대 붕괴 |
세 번째가 제일 무서웠습니다. 인코딩이 깨지면 “글자가 이상해진다”고만 생각했지, 표의 뼈대가 무너진다는 건 상상도 못 했거든요. 저는 그냥 파일을 열었다 저장했을 뿐입니다.
1. 더블클릭은 ‘열기’가 아니라 ‘해석’이었습니다
우리는 더블클릭을 아주 중립적인 행동이라고 여깁니다. 파일이 있고, 두 번 누르면, 그 안에 든 게 화면에 뜬다 — 그게 ‘열기’라고요. 그런데 여기엔 조용한 전제가 하나 숨어 있습니다. 파일이 자기가 어떻게 읽혀야 하는지를 알려준다는 전제요.
CSV는 그걸 안 알려줍니다.
.txt를 엑셀로 열면 마법사가 떠서 “인코딩을 뭐로 읽을까요?”라고 묻습니다. 그런데 .csv는 안 묻습니다. 확장자가 csv면 엑셀은 “이건 내 거”라고 판단하고, 시스템 기본값(한글 윈도우는 CP949)으로 그냥 읽어버려요. 구글 시트가 내보낸 파일은 UTF-8인데, 그렇다고 알려줄 방법이 파일 안에 없습니다.
자기 설명이 없는 파일을 열면, 도구는 추측합니다. 그러니까 더블클릭은 ‘열기’가 아니라 이것이었어요.
추측해서 해석하기 + 안 물어보고 자동으로 바꾸기.
인코딩을 추측하고(→ CP949로 오독), 한술 더 떠 4-6을 “4월 6일”이라고 알아서 바꿉니다. 쉼표가 먹힌 건 그 오독의 부작용이었어요. CP949는 한글을 두 바이트씩 끊어 읽는데, 짝이 안 맞으면 ? 하나로 뭉개면서 바로 옆의 쉼표까지 같이 삼켜버립니다. CSV에서 쉼표는 칼럼과 칼럼의 경계입니다. 경계가 사라지면, 그건 더 이상 표가 아니에요.
제가 뭘 잘못 눌렀냐면, 아무것도 안 눌렀습니다. 그냥 열었을 뿐입니다. 문제는 그 ‘열기’가 제 생각보다 훨씬 많은 일을 하고 있었다는 거예요.
2. 죽은 건 연 순간이 아니라, 저장한 순간이었습니다
여기가 이 이야기의 핵심입니다. 화면에 ?좎쭨이 떴을 때, 파일은 아직 안 죽어 있었습니다.
깨져 보인 건 파일이 깨진 게 아니라, 읽는 방식이 틀린 것이었어요. 원본은 디스크에 UTF-8 그대로 멀쩡히 있었고, 엑셀이 그걸 CP949라고 잘못 읽어 화면에 이상하게 그렸을 뿐입니다. 그 순간 창을 그냥 닫았으면, 파일은 아무 일 없었습니다.
죽인 건 저장이었습니다. 저장은 잘못 읽은 상태를 진짜로 만들어 원본에 덮어씁니다. 실제로 깨진 파일 안에는 엑셀이 새로 써넣은 “월/일” 글자가 CP949 바이트로 박혀 있었어요. 잘못 읽고, 저장할 때 그 오독을 사실로 확정한 겁니다.
저는 화면을 보고 이렇게 생각했습니다. “이미 깨졌네, 고쳐서 저장해야지.” 그 생각이 사망 선고였습니다. 이미 깨진 줄 알았지만 사실 안 깨져 있었고, 제가 저장을 누르는 순간에 정말로 깨졌으니까요.
그래서 이 사고에서 진짜 배울 건 인코딩 지식이 아니었습니다. CP949가 뭔지 UTF-8이 뭔지 몰라도 됩니다. 필요한 건 딱 하나, 반사신경이에요.
화면이 이상하면, 저장을 누르지 않는다.
이건 코드를 몰라도 지킬 수 있고, 알아도 안 지키면 소용없습니다. 저는 인코딩은 몰랐지만, 그것보다 더 중요한 걸 놓쳤어요. 깨진 글자를 보고도 저장을 눌렀다는 것. 이상 신호는 이미 화면에 떠 있었는데, 저는 그걸 “고쳐야 할 상태”로 봤지 “멈춰야 할 신호”로 보지 못했습니다.
3. 그래서 배울 건 엑셀이 아니라, 여는 절차입니다
이 사고를 다시 안 당하는 방법은 엑셀을 더 잘 쓰는 게 아닙니다. 파일을 여는 절차 자체를 바꾸는 것이에요.
더블클릭 대신 데이터 > 텍스트/CSV 가져오기로 엽니다. 클릭이 두 번 더 늘지만, 그 두 번 사이에 도구가 추측하던 것을 내가 직접 정합니다. 인코딩을 UTF-8로 명시하고, 열 형식을 ‘텍스트’로 지정하는 거예요. 그러면 도구가 추측할 자리가 없어집니다. 추측이 없으면, 확정할 오독도 없습니다.
한 발 물러서서 보면, 이건 CSV만의 이야기가 아닙니다. 도구의 ‘기본 동작’은 대체로 ‘가장 편한 추측’에 맞춰져 있어요. 대부분의 경우 그 추측이 맞으니까 우리는 그걸 기본으로 씁니다. 문제는 틀렸을 때 아무 말이 없다는 거예요. 틀린 추측은 에러를 내지 않습니다. 그냥 조용히 틀린 결과를 남기고, 다음 저장이 그걸 굳힙니다.
일하는 방식을 바꾼다는 건 종종 이렇게 작습니다. 더 어려운 기능을 배우는 게 아니라, 도구가 알아서 하던 결정을 내 손으로 가져오는 것. 클릭 두 번의 차이지만, 그 두 번 안에서 데이터가 죽고 사는 게 갈립니다.
4. AI 시대엔 파일이 도구 사이를 계속 흐릅니다
예전 같으면 이건 엑셀 하나의 문제로 끝났을 겁니다. 그런데 요즘 데이터는 한자리에 머물지 않아요. 구글 시트에서 받아 CSV로 바꾸고, 엑셀로 고치고, 앱에 올리고, 다시 AI에게 넘깁니다. 파일 하나가 여러 도구 사이를 계속 건너다녀요.
그리고 매 경계마다 도구가 알아서 해석하고 알아서 바꿉니다. 넘어갈 때마다 조용한 추측이 한 번씩 끼어드는 거예요. 어디서 틀어졌는지는 대개 한참 뒤에야, 그것도 엉뚱한 자리에서 드러납니다. 데이터를 AI에게 줄 때 화려한 엑셀이 아니라 CSV로 줘야 하는 이유도, AI가 무엇을 보고 답했는지 따로 물어야 하는 이유도 결국 같은 자리에서 나옵니다. 도구는 ‘알아서’ 해주지만, 그 ‘알아서’가 무엇을 바꿨는지는 먼저 말해주지 않아요.
이번 일에는 반전이 하나 있었습니다. 숫자는 안 죽었어요. 무게나 횟수처럼 숫자로만 된 칸은 인코딩에도, 날짜 변환에도 걸리지 않고 그대로 살아남았습니다. 죽은 건 한글뿐이었어요. 그러니까 한글을 쓰는 우리는 남들보다 이 사고를 더 자주 당합니다. 영어권 블로그를 아무리 뒤져도 이 얘기가 잘 없는 이유예요. 우리 데이터라서, 우리가 스스로 챙겨야 합니다.
덤이 하나 더 있습니다. 복구하려고 제가 구매한 원본 프로그램 파일(.xlsx)을 열어봤더니, 거기 이미 4-6이 들어가야 할 칸에 46118(엑셀의 날짜 내부 번호)이 박혀 있었습니다. 만든 사람이 언젠가 엑셀을 거치면서 오염된 걸 팔고 있었던 거예요. 본인도 몰랐을 겁니다. 화면엔 표시 서식이 덮여 4-6으로 보이니까요. 원본이라고 안전한 게 아닙니다. 원본도 누군가의 도구를 거쳐 만들어지니까요.
5. 도구가 ‘알아서’ 해줄 때, 한 번 멈춥니다
더블클릭, 자동 서식, 스마트 붙여넣기, 자동 변환. 우리를 편하게 하려고 만든 이 ‘알아서’들은 대부분 맞습니다. 그러니까 우리가 믿고 쓰죠. 문제는 틀릴 때예요. 틀린 ‘알아서’는 경고음을 울리지 않습니다. 조용히 틀린 결과를 남기고, 다음 한 번의 확정 — 저장이든, 전송이든, 업로드든 — 이 그 오독을 되돌릴 수 없게 만듭니다.
그래서 데이터가 도구를 건너갈 때, 특히 화면이 조금이라도 이상할 때, 저장 버튼 앞에서 한 번 멈춥니다. 그리고 묻습니다.
“이거, 내가 연 게 맞나 — 아니면 도구가 자기 맘대로 해석한 건가?”
이 질문 하나면 됩니다. 인코딩을 몰라도, 코드를 못 읽어도, 확정하기 전에 한 번 멈출 줄만 알면 데이터는 안 죽어요. 깨진 건 언제나 되돌릴 수 있습니다 — 저장을 누르기 전까지는요.
본문의 사례는 필자가 개인적으로 쓰는 기록 파일에서 나온 것이며, 특정 기업·클라이언트와 무관합니다. 해석과 현장 관점은 박상훈의 견해입니다.