Yagur의 Juggling

작성자: yagur  Rev : 1

 품질 분석 그리고 개선(Quality analysis and improvement)

 얼마전에 케이블 방송에서 가장 날카로운 칼에 대한 다큐멘터리를 방영하는것을 볼수 잇었다. 제목은 기억 나지 않았지만 가장 날카로운 레이저 블레이드를 파는 회사가 등장했다. 거기서 가장 인상깊게 본 장면은 자신들의 제품의 품질을 검증하기 위한 테스트가 구축되어있고 그 테스트를 통해 제품을 개선해 나가 지금의 제품을 생산해 내고 있었다는 점이다. 아래의 영상과 비슷한 실험을 통해 칼날의 품질을 테스트 하였다.

 그들은 칼날 끝에 미세한 홈을파고 다듬어 날카로움을 더했고, 열처리 후에 특별한 처리과정을 통해 내구도를 높혔다. 장인들의 제품은 고사처럼 비법전수로 이루어지는것 보다는, 숱한 테스트와 개선을 통해 이루어진다는 것을 알수 있었다. 지금 작성하는 프로그램은 어떠한가, 테스트와 개선을 어떤식으로 이루어 내는지 고민하는것은 매우 가치있는 일이 될것이다. 어떻게 프로파일링(profiling) 할것인지, 어떤 프레임워크나 도구로 테스트를 진행할것인지말이다. 소프트웨어 개발에는 TDD(Test Driven Development)나 TAD(Test After Development)와 같은 방법론을 찾을수있다. TDD같은 경우는 최근 트렌드인 애자일 개발과도 맞물려있다.

 부분 품질(Partial Quality)

  부분의 오류가 전체에 오류를 초래하는 경우는 프로그램에서 매우 친숙하게 느껴질정도로 자주 격는 일이다. 하지만 작은 오류는 찾아내기 쉽지 않다. 한 부분의 오류가 끼치는 영향력은 어떠할까?  비행기의 엔진에 여러개의 날을 가진 팬이 회전하는것을 볼수 있다. 이 팬의 날중 하나가 떨어진다면 비행기 탑승객은 어떤 상황을 격게 될까? 실제로 한해에도 수차례 이런 상황이 벌어진다고 한다.
 미션 크리티컬한 엔진 개발은 무엇으로 검증되는지 궁금할것이다.
 다음 동영상은 디스커버리에서 방영한 A380에 탑제된 롤스로이스의 트렌트 900 테스트 장면이다. 이 테스트는 엔진의 팬의 구성요소중 하나인 날이 동작중 분리되는 사태에 대한 안전도 테스트이다.


 왜 비행기들이 롤스로이스 엔진을 탑제하는지 알수 있는 다큐이다. 이 테스트를 위해 개발자이 200야드 떨어진 장소에서 테스트 광경을 주시한다. 이 테스트 자체가 트렌트900 개발의 중요한 마일스톤이다. 이들이 보통 이 테스트를 극비에 붙인다고 하는데 왜 공개했을까? 중요한 검증이며 신뢰도를 이보다 쉽게 줄순 없기때문이다.
 비행기는 소프트웨어 시스템이고 트렌트900은 시스템을 이루는 컴포넌트이며 트렌트900 팬의 날은 클래스라고 볼수도 있다. 소프트웨어가 미션 크리티컬하지 않다고 생각한다면 테스트는 필요 없지만, 컴퓨터는 인간이 작성한 오류에 관하여 너무 정직하다. 무엇보다 미션 크리티컬한 작업이 소프트웨어 작성이다.
 검증과 신뢰를 줄수 있는 방법(test)을 외면하지 말고, 적극적이 된다면 품질은 눈에 보이게 되며, 눈에 보이는 품질은 개발자에게 결과물에 대한 신뢰와 자신감을 심어줄수있다. 그 작은 예중 하나가 TDD의 녹색 막대이다.


 품질 검증(Quality verify)

 무엇이 완벽하게 검증을 할수는 없겠지만, 이 검증 행위는 신뢰도에 큰 도움이 되는것만은 분명하다. 만약 트렌트 900이 비와 황사에 약하다면 비행기는 롤스로이스의 제품을 탑제할수 없을것이다. 부분 품질에 소개되었던 안전성 테스트는 부분 오류와 그 파장에 대한 테스트 였다면,  아래의 두 테스트는 외부 조건에 대한 테스트이다. 특정 상황에 대한 제품의 품질을 검증하여 보장해주는 것이다.



 비에 오동작할 걱정은 물을 들이 부어서 검증시켜주고, 황사에 오동작할 걱정은 모래를 들이 부어 검증해준다. 이 영상들을 보니 다음 여행때는 A380이 타고 싶어지지 않는가? 최종 사용자 입장이나 개발자 입장에서도 테스트로 검증된 유닛들은 굉장한 신뢰와 매력을 지니고 있다.
 개발중인 소프트웨어 구성요소들이 외부 조건에 어떤반응을 보일지 테스트를 통해 검증하는 것은 문제가 생겼을때 혼란을 줄여줄 커다란 재산중 하나이다. 메모리가 부족할때, 디스크가 꽉찼을때, 네트워크 대역폭이 부족할때 어떤 결과를 얻기 원하는가. 지나친 테스트는 생산성을 저해할수도 있다, 하지만 검증된것을 대부분의 사람들은 좋아한다. 이름 없는 데이터 베이스와 Oracle을 사용할수 있다면 어떤  것을 사용하겠는가? 아마 열중 아홉은 오라클을 택할것이고 그 이유로 안정성과 검증된 제품이라는 말을 할것이다. 검증은 소프트웨어의 건강을 유지시켜줄것이다.