2012.02.13

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

Matthew Heusser | CIO

마이클 파간은 1970년대 IBM에서 근무하던 때, 소프트웨어 인스펙션이 방대한 생산성 향상을 가져온다는 사실을 발견했다. 그러나 35년이 지난 현재, 상황은 많이 달라졌고 다음과 같은 질문들이 제기되고 있다. 소프트웨어 개발 역동이 그때와 같은가? 파간의 발견이 오늘날의 애자일 개발 및 익스트림 프로그래밍에 여전히 유효한가? 만약 그렇다면, 오늘날 조직들이 이와 관련해 해야 하는 작업은 무엇인가?

정형 인스펙션(Formal Inspection)이 태동한 시대에 대해 살펴보자. : 애자일 매니페스토(Agile Manifesto)의 공동 창시자 로버트 C. 마틴은 저서 “더 클린 코더(The Clean Coder)”에서 ‘릴투릴’ 구동방식의 테이프 드라이브는 ‘럭셔리한’ 것이었고 대부분의 사람들이 여전히 펀칭 카드를 사용했다는 점을 언급했다.

이러한 테이프는 한 방향으로만 구동될 수 있었다. 그래서 읽기 오류가 발생한 경우, 테이프 구동을 저장하고 다시 읽을 수 있는 방법이 없었다. 현재 진행 중인 곳에서 멈춰 구동 지점으로 테이프를 다시 돌린 후 실행해야만 했다. 이러한 일은 하루에도 두 세 번 일어났다. 쓰기 오류도 매우 흔했고, 드라이브는 그것을 탐지할 수 있는 수단을 제공하지 않았다. 그래서 우리는 테이프를 쌍으로 쓰고 완료 후 확인을 해야만 했다. 만약 두 테이프 중 하나에 이상이 있으면 바로 복사본을 만들었다. 흔한 경우는 아니지만 두 테이프 모두에 이상이 있는 경우 우리는 이러한 모든 과정을 되풀이 해야만 했다.


우리는 한 화면상에서 테이프를 편집했다… 우리는 테이프에서 “페이지”를 읽고 내용물를 수정한 후 그 페이지를 작성하고 다음 페이지를 읽어야만 했다. 일반적으로 한 페이지에는 50라인의 코드가 있었다. 앞에 나올 페이지를 살펴보기 위해 테이프를 앞으로 돌리거나 이전에 수정한 페이지를 보기 위해 테이프를 뒤로 돌릴 수 없었다. 그래서 우리는 리스트를 사용했다. 실제로, 우리는 우리가 수정하고자 하는 모든 것을 표시한 리스트를 작성한 후 그러한 표시에 따라 파일을 수정했다. 아무도 터미널에서 코드를 작성하거나 수정하지 않았다. 그것은 자살 행위나 마찬가지였다. 필요한 모든 파일을 수정한 후, 우리는 방영 가능한 테이프를 만들기 위해 최종본(마스터 테잎)으로 편집해갔다. 이것이 우리가 컴파일과 테스트를 수행하기 위해 사용하던 테이프다.

이러한 환경에서 컴파일 오류가 발생한 결과는 어땠을까? 오류가 일어난 테이프를 찾아, 해당 지점을 설정한 후 해당 페이지를 수정하고 테이프를 다시 저장한 다음 머신에서 실행해야만 하는 것이다. 그리고 다음 컴파일 오류가 발견되면? 이 과정을 또 다시 반복해야만 한다. 열 개의 컴파일 오류가 발생하면 몇 일간 그것에 매달려야만 했다. 만약 컴파일에 하룻밤이 걸리는 펀칭 카드를 사용한다면? 아마도 몇 주가 걸리게 될 작업이었다.

그러한 환경에서는 컴파일 단계 전에 종이 상에 코드를 인쇄한 후 검토하거나 작성하기 전에 손으로 직접 코드를 작성한 후 검토하는 것이 좋은 방법이다.

그러나 최근에는 코드를 검토하기 전 컴파일 하고 만약 테스트 지향 개발을 하고 있다면 유닛 테스트의 모든 단계를 건너 뛰기 쉽다. 그러한 상황에서 자체 인스펙션의 비용/효율은 매우 다를 것이다.




2012.02.13

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

Matthew Heusser | CIO

마이클 파간은 1970년대 IBM에서 근무하던 때, 소프트웨어 인스펙션이 방대한 생산성 향상을 가져온다는 사실을 발견했다. 그러나 35년이 지난 현재, 상황은 많이 달라졌고 다음과 같은 질문들이 제기되고 있다. 소프트웨어 개발 역동이 그때와 같은가? 파간의 발견이 오늘날의 애자일 개발 및 익스트림 프로그래밍에 여전히 유효한가? 만약 그렇다면, 오늘날 조직들이 이와 관련해 해야 하는 작업은 무엇인가?

정형 인스펙션(Formal Inspection)이 태동한 시대에 대해 살펴보자. : 애자일 매니페스토(Agile Manifesto)의 공동 창시자 로버트 C. 마틴은 저서 “더 클린 코더(The Clean Coder)”에서 ‘릴투릴’ 구동방식의 테이프 드라이브는 ‘럭셔리한’ 것이었고 대부분의 사람들이 여전히 펀칭 카드를 사용했다는 점을 언급했다.

이러한 테이프는 한 방향으로만 구동될 수 있었다. 그래서 읽기 오류가 발생한 경우, 테이프 구동을 저장하고 다시 읽을 수 있는 방법이 없었다. 현재 진행 중인 곳에서 멈춰 구동 지점으로 테이프를 다시 돌린 후 실행해야만 했다. 이러한 일은 하루에도 두 세 번 일어났다. 쓰기 오류도 매우 흔했고, 드라이브는 그것을 탐지할 수 있는 수단을 제공하지 않았다. 그래서 우리는 테이프를 쌍으로 쓰고 완료 후 확인을 해야만 했다. 만약 두 테이프 중 하나에 이상이 있으면 바로 복사본을 만들었다. 흔한 경우는 아니지만 두 테이프 모두에 이상이 있는 경우 우리는 이러한 모든 과정을 되풀이 해야만 했다.


우리는 한 화면상에서 테이프를 편집했다… 우리는 테이프에서 “페이지”를 읽고 내용물를 수정한 후 그 페이지를 작성하고 다음 페이지를 읽어야만 했다. 일반적으로 한 페이지에는 50라인의 코드가 있었다. 앞에 나올 페이지를 살펴보기 위해 테이프를 앞으로 돌리거나 이전에 수정한 페이지를 보기 위해 테이프를 뒤로 돌릴 수 없었다. 그래서 우리는 리스트를 사용했다. 실제로, 우리는 우리가 수정하고자 하는 모든 것을 표시한 리스트를 작성한 후 그러한 표시에 따라 파일을 수정했다. 아무도 터미널에서 코드를 작성하거나 수정하지 않았다. 그것은 자살 행위나 마찬가지였다. 필요한 모든 파일을 수정한 후, 우리는 방영 가능한 테이프를 만들기 위해 최종본(마스터 테잎)으로 편집해갔다. 이것이 우리가 컴파일과 테스트를 수행하기 위해 사용하던 테이프다.

이러한 환경에서 컴파일 오류가 발생한 결과는 어땠을까? 오류가 일어난 테이프를 찾아, 해당 지점을 설정한 후 해당 페이지를 수정하고 테이프를 다시 저장한 다음 머신에서 실행해야만 하는 것이다. 그리고 다음 컴파일 오류가 발견되면? 이 과정을 또 다시 반복해야만 한다. 열 개의 컴파일 오류가 발생하면 몇 일간 그것에 매달려야만 했다. 만약 컴파일에 하룻밤이 걸리는 펀칭 카드를 사용한다면? 아마도 몇 주가 걸리게 될 작업이었다.

그러한 환경에서는 컴파일 단계 전에 종이 상에 코드를 인쇄한 후 검토하거나 작성하기 전에 손으로 직접 코드를 작성한 후 검토하는 것이 좋은 방법이다.

그러나 최근에는 코드를 검토하기 전 컴파일 하고 만약 테스트 지향 개발을 하고 있다면 유닛 테스트의 모든 단계를 건너 뛰기 쉽다. 그러한 상황에서 자체 인스펙션의 비용/효율은 매우 다를 것이다.


X