SHA-1 vs SHA-256 vs SHA-512: 2026년에 올바른 해시 알고리즘 선택하기

TLS 인증서, Git 객체 데이터베이스, Bitcoin 블록 헤더, 리눅스 패키지 관리자, Docker 이미지 매니페스트를 열어 보십시오 — 어디에나 SHA 해시가 있습니다. 그러나 모두 같은 SHA는 아닙니다. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: 이 패밀리는 30년에 걸친 역사, 두 가지 설계 계보, 그리고 가장 오래된 구성원을 실제 운영 환경에서 깨뜨린 충돌 공격을 아우릅니다.

이 가이드는 패밀리 전체를 정리하여 여러분이 자신의 사용 사례에 맞는 알고리즘을 망설임 없이 선택할 수 있도록 합니다.

빠른 의사결정 트리

세부 내용을 다루기 전에, 대부분의 개발자에게 실제로 필요한 한 줄 요약표를 제시합니다.

상황	최선의 선택	이유
TLS/HTTPS 인증서	SHA-256(최소), 고보안용 SHA-384	CA/Browser Forum Baseline Requirements에서 규정
JWT 서명(HMAC 또는 RSA)	SHA-256(HS256/RS256)	범용 지원; 규정 준수 환경에는 SHA-384/512
소프트웨어 무결성 체크섬	SHA-256	업계 기본값; 널리 이해됨
장기 보존 또는 오래 쓰는 무결성	SHA-512	더 큰 출력, 수십 년 앞을 위한 안전 여유
콘텐츠 주소 지정(IPFS, OCI)	SHA-256	콘텐츠 주소 저장의 사실상 표준
Git(기존 저장소 읽기/쓰기)	기존에는 SHA-1, 신규에는 `--object-format=sha256`으로 SHA-256	Git 이전 진행 중; SHA-1 여전히 주류
Ethereum 연동	Keccak-256(NIST SHA-3가 아님)	Ethereum은 표준화 이전 Keccak 변형 사용
심층 방어 또는 기밀 시스템	SHA-384 또는 SHA-512	NSA Suite B; AES-256-GCM과 함께 사용
새 코드, 레거시 제약 없음	SHA-3 (SHA3-256)	다른 설계 계보; 길이 확장 취약점 없음
비밀번호 저장	위 어느 것도 해당 없음	bcrypt, Argon2id, scrypt 사용 — SHA는 너무 빠름

SHA 패밀리 한눈에 보기

알고리즘	표준	출력 비트	16진수 자릿수	연도	NIST 상태	오늘날 주요 용도
SHA-1	FIPS 180-4	160	40	1995	비권장(2011), 디지털 서명에서 철회	Git 레거시, 지문
SHA-256	FIPS 180-4	256	64	2001	현행	TLS, JWT, Bitcoin, 체크섬
SHA-384	FIPS 180-4	384	96	2001	현행	Suite B, 고보안 TLS
SHA-512	FIPS 180-4	512	128	2001	현행	보존, LUKS, HMAC-SHA-512
SHA-3 (모든 변형)	FIPS 202	224/256/384/512	가변	2015	현행	대체 계보, 하드웨어 가속

SHA-1과 SHA-2(256/384/512 그룹)는 Merkle-Damgard 구조를 공유합니다. SHA-3은 스펀지 구조를 사용하며 — 이 차이는 겉보기보다 더 중요하며, 아래에서 다룹니다.

SHA-1: 깨졌지만 사라지지 않은

SHA-1은 2000년대의 주역이었습니다. SSL 인증서, S/MIME 이메일, PGP 지문, Git 모두 SHA-1로 수렴했습니다. 그러다 2017년 2월, Google과 CWI 암스테르담이 SHAttered를 발표했습니다. 동일한 SHA-1 해시를 가진 두 개의 서로 다른 PDF 파일을 생성하는 선택 접두어 충돌 공격이었습니다. 이 공격에는 약 6.5 × 10^19번의 SHA-1 연산이 필요했는데 — 2017년에는 비쌌지만 오늘날 클라우드 컴퓨팅으로는 감당 가능한 수준입니다.

NIST는 이미 2011년에 디지털 서명에서 SHA-1을 비권장했습니다(NIST Special Publication 800-131A). SHAttered 시연은 정리 작업을 가속화했습니다. 브라우저들은 2017년까지 SHA-1 TLS 인증서를 신뢰하지 않게 되었고, CA/Browser Forum은 새 발급에 SHA-256을 의무화했습니다.

SHA-1이 여전히 쓰이는 곳:

Git 객체 데이터베이스: Git은 보안 프리미티브가 아닌 빠른 콘텐츠 해시로 SHA-1을 중심으로 설계되었습니다. 저장소 형식은 40자리 16진수 객체 ID를 하드코딩합니다. SHA-256으로의 이전 경로(git init --object-format=sha256)가 존재하지만, 모든 호스팅 플랫폼, 모든 CI 도구, 모든 기존 클론이 동시에 이전해야 하기 때문에 채택이 더딥니다.
레거시 시스템 지문: 오래된 SSH 호스트 키 지문, PGP 키 지문, 인증서 일련 번호 체계는 여전히 SHA-1 값을 노출합니다. 대부분의 맥락에서 이는 정보 제공용이지 보안에 중요한 것이 아닙니다.

해야 할 일: 새로운 것에 SHA-1을 사용하지 마십시오. Git의 경우 충돌 위험은 일반적인 소프트웨어 개발 워크플로에서 낮지만(공격자가 충돌의 두 파일을 모두 제어해야 합니다), --object-format=sha256을 사용하는 새 프로젝트가 올바른 장기적 방향입니다.

브라우저에서 SHA-1 해시 생성: SHA-1 생성기.

SHA-256: 일상의 주역

SHA-256은 2026년 인터넷을 운영하는 알고리즘입니다. 공개 CA가 발급하는 모든 TLS 인증서는 서명 해시에 SHA-256을 사용합니다. HS256, RS256, ES256으로 서명된 모든 JWT는 내부적으로 SHA-256을 사용합니다. Bitcoin의 작업 증명은 이중 SHA-256입니다. Docker 콘텐츠 해싱은 SHA-256입니다. npm 패키지 무결성은 SHA-256을 사용합니다.

이유는 실용적입니다.

보안 여유: 256비트 출력은 무차별 대입 원상 공격에 2^128번의 연산이 필요함을 의미합니다 — 예견 가능한 미래에는 어떤 하드웨어로도 불가능합니다. 실제 보안 수준은 생일 경계 충돌 공격(2^128번 연산) 때문에 약간 낮지만, 여전히 돌파 불가능합니다.
하드웨어 가속: SHA-256은 모든 Intel Goldmont+ CPU(SHA-NI 확장), 모든 Apple 실리콘 칩, 모든 ARMv8 프로세서, 네트워크 어플라이언스와 스토리지 컨트롤러의 전용 ASIC에서 실리콘으로 구현되어 있습니다. 하드웨어 경로를 이용할 때 SHA-256 처리량은 소프트웨어로 구현된 빠른 대안을 능가합니다.
광범위한 라이브러리 지원: 모든 TLS 라이브러리, 모든 JWT 라이브러리, 모든 언어 표준 라이브러리가 SHA-256을 구현합니다. 호환성 문제에 부딪히지 않을 것입니다.

콘텐츠 주소 지정, 무결성 검증, 대부분의 서명 워크플로에서 SHA-256은 특정 표준이 달리 요구하지 않는 한 올바른 기본값입니다.

브라우저에서 SHA-256 해시 생성: SHA-256 생성기.

SHA-384: TLS 특수 용도

SHA-384는 384비트로 잘린 SHA-512입니다. 192비트 보안 수준(출력 크기의 절반이 충돌 저항 하한)을 제공하기 위해 만들어졌으며, AES-256-GCM 및 P-384 타원 곡선 키와 함께 NSA Suite B 암호화에 포함되었습니다.

SHA-384를 TLS에 특별히 매력적으로 만드는 두 가지 속성이 있습니다.

이 출력 크기에서의 길이 확장 면역: SHA-256과 SHA-512는 길이 확장 공격에 취약합니다 — H(비밀 || 메시지)를 아는 공격자가 비밀을 모르더라도 H(비밀 || 메시지 || 확장)을 계산할 수 있습니다. SHA-384와 SHA-512/256은 전체 내부 상태에서 잘린 값이므로 길이 확장이 적용되지 않습니다. HMAC 대신 원시 SHA 해시를 MAC으로 사용한다면 SHA-384가 더 안전합니다.
Suite B 준수: NSA/CNSA(Commercial National Security Algorithm) 스위트 요구사항을 충족해야 하는 기관은 RSA-3072+, ECDH P-384, AES-256과 함께 SHA-384 또는 SHA-512를 사용해야 합니다. 고객이 미국 연방 기관이거나 FIPS 140-3 요구사항 하에 운영되는 계약자라면 SHA-384가 의무일 수 있습니다.

SHA-384는 대부분의 사용 사례에서 SHA-256보다 의미 있게 더 안전하지 않습니다 — 현재 연산 수준에서 128비트와 192비트 충돌 저항의 실질적 차이는 이론적입니다. 규정 준수 또는 Suite B 페어링이 필요할 때 선택하고, 일반 용도에는 사용하지 마십시오.

브라우저에서 SHA-384 해시 생성: SHA-384 생성기.

SHA-512: 더 많은 비트가 필요할 때

SHA-512는 512비트(128자리 16진수) 다이제스트를 생성합니다. 64비트 하드웨어에서는 알고리즘이 32비트 단어 대신 64비트 단어로 연산하기 때문에 종종 SHA-256보다 빠릅니다 — SHA-256의 내부 스케줄은 32비트 산술을 사용하는 반면, SHA-512는 현대 CPU에 더 효율적으로 매핑되는 64비트 산술을 사용합니다.

64비트 하드웨어 벤치마크(참고용; 브라우저 Web Crypto API):

알고리즘	대략적인 처리량
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

참고: SHA-384와 SHA-512는 동일한 내부 압축 함수를 공유하므로 같은 속도로 실행됩니다. SHA-256은 64비트에서 더 느린데, 32비트 단어 크기로 인해 각 512비트 메시지 블록을 처리하는 데 더 많은 반복이 필요하기 때문입니다. 32비트 또는 제한된 하드웨어에서는 SHA-256이 더 빠릅니다.

SHA-512는 다음 용도에 적합합니다.

보존용 무결성: 수십 년을 견뎌야 하는 체크섬은 더 큰 출력 여유에서 이점을 얻습니다.
전체 디스크 암호화: 리눅스 LUKS는 기본 키 유도 PBKDF 해시로 SHA-512를 사용합니다(단독 해시가 아닌 PBKDF2의 구성 요소로).
HMAC-SHA-512: 일부 JWT 서명 방식(HS512)과 더 큰 MAC이 선호되는 API 인증에 사용됩니다.
대량의 의사 난수 데이터 생성: 시드를 해싱하고 많은 출력 비트가 필요한 애플리케이션은 SHA-512를 사용해 해시 호출 횟수를 줄일 수 있습니다.

브라우저에서 SHA-512 해시 생성: SHA-512 생성기.

SHA-3: 다른 설계 철학

SHA-3은 더 큰 출력의 SHA-2가 아닙니다. Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche가 설계한 Keccak이라는 스펀지 구조를 기반으로 한 근본적으로 다른 알고리즘입니다. NIST는 SHA-2의 Merkle-Damgard 구조에서 약점이 발견될 경우 백업으로 사용할 수 있는 해시 패밀리를 구성하기 위한 7년간의 공개 경쟁(2007–2012)에서 이를 승자로 선정했습니다.

스펀지 구조는 Merkle-Damgard와 다르게 작동합니다.

입력이 패딩되어 블록으로 분할됩니다.
각 블록은 큰 내부 상태의 첫 번째 부분(“레이트”)에 XOR되고, 전체 상태는 Keccak-f 치환으로 순열됩니다.
모든 입력을 흡수한 후 출력이 상태의 레이트 부분에서 “짜내어”집니다.

출력이 상태의 일부에서만 추출되고 용량 부분이 직접 노출되지 않기 때문에, 스펀지 구조는 잘라내기 없이도 길이 확장 공격에 본질적으로 면역입니다.

SHA-3 표준 변형(FIPS 202):

변형	출력 비트	보안 수준
SHA3-224	224	112비트
SHA3-256	256	128비트
SHA3-384	384	192비트
SHA3-512	512	256비트
SHAKE128	가변	128비트
SHAKE256	가변	256비트

실제 SHA-3 vs SHA-2:

SHA-3은 2015년 이전에 설계된 프로토콜 — TLS, JWT, 대부분의 인터넷 인프라 — 에는 아직 널리 배포되어 있지 않으며 SHA-2를 계속 사용합니다. SHA-3은 후양자 서명 방식(CRYSTALS-Dilithium, SPHINCS+는 내부적으로 SHA-3 사용), 다른 계보의 백업을 원하는 새 프로토콜 설계, Keccak 치환이 잘 가속되는 하드웨어에 등장하고 있습니다. 순수 소프트웨어에서 SHA-3은 x86에서 SHA-256보다 약 40% 느립니다.

브라우저에서 SHA-3 해시 생성: SHA-3 생성기.

Ethereum Keccak-256 구분

중요한 함정: Ethereum은 NIST SHA-3을 사용하지 않습니다. Ethereum은 Keccak 경쟁이 진행 중이고 NIST가 FIPS 202를 최종화하기 전인 시점에 설계되었습니다. Ethereum 가상 머신은 최종화된 NIST SHA-3 표준과는 다른 패딩을 사용하는 원래 Keccak-256 제출을 사용합니다.

구체적으로:

NIST SHA3-256은 최종 블록 전에 0x06 패딩을 추가합니다.
원래 Keccak-256(Ethereum이 사용)은 0x01 패딩을 추가합니다.

동일한 입력이 다른 해시를 생성합니다. NIST SHA3-256과 Ethereum의 keccak256을 호출하는 것은 호환되지 않습니다. 대부분의 언어에는 둘 다 있습니다. Python에서 hashlib.sha3_256()은 NIST SHA-3이고, Ethereum이 사용하는 Keccak-256의 경우 pysha3(keccak_256 구현) 같은 라이브러리가 필요합니다. JavaScript에서는 js-sha3 라이브러리가 둘 다 노출합니다. SHA-3 생성기는 NIST SHA3-256을 구현합니다 — Ethereum Keccak-256 해시가 필요하다면 Ethereum 전용 도구를 사용하십시오.

성능 벤치마크

아래 수치는 현대 x86-64 노트북의 브라우저 Web Crypto API에 대한 참고용입니다. 실제 처리량은 하드웨어, 메시지 크기, 플랫폼의 하드웨어 가속 경로 사용 여부에 따라 달라집니다.

알고리즘	스트리밍 처리량(64비트)
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

작은 메시지(API 토큰, 몇 KB 미만 체크섬)의 경우 모든 알고리즘이 2 µs 미만에 완료되며 — 차이가 눈에 보이지 않습니다. 큰 데이터(tarball, 디스크 이미지)의 경우 SHA-384/512는 64비트 단어로 연산하기 때문에 64비트 시스템에서 SHA-256을 능가합니다. SHA-3은 순수 소프트웨어에서 더 느립니다. 하드웨어 Keccak 가속이 없다면 처리량 중심 코드에서는 SHA-2를 선호하십시오. SHA-1 처리량은 그것을 사용할 이유가 되지 않습니다.

흔한 함정

인코딩 불일치

SHA는 바이트에서 연산합니다. 브라우저에서 JavaScript가 UTF-8이 아닌 UTF-16으로 인코딩하여 "hello" 문자열을 해싱하면, str.encode("utf-8")을 사용하는 Python 스크립트와 다른 다이제스트가 나옵니다. 텍스트 해싱 전에 항상 UTF-8로 정규화하십시오.

일관된 패턴:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

MAC에 솔팅 누락

원시 SHA 해시를 메시지 인증 코드(H(비밀 || 메시지))로 사용하는 것은 SHA-256과 SHA-512에서 길이 확장 공격에 취약합니다. 대신 HMAC(RFC 2104)을 사용하십시오: HMAC-SHA256(키, 메시지). HMAC은 확장 공격을 방지하는 내부 및 외부 키 패드로 해시를 감쌉니다.

SHA-256의 길이 확장

API 서명을 SHA256(비밀 + 페이로드)로 구성한다면, 결과 해시를 아는 공격자는 비밀을 모르더라도 SHA256(비밀 + 페이로드 + 공격자_확장)을 계산할 수 있습니다. 수정 방법: HMAC을 사용하거나, SHA-3을 사용(구조적으로 면역)하거나, SHA-384/SHA-512/256을 사용(잘라내기로 면역)하십시오.

Keccak-256과 NIST SHA-3 혼동

위에서 설명한 대로: Ethereum은 0x01 패딩의 Keccak-256을 사용하고, NIST SHA3-256은 0x06 패딩을 사용합니다. 같은 입력에서 다른 출력을 생성합니다. Ethereum 컨트랙트나 Solidity ABI 인코딩과 통합하기 전에 라이브러리가 어느 변형을 구현하는지 확인하십시오.

비밀번호에 SHA 사용

SHA 알고리즘은 빠르게 설계되어 있습니다. 바로 그것이 비밀번호 저장에는 잘못된 속성입니다. GPU 클러스터는 초당 수십억 번의 SHA-256 해시를 계산할 수 있어, SHA로 해싱된 비밀번호 데이터베이스에 대한 사전 공격이 현실적입니다. 비밀번호에는 메모리 집약적 키 유도 함수를 사용하십시오: Argon2id(권장), bcrypt, 또는 scrypt. 솔팅했더라도 원시 SHA 해시로 비밀번호를 저장하지 마십시오.

자주 묻는 질문

SHA-1과 SHA-256의 차이는 무엇인가요?

SHA-1과 SHA-256은 모두 FIPS 180-4에서 표준화된 Merkle-Damgard 해시 함수이지만, SHA-256은 SHA-1의 160비트 대비 256비트 다이제스트를 생성합니다. 더 중요한 것은 SHA-1이 깨졌다는 점입니다. 실제 충돌 공격(SHAttered, 2017)이 동일한 SHA-1 해시를 가진 두 개의 서로 다른 PDF 파일을 시연했습니다. SHA-256은 알려진 충돌 공격이 없으며 128비트 충돌 저항 수준을 제공합니다. 무결성 보장이 필요한 모든 것에 SHA-256을 사용하고, 새 작업에는 SHA-1을 사용하지 마십시오.

SHA-512가 SHA-256보다 빠른가요?

64비트 하드웨어에서는 큰 입력에 대해 종종 30–40% 빠릅니다. SHA-512는 현대 CPU가 네이티브로 처리하는 64비트 단어 산술을 사용합니다. SHA-256은 32비트 단어 산술을 사용해 같은 하드웨어에서 메시지 블록당 두 배의 연산이 필요합니다. 32비트 플랫폼이나 제한된 마이크로컨트롤러에서는 SHA-256이 더 빠릅니다. 짧은 메시지(몇 KB 미만)에서는 차이가 감지 불가능합니다.

SHA-1에서 SHA-256으로 이전해야 하나요?

디지털 서명, TLS 인증서, 코드 서명의 경우: 그렇습니다, 반드시 — SHA-1은 비권장이며 실제로 깨졌습니다. Git 저장소의 경우: 이전 경로(git init --object-format=sha256)가 존재하지만 생태계 조정 요구사항으로 채택이 더딥니다. 일반적인 저장소 사용에서 충돌 위험은 낮습니다. 정보용 지문(SSH 호스트 키 표시)의 경우: 보안 노출은 최소이지만 SHA-256으로 이전하는 것이 좋은 관행입니다.

SHA-256을 역산할 수 있나요?

아니요. SHA-256은 설계상 단방향 함수입니다. 해시로부터 수학적으로 원래 입력을 복원할 수 없습니다. 공격자가 할 수 있는 것은 사전 또는 무차별 대입 공격입니다. 수백만 개의 후보 입력을 해싱하여 비교하는 방식입니다. 낮은 엔트로피 입력(짧은 문자열, 일반 비밀번호, 순차 번호)의 경우 미리 계산된 레인보우 테이블이 이를 현실적으로 만듭니다. 높은 엔트로피 입력(무작위 UUID, 큰 파일)의 경우 역산은 계산적으로 불가능합니다. 이것이 SHA만으로는 비밀번호에 부적절한 이유입니다 — 느리고 솔팅된 키 유도 함수가 필요합니다.

SHA-3를 SHA-2 대신 언제 써야 하나요?

SHA-3이 적합한 경우: (a) 미래 SHA-2 약점에 대한 보험으로 다른 설계 계보의 해시를 원할 때; (b) HMAC 없이 길이 확장 면역이 필요한 프로토콜; (c) 내부적으로 SHA-3을 지정하는 후양자 서명 방식을 구현할 때; (d) Keccak용 하드웨어 가속이 있고 처리량이 필요할 때. 대부분의 일상적 사용 사례(TLS, JWT, 체크섬)에서는 SHA-256이 더 넓은 생태계 지원을 받고 실용적인 기본값입니다. SHA-3이 동등한 출력 크기에서 SHA-2보다 더 안전하지는 않습니다 — 장기적 보안에 대한 다른 선택지입니다.

Ethereum은 왜 NIST SHA-3 대신 Keccak-256을 사용하나요?

Ethereum은 NIST가 SHA-3 표준을 최종화한 FIPS 202(2015년 8월)를 발표하기 전인 2013–2014년에 설계되었습니다. 당시 Keccak 제출이 유력한 승자로 여겨졌고, Ethereum 작성자들이 직접 사용했습니다. NIST가 표준을 최종화할 때 도메인 분리 패딩을 0x01(원래 Keccak)에서 0x06으로 변경하여 같은 입력에서 다른 출력을 생성하게 되었습니다. Ethereum은 이미 원래 Keccak 패딩으로 배포되어 변경할 수 없었습니다. 따라서 “Ethereum keccak256”과 “NIST SHA3-256”은 동일한 기반 Keccak-f 치환을 공유함에도 불구하고 서로 다른 알고리즘입니다.

도구 바로 사용: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — 모두 브라우저에서 실행되며, 데이터가 기기를 떠나지 않습니다.

SHA-1 vs SHA-256 vs SHA-512: 2026 해시 알고리즘 가이드