1. 이름이 같은 파일과 내용이 같은 파일은 다르다
다운로드한 설치 파일의 이름과 용량이 안내 페이지와 같으면 제대로 받았다고 생각하기 쉽습니다. 그러나 이름은 바꿀 수 있고, 같은 용량의 파일도 내용은 다를 수 있습니다. 반대로 사진 파일을 다른 이름으로 복사했다고 해서 사진 안의 바이트가 반드시 바뀌는 것은 아닙니다. 이때 파일 내용을 정해진 계산에 넣어 짧은 값으로 나타내는 해시가 비교에 도움을 줍니다. 확인하려는 질문은 파일 이름이 그럴듯한지가 아니라, 내가 받은 바이트가 믿을 만한 기준과 일치하는지입니다. 백업 파일을 다른 저장 장치로 옮겼을 때도 같은 질문을 할 수 있습니다.
SHA-256은 입력에서 256비트의 해시값을 만드는 알고리즘입니다. 이를 흔히 16진수 64자리로 표시하는데, 16진수 한 자리가 4비트를 나타내기 때문입니다. 파일이 커져도 결과의 길이가 파일 크기에 비례해 늘지는 않습니다. 같은 바이트에 같은 알고리즘을 적용하면 같은 결과를 얻습니다. 다만 유한한 길이의 값에 모든 입력을 담으므로, 서로 다른 입력이 같은 값을 갖는 충돌은 원리상 존재합니다. 실용적인 비교에 쓰인다는 말과 수학적으로 모든 파일에 유일한 이름을 붙인다는 말은 구별해야 합니다. RFC 6234는 SHA-256을 포함한 해시 계산과 시험 자료를 제공합니다.
2. 해시는 암호화나 파일의 축소 복사본이 아니다
해시값을 안다고 해서 원래 문서나 사진을 복원하는 해독 버튼이 생기지는 않습니다. 암호화는 적절한 키로 원문을 되찾도록 설계하지만, 암호학적 해시는 원문을 복원하는 저장 형식이 아닙니다. 그렇다고 해시만 공개하면 모든 입력이 비밀로 보호된다는 뜻도 아닙니다. 가능한 입력이 몇 개뿐이라면 각각의 해시를 계산해 비교할 수 있습니다. 따라서 파일 확인용 SHA-256의 설명을 비밀번호를 그대로 해시해서 저장해도 충분하다는 조언으로 확대하면 안 됩니다. 무결성 확인, 비밀 유지, 비밀번호 보관은 요구하는 조건이 서로 다른 작업입니다.
파일 전체를 계산한다면 화면에 보이는 글자만 비교하는 것도 아닙니다. 같은 문장처럼 보여도 줄바꿈 방식이나 문자 인코딩, 문서 내부의 메타데이터가 다르면 바이트가 달라질 수 있습니다. 압축 파일을 푼 뒤 나온 파일은 원래 압축 파일과 다른 비교 대상입니다. 글자를 정규화하거나 줄바꿈을 바꾸고 계산하면 그 변환을 거친 자료의 해시를 얻습니다. 배포자가 원본 압축 파일의 값을 제공했다면, 먼저 받은 압축 파일 자체와 비교해야 합니다. 이 구분은 기존 Unicode·UTF-8 글에서 다룬 표시와 바이트의 차이를 실제 파일 검증에 적용하는 예입니다.
3. 내려받은 파일은 같은 알고리즘과 기준값으로 비교한다
검증 전에 제작자의 공식 배포 안내에서 대상 버전, 운영체제, 파일 이름과 해시 알고리즘을 함께 확인합니다. 서로 다른 운영체제용 설치 파일이나 다른 버전의 값은 비교 기준이 될 수 없습니다. PowerShell에서는 Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256으로 로컬 파일을 읽어 계산할 수 있습니다. 이 명령은 해당 경로의 내용을 실행하는 명령이 아닙니다. Microsoft 공식 문서는 파일 내용으로 값을 계산하며 이름 변경만으로는 값이 달라지지 않는다고 설명합니다. 파일 이름과 경로는 실제 받은 파일에 맞춰 바꾸고, 계산하는 동안에는 파일을 수정하지 않습니다.
출력에서는 Hash 항목의 전체 64자리를 배포자가 공개한 SHA-256 값과 대조합니다. 앞이나 뒤 몇 자리만 같다고 전체가 일치한다고 판단하지 않습니다. 16진수의 영문 대문자와 소문자는 같은 수를 나타내지만, 다른 문자가 끼었거나 자릿수가 부족하면 먼저 복사한 값을 확인합니다. 일치한다는 결과는 신뢰한 기준값과 받은 바이트의 일관성을 뒷받침합니다. 문서의 사실관계, 프로그램의 품질이나 악성 동작까지 검사한 결과는 아닙니다. 기준 파일 자체에 문제가 있으면 그 파일과 똑같은 사본도 같은 해시를 갖습니다. 계산이 성공했다는 사실과 파일을 사용해도 되는지는 별도로 판단해야 합니다.
4. 불일치는 원인 조사 신호이며 공격의 확정 증거는 아니다
예를 들어 어제 받은 배포 파일을 오늘의 안내에 나온 값과 비교했더니 다르다고 가정해 봅시다. 이는 실제 사고 기록이 아닌 설명용 사례입니다. 먼저 안내가 같은 버전을 가리키는지, 다른 기기용 파일을 받지는 않았는지, 다운로드가 끝나기 전에 계산하지는 않았는지 확인합니다. 압축 파일 대신 풀어 놓은 파일을 계산했거나, 편집기가 문서를 다시 저장했을 수도 있습니다. 이처럼 비교 대상이 바뀐 경우와 전송·저장 과정에서 내용이 변한 경우를 나누어야 합니다. 값이 다르다는 사실만으로 누가 언제 무엇을 바꾸었는지는 알아낼 수 없습니다.
불일치한 설치 파일은 바로 실행해서 확인하지 말고, 공식 배포 안내와 기준값을 다시 확인한 뒤 새로 받은 파일을 비교합니다. 계속 다르면 배포자의 정정 안내나 지원 경로를 확인하고 결과를 남기는 편이 좋습니다. 기록에는 확인 시각, 출처 주소, 파일 버전, 알고리즘과 계산값을 함께 적습니다. 반복 계산 결과가 같다면 현재 로컬 파일을 같은 방식으로 읽었다는 단서가 되지만, 그 사실이 배포자가 게시한 값의 오류나 배포 경로의 문제까지 해결하지는 않습니다. 기대한 값으로 기준 기록을 덮어쓰면 이후에 변화가 있었는지 판단할 근거를 잃습니다.
5. 기준값을 믿는 근거와 전자서명의 역할
공격자가 파일과 함께 안내된 해시값도 바꿀 수 있다면, 바뀐 파일의 해시를 계산해 새 기준으로 적어 놓을 수 있습니다. NIST SP 800-175B는 키나 서명 없이 해시만 사용하는 경우 이런 한계를 설명합니다. 공식 주소의 HTTPS 페이지에서 값을 얻는 것은 출처와 전송 경로를 확인하는 데 도움이 되지만, 배포 서버 자체가 침해된 경우까지 없애 주는 보장은 아닙니다. 중요한 것은 해시 문자열이 길어 보이는지가 아니라 그 기준을 어디에서 어떤 신뢰 절차로 얻었는지입니다. 같은 화면에서 복사한 두 값이 서로 맞는다는 사실만으로 제작자의 신원이 확인되지는 않습니다.
전자서명은 신뢰할 수 있게 확보한 공개키 등으로 서명과 자료의 관계를 검증하도록 합니다. 배포자가 제공하는 서명 확인 절차가 있다면 키의 소유자와 지문을 확인하는 방법까지 공식 안내를 따릅니다. 출처가 불분명한 파일 옆에서 처음 본 공개키를 그대로 신뢰하면 신뢰의 출발점이 해결되지 않습니다. 공유 비밀키를 쓰는 HMAC도 일반 해시와 다른 인증 도구이지만, 모든 다운로드에 임의로 덧붙여 해결하는 기능은 아닙니다. 서명이 유효해도 프로그램에 결함이 없거나 문서 내용이 참이라는 결론은 나오지 않습니다. 바이트의 일치, 출처의 확인, 내용의 평가는 서로 연결되지만 각각 확인할 근거가 필요합니다.
6. 백업과 협업에서는 비교 범위까지 기록한다
개인 사진 백업에서는 원본 파일의 SHA-256을 저장해 두고 복사본과 비교하면 이동 과정의 변화 여부를 확인하는 데 도움이 됩니다. 이때 기준 목록도 원본과 함께 사라지거나 덮어써지지 않도록 보관합니다. 사진 관리 프로그램이 회전 정보나 촬영 메타데이터를 다시 기록했다면 보이는 사진이 비슷해도 파일 해시는 달라질 수 있습니다. 따라서 바이트 단위 보존이 목적인지, 편집한 사진의 의미가 같은지부터 구분합니다. 폴더 전체를 확인하려면 파일 하나의 해시로 끝내지 않고 포함할 파일 목록과 상대 경로, 각 파일의 값을 함께 관리해야 합니다.
협업 문서 검토에서도 해시는 검토한 판본을 고정하는 표식이 될 수 있습니다. 그러나 해시가 일치한다는 검사는 누군가 실제로 전문을 읽었거나 번역을 대조했다는 증거를 대신하지 않습니다. 무엇을 언제 어떤 방법으로 검토했는지 기록한 뒤, 그 기록을 해당 파일의 값과 연결해야 의미가 있습니다. 이 글의 그림은 바이트 비교, 기준값의 출처, 검증 범위를 정리한 자체 설명용 도식이며 실제 측정 결과나 인증서가 아닙니다. 파일을 확인할 때는 대상과 알고리즘, 기준의 출처, 결과로 말할 수 있는 범위를 차례로 남겨 보세요. 이렇게 하면 일치와 불일치를 과장하지 않으면서 다음 사람이 같은 절차를 재현할 수 있습니다.