사소한 것일수록 회의가 길어지는 법칙

가상의 PR 을 하나 떠올려 보자. 결제 모듈에 캐시 계층을 새로 넣는 300줄짜리 변경이다. 리뷰어 세 명 중 두 명은 LGTM 한 줄을 남기고 승인한다. 남은 한 명은 42번째 줄의 data 라는 변수 이름이 너무 막연하다는 댓글을 단다. 그 아래로 items 가 낫다는 의견과 result 가 낫다는 의견이 붙기 시작하더니 하루 만에 댓글이 열네 개가 된다. 캐시가 언제 무효화되는지 물어본 사람은 아무도 없다.

과장처럼 들리겠지만 코드 리뷰를 몇 년 해 본 사람이라면 비슷한 장면을 한 번쯤 봤을 것이다. 이 현상에는 이름도 있다. 사소함의 법칙인데 개발자들 사이에서는 바이크셰딩(bikeshedding)이라는 말로 더 자주 불린다.

이번 포스팅에서는 이 법칙이 어디서 나왔는지 살펴보고 코드 리뷰에서 어떻게 줄일 수 있는지 정리해보려고 한다.

파킨슨의 위원회

영국의 역사학자 시릴 노스코트 파킨슨(C. Northcote Parkinson)은 1957년에 낸 책 『파킨슨의 법칙』에서 가상의 재무 위원회를 하나 그린다. 이날 회의의 안건은 세 개다. 1,000만 파운드짜리 원자로 건설 계약, 사무직원들이 쓸 350파운드짜리 자전거 보관소, 그리고 복지 위원회에 들어갈 1년 21파운드의 다과비다.

원자로 계약은 2분 30초 만에 통과한다. 자전거 보관소는 45분을 끈다. 지붕을 알루미늄으로 할지 아연 도금 철판으로 할지를 두고 말이 오가다가 50파운드쯤 아끼는 쪽으로 끝난다. 다과비 안건은 1시간 15분이 걸린다.

파킨슨은 이 장면을 한 문장으로 정리했다.

안건 하나에 쓰는 시간은 거기 걸린 금액에 반비례한다.

원자로는 위원 대부분이 판단할 만큼 알지 못하니 전문가의 설명을 믿고 넘어간다. 자전거 보관소는 누구나 어떻게 생겼는지 안다. 지붕 재료 정도는 아무나 한마디 보탤 수 있으니 원자로 앞에서 조용했던 위원들도 여기서는 할 말이 생긴다. 회의에 뭔가 기여했다는 걸 보여줄 기회가 자전거 보관소에서 처음 온 셈이다.

바이크셰딩이라는 말

이 이야기가 개발자들 사이에 퍼진 건 1999년이다. FreeBSD 개발자 폴헤닝 캄(Poul-Henning Kamp)이 사소한 변경 하나를 두고 끝없이 이어지는 토론에 지쳐서 파킨슨의 자전거 보관소 이야기를 꺼내는 메일을 썼다. 그 메일 이후로 사소한 것에 쏟는 긴 논쟁을 자전거 보관소를 칠한다는 뜻에서 바이크셰딩이라고 부르게 됐다. FreeBSD FAQ 에는 지금도 자전거 보관소 색이 왜 중요하냐는 제목의 항목이 남아 있다.

코드 리뷰에서 바이크셰딩이 유독 잘 생기는 이유는 의견을 내는 비용이 낮기 때문이다. 캐시 무효화 시점이 맞는지 판단하려면 그 모듈의 데이터 흐름을 따라가야 한다. 30분은 걸린다. 변수 이름이 마음에 안 드는 건 그 줄을 읽는 순간 안다. 3초면 된다. 게다가 30분짜리 판단이든 3초짜리 판단이든 화면에는 똑같이 댓글 하나로 남는다. 리뷰를 했다는 흔적을 남기고 싶은 리뷰어에게 3초짜리 댓글은 꽤 효율 좋은 선택이다.

물론 이름은 중요하다. 잘못 지은 이름 하나가 몇 년 동안 사람들을 헷갈리게 만들기도 한다. 다만 변수 이름에 달린 댓글 열네 개가 캐시 무효화 질문 하나보다 중요한 경우는 드물다. 참고로 파킨슨의 위원회가 자전거 보관소에서 아낀 50파운드는 원자로 예산의 0.0005%다.

사소한 결정은 기계에게

바이크셰딩을 줄이는 가장 확실한 방법은 사람이 논쟁할 거리를 미리 없애는 것이다. 들여쓰기나 따옴표 종류, 줄바꿈 위치 같은 건 포매터가 정하게 두면 된다. Prettier 문서는 옵션을 적게 두는 이유를 이렇게 설명한다.

스타일 논쟁은 어떤 Prettier 옵션을 쓸지에 대한 논쟁으로 바뀔 뿐이다. 옵션은 팀 안에서 바이크셰딩을 많이 일으키는데, 그 점은 미안하게 생각한다.

옵션이 하나 생기면 그 옵션을 두고 회의가 또 열린다. 그래서 Prettier 는 선택지를 줄이는 쪽을 골랐다. 탭이냐 스페이스냐로 하루를 쓰던 팀도 포매터를 들이고 나면 그 논쟁이 대개 사라진다. 결과가 마음에 안 들어도 따질 상대가 없기 때문이다.

이름 짓기처럼 기계가 정해 줄 수 없는 것도 있다. 이런 건 댓글에 무게를 표시해 두면 된다. 꼭 고칠 필요가 없는 의견이면 앞에 nit 이라고 붙여서 넘어가도 괜찮다는 신호를 주는 식이다. 리뷰를 받는 사람은 nit 이 붙은 댓글을 나중으로 미루고 캐시 무효화 같은 질문부터 답할 수 있다.

리뷰를 시작할 때

리뷰어 쪽에서 할 수 있는 일도 하나 있다. PR 을 열면 변수 이름보다 이 변경에서 가장 위험한 줄이 어디인지부터 찾아보자. 결제 모듈이라면 돈이 두 번 나갈 수 있는 경로가 그런 줄이다. 캐시라면 오래된 값이 화면에 보일 수 있는 경로를 먼저 본다. 그 줄에 대한 질문을 먼저 남기고 나면 변수 이름 이야기는 nit 으로 달아도 늦지 않다. 자전거 보관소 지붕 색은 그다음에 정해도 된다.