Hash와 암호화의 차이

Hash는 복원이 불가능한 일방향 변환이고, 암호화는 복호화가 가능한 양방향 변환입니다. 둘 다 데이터를 "변환"하지만 목적이 전혀 다릅니다. 이 차이를 헷갈리면 비밀번호 저장, 개인정보 보호, 무결성 검증에서 모두 잘못된 설계를 하게 됩니다.

1) Hash가 적합한 경우

• 무결성 확인(파일 비교)
• 비밀번호 저장(솔트 포함)
• 데이터 변경 여부 검증
• 캐시 키나 데이터 식별자 생성

2) 암호화가 필요한 경우

• 민감 데이터 보관
• 외부 전송 시 기밀성 보장
• 규정 준수가 필요한 정보
• 나중에 다시 원문을 꺼내 써야 하는 정보

3) 실무 팁

• 비밀번호는 해시 + 솔트 + 반복(예: bcrypt/argon2)로 저장하세요.
• MD5는 보안 목적에 사용하지 마세요.
• 해시는 입력의 공백/줄바꿈에도 영향을 받습니다.
• 복호화가 필요한 데이터에 해시를 적용하면 다시 사용할 수 없습니다.

4) 바로 써보기

Hash Generator에서 입력 문자열의 MD5/SHA-256 결과를 확인하며 해시 특성을 파악하세요.

5) 자주 쓰는 해시 알고리즘

• MD5: 빠르지만 보안 용도에는 부적합
• SHA-256: 일반적인 무결성 체크에 사용
• bcrypt/argon2: 비밀번호 저장에 적합 (솔트+반복)

6) 암호화 예시

• 대칭키: AES (속도 빠름, 키 관리 중요)
• 비대칭키: RSA/ECC (키 분리 가능, 속도 느림)

7) 가장 흔한 오해

비밀번호를 "암호화해서" 저장한다고 표현하는 경우가 많지만, 실무에서는 대부분 암호화보다 해시 저장이 맞습니다. 이유는 운영자가 원문 비밀번호를 다시 알 필요가 없기 때문입니다. 반대로 주민등록번호 일부, 결제 연동 키, 외부 API 시크릿처럼 나중에 원문을 다시 써야 하는 값은 해시가 아니라 암호화가 필요할 수 있습니다.

8) 설계 관점에서 구분하는 방법

간단한 질문 하나로 구분할 수 있습니다. "나중에 원문이 다시 필요하나?" 필요 없으면 해시를 먼저 검토하고, 필요하면 암호화를 검토합니다. 여기에 추가로 "공격자가 DB를 가져가면 어떤 피해가 나는가?"까지 생각해야 합니다. 해시는 원문 복원이 어렵지만, 암호화는 키가 유출되면 원문도 함께 노출될 수 있습니다.

9) 실패 사례

해시를 비교해야 하는 곳에 매번 새로운 솔트를 붙여 결과가 바뀌어서 로그인 검증이 실패하는 경우가 있습니다. 반대로 복호화가 필요한 API 키를 해시로 저장해 놓고 나중에 원문을 찾지 못해 기능이 막히는 경우도 있습니다. 이런 문제는 알고리즘 선택보다 데이터 수명 주기를 먼저 정의하면 줄일 수 있습니다.

10) 체크리스트

• 비밀번호는 반드시 해시+솔트로 저장하고 있는가?
• MD5를 보안 용도로 사용하고 있지 않은가?
• 복호화가 필요한 데이터는 암호화를 사용하고 있는가?
• 키 관리와 접근 제어를 분리했는가?

11) 추가 예시

• 파일 해시는 배포 전후 무결성 체크에 사용합니다.
• 암호화는 개인정보/결제정보 저장에 사용합니다.
• 비밀번호는 bcrypt/argon2 같은 느린 해시가 적합합니다.