우선 내적 품질과 외적 품질을 구분해보려고 한다.
- 외적 품질은 시스템을 사용하는 사람들이 인식하는 품질이다. 느리고 직관적이지 않은 사용자 인터페이스는 낮은 외적 품질의 예라고 할 수 있다.
- 내적 품질은 대개 사용자들에게는 직접 드러나지 않지만 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는 것을 지칭한다. 시스템 설계의 일관성, 테스트 커버리지, 코드의 가독성, 리팩토링 같은 것과 관련이 있다.
일반적으로 내적 품질이 높은 시스템이라 하더라도 외적 품질이 낮을 수 있다. 하지만 내적 품질이 낮은 시스템에서 높은 외적 품질을 기대하기란 힘들다. 부실한 기초 위에 멋진 건물을 짓기란 어려운 법이다.
나는 외적 품질을 범위(scope)의 한 부분이라고 본다. 예를 들자면, 우선은 다소 불편하면서 느린 사용자 인터페이스라 하더라도 시스템을 출시한 다음 나중에 깔끔한 버전을 출시하는 것이, 경우에 따라서는 비즈니스 관점에서 보았을 때 전혀 문제가 없는 결정일 수 있기 때문이다. 나는 이와 같은 트레이드오프를 [footnote]Scrum 에서 Product Owner[/footnote]에게 맡겨둔다. 범위를 결정하는 것이 바로 그의 책임이기 때문이다.
반면, 내적 품질은 논의의 대상이 될 수 없다. 어떠한 상황에서도 시스템의 품질을 유지하는 것이야말로 팀이 책임져야 할 사항이며, 이것은 두말할 필요 없이 그냥 협상의 대상이 아니다. 절대로.
- 스크럼과 XP 에서
그간 일정에 맞추기 위해, 또는 성과를 빨리 내기 위해서 어쩔 수 없다고 스스로에게 최면을 걸면서 코드의 품질을 희생해 왔던 일들이 얼마나 많았는지..
