결함은 개발자 때문이다.

결함은 왜 생기는 것일까요?

많은 경우 우리는 결함은 개발자 때문에 생긴다고 생각합니다. 어떤 조직에서는 개발자 별로 결함율을 측정하여 인사고과를 매기는 곳도 있습니다.

그런데 과연 결함은 개발자 때문에 생기는 것일까요?

이 질문에 대답하기 전에 생각해 볼것은 결함이란 무엇인가? 하는 질문입니다.

결함은 무엇일까요?

답을 확인 하기 전에 한번 꼭 생각해 보시기 바랍니다.

펼쳐두기..

결함은 에러로 인하여 발생할 수 있는 장애나 어떤 사건을 실제로 확인한 경우 결함이라고 부릅니다.

에러는 인간의 실수로 발생합니다.

정리하면 결함은 소프트웨어 개발 중 사람의 실수로 인하여 소프트웨어가 기대한 결과와 다르게 작동하거나 장애를 발생시킬 수 있는 상황을 발견한 것이라고 할 수 있습니다.

하지만 결함이 모두 장애를 일으키는 것은 아닙니다.

여기서 중요한 것은 사람의 실수 입니다.

여기서 말하는 사람은 꼭 개발자만을 지칭하는 것이 아니라는 것이 중요합니다.

소프트웨어 개발에는 매우 많은 사람이 참여합니다.

기획자, 사용자 분석가, 개발자, 그래픽 디자이너, 테스터, 마케터 등등 적게는 10여명부터 많게는 수백명이 넘는 사람이 소프트웨어 개발에 참여합니다.

이 모든 사람이 하는 실수는 곧 에러가 되고 이러한 에러가 결함이 됩니다.

때문에 결함이 꼭 개발자 때문에 생기는 것은 아닙니다.

사용자가 자신이 원하는 기능을 잘 정의하지 못하는 경우도 결함이 될 수 있으며, 사용자의 요구사항을 잘못 설계하는 경우도 결함이 될 수 있고, 테스터가 요구사항이나 기능 명세를 잘 못 분석하여 설계한 테스트 케이스 때문에 결함이 생길 수도 있습니다.

즉, 결함은 누구나 만들어 낼 수 있기 때문에 소프트웨어 개발에 참여하는 사람들은 그러한 사실을 인지하고 늘 조심해야 합니다. 그러기 위해서 모든 구성원이 기초적인 테스트 지식을 가지고 있는 것이 좋습니다.

그런데 문제는 이것 뿐만이 아닙니다.

결함은 사람 때문에 생깁니다. 아마 소프트웨어가 지상에 존재하는 한 절대로 결함이 없는 제품은 있을 수가 없을 것입니다. 만약에 기술이 너무 발전해서 개발이 100% 자동화된다고 하더라도 개발을 시작하는 요구사항은 사람에게서 나올 것이고 자동화된 개발 도구도 역시 사람이 만든 것이기 때문에 결함은 계속 존재하게 될 것입니다.

하지만 결함은 사람의 문제이다라는 가정이 존재하는 한 결함은 절대 줄어들지 않을 것입니다.

결함이 사람의 문제라는 것을 가정하게 될 경우 우리는 성과 측정에 결함율을 사용하게 됩니다.

결함율로 테스터의 자질을 평가하고 개발자의 자질을 평가하게 되는 것입니다.

이것은 개발자나 테스터의 능력을 향상시키는 데 아무런 도움도 되지 못합니다.

그리고 결함발생율을 줄이는데도 아무런 도움도 되지 못합니다.

1980년대 품질관리운동에서 품질 결함 중 20% 이하의 경우에만 사람의 실수로 발생하는 결함이 있다는 사실이 밝혀진바 있습니다.

즉 결함이 사람의 문제이고 사람의 능력을 향상시키면 결함이 줄어들 것이라는 사고 방식으로는 지금까지의 결함 발생율중 20% 정도만 줄어들 뿐 더 큰 효과를 볼 수 없다는 것입니다.

그렇다면 결함이 사람의 문제가 아니라면 무엇이 문제인걸까요? 어떻게 하면 결함이 적은 제품을 만들 수 있는 것일까요?

여기서 생각해 볼 것은 사람의 실수 입니다.

사람이 왜 실수를 하는 가를 생각해 볼 필요가 있습니다.

잘 몰라서, 몸이 안좋아서, 주변에 슬픈일이 생겨서 등으로 사람은 실수를 할 수도 있습니다.

하지만 그보다 더 큰 문제는 바로 시스템 즉, 프로세스입니다.

우리가 소프트웨어를 개발하면서 의식적으로 무의식적으로 수행하는 모든 프로세스가 사람의 실수를 증가시키고 있습니다.

우리는 생각하는 대로 행동하는 경향이 있고 우리의 생각은 어떤 규칙에 의해 형성됩니다.

버전관리 시스템, 빌드 시스템, 코딩 규칙, 자동화된 테스트와 같은 고도로 정제된 프로세스가 없는 개발자 개인의 역량에 의존하는 프로세스를 가진 조직에서는 결함이 더 많이 발생할 수 밖에 없습니다.

대부분의 결함은 프로세스에 기인한 것이므로 결함의 원인을 개발자나 다른 사람의 문제로 인식하게 된다면 그것은 결함의 원인을 발견하기 쉽도록 옮겨놓은 것일 뿐 결함의 근본원인을 찾아내는 방법은 아닙니다.

그리고 결함을 개인의 문제로 다루게 된다면 결함을 발견하고 해결하는데 조직의 협력이 이루어질 가능성도 거의 없습니다.

결함의 근본원인을 찾아내는 방법은 전체 개발 조직이 문제를 찾는데 협력하도록 노력해야 하는 것입니다. 왜냐하면 결함은 개발 프로세스 전반에 걸쳐 관련된 모든 사람들에게서 발생할 수 있기 때문입니다.

결론은 아래와 같습니다.

1. 결함을 개인의 문제로 다루지 않는다. 결함을 조직의 관점에서 바라보고 결함을 줄이기 위해 조직원 전체가 협력할 수 있는 프로세스를 구축한다.

2. 결함으로 개인의 성과를 절대 측정하지 않는다. 사람은 규칙에 따라 생각하고 행동합니다. 결함발생율이나 결함발견율과 같은 성과 지표는 핵심적인 사항을 놓치게 만듭니다.
결함발생율로 개발자를 평가하게 된다면 개발자는 결함 발생의 원인에 대한 책임을 회피하기 위해 행동할 것입니다.
결함발견율로 테스터를 평가하게 된다면 테스터는 발견하기 어렵고 심각한 결함보다 발견하기 쉬운 결함만을 찾기 위해 애쓰게 될 것입니다.
결함을 조직의 성과로 측정하고 개인의 성과지표로 절대 사용해서는 안됩니다.

3. 결함을 줄이기 위해서는 조직 전체가 협력할 수 있는 프로세스를 구축합니다. 결함에 대한 정보를 공유하고 언제 어디서든 누구나 접근 할 수 있도록 프로세스를 구축할 필요가 있습니다.

우리는 많은 경우 잘못된 규칙에 따라 행동하는 경우가 많습니다. 일부에서는 이러한 잘못된 규칙을 맹신하는 사람들 때문에 변화를 일으키지 못하는 경우도 많습니다.

더 좋은 소프트웨어를 개발하기 위해 잘못된 규칙을 찾고 규칙을 바꾸기 위한 노력을 게을리 하지 말아야 할 것입니다.