보이스카우트 규칙

코드를 정리하는 일은 늘 다음으로 밀립니다. 새 기능에는 약속한 날짜가 있고 정리에는 없기 때문입니다. 미루는 쪽이 이번 주에는 언제나 더 빨라 보입니다.

그래서 같은 대화가 분기마다 반복됩니다. 태오가 "결제 쪽 파일이 감당이 안 됩니다. 2주만 주시면 정리하겠습니다" 하고 말하면, 규원은 "이번 분기는 출시가 먼저니까 다음에 보자" 고 답합니다. 다음 분기가 되면 또 다른 출시가 잡혀 있습니다. 정리를 위한 2주는 한 번도 오지 않습니다.

그동안 코드에는 코드 스멜이 쌓입니다. 고장 난 것은 아닌데 구조가 나빠졌다는 신호를 가리키는 말로, 함수 하나가 400줄까지 늘어났거나 같은 계산이 네 파일에 복사되어 있는 상태입니다. 그대로 두면 기술 부채가 됩니다. 미뤄 둔 정리가 쌓여 나중에 더 내게 되는 비용을 말합니다.

보이스카우트 규칙은 그 2주를 기다리지 않기로 한 대답입니다. 정리를 별도 일정으로 올리는 대신 이미 진행 중인 작업에 얹습니다. 이름은 캠프장을 왔을 때보다 깨끗하게 해 두고 떠나라는 보이스카우트의 수칙에서 왔습니다.

다른 일을 하려고 이미 연 파일 안에서, 그 일과 같은 변경 묶음에, 리뷰어가 몇 분이면 확인할 만한 크기의 정리를 하나 얹습니다. 세 가지가 동시에 지켜져야 규칙이 됩니다.

1. 범위는 이미 연 파일로 제한합니다. 알림 버그를 고치러 파일을 열었다면 정리 대상도 그 파일 안입니다. 멀쩡한 옆 파일까지 따라 열기 시작하면 원래 작업이 무엇이었는지 아무도 모르게 됩니다.
2. 크기는 원래 작업보다 작게 잡습니다. 10줄을 고치러 들어가 300줄을 바꾼 풀 리퀘스트는 규칙을 지킨 결과가 아닙니다. 합쳐 달라고 올린 변경 묶음 안에서 버그 수정과 정리가 뒤엉켜 리뷰어가 둘을 구분하지 못합니다.
3. 동작은 그대로 둡니다. 화면에서 달라지는 것이 하나도 없어야 하고, 이 조건 때문에 얹는 정리는 리팩터링의 범위 안에서만 이뤄집니다.

실제로 얹는 것은 이런 것들입니다. 하는 일과 다른 이름이 붙은 변수를 바로잡기, 주석으로 설명해 둔 긴 조건문을 이름 있는 함수로 빼기, 네 곳에 복사된 상수를 한 곳으로 모아 DRY 원칙에 맞추기, 어디서도 부르지 않는 함수를 지우기입니다. 하나에 10분에서 30분이 걸리는 크기입니다.

동작이 그대로인지는 눈으로 확인되지 않습니다. 그래서 단위 테스트가 먼저 깔려 있는 영역에서만 안전합니다. 함수나 모듈 하나를 떼어 자동으로 확인하는 검사라서, 정리하다 무언가를 깨뜨리면 합치기 전에 빨간 줄로 나타납니다. 테스트가 없는 영역이라면 이름 바꾸기처럼 되돌리기 쉬운 것만 건드립니다.

가장 자주 불려 나오는 자리는 코드 리뷰입니다. 합치기 전에 동료가 코드를 살펴보는 절차인데, 이때 리뷰어가 원래 작업과 무관한 정리를 발견하고 왜 들어왔는지 묻거나, 반대로 눈에 띄는 문제를 지나친 작성자에게 손댄 김에 고치자고 제안합니다.

팀 규칙 문서에도 한 줄로 적혀 있는 경우가 많습니다. 새로 들어온 사람에게 코드베이스를 설명할 때 함께 알려 주는 항목이기도 합니다. 정리할 시간을 따로 받지 못하는 팀이 먼저 꺼내는 수단이라서, 규모가 작고 출시 압박이 센 팀일수록 이 규칙에 기댑니다.

도구가 맡는 영역과는 겹치지 않습니다. 린터는 안 쓰는 변수나 빠뜨린 예외 처리 같은 정해진 위반을 자동으로 잡아 주지만, 이름이 하는 일과 맞는지나 이 조건문이 한 덩어리로 묶여야 하는지는 판정하지 못합니다. 사람이 그 파일을 열었을 때만 보이는 것들이 이 규칙의 몫입니다.

그래서 한계도 분명합니다. 아무도 열지 않는 파일은 영영 좋아지지 않습니다. 반년 동안 손이 닿지 않은 영역은 이 규칙으로 닿지 않으니 따로 일정을 잡아야 합니다.

"이번 PR 범위는 아닌데 보이스카우트 규칙으로 변수명만 바로잡아 뒀습니다."

원래 작업과 별개지만 파일을 연 김에 작은 것 하나를 정리했다는 뜻입니다.

"정리 티켓 따로 만들지 말고 보이스카우트 규칙으로 갑시다."

정리 전용 일정을 잡는 대신 각자 그 파일을 여는 김에 처리하자는 제안입니다.

"보이스카우트 규칙은 좋은데 이건 범위가 너무 커요. 리뷰가 안 됩니다."

얹은 정리가 원래 작업보다 커졌으니 변경을 두 개로 나눠 달라는 요청입니다.

페이지덱에서는 이렇게 오갑니다. 태오가 알림 설정이 저장되지 않는 버그를 고치러 파일을 열었다가, 같은 조건식이 세 군데에 복사되어 있는 것을 봅니다. 버그 자체는 12줄이면 끝나지만 조건식을 함수 하나로 빼는 데 20분을 더 씁니다. 올린 변경에는 "버그 수정 외에 중복 조건식 정리 포함" 이라고 한 줄을 적어 둡니다.

리뷰를 맡은 동료는 그 한 줄 덕에 어디까지가 수정이고 어디부터가 정리인지 구분해서 봅니다. 지현은 일정에 영향이 있는지만 확인하고, 20분이라는 답을 듣고는 더 묻지 않습니다. 이 20분이 매주 몇 번씩 쌓이는 것이 팀이 정리 일정을 따로 받지 않고도 버티는 방식입니다.

정리해도 좋다는 허가증으로 읽는 경우가 가장 많습니다. 규칙이 낫게 두고 나오라고만 말하고 얼마나 낫게 할지는 말하지 않으니 그렇게 읽히기 쉽습니다. 하지만 규칙의 절반은 크기 제한입니다. 버그 하나 고치러 들어가 파일 구조를 통째로 바꿔 놓으면, 리뷰어는 300줄을 처음부터 읽어야 하고 정작 그 안에 섞인 수정이 맞는지는 확인하지 못합니다. 이런 변경이 몇 번 반복되면 팀은 규칙 자체를 금지하는 쪽으로 돌아섭니다.

이 규칙만으로 기술 부채를 다 갚을 수 있다고 보는 것도 흔합니다. 손댈 때마다 조금씩 나아지니 시간이 지나면 전체가 좋아질 것처럼 보입니다. 실제로는 사람 손이 자주 닿는 곳만 좋아집니다. 가장 오래되고 가장 무서운 영역일수록 아무도 열지 않아서 그대로 남습니다. 이 점을 모르면 정리 예산을 요청할 근거를 이 규칙이 오히려 가려 버립니다. 규칙을 지키고 있으니 부채는 관리되고 있다는 말로 논의가 닫히는 것입니다.