솔직히 나는 대학교에서 품질공학과 관련된 강의를 들어본적도 없다.
어쩌다 보니 테스트를 시작했고 테스트를 하다 보니 욕심이 생겼고 필요에 의해 띄엄 띄엄 품질에 대한 자료를 찾아가며 공부를 하고 있다.
그러다 보니 품질이라는 것에 대해 내가 오해하고 있는 부분이 있을 수도 있고 품질공학을 전공한 사람의 입장에서 본다면 잘못된 내용이 있을 수도 있다.
아래 내용은 다분히 내 개인적인 의견이고, 이 의견에 대한 조언은 댓글이나 트랙백으로 주시면 대단히 고맙겠습니다.
품질관리 기법은 굉장히 많은 기법이 알려져 있습니다. 이러한 품질관리 기법들을 연대순으로 주요한 기법들만 나열해 본다면 아래와 같은 기법들을 제시해 볼 수 있습니다.
1. 1798년 휘트니의 표준화 - 호환성의 원리
2. 1924년 벨연구소의 통계적 품질 관리(SQC)
3. 1960년 GE 사 파이겐바움의 TQC
4. 1962년 이시가와의 품질관리 분임조
5. 1962년 마틴 사의 ZD 운동
6. 1969년 일본전장 사의 TPM
7. 1972년 디즈니 사의 고객만족
8. 1987년 모토롤라 사의 6시그마
이전에도 얘기한 적 있지만 이러한 수많은 기법들 중 어떤 기법을 선택할 것인가 또는 어떤 순서로 도입할 것인가 하는 문제의 해답을 얻기 위해서는 이러한 기법들의 본질에 대한 이해가 선결되어야 합니다.
그리고 그러한 본질에 대한 이해를 위해서는 해당 기법들이 탄생하게 된 배경을 이해하는 것이 꼭 필요합니다.
왜냐하면 우리가 어떤 특정한 기법들을 도입하기 위해서는 그러한 기법이 탄생하기 이전에 그러한 기법들을 도입했던 선진 기업들의 시행착오를 꼭 한번씩은 거쳐야 하기 때문입니다.
그들이 실패했던 경험을 거치지 않는다면 최신 기법에 대한 배경과 본질에 대해 심도있게 이해할 수 없기 때문입니다.
최근에 대기업부터 일반 중소기업까지 수많은 사람들과 이야기를 해보면 국내에서는 대기업과 일반 중소기업의 기술, 경영 등 전반에 걸친 격차가 매우 크다는 것을 새삼 느끼게 됩니다.
그런데 일반 중소기업들은 성과 위주로 대기업에서 수행되고 있는 최신의 기법에만 집중하는가 하면 대기업역시 자신의 하청 기업들에 그러한 기법들을 강요하는 것을 볼 수 있습니다.
하지만 이런 경우 그러한 최신 기법 이전의 과정에 대한 경험이 없는 중소기업의 경우 새로운 최신 기법이 정착되기 위해서는 수많은 시행착오와 자원의 낭비가 필연적으로 따라오게 됩니다.
그러한 과정을 무사히 잘 넘길수만 있다면 상관없지만 그러한 과정의 실패속에서 사라져가는 기업들도 많은 것은 참 안타까운 일이 아닐 수 없습니다.
전 최근에 SW Testing Camp 를 준비하면서 지난 몇년간 그나마 나아졌다던 Testing 에 대한 일선 대학부터 기업들까지의 인식이 얼마나 낮은 수준인지 다시 한번 느낄 수 있었습니다.
품질을 개선하고 더 나은 제품을 만들기 위해서 반드시 필요한 과정인 Testing 이 그냥 있으면 좋고 없어도 그만이라는 식의 대우를 받고 있는지에 대해 다시 한번 고민하게 되었고, 중소기업을 기준으로 현재 우리나라의 Testing 의 단계가 어디쯤이고 우리가 더 발전하기 위해서 어떤 단계를 수용해야 하는지에 대해 개인적으로 고민해 보았습니다.
결론적으로 우리가 취애야할 단계는 전 TQC가 아닌가 싶습니다.
휘트니가 얘기한 호환성의 원리는 ISO/IEC 9125 또는 25000 에 하나의 품질 특성으로 언급되어 있고 많은 곳에서 고민하여 적용하고 있는 것이라고 봅니다.
통계적 품질관리 역시 많은 기업에서 그 기준이나 측정 방법, 결과 등에 차이는 있지만 분명히 수행하고 있는 단계입니다.
그 기준이 자사에서 개발한 기준이건 표준에서 변형된 기준이건 우리는 소프트웨어를 개발하면서 나름의 기준에 따라 측정하고 통계적 기법을 이용해서 얻어진 정확한 계량 데이터에 의해 적절한 조치를 취하고 있습니다.
하지만 아직까지 많은 기업들이 품질과 테스팅에 대한 책임을 전적으로 테스트 조직이나 QA 조직의 일로만 여깁니다.
기획, 설계, 개발, 마케팅 등 소프트웨어 개발에 관련된 모든 이해관계자들 사이에서 품질을 체계적으로 고민하는 경우가 그다지 많지 않습니다.
TQC는 '품질은 검사에서 만드어지지 않는다. 개발 과정에서 만들어 넣어야 한다.' 또는 '품질은 설계에서 의도한 대로 공정에서 만들어 내는 것이다' 라고 얘기합니다.
바꾸어 말하면 '품질 관리는 모두의 일이며 따라서 누구의 일도 아니다.' 라는 것입니다.
즉, 품질 관리는 모든 이해 관계자와 작업자에 의해 수행되어야 한다는 의미입니다.
소비자는 시간이 지날 수록 더 높은 수준의 품질을 요구합니다. 이러한 요구를 만족하기 위해서는 더 엄격하게 제품을 테스트 하는 것만이 거의 유일한 방법입니다. 하지만 테스트가 엄격해지면 엄격해질수록 테스트에 들어가는 비용은 기하 급수적으로 늘어납니다.
테스터를 증원하고 교육하고 각종 테스트 도구들을 구매해야 하는 문제가 생깁니다.
때문에 많은 기업들은 테스트가 돈만 잡아먹는 괴물쯤으로 치부합니다. 일정 정도의 품질에 만족할 뿐 더 이상 개선할 의지를 보이지 않습니다.
이러한 경향은 소프트웨어가 출시 이후에 발생한 문제에 대해서는 유지보수 하면 그만이라는 것때문에 더욱 심화됩니다. 일반 건축물과 같은 하드웨어와 달리 많은 사람들은 소프트웨어를 재구성 하는 것이 무척 간단한 작업이라고 오해하고 있습니다.
하지만 정말 그런가요? 이러한 문제를 해결할 더 좋은 방법은 무엇이 있을까요?
전 이러한 문제에 대한 해답으로 소프트웨어를 개발하는 모든 사람이 테스트를 수행할 수 있다면 어떨까라는 생각을 합니다.
Agile 에서 얘기하는 것처럼 개발자가 일부의 테스트를 수행하고, 기획자나 설계자 역시 품질과 테스트 용이성을 염두에 두고 작업을 하는 것입니다.
저는 우리나라의 IT 산업이 발전하고 소프트웨어의 품질이 한단계 더 높아지기 위해서는 위와 같이 소프트웨어 개발에 관련된 모든 사람들이 테스트를 알아야 하고 품질을 고려해야할 필요가 있다고 생각합니다.
이러한 인식의 전환 없이 무결함 운동이나 6시그마와 같은 여타 다른 품질관리 기법들이 성공할 수는 없다고 봅니다.
여러분은 이 의견에 대해 어떻게 생각하시나요? 이러한 인식의 변화를 일으킬 수 있는 좋은 방법은 무엇이 있을까요?
어쩌다 보니 테스트를 시작했고 테스트를 하다 보니 욕심이 생겼고 필요에 의해 띄엄 띄엄 품질에 대한 자료를 찾아가며 공부를 하고 있다.
그러다 보니 품질이라는 것에 대해 내가 오해하고 있는 부분이 있을 수도 있고 품질공학을 전공한 사람의 입장에서 본다면 잘못된 내용이 있을 수도 있다.
아래 내용은 다분히 내 개인적인 의견이고, 이 의견에 대한 조언은 댓글이나 트랙백으로 주시면 대단히 고맙겠습니다.
품질관리 기법은 굉장히 많은 기법이 알려져 있습니다. 이러한 품질관리 기법들을 연대순으로 주요한 기법들만 나열해 본다면 아래와 같은 기법들을 제시해 볼 수 있습니다.
1. 1798년 휘트니의 표준화 - 호환성의 원리
2. 1924년 벨연구소의 통계적 품질 관리(SQC)
3. 1960년 GE 사 파이겐바움의 TQC
4. 1962년 이시가와의 품질관리 분임조
5. 1962년 마틴 사의 ZD 운동
6. 1969년 일본전장 사의 TPM
7. 1972년 디즈니 사의 고객만족
8. 1987년 모토롤라 사의 6시그마
이전에도 얘기한 적 있지만 이러한 수많은 기법들 중 어떤 기법을 선택할 것인가 또는 어떤 순서로 도입할 것인가 하는 문제의 해답을 얻기 위해서는 이러한 기법들의 본질에 대한 이해가 선결되어야 합니다.
그리고 그러한 본질에 대한 이해를 위해서는 해당 기법들이 탄생하게 된 배경을 이해하는 것이 꼭 필요합니다.
왜냐하면 우리가 어떤 특정한 기법들을 도입하기 위해서는 그러한 기법이 탄생하기 이전에 그러한 기법들을 도입했던 선진 기업들의 시행착오를 꼭 한번씩은 거쳐야 하기 때문입니다.
그들이 실패했던 경험을 거치지 않는다면 최신 기법에 대한 배경과 본질에 대해 심도있게 이해할 수 없기 때문입니다.
최근에 대기업부터 일반 중소기업까지 수많은 사람들과 이야기를 해보면 국내에서는 대기업과 일반 중소기업의 기술, 경영 등 전반에 걸친 격차가 매우 크다는 것을 새삼 느끼게 됩니다.
그런데 일반 중소기업들은 성과 위주로 대기업에서 수행되고 있는 최신의 기법에만 집중하는가 하면 대기업역시 자신의 하청 기업들에 그러한 기법들을 강요하는 것을 볼 수 있습니다.
하지만 이런 경우 그러한 최신 기법 이전의 과정에 대한 경험이 없는 중소기업의 경우 새로운 최신 기법이 정착되기 위해서는 수많은 시행착오와 자원의 낭비가 필연적으로 따라오게 됩니다.
그러한 과정을 무사히 잘 넘길수만 있다면 상관없지만 그러한 과정의 실패속에서 사라져가는 기업들도 많은 것은 참 안타까운 일이 아닐 수 없습니다.
전 최근에 SW Testing Camp 를 준비하면서 지난 몇년간 그나마 나아졌다던 Testing 에 대한 일선 대학부터 기업들까지의 인식이 얼마나 낮은 수준인지 다시 한번 느낄 수 있었습니다.
품질을 개선하고 더 나은 제품을 만들기 위해서 반드시 필요한 과정인 Testing 이 그냥 있으면 좋고 없어도 그만이라는 식의 대우를 받고 있는지에 대해 다시 한번 고민하게 되었고, 중소기업을 기준으로 현재 우리나라의 Testing 의 단계가 어디쯤이고 우리가 더 발전하기 위해서 어떤 단계를 수용해야 하는지에 대해 개인적으로 고민해 보았습니다.
결론적으로 우리가 취애야할 단계는 전 TQC가 아닌가 싶습니다.
휘트니가 얘기한 호환성의 원리는 ISO/IEC 9125 또는 25000 에 하나의 품질 특성으로 언급되어 있고 많은 곳에서 고민하여 적용하고 있는 것이라고 봅니다.
통계적 품질관리 역시 많은 기업에서 그 기준이나 측정 방법, 결과 등에 차이는 있지만 분명히 수행하고 있는 단계입니다.
그 기준이 자사에서 개발한 기준이건 표준에서 변형된 기준이건 우리는 소프트웨어를 개발하면서 나름의 기준에 따라 측정하고 통계적 기법을 이용해서 얻어진 정확한 계량 데이터에 의해 적절한 조치를 취하고 있습니다.
하지만 아직까지 많은 기업들이 품질과 테스팅에 대한 책임을 전적으로 테스트 조직이나 QA 조직의 일로만 여깁니다.
기획, 설계, 개발, 마케팅 등 소프트웨어 개발에 관련된 모든 이해관계자들 사이에서 품질을 체계적으로 고민하는 경우가 그다지 많지 않습니다.
TQC는 '품질은 검사에서 만드어지지 않는다. 개발 과정에서 만들어 넣어야 한다.' 또는 '품질은 설계에서 의도한 대로 공정에서 만들어 내는 것이다' 라고 얘기합니다.
바꾸어 말하면 '품질 관리는 모두의 일이며 따라서 누구의 일도 아니다.' 라는 것입니다.
즉, 품질 관리는 모든 이해 관계자와 작업자에 의해 수행되어야 한다는 의미입니다.
소비자는 시간이 지날 수록 더 높은 수준의 품질을 요구합니다. 이러한 요구를 만족하기 위해서는 더 엄격하게 제품을 테스트 하는 것만이 거의 유일한 방법입니다. 하지만 테스트가 엄격해지면 엄격해질수록 테스트에 들어가는 비용은 기하 급수적으로 늘어납니다.
테스터를 증원하고 교육하고 각종 테스트 도구들을 구매해야 하는 문제가 생깁니다.
때문에 많은 기업들은 테스트가 돈만 잡아먹는 괴물쯤으로 치부합니다. 일정 정도의 품질에 만족할 뿐 더 이상 개선할 의지를 보이지 않습니다.
이러한 경향은 소프트웨어가 출시 이후에 발생한 문제에 대해서는 유지보수 하면 그만이라는 것때문에 더욱 심화됩니다. 일반 건축물과 같은 하드웨어와 달리 많은 사람들은 소프트웨어를 재구성 하는 것이 무척 간단한 작업이라고 오해하고 있습니다.
하지만 정말 그런가요? 이러한 문제를 해결할 더 좋은 방법은 무엇이 있을까요?
전 이러한 문제에 대한 해답으로 소프트웨어를 개발하는 모든 사람이 테스트를 수행할 수 있다면 어떨까라는 생각을 합니다.
Agile 에서 얘기하는 것처럼 개발자가 일부의 테스트를 수행하고, 기획자나 설계자 역시 품질과 테스트 용이성을 염두에 두고 작업을 하는 것입니다.
저는 우리나라의 IT 산업이 발전하고 소프트웨어의 품질이 한단계 더 높아지기 위해서는 위와 같이 소프트웨어 개발에 관련된 모든 사람들이 테스트를 알아야 하고 품질을 고려해야할 필요가 있다고 생각합니다.
이러한 인식의 전환 없이 무결함 운동이나 6시그마와 같은 여타 다른 품질관리 기법들이 성공할 수는 없다고 봅니다.
여러분은 이 의견에 대해 어떻게 생각하시나요? 이러한 인식의 변화를 일으킬 수 있는 좋은 방법은 무엇이 있을까요?
댓글
댓글 쓰기