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

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

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

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

그냥 넣을 수 있는데도

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

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

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

의심해서가 아니라

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

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

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

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

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

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

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

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

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

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

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

저는 이 대목에서 우리가 함께 살아가며 무언가를 바꾸는 수많은 순간들을 떠올립니다.

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

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

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

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