pull request - 혹시 가져가 주시겠어요?

함께 무언가를 꾸려본 사람이라면 이런 답답함을 느껴본 적이 있을 것입니다. 분명 내가 직접 처리하면 5분이면 끝날 일인데, 굳이 단톡방에 올리고, 설명하고, 다들 괜찮다고 할 때까지 기다려야 하는 상황 말입니다. 동아리 회비 쓰는 일이든, 공용 공간의 물건 배치든, 팀의 일하는 방식이든. “그냥 내가 하면 안 되나? 왜 이렇게 번거롭게 다 물어봐야 하지?” 하는 마음이 슬그머니 듭니다.

흥미롭게도 개발자들은 이 ‘번거로운 절차’를 자발적으로, 그것도 아주 엄격하게 지킵니다. ‘Pull Request’라 불리는 것입니다. 줄임말로는 PR이라고 부릅니다. IT 업계에서 일하는 사람이라면, 개발자들이 “PR 올렸습니다. 확인해주세요”라고 말하는 걸 들어본 적이 있을 겁니다.

그런데 이 이름부터가 곱씹어볼 만합니다. 직역하면 “당겨가 주기를 청하는 요청”입니다. 가만히 보면 이상한 어순입니다. 내가 만든 것을 공동의 본체에 합치는 일인데, 왜 내가 ‘밀어 넣겠다’가 아니라 상대더러 ‘당겨가 달라’고 청하는 걸까요. 물건을 건넬 때를 떠올려보면 차이가 분명해집니다. 상대의 품에 내가 안기듯 밀어 넣는 것과, 내 것을 가지런히 내밀어두고 “필요하시면 가져가세요” 하고 기다리는 것. 행위의 결과는 같아도, 그 안에 담긴 태도는 정반대입니다. 무게중심이 나에게 있느냐, 받는 쪽에 있느냐의 차이지요. 개발자들이 자기 작업을 합치는 흔하디흔한 이 행위에, 하필 ‘당겨가 달라’는 수동의 이름을 붙였다는 사실은 그 자체로 무언가를 말해줍니다.

그냥 넣을 수 있는데도

여러 개발자가 함께 만드는 소프트웨어에는, 모두가 공유하는 하나의 본체가 있습니다. 앞선 글들에서 이야기한, 여럿이 함께 써 내려가는 한 권의 책과 같은 것이지요. 개발자가 자기 작업을 끝내면, 그 결과를 이 공동의 본체에 합쳐야 비로소 의미가 생깁니다.

여기서 한 가지 짚어둘 것이 있습니다. 많은 경우 개발자는 자기가 고친 코드를 이 본체에 곧장 밀어 넣을 수도 있다는 사실입니다. 기술적으로 막혀 있는 것이 아닙니다. 마음만 먹으면 혼자 판단해서 바로 반영할 수 있습니다. 개발자들은 이것을 ‘직접 푸시(push)한다’고 말합니다. 그냥 밀어 넣는 것이지요.

그런데도 대부분의 팀에서 개발자들은 그렇게 하지 않습니다. 대신 한 박자 멈춰 서서, Pull Request라는 절차를 거칩니다. 자기가 만든 것을 곧장 합치는 대신, “제가 이런 작업을 했습니다. 본체에 합쳐도 될지 봐주시겠어요?” 하고 동료들에게 청하는 것입니다. 밀어 넣는(push) 대신 당겨가(pull) 달라 청하는, 앞서 말한 그 이상한 어순이 여기서 실제로 작동합니다.

의심해서가 아니라

그렇다면 개발자는 왜 그냥 밀어 넣지 않고 굳이 청하는 걸까요. 자기 코드에 자신이 없어서일까요?

그렇지 않습니다. 개발자는 자기 작업에 충분한 확신이 있을 때도 Pull Request를 올립니다. 이것은 자기 의심의 문제가 아닙니다. 핵심은 다른 데 있습니다. 그 코드가 곧 ‘우리 모두의 것’이 될 것이기 때문입니다.

내가 고친 코드는 나 혼자 쓰고 마는 것이 아닙니다. 그것은 공동의 본체에 합쳐져, 앞으로 동료들이 그 위에서 일하게 되고, 문제가 생기면 함께 책임지게 됩니다. 내가 오늘 넣은 한 줄이 반년 뒤 누군가의 작업을 어렵게 만들 수도 있고, 내가 미처 보지 못한 곳에 영향을 줄 수도 있습니다. 그러니 그것을 합치는 일은, 아무리 내가 만든 것이라 해도 더 이상 온전히 나 혼자만의 결정이 아닙니다.

Pull Request는 바로 이 인정에서 출발합니다. “이건 내 작업이지만, 곧 우리 것이 될 테니, 우리 것이 되기 전에 우리가 함께 보자”는 것. 혼자 쓰는 일기장이라면 이런 절차는 필요 없습니다. 무엇을 쓰든 나만의 것이니까요. 여럿이 함께 써 내려가는 책이기에, 그 책에 한 문장을 더할 때 동료들에게 알리는 것입니다. 그것은 능력의 부족도, 자기 확신의 부족도 아니라, 공동의 것을 대하는 태도입니다.

드러내고, 설명하고, 동의를 구하는 일

Pull Request를 올린다는 것은 구체적으로 세 가지를 동시에 하는 일입니다.

먼저 드러냅니다. 내가 무엇을 어떻게 바꿨는지를, 동료들이 한눈에 볼 수 있도록 펼쳐놓습니다. 내 작업은 더 이상 내 책상 위에만 있지 않고, 모두가 들여다볼 수 있는 자리로 나옵니다. 숨기지 않는다는 것, 내 변화를 투명하게 내보인다는 것이 첫 번째입니다.

다음으로 설명합니다. 좋은 Pull Request에는 으레 설명이 따라붙습니다. “저는 이런 문제를 풀기 위해, 이런 방식으로, 이렇게 바꿨습니다.” 내 작업을 그냥 던져놓고 “알아서 보라”는 것이 아니라, 받는 사람이 이해하기 쉽도록 맥락을 갖추어 내미는 것입니다. 이것은 일종의 배려입니다. 내 결과물이 그 자체로 완벽하니 너희가 알아서 파악하라는 태도와, 너희가 검토하기 편하도록 내가 정리해 왔다는 태도는 다릅니다.

마지막으로 동의를 구합니다. 드러내고 설명한 뒤, 개발자는 기다립니다. 동료들이 살펴보고 “좋습니다, 합치죠”라고 할 때까지. 합칠 능력이 있어도, 그 능력을 혼자 행사하지 않고 함께의 동의를 기다리는 것입니다. 힘이 있어도 절차를 밟는 것, 할 수 있어도 묻는 것이지요.

이 세 가지는 모두 같은 곳에서 나옵니다. “이건 우리 것”이라는 전제 말입니다. 내 것이 공동의 것으로 합쳐지는 그 길목에서, 개발자들은 이 작은 의식을 치릅니다.

우리 것을 바꿀 때는, 우리에게

우리가 함께 살아가며 무언가를 바꾸는 수많은 순간도 다르지 않습니다.

가족이 함께 쓰는 거실의 가구를 옮길 때, 오래 이어온 모임의 규칙을 손볼 때, 여럿이 일하는 팀의 방식을 바꾸려 할 때. 우리는 종종 “이건 명백히 더 나으니까” “내가 책임지면 되니까” 하며 혼자 결정해 밀어붙이고 싶어집니다. 실제로 그렇게 할 힘이 있을 때도 많습니다. 그리고 그것이 더 빠르기도 합니다.

그러나 그것이 나 혼자의 것이 아니라 우리 모두의 것일 때, 거기에는 다른 길이 있습니다. 곧장 밀어 넣는 대신, 한 박자 멈춰 서서 내가 무엇을 바꾸려 하는지 드러내고, 왜 그러려는지 설명하고, 함께 쓰는 이들의 동의를 구하는 길입니다. 이것은 내 판단이 틀렸을까 걱정해서라기보다는, 그 무언가가 나만의 것이 아님을 알기 때문입니다.

번거롭게 느껴지던 그 절차의 정체가 여기 있습니다. 공유된 것에는 공유된 방식으로 다가가야 한다는 것. 내가 아무리 옳고 아무리 빠르게 할 수 있어도, 우리 것을 바꾸는 일은 우리에게 먼저 알리는 데서 시작해야 한다는 것. 그 한 박자의 멈춤이, 함께 쓰는 것을 오래 함께 쓸 수 있게 합니다.

밀어 넣는 대신 당겨가 달라 청하는 일. 그 작은 어순의 차이 안에, 공동의 것을 지켜내려는 마음이 담겨 있습니다.