[개발서적] Professional 소프트웨어 개발 핵심 요약 및 정리

1. 소프트웨어 늪지대

---

[ 바보들의 황금 ]

일단 작성하고 고쳐보는 개발

소프트웨어 개발은 설계없이 일단 작성하고 고친다고 해서 빨리 끝나지 않는다. 그리고 나중으로 갈수록 초기 결함을 수정하기 위해 많은 시간이 쓰여 대부분의 시간을 허비하게 되며 부숴지기 쉬워진다. 그럼에도 일단 개발하는 이유는 실행 즉시 얼만큼 진척했는지 알 수 있고, 프로젝트를 진행하는데 어떠한 훈련도 필요 없기 때문이다. 하지만 이러한 방식은 첫눈에 좋아 보일지몰라도, 숙련된 개발자들은 그것이 얼마나 가치없는 것 인지 안다.

 

 

품질에 집중하라

품질을 버리고 비용이나 시간을 줄이려는 시도는 대부분 비용을 높이고 일정을 늘리기만 한다. 오히려 95% 이상의 결함을 제품 출시 전에 제거하는 프로젝트가 가장 생산성이 높다.

 

 

바보들의 황금

어떠한 혁신적인 방법이 커다란 성공을 가져오리라 기대했지만, 오히려 그 혁신으로 인해 실패한 것들이 많다. 무작정 새로운 유행을 따르게 되면 최악의 생산성에 빠질 수 있다. 그렇기 때문에 적절한 훈련을 거치고 장기간에 걸친 전략으로써 새로운 것을 적용해야 한다.

 

 

소프트웨어는 소프트하지 않다

하드웨어는 일단 만들고나면 바꾸기 어렵지만 소프트웨어는 바꾸기 쉽다는 점에서 소프트하다고 알려져 있다. 하지만 소프트웨어 시스템이 점점 더 복잡해짐에 따라, 소프트웨어가 고치기 쉽다는 믿음은 오히려 해악이 되어버렸다. 소프트하다는 특성 때문에 요구사항을 바꾸는 일이 비일비재하여 비용과 일정이 자주 초과된다는 연구 결과도 나왔다.

또한 소프트웨어 개발자들은 언제나 확장가능한 형태로 설계해야 한다고 얘기할 수 있다. 하지만 이러한 확장가능성 또는 유연성은 돈이나 시간과 같은 비용과 직결되기 때문에, 현재 필요한 것과 앞으로 필요한 것의 균형을 맞추어 결정해야 한다.

 

 

어떻게 바보들의 황금을 가려낼 것인가?

지금까지의 내용들로 얻어낸 소프트웨어의 자명한 특성들은 다음과 같다.

• 프로젝트의 성공은 프로젝트 초기에 얼마나 빨리 코딩하는가에 달려 있지 않다.
• 결함 개수에 초점을 맞춘다면 비용과 기간에 걸린 문제는 자연히 해결될 것이다.
• 은빛 총알(새로운 트렌드)는 프로젝트에 유해하다. 하지만 기업에서는 끊임없이 새로운 은빛 총알을 제안할 것이다.
• 건성으로 프로세스를 개선하려는 것은 특히나 더 위험하다
• 소프트웨어는 소프트하지 않으며, 소프트하게 하기 위해서는 비용이 든다.

 

[ 화물 숭배 소프트웨어 공학 ]

프로세스 기반 개발은 잘 짜인 계획, 잘 정의된 프로세스, 효율적인 시간 사용, 오랜 경험을 통해 좋다고 판명된 소프트웨어 공학 기법들을 적용해 프로젝트를 성공시키는 것이다. 이 개발 방식을 적용한 프로젝트는 대부분 성공하고, 회사는 지속적으로 자신의 역량을 향산한다. 도입 초기에는 약간의 혼란이 생길지도 모른다. 그러나 프로세스에 계속적으로 투자한다는 것은 다음에 적용할 때 전에 적용한 것보다 더 좋은 결과를 얻게 된다는 것을 의미한다. 책임 기반 개발은 영웅 중심 개발 또는 개별 권한 부여 등의 이름으로 불리기도 한다. 이는 조직이 해당 분야의 최고 인재를 고용한 다음, 그 사람에게 특정 프로젝트를 맡아주도록 요청하고, 전권을 위임한다. 이는 해당 인재에게 동기 보여를 제공하고, 생산성을 높이게 되어 성공할 확률이 높아진다.

 

 

개발 방법 사칭 조직

앞서 설명한 두 개발 방법을 현명하게 사용한다면, 비용을 절감하고 개발 기간도 단축하면서 좋은 품질의 소프트웨어를 만들 수 있다. 하지만 둘 다 완벽히 실행되기는 어렵고, 제대로 수행하고 있는지 알아내기도 어렵다.

프로세스를 중시한다고 사칭하는 조직들은 조직이 아닌 프로세스 자체를 위한 프로세스에 투자하는데, 이 과정에서 다른 회사를 참고하며 여러 잘못된 기법들을 많이 만든다. 그에 따라 엄청난 분량의 문서와 회의가 성공의 길이라고 오해한다. 하지만 이것은 성공을 담보하는 요소가 아니라 프로젝트를 수행하면서 생기는 부작용일 뿐이다. 이런 조직들은 프로세스의 형태를 그 본질보다 중요하게 생각한다. 그래서 개발자들의 사기는 오히려 떨어지고, 생산성은 저하된다.

책임을 중시한다고 사칭하는 조직은 어떻게 하면 좀 더 밤 늦게까지 일하게 할 수 있는가에 골몰한다. 그래서 다른 회사를 참고하며 적은 분량의 문서와 스톡 옵션을 주고 야근하도록 닥달하면 성공할 것이라고 오해한다. 하지만 MS와 같은 책임 중심 조직들은 직원들에게 야근을 강요하지 않는다. 대신 소프트웨어 만드는 것을 좋아하는 사람들을 고용하고, 팀으로 묶어 프로젝트를 진행하게 한다. 진행 동안에는 아낌없이 지원하고, 결과가 좋으면 충분히 보상하며, 끝나면 충분히 쉬게할 뿐이다. 관리자가 시켜서 야근하는 것이 아니라, 개발자 스스로 좀 더 일해야겠따고 결정한 것이다. 책임 사칭 조직은 결과(긴 근무시간)와 원인(높은 동기부여)을 혼동한다. 그리고 조직이 무질서하고 비효율적이게 된다.

 

 

화물 숭배 소프트웨어 공학

위의 두 잘못된 조직 형태는 모두 비효율적이며, 무엇이 프로젝트의 성공 여부를 결정하는지 정확히 이해하지 않고 모방하려고만 하였다. 조직의 성공 원인을 확실히 이해하지 않는다면 무의미하게 흉내내기만 할 뿐이다.

 

 

진정한 논쟁

위에서 설명한 두 프로세스 모두 좋으며, 동시에 존재할 수도 있다. 어느 것이 더 좋느냐는 개인의 스타일과 성격에 달려있다고 해도 과언이 아니다. 잘 계획하고 합리적으로 수행하면 어느 쪽이든 잘 실행된다.

우리는 프로세스인가 책임인가 보다는 완전하냐, 불완전하냐를 노의해야 한다. 어떤 스타일을 선택했느냐가 중요한 것이 아니라, 프로젝트를 수행하기 위해 어떤 교육, 훈련, 이해를 동반하느냐를 심각하게 고려해야 한다. 즉, 이에 대해 공방을 벌이기보다 개발자와 관리자의 능력 수준을 향상시키는 길을 찾아야 한다. 그러면 어떠한 개발 방식을 선택했는지에 상관없이 프로젝트 성공 확률을 높여줄 것이다.

 

 

[ 컴퓨터과학이 아닌 소프트웨어공학 ]

소프트웨어 공학대 컴퓨터 과학

전문적인 소프트웨어 개발은 어떤 모습이어야 하는가? 저자는 이에 대해 반드시 공학이여야 한다고 답하고 있다.

소프트웨어 개발자의 약 40% 정도는 소프트웨어공학 학위가 아닌 컴퓨터과학 학위를 가지고 있다. 많은 사람들이 이 둘의 차이에 대해 혼란스러워 한 건 하루 이틀이 아니다. 소프트웨어에서의 공학과 과학의 차이점은 다른 분야에서와 동일하다.

과학자는 무엇이 진실인지, 만든 가설을 어떻게 테스트할 수 있는지, 또 어떻게 하면 지식을 더 확장할 수 있는지 배운다. 하지만 엔지니어는 무엇이 진실인지, 어떤 것이 쓸모가 있는지, 받아들인 지식을 사용하여 실무상의 문제를 어떻게 해결하는지에 대해 배운다. 또한 과학자는 항상 최신 논문이나 연구에 촉각을 곤두세워야 하지만 엔지니어는 효율적이고 믿을 수 있다고 증명된 지식에 익숙해져야 한다.

물론 그 외에도 많은 차이점이 있는데, 문제는 컴퓨터과학 전공자들이 소프트웨어 개발(공학의 영역)을 하게 된다는 것이다.

 

 

소프트웨어공학이라는 단어 뒤에 숨겨진 의미

공학은 실세계의 문제를 해결하기 위해 과학의 원리를 응용하는 것이다. 그렇기 때문에 우리는 각각의 프로젝트에 적절한 개발 방법론을 적용하면 된다. 그리고 프로젝트가 잘 굴러가려면 아래의 목표들을 만족하도록 관리해야 한다.

• 최소한의 결함
• 최대한의 사용자 만족도
• 응답시간의 최소화
• 운영성
• 확장성
• 어떤 상황에도 다운되지 않는 것
• 정확한 결과

프로젝트 팀은 위에 나열된 특성들의 우선순위를 명확히 정의한 후, 그에 맞는 특성을 고려해야 제품을 제작해야 한다. 만들고자 하는 목표에 따라 소프트웨어 공학은 다양한 범주로 적용 가능하며, 소프트웨어 공학은 인건비가 대부분의 비용을 차지하기 때문에, 목표를 최적화하는 것 역시 중요하다.

 

 

[ 지식체계 ]

한 분야의 전문가가 되기 위해서는 50000여의 지식을 알아야 하고, 이 지식들은 각각 따로 기억해야 하는 성질의 것이라고 한다. 특히 성숙한 분야의 경우 모든 관련 정보를 소화하려면 세계적인 수준의 전문가일지라도 최소 10년이 걸린다고 알려져 있다.

또 소프트웨어 관련 지식은 지식체계로 정리하기에 너무도 불안정하다고 주장하는 사람도 있다. 예를 들어 현재 소프트웨어 개발에 필요한 정보 중 반은 3년 내에 죽은 정보가 될 것이기 때문이라고 말한다. 그리고 실제로 기술 관련 지식들의 경우 3년 후에는 반 정도만 계속 사용되는 경우가 대부분이다. 그러나 프로그래머로 살아가는 동안 지속적으로 도움을 주는 지식들도 분명히 존재한다. 이 지식은 반감기를 뛰어넘어 계속 살아남는다.

 

 

본질과 비본질

1987년 프레드 브룩스는 "은빛 총알은 없다(No Silver Bullets)"는 글을 발표했다. 이 글의 주요 내용은 어떠한 툴이나 방법론도 다음 10년에 걸쳐 10배의 샌산성을 향상시킬 수는 없다는 것이다. 이 주장을 이끌어낸 논리를 살펴보면, 반감기를 따르지 않고 살아남은 소프트웨어 개발 지식이 무엇인지 아는데 도움이 될 것이다.

브룩스는 이 글에서 본질(essence)과 비본질(accident)라는 단어를 이용해, 소프트웨어 공학 논의에 고대 철학을 끌어다 놓았다. 본질적 속성이란 어떤 개체를 바로 그 개체가 되게 하는 속성으로, 자동차는 자동차가 되기 위해 반드시 엔진, 바퀴, 변속기를 가져야 하는데, 이런 것들이 바로 본질적 속성이다. 반면에 자동차의 엔진이 무엇이고, 어떠한 타이어를 사용하는지는 자동차를 정의하는데 어떠한 영향도 미치지 않는다. 이러한 것들은 비본질적 속성인 것이다.

브룩스는 소프트웨어 개발에서 가장 어려운 것은 한 컨셉을 프로그래밍 언어로 표현하는 것(코딩)이나 그 표현이 정확한지 확인하는 것(테스팅)이 아니라고 말했다. 이것들은 그저 비본질적 속성이며, 소프트웨어 개발의 본질은 서로 맞물려 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이라고 주장했다. 또 그는 소프트웨어가 어려운 본질적인 이유가 복잡성, 일치성, 변화 가능성, 비가시성 때문이라고 했다.

컴퓨터 프로그램은 천성이 복잡하다. 새로운 프로그래밍 언어가 등장하였다 하더라도, 여전히 실게계 엔티티 간의 관계를 자세히 정의해주어야 하고, 예외적인 상황을 식별해야 하며, 모든 상태 변화를 예측해야 한다.

또 다른 어려운 점은 하드웨어나 써드파티 컴포넌트, 법규, 비지니스 룰, 기존 시스템의 데이터 포맷 등과 같은 복잡한 실세계 제약 사항에 일치하는 소프트웨어를 작성해야 한다는 것이다. 소프트웨어 설계자는 복잡성을 낮출 수 있는 설계를 하고 싶지만, 실세계의 외부 요인 때문에 성공하지 못한다.

소프트웨어의 변화 가능성은 또 다른 본질적인 어려움을 불러온다. 성공한 애플리케이션은 더 많은 사람들이 사용하게 되고, 늘어난 사용자를 위해 초기에 의도한 것보다 더 많은 영역에 적합하도록 수정되어야 한다.

마지막 본질적 어려움은 소프트웨어의 비가시성 때문에 일어난다. 소프트웨어는 도형 같은 것으로 표현하기 힘들며, 간단한 로직이라도 시각적으로 표현하려면 복잡해진다.

브룩수는 비본질적 속성에서는 더 이상 발전될 것이 없다고 말했다. 고수준 언어나 통합 개발 환경 등이 이미 적용되어 많은 부분이 개선되었다고 한다. 그는 앞으로의 대규모 생산성 증가는 오직 소프트웨어의 본질적 어려움(복잡성, 일치성, 변화 가능성, 비가시성) 들을 해결할 때만 이루어질 수 있다고 주장했다.

 

 

소프트웨어공학 지식 체계

전문가들은 소프트웨어공학 영역이 어떠한 지식들로 구성되는지 정의할 때, 일반적으로 받아들여지는 지식과 기법에 초점을 맞춰야 한다고 권고하였다. 일반적으로 받아들여진다는 것은 해당 지식과 기법들이 대부분의 프로젝트에 적합하다는 것을 의미한다. 그러나 모든 프로젝트에 똑같이 적용되는 것은 아니다. 프로젝트 리더는 특정 프로젝트에 가장 적합한 기법을 선택할 책임이 있다.

몬트리올에 있는 퀘백대학의 연구원들은 소프트웨어공학에서 일반적으로 받아들여지는 요소들을 식별하려고 노력해왔다. 이 시도는 소프트웨어공학 지식체계 프로젝트(SWEBOK)라 명명되었고, ACM과 IEEE에서 관리한다. SWEBOK은 전문 소프트웨어 엔지니어가 반드시 갖추어야 할 능력을 구성하는 지식 영역들을 식별하였다.

• 소프트웨어 요구사항
• 소프트웨어 설계
• 소프트웨어 구축
• 소프트웨어 테스팅
• 소프트웨어 유지보수
• 소프트웨어 형상관리
• 소프트웨어 품질
• 소프트웨어 공학 관리
• 소프트웨어 공학 툴과 방법론
• 소프트웨어 공학 프로세스

 

많은 실무 프로그래머들은 단지 소프트웨어 구축만을 필요한 지식 영역으로 생각한다. 구축이 중요하다고 하지만, 그것은 10가지 영역 중 하나일 뿐이다. 또한 실무자들은 소프트웨어 구축이나 유지보수에는 상당히 지식을 갖게 되었지만, 요구사항, 디자인, 테스팅 등 다른 분야에는 거의 아는 바가 없게 되었다.

물론 소프트웨어 엔지니어가 모든 영역을 숙달하기를 바라지는 않지만, 전문 소프트웨어 엔지니어라면 반드시 모든 개론 정도의 지식은 가져야 하며, 대부분의 영역에 대해서는 충분한 지식을, 특정 영역에 대해서는 숙달되어야 한다고 생각한다.

앞서 설명했듯이 과학자와 엔지니어의 차이는 과학자는 좁은 영역에만 깊은 지식을 가져도 되는데 비해, 엔지니어는 제품에 영향을 미치는 모든 요소들에 대해 광범위하게 이해할 필요가 있다는 것이다.

 

 

주춧돌 놓기

지금까지 설명한 소프트웨어 공학의 지식 체계가 더 이상 변하지 않을 것인가? 아니다. 의학 분야가 계속 진화하듯이, 소프트웨어 공학 분야도 계속 진화할 것이다. 그러나 현재의 지식체계를 정의하는 것은 더 좋은 기반이 될 것이다.

 

 

 

2. 개인의 프로 정신

---

[ 소프트웨어 의식 향상 ]

찰스 리치는 의식혁명이라는 책을 내놓았는데, 여기서 자각 단계를 의식1, 의식2, 의식3으로 구분하였다.

 

• 의식1
  • 개척자 정신으로 독립과 자기 만족에 큰 비중을 둔다.
  • 그들은 남이 자신에게 지시하는 것을 쉽게 참지 못한다.
  • 찰스 리치는 의식1이 미국의 초기 100년 간의 사회 양상을 지배했고, 이러한 자립적 측면이 미국 발전의 중요한 요소가 되었다고 믿었다.
• 의식2
  • 회사에서 일하는 사람들의 정신이다.
  • 의식2의 사람들은 인간 관계와 규칙의 중요성을 안다.
  • 그들은 규칙이 사회에 이로운 것이라 믿고, 따라야 한다고 생각한다.
  • 리치는 20세기 중반부터 의식2가 의식1보다 더욱 우세해졌다고 보았다.
• 의식3
  • 계몽된 독립 정신이다.
  • 의식3의 사람들은 원칙 아래 행동하지만, 의식2 처럼 규칙을 중요하게 생각하지 않고, 의식1 처럼 이기적이지도 않다.
  • 리치는 의식혁명이 출판되던 즈음에 의식2가 사라지고 있으며, 의식 3이 그 대안이라고 생각하였다.
  • 의식 3은 히피 열풍을 뜻하는 것이었다. 하지만 히피 문화가 점점 사라지면서 리치의 예측도 신빙성이 떨어져갔다.

 

 

 

완벽한 것은 없다.

리치의 예측은 시간의 시험을 통과하지 못한듯 하지만, 3가지 의식 분류는 현대 소프트웨어 산업에 유용한 모델이 된다.

소프트웨어에서 의식1은 자만심과 관련 있다. 이런 개발자들은 좀처럼 타인의 아이디어를 받아들이지 못하고, 홀로 일하기를 즐긴다. 또 표준을 따르기 싫어하며, 자기가 만든 것이 아니면 신뢰하지 않는 신드롬이 번성한다. 의식1의 사람들은 작은 프로젝트를 위해 적은 수의 프로그래머만을 고용해도 문제 없는 상황에서 제대로 작동한다. 하지만 일정 규모의 팀이 필요한 프로젝트에는 적당하지 않다. 즉, 작은 프로젝트에서만 가치가 있다.

소프트웨어에서 의식2는 규칙을 중시한다. 소프트웨어 개발자들은 결국 의식1의 독립된 개발 스타일의 한계를 발견하고, 팀 단위 개발에 눈을 돌린다. 개발자는 시간이 지나면서, 남과 같이 일하는데 필요한 규칙들을 배우게 된다. 또한 시행착오를 거치며 비공식적인 규칙을 만들어 효율적팀으로 탈바꿈하기도 한다. 이 단계의 개발자들은 방법론에 따르는 것을 중요시 한다.

소프트웨어에서 의식3은 원칙에 초점을 맞춘다. 이 단계에서 개발자는 이미 만들어진 방법론이란 것이 기껏해야 원칙에 가까워지려고 노력한 것에 불과하다는 것을 꿰뚫는다. 즉, 유사 원칙들은 대부분 잘 적용되지만, 모든 경우에 적용되는 것이 아니라는 것을 깨닫는다. 의식3의 원리를 개발자에게 가르치려면 많은 교육 훈련이 필요하지만, 훈련을 받게 되면 프로젝트의 광범위한 성공을 지원하는 강력한 소프트웨어 공학 도구들로 무장하게 된다.

의식2의 접근 방법이 테크닉과 절차를 반복 이용한다면, 의식3에서는 판단과 창의성을 이용한다. 의식2의 개발자는 무엇이 그것을 가능하게 했는지에 대한 깊은 이해 없이 단지 흉내내기만 하기 때문에 의식2의 접근 방법은 불안정한 프로젝트 결과를 이끌어낸다.

 

 

당신 곁에 있는 것을 사랑하라

소프트웨어 업계는 오랫동안 모든 경우에 적용가능한 만능 방법론을 찾으려고 시도했지만 실패하였다. 이것은 의식2의 접근법이며, 의식2이기 때문에 조금이라도 적용 영역을 벗어나면 실패하였다. 소프트웨어 세계는 몇 가지 규칙으로 설명하기에 너무나 복잡하다. 그렇기 때문에 의식3 개발자라면 만들어야 하는 대상마다 서로 다른 방법론을 사용할 것이다.

 

 

당신은 경험을 쌓았나?

리치는 의식의 3단계를 시간의 흐름에 따른 시대 정신으로 보았지만, 저자는 소프트웨어 공학에서는 개인 성숙의 단계로 생각한다. 누군가는 의식2까지 이르는 여정을 밟는다. 어떤 경우 의식2는 충분히 효율적인 업무를 보장할 수 있다. 하지만 상황에 따라 의식3로 진보할 필요가 있을 것이다.

의식2와 같은 규칙 기반 기법들의 세부사항은 실제로 그리 중요하지 않다. 필요에 따라 규칙을 깰 수 있을 정도로 소프트웨어 프로젝트 역학을 깊이 이해하는 의식3으로 발전하려면, 그것을 실제로 적용하는 경험을 쌓아야만 한다.

 

 

[ 커뮤니티 ]

저자는 컴퓨터 업계에 직장인으로 발을 들여 놓은지 3년이 되기까지 어떤 책이나 프로그래밍 잡지를 구독하지 않았었다. 하지만 새로운 회사에 입사하여 다양한 책들을 읽으면서, 지금까지 알고 있던 것보다 훨씬 더 도움이 될만한 정보들이 어딘가에 있을 것이라는 생각이 들었다고 한다. 이후에 ACM, IEEE와 같은 잡지들을 구독하며 효율적인 업무 수행을 위해 필요한 이슈들을 접하는 내용들을 통해 많은 것들을 배울 수 있었다고 한다.

그리고 이러한 커뮤니티를 하면서 소프트웨어 개발을 좋아하는 다른 사람들과 자신의 경험들을 공유하고, 동기를 부여받았다고 한다. 그 외에도 다양한 지식들을 나누면서 아이디어를 넓힐 수 있었다고 한다.

 

[ 건축가와 목수 ]

성숙한 분야의 업무는 갈수록 계층화, 전문화된다. 건설 업계에서 건축가와 엔지니어는 주 계약자가 수행해야 할 계획을 세운다. 그리고 소프트웨어 업계도 이러한 직종들이 생겨나고 있다.

 

 

계층화

소프트웨어공학이 점점 성숙해짐에 따라, 많은 교육과 훈련이 필요한 직종부터 그렇지 않은 직종까지 계층이 나눠질 것이다. 그리고 그 계층에 따라 갖는 책임과 특권 및 보상들도 달라질 것이다.

 

 

전문화

계층화에 더불어, 소프트웨어 업계는 직업을 전문화할 필요가 있다. 오늘날 대부분의 소프트웨어 인력은 만능이다. 그들은 한 순간 건축가였다가, 코드를 찍는 목수로 변신한다. 하지만 전문화는 성숙된 전문직의 중요한 요소이다. 소프트웨어 개발에 관한 연구에서도 특정 기법을 사용하는 것보다 각자 특정 전문 역할을 맡도록 훈련하는 것이 훨씬 효과적이라고 말한다.

 

 

시간이 말해줄 것이다.

계층화와 전문화가 이루어지는 것은 미래를 앞서간 결론일 것인가? 시간이 지나야 알겠지만, 이것은 의학이나 법률 같은 성숙된 전문직에서는 이미 이루어진 일이다.

 

[ 글 쓰는 프로그래머 ]

프레드 부룩스는 최고의 소프트웨어공학 기법과 평균 소프트웨어공학 기법 간의 격차는 아주 크며, 이에 따라 최고의 기법들을 전파하는 도구의 역할이 중요해질 것이라고 얘기했다. 그렇다면 이러한 전파를 위한 안내서를 누가 만들어야 할까?

• 최근 퇴직자
• 대학 교수
• 세미나 강사
• 컨설턴트
• 두뇌 집단 개발자
• 상용 소프트웨어 프로젝트에서 일하는 개발자

저자는 상용 소프트웨어 프로젝트에서 일하는 개발자들이 안내서를 써야한다고 한다. 실제 소프트웨어 세계에 직접 참여하여 경험하지 못한 사람들은 아주 조금의 것들 만을 얻기 때문이다.

그리고 저자는 소프트웨어 개발에 참여중이라면, 글을 한번 써보라고 권한다. 이것이 코딩에 관한 것이든, 품질보증 기법, 효과적인 프로젝트 관리 기법 등 상관없이 아이디어를 책에 옮겨 보라고 한다.

 

 

 

3. 조직의 프로 정신

---

[ 소프트웨어 골드러시 ]

소프트웨어 골드러시

저자는 혁신적인 기술이 출현할 때마다 '소프트웨어 골드러시'의 시작으로 본다고 한다. 여러 개인과 회사는 조금만 열심히 일하면 엄청난 돈을 안겨줄 것이라고 신기술 영역으로 몰려든다. 하지만 소프트웨어 골드러시는 고위험 고수익이라는 특징이 있다. 그래서 누군가는 개척자가 되려고 하는 반면, 누군가 발굴하기를 기다리는 사람들도 있다. 물론 개척자가 되어 성공할 확률은 상당히 낮다.

 

 

포스트-골드러시 소프트웨어 개발

골드러시가 지난 후의 소프트웨어 개발은 체계적이고 위험도가 낮으며, 자본과 노동집약적이다. 그리고 골드러시 기간에는 거의 주목받지 못한, 소프트웨어공학에 대한 심도있는 고찰이 이 단계에서 기술의 성숙과 함께 부각된다.

골드러시 이후에 옛날 방식으로 일하는 것은 골드러시 시대에 같은 방식으로 일할 때보다 성공률이 낮다. 신기술 등장 초기에는 일정 수준에 도달한 전문가나 상품의 수가 드물어서, 기술 진입 장벽이 낮고, 조잡하고 불안정한 품질이라도 초기 상품이라는 이유로 성공을 거둘 수 있었다. 그로 인해 초창기에는 소수의 인원과 적은 자본만으로도 경쟁에 뛰어들 수 있는 것이다. 예를 들어 맥킨토시판 MS Word의 첫 버전은 겨우 153,000줄의 코드만으로 제작된 골드러시 상품이다. 하지만 기술이 성숙되면서, 손쉽게 채집가능한 금덩이는 사라지고 성공한 기업들은 고도로 자본이 집약된 프로젝트 기반 아래서 경쟁얼 벌여야 하는 처지가 되었다.

골드러시 기간 중에 성공을 거둔 기업들이 이후에 저지르는 가장 큰 실수는 프로젝트의 규모가 커지고, 기술이 성숙했음에도 불구하고 과거의 접근법을 고수한다는 것이다. 골드러시 이후에는 단순히 젊은이의 수를 늘리는 것만으로 경쟁할 수 없다.

또한 골드러시 이후 고객들은 더욱 까다로워진다. 골드러시 시대 고객들은 혁신자이자 선각수용자이기 때문에, 신기술에 푹 빠져 매끄럽지 못한 결점 정도는 참고 넘어간다. 하지만 이후에 등장할 소비자들은 위험을 회피하며, 믿고 쓸 정도로 개선된 제품을 원한다.

 

 

골드러시 경제에 대한 오해와 이해

거시경제학적 관점에서 보자면, 사업적인 위험을 자발적으로 감수하는 수천의 개인 소프트웨어 개발자들은 매우 유익한 존재이다. 하지만 회사의 입장에서는 모든 신기술에 투자하는 것이 불가능하다. 그렇기 때문에 회사는 일부 작은 골드러시 회사를 인수하기도 한다. 하나의 성공에 돈을 치르는 것은 불투명한 사업을 자체적으로 천 번 시도하는 것보다 저렴하기 때문이다.

 

 

[ 소프트웨어 개발 개선 사례 ]

최상의 소프트웨어 개발

일반적인 조직들은 효과적인 소프트웨어 기법들을 아주 느리게 받아들이고, 그로 인해 아주 소수의 조직만이 높은 수준까지 올라가게 된다. 실제로 최악의 조직과 최상의 조직을 비교해보면, 능력 측면에서 10:1 정도의 격차를 보인다고 한다.

또한 책에서 보여주는 분포는 대부분의 개발자가 최상의 소프트웨어 개발이 어떤 건지도 모른다는 것을 암시하며, 분명 좋은 방법이 있음에도 불구하고, 자신이 보지 못했으므로 회의적 태도를 보인다고 한다. 이후의 내용들에서는 최고의 조직들이 얼마나 뛰어난지를 보여준다.

 

 

소프트웨어 개발 기법 개선의 효과

소프트웨어 공학 연구소는 체계적인 프로세스 개선을 이룬 조직들은 엄청난 생산성 향산과 결함의 감소 등을 보여주었음을 제시하였다. 또한 대부분의 조직에서 높은 생산성과 더 나은 품질이 공존할 수 있음을 보여주었다. 결함을 방지하는데 중점을 두는 조직은 일정 단축과 생산성 향상 모두를 얻을 수 있었다.

 

 

소프트웨어 개발 기법 개선의 효과

조직이 소프트웨어 개발을 효과적으로 할 수 있었던 이유는 조직마다 다르겠지만, 일부 특정 기법들은 모든 조직에서 대체로 효과적으로 인정되었다.

• 정형 코드 검증
• 정형 설계 검증
• 장기 기술 계획
• 가격, 품질 예측 도구
• 생산성 추정
• 프로세스 평가
• 관리 교육
• 기술 직원 교육

 

소프트웨어 추정으로 얻을 수 있는 통찰

조직이 더 정확히 무언가를 추정할 수 있다는 것은 그 조직이 프로젝트를 얼마나 잘 관리하고, 수행하는지 보여주는 지표다. 하지만 26000개가 넘는 비지니스 시스템 프로젝트들을 조사한 결과 처음 계획한 예산보다 100% 초과한다는 사실을 알아냈다.

 

 

소프트웨어 개발 기법 개선의 간접 효과

여러 문헌에서 다루는 투자대비수익률은 대부분 운영상의 비용 절감 효과에 기반한다. 즉, 코드의 라인 단위 또는 기능 점수 단위 개발 비용을 줄이는 것을 의미해왔다. 직접적인 비용 절감 효과도 상당하지만, 개선된 소프트웨어 기법에서 얻을 수 있는 간접적인 이익도 무시할 수 없다.

더 나은 소프트웨어 개발 기법은 비용과 일정 추정 성공률을 높이고, 일정/비용 초과 같은 위험을 줄여준다. 또한 문제점을 조기에 발견할 수 있고, 더 정확히 관리할 수 있다.

소프트웨어 제품 회사의 경우, 개발 일정 추정 정확도를 높이면 고객의 신뢰도나 비용 등의 효과를 얻을 수 있다. 또한 간접적인 이익으로는 새로운 사업 기회를 얻게해준다는 것이다. 경영자의 입장에서는 간접적인 이익이 훨씬 매력적일 것이다.

 

 

최상의 조직

대부분의 조직에서는 프로젝트가 커질수록 각 프로젝트 팀원들의 생산성이 떨어진다. 소프트웨어 프로젝트는 규모가 커질수록 경제성이 낮아진다는 것이다. 하지만 여러 성공한 기업에 따르면, 충분히 성숙되고 전문화된 조직이라면 프로젝트의 기존 문제점이라고 알려진 것을 완전히 뒤집고, 프로젝트 규모가 커질수록 개인 생산성을 높일 수 있다는 것을 보여준다.

 

 

문제는 조직이다

많은 조직들은 소프트웨어 기법들을 개선하는 책임을 프로젝트 차원으로 넘긴다. 그러나 실제로 검토해보면 아주 적은 요소들만이 프로젝트 관리자의 통제하에 있으며, 조직 차원에서 가장 크게 개선가능함을 확인할 수 있었다.

 

 

엄청난 가능성이 남겨진 분야

많은 비지니스 분야에서 15~20%의 수익을 낼 수 있다면 매력적인 투자라고 생각한다. 그러나 소프트웨어 개법 기선은 300%에서 1900%까지 평균 500%의 이익을 반환한다. 새로운 기법들은 사용한다고 해서 위험이 증가되지 않지만, 그에 비해 기대 효과는 상당하다. 필요한 것은 기법들을 적용하고자 하는 조직의 결심뿐이다.

 

 

까다로운 질문 열가지

정량적인 데이터 없이 의사를 결정하기란 보통 어려운 일이 아니다. 많은 조직은 다음과 같은 소프트웨어 활동에 대해 기본적인 질문에도 답하기 어려워한다.

1. 당신의 조직은 얼마나 많은 비용을 소프트웨어 개발에 쓰는가?
2. 당신의 프로젝트의 몇%가 기한/예산 내에 수행되는가?
3. 당신의 프로젝트는 일반적으로 얼마나 기한/예산을 초과하는가?
4. 현재 진행하는 프로젝트 중 어떤 것이 명백하게 실패할 것 같은가?
5. 당신의 프로젝트 비용의 몇 %가 충분히 피할 수 있었던 재작업에서 발생하는가?
6. 당신의 소프트웨어에 사용자가 얼마나 만족하는가?
7. 당신의 직원들의 기술은 업계 평균과 비교하여 어느정도 수준인가?
8. 당신의 조직을 비롯한 다른 조직과 비교한다면 어느 정도의 능력을 보여주고 잇는가?
9. 과거 12개월동안 당신 조직의 생산성이 얼마나 증가했는가?
10. 당신 직원의 기술과 조직의 능력을 개선시키기 위해 어떤 계획이 있는가?

이러한 질문들에 대답할 수 없는 조직은 분명 바람직하지 못할 것이다. 또한 앞선 자료들을 살펴보았다면, 더 좋은 소프트웨어 개발 기법들을 사용하는 것이 좋을 것이다.

 

 

[ 프톨레마이오스식 논리 ]

SW-CMM 소개

SW-CMM은 1987년 처음 제안되었는데, 현재 소프트웨어 조직의 개발 시스템을 평가할 때 가장 잘 알려진 효과적인 접근 방법이다. SW-CMM은 소프트웨어 조직을 다섯 레벨로 분류한다.

• 레벨1(초기, Initial)
  • 소프트웨어 개발 프로세스가 없고, 모든 것이 매우 혼란스러운 상태이다.
  • 프로젝트는 비용과 시간을 초과하기 일수고, 조직의 모든 정보가 프로그래머 개개인의 머리 속에 있다. 즉, 프로그래머가 회사를 떠나는 것은 정보가 함께 없어진다는 의미이다.
  • 프로젝트의 성공여부가 1명의 영웅에 의해 크게 좌우된다.
  • 더 나은 개발방법론이 없다면 일단 코드를 작성하고 고치는 개발을 한다.
• 레벨2(반복, Repetable)
  • 기본적인 프로젝트 관리 프로세스가 수립되고, 조직은 정해진 프로세스를 따르는 상태이다.
  • 프로젝트의 성패가 특정 개인에게 좌우되지 않는다.
  • 이 단계에서는 시행할 프로젝트가 이전에 행한 프로젝트와 얼마나 유사한지에 따라 효율적 수행 여부가 결정된다.
  • 이러한 조직에서는 새로운 툴이나 소프트웨어, 방법론을 사용할 때 문제가 발생한다.
• 레벨3(정의, Defined)
  • 이 단계에서는 표준화된 기술과 관리 프로세스가 조직 전체에 적용되며, 각각의 프로젝트는 필요에 따라 표준화된 프로세스를 자신에 맞게 고쳐서 사용한다.
  • 조직 내의 특정 그룹이 소프트웨어 프로세스 활동에 대한 책임을 지며, 교육 프로그램을 설립함으로써 직원들이 이 레벨에 적절한 지식과 기술을 보유하게 한다.
  • 이 단계의 조직은 일단 작성하고 고치는 개발을 넘어선 상태이며, 정해진 예산과 시간 안에 프로젝트를 완수할 수 있다.
• 레벨4(관리, Managed)
  • 프로젝트의 세부적인 결과가 예측 가능한 상태고, 결과의 변동 원인을 식별하고 처리할 수 있을 만큼 안정적인 프로세스를 가진다.
  • 범 조직적으로 프로젝트 자료를 수집핳고 데이터베이스화 함으로써, 여러 프로세스의 효율성을 비교 평가할 수 있다.
  • 모든 프로젝트는 조직의 표준 프로세스 관리 지침에 따르고, 프로젝트에서 생성되는 자료들은 비교/분석할 수 있다.
• 레벨5(최적화, Optimizing)
  • 이 단계에서는 모든 관심이 지속적인 프로세스 개선에 맞추어 진다.
  • 프로세스를 변형하고 변화된 결과를 측정함으로써, 조직 전체에 더 효율적인 새로운 표준을 확산시킨다.
  • 그리고 이전에 발견된 결함이 재발하지 않도록 모든 근본적인 결함 원인을 사전에 제거함으로써 제품의 품질을 보장한다.

SW-CMM의 기본 원칙은 콘웨이 법칙과 유사하다. 콘웨이 법칙은 "프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다"는 것이다. 혼란스러운 회사는 혼란스러운 제품을 만들어내며, 비효율적인 프로세스를 실행하는 회사의 제품은 유치하고 둔한 반면, 효과적이고 최적화된 조직은 조화롭고 아주 만족스러운 소프트웨어를 만들어낸다.

 

 

감당할 수 있는 위험

누군가는 SW-CMM이 조직을 관료적이고 보수적으로 변질시키고, 그에따라 경쟁력을 약화시킨다고 얘기한다. 하지만 이는 사실이 아니다. 잘 정비된 프로세스를 가진 조직은 필요치 않은 위험에 노출될 가능성을 줄임으로써, 예상할 수 있는 위험에만 대처해도 되는 유리한 위치에 올라선다. 그에 반해 덜 정비된 프로세스를 가진 조직은 예상치 못한 위험에서 나오지 못할 수도 있다.

 

 

혼이 없는 소프트웨어 개발

SW-CMM의 영향에 대해 설문조사한 결과 84%가 SW-CMM에 의해 조직이 경직되거나 관료화되었냐는 질문에 동의하지 않았다. 반면에 SW-CMM 레벨1에 있는 직원들은 오히려 20%만이 사기가 좋거나 훌륭하다라고 응답하였다. 그리고 조직의 레벨이 높아질수록 사기가 좋거나 훌륭하다고 응답하는 비율이 증가하였다.

 

 

노력

조직 구조를 향상시키는 것이 좋다고 하더라도, 이것은 쉽지 않은 일이다. 대부분의 경우 조직을 개선하는 시간이 예상보다 많이 소요되었으며, 예산을 초과하였다고 응답하였다. SW-CMM은 은빛 총알이 아니기 때문에, 오랜 시간과 예산이 필요하다. 그리고 이에 대한 주의사항 역시 존재한다.

 

 

형식과 내용

SW-CMM은 조직 개선을 위한 효과적이고 성숙된 모델이다. 이는 조직을 평가하는 효과적인 모델이기도 하다.

단순 레벨을 올리는 것이 아니라 SW-CMM식 조직 개선이 가져다주는 품질과 생산성 향상에 초점을 맞추는 회사는 보다 신중하게 계획을 세우고, 더 나은 실행을 한다. 조직은 프로세스에 중점을 둠으로써 생산성이 높아지고, 적은 결함을 가진 소프트웨어를 만들어내며, 위험을 감내할 수 있다. 또한 좀 더 정확히 추정할 수 있으며, 사기를 증진시키고, 대규모 프로젝트를 잘 수행할 것이다.

 

 

[ 소프트웨어 요소의 정량화 ]

효율적인 소프트웨어 개발, 프로세스 개선과 같이 중요한 주제들에 대해 토의할 때 무시하기 쉬운 것이 바로 인간의 역할이다.

 

인간 요소

소프트웨어공학 연구에서 가장 자주볼 수 있는 결과 중 하나는 개발자에 따른 생산성 차이다. 개발자에 따라 디버깅 시간은 최대 20배가 난다는 것을 실험을 통해 발견하였다. 이 결과는 7년 이상의 경력자들을 대상으로 한 실험에서 도출되었다. 그리고 Cocomo2 평가 모델에서 개인 영향 요소들은 다음과 같은 것들이 있었다.

• 분석가의 경험
• 의사소통 요소
• 언어, 툴의 사용 경험
• 인사의 연속성
• 프로그래머의 경험
• 프로그래머의 능력
• 요구사항 분석가의 능력

 

생산성이 낮은 프로그래머

생산성이 낮다는 것은 자신의 일을 끝내지 못한다는 것이다. 그리고 결국 다른 누군가가 이를 해야할 것이다. 생산성이 낮은 프로그래머들은 그 외에도 설계 표준이나 코딩 관례를 지키지 못하는 경우가 많으며, 다른 사람과 코드를 합칠 때에도 결함을 거의 제거하지 않는다.

 

 

물리적 환경

연구 결과에 따르면 상위 개발자들은 다른 개발자들에 비해 더 크고, 조용하고, 개인적인 사무실을 가지고 있으며, 다른 사람이나 전화로부터 방해가 적다고 한다. 물리적 공간의 차이가 크지 않더라도, 이는 생산성 차이로 귀결된다.

 

 

동기

동기는 사람이 얼마나 일을 잘 수행할 수 있는가에 가장 큰 영향을 미치는 요소로 알려져있다. 그리고 실험 결과 이러한 것들은 사실로 밝혀졌다. 마이크로소프트는 높은 수준으로 동기를 유발시키기 위해 사기를 증진시키는데 초점을 맞춘다. 이를 위한 예산 역시 편성이 되어 있다. 이 예산은 팝콘 기계, 스키, 볼링, 파티, 티셔츠 제작 등으로 사용된다. 또한 프로젝트에 참여한다는 명패 등과 같은 비금전적인 보상에도 많은 신경을 쓴다. 또한 개개인의 생활 역시 존중해준다.

 

 

선임 직원

업계 선두를 달리는 많은 조직들은 경험 많은 선임 직원의 중요성을 인식한다. 이들에 의해 시간과 비용이 심각하게 초과될 수 있다. 그래서 어떤 제품을 업데이트 할 때, 이전 버전의 개발자들을 최소 2명이상 투입시킨다.