> ## Content Index
> Fetch the complete content index at: https://www.mekeywhydoesmatter.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# [DATA] 2. 데이터 Hash는 왜 하는가? Salt는 왜 필요한가?
- URL: https://www.mekeywhydoesmatter.com/data-hash-salt/
- Published: 2026-02-08T13:55:50.000Z
- Updated: 2026-02-25T12:31:11.000Z
- Author: mekey
- Tags: Data

데이터가 기계에서 발생하는 센싱 데이터가 아닌 고객과 관련된 데이터라고 한다면 항상 다음과 같은 이슈가 발생하게 된다.

- “이 값은 유니크하게 **식별은 가능해야 하지만**, 원본은 보이면 안됨”
- “서로 다른 데이터가 같은 사용자의 것인지만 알 수 있으면 됨”
- “개인정보는 절대 저장하면 안됨”

이때 가장 흔히 등장하는 선택지가 바로 특정 데이터 항목에 대한 **Hash 처리**다.

하지만 많은 경우,

> *“그냥 보안 때문에 하는 거 아닌가요?”* 정도로만 이해하고 넘어간다.

이 글에서는 **데이터 Hash 처리가 왜 필요한지**, 또 **Salt**는 무언인지

그리고 **언제 쓰고 언제 쓰면 안 되는지**를 정리해본다.

---

## **Hash란 무엇인가?**

Hash는 입력값을 **고정 길이의 값으로 변환하는 함수이며 변환된 값으로는 절대 원본값을 복원​할 수 없게 만들어 주는게 특징이다**.

입력: user\_id = "abc123"  
출력: e99a18c428cb38d5f260853678922e03

입력의 길이가 어떻게되든 상관없이 출력은 항상 동일한 길이가 된다는 걸 명심하자.

특징은 명확하다.

- 같은 입력 → 항상 같은 결과값
- 입력이 조금만 달라져도 → 완전히 다른 결과값
- 결과값으로 **원본을 복원할 수 없음** (일방향)

 이 “**일방향성**”이 Hash의 핵심이다.

---

## **데이터 Hash 처리를 하는 이유**

###   
**1\. 개인정보 보호 (Privacy)**

가장 흔한 이유다.

- 이메일
- 전화번호
- 주민번호
- 고객 ID

이런 값들은 **분석에는 필요하지만, 원본 저장은 위험**하다.

email → hash(email)  
phone → hash(phone)

이렇게 하면:

- 같은 사용자인지 **식별은 가능**
- 실제 개인정보는 **노출되지 않음**

> 즉, “식별 가능하지만 알아볼 수는 없는 상태”를 만든다.

---

### **2.내부 식별자 통일**

실무에서는 이런 상황이 자주 생긴다.

- 서비스 A의 user\_id
- 서비스 B의 customer\_no
- 로그 시스템의 device\_id

서로 다른 ID 체계를 **하나의 키로 묶고 싶을 때**, Hash는 매우 깔끔한 해결책이다.

hash(user\_id)  
hash(device\_id)  
hash(customer\_no)

→ 모두 같은 Hash 공간으로 매핑

### **3.데이터 공유 / 외부 반출**

데이터를 외부에 공유해야 할 때:

- 협력사
- 분석 대행
- 리서치 목적

이때 원본 ID를 넘기는 것은 거의 불가능하다.

그러나, Hash 처리된 데이터는:

- 반출이후에는 개인을 직접 식별할 수 없고
- 내부에서는 매핑정보를 관리해 내부 시스템과 동일한 사용자를 매칭할 수 있으며
- 법적 리스크를 크게 줄여준다

그래서 실무에서는 종종 이렇게 말한다.

> “Hash 안 된 데이터는 밖으로 못 나갑니다.”

---

### **4.머신러닝 / 분석 안정성**

의외로 중요한 이유다.

모델은 보통 이런 값을 **의미 없이 숫자로 학습**한다.

- user\_id = 1001
- user\_id = 1002

이 숫자 크기 자체는 아무 의미가 없다.

하지만 모델은 **의미가 있는 것처럼 오해할 수 있다.**

Hash를 사용하면:

- 임의성이 보장되고
- 순서/크기 의미가 사라지며
- 모델이 ID 자체를 외우는 문제를 줄일 수 있다

### **5.데이터 최소화 원칙**

좋은 데이터 설계의 기본 원칙 중 하나는 이것이다.

> **필요한 정보만 저장하자**

Hash는 이 원칙을 잘 만족한다.

- 데이터상에서 “누구인지”는 직접 알 필요 없음
- 데이터간에서 “같은 사람인지”만 필요함

이럴 때 원본 데이터는 **과한 정보**다.

Hash는 정확히 필요한 만큼만 남긴다.

---

## **Hash ≠ 암호화**

중요한 오해 하나는 꼭 짚고 가야 한다.

| **구분** | **Hash** | **Encryption** |
| ------ | -------- | -------------- |
| 복호화 가능 | 불가능      | 가능             |
| 목적     | 식별 / 보호  | 기밀성            |
| 키 필요   | 없음       | 있음             |
| 원본 복원  | X        | O              |

## **Hash를 쓰면 안 되는 경우**

다음 경우에는 Hash가 오히려 문제를 만든다.

- 나중에 원본 값을 복구해야 하는 경우
- 법적 요청으로 개인정보 제공이 필요한 경우
- 입력 값의 후보군이 매우 작은 경우(ex: 성별, Yes/No, 국가 코드)

특히 **값의 범위가 작으면 brute-force(Hash로 변환된 값을 원본으로 복구는 못하더라도 입력 자체를 조금씩 바꿔가며 매우 많이 변환해 보면 언젠가는 원하는 변환값을 찾을 수도 있기 때문인데 이를 무작위 대입 공격이라고 함) 위험**이 있다.

---

## **그럼, Salt는 언제 필요한가?**

Hash와 함께 같이 언급되는 주요 용어가 Salt이다.

같은 값 → 같은 Hash

이 특성 때문에 생기는 문제도 있다.

- 무작위 대입 공격
- 사전 공격 (rainbow table)

이를 막기 위해 **Salt**를 사용한다.

hash(value + salt)

즉, 입력값에 약간의 소금을 치는 것이다. 

대부분 실무적으로 Salt값은 고정된 값을 사용하고, 데이터를 Hash해서 제공하는 부서에서 비밀리에 간직하게 된다. 

- 외부 공개 데이터 → Salt 적용 필수
- 내부 분석용 ID → 상황에 따라 선택

---

# 

## **자주사용하는 Hash 알고리즘** 

보안 목적에 적합한 Hash 알고리즘으로 SHA 알고리즘이 있다.

특징:

- 충돌(입력이 다른데 변환값이 동일해지는 경우)이 거의 없음
- 입력 변화에 매우 민감(입력이 조금만 변하더라도 변환값이 크게 달라짐)
- 일방향성 보장(변환값으로 입력을 복구할 수 없음)

#### **SHA-256 / SHA-512 (거의 표준)**

가장 많이 사용되는 알고리즘이 SHA계열 알고리즘 중에 SHA256, 512가 있다.

- 출력 길이에 따라 구별됨: 256bit / 512bit
- 현재 가장 널리 사용
- 데이터 식별, 무결성 검증, ID Hash에 적합

```
SHA-256("hello") → 2cf24dba5fb0...
```

사용 예:

- 개인정보 Hash
- 파일 무결성 검증
- 내부 식별자 생성