바이브 코딩같은 사진이 두 장 보인다고 해서 같은 파일인 것은 아니다. 이름만 바뀐 복사본일 수도 있고, 해상도를 줄인 재압축본일 수도 있다. 영상은 더 복잡하다. 컨테이너만 바뀌었거나 앞뒤 몇 초가 잘렸을 수도 있다. 중복 검사에서 먼저 정해야 할 것은 알고리즘이 아니라 ‘무엇을 같은 것으로 볼 것인가’다.
SHA-256은 이 가운데 파일의 바이트가 완전히 같은지를 판별하는 데 널리 쓰인다. 파일 전체를 읽어 고정 길이 지문을 만들기 때문에 이름, 폴더, 수정 시각에 흔들리지 않는다. 표준화가 잘 돼 있고 대부분의 언어와 운영체제에서 바로 쓸 수 있다는 점도 크다.
해시가 낯선 독자라면 출력 길이와 충돌부터 익히면 된다. 이어서 SHA 계열의 역사, 대용량 파일을 거르는 순서, 사진·영상에 지각 해시가 필요한 이유를 연결한다. 바이브 코딩으로 중복 업로드 방지 기능을 만들 때 자주 놓치는 설계 오류도 뒤에서 확인할 수 있다.
1. 중복의 뜻부터 나눠야 한다
중복이라는 말은 적어도 세 가지 뜻으로 쓰인다.
| 판정하려는 것 | 같은 것으로 보는 기준 | 알맞은 기술 |
|---|---|---|
| 정확 파일 중복 | 처음부터 끝까지 모든 바이트가 같음 | 파일 크기 + SHA-256 + 선택적 바이트 비교 |
| 사진 근접 중복 | 리사이즈·재압축 뒤에도 사람이 같은 사진으로 인식 | aHash·dHash·pHash·이미지 임베딩 |
| 영상 파생 중복 | 재인코딩·자르기·자막 뒤에도 같은 장면 흐름 | 키프레임 지문·시간 순서·오디오 지문·임베딩 |
예를 들어 사진의 EXIF 촬영 정보만 바뀌어도 파일 바이트는 달라진다. SHA-256 기준에서는 다른 파일이다. 반면 지각 해시는 화면의 큰 형태가 같다면 가까운 값으로 볼 수 있다. 정확도의 문제가 아니라 답하려는 질문이 다르다. 원본 보존 시스템은 바이트 동일성이 중요하고, 사진 정리 앱은 시각적 동일성이 더 중요하다.
2. 해시와 SHA-256의 기초
해시 함수는 길이가 제각각인 입력을 일정한 길이의 값으로 바꾼다. SHA-256의 출력은 언제나 256비트, 32바이트, 16진수 64자리다. 1KB 문서와 20GB 영상도 출력 길이는 같다.
그림 1. SHA-256은 파일의 모든 바이트를 읽어 256비트 지문을 만든다.
같은 바이트열을 넣으면 언제나 같은 값이 나온다. 입력의 한 비트만 바뀌어도 결과는 크게 달라진다. 이를 눈사태 효과라고 부른다. 해시값만 보고 원본을 복원하기도 현실적으로 어렵다.
SHA-256 내부에서는 입력에 패딩과 길이 정보를 붙인 뒤 512비트 블록으로 나눈다. 각 블록은 64라운드의 연산을 거치고, 여덟 개의 32비트 상태값이 갱신된다. 마지막 여덟 값을 이어 붙인 결과가 256비트 다이제스트다. 중복 검사 기능 때문에 이 64라운드를 직접 구현할 필요는 없다. 검증된 표준 라이브러리를 사용하고, 파일을 청크 단위로 스트리밍해 해시 상태를 갱신하면 된다.
해시는 암호화와도 다르다. 암호화는 키가 있으면 원문으로 되돌릴 수 있어야 한다. 해시는 복호화를 전제로 하지 않는다. 비밀번호 저장 역시 별도 문제다. SHA-256은 너무 빠르므로 비밀번호에는 Argon2id 같은 전용 방식이 필요하다.
3. 해시라는 말의 두 뿌리
컴퓨터 분야에서 해시는 두 맥락으로 발전했다. 1950년대의 해시 테이블은 데이터를 빠르게 찾기 위한 자료구조다. 키를 작은 정수 인덱스로 바꾸고 충돌이 나면 체이닝이나 개방 주소법으로 해결한다. 여기서 충돌은 예상 가능한 운영 문제다.
암호학적 해시는 1970년대 후반부터 무결성과 서명을 위해 발전했다. 이쪽은 공격자가 같은 해시를 가진 다른 입력을 의도적으로 만들기 어려워야 한다. 해시 테이블용 함수와 SHA-256을 같은 종류로 취급하면 안 되는 이유다. 전자는 속도와 분산이 중심이고, 후자는 충돌 저항성과 역상 저항성까지 요구한다.
4. SHA 계열이 등장한 배경과 역사
1991년 발표된 MD5는 128비트 지문을 사용했다. SHA-1은 1995년 표준화돼 160비트 출력을 제공했다. 이후 더 긴 출력과 강화된 구조가 필요해졌고, 2002년 FIPS 180-2에 SHA-256·SHA-384·SHA-512가 포함됐다. 이 묶음을 SHA-2 계열이라고 부른다.
그림 2. 검색용 해시에서 암호학적 해시, 지각 해시로 용도가 갈라진 흐름.
2004~2005년에는 여러 해시 함수에 대한 공격이 공개됐다. NIST는 2007년 SHA-3 공모전을 시작했고, 2012년 구조가 다른 Keccak을 선정했다. SHA-3는 SHA-2가 깨져서 급히 교체한 결과가 아니다. NIST는 SHA-2를 계속 안전한 표준으로 보면서도 다른 설계 계열을 함께 확보했다.
2017년 Google과 CWI의 SHAttered 프로젝트는 서로 다른 PDF 두 개가 같은 SHA-1 값을 갖도록 만드는 실용 충돌을 공개했다. 이 사건은 ‘출력 길이가 길어 보인다’는 인상보다 공개 검증과 현재의 공격 가능성을 봐야 한다는 교훈을 남겼다. 새 중복 검사 시스템이 MD5나 SHA-1 대신 SHA-256을 기본값으로 택하는 배경도 여기에 있다.
5. SHA-256이 정확 중복 검사에 알맞은 이유
같은 입력에서 같은 결과가 나오는 결정성은 중복 검사에 꼭 맞는다. 파일을 어느 폴더에서 읽든 바이트가 같으면 해시도 같다. 이름을 바꿔도 결과는 달라지지 않는다.
비교 데이터가 작다는 장점도 있다. 10GB 파일 두 개를 조회 때마다 다시 대조할 필요 없이, 한 번 계산한 32바이트 해시를 데이터베이스에 보관하면 된다. 최초 계산은 모든 바이트를 한 번 읽지만 그 뒤의 조회는 고정 길이 값만 비교한다.
NIST는 SHA-256의 기대 충돌 저항 강도를 128비트로 평가한다. 공격자가 같은 해시를 내는 다른 파일을 노려서 만들려 해도, 생일 경계 기준으로 약 2의 128제곱에 이르는 작업이 필요하다는 의미다.
지원 범위도 넓다. 브라우저 Web Crypto, Node.js crypto, Python hashlib, Java MessageDigest, .NET SHA256, 운영체제 도구와 클라우드 서비스가 SHA-256을 제공한다. 같은 표준을 쓰면 서로 다른 시스템이 만든 값도 그대로 대조할 수 있다.
콘텐츠 주소화와도 잘 맞는다. Git은 콘텐츠를 해시로 부르는 콘텐츠 주소형 파일시스템의 대표 사례다. 업로드 서비스가 SHA-256을 객체 식별자나 중복 방지 키로 삼으면 동일 콘텐츠 재사용, 캐시, 무결성 검사를 한 흐름으로 연결하기 쉽다.
6. 충돌 확률을 바르게 이해하는 법
서로 다른 입력은 무한히 많고 SHA-256 출력은 유한하다. 비둘기집 원리에 따라 충돌 자체는 반드시 존재한다. 중요한 것은 충돌이 존재하느냐가 아니라 현실적인 계산량으로 찾을 수 있느냐다.
| 성질 | 질문 | SHA-256의 기대 강도 |
|---|---|---|
| 충돌 저항성 | 아무 두 입력이나 같은 해시로 만들 수 있는가 | 약 128비트 |
| 역상 저항성 | 정해진 해시값을 만드는 입력을 찾을 수 있는가 | 약 256비트 |
| 제2 역상 저항성 | 주어진 파일과 같은 해시의 다른 파일을 찾을 수 있는가 | 메시지 길이에 따라 최대 256비트 수준 |
파일이 10억 개라고 가정해도 무작위 충돌의 근사 확률은 대략 4.3×10의 -60제곱 수준이다. 일상적인 저장소에서 우연한 SHA-256 충돌을 걱정하기보다 잘못된 경로 처리, 스캔 중 파일 변경, 데이터베이스 경쟁 조건을 먼저 막는 편이 현실적이다.
다만 같은 해시만으로 수학적 동일성이 증명되는 것은 아니다. 삭제나 원본 대체처럼 결과가 큰 작업에서는 크기 일치 → 전체 SHA-256 일치 → 바이트 단위 최종 비교를 적용하면 된다. 해시는 후보를 빠르게 묶고, 마지막 바이트 비교가 절대 확인을 맡는다.
7. 실무 중복 검사 파이프라인
모든 파일을 처음부터 전체 해시로 읽으면 정확하지만 저장장치 I/O가 커진다. 후보를 단계적으로 줄이면 같은 정확도를 더 적은 읽기로 얻는다.
그림 3. 값싼 필터부터 적용하고 삭제 직전에 바이트 확인을 더하는 안전한 순서.
| 단계 | 수행 내용 | 통과 조건 | 주의점 |
|---|---|---|---|
| 파일 크기 | 바이트 수가 같은 파일끼리 묶음 | 크기 중복 그룹 | 크기만 같다고 내용이 같은 것은 아님 |
| 부분 해시 | 앞부분 또는 여러 구간의 짧은 지문 계산 | 부분 지문 일치 | 최종 판정에 사용하지 않음 |
| 전체 SHA-256 | 파일 전체를 스트리밍하며 계산 | 전체 해시 일치 | 스캔 중 변경 여부 확인 |
| 바이트 비교 | 두 파일을 청크 단위로 직접 대조 | 끝까지 모두 일치 | 삭제·하드링크 전 권장 |
대용량 파일은 전체를 메모리에 올리지 않는다. 64KB나 1MB 같은 청크를 반복해서 읽고 해시 객체에 전달하면 메모리 사용량이 파일 크기와 무관하게 일정해진다. 실제 처리량은 CPU보다 SSD나 네트워크 스토리지의 읽기 속도에 좌우되는 경우가 많다. 동시 작업 수를 무작정 늘리면 디스크 탐색과 네트워크 대역폭 경쟁으로 오히려 느려질 수 있다.
캐시도 필요하다. 파일 식별자, 크기, 수정 시각과 함께 계산한 해시를 저장하면 다음 스캔에서 재사용할 수 있다. 수정 시각은 성능용 힌트일 뿐 동일성 증거가 아니다. 해시 계산 전후에 크기와 수정 시각을 다시 읽어 값이 바뀌었다면 결과를 버려야 한다. 이는 검사 도중 다른 프로세스가 파일을 바꾸는 시간차 문제를 줄인다.
심볼릭 링크와 하드링크도 구분한다. 하드링크 두 경로는 이미 같은 저장 블록을 가리킬 수 있어 하나를 중복으로 삭제해도 기대와 다른 결과가 생긴다. 자동 삭제보다 휴지통 이동, 격리, 보존할 대표 파일 선택, 작업 로그 기록을 기본값으로 두는 편이 안전하다.
8. 사진 중복은 왜 SHA-256만으로 부족한가
JPEG 품질을 90에서 85로 낮추거나 4000픽셀 사진을 1200픽셀로 줄이면 눈에는 같은 장면이지만 파일 바이트는 다시 기록된다. EXIF 삭제, 색 공간 변환, 워터마크 추가도 SHA-256을 바꾼다. 정확 해시가 실패한 것이 아니라 ‘바이트 동일성’이라는 질문에 정확히 답한 결과다.
지각 해시는 이미지를 작게 줄이고 명암이나 주파수 특징을 뽑아 짧은 비트열로 만든다. aHash는 평균 밝기, dHash는 이웃 픽셀의 변화, pHash는 주로 DCT 저주파 성분을 이용한다. 두 지문의 차이는 해밍 거리로 잰다. 거리가 작을수록 같은 사진의 변형일 가능성이 높다.
그림 4. 정확 파일과 같은 사진·같은 영상을 찾는 기술은 서로 다른 질문에 답한다.
지각 해시는 빠르지만 만능은 아니다. 강한 자르기, 회전, 좌우 반전, 큰 자막, 배경 합성은 비트 배치를 크게 바꿀 수 있다. 이런 편집까지 잡으려면 여러 회전 버전의 해시, 국소 특징, CNN 기반 임베딩을 조합한다. 임베딩은 의미가 비슷한 다른 사진까지 가까이 둘 수 있으므로 ‘동일 작품’ 판정에는 별도 검증 단계가 필요하다.
임계값은 인터넷에서 찾은 숫자를 그대로 쓰지 않는다. 서비스가 실제로 다루는 사진으로 같은 쌍과 다른 쌍을 만든 뒤, 거리별 오탐과 미탐을 측정해야 한다. 상품 사진, 문서 스캔, 풍경 사진은 분포가 다르다.
9. 영상 중복은 어떻게 찾는가
영상 파일 전체 SHA-256은 같은 MP4 복사본을 찾는 데 정확하다. 그러나 코덱, 비트레이트, 해상도, 자막 트랙, 메타데이터가 달라지면 다른 값이 된다. 같은 영상을 다시 인코딩하면 컨테이너 바이트가 완전히 바뀌기 때문이다.
목표에 따라 비교 층을 나눈다.
| 목표 | 처리 방법 | 잡아내는 범위 |
|---|---|---|
| 원본 복사본 | 파일 전체 SHA-256 | 이름·경로만 다른 완전 복사 |
| 디코딩 결과 동일성 | 정규화한 프레임·오디오의 framehash | 컨테이너 차이를 일부 제거한 동일 스트림 |
| 재인코딩 영상 | 일정 간격 키프레임의 pHash 시퀀스 | 해상도·압축 변경 |
| 일부 구간 재사용 | 장면 분할 + 시간 순서 지문 | 앞뒤 자르기·클립 삽입 |
| 강한 편집 | 영상·오디오 임베딩과 후보 재검증 | 자막·크롭·속도 변화·부분 재구성 |
FFmpeg의 framehash 형식은 디코딩된 오디오·비디오 패킷을 정규화한 뒤 기본적으로 SHA-256을 계산한다. 파일 컨테이너가 달라도 디코딩 결과의 패킷별 동일성을 확인하는 테스트에 유용하다. 하지만 장면 순서가 바뀌거나 프레임이 삭제되면 단순 전체 비교로는 맞지 않는다. 키프레임 특징과 시간 축 정렬이 필요하다.
영상 시스템은 오디오도 함께 본다. 화면을 크롭했어도 음원이 같으면 강한 단서가 되고, 반대로 같은 영상에 다른 해설을 붙였는지 구분할 수 있다. 최종 판정은 길이, 키프레임 거리, 연속 일치 구간, 오디오 지문을 가중해 내리는 편이 안정적이다.
10. SHA-256과 다른 방법 비교
| 방식 | 암호학적 보안 | 속도 특성 | 주 용도 | 새 시스템 권장 판단 |
|---|---|---|---|---|
| SHA-256 | 있음 | 널리 최적화됨 | 무결성·정확 중복·콘텐츠 주소 | 호환성과 표준성이 필요할 때 기본값 |
| SHA-3-256 | 있음 | 구조가 SHA-2와 다름 | 보완 표준·특정 보안 요구 | 요구사항에 SHA-3가 있을 때 |
| BLAKE3 | 있음 | 병렬·SIMD 처리에 강함 | 대용량 로컬 스캔·콘텐츠 저장 | 생태계가 허용하고 성능이 중요할 때 |
| MD5 | 충돌 저항 깨짐 | 빠름 | 레거시 체크섬 | 새 보안 경계의 최종 판정에는 피함 |
| SHA-1 | 실용 충돌 공개 | 레거시 호환 | 기존 시스템 | 새 설계 기본값으로 부적합 |
| xxHash·CRC32 | 없음 | 매우 빠름 | 사전 필터·오류 감지 | 신뢰 경계 밖 입력의 최종 판정에는 부적합 |
| pHash·dHash | 목적이 다름 | 짧은 지문 비교 | 사진 근접 중복 | SHA-256과 함께 사용 |
SHA-256이 언제나 가장 빠르거나 유일한 답은 아니다. 로컬 미디어 아카이브에서 수십 테라바이트를 반복 스캔한다면 크기와 xxHash로 후보를 줄이고 BLAKE3 또는 SHA-256으로 확정하는 방식이 효율적일 수 있다. 외부 업로드를 받는 공개 서비스에서는 공격자가 입력을 고를 수 있으므로 암호학적 해시를 최종 키로 쓰는 편이 안전하다.
11. 바이브 코딩 개발자가 꼭 알아야 하는 이유
AI에게 ‘중복 업로드를 막아줘’라고만 지시하면 화면에서는 작동해도 운영 환경에서 위험한 코드가 나오기 쉽다. 파일명만 비교하거나, 브라우저가 보낸 해시를 서버가 그대로 믿거나, 대용량 영상을 한 번에 메모리로 읽는 구현이 대표적이다.
먼저 중복 정의를 요구사항에 적어야 한다. 정확 복사본만 막는지, 리사이즈 사진도 막는지, 영상 일부 재사용까지 찾는지에 따라 데이터 모델과 비용이 달라진다. ‘SHA-256 중복 체크’ 한 문장만으로는 사진 근접 중복 문제를 해결할 수 없다.
서버는 클라이언트 해시를 신뢰하지 말고 업로드 바이트로 다시 계산한다. 클라이언트 해시는 빠른 사전 조회 힌트로 쓸 수 있지만 조작 가능하다. 데이터베이스에는 해시만 단독으로 두기보다 알고리즘, 바이트 크기, MIME 유형, 원본 객체 상태를 함께 기록한다. SHA-256 문자열은 소문자 64자리 16진수처럼 한 형식으로 정규화해야 한다.
동시 업로드도 고려한다. 두 요청이 거의 동시에 ‘아직 없음’을 확인한 뒤 둘 다 저장할 수 있다. 애플리케이션의 조회 한 번으로 막지 말고 데이터베이스의 유일 제약, 트랜잭션, 객체 저장 순서를 함께 설계한다. 업로드가 중간에 끊긴 임시 객체와 정상 완료 객체도 구분해야 한다.
AI가 생성한 코드를 검토할 때는 다음 질문이 유용하다.
- 파일을 스트리밍하는가, 통째로 메모리에 올리는가?
- 서버가 직접 해시를 계산하는가?
- 같은 해시의 동시 요청을 데이터베이스가 막는가?
- 스캔 중 파일이 바뀌면 결과를 폐기하는가?
- 지각 해시 결과를 자동 삭제 근거로 오해하지 않는가?
- 실패한 업로드와 완료된 원본의 상태를 나누는가?
- 삭제 대신 재사용·참조 증가·격리 같은 정책이 있는가?
이 기초를 알면 AI가 제안한 라이브러리 이름보다 설계의 빈틈을 먼저 볼 수 있다. 백업, 패키지 캐시, 이미지 갤러리, 영상 편집 자산, CDN 업로드 등 여러 기능에 같은 원리가 반복된다.
12. 상황별 선택표
| 상황 | 1차 판정 | 2차 판정 | 최종 안전장치 |
|---|---|---|---|
| 개인 PC 정확 중복 정리 | 크기 + 부분 해시 | 전체 SHA-256 또는 BLAKE3 | 삭제 전 바이트 비교·휴지통 |
| 웹 업로드 중복 방지 | 서버 계산 SHA-256 | DB 유일 제약 | 업로드 상태·트랜잭션 |
| 사진 갤러리 유사 중복 | SHA-256으로 완전 복사 제거 | pHash·dHash 또는 임베딩 | 미리보기와 사람 확인 |
| 영상 아카이브 | 파일 SHA-256 | 키프레임·오디오 지문 | 연속 구간 재검증 |
| 보안·감사 로그 | SHA-256 또는 승인된 표준 | 서명·HMAC과 결합 | 키 관리와 변경 불가 로그 |
정확 중복은 SHA-256으로 시작하면 된다. 시각적 중복은 그 위에 지각 해시를 얹는다. 삭제처럼 되돌리기 어려운 결정은 바이트 비교나 사람 확인을 마지막에 둔다. 한 알고리즘에 모든 의미를 맡기지 않는 것이 가장 단순하고 안전한 설계다.
13. 공식 자료와 더 읽을거리
- NIST FIPS 180-4 Secure Hash Standard: https://csrc.nist.gov/pubs/fips/180-4/upd1/final
- NIST Hash Functions와 보안 강도 표: https://csrc.nist.gov/Projects/hash-functions
- NIST SHA-3 공모전 역사: https://www.nist.gov/programs-projects/cryptographic-hash-algorithm-competition
- Google·CWI SHAttered 발표: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
- Git 해시 함수 전환 문서: https://git-scm.com/docs/hash-function-transition
- pHash 프로젝트 설명: https://phash.org/
- FFmpeg framehash 문서: https://github.com/FFmpeg/FFmpeg/blob/master/doc/muxers.texi
- BLAKE3 공식 구현: https://github.com/BLAKE3-team/BLAKE3
14. 마무리
앞에서 다룬 SHA-256과 사진·영상 중복 검사의 핵심만 짧게 정리한다.
- 정확 중복은 파일 이름이 아니라 바이트가 같은지를 묻는다.
- SHA-256은 256비트 고정 길이 지문으로 정확 중복 후보를 안정적으로 묶는다.
- 같은 SHA-256은 실무상 매우 강한 증거지만, 파괴적 작업 전 바이트 비교를 더하면 이론적 충돌 위험까지 제거된다.
- 리사이즈·재압축 사진은 지각 해시, 편집된 영상은 키프레임·시간·오디오 지문이 필요하다.
- 대용량 처리는 크기·부분 해시·전체 해시 순으로 후보를 줄이고 스트리밍해야 한다.
- 바이브 코딩에서는 서버 재계산, DB 유일 제약, 동시성, 삭제 전 검증을 요구사항에 명시해야 한다.
「같은 파일을 찾는 해시와 같은 장면을 찾는 지문은 서로 다른 도구다.」 목적을 먼저 정의하고 SHA-256, 지각 해시, 영상 지문을 단계별로 조합하면 정확도와 처리 비용을 함께 관리할 수 있다. 성능 수치와 지각 해시 임계값은 저장장치·CPU·실제 미디어 데이터셋에 따라 달라지므로 운영 환경에서 측정해 확정해야 한다.
자주 묻는 질문
- SHA-256 값이 같으면 두 파일은 100% 같은 파일인가요?
실무에서는 같은 크기와 같은 SHA-256 값을 가진 파일을 사실상 동일한 바이트열로 취급해도 될 만큼 충돌 가능성이 작습니다. 다만 해시는 유한한 길이이므로 수학적 절대 보장은 아닙니다. 삭제·덮어쓰기처럼 되돌리기 어려운 작업 전에는 마지막으로 바이트 단위 비교까지 하면 이론적 충돌 위험도 없앨 수 있습니다.
- 파일 이름과 폴더가 달라도 중복을 찾을 수 있나요?
찾을 수 있습니다. SHA-256은 이름, 폴더 경로, 생성 날짜가 아니라 파일 내부 바이트를 읽어 계산합니다. 같은 파일을 이름만 바꾸거나 다른 폴더로 복사해도 바이트가 같으면 같은 해시가 나옵니다. 반대로 이름이 같아도 내용이 한 바이트라도 달라지면 다른 해시가 나옵니다.
- 사진 크기만 줄였는데 SHA-256 값이 왜 달라지나요?
리사이즈나 JPEG 재압축은 픽셀 데이터와 파일 구조를 다시 기록합니다. 눈으로는 같은 사진처럼 보여도 바이트열이 달라지므로 SHA-256도 완전히 달라집니다. 이런 근접 중복을 찾으려면 pHash·dHash 같은 지각 해시나 이미지 임베딩을 함께 사용해야 합니다.
- MD5가 빠르다는데 파일 중복 검사에 사용해도 되나요?
악의적 입력이 전혀 없고 결과를 삭제 판단에 쓰지 않는 내부 사전 필터라면 쓸 수는 있습니다. 그러나 MD5와 SHA-1은 충돌 저항성이 깨졌고 새 시스템의 기본값으로 삼을 이유가 적습니다. 호환성과 표준성이 중요한 일반 서비스에서는 SHA-256이 더 보수적인 선택입니다.
- BLAKE3나 xxHash가 SHA-256보다 좋은 선택인가요?
어떤 용도인지에 따라 선택이 달라집니다. BLAKE3는 병렬 처리에 강한 현대적 암호학 해시라 대용량 로컬 스캔에서 유리할 수 있습니다. xxHash는 매우 빠르지만 공격자가 입력을 조작하는 상황을 막도록 설계된 암호학 해시는 아닙니다. 외부 업로드나 보안 경계에서는 SHA-256 또는 BLAKE3 같은 암호학 해시를 우선합니다.
- pHash의 해밍 거리 기준은 몇으로 설정해야 하나요?
모든 사진에 통하는 단일 기준은 없습니다. 해시 길이, 전처리, 이미지 유형, 허용할 편집 범위에 따라 오탐과 미탐이 달라집니다. 실제 서비스 사진에서 같은 쌍과 다른 쌍을 라벨링한 검증 세트를 만든 뒤 거리별 정밀도와 재현율을 보고 임계값을 정해야 합니다.
- 영상 중복은 파일 전체 SHA-256만 계산하면 충분한가요?
원본 파일의 정확 복사본을 찾는 목적이라면 충분합니다. 재인코딩, 해상도 변경, 앞뒤 자르기, 자막 삽입까지 같은 영상으로 묶으려면 키프레임 지각 해시와 시간 순서, 길이, 오디오 지문 등을 조합한 영상 지문이 필요합니다.
- 중복 파일을 찾은 즉시 자동 삭제해도 되나요?
바로 삭제하는 방식은 피해야 합니다. 심볼릭 링크·하드링크, 스캔 도중 변경된 파일, 권한과 보존 정책, 지각 해시 오탐을 먼저 확인해야 합니다. 기본 동작은 보고서나 격리함 이동으로 두고, 정확 크기·전체 해시·필요 시 바이트 비교를 다시 확인한 뒤 삭제하는 편이 안전합니다.
- 해시는 암호화와 무엇이 다른가요?
암호화는 키를 이용해 원문을 복원할 수 있도록 변환하지만, 해시는 임의 길이 입력을 고정 길이 지문으로 줄이는 일방향 함수입니다. 해시만으로 원본 파일을 되살리는 용도가 아닙니다. 무결성 확인과 중복 식별, 콘텐츠 주소 생성에 주로 사용합니다.
- 비밀번호도 SHA-256으로 저장하면 되나요?
파일 중복 검사와 비밀번호 저장은 요구 조건이 다릅니다. SHA-256은 빠르기 때문에 공격자가 많은 비밀번호 후보를 빠르게 시험할 수 있습니다. 비밀번호는 임의 솔트와 함께 Argon2id, scrypt, bcrypt처럼 의도적으로 느리고 메모리를 많이 쓰는 전용 비밀번호 해시를 사용해야 합니다.