2008년 07월 27일
당신의 소프트웨어 프로젝트 10개의 위험신호
C# 프로그래머인 제프 앳우드(Jeff Atwood)의
당신의 소프트웨어 프로젝트 10개의 위험신호
C# 프로그래머인 제프 앳우드(Jeff Atwood)가 운영하는코딩호러(www.codinghorror.com)라는 블로그는 프로그래머에게 도움이 될 만한 이야기들을 많이 담고 있다. 그중에는 “프로그래밍 탑 10 리스트 6개(Top 6 List of Programming Top 10 Lists)”라는 게시물이있는데, 앳우드 자신이 작성한 목록이 아니라 다른 블로거/프로그래머가 작성한 10대 목록 중에서 가장 흥미로운 것으로 6개를뽑아서 정리해 놓은 것이다. 그 중에서 두 개의 목록을 골라서 이 글의 소재로 삼아보았다.
이 가운데 먼저 살펴볼 목록은 마이크로소프트에서 일하는 데어 오바산조(Dare Obasanjo)라는 프로그래머가 작성한“당신의 소프트웨어 프로젝트가 망했음을 보여주는 10개의 신호(Top 10 Signs Your Software Projectis Doomed)”라는 제목의 목록이다. 그가 제시한 목록은 다음과 같이 구성되어 있다.
1. 처음 버전에서 너무 많은 것을 이루려고 하기(Trying to do too much in the first version)
2. 증명되지 않은 기술에 전적으로 매달리기(Taking a major dependency on unproven technology)
3. 든든한 재정적 지원을 받고 있는 회사 내부의 프로젝트와 경쟁하기 (Competing with an existinginternal project that is either a cash cow or has powerful backers)
4. 모자란 개발자 수 (The team is understaffed)
5. “복잡한 문제는 복잡한 해결책을 요구한다” (“Complex problems require complex solutions”)
6. 스케줄 겁쟁이(Schedule Chicken)
7. 범위의 증가(Scope Creep)
8. 두 번째 시스템 신드롬(Second System Syndrome)
9. 진입전략의 부재
10. 해결책을 알지 못하는 문제와 씨름하기
데어 오바산조의 목록
5번 항목에 있는 “복잡한 문제는 복잡한 해결책을 요구한다”는 말이 의미하는 것은 이렇다. 프로젝트를 진행하는 사람들중에는 간혹 ‘복잡한 해결책’을 구현하는 기쁨에 취한 나머지 해결해야 하는 문제보다는 문제의 ‘복잡성’ 자체를 목표로 삼는사람이 있다. 문제를 일부러 복잡하게 만들어 놓고 기뻐하는 것이다. 이것은 매우 위험한 경향이다.
성공을 지향하는 프로젝트는 언제나 간결하고 안전한 방향을 취해야 한다. 프로젝트가 복잡한 해결책을 필요로 하는 상황에빠졌다면, 그 프로젝트는 이미 실패의 길로 접어든 것과 다름없다. 문제를 단순하고 명쾌하게 정의하며, 최대한 해결 가능한 문제를목표로 설정하는 것은 성공적인 프로젝트를 수행하기 위한 발걸음의 첫 번째이다.
6번 항목에 있는 ‘스케줄 겁쟁이’라는 표현은 오바산조가 아니라 피터 클락(Peter Clark)이라는 프로그래머가 처음사용한 것이다. 이것은 프로젝트 일정의 지연을 초래하는 나쁜 소식을 입 밖에 꺼내기 두려워하는 사람들의 심리를 지칭한다.프로그래머들은 종종 자신의 개발 일정이 설계에서의 실수나 치명적인 버그 때문에 지연되는 것을 말하지 않는다. 그들이 사용할 수있는 핑계거리가 얼마든지 널려 있기 때문이다.
예컨대 사용자 인터페이스를 개발하는 사람이 GUI의 겉모습을 다듬을 시간이 필요하다고 말하는 것은 사실 설계상의 심각한문제나 치명적인 버그를 감추기 위한 변명일 가능성이 높다. 서버의 모듈을 구현하는 개발자가 네트워크 관리팀의 지원이 없어서모듈을 테스트하지 못했다고 말하는 것은 사실 자신의 일이 일정에 맞춰서 진행되고 있지 않다는 사실을 감추는 핑계에 불과할 수도있다.
이러한 변명과 핑계는 대개 사소한 수준이지만 그들이 여러 사람들을 통해서 누적되면 프로젝트 전체 일정을 위기에 빠뜨릴 수도있다. 문제가 생긴 당시에 솔직히 보고되었으면 유연하게 해결되었을 지도 모르는 문제들이 ‘스케줄 겁쟁이’들의 소심한 태도 때문에큰 문제로 확대되는 것이다.
그 다음 항목은 ‘범위의 증가(scope creep)’다. 사실 이것은 어느 정도 불가피하다. 요구사항 분석, 개발,테스트, 출시를 아우르는 소프트웨어 개발 사이클이 3개월이라고 하자. 가장 이상적인 상황에서는 요구사항이 결정되고 나면고정되고, 개발자는 고정된 요구사항을 토대로 소프트웨어를 구현하고, 테스터는 소프트웨어를 테스트한다. 개발과 테스트가 끝나가는무렵을 기준으로 보았을 때 고정된 요구사항은 3개월 전의 시장상황을 반영한다.
경험이 있는 개발자라면 잘 알겠지만,이러한 상황은 현실에 존재하지 않는다. 시장은 하루가 다르게 변화하고, 시장을 반영하는 요구사항도 그에 따라 변화하기 때문이다.프로젝트가 진행되는 도중에 요구사항이 바뀌고 범위가 늘어나는 것은 그래서 어쩔 수 없다. 하지만 모든 일에는 정도가 있는법이다.
프로젝트가 마감일에 가까워질수록 요구사항의 변경과 범위의 증가가 초래하는 비용(cost)은 기하급수적으로 늘어난다. 그리고 그 비용이 어느 지점을 넘어서면 프로젝트 자체의 파국을 초래한다. 프로젝트가 망하는 것이다.
두 번째 시스템 효과
8번 항목인 두 번째 시스템 신드롬은 ‘두 번째 시스템 효과(second-system effect)’라고 불리기도 하는내용이다. 영국 프리미어 축구와 같은 프로 운동경기에 보면 흔히 ‘2년차 신드롬’이라고 말하는 징크스가 있다. 많은 기대를 안고데뷔한 선수가 처음 한 해 동안은 긴장도 하고 해서 잘 적응을 하는 것처럼 보였는데, 2년차가 되면 긴장이 풀리며 슬럼프에빠지는 현상을 지칭하는 표현이다. 소프트웨어에도 이와 비슷한 경향이 있다. 상업적이나 대중적으로 성공을 거둔 소프트웨어가 있다고하자. 그 소프트웨어를 계승하는 새로운 소프트웨어, 즉 후속작이 만들어질 때를 관찰해보면 소프트웨어의 설계가 필요이상으로거창(grandiose)해 지는 경향이 있다.
전편을 뛰어넘겠다는 강박증이 작용하는 탓이다. 그렇지만 ‘복잡한 해결책’의 경우와 마찬가지로 지나친 거창함이란 프로젝트를 실패로 이끄는 확실한 지름길에 불과하다. 언제나 그렇지만, 아름다운 것은 단순한 법이다.
‘두 번째 시스템 효과’라는 표현은 프레드 브룩스(Fred Brooks)가 1975년에 쓴 <신비로운 맨먼스:소프트웨어 공학에 대한 에세이(The Mythical Man-Month: Essays on SoftwareEngineering)>라는 책에서 처음 사용했다. “일정이 늦어지는 프로젝트에 더 많은 개발자를 투입하면, 일정이 앞당겨지는 것이 아니라 더욱 늦어질 뿐”이라는 브룩스의 법칙으로 유명한 그는 이 책에서 IBM 70xx 시리즈가 사용했던 간결하고유연한 운영체제가 360 시리즈의 OS/360으로 넘어갈 때, 새로운 운영체제를 개발하기 위한 프로젝트가 실패를 겪을 수밖에없었던 이유를 분석하여 많은 유용한 법칙을 정리해냈다.
브룩스는 훗날 <신비로운 맨먼스>를 가리켜서 “모든 사람이 이 책을 읽지만, 책을 읽은 다음 행동을 취하는사람은 아무도 없다”고 지적하고, 그런 점에 있어서 이 책은 “소프트웨어 공학의 성경이다”라고 말하며 익살을 부리기도 했다.맞는 말이다. 일정이 늦춰지는 프로젝트에 더 많은 개발자가 투입되는 음울한 풍경을 본 적이 없는 프로그래머가 도대체 어디에있겠는가?
진입전략의 부재
9번 항목인 ‘진입전략의 부재’가 의미하는 것은 간단하다. 오바산조 자신의 설명에 의하면 그는 데모나 프로토타입 버전을 최종 제품으로 바꾸어내기 위한 구체적인 전략이 부재한 상태를 지칭하기 위해서 이 표현을 사용했다.
특히 그는 웹 2.0 시대에 수많은 신생회사들이 매체의 관심을 끌기 위한 목적으로 반짝거리는 데모 프로그램을 만들어내는 것에만 익숙하고, 데모 버전을 유용하고 진지한 제품으로 만드는 전략엔 서투른 점을 지적하고자 했다.
아무리 지금이 최종버전이 없이 베타버전만 존재하는 웹 2.0 시대라고 하지만, 최종 제품에 대한 고민이나 전략을 무시한 채겉모습만 번듯한 데모 버전으로 관심을 끄는 회사나 개발자는 냉정한 의미에서 보면 일종의 사기를 치는 것이다. 그것은 스스로의무덤을 파는 것과 다를 바가 없다. 진정한 제품을 위한 아이디어 없이 데모 버전의 화려한 치장에만 몰두하는 것은 자멸적 행위인것이다.
안드레즈 타일러(Andres Taylor)의 목록
다음으로 살펴볼 안드레즈 타일러(Andres Taylor)의 목록은 오바산조의 목록과 달리 프로젝트가 아니라 개발자에게초점을 맞추고 있다. ‘전문적 소프트웨어 개발자로서 보낸 10년이 나에게 가르쳐준 10개의 사실(Top 10 ThingsThen Years of Professional Software Development Has Taught Me)’이라는 흥미로운제목을 달고 있는 그의 목록은 다음과 같다.
1. 객체지향은 당신이 생각하는 것보다 더 어렵다
2. 소프트웨어 개발에서 어려운 부분은 바로 의사소통이다
3. ‘아니’라고 말하는 것을 배워라
4. 모든 것이 동일하게 중요하다면, 아무 것도 중요하지 않은 것이다
5. 어떤 문제를 지나치게 생각하지 말라
6. 어떤 것에 정말로 깊이 뛰어들어라. 하지만 그것에 사로잡히지 말라
7. 소프트웨어 개발 과정의 다른 면들에 대해서 배워라
8. 당신의 동료가 당신에게 최고의 선생이다
9. 결국 중요한 것은 제대로 작동하는 소프트웨어다
10. 어떤 사람은 멍청이다
여기에도 귀에 익은 말들이 여럿 포함되어 있다. 예컨대 1번 항목인 “객체지향은 당신이 생각하는 것보다 더 어렵다”는수없이 반복된 경구에 해당한다. 그렇지만 여전히 너무나 많은 프로그래머가 자신이 객체지향을 아주 잘 알고 있으며 그것을적재적소에 잘 적용하고 있다고 착각한다.
3번 항목에서 말하는 ‘아니’라고 말하는 법을 배우라는 내용은, 앞에 나온 오바산조의 목록에서 6번 항목에 해당하는‘스케줄 겁쟁이’와 밀접하게 맞물리는 내용이다. 피터 클락과 오바산조에 의하면 모든 프로그래머에게는 자신의 일정이 늦어지고있다는 사실을 감추고 싶어 하는 겁쟁이 기질이 숨어 있다.
그와 비슷한 맥락에서 모든 프로그래머에게는 자신에게 “할 수 있는가?”라고 묻는 사람에게 선뜻 ‘아니’라고 말하지 못하는심리가 존재한다. 아니라고 말하는 것이 왠지 자존심 상하는 것처럼 느껴지기도 하고, ‘예’라고 말함으로써 자신의 능력을 뽐내고싶기도 하고, 자기는 아니라고 대답했는데 다른 사람이 일을 해결할까봐 두려워하기도 하는 등 프로그래머의 심리는 그런 질문 앞에서복잡하게 반응하기 때문이다.
이렇게 ‘아니’라고 말하지 못하는 심리는 경험이 부족한 초보일수록, 혹은 자기 실력에 대한 확신이 부족한 사람일수록 더욱 강하다. 자신의 실력을 객관적으로 인식하는 능력이 떨어지기 때문이다.
프로젝트 관리자나 PM이 개발자에게 “할 수 있는가?”라고 물을 때에는 무조건적인 긍정을 원하는 것이 아니다. 그들이원하는 것은 납득이 가능한 근거와 이유를 동반한 대답이다. 비즈니스의 현장에서는 근거 없는 긍정이 근거 없는 부정보다 더나쁘다. 책임감이 있는 프로그래머란 이러한 즉자적인 심리적 반응과 싸워서 이길 줄 아는 사람이다. 신중하게 ‘아니’라고 말할 줄아는 사람이 장기적으로는 주변의 신뢰를 쌓는 사람임을 아는 것이다.
주관적인 자존심, 경쟁심, 두려움과 같은 심리적인 요소 때문에 객관적인 판단을 내리지 못하는 프로그래머는 사실 생각보다많다. 부실한 설계, 유닛테스트의 부재, 끊이지 않는 버그의 존재는 어떻게 보면 이러한 심리적 기제가 작동한 결과인 경우가대부분이다.
이런 사람들은 새로 나온 언어의 API를 살펴보거나 유행을 타는 개발도구를 다운로드 받으려고 서두르기 전에, 자신이 할 수있는 일과 할 수 없는 일을 정확하게 분별하는 능력과, ‘예’와 ‘아니’를 자신 있게 말하는 능력을 갖추는 것이 프로그래머로서의‘실력’을 한 눈금 올리는 길임을 기억할 필요가 있다.
일의 우선순위와 개발환경 파악해야
4번 항목은 일의 우선순위를 매길 줄 아는 능력에 대한 이야기다. 요구사항을 작성하는 진영에서는 언제나 모든 일이 다중요하게 여겨지는 법이다. 그들로 하여금 지금, 당장, 여기서, 내가 해야 할 일을 선택하도록 하는 책임은 프로그래머 자신에게있다. 초보 프로그래머는 우선순위를 정하는 책임이 전적으로 요구사항을 작성하는 사람에게 있다고 믿고, 경험이 많은 프로그래머는그러한 책임이 자기 자신에게 있음을 안다.
그것은 큰 차이다. 그 다음에 있는 5번과 6번 항목은 비슷하다. 수능과 같은 큰 시험이 다가오면 선생님들이 거듭해서강조하는 말이 있다. 모르는 문제를 붙잡고 시간을 허비하지 말라는 말이다. 이러한 요령은 프로그래머에게도 그대로 적용된다.프로젝트를 진행하다보면 참으로 단순한 버그를 붙들고 씨름을 하느라 중요한 기능을 구현할 시간을 허비하는 사람을 볼 때가 있다.
이러한 태도는 시간을 비효율적으로 사용한다는 점에 있어서도 문제지만, 풀리지 않는 문제를 붙들고 씨름을 하다보면 생각이굳기 때문에 문제를 해결할 가능성이 낮아진다는 단점을 내포하기도 한다. 문제가 해결되지 않으면 다른 곳으로 경쾌하게 이동하는것이 현명한 태도다. 이것은 문제를 포기하는 것과 다르다. 시간이 지난 다음에 맑아진 정신으로 문제를 다시 보면 해결의 실마리가보이는 경우가 많기 때문이다.
7번 항목은 개발자가 자신의 개발환경만 들여다보는 것이 아니라, 프로젝트의 환경 전체를 알아야 한다는 사실을 말하고 있다.IDE와 구글 검색창만 들여다 볼 것이 아니라 QA, 네트워크, 데이터베이스, PM, 고객, 비즈니스 분석가를 아우르는 모든사람들의 일상과 고민을 알수록 더욱 실력 있는 프로그래머가 될 가능성이 높다고 주장하는 것이다.
필자는 타일러의 의견에 기본적으로 동의하지만 필자가 볼 때 주변 환경에 관심을 갖는 것은 ‘필수’가 아니라 ‘선택’이다.프로그래머에 따라서 주변 환경에는 전적으로 무관심하지만 품질이 뛰어난 코드를 만들어내는 사람이 얼마든지 존재하기 때문이다.그것이 자신의 스타일이라면 굳이 주변 환경의 일에 관심을 기울이지 않아도 상관이 없다.
8번 항목의 의미에 대해서는 필자의 설명보다 타일러 자신의 말을 들어보는 것이 훨씬 나을 것 같다. 다음은 타일러의블로그에서 직접 인용한 내용이다. 그의 고백은 내가 3년 전에 루슨트테크놀로지에서 월스트리트로 직장을 옮기면서 느꼈던 심정과너무 비슷하다. 그런 면에서 타일러의 이야기는 곧, 필자의 이야기이기도 하다.
“내가 첫 직장에서 일을 시작한 1년 뒤에, 우리 회사는 다른 회사와 합병되었다. 나는 갑자기 나보다 훨씬 재능이 많고경험도 풍부한 사람들에 의해서 둘러싸이게 되었다. 그 상황이 나를 얼마나 큰 열등감과 바보 같은 심정에 휩싸이게 만들었는지지금도 생생하게 기억한다. 나는 열심히 공부했고, 많은 책들을 읽었지만 그들을 따라잡을 수 없었다. 그들은 나에 비해서 많은장점을 가지고 있었다. 그렇지만 이제는 뛰어난 사람들과 함께 일하는 것이 나를 슬프게 하지 않는다. 나는 다만 그들로부터 배울수 있는 기회를 얻었다고 느낄 뿐이다. 나는 동료에게 질문을 던지고 그들이 왜 그러한 결론에 이르렀는지를 이해하기 위해서 머리를싸매고 고민한다. (중략) 당신의 동료를 경쟁자가 아니라 당신의 재산이라고 여길 필요가 있다.”
그 다음에 있는 9번 항목은 마치 1992년 미국의 대통령선거에서 회자된 “바보야 문제는 경제야”라는 문구를 떠오르게한다. 우리식으로 말하자면 “바보야 문제는 소프트웨어야”가 되는 셈이다. 요즘 세상에서 모든 것이 결국 ‘돈’으로 통하는것처럼, 소프트웨어 개발 환경에서 모든 것은 결국 ‘소프트웨어’로 귀착된다. 그것도 그냥 소프트웨어가 아니라 제대로 작동하는소프트웨어다.
프로그래밍의 세계에서 작동한다(working)는 말은 버그 없이, 최적의 성능으로, 사용자가 원하는 기능을 제공한다는의미를 함축한다. 스트라이커에게 있어서 결국 중요한 것이 ‘골(goal)’인 것처럼, 프로그래머에게 있어서 결국 중요한 것은제대로 작동하는 소프트웨어다. 이것은 너무나 당연한 상식이라서 더 이상 부연할 것도 없다.
마지막 10번 항목은 매체의 품위를 고려해서 매우 부드럽게 의역을 해놓았는데, 타일러가 영문에서 사용한 단어의 뉘앙스는‘멍청이’에 비해서 10배는 강한 표현이다. 소프트웨어 개발 경험이 있는 사람이라면 따로 설명하지 않아도 그 의미를 잘 알것이다. 도무지 상식이 통하지 않는 사람 때문에 “뚜껑이 열리는” 경험을 해보지 않는 사람은 없다.
타일러에 의하면 그러한 경험이 불가피한 이유는 간단하다. 우리의 주변에 있는 사람들 중에서 몇몇은 정말이지 ‘멍청이’이기때문이다. 이러한 선언은 누굴 인격적으로 모독하거나 비방하자는 의미가 아니다. 이러한 인식을 통해서 불필요한 감정과 에너지의소모를 피하자는 것이 목적이다. 그런데 여기엔 주의할 점이 있다.
자신의 주변에 있는 사람 중에서 누가 ‘멍청이’인지 생각해보기 전에, 혹시 내가 다른 사람에게 ‘멍청이’로 인식되고 있지는않은지 생각할 필요가 있는 것이다. 내가 ‘멍청이’로 여기는 사람이 있다면, 나를 ‘멍청이’로 여기는 사람도 존재한다고 생각하는것이, 아마 현명할 태도일 것이다. 뒤집어 말하면, 세상에 멍청이는 없다. 멍청이란 존재는 본질적으로 상대적인 관계 속에서규정되는 개념이기 때문이다.
이상으로 우리는 오바산조와 타일러라는 두 프로그래머의 경험에서 우러난 경구를 고찰해보았다. 대부분 상식적인 수준의이야기이지만, 상식적이기 때문에 우리가 종종 의식하지 못하고 지나가는 소중한 내용이 담겨있기도 했다. 그들이 들려준 스무 개의경구중에서 하나라도 새겨들을 만한 것이 있었다면 다행이겠다.
# by | 2008/07/27 21:48 | Web | 트랙백 | 덧글(0)
