데이터 중복제거(Data Deduplication)

1. 개요

가. 정의

데이터 중복제거(Data Deduplication)란 저장 대상 데이터를 일정 단위(청크)로 분할한 뒤 각 청크의 해시 지문(fingerprint)을 비교하여, 동일한 내용의 청크는 물리적으로 단 한 번만 저장하고 나머지는 참조 포인터로 대체함으로써 중복 저장을 제거하는 용량 최적화(capacity optimization) 기법이다.

중복제거의 본질은 "같은 내용은 두 번 쓰지 않는다"는 단순한 원리를, 콘텐츠 주소화(content addressing)라는 메커니즘으로 구현한 것이다. 전통적인 스토리지는 데이터를 위치(주소) 로 식별하지만, 중복제거 시스템은 데이터를 내용(해시) 으로 식별한다. 동일한 바이트열은 어디에 몇 번 등장하든 동일한 지문을 가지므로, 시스템은 지문을 인덱스에서 조회해 이미 저장된 청크인지 판별하고 신규 청크만 기록한다. 결과적으로 논리적으로는 원본 데이터가 그대로 보존되지만, 물리적으로는 유일한(unique) 청크 집합과 그것을 가리키는 참조 메타데이터만 남는다.

이 기법은 데이터 압축(compression)과 혼동되기 쉬우나 작동 계층이 다르다. 압축이 하나의 데이터 블록 내부 의 통계적 중복(엔트로피)을 줄이는 반면, 중복제거는 여러 블록·파일·시스템에 걸친 거시적 중복 을 제거한다. 둘은 상호 배타적이지 않고 보통 함께 쓰여, 중복제거로 유일 청크만 남긴 뒤 그 청크를 다시 압축하는 2단 최적화로 전체 감축률을 극대화한다.

중복제거를 이해하는 또 다른 관점은 데이터의 논리 뷰와 물리 뷰의 분리 다. 응용 프로그램과 사용자에게는 모든 파일이 온전히 존재하는 것처럼 보이지만(논리 뷰), 실제 매체에는 유일 청크와 참조 메타데이터만 존재한다(물리 뷰). 이 간극을 메우는 것이 파일 레시피이며, 중복제거 시스템의 신뢰성은 결국 이 매핑 메타데이터를 얼마나 안전하게 유지하느냐에 달려 있다. 메타데이터가 손상되면 유일 청크가 멀쩡해도 원본을 재조립할 수 없으므로, 메타데이터 보호는 데이터 보호만큼 중요하다.

나. 등장 배경 및 필요성

데이터 중복제거가 핵심 기술로 부상한 일차적 배경은 데이터 증가 속도가 저장 매체의 가격 하락 속도를 추월 했다는 데 있다. 가상화·클라우드·협업 환경에서는 거의 동일한 운영체제 이미지, 반복 전송되는 메일 첨부, 날마다 거의 변하지 않는 전체 백업본이 끝없이 복제된다. 예컨대 100대의 가상머신(VM)이 동일한 OS를 쓰면 OS 영역 수십 GB가 100벌 저장되는데, 중복제거를 적용하면 1벌만 물리 저장되고 나머지 99벌은 참조로 대체된다.

특히 백업 은 중복제거의 가장 강력한 적용처다. 매일 풀백업을 수행하면 변경분은 보통 1~~5%에 불과한데도 전체 용량이 그대로 재저장된다. 중복제거를 적용하면 변하지 않은 97~~99%의 청크가 제거되어, 백업 대상 환경에 따라 10:1에서 많게는 30:1 이상의 감축비(reduction ratio) 를 얻는다. 이는 곧 디스크 구매량, 데이터센터 상면(rack space), 전력·냉각 비용, 그리고 원격지 복제 시 네트워크 대역폭의 직접적 절감으로 환산된다.

최근에는 랜섬웨어 대응 이라는 새로운 수요도 더해졌다. 중복제거 기반 백업 어플라이언스에 불변(immutable)·보존잠금(retention lock)을 결합하면, 공격자가 백업까지 암호화·삭제하려 해도 일정 기간 변경 불가능한 복구 지점을 다수 보관할 수 있다. 중복제거 덕분에 동일 용량으로 더 많은 복구 시점을 오래 보관할 수 있어, 깨끗한 시점으로의 복구 가능성이 높아진다.

근본적으로 중복제거의 필요성은 저장 경제학과 데이터 이동 비용 의 문제다. 수 PB 규모에서 감축비 2배 차이는 수천 대의 디스크와 그에 딸린 운영비 차이로 이어지며, 재해복구(DR)를 위한 원격 복제에서는 "중복을 제거한 뒤 전송"하는 소스 중복제거가 WAN 대역폭 부족을 해소하는 결정적 수단이 된다. 즉 중복제거는 단순한 용량 절감 기술을 넘어, 폭증하는 데이터를 경제적으로 보관하고 저렴하게 이동 시키기 위한 기반 기술로 자리 잡았다.

다. 핵심 특징

중복제거의 성격은 네 가지로 요약된다. 첫째 콘텐츠 기반 식별 — 데이터를 위치가 아니라 내용의 해시로 식별하므로, 같은 내용은 자동으로 하나로 수렴한다. 둘째 참조 무결성 의존성 — 하나의 유일 청크를 다수가 참조하므로, 그 청크 하나의 손상은 이를 참조하는 모든 데이터의 손상으로 전파된다. 셋째 읽기·쓰기 비대칭 — 쓰기 시에는 청킹·해싱·인덱스 조회라는 추가 연산이 들지만, 복원 시에는 흩어진 청크를 모아야 하므로 단편화(fragmentation) 페널티가 발생한다. 넷째 메타데이터 집약성 — 청크가 작을수록 감축률은 높아지지만 지문 인덱스와 참조 테이블이 커져 메모리·연산 부담이 가중된다. 이 특징들은 뒤에서 다룰 "언제, 어떤 방식으로 중복제거를 적용할 것인가"의 판단 근거가 된다.

중복제거의 효과를 정량화하는 핵심 지표는 감축비(Deduplication Ratio) 로, 보통 "논리 용량 ÷ 물리 용량"으로 정의되어 10:1, 20:1처럼 표기한다. 다만 감축비는 데이터 특성에 극도로 민감해 같은 장비라도 워크로드에 따라 2:1에서 50:1까지 출렁이므로, 벤더가 제시하는 최대치를 그대로 신뢰하기보다 자사 데이터로 사전 평가(assessment)하는 절차가 필수다. 또한 중복제거와 압축을 합쳐 "데이터 감축률(data reduction ratio)"로 통합 표기하는 경우가 많아, 지표가 순수 중복제거만을 가리키는지 압축·씬 프로비저닝까지 포함하는지 정의를 명확히 구분해 비교해야 한다.

2. 중복제거의 동작 원리와 아키텍처

가. 청킹(Chunking)과 핑거프린팅

중복제거의 첫 단계는 데이터 스트림을 비교 단위인 청크로 분할 하는 것이다. 청킹 방식은 중복제거의 성능과 감축률을 좌우하는 가장 중요한 설계 결정이다. 가장 단순한 고정 길이 청킹(fixed-size chunking) 은 데이터를 4KB·8KB 등 일정 크기로 자른다. 구현이 간단하고 빠르지만, 파일 앞부분에 단 1바이트가 삽입되면 그 뒤 모든 경계가 밀려(boundary shift) 이후 청크가 전부 달라지는 치명적 약점이 있다.

이를 해결한 것이 가변 길이 청킹(CDC, Content-Defined Chunking) 이다. CDC는 데이터 내용 자체로 경계를 정한다. 슬라이딩 윈도를 이동시키며 롤링 해시(rolling hash, 예: Rabin fingerprint) 를 계산하고, 그 값이 특정 조건(예: 하위 n비트가 0)을 만족하는 지점을 청크 경계로 삼는다. 이렇게 하면 데이터가 삽입·삭제되어도 경계가 내용에 고정되므로, 변경된 주변 청크만 달라지고 나머지는 지문이 보존되어 높은 중복 탐지율을 유지한다. 백업·동기화처럼 소규모 변경이 반복되는 워크로드에서 CDC가 사실상 표준인 이유다.

분할된 각 청크는 암호학적 해시 함수(SHA-256 등) 로 지문을 계산한다. 이 지문이 청크의 전역 식별자가 되며, 인덱스에서 동일 지문이 조회되면 중복으로 판정한다. 여기서 이론적으로 서로 다른 청크가 같은 지문을 갖는 해시 충돌 가능성이 제기되지만, SHA-256의 충돌 확률은 천문학적으로 낮아(2^-128 수준) 실무에서는 "지문이 같으면 내용도 같다"고 간주한다. 다만 보수적 설계에서는 지문 일치 후 실제 바이트 비교(byte-level verification)를 추가해 충돌 위험을 원천 차단하기도 한다.

해시 함수의 선택도 성능과 안전성의 트레이드오프다. SHA-256은 충돌 저항성이 강하지만 계산 비용이 커 고속 데이터 경로에서 병목이 될 수 있다. 그래서 일부 시스템은 BLAKE2·BLAKE3처럼 빠르면서도 안전한 해시를 쓰거나, 1차로 빠른 비암호 해시로 후보를 거른 뒤 2차로 강한 해시·바이트 비교로 확정하는 2단 검증을 택한다. 반대로 MD5·SHA-1 같은 약한 해시는 의도적 충돌 생성이 가능해, 공격자가 서로 다른 내용을 같은 지문으로 위장하면 한쪽을 다른 쪽으로 덮어쓰는 데이터 오염(hash collision attack) 위험이 있으므로 보안이 중요한 환경에서는 피해야 한다.

flowchart LR
  IN["입력 데이터 스트림"] --> CHUNK["청킹(CDC 롤링 해시로 경계 결정)"]
  CHUNK --> HASH["청크별 지문 계산(SHA-256)"]
  HASH --> IDX{"지문 인덱스에 존재?"}
  IDX -->|"있음(중복)"| REF["참조 포인터만 기록 + 참조 카운트 증가"]
  IDX -->|"없음(신규)"| STORE["유일 청크 저장 + 인덱스 등록"]
  REF --> META["파일→청크 매핑(레시피) 갱신"]
  STORE --> META
  META --> OUT["논리 뷰는 원본 그대로 유지"]

나. 인덱스·참조 관리 아키텍처와 I/O 경로

중복제거 시스템의 심장은 지문 인덱스(fingerprint index) 와 파일 레시피(file recipe) 다. 지문 인덱스는 "이 지문을 가진 청크가 어디에 저장되어 있는가"를 매핑하고, 파일 레시피는 "이 파일은 어떤 청크들을 어떤 순서로 이어 붙인 것인가"를 기록한 참조 목록이다. 복원 시에는 레시피를 따라 청크를 모아 원본을 재조립한다. 이 구조 덕분에 논리 용량은 변하지 않으면서 물리 용량만 줄어든다.

실무의 가장 큰 난제는 인덱스 크기 다. 8KB 청크로 1PB를 다루면 지문만 수십억 개가 되어 인덱스가 수백 GB에 달하므로 전부 메모리에 올릴 수 없다. 이를 해결하기 위해 블룸 필터(Bloom filter) 로 "확실히 없음"을 빠르게 걸러 디스크 조회를 줄이고, 유사한 지문을 지역성 있게 묶어 캐시 적중률을 높이는 기법(예: Data Domain의 SISL, Stream-Informed Segment Layout)이 쓰인다. 이 디스크 병목(disk bottleneck) 완화가 상용 중복제거 장비 성능의 핵심 경쟁력이다.

sequenceDiagram
  participant C as 클라이언트/백업 서버
  participant D as 중복제거 엔진
  participant I as 지문 인덱스
  participant S as 청크 저장소
  C->>D: 데이터 쓰기 요청
  D->>D: 청킹 + 지문 계산
  D->>I: 지문 조회(블룸 필터 선검사)
  I-->>D: 존재 여부 응답
  alt 중복 청크
    D->>I: 참조 카운트 증가
  else 신규 청크
    D->>S: 청크 저장(선택적 압축)
    D->>I: 지문 인덱스 등록
  end
  D-->>C: 쓰기 완료(레시피 기록)

삭제는 참조 카운트(reference count) 로 관리한다. 여러 파일이 한 청크를 공유하므로, 한 파일을 지워도 참조 카운트가 0이 될 때까지 실제 청크는 삭제하지 못한다. 참조가 0이 된 청크를 회수하는 작업이 가비지 컬렉션(GC) 인데, 수십억 청크의 참조 관계를 안전하게 추적해야 하므로 마크-앤-스윕(mark-and-sweep) 기반의 무거운 백그라운드 작업으로 수행된다. 삭제 즉시 공간이 반환되지 않는 것은 중복제거 운영의 중요한 특성이다.

다. 확장성과 글로벌 중복제거의 한계

단일 노드 중복제거는 그 노드가 본 데이터 안에서만 중복을 제거한다. 그러나 수십 노드로 구성된 스케일아웃 스토리지에서 모든 노드에 걸친 전역 중복제거(global dedup) 를 구현하려면, 어느 노드에 어떤 지문이 있는지를 전 클러스터가 공유해야 하므로 노드 간 지문 조회 트래픽이 폭증한다. 이 때문에 많은 시스템은 데이터를 지문 해시로 특정 노드에 라우팅하는 지문 샤딩 을 써서 같은 지문을 항상 같은 노드로 보내거나, 노드 내에서만 중복을 제거하는 로컬 중복제거 로 타협한다. 즉 중복제거의 감축률과 시스템 확장성은 본질적으로 상충하며, 이 둘의 균형점을 정하는 것이 분산 중복제거 설계의 핵심이다.

청크 크기 선택도 이 확장성 문제와 직결된다. 예컨대 평균 8KB 청크로 100TB의 유일 데이터를 관리하면 지문은 약 130억 개, SHA-256 지문(32바이트)만 해도 400GB가 넘는다. 여기에 참조·위치 메타데이터까지 더하면 메모리에 상주시키기 어려우므로, 앞서 설명한 블룸 필터와 지역성 캐시로 디스크 조회를 최소화하는 설계가 필수가 된다. 반대로 청크를 64KB·128KB로 키우면 메타데이터는 줄지만, 작은 변경에도 큰 청크 전체가 신규로 저장되어 감축률이 떨어진다. 이 감축률-메타데이터-성능 의 삼각 트레이드오프를 워크로드 특성에 맞게 조율하는 것이 실무 튜닝의 요체다.

3. 유형 분류

중복제거는 처리 시점·수행 위치·비교 단위 라는 세 축으로 분류되며, 각 선택은 성능·감축률·자원 사용의 트레이드오프를 낳는다. 아래 표는 비교의 보조 수단이며, 각 축이 왜 그런 차이를 낳는지는 표 뒤에서 서술한다.

분류 축	유형	특징	적합 환경
처리 시점	인라인(Inline)	저장 전 실시간 제거, 쓰기 지연 발생	플래시·충분한 CPU
	포스트프로세스(Post-process)	일단 저장 후 비동기 제거, 임시 공간 필요	쓰기 성능 우선
수행 위치	소스(Source-side)	전송 전 클라이언트에서 제거, 대역폭 절감	원격 백업·WAN
	타깃(Target-side)	저장 장비에서 제거, 클라이언트 부담 없음	LAN·전용 어플라이언스
비교 단위	파일 단위(SIS)	파일 전체 해시 비교, 가볍지만 감축률 낮음	메일 첨부·문서
	블록/바이트 단위	청크 단위 비교, 감축률 높고 연산 무거움	백업·VM 이미지

처리 시점 의 선택은 쓰기 지연과 공간 효율의 맞교환이다. 인라인 방식은 데이터가 디스크에 닿기 전에 중복을 제거하므로 추가 임시 공간이 필요 없고 즉시 감축 효과를 얻지만, 쓰기 경로에 청킹·해싱·인덱스 조회가 끼어들어 지연이 커질 수 있다. 포스트프로세스 방식은 원본을 먼저 빠르게 저장한 뒤 한가한 시간에 중복을 제거하므로 쓰기 성능이 좋지만, 제거 전 원본을 담을 스테이징 공간(landing zone) 이 별도로 필요하다. 플래시·NVMe처럼 CPU 여력이 충분한 고성능 스토리지에서는 인라인이 대세가 되었다.

두 방식의 선택은 결국 워크로드의 성격에 달려 있다. 백업 윈도가 빡빡해 쓰기 처리량이 최우선인 환경에서는 포스트프로세스가 백업 완료 시점을 앞당기는 데 유리하고, 상면·전력 비용이 민감하거나 스테이징 공간 확보가 어려운 환경에서는 인라인이 유리하다. 일부 상용 제품은 두 방식을 조합해, 피크 시간에는 포스트프로세스처럼 동작하다가 유휴 시간에 인라인 수준으로 전환하는 적응형(adaptive) 정책을 제공하기도 한다. 이처럼 처리 시점은 고정된 정답이 아니라 운영 목표(RTO·백업 윈도·TCO)에 맞춰 선택·조정하는 설계 변수다.

수행 위치 는 네트워크 대역폭과 클라이언트 부하의 맞교환이다. 소스 중복제거는 클라이언트가 전송 전에 중복을 제거해 WAN 구간으로 유일 청크만 보내므로, 원격지 백업에서 대역폭을 극적으로 아낀다. 다만 클라이언트가 청킹·해싱 연산을 부담한다. 타깃 중복제거는 저장 장비(어플라이언스)에서 처리하므로 클라이언트는 가볍지만, 중복을 포함한 전량이 네트워크를 통과한다. 지사-본사 백업처럼 대역폭이 귀한 환경에서는 소스 방식이, 데이터센터 내부 LAN에서는 타깃 방식이 흔히 쓰인다.

비교 단위 는 감축률과 연산량의 맞교환이다. 파일 단위 중복제거(SIS, Single Instance Storage)는 파일 전체가 똑같을 때만 제거하므로 가볍지만, 파일 내 1바이트만 달라도 중복으로 보지 못한다. 블록·바이트 단위는 파일 일부만 같아도 공유하므로 감축률이 훨씬 높지만, 관리할 청크와 메타데이터가 폭증한다. 청크 크기를 작게 할수록 감축률은 오르고 인덱스 부담은 커지는 감축률-메타데이터 트레이드오프 가 전형적으로 나타난다.

4. 비교와 적용 사례

가. 중복제거 vs 압축 — 왜 함께 쓰는가

중복제거와 압축은 경쟁 관계가 아니라 보완 관계다. 압축은 단일 블록 내부의 반복 패턴을 지역적으로 제거하므로 텍스트·로그처럼 엔트로피가 낮은 데이터에 효과가 크지만, 서로 떨어진 동일 파일 100벌의 중복은 인식하지 못한다. 반대로 중복제거는 광역의 동일 청크를 제거하지만 청크 내부의 중복은 손대지 않는다. 그래서 상용 스토리지는 중복제거 → 압축 순으로 2단 적용해, 먼저 유일 청크만 남기고 그 청크를 다시 압축한다. 실제로 VM 백업 환경에서 중복제거만으로 10:1을 얻은 뒤 압축으로 추가 2:1을 얻어 총 20:1 의 감축을 달성하는 식의 사례가 흔하다.

순서가 중복제거 먼저인 데는 이유가 있다. 압축을 먼저 하면 동일한 원본이라도 압축 결과가 블록 경계·사전 상태에 따라 미세하게 달라져 중복 탐지가 어려워지기 때문이다. 따라서 "먼저 내용이 같은 청크를 지문으로 묶어 제거하고(중복제거), 남은 유일 청크를 압축한다"는 순서가 감축률 측면에서 유리하다. 다만 이미 JPEG·동영상·암호문처럼 고도로 압축·무작위화된 데이터는 중복제거·압축 모두 효과가 미미하면서 연산 비용만 발생하므로, 이런 데이터 유형은 감축 대상에서 제외하는 정책(dedup/compression bypass)을 두는 것이 합리적이다.

나. 구체 사례와 수치

대표적 상용 사례로 Dell EMC Data Domain 계열은 인라인·가변 청킹·SISL 인덱스 지역화를 결합해 백업 워크로드에서 10~55:1 범위의 감축비를 공표해 왔으며, 이것이 백업 전용 어플라이언스(PBBA) 시장을 연 핵심 기술이다. 오픈소스에서는 ZFS 가 블록 단위 인라인 중복제거를 제공하는데, "청크 1TB당 약 5GB의 RAM"이라는 경험칙이 통용될 만큼 인덱스 메모리 비용이 커서, 무분별한 활성화 시 성능 저하를 겪는 사례가 자주 보고된다. 백업 소프트웨어 Veeam 은 소스/타깃 중복제거와 압축을 조합해 일상적으로 변경분 백업에서 큰 감축을 얻는다. 클라우드 백업 서비스 역시 소스 중복제거로 전송·저장량을 줄여, 사용량 과금 모델에서 네트워크·스토리지 비용을 직접 낮추는 핵심 수단으로 활용한다.

컨테이너 생태계의 도커 이미지 레이어 역시 콘텐츠 주소화 기반 중복제거의 일종으로 볼 수 있다. 여러 이미지가 동일한 베이스 레이어(예: 같은 우분투 계층)를 공유하면 그 레이어는 디스크·레지스트리에 한 번만 저장되고 참조로 공유된다. 마찬가지로 Git의 객체 저장소도 내용 해시(SHA-1/256)로 블롭을 식별해 동일 내용을 한 번만 보관하는 콘텐츠 주소화의 전형이다. 즉 중복제거의 원리는 전용 스토리지 장비를 넘어 버전관리·클라우드 네이티브 소프트웨어 설계 전반에 깊이 스며들어 있다.

다. 가상 데스크톱(VDI)·메일 아카이빙 사례

가상 데스크톱 인프라(VDI)는 중복제거의 효과가 극적으로 드러나는 대표 사례다. 수천 명의 사용자가 거의 동일한 OS·오피스 이미지를 사용하는 VDI에서, 블록 단위 중복제거를 적용하면 공통 OS 영역이 사실상 1벌만 물리 저장되어 수십 대 1 의 감축이 나타나며, 부팅 스톰(boot storm) 시 공통 블록이 캐시에 집중 적중해 성능까지 개선되는 부수 효과도 생긴다. 메일 아카이빙에서도 동일 첨부가 수신자 수만큼 복제되던 것이 파일·블록 단위 중복제거로 하나로 수렴해, 규제 대응을 위한 장기 보관 비용을 크게 낮춘다. 이처럼 "다수가 거의 같은 데이터를 쓰는" 구조일수록 중복제거의 투자 대비 효과(ROI)가 커진다.

5. 심화 — 최신 동향과 적용 확장

중복제거 기술은 네 방향으로 진화하고 있다. 첫째, 올플래시·NVMe 스토리지로의 이동 이다. 과거 중복제거는 복원 시 청크가 디스크 곳곳에 흩어져 발생하는 단편화 때문에 HDD에서 성능 손해가 컸으나, 임의 접근 지연이 거의 없는 플래시에서는 이 페널티가 사실상 사라졌다. 그 결과 프라이머리(운영계) 올플래시 어레이에서도 인라인 중복제거를 상시 켜 두는 것이 표준이 되었고, Pure Storage·NetApp 등은 중복제거+압축+씬 프로비저닝을 묶은 데이터 감축(data reduction) 을 기본 기능으로 제공한다. 나아가 플래시는 쓰기 수명(마모)이 유한하므로, 중복 쓰기를 원천 제거하는 중복제거가 실제 기록량을 줄여 SSD 수명 연장 에까지 기여한다는 점도 운영계 상시 적용을 뒷받침하는 요인이다.

둘째, 보안·프라이버시와의 긴장 이다. 클라우드 멀티테넌트 환경에서 사용자 간 중복제거(cross-user dedup)는 공간을 크게 아끼지만, "파일이 이미 서버에 있는지" 여부가 응답 속도로 드러나는 사이드 채널 공격 과, 서버에서 중복제거를 하려면 데이터를 평문으로 봐야 하는 종단간 암호화와의 충돌 문제를 낳는다. 이를 완화하기 위해 동일 평문이 동일 암호문이 되도록 하는 수렴 암호화(convergent encryption), 그리고 소유 증명(PoW, Proof of Ownership) 기법이 연구·적용되고 있다. 다만 수렴 암호화는 사전 공격(known-plaintext)에 취약하다는 한계가 있어, 보안과 공간 효율의 트레이드오프를 신중히 평가해야 한다.

셋째, AI·대용량 데이터셋으로의 확장 이다. 대규모 언어모델 학습 데이터에는 웹 크롤링으로 수집된 중복·근접중복 문서가 대량 포함되는데, 최근 연구는 학습 데이터 중복제거가 저장 비용 절감을 넘어 모델 품질 향상(암기 감소·일반화 개선) 과 학습 효율에 직접 기여함을 보고한다. 또한 내용이 완전히 같지는 않지만 유사한 데이터를 묶는 근접중복제거(near-dedup), 델타 인코딩과 결합한 하이브리드 감축도 백업·아카이브 영역에서 확대되고 있다. 이처럼 중복제거는 스토리지 비용 최적화 기술에서 데이터 품질·거버넌스 기술로 외연을 넓히는 중이다.

넷째, 컴퓨팅 스토리지·오프로딩 이다. 청킹·해싱·압축은 CPU 집약적 연산이어서 프라이머리 스토리지의 응답 지연에 부담을 준다. 이를 완화하기 위해 DPU(Data Processing Unit)나 연산 기능을 내장한 컴퓨티드 스토리지 드라이브(CSD)로 중복제거 연산을 오프로딩하는 접근이 등장했다. 이렇게 하면 호스트 CPU는 애플리케이션 처리에 집중하고 데이터 감축은 전용 하드웨어가 전담하므로, 올플래시 환경에서 "상시 중복제거"의 성능 비용을 더욱 낮출 수 있다. 중복제거가 소프트웨어 기능에서 데이터 경로상의 하드웨어 가속 기능으로 이동하는 흐름으로, 암호화·소거 코딩 오프로딩과 같은 맥락에서 이해할 수 있다.

6. 고려사항 및 시사점

중복제거는 "공짜 용량 절감"처럼 보이지만, 실제로는 성능·무결성·보안·거버넌스 전반에 걸친 설계 판단을 요구하는 기술이다.

데이터 중복제거를 도입·운영할 때 정보관리기술사 관점에서 고려할 전략적 항목은 다음과 같다.

데이터 특성 기반 선별 적용(적용 전략): 모든 데이터가 중복제거 대상은 아니다. 백업·VM·파일 공유처럼 중복이 많은 데이터는 효과가 크지만, 이미 압축·암호화된 미디어나 고유한 측정 데이터는 감축률이 낮으면서 연산 비용만 유발한다. 워크로드별 감축률을 사전 평가해 선별 적용하고, 프라이머리 vs 백업 계층에 맞는 방식(인라인/포스트프로세스)을 구분해 설계해야 한다.
성능-용량 트레이드오프의 정량화(트레이드오프): 청크 크기를 줄이면 감축률은 오르지만 인덱스 메모리와 CPU 부담, 복원 단편화가 커진다. RTO(복구 목표 시간)가 엄격한 업무라면 과도한 감축보다 복원 성능을 우선해 청크를 키우거나 포스트프로세스를 택하는 균형이 필요하다. ZFS의 "1TB당 5GB RAM" 사례처럼, 자원 산정을 소홀히 하면 오히려 성능이 붕괴한다.
데이터 무결성과 단일 장애 전파 위험(가용성): 중복제거는 다수 데이터가 소수 유일 청크를 공유하므로, 하나의 청크 손상이 광범위한 데이터 손실로 번진다. 반드시 엔드투엔드 체크섬, 주기적 스크러빙, RAID·EC·복제 등 하부 데이터 보호와 병행해야 하며, 중복제거를 "백업의 대체"가 아니라 "저장 효율화"로 한정해 3-2-1 백업 원칙과 결합해야 한다.
보안·규제와 삭제 보장(거버넌스): 참조 공유 구조에서는 한 파일 삭제가 즉시 물리 삭제로 이어지지 않아, 개인정보의 완전 파기(right to erasure) 요구와 충돌할 수 있다. GC 주기와 파기 증빙 체계를 명확히 하고, 멀티테넌트 환경에서는 테넌트 간 중복제거의 사이드 채널·암호화 충돌을 평가해 테넌트 내로 범위를 제한하는 등의 정책이 필요하다.
전망과 연계 기술(전망): 중복제거는 압축·씬 프로비저닝·계층화(tiering)와 묶인 데이터 감축 플랫폼으로, 그리고 AI 데이터 파이프라인의 품질 관리 단계로 외연을 넓히고 있다. 컴퓨팅 스토리지·DPU로의 오프로딩, 소거 코딩·CDP(지속적 데이터 보호)와의 결합을 함께 조망하면 기술 선택의 시야가 넓어진다.

참고자료

Dell Technologies, "Data Domain / PowerProtect DD Deduplication" — https://www.dell.com/en-us/dt/data-protection/powerprotect-dd-series-appliances.htm
OpenZFS Documentation, "Deduplication" — https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Deduplication.html
Lee et al., "Deduplicating Training Data Makes Language Models Better" (ACL 2022) — https://arxiv.org/abs/2107.06499
NIST, "Guide to Storage Encryption / Data Reduction considerations" — https://csrc.nist.gov/

한 줄 요약: 데이터 중복제거는 데이터를 청크로 나눠 해시 지문으로 식별하고 동일 청크를 참조로 대체해 물리 용량을 줄이는 콘텐츠 주소화 기반 용량 최적화 기법으로, 청킹·인덱스·참조관리의 설계와 성능·무결성·보안 트레이드오프를 함께 고려해야 한다.