제품을 만드는 대부분의 회사는 인력과 시간이 충분하지 않다. 이때 가장 먼저 챙기는 것은 속도이고, 가장 먼저 타협하는 것은 품질이다.
제품 초기에는 품질을 조금 희생하는 것이 합리적으로 보일 때가 많다. 아직 사용자가 많지 않고, 요구사항도 계속 바뀐다. 지금 만든 코드가 몇 달 뒤 사라질 수도 있다. 그런 상황에서 모든 코드를 정교하게 만드는 것은 오히려 낭비다.
그래서 어느 정도의 기술부채는 필요하다.
문제는 어떤 기술부채를 언제 갚을지 판단하는 기준이 사라지는 순간이다. 코드 리뷰를 제대로 하지 않는 문화도 마찬가지다.
기술부채는 선형적으로 증가하지 않는다
처음에는 품질을 조금 포기하는 것이 생산성을 높이는 선택처럼 보인다. 조금씩 쌓이는 기술부채는 복잡성과 사이드 이펙트 가능성을 아주 조금 올릴 뿐인 것처럼 보인다.
하지만 회사는 늘 바쁘다. 채용 기준이 높은 회사라면 길게는 1~2년 동안 인력을 충원하지 못하기도 한다.
기술부채를 갚을 시간을 확보하지 못한 채 새 기능만 빠르게 붙이다 보면, 복잡성은 어느 순간 임계점을 넘는다. 그때부터 기술부채는 J 커브를 그리며 증가한다.
결국 대규모 리팩토링을 해야 하는 상황이 오고, “새로 만드는 게 낫겠는데?”라는 말이 나온다.
태도의 부채는 문화가 된다
가장 큰 문제는 품질을 포기하는 과정과 코드 리뷰 부채, 쌓이는 기술부채가 팀의 엔지니어링 태도까지 바꾼다는 점이다. 나는 이것을 엔지니어링 태도의 부채라고 부른다.
이 부채는 아무도 인식하지 못한 사이에 팀의 문화로 굳는다.
기술부채는 코드에만 쌓이는 것이 아니라 팀의 기대 수준과 엔지니어링 태도에도 쌓인다.
기술부채는 나중에 갚을 수 있다. 구조를 다시 만들 수도 있고, 테스트를 추가할 수도 있다.
하지만 품질을 포기해도 괜찮다는 태도가 팀에 자리 잡으면, 그 태도를 되돌리는 데 훨씬 큰 비용이 든다.
기술부채를 만드는 것과 낮은 품질에 익숙해지는 것은 전혀 다른 문제다. 전자는 전략적인 선택일 수 있다. 후자는 문화가 된다.
품질은 조직의 해자다
속도만큼 중요한 것이 품질이다. 속도를 지키면서도 품질을 놓지 않으려는 개인의 태도가 팀의 문화를 만든다. 나는 그 문화가 조직의 해자(moat)라고 생각한다.
눈에 보이는 것은 일정 수준의 테스트 커버리지와 팀원이 읽기 좋은 코드다. 눈에 보이지 않는 것은 엔지니어링 문화다.
품질은 우리가 어떤 엔지니어링 문화를 가졌는지 보여주는 가장 직접적인 결과다.