delta-compression

2 개의 포스트

공유 사전: 에이전틱 웹에 발맞춘 압축 기술 (새 탭에서 열림)

웹 페이지의 무게가 매년 증가하고 에이전트 기반의 트래픽이 급증하는 현대 웹 환경에서, 공유 사전(Shared Dictionaries) 기술은 대역폭 낭비를 획기적으로 줄일 수 있는 핵심 솔루션입니다. 이 기술은 클라이언트가 이미 캐시한 데이터를 사전으로 활용해 변경된 차이점(Delta)만 전송함으로써, 잦은 배포와 무거운 에셋 환경에서도 로딩 속도를 극대화하고 서버 부하를 최소화합니다. 클라우드플레어는 이러한 압축 표준인 RFC 9842 지원을 통해 효율적인 에이전틱 웹(Agentic Web) 시대를 대비하고자 합니다. ### 빈번한 배포와 캐싱 효율의 저하 * **에이전트 트래픽의 급증:** AI 크롤러와 에이전트 기반 도구들이 전체 요청의 상당 부분을 차지하며, 이들은 정보를 추출하기 위해 전체 페이지를 반복적으로 호출합니다. * **AI 기반 개발 가속화:** AI 보조 개발로 인해 팀들의 배포 주기가 짧아졌으나, 이는 곧 캐시 무효화의 빈도를 높여 단 몇 줄의 코드 수정만으로도 사용자가 전체 JS/CSS 번들을 다시 다운로드하게 만듭니다. * **중복 데이터 전송:** 기존 압축 방식은 파일 내부의 중복은 줄여주지만, 클라이언트가 이미 95% 동일한 파일을 가지고 있다는 사실을 인지하지 못해 수백 메가바이트의 불필요한 데이터를 전송하게 됩니다. ### 공유 사전과 델타 압축의 메커니즘 * **참조 기반 압축:** 서버와 클라이언트가 공통의 '사전(Dictionary)'을 공유하여, 서버는 "이미 알고 있는 내용은 제외하고 새로운 부분만 보낸다"는 방식으로 데이터를 압축합니다. * **델타 압축(Delta Compression):** 브라우저에 이미 캐시된 이전 버전의 리소스를 사전으로 변환합니다. 예를 들어 500KB 크기의 번들에서 한 줄의 코드만 수정되었다면, 실제 네트워크를 통해 전송되는 크기는 몇 KB 수준으로 줄어듭니다. * **HTTP 헤더 활용:** 서버가 `Use-As-Dictionary` 헤더를 통해 특정 파일을 사전으로 지정하면, 브라우저는 다음 요청 시 `Available-Dictionary` 헤더를 통해 자신이 가진 사전을 서버에 알리고 차이점만 수신합니다. * **지속적인 절감:** 버전 1과 버전 2 사이의 차이점만 전송하고, 다시 버전 2를 사전 삼아 버전 3의 차이점만 전송하는 방식으로 배포 횟수가 늘어나도 데이터 절감 효과가 누적됩니다. ### 과거의 한계 극복과 보안 강화 * **SDCH의 실패와 교훈:** 2008년 구글이 시도했던 SDCH는 성능은 좋았으나 CRIME, BREACH 같은 압축 사이드 채널 공격에 취약했고 동일 출처 정책(Same-Origin Policy) 위반 이슈로 퇴출되었습니다. * **RFC 9842 표준:** 최신 표준인 'Compression Dictionary Transport'는 사전을 동일 출처 응답에만 사용할 수 있도록 강제하여 보안 취약점을 해결했습니다. * **브라우저 지원 현황:** 크롬과 엣지는 이미 지원을 시작했으며 파이어폭스도 도입을 준비 중입니다. 이는 단순한 압축 기술을 넘어 복잡한 캐싱 로직과 실시간 델타 압축을 결합한 고난도 기술 구현의 결과물입니다. 잦은 업데이트가 발생하는 모바일 앱의 웹뷰나 대규모 자바스크립트 프레임워크를 사용하는 프로젝트라면, 공유 사전 기술 도입을 통해 사용자 경험을 혁신할 수 있습니다. 특히 네트워크 환경이 불안정한 사용자나 데이터 비용이 민감한 환경에서 그 가치는 더욱 빛을 발할 것입니다.

개발 속도 향상을 위한 모노레포 크기 줄이기 (새 탭에서 열림)

Dropbox는 87GB에 달하던 서버 모노레포 크기를 20GB로 약 77% 줄여 개발자 속도와 CI 효율성을 획기적으로 개선했습니다. 이 과정에서 Git의 기본 델타 압축 알고리즘이 특정 디렉토리 구조에서 비효율적으로 작동한다는 점을 발견했으며, GitHub 팀과 협력하여 최적화된 리팩(Repack) 설정을 적용해 저장소 용량 한계 문제를 해결했습니다. 결과적으로 1시간 이상 걸리던 클론 시간을 15분 미만으로 단축하며 운영상의 리스크를 제거했습니다. ### 대규모 모노레포 성장이 유발하는 운영 병목 - 저장소 크기가 87GB를 넘어서면서 초기 개발 환경 구축을 위한 클론 시간이 1시간을 초과했고, 이는 매번 신규 클론을 수행하는 CI(지속적 통합) 파이프라인의 성능 저하로 이어졌습니다. - 코드 데이터는 매일 20~60MB씩 증가하며 GitHub Enterprise Cloud의 하드 리밋인 100GB에 근접해 가고 있었으며, 이는 단순한 코드 양의 증가라기보다 저장 방식의 구조적 결함에 의한 현상이었습니다. - 내부 동기화 시스템의 타임아웃 발생 빈도가 높아지는 등 저장소 크기 자체가 엔지니어링 루프 전체를 느리게 만드는 핵심 원인이 되었습니다. ### Git 델타 압축 알고리즘과 디렉토리 구조의 충돌 - Git은 파일 간의 차이점(Delta)만 저장하여 용량을 줄이는데, 비교 대상 파일을 선정할 때 파일 경로의 '마지막 16자'만을 참조하는 휴리스틱 방식을 사용합니다. - Dropbox의 다국어(i18n) 파일 구조는 `i18n/[언어코드]/LC_MESSAGES/[파일명].po` 형태였는데, 언어 코드가 경로 중간에 있어 Git은 서로 다른 언어의 동일 파일명을 가진 파일들을 비교 대상으로 묶었습니다. - 내용이 전혀 다른 언어 간의 파일을 비교하다 보니 압축 효율이 극도로 낮아졌고, 아주 작은 번역 수정에도 불필요하게 큰 팩(Pack) 파일이 생성되는 결과로 이어졌습니다. ### GitHub 서버 측 리팩 최적화를 통한 문제 해결 - 실험적 플래그인 `--path-walk`를 사용하면 파일 경로 전체를 탐색해 압축 효율을 극대화할 수 있음을 로컬 테스트로 확인했으나, 이는 GitHub 서버의 비트맵 및 델타 아일랜드 최적화 기능과 호환되지 않았습니다. - 로컬에서 최적화하여 푸시하더라도 GitHub 서버가 전송 시 자체 설정으로 다시 팩을 구성하기 때문에, GitHub 지원팀과 협력하여 서버 측 리팩 설정을 조정하는 방식을 택했습니다. - Git이 더 넓고 깊게 유사성을 검색할 수 있도록 `window`와 `depth` 매개변수를 각각 250으로 상향 조정한 공격적인 리팩을 수행하여, 데이터 손실 없이 저장소 크기를 20GB 수준으로 압축하는 데 성공했습니다. ### 대규모 저장소 관리를 위한 제언 - 모노레포의 크기가 비정상적으로 급증한다면 단순한 바이너리 파일 유입뿐만 아니라, Git의 델타 압축 메커니즘과 현재의 디렉토리 구조가 상충하고 있지는 않은지 점검해야 합니다. - 저장소 최적화는 클라이언트 단의 노력만으로는 한계가 있으며, 호스팅 서비스(GitHub 등)의 서버 측 리팩 설정과 인프라 호환성을 반드시 고려하여 전략을 수립해야 합니다.