코드 공동 소유

코드에 주인을 두는 쪽이 오히려 자연스러워 보이던 시절이 있었습니다. 결제는 누구, 알림은 누구 하는 식으로 영역을 갈라 맡기면 책임이 분명해지고 서로 부딪힐 일도 줄어듭니다. 맡은 사람이 그 안을 제일 잘 아니 고치는 속도도 빠릅니다.

문제는 그 사람이 자리에 없을 때 드러났습니다. 결제 화면의 문구 한 줄을 고치면 되는 일인데 담당자가 휴가를 가 있어서 일주일을 기다립니다. 급한 마음에 다른 사람이 손대면 "거기는 제가 돌아와서 볼게요" 라는 말이 돌아오고, 실제로 남이 고친 뒤 이상하게 동작한 적이 몇 번 있어서 그 말을 반박하기도 어렵습니다.

시간이 지나면 갈라 둔 경계가 그대로 굳습니다. 각자 자기 영역만 깊이 알고 옆은 전혀 모르는 상태가 되어서, 일을 나눌 때도 누가 손이 비었는지가 아니라 누구 영역인지로 나누게 됩니다. 한 사람 앞에 일이 쌓여 있는데 옆자리는 손이 비어 있어도 옮기지 못하는 상황이 반복됩니다.

코드 공동 소유는 이 경계를 아예 지워 버리자는 규칙입니다. 대신 아무나 고쳐도 망가지지 않는다는 근거를 따로 만들어 두는 것을 조건으로 답니다.

규칙 자체는 한 문장입니다. 필요하다고 판단한 사람이 어떤 파일이든 열어 고치고, 고치기 전에 그 영역을 오래 봐 온 사람에게 허락을 받지 않습니다.

이 규칙이 실제로 서려면 세 가지가 함께 있어야 합니다.

1. 자동 테스트 — 코드가 제대로 도는지 사람이 눈으로 확인하는 대신 기계가 돌려 보는 장치입니다. 함수 하나를 떼어 확인하는 단위 테스트부터 화면을 띄워 실제 흐름을 밟아 보는 것까지 층이 있습니다. 낯선 영역을 건드리고도 망가뜨리지 않았다는 근거가 여기서 나옵니다. 테스트가 없는 코드를 공동 소유로 열면 남의 코드를 고치는 일이 그냥 도박이 됩니다.
2. 지속적 통합 — 각자 고친 것을 하루에도 여러 번 본류에 합치고, 합칠 때마다 테스트를 자동으로 돌리는 방식입니다. 합치는 간격이 짧아야 두 사람이 같은 파일을 만졌을 때 충돌이 작게 끝납니다. 2주치 작업을 들고 있다가 한꺼번에 합치면 그때부터는 누구 코드를 살릴지 고르는 일이 됩니다.
3. 코드 리뷰 — 합치기 전에 동료가 변경을 읽어 보는 절차입니다. 허락을 받는 자리가 아니라, 그 영역의 사정을 아는 사람이 놓친 것을 짚어 주는 자리입니다.

여기에 하나를 더 맞춥니다. 팀 전체가 따르는 코드 작성 규칙입니다. 들여쓰기 칸 수부터 변수 이름 붙이는 방식까지 누가 썼든 같은 모양으로 읽히게 정해 둡니다. 모양이 제각각이면 남의 코드는 읽는 데만 시간이 들어 고치기도 전에 지칩니다.

이 원칙은 혼자 들어오지 않고 같은 방법론의 다른 실천법과 묶여서 들어옵니다.

페어 프로그래밍은 두 사람이 한 화면을 보며 함께 코드를 쓰는 방식인데, 짝을 계속 바꾸면 한 사람만 아는 영역이 애초에 생기지 않습니다. 공동 소유를 선언해 두고 실제로 그 코드를 아는 사람이 하나뿐이면 규칙은 문서에만 남습니다. 몹 프로그래밍은 팀 전체가 한 작업에 붙는 방식이라, 아무도 구조를 모르는 새 영역을 열 때 하루를 들여 모두가 같은 그림을 갖게 만듭니다.

단순 설계도 짝입니다. 지금 필요한 만큼만 만들어 두면 코드가 작고, 작은 코드는 처음 보는 사람도 반나절이면 읽습니다. 반대로 나중을 대비해 미리 깔아 둔 구조는 만든 사람 말고는 왜 그렇게 되어 있는지 알기 어려워서, 결국 그 사람만 고칠 수 있는 영역으로 남습니다.

조직 쪽에서는 핵심 인물 의존 위험을 줄이는 수단으로 읽힙니다. 특정 사람이 빠지면 일이 멈추는 상태를 가리키는 말인데, 코드에서 그 상태는 대개 영역을 갈라 둔 데서 생깁니다. 한 명이 퇴사한 뒤 그 영역의 수정 요청이 석 달 밀렸다면 그건 사람 문제가 아니라 소유 방식의 결과입니다.

"이건 결제 쪽이라 태오한테 물어봐야 할 것 같은데요."

공동 소유가 이름뿐이라는 신호입니다. 코드는 열려 있는데 아는 사람이 한 명이라 실제로는 아무도 못 고치는 상태입니다.

"공동 소유니까 그냥 고쳐서 올려 주세요. 리뷰는 제가 볼게요."

허락을 구하지 말고 고친 뒤에 확인받으라는 뜻입니다. 순서가 뒤바뀐 것이 이 규칙의 전부입니다.

"여기는 테스트가 없어서 아직 공동 소유로 못 열어요."

규칙을 거부하는 말이 아니라 조건이 아직 안 갖춰졌다는 말입니다. 보통 테스트를 먼저 붙이자는 제안이 뒤따릅니다.

페이지덱에서는 문서 공유 링크의 만료 안내 문구를 고치는 일이 계기가 됐습니다. 민서가 문구를 바꿔 달라고 올렸는데 그 화면을 만든 태오가 그 주에 휴가였습니다. 예전 같으면 다음 주로 미뤘겠지만, 다른 개발자가 그대로 고쳐 올렸고 테스트가 다 통과해서 그날 배포됐습니다. 돌아온 태오는 변경 내역을 훑어보고 한 줄을 더 다듬었습니다.

지현은 이 방식이 일정 회의를 바꿨다고 말합니다. 예전에는 할 일 목록을 놓고 누구 영역인지부터 따졌는데, 이제는 누가 손이 비었는지로 나눕니다. 대신 리뷰에 쓰는 시간이 눈에 띄게 늘었고, 팀은 그 시간을 대기 시간과 맞바꾼 것으로 봅니다.

가장 흔한 오해는 이 규칙을 "아무도 책임지지 않는다" 로 읽는 것입니다. 주인이 없으면 망가져도 탓할 사람이 없을 것 같으니 자연스러운 걱정입니다. 실제로는 소유가 사라지는 것이 아니라 팀 전체로 옮겨 가는 것이라, 깨진 상태를 발견한 사람이 곧 고칠 사람이 됩니다. 이 오해를 그대로 두면 팀은 "내 영역이 아니니 알리기만 하자" 는 쪽으로 움직이고, 문제는 알려진 채로 몇 달을 남습니다.

두 번째는 규칙이 없어진다는 오해입니다. 누구나 고칠 수 있다는 말이 아무렇게나 고쳐도 된다는 말처럼 들리기 때문입니다. 실제로는 규칙이 늘어납니다. 낯선 사람이 고쳐도 안전하려면 테스트와 작성 규칙과 리뷰가 앞의 방식보다 더 촘촘해야 합니다. 이 준비 없이 경계만 지우면 몇 주 만에 서로가 서로의 코드를 망가뜨린 기록이 쌓이고, 팀은 다시 영역을 나누자는 결론으로 돌아갑니다.