지난 주 팀 회고에서 구성원 중 한 분께서 이런 주제를 던져주셨다.

“최근 작업 하나를 하면서 드는 생각이 있었습니다. 실제 버그 픽스는 딱 한줄 수정한 것 뿐인데, 굳이 이를 위한 테스트 케이스 작성과 문서 작성을 꼭 해야 하나하는 자문였습니다.”

항상 고민스러운 주제다.

버그를 수정할 때 변경할 소스 코드가 단 한 줄 뿐이라면, (한 줄은 아니더라도 너무 뻔한 버그라면) 얼른 수정해서 눈 앞에서 치워버리고 싶다는 생각이 들게 마련이다. 한 줄을 고치면서도 물론 코드 리뷰도 하고, 테스트 케이스도 작성해서 돌려보고, 문서도 충실하게 수정할 수도 있겠지. 하지만 그렇게 하는 사람이 몇이나 될까? 그게 과연 효율적인 행동일까?

(솔직히 고백하자면, 간단한 수정하면서 난 그렇게 해 본 적도 없고, 이런 주제를 갖고 고민해본 적도 없다.)

.

.

.

그 다음 날 책을 보다 그 책에서 정말 우연히도 이런 그래프를 발견했다.

FFR은 “Fault Feedback Ratio”의 약자다. 우선 “Fault Feedback”이란, 버그를 수정하면서 시스템에 또 다른 버그가 생겨나는 것을 말한다. 따라서, FFR은 한 번 수정할 때 몇 개의 버그가 새로 생기는지를 의미하는데, 만약 FFR 값이 0.4라면 버그를 1번 수정하면 0.4개의 버그가 새로 생긴다는 뜻이다. FFR을 살펴보면 해당 조직의 소프트웨어 개발 문화를 매우 정확하게 유추해볼 수 있다.

“Lines of Code Changed”는 변경한 코드가 몇 줄인지를 나타내고 있다. 따라서, 이 그래프는 각 버그 수정마다 몇 줄의 코드를 수정했는지, 그리고 그 수정으로 인해 몇 개의 버그가 새로 생겼는지를 보여주는 그래프다.

대개 변경한 코드가 늘어날수록 (즉, 복잡한 버그일수록) FFR이 높을 것이라고 생각한다.  상대적으로 복잡한 버그를 수정할 때 실수할 가능성이 더 높아지고 올바르게 변경하기 어려울 것이라고 예상하는 것이다. 나도 그렇고 사람들은 대부분 당연히 그렇게 생각한다. 그 가설이 바로 그래프에 있는 점선이다.

그러나, 실제 측정치는 생각과는 달랐다. 그래프에서 볼 수 있는 작은 원이 실제 측정한 값이다. 사람들의 예상을 뒤엎고, 몇 줄 안되는 간단한 수정에서 더 많은 버그가 새로 생겨났던 것이다. 어떤 버그 수정이 사소하다는 생각이 들면, 그 생각으로 인해 신중한 판단의 가능성이 낮아져, 결국 FFR이 높아지는 모습을 보여주고 있다.

“문제를 쉽게 해결할 수 있다는 생각이, 오히려 문제 해결의 가능성을 낮춘다.”

저자는 단 한 줄을 바꾸더라도, 그 코드를 리뷰하고, 테스트 케이스를 작성하고, 문서로 정리하는 일은 결코 시간 낭비가 아니라고 말한다. 나는 리뷰/테스트 케이스 작성/문서화라는 행위자체가 중요한 것은 아니라는 생각이 든다. 한 줄을 바꾸더라도 그런 실천이 왜 의미가 있는지에 대한 구성원들의 이해와 공감대, 그리고 그것을 이루려는 노력이 중요하다. 아마 저자도 그런 이야기를 하고 싶었을 것이다.

이런 고민을 해볼 기회를 던져주신 우리 개발실의 도형님께 감사!