[4부 3번 수필] 생산성과 G 이론

소프트웨어 부문에서 생산성을 놓고 이런저런 말이 정말 많다. SI 업체의 횡포부터 시작해서 야근에 이르기까지 여러 가지 이야기가 나오고 있는데, 로버트 L. 글래스 큰 형님은 여기에 대해 어떻게 생각하고 있을까? G 이론이라는 아주 흥미로운 이론을 소개할테니 읽고 즐기기 바란다.

이론 G는 다음 세 가지 요소로 이뤄진다.

• 하위 이론 G11: 대립 관계를 기반으로 하는 시스템은 커다란 타협이 거의 불가능하다.
• 하위 이론 G12: 미국 노동 시스템은 노동-관리라는 대립 관계를 기반으로 한다.
• 하위 이론 G13: 괄목할만한 생산성 향상은 커다란 타협을 전제로 한다.

여기에 따른 결론:

• 이론 G1: 현 미국 노동 시스템에서 괄목할만한 생산성 향상은 거의 불가능하다
• 이론 G1 증명: 영국 시스템을 보라. 노동과 관리가 거의 교착 상태이다. 영국의 생산성은 침체되어 있다. 증명 끝.
• 이론 G21: 노동-관리 대립이 명확하게 정의되지 않은 시스템에서는 생산성 향상이 아직 가능하다
• 하위 이론 G22: 전산은 새로운 분야라서 아직 노동-관리 대립 관계가 제대로 형성되지 않았다

다시 이에 대한 결론:

• 이론 G2: 컴퓨터 개발 또는 컴퓨터 사용과 관련된 생산성이 향상될 가능성이 아직 있다
• 이론 G2 증명: 나는 조합원이 아니다. 여러분도 조합원이 아닐 것이다. 내 관리층은 아직 내 말에 귀 기울인다. 가끔이긴 하지만. 아마 여러분의 관리층도 마찬가지이리라. 우리 분야에서는 노동-관리 대립 구도보다 노동-관리 협조 체계가 좀더 일반적이다
• 하위 이론 G31: 동기부여는 생산성 향상의 중요한 요인이다
• 하위 이론 G32: 전산 관리에서 동기부여보다 통제를 채택하는 경우가 더 잦다.

이에 대한 결론:

• 이론 G3: 전산 관리는 아직 존재하는 생산성 향상의 가능성을 파괴하는 방향으로 움직이고 있다
• 이론 G3 증명: 5년 전만큼 일을 즐기는가? 그렇지 않다고 본다.
• G 이론 전체: 미국 시스템은 생산성을 크게 향상하기에 너무 늦었을지도 모르겠다. 전산 분야는 아직 희망이 있다. 하지만 전산 관리가 그 희망을 파괴할지도 모르겠다.

옮긴이 생각: 바로 이렇기 때문에 과학자나 공학자를 관리(?)하려는 시도는 무의미하다.

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

[5부 8번 수필] 전산학과 교수에게 보내는 공개 편지

로버트 L. 글래스 큰 형님 의견에 따르면 전체 전산학이라는 범주에서 빠진 연결 고리 중 가장 중요한 요소는 바로 '소프트웨어 유지 보수'라고 한다. 실제로 대한민국 소재 4년재 대학교 전산학과나 컴퓨터 공학과에서 유지 보수를 정식 과목으로 택했다는 말은 아직 들어보지 못했다(혹시 누가 사례를 알고 있다면, 이 과목에서 배우는 내용과 과제를 보내주기 바란다).

대학교 때부터 유지 보수를 배워야 하는 이유는 소프트웨어 컨플릭트 2.0을 읽은 독자라면 이미 알고 있듯이

• 유지 보수 업무는 소프트웨어 비용 중 40~80%를 차지한다.
• 유지 보수 담당자는 자기 시간 중 75%를 제품 개선에 쏟으며, 15%만 버그 수정에 투입한다.(리처드 K. 불 "남들이 만든 버그를 수정하는 일은 소프트웨어 유지 보수 담당자 역할이 아니다. 우리(유지 보수 담당자)는 예의상 버그를 고쳐줄 뿐이다.

로 요약할 수 있다. 이렇게 중요한 유지 보수를 학교에서 다루지 않고 있다는 사실이 신기하지 않은가?

자, 그렇다면 말이 나온 김에 신기한 사실 하나를 더 짚고 넘어가자. 이 책을 번역한 역자가 생각하는 전산학 분야에서 가장 등한시되는 요소는 무엇일까? 바로 '디버깅과 성능튜닝'이다. 개발자 중 디버깅과 성능 튜닝을 하지 않는 행운아가 있을까? 하지만 '유지 보수' 과목이 개설되지 않았듯이 '디버깅 101'이라는 과목 역시 개설된 경우는 보지 못했다. 유지 보수 업무 중에 자기가 만든 코드 디버깅에 쏟아붓는 비율을 한번 따져보면 끔찍한 기분이 들 것이다. (개인 차원이 아니라) 학교나 회사에서 제대로 된 '디버깅'에 대해 별반 신경쓰지 않는 이유를 알고 있다면 바로 댓글 부탁드리겠다.

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

[4부 9번 수필] 실패한 소프트웨어 프로젝트에 관한 전설

4부 9번 수필은 짧지만 너무나도 재미있어서(그리고 가슴 찡하기에) 전체를 소개한다. 흥미가 당기신 분들은 소프트웨어 컨플릭트 2.0 책을 구입해서 다른 글도 읽어보시길... ;) 자, 시작한다!

옛날 옛적에 아주 거대한 난관에 봉착한 소프트웨어 실무자가 있었다. 이 실무자가 처한 곤경을 얘기하자면, 소프트웨어는 예산을 초과했고 일정을 놓쳤으며 불안정했다.

소위 소프트웨어 위기에 관한 글을 읽어보았다면 ‘별로 대단한 일이 아니잖소?’라고 말할지도 모르겠다.

하지만 이 사람에게는 대단한 일이었다. 덧붙이자면, 여러분이 생각하는 정도보다 훨씬 심각했다. 이 소프트웨어 실무자는 전산 분야에서 둘째가라면 서러울 대학을 졸업했다. 졸업 후에는 여러 해 동안 탄탄한 프로그래밍 경력을 쌓았다. 심지어는 수년 동안 실무에서 배운 지식과 학교에서 배운 지식의 정수를 조화시키는 방법까지 익혔다.

다시 말하면, 이 소프트웨어 실무자는 우수한 소프트웨어 실무자가 갖출 조건을 모두 갖춘 셈이다. 그렇다면 무엇이 잘못되었을까?

모든 문제는 맨 처음, 해결할 문제가 처음으로 등장했던 때로 거슬러 올라간다. 회사에 큰 돈을 벌어줄, 아주 중대한 문제였다. 관리층이 그렇게 말했다. 마케팅도 그렇게 말했다. 특별한 문제로 취급해야 한다는 사실에는 의심의 여지가 거의 없었다.

첫번째로 특별히 취급해야 할 사항은 특정 날짜까지 끝내야 한다는 점이었다. 관리층이 그렇게 말했다. 마케팅도 그렇게 말했다. 담당할 소프트웨어 실무자가 그 날짜까지 불가능하다고 생각해도 소용이 없었다. 무조건 날짜를 맞춰야 했다.

협조적인 태도를 보이느라, 실무자는 우려에도 불구하고 일을 시작했다. 관리층이 그의 우려에 귀를 기울이기는 했다. 실무자가 소프트웨어를 개발하는 동안, 관리층은 원하는 답이 나올 때까지 비용 예측 모델링 프로그램을 돌렸다. 그리고는 회심의 미소를 띄우며 이렇게 말했다. “봤죠? 시간 내에 소프트웨어를 개발할 수 있다니까요.”

시간이 흐르고 기한이 다가오면서, 우리의 실무자는 점점 더 초조해졌다. 처음에는 자신의 품질 기준에 맞춰서 소프트웨어를 개발했다. 요구사항을 주의 깊게 검토하고, 철저히 설계한 다음에, 프로그램을 실행하기 전에 코드 행 한줄한줄을 신중하게 검토 desk-checkin했다.

그러나 기한이 코앞에 닥치면서, 그는 우수한 기법을 생략하기 시작했다. 요행을 바라면서 테스트를 대충 해버렸다. 어떤 모듈은 테스트하지 않은 채로 통합하기도 했다. 제품은 자체 표준 테스트도 통과하지 못한 상태에서 베타 테스트로 돌입했다. 그러나 기한은 꿈쩍할 가능성이 없어 보였고, 결국 압박감을 견디다 못해 덜 중요해 보이는 사항을 희생하게 되었다.

결국 우리의 실무자는 기한을 맞추지 못했다. 프로젝트는 그가 처음 예측했던 날짜대로 그만큼 늦어졌다. 당연히 비용은 예상보다 많이 들었다. 낙관적인 일정에 맞추어 비용을 예측했으니까. 안정성? 실무자가 기한을 맞추려고 이것저것 건너뛰는 바람에 안정성도 역시 문제였다. 사람들이 말하는 소프트웨어 위기 그대로였다. 일정을 놓치고 예산을 초과하고 불안정한 소프트웨어 프로젝트가 하나 더 생겨났을 뿐이었다.

요약하자면, 옛날 옛적에 우수한 소프트웨어 실무자가 실패한 소프트웨어 프로젝트를 내놓았다. 마음 속으로는 대충 건너뛰면 안 된다는 사실을 알았다. 하지만 동시에 마음속으로는 개발 과정에서 저지른 실수가 하나뿐이라는 사실도 알았다.

그가 저지른 실수는 소프트웨어를 제작한 방식이 아니었다. 처음부터 잘못된 일정에 맞추려는 시도 자체가 실수였다.

소프트웨어 실무자가 관리층으로부터 성과 평가를 받았을 때, 그는 실패한 프로젝트로 인해 자신의 업무 평가가 낮아졌음을 발견했다.

그는 궁금했다. 나와 같은 입장에서 괴로워하는 사람들이 얼마나 많을까? 순전히 잘못된 예측이나 대충 꾸며댄 예측 탓으로 생기는 소프트웨어 위기가 얼마나 많을까?

아직도 그는 궁금해한다.

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