몹 프로그래밍

일을 나눠 맡는 방식에는 오래된 부작용이 하나 있었습니다. 결제는 태오만, 검색은 다른 사람만 아는 상태가 반년이면 만들어집니다. 그러면 결제에 문제가 생긴 날 태오가 휴가 중이면 그 일은 멈추고, 태오가 돌아와도 자기가 짠 코드를 다시 읽는 데 하루를 씁니다.

코드 리뷰가 이 문제를 절반만 막았습니다. 리뷰는 다 짠 뒤에 받는 절차라서, 방향 자체가 틀어졌을 때는 이미 사흘 치 작업이 쌓인 뒤에 발견됩니다. 그 자리에서 리뷰어가 할 수 있는 말은 대개 둘 중 하나입니다. 전부 다시 하자고 하거나, 이번만 넘기고 다음에 고치자고 하는 것입니다. 뒤쪽을 고르는 일이 반복되면 아무도 자신 있게 손대지 못하는 영역이 하나씩 생깁니다.

아무도 모르는 새 영역을 열 때는 문제가 더 노골적으로 드러났습니다. 각자 흩어져 조사하고 설계 회의를 두 번 하고 나서 코드를 합치면, 세 사람이 서로 다른 그림을 들고 있었다는 사실이 그때 드러납니다. 회의에서 합의했다고 믿은 내용이 실제로는 각자의 머릿속에서 다르게 채워져 있었던 것입니다.

몹 프로그래밍은 이 순서를 뒤집습니다. 나중에 합치고 나중에 리뷰하는 대신, 결정이 내려지는 순간에 관련된 사람이 전부 그 자리에 있게 만듭니다. 페어 프로그래밍이 둘로 하던 일을 팀 크기로 늘린 모양이라고 보면 가깝습니다.

한 번의 몹 세션은 정해진 순서대로 돌아갑니다. 여럿이 모여 이야기하는 자리가 아니라 역할과 교대 시각이 정해진 작업 시간입니다.

1. 작업을 하나만 고릅니다. 결제 취소 흐름을 만든다처럼 그날 끝을 볼 수 있는 크기여야 합니다. 두 개를 동시에 놓으면 관심이 갈라져 참여자 절반이 구경꾼이 됩니다.
2. 타자를 치는 사람 한 명과 방향을 정하는 나머지로 나눕니다. 화면은 하나만 띄우고 모두가 같은 것을 봅니다.
3. 타자를 치는 사람은 자기 판단으로 코드를 쓰지 않습니다. 말로 나온 것만 옮겨 적습니다. 이 규칙이 몹의 핵심입니다. 손이 빠른 사람이 혼자 앞서 나가면 나머지는 따라 읽기만 하게 되고, 그러면 다섯 명이 한 사람의 화면을 구경하는 시간이 됩니다.
4. 10분에서 15분마다 자리를 바꿉니다. 순서를 미리 정하고 타이머를 켜 둡니다. 다섯 명이 12분씩 돌면 한 시간에 한 바퀴가 돕니다.
5. 한 시간에 한 번은 쉽니다. 여럿이 같은 것에 집중하는 시간은 혼자 일할 때보다 빨리 소모됩니다.
6. 세션이 끝나면 그 자리에서 합치고 검증까지 돌립니다. 지속적 통합이 걸려 있으면 자동 검사가 여기서 돌고, 결과를 다 같이 본 뒤에 끝냅니다.

세션 길이는 2시간에서 3시간이 흔합니다. 종일 하는 팀도 있지만 처음 시작하는 팀에게는 권하지 않습니다. 오전 3시간을 한 뒤 오후에 각자 흩어지는 형태가 관리하기 쉽습니다.

참여자는 그 작업의 결정에 실제로 관여하는 사람입니다. 개발자 셋에서 다섯이 기본이고, 화면 동작을 정해야 하면 민서가, 규칙을 정해야 하면 지현이 그 구간에만 들어왔다 나갑니다. 여섯을 넘기면 발언 차례가 돌아오지 않는 사람이 생기고, 그 사람은 노트북을 열어 다른 일을 시작합니다.

시점은 넷으로 정리됩니다.

1. 아무도 구조를 모르는 새 영역을 열 때. 조사와 설계와 구현이 한자리에서 붙어 진행되니 합의가 어긋날 자리가 없습니다.
2. 한 번 틀리면 되돌리기 어려운 부분을 만질 때. 결제와 권한이 대표적입니다. 잘못 나간 금액은 코드를 되돌려도 원래대로 돌아오지 않습니다.
3. 새로 합류한 사람에게 코드를 넘길 때. 문서를 읽히는 것보다 빠르고, 넘기는 쪽도 자기가 무엇을 설명 못 하는지 그 자리에서 알게 됩니다.
4. 설계를 두고 회의가 두 번 넘게 반복될 때. 말로 좁혀지지 않던 차이가 코드를 한 줄 쓰는 순간 드러나는 경우가 많습니다.

반대로 쓰지 않는 때도 분명합니다. 문구 수정이나 비슷한 화면을 하나 더 만드는 일처럼 판단할 것이 없는 작업은 혼자가 빠릅니다. 빈도도 매일이 아닙니다. 주에 한 번 반나절을 정해 두고 그때 다룰 작업을 모아 두는 팀이 많습니다.

"이건 몹으로 하죠. 혼자 들어가면 이틀 걸리고 그동안 아무도 못 봅니다."

작업 시간보다 지식이 한 사람에게만 남는 쪽이 더 비싸다는 판단입니다.

"오늘 오전 몹은 결제 취소 흐름이에요. 태오가 먼저 치고 12분씩 돌립니다."

역할과 교대 간격을 미리 못 박아 두는 말입니다.

"두 시간 몹으로 짠 거라 리뷰는 따로 안 받을게요."

리뷰가 짜는 동안 이미 끝났으니 절차를 중복하지 않겠다는 뜻입니다.

페이지덱이 유료 결제를 붙이던 분기에 태오가 이 방식을 꺼냈습니다. 결제 취소와 환불 금액 계산은 한 번 틀리면 고객 돈이 잘못 나가는 부분이라, 혼자 짜고 리뷰를 받는 순서로는 확신이 서지 않았습니다. 개발자 셋이 오전 3시간을 잡고 12분씩 교대했고, 환불 정책을 정해야 하는 대목에서 지현이 30분 들어왔습니다.

그날 나온 코드의 양은 태오 혼자 짰을 때의 절반쯤이었습니다. 대신 셋 다 그 코드를 읽을 수 있게 됐고, 두 달 뒤 환불 규칙이 바뀌었을 때 그 자리에 없던 사람이 아니라 아무나 그 일을 맡을 수 있었습니다.

다섯 명이 한 작업을 하니 생산성이 5분의 1이 된다고 읽는 경우가 가장 많습니다. 사람 수와 결과물을 곱셈으로 보면 자연스러운 계산입니다. 하지만 혼자 짤 때 빠져 있던 시간이 이 계산에서 빠져 있습니다. 리뷰를 기다리는 시간, 리뷰에서 방향이 틀렸다는 말을 듣고 되돌리는 시간, 반년 뒤 그 코드를 아는 사람이 하나뿐이라 생기는 대기가 그것입니다. 이 오해를 그대로 두면 팀은 몹을 쓸 자리에서 쓰지 못하고, 결국 한 사람만 아는 영역을 계속 늘려 가게 됩니다.

몹이 초보를 가르치는 시간이라고 보는 것도 흔합니다. 여럿이 모여 한 화면을 보는 모습이 교육처럼 보이기 때문입니다. 실제로는 경력자끼리 할 때 효과가 더 크게 나오는 자리가 많습니다. 설계가 갈리는 지점은 아는 사람들 사이에서 갈리기 때문입니다. 교육으로만 쓰면 경력자들은 자기 시간을 뺏긴다고 느끼고, 그 인식이 한번 굳으면 정작 필요한 순간에 모으기 어려워집니다.