이 문서는 Large Object Promisors(LOP)를 활용해 대용량 blob을 별도의 원격으로 분리·관리하는 방식, 클라이언트와 서버 간 프로토콜 협상, 메인 원격과 LOP 간 오프로드 전략, 구현 고려사항과 보안, FAQ 및 향후 개선 과제를 설명합니다. 이를 통해 저장 비용 절감, 성능 향상, 설정 단순화 등 실질적 이점을 제공하는 방법을 다룹니다.
다시 말해, 이 문서의 목표는 Git이 대용량 blob을 처리하는 모든 가능한 최적화 방법을 논하는 것이 아니라, LOP 기반 솔루션이 이미 어떻게 잘 동작할 수 있으며 Git 클라이언트와 서버가 Git 객체를 공유하는 맥락에서 현재의 여러 문제를 완화할 수 있는지를 설명하는 것입니다.
LOP를 그다지 효율적으로 사용하지 않더라도, 다음에서 자세히 보듯이 어떤 경우에는 여전히 유용하며 사용할 가치가 있습니다:
GitLab 저장소에 대한 일부 통계에 따르면 디스크 공간의 75% 이상이 1MB보다 크고 종종 바이너리 형식인 blob이 차지합니다.
따라서 사용자가 Git LFS나 유사 도구를 사용해 많은 대용량 blob을 저장소 밖에 보관할 수 있다 하더라도, 실제로는 그렇게 충분히 하지 않는 경우가 많습니다.
서버 측에서 이상적인 상태는, 서버가 스스로 어떤 방식으로 데이터를 저장할지 결정할 수 있어야 한다는 것입니다. 즉, 사용자가 어떤 blob에 Git LFS 같은 도구를 쓸지 말지에 의존하지 않아야 합니다.
델타 압축이 잘 되지 않는 대용량 blob을 일반적인 빠른 시킹 드라이브(SSD 등)에 저장하는 것은 객체 스토리지(Amazon S3, GCP Buckets 등)에 저장하는 것보다 훨씬 비용이 큽니다. 일반 Git 저장소의 경우에는 텍스트나 코드가 들어 있는 비교적 작은 blob을 빠르게 시킹할 수 있는 드라이브가 적합하므로 빠른 드라이브를 쓰는 것이 타당합니다. 반면 Git LFS blob은 파일이 크기 때문에 시킹 속도가 그리 중요하지 않고 비용이 더 중요하므로 객체 스토리지가 적합합니다. 따라서 사용자가 상당수의 대용량 blob에 Git LFS나 유사 도구를 사용하지 않는 사실은 대부분의 Git 호스팅 플랫폼에서 저장 비용 측면에서 좋지 않은 결과를 초래할 수 있습니다.
대용량 blob을 객체 스토리지 대신 Git 저장소 내의 다른 blob 및 Git 객체와 동일한 방식으로 다루면, 팩 파일 생성 시 메모리 및 CPU 사용량이 증가해 성능이 저하되는 비용도 발생합니다. (Git은 델타 압축이나 zlib 압축을 시도하지만 이미 압축된 바이너리 콘텐츠에는 잘 작동하지 않는 경우가 많기 때문입니다.) 따라서 이는 단순히 저장 비용 증가에 그치지 않습니다.
대용량 blob이 한 번 저장소에 커밋되면, 사용자가 이후에 Git LFS나 유사 도구를 사용하기로 결정하더라도 기록을 다시 쓰지 않고서는 그 blob을 저장소에서 제거하지 못할 수 있습니다.
사실 Git LFS 및 유사 도구는 어떤 blob을 처리할지에 대해 사용자가 마음을 바꾸는 데 유연하지 않습니다.
심지어 사용자가 Git LFS나 유사 도구를 사용할 때에도, 설정, 학습, 올바른 사용에 상당한 노력이 든다고 종종 불평합니다.
아래의 주요 기능은 솔루션이 어떻게 동작할 수 있는지 대략적인 개요를 제공합니다. 필요한 요소에 대한 세부 사항은 뒤따르는 절에서 확인할 수 있습니다.
아래의 각 기능은 전체 솔루션에 매우 유용하지만, 전체 솔루션이 필요하지 않은 경우에도 개별적으로 유용할 가능성이 큽니다. 다만 여기서는 큰 그림에 초점을 맞추겠습니다.
또한 각 기능이 반드시 Git 자체에 전부 구현될 필요는 없습니다. 일부는 Git 저장소의 일부가 아닌 스크립트, 훅, 도우미 프로그램일 수도 있습니다. 다만 그것들이 공동으로 공유되고 개선될 수 있으면 도움이 됩니다. 따라서 공유를 장려하고자 합니다.
대용량 blob은 "Large Object Promisors" 또는 LOP라 부르는 특별한 promisor 원격에 저장해야 합니다. 이러한 LOP는 특히 바이너리 형식의 대용량 blob을 보관하는 데 전용인 추가 원격이 되어야 합니다. 다른 객체를 담는 주요 원격과 함께 사용합니다.
참고 1
++++++
명확히 하자면, LOP는 일반적인 promisor 원격이지만 다음과 같은 차이가 있습니다:
- 대용량 blob만 저장해야 합니다.
- 주요 원격과 분리되어야 하며, 이렇게 하면 주요 원격은 다른 객체와 저장소의 나머지 부분(아래 기능 4 참조)을 제공하는 데 집중할 수 있고, 자신을 위한 promisor 원격으로 LOP를 사용할 수 있습니다.
참고 2
++++++
Git은 이미 클라이언트가 blob 크기에 대한 필터를 사용하여 클론할 때, 주요 원격이 promisor 원격이면서 동시에 일반 객체와 대용량 blob을 함께 저장하는 방식을 지원합니다. 하지만 여기서는 이를 명시적으로 피하고자 합니다.
이유
++++
LOP는 대용량 blob을 잘 처리하는 것을 목표로 하며, 주요 원격은 이미 다른 객체를 잘 처리합니다.
구현
++++
Git은 다중 promisor 원격을 이미 지원합니다. link:/docs/partial-clone#using-many-promisor-remotes[부분 클론 문서]를 참고하십시오.
또한 Git은 blob 크기를 기준으로 필터링하는 부분 클론(`git clone --filter=blob:limit=<size>`)도 이미 지원합니다. 아래의 다른 주요 기능 대부분은 이러한 기존 기능을 바탕으로 하며, 대용량 blob을 더 잘 처리하기 위한 용도로 이것들을 쉽게 효율적으로 사용할 수 있게 하는 데 초점을 둡니다.
2) LOP는 객체 스토리지를 사용할 수 있습니다
LOP는 실제로 대용량 blob을 저장하기 위해 Amazon S3, GCP Bucket, MinIO(GNU AGPLv3 라이선스의 오픈 소스) 같은 객체 스토리지를 사용해 구현할 수 있으며, Git에는 이를 원격처럼 보이게 하는 Git 원격 도우미(참고: https://git-scm.com/docs/gitremote-helpers)를 통해 접근할 수 있습니다.
참고 ++++
LOP는 일부 클라이언트와 주요 원격이 모두 원격 도우미를 통해 접근하는 promisor 원격이 될 수 있습니다.
이유 ++++
이는 많은 대용량 blob을 저비용으로 처리하는 LOP를 만드는 가장 단순한 방법으로 보입니다.
구현 ++++
원격 도우미는 셸 스크립트로도 비교적 쉽게 작성할 수 있지만, Go 같은 다른 언어로 작성하는 것이 더 효율적이고 유지보수에 유리할 수 있습니다.
오픈 소스 라이선스로 이미 존재하는 예:
LOP를 구현하는 다른 방법도 분명 가능하지만, 이 문서의 목표는 LOP 또는 그 기저 객체 스토리지를 어떻게 가장 잘 구현할지 논의하는 것이 아닙니다(위의 "0) Non goals" 절 참조).
LOP가 사용하는 기저 객체 스토리지는 Git LFS가 처리하는 대용량 파일의 스토리지로도 사용할 수 있습니다.
이유
++++
서버 측에서 LOP도 사용하고 Git LFS 서버 역할도 함께 하려는 경우 구성이 단순해집니다.
4) 주요 원격은 구성 가능한 임계값으로 LOP에 오프로드할 수 있습니다
서버 측에서 주요 원격은 크기가 구성 가능한 임계값을 초과하는 모든 blob을 LOP로 오프로드할 수 있어야 합니다.
이유 ++++
이 방식은 설정과 정리를 쉽게 만듭니다. 예를 들어, 관리자는 LOP를 사용하지 않는 저장소를 LOP를 사용하는 저장소로 수동 변환하는 데 이를 사용할 수 있습니다. 이미 LOP를 사용하는 저장소에서 일부 사용자가 가끔 대용량 blob을 푸시하는 경우, 크론 잡으로 이를 정기적으로 LOP로 이동해 대용량 blob이 주요 원격에 남지 않도록 할 수 있습니다.
구현 ++++
오프로드할 blob과 다른 Git 객체를 분리하기 위해 git repack --filter=... 기반의 방법을 사용하는 것이 좋은 아이디어일 수 있습니다. 부족한 부분은 LOP에 연결해 오프로드하려는 blob이 이미 존재하는지 확인하고, 없다면 전송하는 것입니다.
주요 원격은 과도하게 큰 blob을 다량 포함하지 않도록 해야 합니다. 이를 위해 필요 시 LOP로 오프로드하고, 과대 크기 blob이 가져와지거나, 가능하면 푸시되는 것 역시 방지할 수 있어야 합니다.
이유
++++
많은 과대 크기 blob을 포함한 주요 원격은 LOP의 목적을 무색하게 만듭니다.
구현
++++
위 4)에서 논의한 LOP로의 오프로드 방법을 사용해 과대 크기 blob을 정기적으로 오프로드할 수 있습니다. 과대 크기 blob이 저장소로 가져와지는 것을 방지하는 방법은 아래 6)을 참조하십시오. 과대 크기 blob 푸시를 방지하려면 pre-receive 훅을 사용할 수 있습니다.
또한 대용량 blob이 주요 원격으로 가져와질 수 있는 여러 시나리오가 있습니다. 예를 들어:
- "promisor-remote" 프로토콜(아래 6에서 설명)을 구현하지 않은 클라이언트가 주요 원격에서 클론하는 경우.
- 주요 원격이 대용량 blob에 대한 정보를 요청받았을 때, 그 정보를 LOP에서 blob을 가져오지 않고는 얻을 수 없는 경우.
이러한 시나리오를 완전히 방지하지 못할 수도 있습니다. 따라서 여기서의 목표는 대용량 blob의 가져오기를 덜 일어나게 만드는 기능을 구현하는 것입니다. 예를 들어 `git cat-file --batch` 프로토콜과 그 변형에 `remote-object-info` 명령을 추가하면, 주요 저장소가 대용량 blob을 가져오지 않고도 일부 요청에 응답할 수 있게 될 수 있습니다.
6) 클라이언트가 클론할 때 프로토콜 협상이 이루어져야 합니다
클라이언트가 주요 저장소에서 클론할 때, 서버가 하나 이상의 LOP를 광고하고, 클라이언트와 서버가 클라이언트가 서버가 광고하는 LOP를 직접 사용할 수 있는지 논의할 수 있도록 프로토콜 협상이 있어야 합니다. 클라이언트와 서버가 이에 합의하면, 클라이언트는 대용량 blob을 LOP에서 직접 가져올 수 있고, 서버는 클라이언트를 서비스하기 위해 LOP에서 그 blob들을 가져올 필요가 없습니다.
참고 ++++
클론이 아닌 가져오기(fetch)의 경우에는 항상 프로토콜 협상이 일어나지 않을 수 있습니다. 자세한 내용은 아래 FAQ의 "가져오기는 어떻습니까?" 항목을 참조하십시오.
이유 ++++
보안, 구성 가능성, 설정 효율성.
구현 ++++
"promisor-remote" 프로토콜 v2 capability가 이를 구현하는 좋은 방법으로 보입니다. 클라이언트와 서버가 이 capability를 사용하는 방식은 구성 변수로 제어할 수 있습니다.
서버가 이 프로토콜을 통해 클라이언트에 보낼 수 있는 정보에는 다음과 같은 것들이 있습니다: LOP 이름, LOP URL, filter-spec(예: blob:limit=<size>) 또는 클론 시 필터로 사용해야 할 단순 크기 제한, LOP에서 사용할 토큰 등.
클라이언트가 사용하는 LOP가 주요 원격의 LOP이기도 한 경우, 클라이언트는 가져왔지만 더 이상 필요하지 않을 수 있는 일부 대용량 blob을 LOP로 오프로드할 수 있어야 합니다.
참고
++++
클라이언트가 생성한 대용량 blob을, 어떤 방식으로든 주요 원격이 확인(아마도 훅이나 다른 도구 사용)하지 않고 바로 LOP로 오프로드하는 것이 가능한지 여부는 상황에 따라 달라질 수 있습니다.
이 부분은 해당 기능 구현에 가까워졌을 때 논의하고 정교화해야 합니다.
이유
++++
클라이언트에서 불필요해진 대용량 blob을 처리하는 가장 쉬운 방법은 그것들을 오프로드하는 것입니다.
구현
++++
이는 4)에서 다룬 내용과 매우 유사하지만, 서버 측이 아닌 클라이언트 측에서의 동작입니다. 따라서 4)에 대한 좋은 해법은 클라이언트 측에서도 작동하도록 쉽게 적용할 수 있을 것입니다.
여기에는 협상이 없으므로 보안 문제가 있을 수 있으나, 클론 시 획득한 토큰을 재사용할 수 있다면(위 6 참조) 이를 완화할 수 있습니다. 또한 대용량 blob이 LOP에서 가져온 것이라면, LOP에 여전히 존재한다는 가능성이 높고 쉽게 확인할 수 있으므로 클라이언트에서는 단순히 제거해도 됩니다.
III) LOP 사용의 이점
--------------------
많은 이점은 위의 "I) 현재 상황의 문제"에서 논의한 문제와 관련이 있습니다:
- 어떤 blob을 다른 객체와 분리해 처리할지, 혹은 임계값을 이동하거나 제거할지를 결정할 때 기록을 다시 쓸 필요가 없습니다.
- 클라이언트와 서버 간 프로토콜이 충분히 개발되고 보안이 확보된다면, 많은 세부사항을 서버 측에서만 설정하고, 모든 클라이언트가 필요한 구성 정보를 손쉽게 받아 대체로 자동으로 자신을 설정하도록 할 수 있습니다.
- 서버 측 저장 비용 절감.
- 서버 측 주요 원격의 메모리·CPU 필요량 감소.
- 클라이언트 측 저장소 사용량 감소.
IV) 자주 묻는 질문(FAQ)
-----------------------
서버와 클라이언트 측에서 여러 개의 LOP를 사용하는 것은 어떻습니까?
어떤 경우에는 도움이 될 수 있지만, 현재로서는 대부분의 경우 서버가 단일 LOP를 광고하고 클라이언트가 이를 사용하게 되는 상황이 더 일반적일 것입니다.
서버가 여러 LOP를 광고하는 것이 유용할 수 있는 사례로는, 일부 사용자에게는 한 LOP가 더 적합하고 다른 사용자에게는 다른 LOP가 더 적합한 경우가 있습니다. 예를 들어 일부 클라이언트는 특정 LOP에 더 좋은 네트워크 연결을 가질 수 있습니다.
이러한 경우, 클라이언트를 돕기 위한 문서를 제공하는 것은 서버의 책임입니다. 예를 들어 "이 지역의 사용자는 LOP A만 선택하는 것이 연결 상태상 유리할 수 있으며, 다른 지역의 사용자는 같은 이유로 LOP B만 선택해야 합니다"와 같은 안내가 있을 수 있습니다.
서버가 광고하는 LOP를 언제 신뢰해야 하며, 언제 신뢰하지 말아야 합니까?
서버와 모든 클라이언트가 회사 내부 네트워크의 일부이고, 관리자가 모든 시스템에 대한 권한을 가진 기업 환경 같은 맥락에서는, 클라이언트가 서버를 전적으로 신뢰하는 것이 괜찮고 심지어 좋은 일일 수 있습니다. 이는 모든 클라이언트가 동일한 기준을 유지하도록 돕기 때문입니다.
또한 일부 저장소를 제공하는 코드 호스팅 플랫폼을 클라이언트가 신뢰하지만, 해당 저장소 일부를 관리하거나 기여하는 다른 사용자까지 전적으로 신뢰하지는 않는 맥락도 있습니다. 예를 들어 코드 호스팅 플랫폼은 자신이 받는 모든 객체에 악성코드나 나쁜 콘텐츠가 없는지 검사하는 훅을 갖추고 있을 수 있습니다. 이 경우 주요 원격과 그 LOP가 모두 코드 호스팅 플랫폼에 의해 호스팅된다면 클라이언트가 이를 사용하는 것이 괜찮을 수 있으나, LOP가 다른 곳에서 호스팅된다면(콘텐츠가 검사되지 않는 곳이라면) 그렇지 않을 수 있습니다.
다른 맥락에서는, 클라이언트가 서버를 전혀 신뢰해서는 안 될 수도 있습니다.
따라서 클라이언트가 클론 시 서버가 광고하는 LOP에 대해 어떻게 동작해야 하는지를 구성하는 다양한 방법이 있어야 합니다.
서버가 LOP에 대해 광고할 수 있는 기본 요소는 LOP 이름과 LOP URL이므로, 클라이언트는 이 요소를 바탕으로 LOP 수용 여부를 결정해야 합니다.
가장 엄격하게 LOP를 수용하는 간단한 방법은, 서버가 광고하는 이름과 URL이 클라이언트에 이미 동일하게 구성되어 있는 LOP인지 확인하는 것입니다.
일반적으로 기본 및 "안전한" 설정은 "promisor-remote" 프로토콜과는 별개로 클라이언트에 LOP를 구성해두도록 요구하고, 프로토콜에서 받은 정보가 별도로 이미 구성된 정보와 일치할 때에만 LOP를 수용하도록 해야 합니다.
LOP 이름은 어떻게 해야 합니까?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
예를 들어 클라이언트끼리 서로 가져오기를 수행하는 경우가 때때로 있다면, 모든 클라이언트가 사용하는 모든 원격(LOP 포함)의 이름을 동일하게 맞추는 것이 좋은 생각일 수 있습니다.
다른 맥락에서는, 각 클라이언트가 상호작용하는 각 원격(각 LOP 포함)에 원하는 이름을 부여하고 싶어할 수 있습니다.
따라서 서버가 광고하는 LOP 이름을 클라이언트가 수용할지 여부를 구성하는 여러 방법이 있어야 합니다.
기본 또는 "안전한" 설정이 사용된다면, 이러한 설정은 LOP가 별도로 구성되어 있어야 함을 요구하므로, 이름 또한 별도로 구성되며 서버가 클라이언트에 이름을 강제할 위험은 없습니다.
구형 클라이언트나 과도하게 보수적인 클라이언트 때문에 주요 원격이 지연될 수 있습니까?
그럴 수 있습니다. 서버를 신뢰하려 하지 않거나, 너무 오래되어 'git' 클라이언트와 완전히 호환되지 않아 "promisor-remote" 프로토콜을 구현하지 않는 클라이언트가 너무 많을 경우 그렇습니다.
이러한 클라이언트에 서비스를 제공할 때 주요 원격은 클라이언트의 요청을 모두 제공하기 위해 먼저 LOP에서 가져온 뒤 전달하는 것 외에 선택지가 없습니다. 따라서 주요 원격은 정리 메커니즘을 가지고 있더라도(위 II.4 절 참조), LOP에서 가져와야 했던 대용량 blob 때문에 최소한 일시적으로는 부담을 떠안게 됩니다.
이와 다르게 동작하는 것은 하위 호환성을 깨뜨리는 것이며, 클라이언트를 차별하는 것으로 보일 수 있습니다. 예를 들어 "promisor-remote" 프로토콜을 구현하지 않거나 주요 원격을 신뢰하려 하지 않는 클라이언트를 서버가 거부하도록 하는 특수 모드를 구현하는 것도 가능할 수 있습니다. 이 모드는 기업 환경과 같은 특수한 맥락에서는 유용할 수 있습니다. 그러나 이러한 모드를 구현할 계획은 없으며, 어차피 별도로 따로 논의되어야 합니다.
더 나은 접근법은 아마도 주요 원격이, 프로토콜을 구현하지 않았거나 광고된 LOP를 수용하려 하지 않는 클라이언트에게, 클라이언트 소프트웨어를 업그레이드하거나 LOP를 수용하도록 제대로 설정하면 더 빠른 클론과 가져오기를 얻을 수 있다는 메시지를 보여주는 것입니다.
클라이언트 업그레이드를 기다리고 이를 모니터링하며, LOP 사용을 자주 접근되지 않는 저장소로 제한하는 것 또한 LOP에서 일부 이점을 계속 얻도록 하는 좋은 방법일 수 있습니다. 시간이 지남에 따라 더 많은 클라이언트가 업그레이드하고 LOP의 혜택을 누리게 되면, 더 자주 접근되는 저장소에도 점차 LOP를 사용하는 것이 가치 있어질 것입니다.
모든 클라이언트가 최신 상태이고 제대로 구성되도록 관리하기 쉬운 기업 환경에서는, LOP를 더 크고 더 이르게 활용할 수 있기를 기대할 수 있습니다.
가져오기는 어떻습니까?
가져오기에는 여러 종류가 있습니다. 일반적인 가져오기는 서버의 일부 ref가 업데이트되었을 때 클라이언트가 해당 ref 업데이트와 그에 수반된 새 객체를 가져오고자 할 때 발생합니다. 반면 "백필(backfill)" 또는 "레이지(lazy)" 가져오기는, 클라이언트가 이미 알고 있으나 promisor 원격에 있어서 가지고 있지 않은 일부 객체를 사용해야 할 때 발생합니다.
일반 가져오기
+++++++++++++
일반 가져오기에서는 클라이언트가 주요 원격에 접속하고 둘 사이에 프로토콜 협상이 이루어집니다. 매번 프로토콜 협상이 이루어지는 것은 좋은 일입니다. 클라이언트나 주요 원격의 구성이 이전 협상 이후 바뀌었을 수 있기 때문입니다. 이 경우 새로운 프로토콜 협상은 새 가져오기가 클라이언트와 서버의 새로운 구성을 만족하는 방식으로 이루어지도록 보장해야 합니다.
하지만 대부분의 경우 두 번의 가져오기 사이 혹은 최초 클론과 그 다음 가져오기 사이에 클라이언트와 주요 원격의 구성이 바뀌지 않습니다. 이는 새로운 프로토콜 협상의 결과가 이전 결과와 동일하다는 뜻이며, 새로운 가져오기는 이전의 클론이나 가져오기와 동일한 방식으로, 즉 지난번과 동일한 LOP를 사용(또는 사용하지 않음)하여 수행됩니다.
"백필" 또는 "레이지" 가져오기
+++++++++++++++++++++++++++++
백필 가져오기가 있는 경우, 클라이언트는 반드시 먼저 주요 원격에 연락하지는 않습니다. 설정 파일에 나타나는 순서대로 promisor 원격에서 가져오기를 시도하되, `extensions.partialClone` 구성 변수를 사용해 구성된 원격은 마지막에 시도합니다. link:/docs/partial-clone#using-many-promisor-remotes[부분 클론 문서]를 참조하십시오.
이는 이번 노력으로 새로 도입된 것이 아닙니다. 사실 다중 원격은 이미 약 5년 전부터 이런 방식으로 동작해 왔습니다.
LOP를 사용할 때는 주요 원격을 `extensions.partialClone`으로 구성해 마지막에 시도하게 하는 것이 합리적입니다. 누락된 객체는 LOP에 있는 대용량 blob뿐이어야 하기 때문입니다.
이는 누락된 객체가 LOP에서 가져와질 것이므로 주요 원격에서 더 이상 가져올 항목이 남지 않아 프로토콜 협상이 일어나지 않을 가능성이 큽니다.
이를 안전하게 하기 위해, LOP가 클라이언트가 자신에게서 가져올 때 토큰을 요구하도록 하는 것이 좋은 생각일 수 있습니다. 클라이언트는 주요 원격과의 프로토콜 협상 시 토큰을 받을 수 있습니다(위 II.6 절 참조).
V) 향후 개선 사항
-----------------
초기에는 클라이언트가 사용하는 Git 버전을 쉽게 통제할 수 있는 기업 환경이나, 접근 빈도가 낮은 저장소에서 LOP를 사용하는 것이 주로 가치 있을 것으로 예상합니다(FAQ의 "구형 클라이언트나 과도하게 보수적인 클라이언트 때문에 주요 원격이 지연될 수 있습니까?" 항목 참조).
시간이 지나 더 많은 클라이언트가 위 II.6 절에서 설명한 "promisor-remote" 프로토콜 v2 capability를 구현한 버전으로 업그레이드하면, LOP를 더 널리 사용하는 것이 가치 있게 될 것입니다.
또한 LOP의 폭넓은 사용에 도움이 될 많은 개선 사항이 있습니다. 다음과 같은 일부 개선 사항은 이 문서의 범위에 포함됩니다:
- `git cat-file --batch` 프로토콜과 그 변형에 "remote-object-info" 명령을 구현하여, 주요 원격이 대용량 blob을 가져오지 않고도 해당 요청에 응답할 수 있게 합니다. (Eric Ju가 Calvin Wan의 이전 작업을 바탕으로 이를 시작했습니다.)
- 주요 원격과 클라이언트가 대용량 blob 축적을 방지하도록 더 나은 정리 및 오프로드 메커니즘을 만듭니다.
- 클라이언트와 서버 간에 LOP 처리를 위한 더 정교한 프로토콜 협상 기능을 개발합니다. 예를 들어 클론 시 필터링을 위한 filter-spec(예: blob:limit=<size>) 또는 크기 제한을 추가하거나, LOP 인증을 위한 토큰을 추가하는 방식입니다.
- 특히 토큰 처리와 인증 주변에서 LOP 접근 보안 조치를 개선합니다.
- 서로 다른 환경 전반에서 여러 LOP를 구성하고 관리하는 표준화된 방법을 개발합니다. 특히 서로 다른 LOP가 지리적으로 분산된 클라이언트에게 동일한 콘텐츠를 제공하는 경우, LOP 간 복제 또는 동기화가 필요합니다.
다음과 같은 일부 개선 사항은 이 문서의 "0) Non Goals" 절에서 언급되었듯이, 이 문서의 범위를 벗어납니다:
- 클라이언트 측에서 대용량 blob에 대한 새로운 객체 표현을 구현하는 것.
- 대용량 blob을 청크 단위로 나누고 중복 제거하며 효율적으로 저장할 수 있는 플러그형 ODB 또는 기타 객체 데이터베이스 백엔드를 개발하는 것.
- 특히 비압축성 및 델타가 잘 되지 않는 콘텐츠에 대해 LOP와 클라이언트/서버 간 데이터 전송을 최적화하는 것.
- 대용량 객체를 더 효과적으로 관리하기 위한 향상된 클라이언트 측 도구를 만드는 것. 예를 들어 Git LFS 또는 git-annex에서의 마이그레이션 도구, 어떤 객체를 오프로드할 수 있으며 오프로드로 얼마나 디스크 공간을 회수할 수 있는지 찾는 도구 등이 있습니다.
다음과 같은 개선 사항은 이 문서의 범위에 포함될 수 있으나, 이미 Git 프로젝트와는 별도의 프로젝트로 진행 중일 수 있습니다:
- 객체 스토리지에 접근하는 기존 원격 도우미를 개선하거나 새로운 원격 도우미를 개발하는 것.
- 기존 객체 스토리지 솔루션을 개선하거나 새로운 솔루션을 개발하는 것.
위의 모든 개선 사항이 도움이 될 수 있지만, 이 문서와 LOP 노력은 적어도 처음에는 현재 범위 내의 비교적 소수의 개선 사항에 집중하려고 해야 합니다.
예를 들어 플러그형 ODB와 새로운 객체 데이터베이스 백엔드를 도입하는 일은 그 자체로 수년에 걸친 작업이 될 가능성이 있으며, 병행하여 별도로 진행될 수 있습니다. 이는 다른 기술적 요구사항을 가지고 Git 코드베이스의 다른 부분에 영향을 미치며, 자체 설계 문서가 필요합니다.