파일을 받을 때 옆에 붙어 있는 긴 영문·숫자 문자열을 보신 적 있을 겁니다. SHA-256 같은 이름이 붙어 있는 그것입니다. 이 글은 그게 무엇인지, 내 컴퓨터에서 어떤 명령으로 확인하는지, 값이 다르게 나오면 무엇부터 해야 하는지를 맥과 윈도우 기준으로 순서대로 정리합니다. 아래 예시의 값은 이 글을 쓰면서 맥 터미널에서 직접 계산한 결과입니다.
해시는 파일의 지문 같은 값입니다
해시는 파일 내용을 넣으면 정해진 길이의 짧은 값이 나오는 계산입니다. 같은 파일이면 항상 같은 값이 나오고, 한 글자만 달라도 완전히 다른 값이 나옵니다. 마이크로소프트 공식 문서도 두 파일의 해시값이 같으면 내용도 같다고 설명합니다.
그래서 배포하는 쪽이 원본의 해시값을 함께 공개하면, 받는 쪽은 자기 파일을 계산해 비교하는 것만으로 내용이 같은지 확인할 수 있습니다. 파일을 열어 보지 않고도 됩니다.
한 글자만 달라도 값이 완전히 달라지는 것을 직접 봅니다
말로만 들으면 와닿지 않으니 아주 작은 파일 두 개로 비교해 보겠습니다. 첫 번째 파일 a.txt에는 hello를, 두 번째 파일 b.txt에는 마지막 글자만 바꾼 hellp를 넣었습니다. 두 파일 모두 5바이트로 크기는 같습니다. 맥 터미널에서 shasum -a 256 a.txt b.txt를 실행한 결과입니다.
| 파일 | 내용 | 크기 | SHA-256 값 |
|---|---|---|---|
| a.txt | hello | 5바이트 | 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 |
| b.txt | hellp | 5바이트 | fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7 |
| c.txt | hello + 줄바꿈 한 번 | 6바이트 | 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 |
세 값은 첫 글자부터 전혀 닮지 않았습니다. 눈에 보이지 않는 줄바꿈 하나가 더 붙었을 뿐인 c.txt도 완전히 다른 값입니다. 이 성질 때문에 “거의 같은 파일”이 통과되는 일이 없고, 값이 맞으면 내용이 같다고 믿을 수 있습니다. 반대로 값이 다르다고 해서 얼마나 다른지는 알 수 없습니다. 한 바이트가 빠진 것인지 전혀 다른 파일인지는 해시만으로 구분되지 않습니다.
왜 필요한가: 눈으로는 구분할 수 없는 두 가지
- 전송 중 깨짐 — 큰 파일을 받다 보면 일부가 손상될 수 있습니다. 열어 보기 전에는 모릅니다.
- 내용이 바뀐 파일 — 같은 이름과 크기로 다른 내용을 올려 둔 경우입니다. 위 표처럼 크기가 같아도 내용이 다를 수 있어 크기 비교로는 못 잡습니다.
특히 AI 모델처럼 용량이 크고 안을 들여다보기 어려운 파일일수록 이 확인이 중요합니다. 잘못된 파일을 받아도 대체로 그냥 실행되고, 결과가 이상해진 뒤에야 눈치채게 됩니다.
내 컴퓨터에서 확인하는 방법
운영체제마다 명령이 다릅니다. 아래 세 가지 중 쓰는 환경에 맞는 것 하나만 있으면 됩니다.
| 환경 | 명령 | 비고 |
|---|---|---|
| 맥(터미널) | shasum -a 256 파일이름 | 맥 기본 도구입니다. -a 뒤 숫자가 알고리즘이고, 생략하면 SHA-1이 계산됩니다. |
| 윈도우(PowerShell) | Get-FileHash 파일이름 -Algorithm SHA256 | 마이크로소프트 문서 기준으로 알고리즘을 생략하면 SHA256이 기본입니다. |
| 윈도우(명령 프롬프트) | certutil -hashfile 파일이름 SHA256 | PowerShell을 쓰지 않을 때 쓰는 방법입니다. 공식 문서에 SHA256 외에 SHA1·SHA384·SHA512·MD5 등이 적혀 있습니다. |
맥에서 알고리즘을 빼고 shasum 파일이름만 치면 SHA-1 값이 나옵니다. 실제로 a.txt에 그렇게 했더니 aaf4c61d…로 시작하는 40자리 값이 나왔습니다. 배포 페이지가 SHA-256 값을 적어 두었다면 길이부터 다릅니다. SHA-256 값은 영문·숫자 64자리입니다. 값의 자릿수가 다르면 알고리즘이 다른 것이니 비교하기 전에 알고리즘부터 맞춥니다.
값을 눈으로 비교하지 않는 방법
64자리를 눈으로 맞춰 보는 것은 실수하기 쉽습니다. 앞 여섯 글자만 같고 뒤가 다른 경우를 놓치기 때문입니다. 배포 페이지에 값이 SHA256SUMS 같은 목록 파일로 제공된다면 컴퓨터가 대신 비교하게 하는 편이 안전합니다. 맥에서는 -c 옵션을 씁니다.
- 목록 파일에
해시값 파일이름형식으로 한 줄이 들어 있는지 확인합니다. 값과 파일 이름 사이는 공백 두 칸입니다. - 같은 폴더에서
shasum -a 256 -c 목록파일이름을 실행합니다. - 화면에
파일이름: OK가 나오면 일치한 것입니다.
직접 시험한 결과, a.txt의 정상 값을 적은 목록으로는 a.txt: OK가 나왔습니다. 같은 값을 b.txt에 적용하자 b.txt: FAILED와 함께 1 computed checksum did NOT match 경고가 나오고 종료 코드가 1로 끝났습니다.
윈도우에서 PowerShell을 쓴다면 Get-FileHash 결과의 Hash 줄을 복사해 배포 페이지의 값과 나란히 붙여 넣고 비교하는 방법이 가장 단순합니다. 이때 대소문자는 표기 방식일 뿐이어서 달라도 같은 값입니다. 공식 문서 예시는 대문자로, 맥은 소문자로 출력됩니다.
값이 다르게 나왔을 때 순서대로 할 일
| 순서 | 할 일 | 이유 |
|---|---|---|
| 1 | 알고리즘과 자릿수를 다시 맞춘다 | SHA-1(40자리)과 SHA-256(64자리)을 비교한 경우가 가장 흔한 착오입니다. |
| 2 | 같은 파일을 다시 받아 한 번 더 계산한다 | 전송 중 손상이었다면 다시 받은 파일에서는 값이 맞습니다. |
| 3 | 내려받은 버전과 해시 목록의 버전이 같은지 본다 | 새 버전이 올라왔는데 옛 목록을 보고 있을 수 있습니다. |
| 4 | 파일 이름과 확장자를 확인한다 | 비슷한 이름의 다른 파일(예: 설치용·압축본)을 계산했을 수 있습니다. |
| 5 | 그래도 다르면 실행하지 않고 지운다 | 두 번 받아도 같은 값이 나오는데 공식 값과 다르다면 중간에서 바뀐 파일일 수 있습니다. |
2번까지 해도 맞지 않으면 그 파일을 열거나 설치하지 않는 쪽이 안전합니다. 특히 실행 파일이나 AI 모델 파일은 한 번 실행하고 나면 되돌리기 어려운 경우가 있습니다.
텍스트 파일은 줄바꿈 하나로도 값이 달라집니다
위 표의 c.txt가 보여 주듯 눈에 안 보이는 줄바꿈 한 번도 해시를 바꿉니다. 그래서 배포자가 올린 텍스트 파일(설정 파일, 스크립트 등)을 메모장이나 편집기에서 열어 저장만 다시 했는데도 값이 달라지는 일이 생깁니다. 편집기가 마지막 줄바꿈을 붙이거나 줄바꿈 방식을 바꿔 저장하기 때문입니다. 해시를 비교할 파일은 내려받은 그대로 두고, 열어서 고치지 않은 상태에서 계산합니다. 내용을 확인하고 싶으면 복사본을 만들어 그 복사본을 여는 편이 안전합니다.
어떤 알고리즘을 믿어야 하나
해시 계산 방법에는 이름이 여러 가지 있습니다. 미국 표준기술연구소(NIST) 설명에 따르면 SHA-1과 SHA-224·SHA-256·SHA-384·SHA-512 등 SHA-2 계열은 FIPS 180-4에서 정해졌고, NIST는 2011년에 SHA-1 사용을 권장하지 않는 것으로 바꾸고 2013년 말에는 디지털 서명에 쓰는 것을 허용하지 않았습니다. 마이크로소프트 문서도 MD5와 SHA1은 더는 안전하지 않으니 단순한 변경 확인에만 쓰고, 공격이나 변조에서 지켜야 하는 파일에는 쓰지 말라고 안내합니다.
정리하면 배포 페이지에 선택지가 있을 때는 SHA-256 이상을 고르면 됩니다. 페이지가 MD5나 SHA-1만 제공한다면 “전송 중 깨지지 않았는지” 확인하는 용도로는 쓸 수 있지만, “누가 일부러 바꾸지 않았는지”까지 보증하지는 못한다고 이해하면 됩니다.
한 가지 주의: 일치는 안전이 아닙니다
해시가 일치한다는 것은 “배포자가 올린 것과 같다”는 뜻이지 “안전하다”는 뜻이 아닙니다. 배포자 자체를 믿을 수 있는지는 별개 문제입니다. 그래서 해시값도 파일과 같은 곳이 아니라 공식 문서나 저장소에서 확인하는 편이 좋습니다. 둘 다 같은 곳에 있으면 함께 바뀌어 있을 수 있기 때문입니다.
또 하나, 해시로 확인할 수 있는 것은 파일이 “같은지”뿐입니다. 파일 안에 무엇이 들어 있는지, 악성 코드가 있는지는 알려 주지 않습니다. 같은 파일을 내려받았다는 확인이 끝난 다음에야 그 파일을 믿을지 말지의 판단이 시작됩니다.
받을 때마다 확인하는 체크리스트
- 해시값이 적힌 곳이 파일을 받은 곳과 다른 공식 페이지인가
- 배포 페이지가 말하는 알고리즘(SHA-256 등)과 내가 계산한 알고리즘이 같은가
- 값을 눈이 아니라 붙여 넣기나 -c 옵션으로 전체 비교했는가
- 다르게 나왔을 때 다시 받기 → 버전 확인 → 실행 중단 순서를 지켰는가
- 일치해도 실행해도 되는 파일인지는 따로 판단했는가
공식 문서가 알려 주는 명령 옵션과 한계
마이크로소프트의 Get-FileHash 문서는 이 명령이 파일 내용으로 해시값을 계산하며, 알고리즘을 따로 지정하지 않으면 SHA256을 쓴다고 설명합니다. 지정할 수 있는 값은 SHA1, SHA256, SHA384, SHA512, MD5입니다. 같은 문서는 MD5와 SHA1이 더는 안전하다고 보지 않으므로 단순한 변경 확인에만 쓰고, 변조를 막아야 하는 파일에는 쓰지 말라고 안내합니다. 배포 페이지가 SHA-256 값을 적어 두었다면 그대로 SHA256으로 계산해 비교하면 됩니다.
| 옵션 | 공식 문서의 설명 | 쓰는 경우 |
|---|---|---|
| -Path | 파일 경로를 지정하며 와일드카드를 쓸 수 있습니다. | 여러 파일을 한 번에 계산할 때 |
| -LiteralPath | 입력한 경로를 글자 그대로 사용하며 와일드카드로 해석하지 않습니다. | 경로에 특수문자가 들어 있을 때 |
| -Algorithm | SHA1, SHA256, SHA384, SHA512, MD5 중 선택하고 기본값은 SHA256입니다. | 배포 페이지가 SHA-512 등 다른 값을 줄 때 |
웹 페이지에서 쓰는 같은 원리
파일 내려받기가 아니어도 해시 비교는 쓰입니다. MDN의 하위 리소스 무결성(Subresource Integrity) 문서에 따르면, 웹 페이지는 외부에서 불러오는 스크립트나 스타일시트의 integrity 속성에 해시를 적어 둘 수 있고, 브라우저는 내려받은 내용이 그 해시와 맞지 않으면 리소스를 불러오지 않고 네트워크 오류로 처리합니다. 허용되는 알고리즘은 sha256, sha384, sha512이며, 속성에 여러 알고리즘이 함께 있으면 가장 강한 것만 비교합니다. 이 문서의 해시는 16진수가 아니라 base64 형식으로 적는다는 점도 다릅니다. 내려받은 파일 비교든 웹 리소스 비교든, 값이 하나라도 다르면 쓰지 않는다는 판단 기준은 같습니다.
업데이트
알고리즘 이름과 기본값, 사용 중단 시점은 마이크로소프트 Get-FileHash 문서, certutil 문서, NIST 해시 함수 문서(2026년 10월 9일 기준)를 따랐고, 본문의 예시 값은 맥 터미널에서 계산한 결과입니다. 윈도우 명령의 실행 결과는 직접 돌려 본 것이 아니라 공식 문서의 설명을 옮긴 것입니다.
확인 자료
- Microsoft Learn: Get-FileHash 명령 설명
- Microsoft Learn: certutil 명령 설명(-hashfile)
- NIST: 해시 함수 프로젝트(FIPS 180-4, SHA-1 사용 중단 경과)
- MDN: Subresource Integrity(integrity 속성과 해시 불일치 처리)
기준일: 2026-10-09, 보강 자료 기준일: 2026-10-18