핵심 요약
- 한 하드웨어 출신 개발자가 단위 테스트가 실제 까다로운 버그를 잡는 데는 별 효과가 없다고 지적했습니다.
- 단위 테스트의 진짜 효용은 누구나 코드를 마구 고치는 환경에서 다른 사람이 내 코드를 깨뜨리지 못하게 막는 '영역 표시' 기능이라는 분석입니다.
- 경영진은 저비용으로 품질 관리를 생색내고 개발자는 코드 방어벽을 세울 수 있어 양측 모두 만족하는 균형이 형성되었다고 설명합니다.
요약 하드웨어 분야 출신의 한 소프트웨어 개발자가 '단위 테스트(Unit Test)의 진짜 목적은 버그 잡기가 아니라 개발자의 영역 표시'라는 도발적인 통찰을 내놓아 개발자 커뮤니티에서 큰 공감을 얻고 있습니다.
글쓴이는 소프트웨어 업계가 과거와 달리 코드베이스 크기를 두 배 가까이 불려가며 단위 테스트에 집착하게 된 현상을 분석했습니다. 실제로 까다로운 버그나 성능 문제는 여러 컴포넌트가 맞물려 돌아가는 지점에서 터지기 마련이라 복잡한 통합 테스트가 필요한데, 업계에서는 오히려 모킹(Mocking) 등으로 의존성을 극단적으로 배제한 채 몇 가지 하드코딩된 입출력만 확인하는 단위 테스트에만 머물러 있다는 지적입니다.
그렇다면 왜 버그도 제대로 못 잡는 단위 테스트가 2010년대 이후 업계 표준처럼 자리 잡았을까요? 저자는 그 해답을 '통제 불가능한 잦은 코드 수정과 코드 공동 소유권(Shared Ownership) 문화'에서 찾았습니다. 누구나 코드를 수정할 수 있는 환경에서는 내가 공들여 작성한 코드가 다른 동료의 수정으로 훼손되기 십상입니다. 이때 단위 테스트는 커밋을 통과하기 위한 최소한의 방어선 역할을 해줍니다. 다른 개발자가 내 코드를 건드리려 할 때 테스트가 깨지면, 함부로 지우거나 고치지 못하고 원작자에게 물어보거나 맞춰서 고쳐야 하기 때문입니다.
결국 단위 테스트는 코드의 품질을 획기적으로 높이기 위해서라기보다, '이 코드는 내가 의도해서 만든 것이니 함부로 부수지 말라'고 외치며 자기 밥그릇과 영역을 지키기 위해 코드를 한 번 더 되풀이해 작성하는 방어기제라는 설명입니다. 경영진은 최소한의 비용으로 '품질 관리' 체크박스를 채울 수 있어 만족하고, 개발자는 남들이 내 코드를 마구 헤집어 놓는 참사를 막을 수 있어 완벽한 균형을 이루었다는 흥미로운 분석입니다.
Sponsored · 광고