IT/모바일
프레드릭 P. 브룩스(Frederick P. Brooks) : 인간의 편에 선 소프트웨어 공학
저자: 박지훈
출처: 누가 소프트웨어의 심장을 만들었는가 (박지훈 저 / 2005년 3월 출간)
프레드릭 브룩스 ( 1931 ~ 현재 )
개발 기간이 지연되는 소프트웨어 프로젝트의 관리자가 있다. 그는 원래 의도한 날짜에 프로젝트를 마치기 위해 더 많은 인력을 추가했다. 그 결과는 어떻게 되었을까? 지금도 수 많은 프로젝트 관리자가 고민하고 있는 이 질문에 대해 프레드릭 브룩스는 이미 1975년에 답을 했다. 그 답은 소프트웨어 공학이 필요하고 유용하다는 사실을 널리 인식시켰다.
소프트웨어 프로젝트 관리자의 고전 필독서로 오랫동안 사랑 받는 책이 있다. 1975년 프레드릭 브룩스가 지은 “ The Mythical Man Month”는 소프트웨어 개발의 공학적 원리들을 소개하였는데 이들 중 어떤 것은 그 당시 개발자의 기본 상식에서 벗어난 새로운 발상이었다. IBM에서 거대한 운영 체제를 직접 개발하면서 겪게 된 경험을 근간으로 소프트웨어 개발에서 자주 발생하는 문제들을 논리적으로 풀어낸 이 책의 내용은 소프트웨어 공학의 중요한 기준점이 되었다.
IBM에서 운영체제를 개발하다.
1931년에 미국에서 태어난 프레드릭 브룩스는 듀크대를 졸업하였다. 1956년에 하바드 대학에서 컴퓨터 응용 수학(Applied Mathematics)을 전공하여 박사 학위를 받는다. 하워드 아이켄(Howard Aiken)이 그의 스승이었다. 아이켄은 IBM의 하버드 마크 1(Harvard Mark 1) 컴퓨터의 핵심 개발자였다. 그의 영향으로 브룩스는 1956년에 IBM으로 입사하게 된다. 거기서 스트레치(Stretch)와 하비스트(Harvest)라는 컴퓨터들의 아키텍처를 설계하는 일을 하게 된다. 그는 곧 System/360 시리즈에서 동작하는 운영 체제인 OS/360 을 개발하는 프로젝트의 관리자가 된다. 이 시스템을 개발하는 과정에서 얻은 통찰력으로 소프트웨어 공학 분야에 길이 남는 명저를 저술하게 된다.
System/360(S/360) 시리즈는 아키텍처와 구현이 깔끔하게 분리된 최초의 메인 프레임 컴퓨터 시리즈였다. 시리즈의 아키텍트는 진 암달(Gene Amdahl)이었다. 이 시리즈에 속하는 컴퓨터들은 낮은 사양에서 높은 사양으로 업그레이드가 가능하였기 때문에 기업으로부터 많은 인기를 얻게 된다. IBM은 이 시스템에 50억 달러라는 엄청난 비용을 투자했다. 당시 미국에서 가장 높은 비용을 투입한 프로젝트는 아폴로 달 탐사 프로젝트였고 2위가 IBM의 System/360 프로젝트였다고 하니 IBM이 이 프로젝트에 얼마나 관심이 있었는지 알 수 있다.
System/360의 하드웨어가 완성되자 이제는 운영 체제가 필요했다. 따라서 OS/360이라는 운영체제가 배치 처리(Batch Processing)의 용도로 개발되었다. 그런데 이 운영체제는 예상 기간보다 늦게 개발 되었다. 기술적인 어려움 외에 IBM이 소프트웨어 분야에 대규모로 프로젝트를 진행한 경험이 부족했고 개발 조직들간에 불협화음이 있었기 때문이었다. 원래 1966년에 간단한 버전이 출시되어야 했으나 1967년까지 릴리즈 1.0은 생산되지 못했다. 1년 이상 프로젝트가 지연된 것이다. 따라서 IBM은 임시로 BOS(Basic Operating System), TOS(Tape Operating System), DOS(Disk Operating System)을 개발하고 System/360 시리즈에 탑재 시킨다.
OS/360 프로젝트가 지연되면서 프로젝트 관리자인 프레드릭 브룩스는 큰 교훈을 얻게 된다. 그리고 자신이 기존에 경험한 프로젝트의 지식들과 OS/360에서 얻는 통찰력을 기반으로 1975년 “The Mythical Man Month”라는 명저를 저술한다.
전설이 된 소프트웨어 공학의 클래식, “The Mythical Man Month”
그는 이 책에서 당시 시대 상황에는 매우 파격적인 소프트웨어 공학의 원리들을 소개하였다. 그 중 특히 인상적인 것은 책의 제목과 관련이 있다. “Man Month의 신화”가 바로 그것이다. “Man Month(M/M)”란 특정 기간에 프로젝트에 투입되는 인력의 수량을 월 기준으로 나타낸 것이다. 만약 어떤 프로젝트에 한 사람이 12개월 동안 참여했다면 그 프로젝트의 Man Month는 12이다. 만약 두 사람이 참여했다면 24이다. 브룩스는 OS/360 프로젝트가 인력을 더 투입했는데 오히려 더 지연되자 그 이유를 깊이 고민하다가 인력 투입과 개발 기간 간의 상관 관계를 알아냈다.
만약 어떤 개발자가 마이크로소프트사의 파워포인트와 같이 복잡한 프로그램을 만든다고 가정해보자. 아마도 매우 능력있는 프로그래머 1명이 일년동안 프로그램을 분석하고 설계하고 코딩하고 테스트할지 모른다. 이럴 경우 이 프로젝트는 12 Man Month의 노력이 투입된 것이다. 그런데 프로젝트 관리자는 타사의 경쟁 제품이 두 달 후에 출시될 예정이라는 불행한 소식을 듣게 된다. 해법은 무엇일까? 1975년 당시 브룩스를 제외한 대부분의 프로젝트 관리자들은 이렇게 말했을 것이다. “12명의 뛰어난 프로그래머를 스카우트하고 일을 12등분해서 그 사람들에게 나눠 주십시오. 그리고 한 달 안에 일을 마치라고 주문하면 아마 해결될 것입니다. 왜냐하면 12명이 한달 동안 일을 하니까 한 명이 12개월 일하는 것과 동일한 12 Man Month가 투입되었기 때문입니다.”
하지만 브룩스는 다른 결론을 얻었다. “지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다.” 일명 브룩스의 법칙(Brook’s Law)이다. OS/360을 개발하면서 브룩스는 “1 개발자 * 12 개월 == 12 개발자 * 1 개월”이 아니라는 것을 몸소 깨달았다. 개발자를 추가하면 할수록 그들 사이에 미팅, 인터페이스 합의, 이메일 송수신 등과 같은 커뮤니케이션 비용이 월등히 증가하기 시작했다. 또한 커뮤니케이션 오류로 일이 잘못 진행되는 경우도 빈번히 생겼고 그럴 때마다 원상태로 수정하는 추가 작업들이 발생하였다. 이런 요인으로 추가 인력이 투입될수록 프로젝트가 지연되는 현상을 겪게 된 것이었다. 전문적으로 말하면, 개발자가 N명이라면 N만큼 개발자가 일하는 양이 늘어나지만 N의 제곱만큼 프로젝트가 복잡해지기 때문에 결국 시간 내에 일을 끝낼 수 없다는 것이다.
따라서 지연되는 프로젝트를 원래 스케쥴대로 진행하려면 인력을 더 추가하는 것이 아니라 “개발하기로 약속했지만 아직 완성되지 못한 기능”을 없애는 것이 합리적인 방법이며 프로젝트의 범위(scope)를 조절함으로서 스케쥴을 제어해야 한다고 주장했다.
브룩스의 법칙 외에 “두번째 시스템 효과(Second System Effect)”, “프로토타입(prototype)”, “커뮤니케이션(Communication) 중시” 등의 원리들은 30년이 넘는 지금 들어도 충분히 공감되는 소프트웨어 공학의 원리를 제시했다.
“두번째 시스템 효과”란 엔지니어가 두번째로 만드는 시스템은 가장 위험한 시스템이 될 수 있다는 가설이다. 왜냐하면 첫번째 시스템을 작고 성공적으로 개발했던 경험이 있는 엔지니어는 두번째 시스템에서는 그 성공을 뛰어넘을 욕심으로 추가 기능을 많이 포함한 공룡 같은 시스템을 만들려는 경향이 있기 때문이다. 브룩스는 성공적인 IBM 70XX 시리즈의 운영 체제 이후에 OS/360을 개발하면서 그 사실을 깨닫게 되었다. OS/360 은 공룡과 같은 두번째 시스템이었다. 이것은 시스템을 유지보수하면서 확장시켜 나갈 때도 발생될 수 있는 문제이다.
“프로토타입”은 새로운 종류의 시스템을 개발할 때는 프로토타입(prototype)을 먼저 만들어서 기능과 성능을 시험을 해 본 후 버리고, 두번째로 더 좋은 시스템을 새롭게 만들어 고객에게 주자는 것이다. 이렇게 하면 좀 더 품질이 좋은 시스템을 고객에 전달할 수 있다고 주장하였다.
“커뮤니케이션 중시”란 팀은 가능한 다양한 방식으로 의사소통을 원활히 하고 명확히 해야 프로젝트에서 발생 가능한 재앙을 미리 막을 수 있다는 원리이다. 애매한 일은 반드시 매니저에게 확인 받고 진행해야 틀리게 생각했던 작업들의 진행을 방지하여 재작업의 요소를 제거해야 한다는 것이다.
은총알은 없다.(No Silver Bullet) 진정?
브룩스는 1987년에 “은총알은 없다(No Silver Bullet)”라는 소프트웨어 엔지니어링 에세이를 발표했는데 많은 논쟁을 불러 일으켰다. 이 글은 1995년에 출간된 “The Mythical Man Month”의 20주년 기념 서적에 포함되기도 하였다. 그는 소프트웨어 개발 생산성을 한번에 해결해 줄 만한 은총알과 같은 기술이나 개발 방식은 더 이상 없을 것이라고 선언했다. 하드웨어의 발전속도를 소프트웨어 개발 속도가 따라 잡지 못하는 현실을 소프트웨어의 복잡성과 관련해서 설명하였다. 소프트웨어 개발의 복잡도는 두 가지 종류가 있는데, 첫번째로는 제거가 가능한 비본질적(accident)인 복잡성이 있다. 이것은 소프트웨어 개발 방식이나 기술 자체가 덜 성숙하거나 잘못된 경우에 생긴다. 이런 복잡도는 IT 과학자들이 노력하면 복잡성을 제거할 수 있다. 예를 들어 불편한 어셈블리 언어 때문에 개발 생산성이 떨어진다면 C나 자바와 같은 고급 언어를 개발하면 해결된다.. 두번째로는 본질적(essential)인 복잡도가 있다. 브룩스는 풀어야 할 문제 자체가 복잡하다면 그 문제가 사라지지 않는 이상은 복잡도는 줄 지 않는다고 주장했다. 시간이 가면 갈수록 고객들은 복잡한 기능들을 요구할텐데 이런 요구 자체는 단순화될 수 없다는 것이다.. 본질적인 복잡도는 대폭 완화될 수 없기 때문에 소프트웨어 개발 생산성을 높이는 정도에는 한계가 있다는 것이다. 객체 지향이나 재사용 등은 이런 본질적인 복잡성을 줄이지 못하는 실패한 은총알이라 주장했다. 그의 글은 많은 소프트웨어 공학자들이 소프트웨어 생산성을 향상시키기 위해 근본적으로 해결되어야 할 선행 이론들에 대해 관심을 갖게 만들었다.
이 주장은 많은 논쟁을 불러 일으켰고 브래드 콕스(Brad Cox)는 “No Silver Bullet Revisited”라는 에세이에서 브룩스가 말한 본질적인 복잡성도 비본질적인 복잡성들로 분리하여 해결하면 충분히 생산성을 높일 수 있다는 반론을 제기하였다.
누가 소프트웨어의 심장을 만들었는가
인간의 편에 선 소프트웨어 개발의 원리
위의 내용에서 보다시피, 그는 개발자들의 심리와 개발 문화, 커뮤니케이션을 기반으로 소프트웨어 프로젝트의 성과를 분석한 선구자였다. 브룩스의 법칙은 개발자들이 증가할수록 커뮤니케이션의 복잡도가 증가하여 프로젝트의 복잡도가 증가한다는 사실을, “두번째 시스템 효과”는 성공적인 시스템의 후속작을 만들때의 엔지니어의 과대 욕망이 일으키는 프로젝트 실패의 요소를, “커뮤니케이션의 중요성”은 커뮤니케이션 오류로 인해 발생하는 프로젝트의 지연 요소를 지적하고 있다. 브룩스는 단지 뛰어난 능력을 가진 사람들의 노력만으로는 프로젝트를 성공시킬 수 없다는 사실을 객관적인 자신의 경험으로 입증하였다. 기술이 아니라 인간의 편에서 소프트웨어 프로젝트를 투시했다.
그의 성과는 이어지는 소프트웨어 공학 이론들에 큰 영향을 끼쳤다. 베리 보엠의 소프트웨어 개발의 경제학에는 생산성 변수로서 인간의 요소들이 포함되었고, 제럴드 와인버그(Gerald Weinberg)는 인간의 심리학에 근거한 소프트웨어 개발 문화를 역설했으며 켄트 벡은 인간의 용기를 프로그래밍의 주요 덕목으로 내 세운 XP를 개발하였다.
그가 세운 소프트웨어 공학의 원리들은 소프트웨어 프로젝트를 면밀히 관찰하여 데이터를 수집하고 분석하여 공학적인 원리들을 세우는 소프트웨어 공학이라는 학문이 하드웨어의 속도를 못 따라 잡는 소프트웨어의 개발에 꼭 필요하다는 웅변하였다.
안타깝게도 그는 가상 세계에 관심이 많다.
1965년 IBM을 떠난 그는 North California, Chapel Hill 대학에 컴퓨터 공학과를 세우고 교수가 되었다. 지금까지 20년 동안 활발한 연구를 진행하고 있으며 현재 3차원 인터액티브 컴퓨터 그래픽과 가상 세계(Virtual World), 원자 그래픽(Molecular Graphics)에 관심이 많다. 안타까운 것은 그가 소프트웨어 공학이 아니라 가상 세계에 연구를 집중하고 있다는 것이다. 1975년에 보인 그의 통찰력을 현재의 소프트웨어 공학에서도 찾아 볼 수 있었으면 하는 아쉬움이 있다.
그는 운영 체제의 발전과 소프트웨어 공학에 기여한 공로로 1999년에 튜링상을 수상하였다.
“소프트웨어 공학(Software Engineering)”이라는 용어는 1968년 NATO 소프트웨어 공학 컨퍼런스에서 공식화되었고 그때 이후로 널리 사용되고 있다. 소프트웨어 공학의 정의는 다양하지만 IEEE Std 610-1990에서 정의한 것은 다음과 같다[4].
“(1) 소프트웨어의 개발, 운영, 유지보수를 할 때 체계적, 규율적, 정량적인 접근 방식을 응용한 것(The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software)
(2) (1)에 대한 연구”
관련 인물들
1) 베리 보엠
참고 자료
[1] 프레드릭 브룩스의 “Man Month 의 신화”
Frederic P. Brooks, “The Mythical Man Month : Essays on Software Engineering”, Addsion-Wesley, 1975 (1995년에 20주년 기념판이 출간됨)
[2] 프레드릭 브룩스의 “은총알은 없다” 원문
[3] 브래드 콕스의 “’은총알은 없다’를 재고하며” 원문
[4] IEEE의 The Software Engineering Body of Knowledge(SWEBOK)
[5] 위키피디아의 프레드릭 브룩스 페이지
[6] 프레드릭 브룩스 홈페이지
출처: 누가 소프트웨어의 심장을 만들었는가 (박지훈 저 / 2005년 3월 출간)
프레드릭 브룩스 ( 1931 ~ 현재 )
개발 기간이 지연되는 소프트웨어 프로젝트의 관리자가 있다. 그는 원래 의도한 날짜에 프로젝트를 마치기 위해 더 많은 인력을 추가했다. 그 결과는 어떻게 되었을까? 지금도 수 많은 프로젝트 관리자가 고민하고 있는 이 질문에 대해 프레드릭 브룩스는 이미 1975년에 답을 했다. 그 답은 소프트웨어 공학이 필요하고 유용하다는 사실을 널리 인식시켰다.
소프트웨어 프로젝트 관리자의 고전 필독서로 오랫동안 사랑 받는 책이 있다. 1975년 프레드릭 브룩스가 지은 “ The Mythical Man Month”는 소프트웨어 개발의 공학적 원리들을 소개하였는데 이들 중 어떤 것은 그 당시 개발자의 기본 상식에서 벗어난 새로운 발상이었다. IBM에서 거대한 운영 체제를 직접 개발하면서 겪게 된 경험을 근간으로 소프트웨어 개발에서 자주 발생하는 문제들을 논리적으로 풀어낸 이 책의 내용은 소프트웨어 공학의 중요한 기준점이 되었다.
IBM에서 운영체제를 개발하다.
1931년에 미국에서 태어난 프레드릭 브룩스는 듀크대를 졸업하였다. 1956년에 하바드 대학에서 컴퓨터 응용 수학(Applied Mathematics)을 전공하여 박사 학위를 받는다. 하워드 아이켄(Howard Aiken)이 그의 스승이었다. 아이켄은 IBM의 하버드 마크 1(Harvard Mark 1) 컴퓨터의 핵심 개발자였다. 그의 영향으로 브룩스는 1956년에 IBM으로 입사하게 된다. 거기서 스트레치(Stretch)와 하비스트(Harvest)라는 컴퓨터들의 아키텍처를 설계하는 일을 하게 된다. 그는 곧 System/360 시리즈에서 동작하는 운영 체제인 OS/360 을 개발하는 프로젝트의 관리자가 된다. 이 시스템을 개발하는 과정에서 얻은 통찰력으로 소프트웨어 공학 분야에 길이 남는 명저를 저술하게 된다.
System/360(S/360) 시리즈는 아키텍처와 구현이 깔끔하게 분리된 최초의 메인 프레임 컴퓨터 시리즈였다. 시리즈의 아키텍트는 진 암달(Gene Amdahl)이었다. 이 시리즈에 속하는 컴퓨터들은 낮은 사양에서 높은 사양으로 업그레이드가 가능하였기 때문에 기업으로부터 많은 인기를 얻게 된다. IBM은 이 시스템에 50억 달러라는 엄청난 비용을 투자했다. 당시 미국에서 가장 높은 비용을 투입한 프로젝트는 아폴로 달 탐사 프로젝트였고 2위가 IBM의 System/360 프로젝트였다고 하니 IBM이 이 프로젝트에 얼마나 관심이 있었는지 알 수 있다.
System/360의 하드웨어가 완성되자 이제는 운영 체제가 필요했다. 따라서 OS/360이라는 운영체제가 배치 처리(Batch Processing)의 용도로 개발되었다. 그런데 이 운영체제는 예상 기간보다 늦게 개발 되었다. 기술적인 어려움 외에 IBM이 소프트웨어 분야에 대규모로 프로젝트를 진행한 경험이 부족했고 개발 조직들간에 불협화음이 있었기 때문이었다. 원래 1966년에 간단한 버전이 출시되어야 했으나 1967년까지 릴리즈 1.0은 생산되지 못했다. 1년 이상 프로젝트가 지연된 것이다. 따라서 IBM은 임시로 BOS(Basic Operating System), TOS(Tape Operating System), DOS(Disk Operating System)을 개발하고 System/360 시리즈에 탑재 시킨다.
OS/360 프로젝트가 지연되면서 프로젝트 관리자인 프레드릭 브룩스는 큰 교훈을 얻게 된다. 그리고 자신이 기존에 경험한 프로젝트의 지식들과 OS/360에서 얻는 통찰력을 기반으로 1975년 “The Mythical Man Month”라는 명저를 저술한다.
전설이 된 소프트웨어 공학의 클래식, “The Mythical Man Month”
그는 이 책에서 당시 시대 상황에는 매우 파격적인 소프트웨어 공학의 원리들을 소개하였다. 그 중 특히 인상적인 것은 책의 제목과 관련이 있다. “Man Month의 신화”가 바로 그것이다. “Man Month(M/M)”란 특정 기간에 프로젝트에 투입되는 인력의 수량을 월 기준으로 나타낸 것이다. 만약 어떤 프로젝트에 한 사람이 12개월 동안 참여했다면 그 프로젝트의 Man Month는 12이다. 만약 두 사람이 참여했다면 24이다. 브룩스는 OS/360 프로젝트가 인력을 더 투입했는데 오히려 더 지연되자 그 이유를 깊이 고민하다가 인력 투입과 개발 기간 간의 상관 관계를 알아냈다.
만약 어떤 개발자가 마이크로소프트사의 파워포인트와 같이 복잡한 프로그램을 만든다고 가정해보자. 아마도 매우 능력있는 프로그래머 1명이 일년동안 프로그램을 분석하고 설계하고 코딩하고 테스트할지 모른다. 이럴 경우 이 프로젝트는 12 Man Month의 노력이 투입된 것이다. 그런데 프로젝트 관리자는 타사의 경쟁 제품이 두 달 후에 출시될 예정이라는 불행한 소식을 듣게 된다. 해법은 무엇일까? 1975년 당시 브룩스를 제외한 대부분의 프로젝트 관리자들은 이렇게 말했을 것이다. “12명의 뛰어난 프로그래머를 스카우트하고 일을 12등분해서 그 사람들에게 나눠 주십시오. 그리고 한 달 안에 일을 마치라고 주문하면 아마 해결될 것입니다. 왜냐하면 12명이 한달 동안 일을 하니까 한 명이 12개월 일하는 것과 동일한 12 Man Month가 투입되었기 때문입니다.”
하지만 브룩스는 다른 결론을 얻었다. “지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다.” 일명 브룩스의 법칙(Brook’s Law)이다. OS/360을 개발하면서 브룩스는 “1 개발자 * 12 개월 == 12 개발자 * 1 개월”이 아니라는 것을 몸소 깨달았다. 개발자를 추가하면 할수록 그들 사이에 미팅, 인터페이스 합의, 이메일 송수신 등과 같은 커뮤니케이션 비용이 월등히 증가하기 시작했다. 또한 커뮤니케이션 오류로 일이 잘못 진행되는 경우도 빈번히 생겼고 그럴 때마다 원상태로 수정하는 추가 작업들이 발생하였다. 이런 요인으로 추가 인력이 투입될수록 프로젝트가 지연되는 현상을 겪게 된 것이었다. 전문적으로 말하면, 개발자가 N명이라면 N만큼 개발자가 일하는 양이 늘어나지만 N의 제곱만큼 프로젝트가 복잡해지기 때문에 결국 시간 내에 일을 끝낼 수 없다는 것이다.
따라서 지연되는 프로젝트를 원래 스케쥴대로 진행하려면 인력을 더 추가하는 것이 아니라 “개발하기로 약속했지만 아직 완성되지 못한 기능”을 없애는 것이 합리적인 방법이며 프로젝트의 범위(scope)를 조절함으로서 스케쥴을 제어해야 한다고 주장했다.
브룩스의 법칙 외에 “두번째 시스템 효과(Second System Effect)”, “프로토타입(prototype)”, “커뮤니케이션(Communication) 중시” 등의 원리들은 30년이 넘는 지금 들어도 충분히 공감되는 소프트웨어 공학의 원리를 제시했다.
“두번째 시스템 효과”란 엔지니어가 두번째로 만드는 시스템은 가장 위험한 시스템이 될 수 있다는 가설이다. 왜냐하면 첫번째 시스템을 작고 성공적으로 개발했던 경험이 있는 엔지니어는 두번째 시스템에서는 그 성공을 뛰어넘을 욕심으로 추가 기능을 많이 포함한 공룡 같은 시스템을 만들려는 경향이 있기 때문이다. 브룩스는 성공적인 IBM 70XX 시리즈의 운영 체제 이후에 OS/360을 개발하면서 그 사실을 깨닫게 되었다. OS/360 은 공룡과 같은 두번째 시스템이었다. 이것은 시스템을 유지보수하면서 확장시켜 나갈 때도 발생될 수 있는 문제이다.
“프로토타입”은 새로운 종류의 시스템을 개발할 때는 프로토타입(prototype)을 먼저 만들어서 기능과 성능을 시험을 해 본 후 버리고, 두번째로 더 좋은 시스템을 새롭게 만들어 고객에게 주자는 것이다. 이렇게 하면 좀 더 품질이 좋은 시스템을 고객에 전달할 수 있다고 주장하였다.
“커뮤니케이션 중시”란 팀은 가능한 다양한 방식으로 의사소통을 원활히 하고 명확히 해야 프로젝트에서 발생 가능한 재앙을 미리 막을 수 있다는 원리이다. 애매한 일은 반드시 매니저에게 확인 받고 진행해야 틀리게 생각했던 작업들의 진행을 방지하여 재작업의 요소를 제거해야 한다는 것이다.
은총알은 없다.(No Silver Bullet) 진정?
브룩스는 1987년에 “은총알은 없다(No Silver Bullet)”라는 소프트웨어 엔지니어링 에세이를 발표했는데 많은 논쟁을 불러 일으켰다. 이 글은 1995년에 출간된 “The Mythical Man Month”의 20주년 기념 서적에 포함되기도 하였다. 그는 소프트웨어 개발 생산성을 한번에 해결해 줄 만한 은총알과 같은 기술이나 개발 방식은 더 이상 없을 것이라고 선언했다. 하드웨어의 발전속도를 소프트웨어 개발 속도가 따라 잡지 못하는 현실을 소프트웨어의 복잡성과 관련해서 설명하였다. 소프트웨어 개발의 복잡도는 두 가지 종류가 있는데, 첫번째로는 제거가 가능한 비본질적(accident)인 복잡성이 있다. 이것은 소프트웨어 개발 방식이나 기술 자체가 덜 성숙하거나 잘못된 경우에 생긴다. 이런 복잡도는 IT 과학자들이 노력하면 복잡성을 제거할 수 있다. 예를 들어 불편한 어셈블리 언어 때문에 개발 생산성이 떨어진다면 C나 자바와 같은 고급 언어를 개발하면 해결된다.. 두번째로는 본질적(essential)인 복잡도가 있다. 브룩스는 풀어야 할 문제 자체가 복잡하다면 그 문제가 사라지지 않는 이상은 복잡도는 줄 지 않는다고 주장했다. 시간이 가면 갈수록 고객들은 복잡한 기능들을 요구할텐데 이런 요구 자체는 단순화될 수 없다는 것이다.. 본질적인 복잡도는 대폭 완화될 수 없기 때문에 소프트웨어 개발 생산성을 높이는 정도에는 한계가 있다는 것이다. 객체 지향이나 재사용 등은 이런 본질적인 복잡성을 줄이지 못하는 실패한 은총알이라 주장했다. 그의 글은 많은 소프트웨어 공학자들이 소프트웨어 생산성을 향상시키기 위해 근본적으로 해결되어야 할 선행 이론들에 대해 관심을 갖게 만들었다.
이 주장은 많은 논쟁을 불러 일으켰고 브래드 콕스(Brad Cox)는 “No Silver Bullet Revisited”라는 에세이에서 브룩스가 말한 본질적인 복잡성도 비본질적인 복잡성들로 분리하여 해결하면 충분히 생산성을 높일 수 있다는 반론을 제기하였다.
누가 소프트웨어의 심장을 만들었는가
인간의 편에 선 소프트웨어 개발의 원리
위의 내용에서 보다시피, 그는 개발자들의 심리와 개발 문화, 커뮤니케이션을 기반으로 소프트웨어 프로젝트의 성과를 분석한 선구자였다. 브룩스의 법칙은 개발자들이 증가할수록 커뮤니케이션의 복잡도가 증가하여 프로젝트의 복잡도가 증가한다는 사실을, “두번째 시스템 효과”는 성공적인 시스템의 후속작을 만들때의 엔지니어의 과대 욕망이 일으키는 프로젝트 실패의 요소를, “커뮤니케이션의 중요성”은 커뮤니케이션 오류로 인해 발생하는 프로젝트의 지연 요소를 지적하고 있다. 브룩스는 단지 뛰어난 능력을 가진 사람들의 노력만으로는 프로젝트를 성공시킬 수 없다는 사실을 객관적인 자신의 경험으로 입증하였다. 기술이 아니라 인간의 편에서 소프트웨어 프로젝트를 투시했다.
그의 성과는 이어지는 소프트웨어 공학 이론들에 큰 영향을 끼쳤다. 베리 보엠의 소프트웨어 개발의 경제학에는 생산성 변수로서 인간의 요소들이 포함되었고, 제럴드 와인버그(Gerald Weinberg)는 인간의 심리학에 근거한 소프트웨어 개발 문화를 역설했으며 켄트 벡은 인간의 용기를 프로그래밍의 주요 덕목으로 내 세운 XP를 개발하였다.
그가 세운 소프트웨어 공학의 원리들은 소프트웨어 프로젝트를 면밀히 관찰하여 데이터를 수집하고 분석하여 공학적인 원리들을 세우는 소프트웨어 공학이라는 학문이 하드웨어의 속도를 못 따라 잡는 소프트웨어의 개발에 꼭 필요하다는 웅변하였다.
안타깝게도 그는 가상 세계에 관심이 많다.
1965년 IBM을 떠난 그는 North California, Chapel Hill 대학에 컴퓨터 공학과를 세우고 교수가 되었다. 지금까지 20년 동안 활발한 연구를 진행하고 있으며 현재 3차원 인터액티브 컴퓨터 그래픽과 가상 세계(Virtual World), 원자 그래픽(Molecular Graphics)에 관심이 많다. 안타까운 것은 그가 소프트웨어 공학이 아니라 가상 세계에 연구를 집중하고 있다는 것이다. 1975년에 보인 그의 통찰력을 현재의 소프트웨어 공학에서도 찾아 볼 수 있었으면 하는 아쉬움이 있다.
그는 운영 체제의 발전과 소프트웨어 공학에 기여한 공로로 1999년에 튜링상을 수상하였다.
“소프트웨어 공학(Software Engineering)”이라는 용어는 1968년 NATO 소프트웨어 공학 컨퍼런스에서 공식화되었고 그때 이후로 널리 사용되고 있다. 소프트웨어 공학의 정의는 다양하지만 IEEE Std 610-1990에서 정의한 것은 다음과 같다[4].
“(1) 소프트웨어의 개발, 운영, 유지보수를 할 때 체계적, 규율적, 정량적인 접근 방식을 응용한 것(The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software)
(2) (1)에 대한 연구”
관련 인물들
1) 베리 보엠
참고 자료
[1] 프레드릭 브룩스의 “Man Month 의 신화”
Frederic P. Brooks, “The Mythical Man Month : Essays on Software Engineering”, Addsion-Wesley, 1975 (1995년에 20주년 기념판이 출간됨)
[2] 프레드릭 브룩스의 “은총알은 없다” 원문
[3] 브래드 콕스의 “’은총알은 없다’를 재고하며” 원문
[4] IEEE의 The Software Engineering Body of Knowledge(SWEBOK)
[5] 위키피디아의 프레드릭 브룩스 페이지
[6] 프레드릭 브룩스 홈페이지
TAG :
이전 글 : 엑셀 실무 활용노트(1) : 시간을 올림, 내림하기
최신 콘텐츠