외부 개발사와 장기 협업을 시작할 때, 많은 팀이 "어느 거버넌스 모델을 따를 것인가"를 벤더 선정 이후에 결정한다. 그러나 거버넌스 구조는 코드 리뷰 속도, 기술 부채 처리 우선순위, 그리고 기여자 온보딩 방식까지 연쇄적으로 결정하기 때문에, 협업 계약보다 먼저 설계해야 할 문제다.
Chromium은 이 질문에 답하기 좋은 사례 구조를 제공한다. Google 내부 Chrome 팀과 Igalia(외부 오픈소스 컨설팅 협력사)가 같은 저장소에서, 같은 도구로, 상당 부분 같은 인력과 협력하면서도 전혀 다른 방식으로 프로젝트를 운영한다. 두 모델이 공존하는 단일 코드베이스이기 때문에, 거버넌스 차이가 개발 결과에 어떻게 나타나는지를 비교적 선명하게 볼 수 있다.
무엇이 같고 무엇이 다른가
두 모델의 가장 큰 오해는 "대기업 주도는 빠르고, 분산 기여는 느리다"는 단순화다. 실제로는 속도와 품질의 병목이 서로 다른 지점에서 발생한다.
Google Chrome 팀은 관리 체계 안에서 프로젝트 우선순위가 결정된다. 새 기능, 측정 가능한 성능 지표 개선처럼 인사 평가에 반영되는 작업이 먼저 선택된다. 이 구조는 단기 배포 속도에 유리하지만, 기술 부채나 코드 건강성 개선처럼 성과로 측정하기 어려운 작업은 구조적으로 후순위가 된다.
반면 Igalia 같은 외부 기여자에게 주어지는 작업은 대체로 코드 구조 개선, 테스트 호환성 향상, 모듈화처럼 내부에서 일상적으로 다루기 어려운 영역이다. 단기 속도보다 장기 코드 품질에 기여하는 작업이지만, 프로젝트 가시성은 낮다. 어느 쪽이 더 낫다기보다, 두 모델이 서로 다른 종류의 문제를 해결하도록 구조화되어 있다고 보는 편이 정확하다.
거버넌스가 온보딩과 정보 접근에 미치는 영향
프로젝트 거버넌스 모델은 코딩 컨벤션이나 리뷰 프로세스뿐 아니라, 신규 기여자가 얼마나 빨리 실질적인 작업을 시작할 수 있는지를 결정한다.
대기업 주도 프로젝트에서 내부 개발자는 빌드 인프라, 버그 추적 시스템, 내부 문서에 즉각 접근할 수 있다. 외부 기여자는 같은 도구를 쓰지만 접근 권한을 별도로 요청해야 하고, 일부 버그 리포트나 내부 문서는 공개 설정이 누락된 채로 남아 있다. 악의적인 설계가 아니라 대규모 조직에서 공개 설정이 "최선을 다하는 일"로 처리되기 때문에 생기는 구조적 마찰이다.
이 마찰이 누적되면 외부 기여자가 동일한 속도로 기여하기 어려워진다. 온보딩 첫 주가 비슷하게 느껴지더라도, 한 달 이후부터 내부자와 외부자 사이에 정보 비대칭이 실질적으로 드러난다.
팀이 외부 개발사와 협업을 설계할 때 이 부분을 어떻게 다룰 것인지가 초기에 명시되어야 한다. 정보 접근 경로, 도구 권한 요청 절차, 공개 문서화 책임이 계약이나 협업 규약에 포함되지 않으면 프로젝트가 진행될수록 마찰이 쌓인다.
두 모델을 비교하는 실질적인 축
거버넌스 모델을 선택할 때 "어느 쪽이 더 좋은가"보다 "우리 프로젝트에서 무엇이 먼저 무너지는가"를 기준으로 비교하는 편이 유용하다.
우선순위 결정 구조: 대기업 주도 모델에서는 관리 체계가 우선순위를 결정하고, 분산 기여 모델에서는 의뢰 주체인 기술 담당자가 결정한다. 전자는 사업 목표와 정렬이 빠르지만 기술 부채 해소가 후순위가 되기 쉽다. 후자는 기술적 필요에 충실하지만 사업 우선순위와 충돌할 때 조율 비용이 발생한다.
리뷰 프로세스의 독립성: 대기업 주도 프로젝트에서 리뷰어는 조직 목표의 영향을 받는다. 분산 기여 모델에서는 리뷰어가 다양한 조직에 분산되어 있어 단일 조직의 판단이 코드 방향 전체를 결정하기 어렵다. 코드베이스의 독립성을 중요하게 여긴다면, 리뷰어 구성이 어떻게 되어 있는지를 거버넌스 선택 기준에 포함해야 한다.
기여자 온보딩의 공개성: 온보딩 문서, 빌드 가이드, 기여 가이드라인이 외부에 공개되어 있고 최신 상태로 유지되는지가 중요하다. 이것은 오픈소스 철학의 문제가 아니라 실용적인 속도 문제다. 외부 기여자가 문서 없이 내부 지식에 의존해야 한다면, 온보딩 시간이 길어지고 기여 품질도 불안정해진다.
도구와 인프라의 통제권: 대기업이 버그 추적, 코드 리뷰, 빌드 시스템을 모두 소유하고 운영하면, 외부 기여자는 도구 개선을 요청할 수 없다. 장기 협업이라면 도구 운영 주체가 누구인지, 외부 기여자가 피드백을 어떻게 전달할 수 있는지를 협업 시작 전에 확인해야 한다.
규모가 아니라 구조가 결정하는 것
Chromium 사례에서 가장 주목할 만한 점은, 효율성의 차이가 Google과 Igalia의 규모 차이에서 오지 않는다는 것이다. 직원 수는 180,000명 대 180명으로 1,000배 차이가 나지만, 두 팀은 동일한 저장소에서 의미 있는 기여를 동시에 이어가고 있다.
차이를 만드는 것은 역할 분담이 얼마나 명확한가, 리뷰 프로세스가 기여자 유형과 무관하게 작동하는가, 그리고 새로운 기여자가 맥락을 이해하는 데 필요한 정보가 공개되어 있는가다. 이 세 조건이 갖춰지지 않으면 대기업 주도 모델도 내부 정치와 우선순위 충돌로 속도를 잃고, 분산 기여 모델도 정보 단절로 품질을 잃는다.
외부 개발사와 장기 협업을 앞두고 있다면, 지금 당장 세 가지를 먼저 확인하는 것이 실용적이다. 기여 범위와 리뷰 권한이 역할별로 구분되어 있는지, 외부 기여자가 접근할 수 없는 정보 영역이 어디인지, 그리고 온보딩 문서가 내부 지식 없이도 작동하는지다. 이 세 질문에 답하지 못한 상태에서 거버넌스 모델을 선택하면, 계약 이후에 구조를 다시 설계하는 비용이 발생한다.
