[NHN FORWARD 22] 델타 인코딩 적용을 통한 Dooray! 드라이브 업로드 다운로드 성능 향상기

동기화 앱이 폴더를 주기적으로 모니터링해 변경을 감지하고 서버와 주고받는 흐름을 설명한다. 문제는 앱도 서버도 어느 부분이 바뀌었는지 몰라, 파일 일부만 수정돼도 전체 파일이 업로드되고 다른 사용자에게 전체가 다운로드되는 비효율 구조라는 점을 지적한다.

변경된 부분만 전달하는 방식인 델타 인코딩을 소개한다. rsync·Dropbox·구글 플레이 APK 업데이트 등에서 이미 쓰이며, 비교하려면 원본 대신 훨씬 작은 파일이 필요하다는 아이디어를 제시한다. 파일을 일정 크기 블록으로 잘라 체크섬을 계산한 시그니처로 비교한다.

위크해시 2개를 쓰는 rsync 스타일과 스트롱해시만 쓰는 Dropbox 스타일 시그니처를 비교하고, 계산이 빠른 rsync 스타일을 택한 이유를 설명한다. 파일 A·B를 같은 블록 사이즈로 잘라 해시를 비교하면 몇 번의 비교로 동일 여부를 판단할 수 있고, 뒷부분 추가는 마지막 블록만 다르게 잡힌다.

파일 앞부분에 데이터가 추가되면 모든 블록이 한 칸씩 밀려 전체가 다르게 판단되는 문제를, 롤링 해시로 해결한다. 슬라이딩 윈도우로 한 바이트씩 이동하며 해시를 계산하되, 빠지는 값을 빼고 들어오는 값을 더해 이전 해시를 재사용함으로써 재계산 오버헤드를 최소화한다. 매치되면 블록째 건너뛴다.

철수와 영희가 파일을 공유하는 예시로 델타 인코딩 전 과정을 시연한다. 철수가 영희에게 시그니처를 요청받아 블록별로 위크해시·스트롱해시를 비교하며, 매치되면 레퍼런스 타입(오프셋·길이)으로, 아니면 데이터 타입으로 인스트럭션을 만든다. 영희는 이 인스트럭션으로 새 파일을 재구성한다.

델타 인코딩을 클라이언트→서버, 서버→클라이언트 두 방향으로 적용한 구조를 설명한다. 각 방향 모두 시그니처 요청·비교·인스트럭션 전달로 한 스텝 늘지만, 실제 전달 데이터는 변경분만큼이라 전체 파일 전송보다 훨씬 효과적이다.

시그니처 생성이 파일 크기에 비례해 느려지는 문제를 업로드 시점에 파이프로 미리 생성·캐시해 해결하고, 서버가 받은 인스트럭션을 저장·재사용해 다수 사용자 반영 시 즉시 응답한다. 다만 동기화 앱에서만 효과가 있고 브라우저·모바일은 제외라는 점, 시그니처 저장 공간 등 남은 고민과 위키·공동 편집 확장 계획을 공유한다.