[2부 2번 수필] 버그, 오류, 결함

SC2.0을 읽다보면 이런저런 '잡스러운' 생각을 많이 하게 됩니다. 2장 2번 수필을 읽다가 메모해 둔 질문 중 하나입니다.

버그(bug)와 오류(error)와 결함(defect)의 차이는 무엇일까요?

대충 많이 쓰는 말이고 대충 느낌으로 이해하는 단어이고, 많이 섞어쓰는 뜻이기도 합니다. 하지만 정확히 구분해서 정의한다면?

여러분들이 재밌게 여길 질문이다 싶어서 올려봅니다. 답은 안올려도 되겠죠? 찾고 생각하는 과정이 더 재밌으니까요.

"소프트웨어 컨플릭트 2.0" 역자 이해영 올림.

@ In Search of Stupidity 2nd Ed. 번역을 한창 진행 중입니다. 너무너무 재미있어서 빨리 읽혀드리고 싶네요.

[2부 5번 수필] 소프트웨어 품질과 소프트웨어 유지보수 사이의 관계

로버트 L. 글래스 큰 형님에 따르면 소프트웨어 품질이 우수하기 위한 속성이 일곱 가지있다고 한다.

• 신뢰성(reliability)
• 효율성(efficiency)
• 인간공학(human engineering)
• 이해 용이성(understandability)
• 수정 용이성(modifiability)
• 테스트 용이성(testability)
• 이식성(portability)

여기서 제시한 일곱 가지 속성 중에 소프트웨어 유지 보수와 관련이 있는 항목이 대부분이다. 이해 용이성, 수정 용이성은 당연히 유지 보수와 직접적인 관련이 있는 항목이며, 소프트웨어가 실패하지 않고 제 기능을 수행해야 한다는 신뢰성과 소프트웨어가 시간/공간 자원을 최소로 사용해서 동작해야 한다는 효율성, 소프트웨어 테스트가 쉬워야 한다는 테스트 용이성, 소프트웨어를 쉽게 사용하도록 만들어주는 능력인 인간 공학, 다른 컴퓨터나 환경에서 소프트웨어를 사용하게끔 만드는 이식성 모두 유지 보수 담당자가 머리를 싸매는 항목이다.

자, 그렇다면 소프트웨어 품질을 높이려면 가장 좋은 방법은 무엇일까? 상기 일곱 가지 항목을 생각해보면 대답이 바로 나오지 않는가? 바로 '유지 보수'를 제대로하는 방법이다. 유지 보수가 3D 중의 3D로 계속 남아있으며, 애물단지로 취급되는 현 상황에서는 절대로 소프트웨어 품질을 높이지 못한다. 따라서, 소프트웨어 품질 운운하면서 유지 보수에 형편없는 인력을 투입하는 관리자를 항상 경계하기 바란다. 실제로는 소프트웨어 품질을 높이고 싶은 생각이 전혀 없음을 에둘러서 표현했을 뿐일테니까.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 3번 수필] 소프트웨어 오류 제거에 대한 실험적 관점

소프트웨어 오류를 제거하는 가장 효율적인 방법과 가장 저렴한 방법은 무엇일까? 프로젝트를 진행함에 있어 이 두 가지 질문은 항상 가슴 속에 품고 다녀야 하지만, 공론화가 되지 않는 희한한 속성이이 있다. 이미 널리 알려진 바와 같이 오류 제거에 드는 비용은 시스템 분석과 설계와 구현에 드는 비용 각각에 비해 거의 두 배가 넘든다고 한다. 그렇다면 왜 이렇게 비싼 댓가를 치루면서도 계속 소프트웨어 오류에 무관심할까?

가장 큰 이유는 소프트웨어 오류에 대한 연구가 상당히 뒤쳐저 있기 때문이다. 최신 프로그램 언어, 최신 라이브러리, 프레임워크에 대한 책이나 기사는 넘쳐나지만, 소프트웨어 오류에 대한 책을 한번 찾아보기 바란다. 책장 한 칸이면 다 채우고도 남을 정도다. 결국 '~카더라'라는 주관적인 견해가 판을 치다보니 믿을만한 정보가 부족해지고, 믿을만한 정보가 부족하다 보니 모두 자기 머리만 믿는다. 그리고... 후반부에 가서 완전히 함정에 빠진 사실을 알아차린다. T_T

로버트 L. 글래스 큰 형님은 테스트와 관련한 여러 연구를 종합해서 다음과 같은 결론을 내린다.

• 반드시 검토를 수행하여 테스트를 보완한다
• 기능적 테스트를 강조하되 구조적 테스트도 수행한다
• 설계 검토와 코드 검토를 모두 수행해야 한다

여기서 기능적 테스트는 프로그램 요구사항 명세서를 기반으로 범위를 결정한 테스트이고, 구조적 테스트는 프로그램 내부 동작 방식에 맞춰 범위를 결정한 테스트이다. 코드 검토는 소프트웨어를 실행하지 않고 정적으로 소스 코드 자체를 살펴서 오류를 찾는 방법이다.

코드 검토 과정에서 사용하는 단계적 추상화(stepwise abstraction)는 소프트웨어에서 핵심적인 하위 프로그램을 찾아 기능을 파악한 후 이들 개별 기능으로부터 소프트웨어 전체 그림을 파악하는 방법이다. 워크스루와 인스펙션은 검토 회의 전에 코드를 읽고 마음속으로 소프트웨어 논리를 따라서 테스트 케이스를 실행하는 방법이다.

흥미롭게도 코드 검토 과정에서 사용하는 방법이나 소프트웨어 설계 과정에서 사용하는 방법이 너무나도 유사하다. 한쪽에서는 마음 속으로 설계도를 그리고, 다른 한쪽에서는 마음속으로 설계도면을 돌려본다. 결국 설계와 코드 검토는 마음으로 행하는 작업이며, 유기적으로 수행해야 효과를 높인다는 결론에 이른다. 물론 예나 지금이나 테스트는 반드시 수행해야할 작업이긴 하지만, 마음의 눈으로 수행하는 코드 검토를 절대 간과하지 말지어다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림