화면에서 00123이 보였다고 저장 파일에도 그대로 남았다고 단정하기는 어렵습니다. 가져오기 설정이 ID를 숫자로 바꾸거나, 줄바꿈이 다음 행으로 해석되거나, 내보낸 파일의 형식이 달라질 수 있습니다. 보존을 확인하려면 한 번 읽고 끝낼 것이 아니라, 쓰고 다시 읽은 값을 원본과 비교해야 합니다.
평범한 값보다 깨지기 쉬운 값을 넣었습니다.
| 행 | ID | 메모 | 의도 |
|---|---|---|---|
| 1 | 00123 | comma, kept | 앞자리 0·쉼표 |
| 2 | 000000000000000001 | quote “kept” | 긴 ID·따옴표 |
| 3 | A-03 | two↵lines | 필드 안 줄바꿈 |
| 4 | A-04 | =1+1 | 실행하지 않는 수식 후보 |
| 5 | 가-05 | 한글 식별자 | UTF-8 문자 |
모든 필드를 따옴표로 감싸고, 필드 안 따옴표는 두 번 쓰는 방식으로 인코딩했습니다. UTF-8 BOM을 포함했지만, BOM이 모든 프로그램의 가져오기 규칙을 통일하는 해답은 아닙니다.
실행 결과는 “5행 완전 일치”였습니다.
Node.js로 만든 CSV는 194바이트였고 SHA-256는 b0c2d6d4f9e2f2a699cb8450f0244de160c3dd5deea263e8f049032975db2a83입니다. 다시 파싱한 배열은 원본 배열과 문자열 단위로 일치했습니다. 앞의 다섯 ID, 쉼표, 따옴표, 줄바꿈, =1+1은 모두 그대로 복구되었습니다.
실제 파일에서는 세 번 비교합니다.
- 원본 파일의 복사본과 해시를 남깁니다.
- 가져오기 설정에서 ID·전화·우편번호 열을 문자열로 고정합니다.
- 내보낸 파일을 다시 열어 행 수·헤더·ID·줄바꿈을 대조합니다.
- 불일치가 있으면 원본을 고치지 말고 어느 변환 단계에서 생겼는지 줄여 재현합니다.
이 글의 재현 자료
전체 자료의 범위·실행 방법·주의사항은 재현 자료 안내에서 한번에 확인할 수 있습니다.
원문과 함께 읽기
파일이 맞아도 가져오기 설정에서 깨질 수 있습니다.
CSV는 셀의 자료형을 강제하는 형식이 아닙니다. 00123이 문자열이라는 정보는 파일 밖의 스키마나 가져오기 설정에서 제공해야 합니다. 스프레드시트가 자동으로 숫자로 판단하면 파일의 바이트는 멀쩡해도 화면에서는 123으로 보일 수 있습니다. 긴 번호는 지수 표기나 반올림으로 바뀐 뒤 다시 되돌릴 수 없습니다.
그래서 헤더를 봐서 ID·우편번호·전화번호처럼 계산하지 않는 열은 가져오기 시점에 문자열로 지정합니다. 숫자 처럼 보이는지가 아니라 계산 대상인지가 기준입니다.
왕복 합격 기준을 수치로 적습니다.
| 검사 | 합격 기준 |
|---|---|
| 행 수 | 헤더 제외 원본과 일치 |
| 열 순서 | 헤더 이름과 순서 일치 |
| 식별자 | 문자열로 전부 일치 |
| 줄바꿈·따옴표 | 원문의 문자 위치 보존 |
| 문자 인코딩 | 한글·특수문자 손실 없음 |
| 수식 후보 | 문자열로 보존되었음을 표시 |
파일 전체의 SHA-256는 빠른 변경 감지에 유용하지만, 어느 셀이 달라졌는지는 알려 주지 않습니다. 해시가 다르면 행 ID를 기준으로 범위를 줄이고, 값과 원문 표현을 필드 단위로 비교합니다.
수식 후보 검사는 왕복 보존과 다른 단계입니다.
=1+1이 그대로 돌아왔다는 것은 문자열 보존 합격입니다. 이 값을 스프레드시트에서 열어도 안전하다는 결론은 아닙니다. 파일을 열 제품, 해당 열의 용도, 내보내기 방식을 확인한 뒤 조직의 보안 기준에 맞게 처리해야 합니다. 왕복 테스트는 값을 멋대로 바꾸지 않았다는 것까지를 증명합니다.
