The geometric model of maintenance

entropicthoughts.com 원문을 읽었지만 수집 상한(9,000자) 때문에 기하 모델 소개 중간까지만 읽었어요. 결론부는 못 읽어 partial로 표시해요.

출발점: Shore의 임계 모델

James Shore는 코드 작성에 들인 1인월마다 첫해 10일, 이후 매년 5일의 유지보수가 생긴다고 말해요. 로봇이 만든 코드의 영향에 관한 Shore의 주장은 구체적 숫자에 기대지 않아서, 그 숫자는 실제 데이터가 아니라 가상의 집단 지혜에서 나온 거예요. 저자는 가정 대신 git으로 확인하자고 해요.

측정 방법

커밋을 "신규 개발"과 "유지보수"로 나누고, 커밋 크기(추가+삭제 줄 수)를 노력의 양으로 셌어요. 필요한 유지보수는 실제로 수행됐다고 가정해요. 사용자가 고쳐지지 않은 걸 참고 계속 쓴다면 그건 엄밀히 필요하지 않았던 거라는 논리예요.

tmux 사례

• 2008–2010년: 연 60,000줄, 유지보수 약 50%
• 2010–2014년: 연 16,000줄, 약 50%
• 2014–2022년: 연 38,000줄, 약 80%
• 2022–2026년: 연 18,000줄, 약 55%

전체 약 660,000줄 중 신규 개발은 약 230,000줄로 3분의 1 정도예요. 유지보수 비율이 계속 오른다는 임계 모델의 예측과는 달라요. 그래도 2008–2022년의 유지보수 절대량은 임계 모델이 꽤 잘 맞혔지만, 지수적 성질 때문에 결국 예측이 실제보다 빠르게 올라가요. 저자가 본 모든 프로젝트(급여를 받는 기여자가 중심인 기업 후원 프로젝트 포함)에서 신규 개발이 유지보수에 밀려 크게 줄지 않았다고 해요.

다른 프로젝트

• nginx: 실제 유지보수 63%, 모델 예측 81%로 과대 추정해요. Rust, VSCode, Go도 과대 추정이에요.
• Neovim: 처음부터 유지보수 중심이라 실제 83%, 모델 70%로 과소 추정해요.
• Syncthing: 평생 비율은 70% 대 실제 67%로 비슷하지만 곡선 모양은 전혀 따라가지 못해요. 이런 타이밍 문제가 임계 모델의 큰 결함이라고 해요.

기하 모델

오늘 쓴 100줄이 영원히 매년 5줄의 유지보수를 낳는다는 건 사실이 아닐 거라고 해요. 오래된 코드는 안정적이고, 코드는 점점 다시 쓰여서 5년 뒤엔 남아 있지 않을 수도 있어요. 그래서 유지보수에 기하급수적 감쇠를 넣어요.

• Shore 숫자에 맞추면 유지보수는 작업량의 5%에서 시작해 매달 3.6%씩 줄어요. 100줄 기준 1년 뒤엔 월 3줄, 5년 뒤엔 월 0.5줄, 10년 뒤엔 월 1/20줄이에요. 하지만 이 값도 실제 곡선을 따라가지 못했어요.
• 4%에서 시작해 매달 2.6%씩 줄이면 유지보수 곡선이 신규 개발 곡선을 꽤 가깝게 따라가고, nginx에 잘 맞는다고 해요.