 |
| 개발자 책꽂이 |
고전 탐험 3탄: 소프트웨어 공학 서적 2선 |
|
초창기 소프트웨어 제작은 수학이나 전자 공학 쪽의 접근 방법을 따랐다. 하지만 세월이 흘러가며 점차 알고리즘, 자료 구조, 프로그래밍 언어라는 독자적인 컴퓨터 과학이 태동하기 시작했고, 규모가 커지기 시작하면서 소프트웨어에 공학을 결합한 소프트웨어 공학이 탄생했다. 21세기도 8년이나 지난 요즘은 개발자들 사이에서 소프트웨어를 공학적으로 개발한다는 사실 자체가 당연하게 받아들여질지 몰라도, 1980년대까지만 하더라도 소프트웨어에 공학을 접목한다는 개념은 일반 개발자에게 상당히 낯설었다. 이번 연재에서는 과거를 회상하는 의미에서 소프트웨어 공학이라는 주제를 다루는 고전을 두 권 선택해보았다.
1번 타자 : 프로그래밍 심리학
Gerald M. Weinberg 지음, 조상민 옮김, 인사이트 2008년 출간
집에 있는 이 책 원서 판권 정보를 살펴보면 1971년에 초판이 시중에 등장했고 계속해서 기존 내용에 주석을 붙인 25주년 기념판이 1998년에 나왔다. 책이 나온 지 거의 40년이 다 되어 가는 시점에서 이 책을 평가하자면 여전히 흥미롭고 재미있고 종종 뒤통수를 친다. 이런 책이 있기 때문에 고전의 가치는 계속해서 이어진다.
그렇다면 책 제목인 프로그래밍 심리학을 뜯어보자. 요즘 같이 학제별 통합 연구가 활발한 분위기에서도 ‘프로그래밍’과 ‘심리학’을 결합한 책을 기획하겠다고 말하면 도시락 싸 들고 다니면서 말릴 상황인데, 40년 전에는 어땠을까? 출판사에 원고 뭉치를 들고 가서 퇴짜를 맞은 와인버그 모습이 떠올라 책을 읽다가 낄낄거리지 않을 수 없었다.
‘프로그래밍’ 관점에서 ‘심리학’을 다루는 이 책은 소프트웨어는 사람이 만들며 사람이 사용한다는 기본적인 사실을 다시 한번 생각하게 만들어주므로 사람이 바뀌지 않는 이상 계속해서 유효한 내용을 담고 있다. 따라서 본문 중에 PL/I 코드, 메인프레임, 포트란 이야기가 나온다고 지레 겁먹지 말자.
‘프로그래밍 심리학’은 크게 4부로 이뤄져 있는데, 첫 3부가 프로그래밍을 각각 인간 행위, 사회 활동, 개인 행위로 구분해서 조감한다. 그리고 4부는 프로그래밍 도구를 소개한다. 이렇게 재미있는 주제가 등장했으니, 독자들을 위해 하나씩 뜯어보기로 하자.
‘인간 행위로서 프로그래밍’을 다루는 1부는 사람이 만든 인위적인 창조물인 프로그래밍 언어를 놓고 프로그램을 읽는 과정에서 발생하는 한계, 좋은 프로그램을 만드는 요건, 복잡한 인간 행동으로서 프로그래밍을 연구하는 방법을 설명한다. 와인버그가 1부 주석에서도 강조하지만 사람에게 주의를 기울이는 관리자가 좋은 결과를 얻는다는 기본 규칙을 모르는 사람이 많다. 이런 현상은 사람들이 코드 모듈처럼 행동해서 상호 대화 없이 각자 맡은 부분만 완성해 합치면 프로그램이 돌아가야 한다는 강박 관념이 만든 폐해다.
‘사회 활동으로서 프로그래밍’을 다루는 2부는 비공식적인 조직인 그룹으로 프로그래밍을 하는 방법을 먼저 다루고, 공식적인 조직인 팀과 프로젝트로 프로그래밍을 하는 방법을 다룬다. 그룹 프로그래밍에서는 이 책 전반에 걸쳐 가장 큰 논쟁을 불러일으킨 비자아(egoless) 프로그래밍에 대한 설명이 나온다. 팀 프로그래밍에서는 팀 구조, 목표 설정, 팀 리더십, 팀에 있어 위기 상황을 설명한다. 프로젝트 프로그래밍에서는 대규모 프로젝트에서 벌어지는 프로그래밍 활동에 대해 설명한다.
개인적으로 2부에서 가장 흥미로운 내용은 자판기 사건이다. 전산 대기실이 너무 시끄럽다는 항의가 들어와서 전산 대기실에서 자판기를 철수시켰는데, 철수 직후부터 전산 대기실 도우미 업무 부하가 너무 커져서 수습이 불가능한 정도에 이르러 원인을 조사한 결과 자판기라는 결론이 내려졌다. 자판기가 있을 때는 커피를 마시면서 학생들끼리 정보를 자발적으로 교환했지만, 이런 공유의 장이 없어지자 도우미에게 질문이 쇄도했던 것이다.
‘개인 행위로서 프로그래밍’을 다루는 3부는 먼저 프로그래밍 작업의 다양성을 다루고 개인 성격, 문제 해결 능력, 동기 부여, 훈련, 경험과 같은 개인적인 요소를 다룬다. 프로그래밍 작업의 다양성에서는 전문 프로그래머와 아마추어 프로그래머의 차이점, 프로그래밍이 결코 시간을 맞추지 못하는 이유, 프로그래밍 작업 단계를 설명한다. 개인 성격에서는 프로그래머에게 필요한 성격과 테스트 방법을 설명한다. 지능과 문제 해결 능력에서는 프로그래밍에 필요한 지능과 문제 해결 능력에 대한 여러 가지 측면, 테스트 방법을 설명한다. 동기 부여, 훈련, 경험에서는 프로그래밍을 배우고 익히는 방법을 설명한다. 여러분도 100% 정확하지는 않겠지만 MBTI 검사를 통해 프로그래머로서 스스로 자질을 살펴보면 좋겠다.
마지막 ‘프로그래밍 도구’를 다루는 4부는 프로그래밍 언어, 프로그래밍 언어 설계 원칙, 기타 프로그래밍 도구를 다룬다. 프로그래밍 언어에서는 자연어와 프로그래밍 언어를 비교하고, 프로그래밍 언어 설계를 다룬다. 프로그래밍 언어 설계 원칙에서는 프로그래밍 언어 관점에서 중요한 몇 가지 설계 원칙을 다룬다. 기타 프로그래밍 언어에서는 테스팅 도구, 운영체제, 시분할과 배치, 문서화를 다룬다. 4부는 조금 낡은 내용이 많아서 역사적인 지식을 넓힌다는 관점으로 읽어보면 좋겠다.
2번 타자 : 맨먼스 미신
Frederick P. Brooks 지음, 김성수 옮김, 케이앤피북스 2007년 출간
집에 있는 이 책 원서 판권 정보를 살펴보면 1975년에 초판이 시중에 등장했고 계속해서 브룩스가 1986년에 IEEE Computer 지에 기고한 소프트웨어 공학 관련 논문인 ‘No Silver Bullet’을 추가한 20주년 특별판이 1995년에 나왔다. 그리고 나서도 세월이 흘러 이 책이 나온 지 벌써 사반세기가 다 되어가고 있지만, 이 책에서 설명하는 핵심은 여전히 유효하고 앞으로도 획기적인 패러다임 전환이 없는 한 계속해서 유효하리라는 생각이다.
‘맨먼스 미신’은 브룩스가, 달 탐험을 위한 아폴로 프로젝트를 능가하는 연인원과 비용을 쏟아 부은 IBM 360 메인프레임 프로젝트를 총괄 지휘하면서 하드웨어 제작 비용보다 소프트웨어(OS) 제작 비용이 더 커지는 현상을 목격하면서 받은 충격을 회고 형식으로 작성한 책이다.
이 책이 나오기 전에는 소프트웨어는 하드웨어를 동작시키기 위한 펌웨어 수준에 불과했지만, 이 책이 나온 다음부터 소프트웨어는 (최소한 공학적인 측면에서) 하드웨어와 결별하고 공학 분야에서 독자적인 길을 걷게 되었다고 말해도 결코 맹목적인 찬사나 부풀림은 아니다.
브룩스가 ‘맨먼스 머신’에서 처음으로 선보인 여러 가지 개념 중에 몇 가지를 요약 정리하는 방식으로 이 책에서 다루는 핵심 사상을 함께 살펴보자.
맨먼스 미신: 브룩스 법칙으로 알려진 이 개념은 뒤쳐진 소프트웨어 프로젝트에 사람을 더 넣으면 더 늦어진다는, 그 당시로서는 비밀에 가까운 발견이었다. 요즘은 소프트웨어 개발 과정에서 사람 사이에서 일어나는 의사 소통 문제, 업무 분장, 업무 교육에 들어가는 시간 부하를 고려하지만, 소프트웨어 개발 초창기만 하더라도 이런 문제에 대해 알려진 바가 거의 없었다. 브룩스는 사람 숫자가 늘어나면 의사 소통 채널이 늘어나기 때문에 인력 충원 효과는 점점 줄어들다가 어느 순간부터 역효과를 내기 시작한다고 설명한다.
두 번째 시스템 효과: 첫 번째 시스템을 성공리에 만들고 여세를 몰아 두 번째 시스템을 만들 때, (시간 제약으로) 첫 번째 시스템에서 못다한 온갖 추가 기능을 구겨 넣기 위해 과도한 엔지니어링이 들어간다는 법칙이다.
진도 측정: 브룩스는 아주 의미심장한 질문(“대규모 소프트웨어 프로젝트를 1년 뒤쳐지게 만드는 방법은?”)을 하나 던진다. 그리고는 직접 대답(“한번에 하루씩”)한다. 여러 분야에서 조금씩 샌 일정이 결국 최종적으로 엄청난 지연을 초래한다는 사실을 지적한다.
개념적인 통합: (마이크로소프트 식으로 표현하자면) 사용자 경험을 높이기 위한 시스템은 개념적인 통합이 필수며, 구현에서 아키텍처를 분리해야 한다는 법칙이다. 개념적인 통합은 또한 린 소프트웨어와 관련이 있는데, 복잡한 기능이 들어갈 경우 사람들이 배우고 익히는 과정에서 너무 많은 시간이 필요하므로 사용자 경험을 높이려면 기능을 줄여야 한다는 내용이다.
파일럿 시스템 개념: 새로운 시스템을 설계할 때, 개발팀은 한번 쓰고 버릴 시스템(즉 프로토타입)을 개발해야 한다는 법칙이다. 프로토타입을 토대로 두 번째 만든 훨씬 더 똑똑한 소프트웨어를 고객에게 전달해야지, 고객 불만도 줄이고 시스템과 회사 평판도 높일 수 있다.
상호 대화: 재앙을 막기 위해 프로젝트에 참여하는 모든 팀원은 다양한 수단으로 의사 소통이 가능해야 한다는 법칙이다. 사소한 오해가 쌓여 개발하는 시스템 전체에 타격을 입힐 수 있다.
코드 동결과 시스템 버전 관리: 특정 날짜를 잡아서 더 이상 시스템에 대한 변경을 막고 코드를 동결해버리고, 추가 요청은 다음 버전에 반영하도록 만드는 법칙이다. 마이크로소프트 사가 사용하는 출시 관리 기법을 생각하기 바란다.
이런 경험적인 법칙이 1970년대에 이미 등장했다니 한마디로 놀랄 따름이다. 요즘 사용하는 화려한 개발 방법론과 소프트웨어 공학 이론 앞에서 이런 법칙이 낡아보일지 모르겠지만, ‘맨먼스 미신’을 읽으며 소프트웨어 공학 원조가 누구인지 차근차근 따져보자. “옛것을 익히고 이를 미뤄서 새것을 안다”라는 온고지신이라는 옛말도 있지 않던가?
20주년 특별판 부록에 실린 ‘은총알은 없다’(No Silver Bullet)는 http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf(영문)에서 온라인으로 읽을 수 있다. 소프트웨어 개발 효율을 100배 높여준다는 획기적인 만병 통치약을 선전하며 팔러 다니는 현대판 약장수와 소프트웨어 개발자를 언제든지 교체 가능한 단순한 기계 부품으로 여기는 일부 몰지각한 관리자들에게 따끔한 일침을 가하는 통쾌한 수필이므로 ‘맨먼스 미신’을 읽지 않더라도 ‘은총알은 없다’는 반드시 읽어보기를 권한다.
이 문서 북마킹 하기
|
|
|
|
|
|
박재호 
