💔 손상된 파일

사례	무슨 일이 일어나는가	어떻게 하면 되는가
예외는 발생하는데 사용자에게는 아무것도 전달되지 않는다	`try / catch` 로 뭉뚱그려 삼키고 빈 결과나 500 만 반환하는 구현이 매우 흔합니다. 로그에도 실패했다는 것밖에 남지 않습니다.	어느 파일의 몇 번째 줄에서 무엇이 일어났는지를 사용자에게 돌려줍니다. 깨진 파일을 넣었을 때의 화면을 실제로 보고, 거기서 다음 행동을 취할 수 있는지로 판단하세요.
중간에 잘린 파일이 크기 검사를 통과한다	크기 상한보다 작으면 검사는 통과합니다. 너무 작은 쪽을 보지 않기 때문에 0 바이트나 수십 바이트 파일도 그대로 저장됩니다.	하한도 둡니다. 더해서 형식별 종단을 확인합니다. PDF 라면 끝의 `%%EOF`, ZIP 이라면 End of Central Directory (`50 4B 05 06`) 유무로 절단을 감지할 수 있습니다.
헤더만 보고 내용을 믿어 버린다	매직 바이트가 올바라도 그 뒤가 깨져 있을 수 있습니다. `header-corrupted` 파일은 그 반대로, 내용은 읽히는데 선두만 다른 형태입니다.	검사는 입구뿐 아니라 실제로 읽는 처리에서도 합니다. 이미지라면 실제로 디코딩해 보고, ZIP 이라면 목록을 뽑아 보는 것이 확실합니다.
열 수가 맞지 않는 CSV 가 조용히 통과한다	많은 CSV 파서는 행마다 배열을 돌려줄 뿐 열 수가 맞는지는 검사하지 않습니다. 모자란 열은 `null` 이 되어 그대로 저장됩니다.	헤더 행의 열 수를 기준으로 한 행씩 대조해 행 번호와 함께 거부합니다. 구분자나 따옴표 문제를 먼저 없애고 싶다면 CSV 클리너로 정리한 뒤 읽는 편이 빠릅니다.

여기서 상정하는 것은 사고에 의한 손상입니다. 의도적으로 만들어진 ZIP 폭탄, 극단적으로 중첩된 XML, 압축 해제 후 크기가 거대한 파일 같은 공격용 입력은 포함되어 있지 않습니다. 그런 것들은 전개 전에 크기와 깊이 상한으로 막는 설계가 필요합니다.