How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems

소프트웨어를 만드는 것이 거대하고 정교한 성을 쌓는 것과 같은 세상을 상상해 보십시오. 이 세상에서 개발자들은 단순히 벽에 벽돌을 던져 붙기를 바라는 것이 아니라, **코드 리뷰(Code Review)**라고 불리는 엄격한 시스템을 사용합니다. 새로운 벽돌(또는 코드 한 줄)이 성에 영구적으로 추가되기 전에, 검사팀은 그것에 균열이 없는지 확인하고, 설계에 부합하는지, 그리고 다른 부분을 망가뜨리지는 않는지 점검합니다. 이 과정은 성이 높고 안전하게 서 있도록 유지하는 데 필수적입니다.

하지만 때로는 프로젝트가 단 하나의 벽돌로 이루어지기에는 너무 클 때가 있습니다. 그것은 하나의 탑 전체를 세워야 하는 일일 수도 있습니다. 과거에 개발자들은 탑 전체를 한꺼번에 만들려고 시도했을지도 모르지만, 그것은 검사하기가 매우 어렵습니다. 그래서 그들은 이를 작고 연결된 일련의 단계들로 나누기 시작했습니다. 소프트웨어 세계, 특히 **게릿(Gerrit)**이라는 도구 내에서는 이러한 연결된 단계들을 **관계 체인(Relation Chains)**이라고 부릅니다. 관계 체인을 늘어선 도미노라고 생각해보십시오. 두 번째 도미노가 쓰러지기 전에는 세 번째를 쓰러뜨릴 수 없고, 첫 번째가 쓰러지기 전에는 두 번째를 쓰러뜨릴 수 없지만, 검사관들은 이 모든 것을 동시에 확인할 수 있는 반면, 성은 반드시 순서대로 완성되어야 합니다. 전체 체인은 서로 연결되어 있습니다. 만약 첫 번째 도미노(즉, "베이스")가 흔들린다면, 전체 라인이 위험에 처하게 됩니다. 이러한 체인이 어떻게 작동하는지 이해하는 것은 매우 중요합니다. 왜냐하면 시스템이 너무 느리거나 혼란스러우면 개발자들이 몇 시간 동안 기다리며 갇혀 있을 수 있고, 혹은 성이 숨겨진 균열을 가진 채 지어질 수도 있기 때문입니다.

---

도미노 효과: 개발자들이 실제로 코드 체인을 사용하는 방식

이 논문은 세 개의 거대한 오픈 소스 커뮤니티(OpenStack, Wikimedia, ONAP)에서 개발자들이 소프트웨어를 구축하기 위해 이 "관계 체인"을 어떻게 사용하는지에 대한 심층적인 연구입니다. 연구진은 약 30,000개의 체인과 40만 개 이상의 개별 코드 변경 사항을 조사하여, 이 연결된 도미노들이 실제 환경에서 어떻게 작동하는지 살펴보았습니다. 그들은 알고 싶었습니다. 이 체인들이 흔한가? 이들이 리뷰 과정을 더 빠르게 만드는가, 아니면 더 느리게 만드는가? 그리고 체인의 중간에 있는 도미노를 수정하려고 할 때 어떤 일이 발생하는가?

체인은 어디에나 존재하며 (점점 더 커지고 있다)

첫째, 연구는 이러한 체인이 드물고 특수한 기술이 아니라 표준적인 작업 방식임을 발견했습니다. 프로젝트에 따라 모든 코드 변경 사항 중 **5%에서 49%**가 체인의 일부입니다. 실제로 연구 대상인 15개 프로젝트 중 14개에서 이러한 체인의 사용은 시간이 지남에 따라 실제로 증가하고 있습니다. 개발자들은 큰 작업을 연결된 작은 조각들로 나누는 것이 올바른 방향임을 깨닫고 있습니다.

대부분의 체인은 보통 두 개의 도미노(베이스 변경 사항과 그에 의존하는 하나의 변경 사항)로 이루어진 짧은 형태입니다. 하지만 어떤 프로젝트들은 믿기 힘들 정도로 깊게 뻗어 나가는 체인을 가지고 있습니다. 연구진은 최대 98개의 멤버를 가진 체인을 발견했습니다. 심지어 한 프로젝트에서는 자동 생성된 체인이 거의 60,000개의 멤버를 가진 경우도 있었으나, 이는 인간이 작성한 것이 아닌 자동화된 구성의 특수한 사례였습니다.

"중간"이 병목 구간이다

여기서 흥잡한 점이 드러납니다. 연구진은 체인의 중간에 있는 것이 가장 힘든 일이라는 것을 발견했습니다. 만약 당신이 첫 번째 도미노(베이스)라면, 당신은 그저 자신의 리뷰를 기다리기만 하면 됩니다. 만약 당신이 마지막 도미노(탑)라면, 당신은 앞선 것들을 기다리기만 하면 됩니다. 하지만 만약 당신이 중간에 있다면, 당신은 압박 속에 갇히게 됩니다. 당신은 앞의 도미노(승인되기를 기다림)에 의해 막혀 있는 동시에, 뒤의 도미노들을 가로막고 있습니다.

이러한 "압박" 때문에, 체인의 중간에 있는 변경 사항들은 승인되는 데 훨씬 더 오랜 시간이 걸립니다. 연구 결과, 체인의 멤버들은 동일한 크기의 고립된 단일 변경 사항보다 평균적으로 2.6배 더 오래 머지(merge)되는 것으로 나타났습니다. 이 지연은 코드가 더 나빠서 발생하는 것이 아니라, "동기화 오버헤드" 때문에 발생합니다. 검사관(리뷰어)들이 병렬로 벽돌을 확인할 수는 있지만, 실제로 성에 합쳐지는 과정은 반드시 아래에서 위로 하나씩 순차적으로 일어나야 하기 때문입니다. 체인의 변경 사항이 수정될 때마다, 전체 라인을 다시 확인하고, 다시 테스트하고, 다시 정렬해야 하는 경우가 빈번히 발생하며, 이는 중간의 변경 사항들이 아래쪽의 변경 사항을 기다리는 동시에 위쪽의 변경 사항들을 붙잡아 두는 병목 현상을 만들어냅니다.

"CI 증폭" 괴물

논문은 또한 CI 증폭 효과라고 부르는 현상을 강조합니다. "CI"는 지속적 통합(Continuous Integration)을 의미하며, 이는 새로운 벽돌이 성을 망가뜨리지 않는지 확인하기 위해 자동으로 테스트하는 로봇 군단과 같습니다. 규칙이 엄격한 프로젝트(예: OpenStack)에서는 개발자가 체인 내의 변경 사항을 업데이트할 때마다, 로봇 군단은 해당 변경 사항뿐만 아니라 그에 의존하는 모든 변경 사항을 다시 테스트해야 합니다.

연구에 따르면, 체인의 멤버들은 10에서 23개의 자동화된 테스트 작업을 트리거하는 반면, 단일하고 고립된 변경 사항은 두 개 미만의 작업만을 트리거합니다. 이는 마치 전구 하나를 바꿀 때마다 집 전체를 다시 테스트해야 하는 것과 같습니다. 이는 컴퓨터에게 엄청난 양의 추가 작업을 부과하고 인간에게는 지연을 초래합니다.

"기초 효과"

저자들이 **기초 효과(Foundation Effect)**라고 부르는 발견 중 가장 매혹적인 것은 다음과 같습니다. 첫 번째 도미노(베이스)에 투입된 노력의 양이 그 이후의 모든 도미노에 투입될 노력의 양을 예측한다는 것입니다.

베이스 변경 사항에 많은 관심, 많은 댓글, 많은 번의 수정이 집중되면, 전체 체인이 그 흐름을 따르는 경 경향이 있습니다. 연구진은 베이스의 활동과 그 후손들의 활동 사이에 강한 상관관계(0.43 ~ 0.61)를 발견했습니다. 마치 첫 번째 도미노의 "분위기"가 전체 라인의 톤을 결정하는 것과 같습니다. 기초가 흔들리고 많은 수정이 필요하다면, 전체 탑을 세우는 데 더 오랜 시간이 걸립니다. 반대로, 베이스가 견고하고 빠르게 승인된다면, 나머지 체인은 매끄럽게 흘러가는 경향이 있습니다.

체인은 정적인 상태가 아니다

마지막으로, 논문은 이러한 체인이 경직된 구조가 아님을 밝힙니다. 체인 내 변경 사항의 약 **33.5%**가 최종적으로 머지되기 전에 "구조적 진화(structural evolution)"를 겪습니다. 즉, 리뷰되는 동안 도미노 사이의 연결 관계가 변한다는 뜻입니다. 개발자는 변경 사항을 부모로부터 분리하여 다른 것에 연결하거나, 체인 전체를 재구성할 수 있습니다.

이는 또 다른 복잡성을 더합니다. 체인의 지도(map)가 끊임없이 변화한다는 것입니다. 때때로 체인은 오랫동안 휴면 상태로 머물기도 합니다. 연구에 따라 체인의 한 부분이 제출된 시점부터 최종적으로 머지될 때까지의 간격은 어떤 경우에는 2.85년까지 길어지기도 했습니다.

이것이 미래에 의미하는 바

저자들은 현재의 코드 리뷰 도구들이 모든 변경 사항을 체인의 일부로서 보는 것이 아니라, 마치 독립된 사건처럼, 즉 벽 전체를 보지 못한 채 단일 벽돌만을 보는 것처럼 취급한다고 결론짓습니다. 이 논문은 우리가 체인을 하나의 단위로 이해할 수 있도록 도구를 변화시켜야 한다고 제안합니다.

그들은 만약 우리가 체인의 베이스(첫 번째 도미노)에 집중한다면, 나머지 체인을 위해 엄청난 시간을 절약할 수 있다고 제안합니다. 기초가 견고하다면 전체 구조가 더 빠르게 움직입니다. 또한, 도구들이 "중간" 변경 사항들에 대해 더 똑똑해져야 하며, 아마도 나머지 라인을 풀어주기 위해 이들을 우선적으로 처리해야 한다고 제안합니다.

요약하자면, 관계 체인을 통해 소프트웨어를 구축하는 것은 복잡한 오케스트라를 지휘하는 것과 같습니다. 만약 지휘자(베이스)가 박자를 놓치면, 오케스트라 전체가 고전하게 됩니다. 하지만 지휘자가 명확하고 연주자들(도구들)이 악기들이 어떻게 연결되어 있는지 이해한다면, 음악은 훨씬 더 빠르게 흐를 것입니다. 연구는 이러한 연결 고리를 이해함으로써, 우리가 줄을 서서 기다리는 대신 훨씬 더 효율적으로 성을 쌓을 수 있다는 것을 시사합니다.