해시 vs 암호화 차이 완벽 정리 - 비밀번호는 왜 복호화가 안 될까

회원가입 시스템을 만들다 보면 비밀번호를 어떻게 저장해야 할지 고민이 생깁니다. 어떤 사람은 암호화를 쓰라고 하고, 어떤 사람은 해시를 써야 한다고 말합니다. 둘 다 데이터를 알아볼 수 없는 형태로 바꾸는 것 같은데 무슨 차이가 있을까요. 해시 vs 암호화 차이를 제대로 이해하지 못하면 보안 사고로 이어질 수 있습니다.

실제로 2020년대 이후 발생한 대규모 개인정보 유출 사고 중 상당수가 비밀번호를 잘못된 방식으로 저장한 사례였습니다. 평문 저장은 물론이고, 복호화가 가능한 방식으로 비밀번호를 보관한 서비스에서 사고가 잇따랐습니다.

해시와 암호화를 헷갈리는 이유

두 기술 모두 입력값을 알아볼 수 없는 문자열로 바꿉니다. 결과물만 놓고 보면 둘 다 무작위 문자열처럼 보이기 때문에 비슷한 기술로 착각하기 쉽습니다. 하지만 핵심 목적이 완전히 다릅니다.

해시는 데이터를 검증하기 위해 사용합니다. 원본을 복원할 필요가 없을 때, 두 데이터가 같은지만 확인하면 될 때 씁니다. 반면 암호화는 데이터를 안전하게 보관했다가 나중에 다시 꺼내 쓰기 위해 사용합니다. 보낸 메시지를 받는 사람이 원본으로 읽어야 하니까요.

해시는 일방통행입니다. 한번 들어가면 나올 수 없습니다. 암호화는 양방향 통행입니다. 들어간 만큼 다시 나올 수 있습니다.

해시란 무엇인가

해시 함수는 임의의 길이를 가진 입력값을 고정된 길이의 출력값으로 변환하는 함수입니다. 같은 입력에 대해 항상 같은 결과를 내놓고, 한번 변환된 결과로는 원본을 알 수 없습니다.

해시의 주요 특징

• 일방향성: 해시값에서 원본을 역산할 수 없습니다
• 고정 길이: 입력이 1글자든 1억 글자든 출력 길이는 동일합니다
• 충돌 저항성: 서로 다른 입력이 같은 해시값을 가질 확률이 극히 낮습니다
• 눈사태 효과: 입력이 1비트만 바뀌어도 해시값이 완전히 달라집니다

대표적인 해시 알고리즘으로는 SHA-256, SHA-3, bcrypt, scrypt, Argon2가 있습니다. MD5와 SHA-1은 충돌 취약점이 발견되어 보안 용도로는 더 이상 사용하지 않습니다.

암호화란 무엇인가

암호화는 평문(plaintext)을 키(key)를 사용해 암호문(ciphertext)으로 바꾸는 과정입니다. 같은 키로 다시 평문으로 복원할 수 있습니다. 이 복원 과정을 복호화라고 합니다.

대칭키 암호화와 비대칭키 암호화

암호화는 키 사용 방식에 따라 두 가지로 나뉩니다.

대칭키 암호화는 암호화와 복호화에 같은 키를 사용합니다. 속도가 빠르고 대용량 데이터에 적합합니다. AES가 대표적이며, 현재 가장 널리 쓰이는 알고리즘입니다.

비대칭키 암호화는 공개키와 개인키 한 쌍을 사용합니다. 공개키로 암호화하면 개인키로만 복호화할 수 있습니다. RSA, ECC가 대표적이고 SSL/TLS, 전자서명에 쓰입니다.

해시 vs 암호화 핵심 차이

표로 정리하면 차이가 명확하게 보입니다.

가장 핵심적인 차이는 복원 가능 여부입니다. 비밀번호를 잊어버렸을 때 서비스가 원래 비밀번호를 알려주지 않고 재설정만 가능한 이유가 여기에 있습니다. 해시로 저장했기 때문에 서비스 운영자조차 원래 비밀번호를 알 수 없습니다.

실제 어디에 쓰이나

두 기술은 보통 함께 사용됩니다. 어떤 상황에 무엇을 쓰는지 알아두면 보안 설계가 훨씬 쉬워집니다.

해시를 쓰는 경우

• 비밀번호 저장 (bcrypt, Argon2)
• 파일 무결성 검증 (다운로드 파일이 변조되지 않았는지 확인)
• 블록체인의 블록 연결
• 디지털 서명에서 메시지 요약
• 중복 데이터 식별 (이미지 중복 검사 등)

암호화를 쓰는 경우

• HTTPS 통신 (TLS)
• 메신저의 종단간 암호화
• VPN을 통한 데이터 전송
• 데이터베이스의 민감 정보 저장 (주민번호, 카드번호)
• 파일 압축 도구의 비밀번호 보호

개발자가 자주 하는 실수

해시와 암호화를 잘못 사용해서 발생하는 실수는 꽤 흔합니다. 보안 사고로 이어지기 전에 미리 알아두면 좋습니다.

1. 비밀번호를 암호화로 저장하는 실수

비밀번호는 복원할 필요가 없기 때문에 반드시 해시로 저장해야 합니다. AES로 암호화해서 저장하면 키가 유출되는 순간 모든 사용자의 비밀번호가 평문으로 노출됩니다.

2. Salt 없이 해시만 적용하는 실수

단순히 SHA-256만 적용하면 레인보우 테이블 공격에 취약합니다. 사용자마다 고유한 salt를 추가해 같은 비밀번호라도 다른 해시값이 나오게 해야 합니다.

3. 빠른 해시 함수를 비밀번호에 사용하는 실수

SHA-256은 대용량 데이터의 무결성 검증에는 적합하지만 비밀번호 저장에는 너무 빠릅니다. 1초에 수십억 번 시도하는 무차별 대입 공격에 취약하기 때문에 bcrypt, scrypt, Argon2 같은 느린 해시를 써야 합니다.

4. 자체 암호화 알고리즘 개발

검증되지 않은 자체 알고리즘은 거의 항상 취약점을 가지고 있습니다. AES, RSA처럼 수십 년간 검증된 표준 알고리즘을 사용하는 것이 정답입니다.

보안 구현은 단순히 알고리즘을 선택하는 것을 넘어서 시간 관리도 중요합니다. 키 교체 주기, 인증서 갱신 시점을 놓치지 않도록 온라인 타이머로 알림을 설정해두는 것도 실무에서 쓸 만한 팁입니다.

지금 운영 중인 서비스의 비밀번호 저장 방식을 한번 점검해보세요. 평문이나 단순 SHA-256으로 저장하고 있다면 bcrypt나 Argon2로 마이그레이션 계획을 세워야 합니다. 통신 구간에 HTTPS가 적용되어 있는지, 민감한 개인정보가 데이터베이스에 평문으로 저장되어 있지는 않은지도 함께 확인해보시기 바랍니다.