Offcanvas

비즈니스|경제 / 애플리케이션

기고 | 소프트웨어 개발, 테스팅, 그리고 인스펙션에 대한 재고

2012.02.13 Matthew Heusser   |  CIO


실제에서의 피어 리뷰(Peer Review)
미시간주 그랜드래피즈에 거주하고 있는 테크놀로지스트 겸 소프트웨어 테스터 피터 월렌은 지난 15년 간 종종 정형 인스펙션을 사용해 오고 있다. 그는 “인스펙션은 사용해야 할 때가 있다”라고 표현했다. 하지만 그는 “인스펙션 프로그램을 사용할 때마다, 몇몇 사람들이 머리를 맞대고 살펴보면 버그, 분명한 버그, 알아차릴 수 있는 버그가 코드에 있다는 것을 알게 되는 좋은 효과가 있었다. 그 정도 규모의 조직을 운영하고 있다면, 인스펙션을 사용하는 것이 좋다”라고 덧붙였다.

하지만 다시 한 번 그는 너무 서두르지는 말라며 “이러한 프로그램을 구현하기 시작한 1~2년 만에 나는 인스펙션의 필요성이 없다는 것을 깨닫게 되었다. 팀원들은 인스펙션을 수행하기 전에 명백한 종류의 코드 오류가 있다는 것을 발견했다. 인스펙션과 설계의 의미는 무엇이 설계되었는가가 아닌 무엇을 설계할 것인가 이다. 검토는 사실 이후에 결과를 검토하는 것이 아닌 앞을 내다보는 것이 된다”라고 말했다.

다른 말로 하면, 그는 “검토는 멋진 방법은 아니라고 할지라도 어떤 특정한 종류의 문제를 해결할 수 있다. 그러한 문제가 없다면 혹은 그러한 문제가 해결된다면, 검토도 수행할 필요가 없다”고 결론지었다.

앞으로 해야 할 일은?
정형 인스펙션은 컴파일에 수 시간이 걸리고 애플리케이션에 GUI가 없으며 “배치 모드”로 수행되던 시기의 소프트웨어 개발에서 탄생했다. 만약 인스펙션이 여러 사람이 같은 공간에 모여 수행될 필요가 있는 정형화 된 단계라면, 그것은 프로젝트 수행 시간 증가와 회의를 수행해야 하는 원인이 된다. 위의 연구 결과 이러한 시간 추가는 이익을 능가할 수 있지만, 코드 작성 직후 또는 짝 프로그래밍 진행 시 비공식적으로 인스펙션을 수행한다면 유사한 효과를 거둘 수 있을 것이다.

인스펙션 프로그래밍 작성에 관심이 있다면, 첫 번째 질문은 인스펙션을 통해 어떤 문제가 해결되어야 하고 자신의 팀에 그러한 문제가 있는가를 살펴보는 것이다. 월렌이 지적한 바와 같이, 인스펙션을 통해 발견되고 줄어들 수 있는 비즈니스 로직 상 팀에 많은 분명한 문제가 있다면, 인스펙션 프로세스를 도입함으로써 효과를 볼 수 있을 것이다. 있어야 하지만 있지 않은 기능 혹은 사용자 인터페이스의 복잡한 조합 등 만약 다른 곳에 문제가 있는 것이라면 다른 수단을 도입하는 것이 효과가 있을 것이다.  

 “단지” 오류를 발견하는 것 이외에도, 코드베이스 지식 공유, 테스터와 애널리스트의 개발물 이해, 비-프로그래머가 포함된 경우 코드가 과도하게 복잡해지는 것을 방지하는 등 인스펙션과 검토를 수행하는 다른 이유가 있다. 이러한 다른 이익들은 인스펙션을 수행하는 방식에 영향을 미치게 되고, 이것과 관련해서는 다음에 다시 다루도록 하겠다.

편집자 주 : 매트 허이서르는 본 기사의 검토를 수행해 준 라네테 크리머, 앨런 페이지, 벤 시모, 그리고 도로시 그라함에 감사의 말을 전한다. 위 그래프는 스티브 맥코넬의 저서 “소프트웨어 프로젝트 생존 가이드(Software Project Survival Guide)”를 허락 하에 수정한 것이다. ciokr@idg.co.kr

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.