OpenAI에서 Git 확장하기: Pando는 Git을 유지하면서 백엔드를 재구성한다

OpenAI는 2026년 11월 2일 Pando를 공개하며, 이 새로운 Git 백엔드가 푸시 지연 시간의 중앙값을 거의 80% 줄인다고 밝혔다. OpenAI에서 Git 확장하기에 대한 회사의 설명은 이 주장 뒤에 있는 구체적인 인프라 결정을 제시한다. 익숙한 개발 워크플로를 유지하면서 이를 뒷받침하는 공유 기반을 바꾸는 것이다.

Pando는 이제 여러 프로젝트를 포함하는 공유 저장소인 OpenAI의 모노레포 개발을 지원한다. OpenAI는 10주간의 개발 끝에 4월부터 프로덕션 환경에서 운영에 들어갔다고 밝혔다. 따라서 이 발표는 배포를 기다리는 제안이 아니라, 소스 제어를 위한 운영 시스템을 설명한다.

핵심 경쟁 구도는 저장소 전체의 조율과 브랜치 전반에서의 독립 작업 사이에 있다. GitHub의 이전 DGit 아키텍처는 복제 저장소를 통해 Git을 확장한 역사적 참고 사례를 제공한다. Pando는 다른 질문을 제기한다. 코딩 에이전트가 더 많은 병렬 활동을 만들어낼 때, 어떤 공유 보장이 그 조율 비용을 감수할 만큼 가치가 있는가?

OpenAI에서 Git 확장하기는 명령어 뒤편의 병목으로 시선을 돌린다

이 발표는 개발자가 인식하는 Git 워크플로와 이를 제공하는 인프라를 분리해 설명한다.

변경 사항을 추적하고 프로젝트 이력을 교환하는 소프트웨어인 Git은 익숙한 인터페이스이자 구현 방식의 집합이다. 개발자는 명령어, 브랜치, 커밋을 경험한다. 인프라 팀은 협업을 가능하게 하는 스토리지, 조율, 전달 시스템을 관리한다.

이 계층들은 반드시 함께 바뀔 필요가 없다. 기업은 사람들이 사용하는 명령어를 유지하면서도 그에 응답하는 서비스의 상당 부분을 교체할 수 있다. 인프라 병목이 곧바로 개발자 인터페이스의 한계를 의미하지는 않기 때문에 이 구분은 중요하다.

OpenAI의 Git backend design에 따르면, Pando는 브랜치를 독립적으로 조율하고 저장된 전송 패키지를 재사용한다. 그 대가로 브랜치 전반에 걸친 단일 시점 뷰를 포기하며, 때로는 중복 데이터를 전송한다.

이는 중요한 선택이다. 이는 OpenAI가 자사 워크로드에 항상 필요하지는 않은 비용 높은 보장과 최적화를 식별했음을 시사한다. 따라서 이 설계는 기존 호스팅 시스템을 보편적으로 대체할 수단으로 받아들이기보다 해당 워크로드 요건을 기준으로 평가해야 한다.

변경 사항을 저장하는 일과 그 변경 사항을 협업자에게 제공하는 일의 차이를 생각해 보자. 개발자는 로컬 작업을 마칠 수 있지만, 공유 시스템은 여전히 게시나 조회를 지연시킬 수 있다. 코드 생성 속도가 빨라진다고 해서 어느 쪽의 지연도 사라지는 것은 아니다.

이는 실질적인 사람의 결과를 동반하는 인프라 문제를 만든다. 개발자는 주변 도구가 결과물을 가져와 테스트하고 제시할 수 있어야만 에이전트의 출력을 평가할 수 있다. 로컬에서 완료된 작업도 이 공유 프로세스를 거치기 전까지는 팀의 관점에서 미완료 상태다.

같은 구분은 성능 주장에도 적용된다. 푸시 지연 시간은 변경 사항을 원격 저장소에 게시하는 데 걸리는 시간을 측정한다. 이는 그 변경 사항이 정확한지, 유용한지, 검토되었는지, 배포 준비가 되었는지를 측정하지 않는다.

그러므로 OpenAI에서 Git 확장하기는 소스 제어 인프라 사례로 주목할 가치가 있다. 보고된 개선은 개발의 특정 단계와 관련된다. 더 넓은 가치는 그 단계가 개발자가 실제로 겪는 지연에 얼마나 기여하는지에 달려 있다.

인프라 구매자에게 익숙한 워크플로를 유지하는 것은 추가적인 이점도 있다. 조직 변화의 범위를 제한하기 때문이다. 백엔드를 교체하는 일도 광범위한 엔지니어링을 요구할 수 있다. 협업의 언어를 교체하면 개발자와 연결된 도구에도 적응을 요구하게 된다.

어느 쪽도 자동으로 더 바람직한 것은 아니다. 중요한 질문은 인터페이스 자체가 원하는 워크로드를 막고 있는지, 아니면 그 뒤의 서비스가 다른 설계를 필요로 하는지다.

코딩 에이전트는 공유 개발 서비스에 압력을 가한다

직접적인 압력은 코드 생성 자체보다 작업을 게시, 조회, 검증하는 시스템에 가해진다.

OpenAI는 자사의 코딩 에이전트 시스템인 Codex를 소스 제어 부담의 원인으로 지목한다. 이 설명은 개인 생산성과 공유 처리 용량을 구분하는 데 도움이 된다. 개발자가 더 많은 작업을 시작할 수 있다고 해서 모든 다운스트림 서비스가 이를 흡수할 수 있다는 보장은 없다.

엔지니어가 코딩 에이전트에 독립적인 유지보수 작업을 할당한다고 가정해 보자. 각 작업은 별도의 브랜치, 즉 이름이 붙은 개발 라인에서 후보 변경 사항을 만든다. 이러한 브랜치를 게시하면 공유 저장소 서비스에 작업이 발생한다.

테스트는 또 다른 의존성을 더한다. 개발 활동으로 촉발되는 자동화된 검사인 지속적 통합은 검사를 실행하기 전에 관련 소스를 확보해야 한다. 조회가 느려지면 사용 가능한 테스트 용량이 소스 전달 대기열 뒤에서 대기할 수 있다.

이 사례는 메커니즘을 보여줄 뿐, 모든 조직이 에이전트를 사용하는 방식을 단정하지는 않는다. 실제 압력은 작업 빈도, 저장소 구조, 테스트 설계, 환경이 기존 파일을 재사용하는 빈도에 달려 있다. 에이전트 도입만으로 결과를 예측할 수는 없다.

그럼에도 계획 측면의 시사점은 분명하다. 각 사람이 중첩되는 작업을 시작할 수 있게 되면, 활성 개발자 수를 세는 것만으로는 인프라 수요를 추정하기에 불완전하다. 팀은 개발 도구가 동시성 환경에서 어떻게 동작하는지도 이해해야 한다.

동시성이란 여러 작업이 겹치는 기간에 진행되는 것을 뜻한다. 이는 시스템이 보유한 자료의 양을 설명하는 저장소 크기와 다르다. 저장된 이력이 관리 가능한 수준이어도 서비스는 동시 활동으로 어려움을 겪을 수 있다.

이 구분은 플랫폼 팀이 던져야 할 질문을 바꾼다. 느린 조회는 과부하된 전송 경로, 비용이 큰 준비 작업, 또는 공유 상태를 둘러싼 경합을 반영할 수 있다. 스토리지 용량을 늘리는 것은 이러한 원인 중 일부에만 대응한다.

압력은 엔지니어링 관리자에게도 미친다. 에이전트가 후보 변경 사항을 더 빠르게 생성하면 검토와 테스트는 유용한 결과물과 추가 활동을 구분해야 한다. 저장소 작업은 필요한 부하 지표이지만, 제공된 가치의 완전한 척도는 아니다.

브랜치를 게시하기까지의 대기 시간이 줄어들면 협업에는 도움이 된다. 그렇다고 그 브랜치가 승인을 받을 가치가 있다는 뜻은 아니다. 이 결과들을 분리해 다루면 인프라 개선이 소프트웨어 품질에 관한 근거 없는 주장으로 이어지는 것을 막을 수 있다.

엔지니어링 팀을 지원하는 지식 근로자에게 관련 과제는 활동이 확대될수록 의사결정을 이해하기 쉽게 유지하는 것이다. searchable knowledge base는 변경 사항을 둘러싼 기술적 맥락을 보존할 수 있다. 이는 소스 이력을 저장하는 것과는 다른 목적을 수행한다.

조직 차원의 교훈은 제안된 작업부터 수용된 결과에 이르는 전체 경로를 평가하는 것이다. Pando는 이 경로의 일부를 다룬다. 소스 제어 지연이 개발자, 에이전트 또는 자동화된 검사가 기다리는 데 쓰일 수 있는 의미 있는 시간을 소모하는 환경에서 그 관련성은 커진다.

Pando는 독립적인 브랜치 진행을 위해 공유 조율을 교환한다

이 아키텍처 결정은 어디에서 합의가 필요한지, 어디에서 관련 없는 작업이 별도로 진행될 수 있는지에 관한 것이다.

공유 개발 시스템은 충돌하는 업데이트가 서로를 조용히 덮어쓰지 않도록 막아야 한다. 그렇다고 해서 모든 업데이트가 저장소 전체에 걸친 합의를 필요로 하는 것은 아니다. 적절한 경계는 호출자가 무엇을 관찰할 것으로 기대하는지에 달려 있다.

서로 관련 없는 기능 브랜치를 별도 에이전트가 업데이트한다고 가정해 보자. 이러한 작업이 조율 지점을 공유하도록 요구하면, 원래는 서로 의존하지 않는 작업들 사이에 관계가 생긴다. 그 관계를 제거하면 동시 진행의 여지가 생긴다.

더 까다로운 질문은 읽는 쪽과 관련된다. 여러 브랜치를 검사하는 도구는 그 값들이 일관된 시점을 나타내기를 기대할 수 있다. 다른 도구는 특정 브랜치와 이를 뒷받침하는 이력만 필요로 할 수 있다.

이러한 기대는 서로 다른 계약을 설명한다. 전자를 완화하면서 후자를 유지하면 조율을 줄일 수 있지만, 연결된 자동화는 이 차이를 이해해야 한다. 익숙한 명령어만으로는 서비스에 내재된 모든 가정을 전달할 수 없다.

이 때문에 Pando의 설계는 성능 엔지니어링을 넘어 의미가 있다. 이는 조직에 자사 워크플로가 실제로 어떤 보장을 사용하는지 식별하도록 요구한다. 아무도 필요로 하지 않는 보장도 운영 비용을 유발할 수 있다. 문서화되지 않은 보장은 숨은 의존성이 될 수 있다.

GitHub는 유용한 역사적 비교를 제공한다. 2016년 distributed Git architecture는 이후 Spokes로 불린 DGit이 저장소 복제본을 유지하고 쓰기를 커밋하기 전에 성공적인 확인 응답을 요구했다고 설명했다.

이 아키텍처는 복제를 통해 가용성과 내구성을 다뤘다. 이는 Git을 신뢰할 수 있는 공유 서비스로 운영하려는 오랜 노력의 맥락을 제공한다. 이를 GitHub의 현재 인프라를 완전히 설명하는 자료로 오해해서는 안 된다.

이 비교는 아키텍처의 승자를 선언하는 것보다 더 제한적인 결론을 뒷받침한다. 서로 다른 조율 경계는 서로 다른 워크로드에 적합하다. 범용 호스팅 플랫폼과 내부 개발 환경은 호환성, 운영, 고객 기대 측면에서도 서로 다른 요건에 직면한다.

OpenAI에서 Git 확장하기의 유용한 구분선은 독립적인 브랜치 활동과 더 폭넓은 합의가 필요한 작업 사이에 있다. 독립적인 측면에서 얻은 성능은 다른 곳의 경합을 자동으로 없애지 않는다.

공유 통합 브랜치는 분명한 사례다. 별도의 제안은 동시에 진행될 수 있지만, 결국 이들을 결합하려면 순서와 호환성에 관한 결정이 여전히 필요하다. 인프라 설계는 상충하는 코드 변경 사항을 더 빨리 받아들인다고 해서 호환되게 만들 수는 없다.

이 구분은 수평 확장에 대한 흔한 오해를 막는다. 수평 확장이란 더 많은 머신에 걸쳐 서비스 용량을 추가하는 것을 의미한다. 추가 용량은 작업을 분산할 수 있을 때 도움이 된다. 워크로드가 반복적으로 동일한 상태에 대한 합의를 요구한다면 그 효과는 제한적이다.

따라서 아키텍처 평가는 의존성 패턴에서 시작해야 한다. 얼마나 많은 작업이 독립적인가? 어떤 작업이 경쟁하는가? 어떤 읽기 작업에 조율된 뷰가 필요한가? 이 답들이 저장소 전체 조율을 완화하는 것이 유용한 적합성인지, 아니면 받아들일 수 없는 동작 변화인지를 결정한다.

재사용 가능한 Git 전송은 읽기의 경제성을 바꾼다

준비된 데이터를 반복적으로 제공하면 서버 계산, 전송량, 클라이언트 작업 간의 균형이 달라진다.

팩파일은 저장소 객체를 전송하거나 저장하기 위한 Git의 압축 패키지다. 특정 읽기 작업에 맞춰 패키지를 준비하면 불필요한 전송을 줄일 수 있다. 기존 패키지를 재사용하면 준비 작업을 줄일 수 있다.

어느 목표도 항상 우세한 것은 아니다. 선호되는 균형은 대역폭 대비 계산 비용, 읽기 작업 간 유사성, 중첩되는 이력을 요청하는 빈도에 달려 있다. 좁게 최적화된 전송은 반복 준비 비용이 클 수 있다.

Git의 pack transfer protocol은 클라이언트와 서버가 필요로 하거나 이미 보유한 이력에 대해 협상하는 방식을 설명한다. 이 협상은 불필요한 자료 전송을 피하는 데 도움이 된다. 동시에 전송 자체에 앞서 작업을 추가한다.

많은 독자가 비슷한 콘텐츠를 원할 때 이 구분은 중요해진다. 서버는 모든 응답을 맞춤화해 대역폭을 절약할 수 있다. 또는 준비된 자료를 효율적으로 배포하기 위해 어느 정도의 중복을 받아들일 수도 있다.

이는 무조건적인 개선이 아니라 리소스 할당의 결정이다. 시스템은 서버 작업을 줄이면서 전송되는 바이트 수를 늘릴 수 있다. 그러한 교환이 사용자에게 이로운지는 전송이 이루어지는 환경에 달려 있다.

Git의 protocol capabilities에는 별도의 다운로드 위치를 통해 packfile을 가져오는 기능이 포함되어 있다. 이 기능은 fetch 협상과 실제 바이트 전달 사이에 아키텍처적 여지를 만든다. fetch는 다른 시스템에서 리포지토리 이력을 가져온다.

이러한 책임을 분리하면 각기 다른 구성 요소가 서로 다른 요구를 처리할 수 있다. 협상 서비스는 독자에게 무엇이 필요한지 응답한다. 전달 서비스는 선택된 데이터를 전송한다. 이들의 용량 요구 사항이 정확히 같은 방식으로 증가할 필요는 없다.

그렇다면 소비자 가까이에 재사용 가능한 데이터를 보관하는 캐시는 요청이 겹칠 때 도움이 될 수 있다. 그 유용성은 재사용에 달려 있다. 새롭거나 드문 요청이 주를 이루는 워크로드는 인기 있는 이력을 반복적으로 가져오는 경우와 다른 운영 환경을 제공한다.

이 구분은 독자가 처리량 헤드라인을 해석하는 방식에 영향을 줘야 한다. 처리량은 서비스가 시간에 따라 얼마나 많은 데이터를 전달하는지 측정한다. 개별 요청이 전송 시작 전까지 얼마나 오래 대기하는지는 설명하지 않는다.

클라이언트도 중요하다. 바이트를 다운로드하는 것은 사용할 수 있는 이력을 확보하는 과정의 일부일 뿐이다. 개발 환경은 종속 작업을 진행하기 전에 수신한 자료를 처리해야 한다. 더 빠른 전달은 클라이언트 처리나 로컬 스토리지에서 새로운 한계를 드러낼 수 있다.

구체적인 예로, 동일한 프로젝트 리비전을 가져오는 임시 테스트 환경을 생각해 보자. 요청하는 콘텐츠가 겹치므로 재사용은 매력적으로 보인다. 이제 연결성이 제한되고 기존 이력이 상당히 많은 환경을 생각해 보자. 이 경우 중복 전송은 더 큰 비용이 된다.

이러한 예시는 보편적인 결과를 확정하지 않으면서도 메커니즘이 중요한 이유를 설명한다. 인프라 팀은 전송 최소화와 준비된 자료의 재사용 중 하나를 선택하기 전에 대표성 있는 측정값이 필요하다. 동일한 아키텍처도 지역, 기기, 개발 방식에 따라 다르게 작동할 수 있다.

따라서 OpenAI Pando는 설계 방향의 증거로서 가장 유용하다. 더 폭넓은 엔지니어링 질문은 클라이언트나 네트워크에 받아들일 수 없는 부담을 전가하지 않으면서 얼마나 많은 반복 작업을 요청 경로에서 제거할 수 있는가이다.

성능 주장은 워크로드 맥락이 필요하다

보고된 결과는 내부 배포 사례를 뒷받침하지만, 더 광범위한 결론을 위해서는 비교 가능한 측정값과 더 명확한 운영 경계가 필요하다.

OpenAI의 지연 시간 수치는 여전히 회사가 보고한 결과다. 이는 OpenAI가 자사 환경에서 일어났다고 말하는 일을 보여준다. 유사한 아키텍처 선택을 채택한 다른 조직이 기대해야 할 결과를 독립적으로 입증하지는 않는다.

중앙값은 측정된 분포의 가운데 관측치로, 일반적인 동작을 설명한다. 그러나 가장 느린 경험은 해결되지 않은 채 남는다. 가져오기나 게시가 끝날 때까지 종속 프로세스가 계속 진행할 수 없는 경우, 이러한 느린 요청은 중요하다.

따라서 유용한 평가는 일반적인 성능과 느린 구간의 지연을 모두 검토해야 한다. 또한 성공한 작업을 재시도 및 실패와 구분해야 한다. 더 빠르게 완료된 요청은 평균값이 감추는 문제와 공존할 수 있다.

워크로드 정의도 그만큼 중요하다. 독립적인 브랜치 업데이트, 공유 브랜치에 대한 반복 업데이트, 오래된 이력의 가져오기는 서로 다른 경로를 사용한다. 이를 하나의 집계 결과로 결합하면 아키텍처가 가장 큰 도움을 주는 지점이 가려질 수 있다.

비교에는 일관된 출발점도 필요하다. 동일한 클라이언트 이력, 네트워크 조건, 리포지토리 콘텐츠, 요청 결과는 결과를 더 쉽게 해석하게 한다. 그렇지 않으면 겉으로 보이는 서비스 개선이 다른 곳의 차이를 일부 반영할 수 있다.

선택한 가정 아래에서 시스템 동작을 연구하는 데 쓰이는 시뮬레이션과 모델에도 같은 주의가 적용된다. 이들은 조정 비용을 드러내고 예상되는 관계를 설명할 수 있다. 하지만 프로덕션 배포의 모든 장애 모드나 운영 비용을 확정할 수는 없다.

이는 아키텍처 모델을 무시해야 할 이유가 아니다. 그 가치는 가정을 드러내는 데 있다. 독자는 어떤 제약이 결과를 이끄는지, 그리고 그 제약이 의도한 배포 환경과 닮았는지 식별할 수 있어야 한다.

호환성도 더 정밀하게 다룰 가치가 있다. 명령 호환성은 개발자가 자신이 실행하는 작업을 인식한다는 뜻이다. 프로토콜 호환성은 시스템이 서로 이해하는 메시지를 교환할 수 있다는 뜻이다. 동작 호환성은 그러한 메시지가 성공한 뒤 애플리케이션이 의존하는 보장을 다룬다.

이러한 호환성의 형태는 겹치지만 서로 바꿔 쓸 수는 없다. 워크플로는 익숙한 명령을 유지하면서도 인프라 팀이 관측, 순서, 복구에 관한 가정을 검토하도록 요구할 수 있다. 그러한 검토는 도입 평가에 포함돼야 한다.

공개 코드 역시 살펴볼 만한 또 다른 경계다. OpenAI는 Git client fork를 유지하고 있다. 클라이언트 리포지토리는 엔지니어가 검토할 자료를 제공하지만, 전체 Pando 백엔드에 대한 공개 접근과 혼동해서는 안 된다.

엔터프라이즈 구매자에게 가용성과 지원은 기술적 신뢰성과 별개의 문제다. 잘 설명된 내부 아키텍처는 유용한 증거다. 지원되는 외부 서비스에는 추가로 운영 문서, 접근 제어, 복구 절차, 명확히 정의된 책임이 필요하다.

따라서 OpenAI에서 Git을 확장한 사례는 인프라 계획에 참고가 되어야 하지만, 조달을 위한 지름길이 되어서는 안 된다. 이 발표는 검토할 가치가 있는 접근법을 제시한다. 실제 배포 결정에는 그 접근법이 구매자의 종속성, 워크로드, 운영 모델에 맞는다는 증거가 여전히 필요하다.

클라이언트 도입, 워크로드 증거, 외부 가용성을 주시하라

다음으로 유용한 신호는 다른 팀이 무엇을 사용할 수 있고, 독립적으로 평가할 수 있으며, 운영할 수 있는지에 관한 것이다.

첫 번째 신호는 OpenAI 자체 배포 범위를 넘어 관련 클라이언트 개선 사항이 채택되는지다. 공유된 클라이언트 지원은 이 작업의 일부가 기존 Git 환경에도 이롭다는 근거를 강화할 것이다. 특수한 배포판에 의존한다면 즉각적인 도달 범위는 좁아질 것이다.

OpenAI Pando를 지켜보는 독자에게 실질적인 질문은 조직이 이미 지원하는 클라이언트에서 어떤 기능이 일반적인 기능으로 자리 잡는가이다. 소스 코드에서의 가용성과 관리되는 개발자 환경 전반에서의 가용성은 서로 다른 도입 단계에 해당한다.

이 신호가 중요한 이유는 인프라 변경이 모든 곳에 동시에 도착하는 경우가 드물기 때문이다. 개발자 노트북, 테스트 이미지, 자동화 컨테이너, 호스팅된 실행 환경은 서로 다른 업데이트 일정을 따를 수 있다. 이러한 환경이 필요한 기능을 공유할 때 백엔드 설계는 더 쉽게 도입된다.

두 번째 신호는 더 폭넓은 워크로드 증거다. 다양한 브랜치 패턴, 클라이언트 상태, 네트워크 조건을 포괄하는 측정값은 아키텍처를 더 쉽게 평가하게 할 것이다. 이들은 이점이 지속되는 지점과 절충안이 비용 부담이 되는 지점을 보여줄 것이다.

특히 유용한 증거는 서비스 성능을 개발자 결과와 연결하는 것이다. 더 빠른 게시가 중요한 것은 실제 개발 프로세스의 대기 시간을 줄일 때다. 더 낮은 인프라 지표는 유익한 정보이지만, 실질적인 가치는 그다음에 일어나는 일에 달려 있다.

원 조직 외부의 결과는 신뢰를 더욱 강화할 것이다. 동일한 수치를 재현할 필요는 없다. 서로 다른 환경에서 기저 동작에 대한 일치가 헤드라인 개선 폭의 일치보다 더 유익할 것이다.

반대로, 이득이 비정상적으로 유리한 조건에 크게 의존한다는 증거는 결론의 범위를 좁힐 것이다. 그렇다고 내부 배포의 가치를 무효화하는 것은 아니다. 다른 팀이 유사한 설계를 검토할 만한 상황을 식별하는 데 도움이 될 것이다.

세 번째 신호는 구체적인 외부 제공 서비스 또는 릴리스다. 독자는 명확히 정의된 가용성, 문서화된 인터페이스, 운영 경계를 살펴봐야 한다. 이러한 세부 사항은 다른 이들이 채택할 수 있는 기술과 연구만 할 수 있는 아키텍처를 구분할 것이다.

공개 릴리스는 지원 및 배포에 관한 새로운 질문도 낳는다. 누가 스토리지 계층을 운영하는가? 어떤 클라이언트 기능이 필요한가? 장애 발생 시 어떻게 되는가? 이러한 답변은 헤드라인 성능 수치만큼이나 도입을 좌우할 것이다.

그러한 신호가 나오기 전까지도 이 발표는 더 즉각적인 이유로 유용하다. 이는 플랫폼 팀이 개발 시스템이 현재 코딩 워크플로에서 발생시키는 동시성보다 적은 동시성을 가정하고 있는지 집중적으로 검토할 방법을 제공한다.

적절한 대응은 기존 환경에서 증거를 수집하는 것이다. 게시 지연과 가져오기 지연을 분리하라. 반복 전송을 식별하라. 공유 브랜치 주변의 경합을 살펴보라. 모든 리포지토리 작업을 동일한 가치로 취급하지 말고, 각 지연을 그것이 막는 작업과 연결하라.

다음 인프라 검토에서는 Scaling Git at OpenAI를 계기로 완료된 코딩 작업이 공유 서비스 때문에 어디에서 대기하는지 파악하라. 어떤 지연이 필요한 조정에서 비롯되는지, 어떤 지연이 워크로드에 더는 필요하지 않은 구현 선택에서 비롯되는지 물어보라. 릴리스 프로세스가 실제로 의존하는 보장을 유지하고, 그 아래 서비스를 변경하기 전에 이를 문서화하라. 그다음 장애와 느린 요청을 포함한 대표적인 개발 활동을 기준으로 아키텍처 옵션을 비교하라. 유용한 질문은 구체적이다. 소스 제어 시스템의 어느 부분이 팀이 평가하고 제공할 수 있는 작업을 제한하는가? 그 답을 찾으면 Pando, 호스팅 Git, 또는 내부 백엔드에 관한 향후 모든 결정을 훨씬 더 쉽게 정당화할 수 있다.