풀 리퀘스트

학급 문집에 원고를 내미는 순간

우리 반이 함께 학급 문집을 만든다고 생각해 볼게요. 완성된 원고 묶음은 교무실 책상에 딱 한 부만 놓여 있어요. 서른 명이 저마다 볼펜을 들고 이 한 부에 달려들면, 누가 무엇을 고쳤는지 아무도 모르는 엉망진창이 되고 말아요.

그래서 보통은 이렇게 해요. 원고를 복사해 내 사본을 만들고, 거기에만 마음껏 고쳐 써요. 다 고친 뒤에는 편집 담당에게 사본과 함께 쪽지를 건네요.

쪽지에는 '3쪽 둘째 문단의 오타를 고쳤어요'처럼 무엇을 왜 바꿨는지 적어요. 편집 담당은 그 쪽지를 보고 바뀐 자리만 확인하면 되니 훨씬 편해요. 프로그램을 함께 만들 때도 이와 비슷한 쪽지를 주고받는데, 그것이 바로 합쳐 달라는 제안서예요.

영어 머리글자를 따서 PR이라고 짧게 부르기도 하고, 도구에 따라 머지 리퀘스트라는 다른 이름으로 부르기도 해요. 이름은 달라도 하는 일은 같아요.

왜 바로 고치지 않고 제안할까요?

가장 큰 이유는 눈이 하나 더 붙기 때문이에요. 내 사본이 원본에 합쳐지기 전에 동료들이 먼저 읽어요. 이 과정을 코드 리뷰라고 부르는데, 문집으로 치면 편집 담당이 원고를 읽어 보는 일이에요.

두 번째 이유는 기록이에요. 제안서에는 바뀐 줄이 한눈에 표시되고, 오간 대화도 그대로 남아요. 몇 달 뒤에 '이 부분은 왜 이렇게 되어 있지?' 하는 의문이 생기면 그때의 쪽지를 찾아 읽으면 돼요.

세 번째 이유는 안전이에요. 제안이 받아들여지기 전까지 원본 문집은 그대로 멀쩡해요. 사본에서 아무리 크게 갈아엎어도 다른 사람의 작업은 흔들리지 않아요.

그래서 회사든 공개 프로젝트든 이 절차를 즐겨 써요. 처음 보는 사람도 사본을 만들어 고친 뒤 쪽지를 내밀면, 원본을 관리하는 사람이 읽고 판단해요. 낯선 사람의 도움을 안전하게 받는 방법인 셈이에요.

조금 더 정확히 말하면: 쪽지는 원고가 아니에요

다시 문집 이야기로 돌아와 볼게요. 편집 담당에게 건넨 쪽지 자체는 원고가 아니에요. '이 사본을 읽고 합쳐 주세요'라고 부탁하는 말과, 그 부탁을 두고 나눈 대화가 담긴 자리일 뿐이에요.

조금 더 정확히 말하면 제안서는 고친 내용을 담은 대화창이에요. 실제로 고친 글은 내 사본에 들어 있고, 제안서는 그 사본을 가리키며 이야기를 나누는 창구 역할을 해요. 그래서 제안서를 열어 둔 채로 사본을 더 고치면, 창 안의 내용도 따라서 바뀌어요.

한 가지 더 짚어 둘 점이 있어요. 제안서를 냈다고 해서 합쳐지는 것이 정해진 것은 아니에요. 읽어 본 사람이 고쳐 달라고 요청할 수도 있고, 방향이 맞지 않아 그대로 닫힐 수도 있어요.