페어 프로그래밍

혼자 쓰고 나중에 확인받는 순서에는 되돌리기 비용이 붙습니다. 구조를 잘못 잡은 것을 이틀 뒤에 지적받으면 이틀 분량을 다시 써야 합니다. 지적한 쪽도 이미 완성된 코드를 두고 처음부터 다르게 가자고 말하기가 어려워서, 고치는 대신 넘어가는 선택이 반복됩니다.

지식이 한 사람에게 고이는 문제도 함께 옵니다. 페이지덱에서 결제 처리 코드를 아는 사람은 태오뿐이었습니다. 태오가 휴가를 간 주에 결제 실패가 났고, 화면을 열어 본 사람은 셋이었지만 어디를 봐야 하는지 아는 사람이 없어 태오가 연락을 받고 원격으로 고쳤습니다.

같은 시기에 새로 합류한 개발자는 첫 2주 동안 리뷰에서 같은 지적을 여섯 번 받았습니다. 지적은 매번 정확했지만 전달되는 시점이 늦었습니다. 페어 프로그래밍은 그 시점을 쓰는 동안으로 옮깁니다. 이틀 뒤가 아니라 그 자리에서 방향을 잡는 것이 이 방식의 전부입니다.

한 작업과 한 화면을 두 사람이 나눠 맡되 역할을 먼저 정합니다. 여섯 단계로 돕니다.

1. 역할을 둘로 나눕니다. 키보드를 잡고 코드를 쓰는 쪽과, 쓰지 않고 방향과 다음 단계와 빠진 경우를 살피는 쪽입니다. 두 사람이 동시에 같은 층위를 보면 논쟁만 길어지므로 보는 높이를 나누는 것이 이 구분의 뜻입니다.
2. 작업 하나를 고릅니다. 30분 안에 결과를 확인할 수 있는 단위가 좋습니다. 반나절짜리를 통째로 잡으면 중간에 집중이 끊기고 한 사람이 구경하는 시간이 길어집니다.
3. 25분마다 역할을 바꿉니다. 타이머를 켜 두고 기계적으로 넘깁니다. 바꾸지 않으면 손이 빠른 쪽이 계속 치고 다른 쪽은 화면을 보는 사람이 되는데, 그 상태는 두 사람이 붙어 있을 값어치가 없습니다.
4. 살피는 쪽은 문법과 오타를 지적하지 않습니다. 그런 것은 도구가 잡습니다. 대신 값이 없을 때 어떻게 되는지, 이 이름이 나중에도 읽히는지, 이 구조가 다음 요구를 받을 수 있는지를 묻습니다.
5. 두 시간에 한 번씩 쉽니다. 말하면서 쓰는 작업은 혼자 쓰는 것보다 집중 강도가 높아 오래 못 갑니다. 무리하지 않는 강도를 유지하자는 지속 가능한 속도가 이 방식에서 특히 필요합니다.
6. 끝나면 알게 된 것을 한 줄 남깁니다. 둘 사이에서만 오간 판단은 다음 주에 세 번째 사람이 같은 자리에서 다시 막히게 만듭니다.

떨어져 일하는 경우에는 화면을 공유하는 것만으로 부족합니다. 양쪽이 번갈아 키보드를 잡을 수 있는 도구가 있어야 3번 단계가 성립합니다.

누구와 누구를 붙이는지, 그리고 언제 붙는지가 효과를 정합니다.

조합은 셋으로 나뉩니다. 숙련자와 새로 합류한 사람을 붙이면 전수가 목적이 되고, 쓰는 속도는 느려지는 대신 같은 지적이 반복되는 일이 사라집니다. 숙련자 둘을 붙이면 구조를 정하는 작업에 맞습니다. 결정이 필요한 자리에서 두 사람의 반대 의견이 그 자리에서 정리됩니다. 새로 합류한 사람끼리 붙이는 조합은 권하지 않습니다. 둘 다 모르는 것을 함께 모르는 시간이 길어집니다.

붙는 시점은 넷입니다. 처음 들어가는 영역을 다룰 때, 구조를 정해야 할 때, 장애 원인을 쫓을 때, 한 사람만 아는 코드를 건드릴 때입니다. 반대로 반복 작업이나 이미 결정이 끝난 단순 수정, 문서를 읽는 시간에는 붙지 않습니다. 이때 붙어 있으면 한 사람의 시간이 그대로 사라집니다.

하루 종일 하지 않습니다. 하루 두 시간에서 네 시간을 정해 두고 나머지는 각자 일하는 방식이 실무에서 오래갑니다. 누구나 어느 코드든 고칠 수 있게 하자는 코드 공동 소유와 짝으로 움직이고, 지식을 흐르게 하는 수단이 이 방식입니다. 지금 필요한 만큼만 설계하자는 단순 설계와도 이어집니다. 두 사람이 그 자리에서 설명할 수 있는 만큼으로 구조가 유지되기 때문입니다.

"이 부분은 같이 하죠. 저만 아는 코드로 남기고 싶지 않습니다."

작업 배분이 아니라 지식 분산을 이유로 든 말입니다.

"25분 됐어요. 키보드 넘기겠습니다."

역할 교대를 사람의 판단이 아니라 시간으로 정해 뒀다는 뜻입니다.

"오타는 그냥 두시고, 값이 없을 때 어떻게 되는지만 봐 주세요."

살피는 쪽이 볼 층위를 다시 맞추는 말입니다.

태오와 새로 합류한 개발자가 2주 동안 오후마다 짝을 지었습니다. 리뷰에서 같은 지적이 반복되는 일은 첫 주에 사라졌습니다. 결제 처리 코드도 그 기간에 함께 들어가 두 사람이 아는 코드가 됐습니다.

첫 주에는 아침부터 저녁까지 붙어 있었고 둘 다 목요일에 지쳤습니다. 말하면서 쓰는 시간이 혼자 쓰는 시간보다 훨씬 무거웠기 때문입니다. 둘째 주에는 오후 두 시간으로 줄였고, 줄인 뒤의 2주가 처음 방식보다 결과가 좋았습니다. 붙어 있는 시간의 길이가 아니라 어디에 붙는지가 값을 만들었습니다.

두 사람이 하나를 하니 생산성이 절반이라고 읽는 경우가 가장 많습니다. 사람 수와 산출물을 나눠 보면 그렇게 계산됩니다. 하지만 혼자 쓰는 방식에는 뒤에 붙는 시간이 있습니다. 리뷰를 기다리는 시간, 지적을 받고 다시 쓰는 시간, 한 사람만 아는 코드를 나중에 다른 사람이 읽는 시간입니다. 그 합계와 견줘야 계산이 맞습니다. 다만 모든 작업에 이 방식을 쓰면 실제로 낭비가 됩니다. 어디에 쓸지를 고르는 일이 이 방식의 절반입니다.

리뷰를 대체한다고 읽는 것도 흔합니다. 쓰는 동안 다른 사람이 봤으니 다시 볼 필요가 없어 보입니다. 부분적으로는 맞지만 두 가지가 빠집니다. 함께 쓴 두 사람은 같은 전제를 공유하게 되므로 그 전제 자체가 틀렸을 때 아무도 알아채지 못합니다. 그리고 왜 그렇게 정했는지가 기록으로 남지 않습니다. 짝을 지은 작업에도 가벼운 확인을 한 번 거치게 두는 팀이 많은 이유가 그것입니다.