5분 투자, 평생 편해지는 법 - 작은 문제를 바로 고치는 팀의 차이
몇 년 전 프로젝트에서 빌드 로그에 경고 하나가 떴다. 빌드는 통과했고, 게임도 실행됐다. 누구도 급한 일로 보지 않았다. “이건 나중에 정리하자”는 말이 나왔고, 다들 고개를 끄덕였다. 문제는 그런 경고가 늘 그렇듯 혼자 남지 않았다는 점이다. 몇 달 뒤에는 경고가 너무 많아져서 아무도 읽지 않는 로그가 되었고, 그 안에 실제 문제 신호도 함께 묻혀버렸다.
돌이켜보면 대형 사고는 대개 거창한 한 번의 실수보다, 사소한 문제를 오래 방치한 결과로 왔다. 빌드 경고, 오래된 문서, 스킵된 테스트, 애매한 네이밍, 죽은 코드. 각각은 별것 아닌 것처럼 보이지만, 쌓이면 팀의 판단력을 흐리게 만든다.
이 글은 바로 그 지점을 다룬다. “5분이면 고칠 수 있는 것”을 왜 바로 고치는 팀이 결국 더 멀리 가는지에 대해서다.
깨진 유리창은 법칙이라기보다, 소프트웨어에서 오래 살아남은 은유다
여기서 자주 인용되는 비유가 깨진 유리창이다. 원래 이 표현은 1982년 제임스 윌슨과 조지 켈링이 제안한 범죄학 이론에서 왔다. 다만 이 이론은 사회과학 안에서도 논쟁적이다. 브리태니커 요약만 봐도, 무질서가 실제로 범죄를 유발하는지에 대해서는 경험적 증거가 충분하지 않다는 비판이 함께 소개된다. 그러니 이 개념을 다른 분야에 가져올 때는 “검증된 법칙”처럼 말하기보다 은유로 다루는 편이 정직하다.
그럼에도 이 비유가 소프트웨어 업계에서 오래 살아남은 이유는 분명하다. 《The Pragmatic Programmer》의 저자인 Andrew Hunt와 David Thomas는 이 이미지를 끌어와 소프트웨어 엔트로피(software entropy)를 설명했다. 나쁜 설계, 틀린 결정, 지저분한 코드 같은 작은 손상을 방치하면, 팀 전체가 그 손상을 정상 상태로 받아들이기 시작한다는 것이다.
이 은유는 직관만 있는 말도 아니다. 최근 소프트웨어 공학 연구 중에는 기술 부채 밀도가 높은 시스템에서 작업한 개발자들이 기능을 확장하는 과정에서 더 많은 코드 스멜과 비기술적 선택을 추가하는 경향을 보였다는 실험도 있다. 표본이 아주 큰 연구는 아니지만, 적어도 “지저분한 환경이 더 지저분한 결정을 부른다”는 감각이 완전히 근거 없는 직감만은 아니라는 뜻이다.
그래서 내가 이 비유를 좋아하는 이유는 그것이 절대 법칙이어서가 아니다. 팀이 작은 방치를 얼마나 빨리 정상화하는지를 아주 잘 보여주기 때문이다.
실제 현장에서는 작은 문제들이 팀의 판단력을 망가뜨린다
게임 개발 현장에서 “5분이면 되는데 아무도 안 하는 일”은 생각보다 많다.
빌드 경고 정리. 경고는 에러가 아니기 때문에 미루기 쉽다. 하지만 경고가 수십 개, 수백 개로 쌓이면 로그는 더 이상 신호가 아니라 소음이 된다. 그러면 정말 위험한 경고도 눈에 안 들어온다.
공유 문서 업데이트. 설정 구조가 바뀌었는데 위키가 옛날 상태로 남아 있으면, 다음 사람이 틀린 문서를 사실로 믿고 시간을 태운다. 수정자는 5분을 아꼈지만, 팀은 반나절을 잃는다.
실패 테스트를 스킵으로 돌려놓기. 테스트가 깨졌을 때 원인을 고치지 않고 스킵해 두면, 테스트 스위트 전체에 대한 신뢰가 떨어진다. 한 번 신뢰를 잃은 테스트는 점점 덜 실행되고, 결국 존재 이유를 잃는다.
포맷팅과 툴 설정 미루기. .editorconfig, 린터, 포매터를 초기에 맞추지 않으면 코드 리뷰에서 실제 로직보다 공백과 줄바꿈을 더 오래 보게 된다. 그건 생산성 손실일 뿐 아니라, 리뷰의 집중력을 갉아먹는 일이다.
이 일들의 공통점은 해결 난도가 낮다는 데 있다. 어렵지 않기 때문에 더 쉽게 미뤄지고, 더 쉽게 누적된다.
사람들이 작은 문제를 미루는 이유
실무에서 반복해서 보이는 패턴은 대체로 비슷하다.
첫째, 누군가 하겠지라는 분위기다. 책임이 명확히 지정되지 않은 일일수록 더 잘 떠다닌다. 기능 구현은 담당자가 뚜렷하지만, 경고 정리나 문서 최신화는 그렇지 않은 경우가 많다.
둘째, 가시적인 성과가 아니라는 인식이다. 새 기능은 데모에서 보이고, 버그 수정은 티켓에 남는다. 하지만 문서 정리나 경고 제거는 눈에 잘 안 띈다. 평가되지 않는 일은 쉽게 뒤로 밀린다.
셋째, 지금 끊기 싫다는 심리다. “이 함수만 끝내고 하자”라는 생각은 늘 합리적으로 들린다. 문제는 그 다음에도 끝낼 함수가 계속 생긴다는 점이다. 5분짜리 일이 미뤄지는 가장 흔한 이유는 시간이 없어서가 아니라, 우선순위가 영원히 돌아오지 않아서다.
이건 대단한 인간 심리 이론을 들이밀지 않아도, 대부분의 팀이 바로 알아볼 수 있는 장면일 것이다.
즉시 해결하는 문화는 개인 성실함보다 구조에서 나온다
작은 문제를 바로 고치는 습관을 개인 덕목으로만 두면 오래가지 않는다. 팀 구조가 그 행동을 쉽게 만들어줘야 한다.
가장 유용한 원칙 중 하나가 보이스카우트 규칙(Boy Scout Rule)이다. 《Clean Code》의 저자 Robert C. Martin은 코드를 건드리고 나올 때는 들어갔을 때보다 조금 더 깨끗하게 두라고 말한다. 이 원칙의 좋은 점은 대청소를 요구하지 않는다는 데 있다. 변수 이름 하나, 불필요한 주석 하나, 어색한 조건문 하나만 고쳐도 된다. 작은 개선을 일상화하는 규칙이다.
실무적으로는 다음 장치들이 효과가 좋다.
경고 제로 정책. 새 경고가 생기면 바로 처리하게 만드는 구조다. 가능하면 warnings-as-errors로 묶는 편이 가장 강력하다.
작은 유지보수의 가시화. 문서 정리, 테스트 보수, 툴링 정비 같은 일도 스프린트 회고나 리뷰에서 짧게라도 언급해야 한다. 그래야 팀이 그것을 “보이지 않는 잡일”이 아니라 “품질 유지 작업”으로 인식한다.
5분 룰의 명시적 합의. 정말 5분 안에 끝낼 수 있는 일이라면 미루지 않는다는 합의가 있으면, 애매한 청소 작업이 백로그 밖으로 밀려나는 일을 줄일 수 있다.
핵심은 의지만으로 버티는 것이 아니라, 작은 정리를 기본값으로 만드는 것이다.
핵심 정리
작은 문제를 방치하면 팀은 그 상태를 빠르게 정상으로 받아들인다. 깨진 유리창 이론 자체를 소프트웨어에 그대로 옮겨와 법칙처럼 말하는 것은 조심해야 하지만, 작은 손상이 더 큰 방치를 부른다는 은유는 개발 현장에서 여전히 유효하다. 《The Pragmatic Programmer》가 말한 software entropy와, 기술 부채 밀도가 이후 품질 저하 선택을 자극할 수 있다는 최근 연구는 그 감각을 뒷받침한다.
결국 중요한 것은 거창한 리팩터링 결심이 아니다. 경고 하나, 문장 하나, 테스트 하나를 바로 고치는 습관과 그것을 장려하는 팀 구조다. 그런 팀이 시간이 갈수록 더 편해진다.
마치며
코드 품질이 좋은 팀은 대개 천재가 많은 팀이 아니라, 사소한 것을 사소하게 여기지 않는 팀이었다. 반대로 후반에 무너지는 팀은 대개 초반에 “이 정도는 그냥 두자”를 너무 자주 허용한 팀이었다.
5분 투자라는 말은 생산성 자기계발 문구처럼 들릴 수 있다. 하지만 개발 현장에서는 꽤 현실적인 운영 원칙이다. 지금 눈앞의 작은 문제를 바로 고치느냐, 아니면 미래의 팀원에게 넘기느냐. 그 선택이 쌓여서 결국 팀의 기본 체력이 된다.
참고 자료
- Encyclopaedia Britannica, Broken windows theory: https://www.britannica.com/topic/broken-windows-theory
- William Levén, Hampus Broman, Terese Besker, Richard Torkar, The Broken Windows Theory Applies to Technical Debt (arXiv): https://arxiv.org/abs/2209.01549
- Andrew Hunt, David Thomas. (2019). The Pragmatic Programmer: 20th Anniversary Edition. Addison-Wesley.
- Robert C. Martin. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.