소비자의 품질 요구가 높아졌고 소프트웨어의 복잡도가 증가해서, QA가 어느때보다 더 중요해졌다. 왠만한 조직에는 다 QA 부서가 있고 그들의 목소리도 과거보다 커졌지만 여전히 품질은 개판인 경우가 많다. 물론 독보적인 품질의 제품을 출시하는 회사들도 분명히 있다. 이 차이는 어디서 오는걸까?
여러가지 원인이 있고 조직마다의 특수성도 있겠지만, 나는 QA를 All or Nothing으로 보느냐 아니면 부분으로 떼어 놓고 보느냐 하는 차이에 있다고 생각한다. 보통 QA 과정은 적용에 차이가 있겠지만, 다음과 비슷하다.
1. 테스트
2. 결과 리포트
3. 오류 수정
테스트 과정은 기능별로 자잘하게 잘려서 수천에서 수만개가 넘는 경우도 있다. 그리고 그 중에서 분명히 오류가 발견된다. 1000개중 1개의 오류가 발견됐다고 하자. 그리고 그 한 개의 오류를 수정했다. 그 다음 과정은 뭘까?
만약에 고친 오류 1개만 테스트하고 나머지 999개는 그냥 넘긴다면 그 조직은 탁월한 품질의 소프트웨어를 출시하기보다는 똥을 싸지를 확률이 높다. QA는 All or Nothing의 세계다. 999개 중에 단 1개라도 통과하지 못한다면 그건 전체의 실패이며, 전체가 실패했으니까 1개를 수정한 후에 다시 전체를 테스트하는게 맞다.
그러나, 이러한 전체의 실패 정책을 계속 고수하는 건 쉬운 일이 아니다. 특히나 외부의 압박이 심한 경우에는 더욱 더 그러하다. 게임 오베를 하면서 치명적 버그가 발견되면 그것만 고쳐 패치하고 싶은 마음이 안들면 그게 사람이겠는가? 누구나 그런 생각을 하지만 원칙이 아니라 기억을 더듬어 봐도 그런 경우는 언제나 더 큰 문제를 발생시켰다. 하나 패치했더니 두 개의 버그가 새로 생기는 그 아찔한 경험 말이다. 단 1초도 더 방치할 수 없는 치명적인 문제라면 코드를 최소한으로 건드려 (데이터만 수정해서 그 기능을 무력화 시킬 수 있다면 최고) 그 기능을 차단해서 일단 패치하고, 제대로된 과정을 거쳐 패치하는게 맞다.
이렇게 급한 상황에서 원칙을 지키려면 QA 부서는 절대로 타협을 해서는 안되고, 구성원 모두가 QA 부서를 존중해줘야 한다. 그렇지않다면 위에서 말한데로 똥만 싸지르다가 망하게 된다.
나로호 발사 연기가 사소한 소프트웨어 결함때문었다고 한다. 어제 9시 뉴스를 보니 사소한 소프트웨어 결함이고 이를 고치는데 3일정도가 걸려서 순식간에 다시 발사를 할 수 있다고 한다. 상식적으로 생각해도 우주선 발사 프로세스가 그리 간단할리가 없고 몇 백개의 테스트만 거치면 모두 통과하는 단순한 과정은 절대 아닐 것이라고 믿고 싶다.
첫 번째 우주 발사체 발사에 대한 주변의 압박은 매우 심할 것이다. 5000억 이상이 소요됐고 이미 7년이 걸렸다. 며칠 더 걸리는 것은 문제도 아니다. 압박에 굴복해 성급하고 축소된 QA로 발사를 단행해 진짜 큰 문제를 만들지 않기를 간절히 기원한다.
여러가지 원인이 있고 조직마다의 특수성도 있겠지만, 나는 QA를 All or Nothing으로 보느냐 아니면 부분으로 떼어 놓고 보느냐 하는 차이에 있다고 생각한다. 보통 QA 과정은 적용에 차이가 있겠지만, 다음과 비슷하다.
1. 테스트
2. 결과 리포트
3. 오류 수정
테스트 과정은 기능별로 자잘하게 잘려서 수천에서 수만개가 넘는 경우도 있다. 그리고 그 중에서 분명히 오류가 발견된다. 1000개중 1개의 오류가 발견됐다고 하자. 그리고 그 한 개의 오류를 수정했다. 그 다음 과정은 뭘까?
만약에 고친 오류 1개만 테스트하고 나머지 999개는 그냥 넘긴다면 그 조직은 탁월한 품질의 소프트웨어를 출시하기보다는 똥을 싸지를 확률이 높다. QA는 All or Nothing의 세계다. 999개 중에 단 1개라도 통과하지 못한다면 그건 전체의 실패이며, 전체가 실패했으니까 1개를 수정한 후에 다시 전체를 테스트하는게 맞다.
그러나, 이러한 전체의 실패 정책을 계속 고수하는 건 쉬운 일이 아니다. 특히나 외부의 압박이 심한 경우에는 더욱 더 그러하다. 게임 오베를 하면서 치명적 버그가 발견되면 그것만 고쳐 패치하고 싶은 마음이 안들면 그게 사람이겠는가? 누구나 그런 생각을 하지만 원칙이 아니라 기억을 더듬어 봐도 그런 경우는 언제나 더 큰 문제를 발생시켰다. 하나 패치했더니 두 개의 버그가 새로 생기는 그 아찔한 경험 말이다. 단 1초도 더 방치할 수 없는 치명적인 문제라면 코드를 최소한으로 건드려 (데이터만 수정해서 그 기능을 무력화 시킬 수 있다면 최고) 그 기능을 차단해서 일단 패치하고, 제대로된 과정을 거쳐 패치하는게 맞다.
이렇게 급한 상황에서 원칙을 지키려면 QA 부서는 절대로 타협을 해서는 안되고, 구성원 모두가 QA 부서를 존중해줘야 한다. 그렇지않다면 위에서 말한데로 똥만 싸지르다가 망하게 된다.
나로호 발사 연기가 사소한 소프트웨어 결함때문었다고 한다. 어제 9시 뉴스를 보니 사소한 소프트웨어 결함이고 이를 고치는데 3일정도가 걸려서 순식간에 다시 발사를 할 수 있다고 한다. 상식적으로 생각해도 우주선 발사 프로세스가 그리 간단할리가 없고 몇 백개의 테스트만 거치면 모두 통과하는 단순한 과정은 절대 아닐 것이라고 믿고 싶다.
첫 번째 우주 발사체 발사에 대한 주변의 압박은 매우 심할 것이다. 5000억 이상이 소요됐고 이미 7년이 걸렸다. 며칠 더 걸리는 것은 문제도 아니다. 압박에 굴복해 성급하고 축소된 QA로 발사를 단행해 진짜 큰 문제를 만들지 않기를 간절히 기원한다.
