[소프트웨어 공학의 사실과 오해] 15년째 사실인 이야기

[소프트웨어 공학의 사실과 오해] 15년 째 사실인 이야기

말하자면 이 책에 모아놓은 사실들이 소프트웨어 공학 분야에서 가장 기초적이고도 중요한 지식이라는 것이다.

그러나 많은 논쟁이 있을 수 있다고 저자도 말하고 실제로 논쟁이 보이는 부분도 있었다.

저자 Robert L. Glass 는 이런 사실과 논쟁을 말할 수 있는 자격이 있는가? 를 놓고 보았을 때 소프트웨어 분야에서 45년이상을 일하고 기술적 실무자나 연구자였으며, 책 25권을 집필했고, 이쪽 주제에 대해 75편의 전문적인 논문을 썼으며, 현재에도 세 저널에 정기적인 칼럼을 쓰고 있는 그가 아니면 어떤 사람이 소프트웨어공학의 '사실'에 대해 자격을 말할 수 있을까?

그가 인터뷰를 했던 관리자들은 이 책에 나오는 사실 중 많은 것을 잊었거나 들어보지 못했다고 말했다고 한다. 책이 나온 시점에서 15년이 지난 지금 얼마나 많은 부분이 나아졌는지 아니면 불변의 진리인지 궁금하다. 사실 답은 이미 그의 책에 나와있다.

챕터는 다음과 같이 5가지로 나누어 55가지의 사실과 10가지의 오해를 설명하고 있다.

• 관리: 사실 22개 오해 6개

• 생명주기: 사실22개 오해 3개

• 품질: 사실8개

• 연구: 사실1개

• 교육: 사실1개 오해 1개

그리고 이 사실들과 오해들은 이 책의 목차로 다 나오기 때문에 다른 글에서 따로 정리를 하면서 참고 하고 싶은 내용들과 거기에 대해 경험과 생각으로 느낀 점들을 써보려 한다.

이 책이 2002년에 나온 것치곤 (사실은 소프트웨어의 역사와 발전 속도를 놓고 봤을 땐 꽤나 고전이다) 소프트웨어 공학 분야에서 굉장히 유명한 고전으로 알려져 있다.

여기서는 새롭게 느낀 부분이나 정리보단 개인적인 의견을 써보고 싶다.

프로그래머의 자질이 중요하다는 점과 작업성과의 개인차가 5배에서 28배까지 달라질 수 있다는 점은 솔직히 모든 분야가 그렇진 않겠지만 다른 분야에서도 마찬가지란 생각이 들었다. 가장 대표적이 예로 영업능력이 있을 것이다.

새로운 도구 사용에 대해 학습곡선을 극복하고 난 후 실제 이득을 얻을 때 가치를 얻는다는 말은 새로운 말은 아니지만 가끔 나도 마찬가지로 금방 배우고 이게 장기적으론 도움이 될 거란 도구 열광자가 되는 것을 느껴서 공감이 갔다. 이 때 그 장기적으로가 얼마정도인지 기간을 파악할 순 없어도 고려해보라는 부분 (피상적으로 배우는 시간과 능숙해지는 시간도 고려해서)이 도움이 되었다.

형편없는 추정이 프로젝트를 통제 불가능하게 한다는 부분은 굉장히 동의가 되었다. 추정이 어려운 이유가 요구사항도 정의하기 전에 그러니까 문제 이해도 전에 대부분 추정이 들어가야 하기 때문이란 점, 그리고 추정이 경영진이나 마케팅 또는 고객에 의해 결정되는 부적절한 부분에 대해 방법을 찾아보려 하고 있지만 여전히 추정 요소를 알지 못하고 단지 언제 완료될지, 얼마나 많은 비용이 소요될지에 어느정도 확신만으로 예상할 수 밖에 없는 걸까?

그리고 계약이나 출시가 걸려있는 문제에선 추정을 변경하는 것이 굉장히 어렵다..

저자는 추정 외에 다른 방식으로 소프트웨어 프로젝트를 관리할 수 없는지에 대해 언급하기도 했다. 몇 가지 제시를 했는데 XP에서 고객에게 비용, 일정, 기능, 품질 네 가지 요소 중 세 가지를 선택하게 하고 나머지 하나는 고객이 요청한 세 요소에 맞춰 프로그래머가 산정하는 방법이 중요 요소를 식별할 뿐만 아니라 네 요소를 모두 만족시킬 수 있는 방법인 것 같다.

사실13은 충격적이었다. 결론은 프로그래머가 운명을 스스로 통제할 수 있다는 느낌을 가질 때 생산성이 향상된다는 점인데 누구나 그런 것 아닐까?

대학원에 있을 때 배우길 앞으로 점점 컴포넌트 기반의 재사용이 이루어 질 수 있고 모델이 바로 코드로 변환 될 수 있는 방법이 곧 나올 것이라는 긍정적인 방향으로 배운 기억이 있는데 컴포넌트 단위의 재사용이 도메인과 서비스 다양성 앞에서 얼마나 효과적인지는 나도 회의적이었었다.

2장의 생명주기 편은 쭉 읽으면서 대학원에서 '배운' (스스로 익혔다기 보단 수업에서) 모든 내용을 리플레이하는 느낌을 받았다. 오히려 설계에서 코딩으로 전환될 때 설계자의 기본단위와 코더의 기본 단위가 다른 점이 문제가 된다는 점같이 더 디테일하게 설명을 해주는 부분도 있었다.

유지보수에 관한 얘기에서 개선비용과 오류정정을 위한 비용을 나누어 생각하는 부분은 굉장히 새로웠다. 엉켜있던 한 부분이 명쾌하게 풀리는 느낌이었다. 특히 오류정정 비용은 전체 유지보수 비용의 17%정도이고 개선비용이 60%라는 점이 놀라우면서 이해가 되었다.

사실44에서 말한 유지보수 생명주기는 실제로 활용해볼 수 있을 것 같다.

유지보수가 과거 비용 데이터를 살펴 미래 유지보수 비용을 예측할 수 있고 시스템 교체 결정을 내릴 수 있다는 점이 오해라는 점도 조금 놀라웠다. 따지고 보면 당연한 말이긴 하지만 유지보수 비용과 시스템 교체 시점을 보는 논문이 많이 존재하고 있기 때문이다..

3장 품질은 일반적으로 사람들이 품질을 오류에 대한 것으로 생각한다는 점을 집었다. 오류에 관한 것도 물론 품질과 연관있지만 도메인마다 필요한 품질이 다양하다.

그는 소프트웨어 분야가 지혜의 발전이 없다는 점도 이야길 했는데 그러니까 그 말에 따르면 우리는 같은 실수를 계속해서 반복하고 있는 것이다. 같은 실수를 하지 않으려면 어떻게 해야 할까? 15년이 지났어도 수치적으로는 잘 모르겠지만 변함없이 이 사실과 오해들이 적용될 듯 하다. 그러니 이미 겪은 사람들의 지혜를 배워 간접 경험을 해나가는 수밖에 없다.

그러나 내가 아는 소프트웨어 분야의 사람들은 (나를 포함해) 누가 해 놓은 업적을 재사용하기 보다는 직접 경험해보고자 하는 성향이 있는 것 같다. 물론 이 말이 소프트웨어 공학의 사실에 포함될 수는 없다. 이 말이 소프트웨어 공학의 오해에 포함되기를 바란다.