해시 vs 암호화 차이 완벽 정리 - 개발자도 헷갈리는 핵심 개념 비교
해시와 암호화는 전혀 다른 기술입니다. 비밀번호 저장에는 해시, 데이터 전송에는 암호화가 쓰이는 이유를 실무 관점에서 명확하게 설명합니다.
비밀번호를 데이터베이스에 저장할 때 암호화를 쓰면 될까요, 해시를 써야 할까요? 이 질문에 바로 답하지 못한다면 이 글이 도움이 될 겁니다. 해시 vs 암호화 차이는 보안의 기초이면서도 실무에서 가장 많이 혼동되는 개념 중 하나입니다.
두 기술 모두 원본 데이터를 알아볼 수 없는 형태로 바꾼다는 공통점이 있지만, 목적과 작동 방식은 완전히 다릅니다. 이 글에서 해시 vs 암호화 차이를 실제 사용 사례와 함께 명확하게 정리하겠습니다.
해시와 암호화, 각각 무엇인가
해시(Hash)란
해시는 임의 길이의 데이터를 고정 길이의 값으로 변환하는 단방향 함수입니다. 한번 변환하면 원본으로 되돌릴 수 없습니다. 같은 입력에는 항상 같은 출력이 나오지만, 출력값만으로는 입력을 역추적할 수 없습니다.
- 대표 알고리즘: SHA-256, SHA-3, bcrypt, Argon2
- 출력 길이: SHA-256 기준 항상 64자(256비트)
- 핵심 특성: 비가역성(되돌릴 수 없음)
암호화(Encryption)란
암호화는 키(Key)를 사용해 데이터를 변환하는 양방향 함수입니다. 올바른 키가 있으면 원본 데이터를 복원(복호화)할 수 있습니다.
- 대표 알고리즘: AES-256, RSA, ChaCha20
- 출력 길이: 입력 데이터 크기에 따라 달라짐
- 핵심 특성: 가역성(키가 있으면 복원 가능)
해시는 자물쇠를 잠그고 열쇠를 버리는 것이고, 암호화는 자물쇠를 잠그되 열쇠를 보관하는 것입니다. 이것이 해시 vs 암호화 차이의 핵심입니다.
해시 vs 암호화 핵심 차이 비교표
두 기술의 차이를 한눈에 비교하면 다음과 같습니다.
| 구분 | 해시(Hash) | 암호화(Encryption) |
|---|---|---|
| 방향성 | 단방향 (복원 불가) | 양방향 (복호화 가능) |
| 키 필요 여부 | 키 없음 | 암호화/복호화 키 필요 |
| 출력 길이 | 항상 고정 (SHA-256: 32바이트) | 입력 크기에 비례 |
| 동일 입력 | 항상 동일 출력 | 같은 키면 동일 출력 |
| 주요 목적 | 무결성 검증, 비밀번호 저장 | 데이터 기밀성 보호 |
| 대표 알고리즘 | SHA-256, bcrypt, Argon2 | AES-256, RSA, ChaCha20 |
| 속도 | 빠름 (비밀번호용은 의도적으로 느리게) | 상대적으로 느림 |
표에서 볼 수 있듯이 가장 결정적인 차이는 복원 가능 여부입니다. 해시는 원본을 알 수 없고, 암호화는 키만 있으면 원본을 꺼낼 수 있습니다.
해시가 쓰이는 실제 사례
1. 비밀번호 저장
비밀번호는 절대 원본 그대로 저장하면 안 됩니다. DB가 유출되면 모든 사용자의 비밀번호가 노출되기 때문입니다. 비밀번호를 해시로 변환해 저장하면, DB가 탈취되더라도 원본 비밀번호를 알아낼 수 없습니다.
- 로그인 시 사용자가 입력한 비밀번호를 해시로 변환
- 저장된 해시값과 비교하여 일치 여부만 확인
- bcrypt, Argon2 같은 알고리즘은 솔트(salt)를 추가해 레인보우 테이블 공격도 방어
2. 파일 무결성 검증
소프트웨어를 다운로드할 때 배포 사이트에서 SHA-256 체크섬을 함께 제공하는 경우가 많습니다. 다운로드한 파일의 해시값을 계산해서 비교하면, 파일이 전송 중에 변조되지 않았는지 확인할 수 있습니다. 특정 텍스트나 파일의 해시값을 빠르게 확인하고 싶다면 해시 생성기 같은 온라인 도구를 활용하면 별도 설치 없이 바로 확인할 수 있습니다.
3. 데이터 중복 검사
클라우드 스토리지 서비스에서 같은 파일을 여러 번 업로드할 때, 해시값을 비교해 이미 저장된 파일인지 빠르게 판별합니다. 수TB 크기의 파일을 일일이 비교하는 대신 해시값 64자만 비교하면 되니 효율적입니다.
암호화가 쓰이는 실제 사례
1. HTTPS 통신
브라우저 주소창에 자물쇠 아이콘이 보이면 TLS 암호화가 적용된 상태입니다. 로그인 정보, 결제 데이터 등이 암호화되어 전송되므로 중간에 가로채도 내용을 읽을 수 없습니다. 전 세계 웹 트래픽의 약 95% 이상이 HTTPS를 사용하고 있습니다.
2. 메신저 종단간 암호화
카카오톡 비밀채팅, Signal, WhatsApp 등은 종단간 암호화(E2EE)를 적용합니다. 메시지가 발신자 기기에서 암호화되고, 수신자 기기에서만 복호화됩니다. 서버 운영자도 메시지 내용을 볼 수 없는 구조입니다.
3. 데이터베이스 암호화
주민등록번호, 카드번호처럼 나중에 다시 읽어야 하는 민감 정보는 암호화해서 저장합니다. 비밀번호와 달리 원본 데이터가 필요하기 때문에 해시가 아닌 암호화를 사용합니다. 한국의 개인정보보호법은 고유식별정보의 암호화 저장을 의무화하고 있습니다.
실무에서 자주 하는 실수
실수 1: 비밀번호를 암호화로 저장
비밀번호를 AES 같은 암호화로 저장하면 키가 유출되는 순간 모든 비밀번호가 한꺼번에 노출됩니다. 비밀번호는 반드시 bcrypt나 Argon2 같은 해시 알고리즘으로 저장해야 합니다. 이것이 해시 vs 암호화 차이를 이해해야 하는 가장 실질적인 이유입니다.
실수 2: MD5나 SHA-1을 비밀번호 해시에 사용
MD5와 SHA-1은 보안 목적으로는 더 이상 안전하지 않습니다. MD5는 2004년에 충돌 공격이 입증되었고, SHA-1도 2017년 구글에 의해 충돌이 시연되었습니다. 비밀번호 해시에는 반드시 bcrypt(작업 인수 12 이상)나 Argon2를 사용하세요.
실수 3: 해시만으로 데이터 전송 보안을 해결하려는 시도
해시는 데이터가 변조되지 않았는지 확인하는 용도입니다. 데이터 내용을 숨기려면 암호화가 필요합니다. 파일을 안전하게 전송하려면 암호화로 기밀성을 보호하고, 해시로 무결성을 검증하는 방식을 함께 적용해야 합니다.
실수 4: 암호화 키를 코드에 하드코딩
암호화의 안전성은 키 관리에 달려 있습니다. 소스코드에 키를 직접 넣으면 Git 저장소를 통해 키가 유출될 수 있습니다. AWS KMS, HashiCorp Vault 같은 키 관리 서비스를 사용하는 것이 좋습니다.
정리하면
해시와 암호화는 모두 보안에 필수적이지만, 사용 목적이 다릅니다. 지금 운영 중인 서비스가 있다면 두 가지를 점검해 보세요. 첫째, 비밀번호가 해시(bcrypt 또는 Argon2)로 저장되어 있는지 확인하세요. 둘째, 민감한 개인정보가 AES-256 이상으로 암호화되어 있는지 확인하세요. 이 두 가지만 제대로 적용해도 대부분의 데이터 유출 사고에서 피해를 크게 줄일 수 있습니다.
