 |
| 개발자 책꽂이 |
소프트웨어 예측을 다루는 책 2선 |
|
정확한 예측과 추정은 분야에 무관하게 늘 어려운 문제다. 일례로 아름다운 시드니 오페라 하우스 건립 당시 완공 예정 연도는 1963년에, 건축 비용은 700만 달러였지만, 실제로 규모 축소 후 개관 시점은 1973년이었으며 비용은 무려 1억 2000만 달러가 투입되었다. 1976년 몬트리올 하계 올림픽 주 경기장 스타디움 건설 당시 총 비용이 1억 2000만 달러를 예상했지만, 지붕 건설에만 1억 2000만 달러가 들었고, 결국 지붕 없는 경기장으로 올림픽을 치루고 나서 1989년에야 공사가 마무리된다.
소프트웨어 개발 부문에서도 예측은 어렵다. 소프트웨어 개발 과정에서 초기 예측이 정확하게 맞아떨어져 끝까지 가는 경우는 정말 찾기 어렵다. 마이크로소프트 워드 포 윈도우 버전 1.0은 원래 프로젝트 완료 기간을 1년으로 예상했지만, 결국 5년이 걸리고 말았다. 덴버 공항에서 야심차게 진행되었던 자동 수하물 처리 시스템은 1년 가까이 공항 개장을 지연시켰으며, 비효율적인 운영에 매달 100만 달러씩 들어가는 유지보수비를 감당하지 못하고 결국 폐기되는 운명에 처했기에, 500% 일정을 넘어서는 정도는 애교로 봐줄 만하다.
하지만 예측이 어렵다고 넋을 놓고 되는 대로 소프트웨어를 개발하기도 난감한 상황이다. 세상만사 독불장군이 없으므로 작게는 팀원 사이에 크게는 회사끼리 공동 작업을 해야 하기 때문이다. 즉, 예측을 하지 못한다면 계획도 잡지 못하는 상황이 벌어진다. 그렇다면 개발자 관점에서 예측을 어떻게 바라봐야 할까? 이번 서평에서는 전통적인 예측 기법과 애자일 예측 기법을 모두 살펴봄으로써 예측에 대한 시각을 넓히는 데 도움을 주고자 한다.
1번 타자
소프트웨어 추정: 그 마법을 파헤치다
스티브 맥코넬 지음, 안재우 옮김, 정보문화사 2007년 출간
정확도 문제가 있지만, 우리 모두는 뭔가를 예측하고 추정하는 과정에 타고난 선수들이다. 두뇌 회로에 살아 남기 위한 본능이라는 이름으로 탑재된 이런 신비한 능력을 스티브 맥코넬은 ‘마법’이라고 부른다. 독자들의 호기심을 북돋우기 위해 이 책 2장 ‘당신은 얼마나 뛰어난 추정자인가’에 나오는 퀴즈를 정리해 보았다. 가장 낮은 추정 값과 가장 높은 추정 값을 모두 예측해 보기 바란다.
- 태양 표면 온도 [낮은 추정값] [높은 추정값]
- 상하이 위도 [낮은 추정값] [높은 추정값]
- 아시아 대륙 넓이 [낮은 추정값] [높은 추정값]
- 알렉산더 대왕이 태어난 해 [낮은 추정값] [높은 추정값]
- 2004년 미국 총 통화량 [낮은 추정값] [높은 추정값]
- 5대호 총 부피 [낮은 추정값] [높은 추정값]
- 타이타닉 전 세계 흥행 수익 [낮은 추정값] [높은 추정값]
- 태평양 해안선 총 길이 [낮은 추정값] [높은 추정값]
- 1776년 이래 미국에서 출간된 서적 수 [낮은 추정값] [높은 추정값]
- 지금까지 기록된 가장 무거운 흰긴수염고래 무게 [낮은 추정값] [높은 추정값]
딱 보는 순간 숨이 턱 막히겠지만 그래도 우리는 어떤 수를 써서든 추정을 해낸다. 아마 독자들도 문제를 푸는 도중에 추정치를 최대로 정확하게 만들어야 한다는 압박감을 경험했을 것이며, 이게 바로 우리가 예측한 추정값이 어마어마하게 빗나가게 하는 주요 원인이 되었을지도 모른다. 빡빡한 범위 대신에 느슨한 범위를 잡아 아주 낮은 추정값과 아주 높은 추정값을 적용하면 90% 확신도 가능하겠지만, 소프트웨어 제작 기간 범위를 묻는 상사에게 0부터 무한대라고 답했다가는 짐부터 꾸려야 할지도 모른다.
스티브 맥코넬은 이 책에서 추정과 예측에 대한 장벽을 정공법으로 돌파하려고 시도한다. 1부에서는 정확한 추정의 가치를 설명한 다음 추정 오류가 어디서 등장하는지, 추정에 영향을 미치는 요소가 무엇인지를 소개한다. 2부에서는 계산, 카운트, 교정/이력 자료, 개별 전문가 판단, 분해/재구성, 유추, 프록시, 집단 내 전문가 판단, 소프트웨어 도구를 포함한 기초적인 추정 기법을 설명한다. 3부에서는 규모 추정 과정에서 발생하는 문제점, 공수 추정 과정에서 발생하는 특별한 문제점, 일정 추정에서 발생하는 문제점, 계획 매개 변수, 추정 제시 스타일, 정치적 문제/협상/문제 해결을 설명한다.
전반적인 책 구성은 스티브 맥코넬이 집필한 『Rapid Development: 프로젝트 쾌속 개발 전략』(스티브 맥코넬 지음, 박재호/이해영 옮김, 2003년 한빛미디어 펴냄) 중에서 3부 '우수 개발법'과 아주 비슷하므로, 기존 『Rapid Development』를 읽어봤던 독자라면 쉽게 적응이 가능할 것이다. 각 장 처음에 예측 대상, 프로젝트 규모, 개발 단계, 반복/선형, 정확도 등을 일목요연하게 정리해 놓았으므로 실전에 필요한 내용을 바로 파악할 수 있다. 상당수 내용이 『Rapid Development』와 겹치긴 하지만 전문적인 추정과 예측 내용을 다루려다 보니 수학적인 개념, 수학 공식, 그래프 등이 본문 여기저기에 출현하므로 가벼운 마음으로 읽기에는 조금 어렵지 않을까 하는 걱정이 앞선다.
참고로 이 책은 2007년 졸트 상 수상작이며, 애자일 관련 서적과 치열한 경합을 벌이면서 ‘Books General’ 부문 ‘Productivity Winner’로 뽑혔다.
2번 타자
불확실성과 화해하는 프로젝트 추정과 계획: 규모 추정, 우선순위, 일정 배치
마이크 콘 지음, 이병준 옮김, 인사이트 2008년 출간
축구 경기를 TV로 생중계할 때 방송 편성표를 작성하는 업무를 맡았다고 가정해 보자. 전후반 45분에, 휴식 시간 10분에서 15분을 넣어 100분 정도로 예상하면 바로 상사에게 한 소리를 들을지도 모른다. 축구 시작 전에 소개하는 시간, 축구 경기 진행 중에 벌어지는 'added time', 'extra time', 'stoppage time', 'injury time', 'loss time', 게다가 큰 경기 뒤에 중요한 경기 장면 분석이나 선수 인터뷰까지 들어가면 100분이 아니라 두 시간이 넘어갈지도 모른다. 여기서 100분을 이상적 시간이라고 하며, 두 시간을 실제 경과 시간이라고 한다.
소프트웨어 개발 시간을 예측할 때는 이 두 가지 시간 개념을 잘 구분해야 한다. 추정 값이 1개월이라면 개발자는 이상적 시간을, 관리자는 실제 시간을 생각할 가능성이 상당히 높다. 결국 개발자와 관리자 사이에 예측 추정값을 놓고 팽팽한 긴장감이 고조된다. 그렇다면 이상적 시간과 실제 경과 시간 개념을 종합해 프로젝트 계획 과정에 반영할 방법은 없을까?
(사람들이 흔히 저지르는 착각이긴 하지만…) 예측, 추정, 계획이라는 낱말과는 거리가 상당히 멀 듯이 보이는 애자일 분야에서 “프로젝트 추정과 계획”이라는 제목이 붙은 책이 나왔다. 이 책은 제목에서 이미 잘 드러나 있듯이 애자일 기법의 전매 특허인 스토리, 이터레이션, 릴리스 계획을 중심으로 추정, 계획, 배치, 추적과 관련한 설명을 차근차근 전개하므로, 이 책을 읽기 전에 애자일 기법에 대한 기초적인 지식을 습득하는 편이 좋겠다. 확실히 전통적인 소프트웨어 공학 기법과 비교해 애자일 기법은 불확실성이 내재된 프로젝트에 강한 측면을 보이는데, 이런 이면에 숨겨진 비밀인 애자일스러운 추정과 계획 방법을 알고 싶은 독자에게 딱 맞는 책이라고 보면 되겠다.
이 책 목차를 보면 1부(문제와 목표)에서는 앞서 언급한 이상적 시간과 실제 경과 시간의 개념 차이점 분석부터 시작해서, 실패하는 계획법의 특징과 애자일 접근법과 같은 일반적인 이야기를 소개한다. 2부(규모 추정)로 들어가서 스토리 점수와 이상적 작업일을 사용해 규모를 추정하는 방법, 추정과 재추정 기법, 스토리 작업일을 다룬다. 3부(가치 창조를 위한 계획 과정)에서는 우선 순위 결정, 재정적/선호도에 따른 우선 순위, 사용자 스토리 분할을 다룬다. 4부(일정 배치)에서는 릴리스 계획 수립 기법, 이터레이션 계획 과정, 이터레이션 길이 선정, 속도 추정, 불확실성에 대한 버퍼링 계획, 다중 팀 프로젝트 계획을 다룬다. 5부(추적과 의사소통)에서는 릴리스 계획 감시, 이터레이션 계획 감시, 계획과 소통을 다룬다. 마지막 6부(애자일 계획이 통하는 이유)에서는 잘 어울리지 않을 듯이 보이는 애자일 기법에서 추정과 계획이 통하는 이유를 설명한다.
책 전반에 걸쳐 수영 기록 사이트인 SwimStats 웹 사이트를 구축하는 과정에 애자일 기법을 어떻게 적용하는지 일관성 있게 설명하므로, 어떻게 보면 책 전체가 거대한 사례 연구라고 봐도 무방하겠다. 하지만 목차에 맞춰 예제를 보여주므로 (예제 관점으로 바라보면) 중간에 흐름이 끊어진다는 느낌이 들지도 모르겠다. 이렇게 독자가 느끼는 어색함을 해소하려고 이 책은 7부(사례 연구)에 Bomb Shelter Studio라는 가상의 보드 게임 개발 회사 예를 들어 제품 기획 단계부터 구현 완료 시점까지 소설식으로 이야기를 풀어주는 센스를 발휘한다. 흔히 이런 부류의 책에서 볼 수 있는 체크리스트와 글머리 기호를 사용해서 따분하게 이론을 전개하는 대신 표, 그림, 일화 등을 잘 곁들여 독자들이 시종일관 재미있게 읽도록 만든 점도 높이 살 만하다.
켄트 백이 추천사에서도 언급했지만 이 책은 ‘계획은 필요악’이라는 사상을 넘어서 ‘계획은 가치를 추구하는 행위다’라는 사상을 전파하는 미덕을 발휘한다. 솔직히 요구사항, 설계 문서, 프로그램에 파묻히는 바람에 계획이 누구를 위한 활동이었는지 우리 모두가 잊어버리고 있었다. 바로 개발자 자신, 동료, 회사, 고객을 위한 가치 추구가 계획을 수립하는 가장 큰 목표가 아니었던가?
힌트 한 가지
전혀 다른 진영에 속한 지은이가 쓴 두 책을 읽는 도중에 상호 보완적인 요소가 많다는 사실을 발견했을 뿐만 아니라, 실제로 일부 공통적인 설명도 발견할 수 있었다. 『불확실성과 화해하는 프로젝트 추정과 계획』 1장을 보면 비록 폭포수라는 순차적인 개발 방법이라는 단서를 달고 있지만 스티브 맥코넬이 소개한 ‘불확실성 원추(cone of uncertainty)’ 그래프와 설명을 예로 제시하고 있다. 반면에 『소프트웨어 추정』을 읽다 보면 이전 프로젝트와 비교하는 방법, 스토리 점수, 초과 근무를 바라보는 시각, 사람을 중심으로 문제 해결 접근 방법과 같이 애자일 쪽에 가까운 내용도 제법 보인다. 결국 전통적인 소프트웨어 개발 방법론이든 애자일 방법론이든 예측과 추정 과정에서 초기 단계에 불확실성이 내재되어 있다는 사실은 이견의 여지가 없다. 어떤 수단을 동원해 불확실성을 최대한 감소시켜서 위험을 줄이느냐가 가장 중요하다.
소프트웨어 분야에서 은총알과 만병통치약은 절대로 존재하지 않기에 한 쪽에 통한 방법이 다른 쪽에도 그대로 통하리라는 순진한 생각은 처음부터 버리는 편이 좋겠다. 다시 말해 규모가 작고 빠르게 변하는 프로젝트와 규모가 크고 요구 사항이 비교적 변하지 않는 프로젝트는 예측과 추정 방식이 상당히 다르므로, 각각의 특성을 파악하기 위해서라도 두 책을 동시에 읽어보기를 권한다.
이 문서 북마킹 하기
|
박재호 
