할로윈이 다가온다. 뱀파이어, 좀비 따위의 시시한 것들을 무서워하는 사람도 있겠지만 IT 전문가들은 단 몇 마디 말이 보통 사람들이 상상하는 것보다 훨씬 더 무서울 수 있음을 잘 안다. 이 몇 마디가 IT 자원의 무의미한 낭비, 망친 출시, 실패한 프로젝트 등의 악몽 같은 결과로 이어질 수 있다. 이번 할로윈에 여러분을 진정한 공포로 몰아넣을 수 있는 10가지 짧은 문구를 살펴보자. 장시간 노동과 프로젝트 실패가 무섭다면, 여기 소개하는 내용에는 아마 뼛속까지 움츠러들 것이다. editor@itworld.co.kr
“그 업체가 가장 싼 가격을 제시했어요!”
“최저가 입찰”이라는 말은 지난 몇 년 동안 사실상 모욕적인 의미로 사용된 만큼, 이제 구매 부서의 사람들도 ‘최저가’보다 더 좋은 기준으로 업체를 선택하는 방법을 알아냈으리라 생각하겠지만, 많은 구두쇠 CFO들은 싼 가격표 너머의 미래에 사실 끔찍하고 값비싼 대가가 도사리고 있음을 여전히 알지 못한다. 특히 정부 기관들이 이러한 사고에 취약하다. IBM은 2000년대 후반 텍사스의 초대형 데이터센터 아웃소싱 프로젝트 입찰에서 경쟁업체들보다 훨씬 저렴한 가격을 내세웠는데, 이후 텍사스는 톡톡한 대가를 치러야 했다. 사진 : 텍사스 주지사 릭 페리. REUTERS/Jaime R. Carrero
“기능 한 개만 더 추가할 수 있어요?”
프로젝트에서 요청 접수 시점이 지났는데도 사용자들이 새로운 기능을 계속해서 요청한다면 일관성 있는 제품을 제대로 만들 수 없다. 이른바 범위 추가(scope creep)라고 하는 이 현상은 막대한 비용 초과와 일정 지연을 유발한다. 개발자가 새 기능을 추가해야 할 뿐만 아니라 이를 위해 이전 코드와 설계까지 변경해야 하기 때문이다. 대표적인 사례로, 미국 인구조사국은 방문 인구조사 요원이 사용할 맞춤형 휴대용 컴퓨터를 설계할 당시 설계 공정의 후반부에 계약업체에 400가지의 새로운 또는 수정된 요구 사항을 전달한 적이 있다. 이 프로젝트는 결국 폐기됐고 2010년 인구 조사는 언제나 그랬듯이 종이 서류를 통해 이루어졌다. 사진 : 구현되지 못한 휴대용 기기. 미 인구조사국.
“이 솔루션에는 온갖 기능이 다 있어요!”
업체들이 실무진보다 기업 고위 임원진과의 세일즈 미팅을 선호하는 데는 그럴 만한 이유가 있다. 고위 임원진은 기업에서 일상적으로 구매하는 물건들에 대해 일일이 신경을 쓸 필요가 없기 때문이다. CRM 통합 전문가 로렌스 뷰캐넌에 따르면 임원들은 해결해야 할 구체적인 문제점을 자문하고 바로 그 문제를 처리할 제품을 찾아야 하는데, 실상은 들뜬 나머지 제품의 어지러운 기능 목록에 현혹되어 이런저런 기능들로 모든 문제를 해결할 수 있다는 설득에 넘어가기가 쉽다고 한다. 사진 : JeromeG111/Flickr
“그걸 테스트할 시간도 돈돈 없어요.”
대부분의 개발자는 소프트웨어에서 고품질의 테스트가 주는 혜택을 잘 알지만 대부분의 임원들 생각에 테스트는 비용과 시간 낭비일 뿐이다. 유능한 개발자들을 채용했고, 이 개발자들이 애플리케이션을 개발했고, 아무 문제 없어 보이는데 무엇이 더 필요하단 말인가? 2007년, LA 통합 교육구와 딜로이트는 교사용 SAP 기반 급여 시스템을 도입할 당시 바로 그런 생각을 갖고 있었다. 교원 노조는 폭넓은 테스트를 원했지만 교육구와 딜로이트는 비용을 이유로 이를 거부했고, 결과는 예상대로 처참했다. 사진 : 미 LA 통합교육구. Ucla90024/Wikipedia
“테스트 환경에서 문제 없었으니까 실무 환경에서도 아무 문제 없을 겁니다”
테스트 실패의 대표적인 이유 중 하나는 테스트 환경 자체가 실무 환경의 완벽한 재현이라고 가정하는 데 있다. 이러한 가정은 특히 규모 측면에서 문제를 일으킬 수 있다. 즉, 10여 명의 테스터로는 그보다 1,000배 이상 많은 실제 사용자만큼 애플리케이션이나 웹 사이트에 부담을 가할 수가 없다. 베이징 올림픽 위원회가 중국의 13억 시민들에게 티켓 판매를 개시하자 티켓 발매 웹 사이트는 계속 작동을 멈췄고, 결국 올림픽을 관람하고자 했던 중국인들은 티켓 추첨 서비스를 사용할 수밖에 없었다. 사진 : 올림픽 입장권을 사려고 24시간 줄을 선 사람들. REUTERS/Joe Chan
“항상 이렇게 했는데요!”
대규모 IT 프로젝트에는 항상 변화가 수반된다. 때로 이 변화는 불쾌한 변화일 수도 있고, 이유 없는 저항에 직면하여 시간과 노력을 소비하기도 한다. “예전에는 이렇게 했는데요”라는 말은 많은 경우 “왜 이렇게 해야 하는지는 모르지만 이렇게 하는 게 편해요”라는 말로 해석할 수 있다. 또한 이러한 태도는 프로젝트의 초반 이점이 구현된 이후 프로젝트를 합리적인 결론으로 이끄는 데 있어 보이지 않는 장벽이 되기도 한다. 사진 : Brian O'Connell/Flickr
“프로젝트에 더 많은 프로그래머들을 투입하고 있어요.”
프로그래밍 프로젝트 관리의 교과서 중 하나는 ‘맨먼스의 미신(Mythical Man-Month)’이다. 저자프레드 브룩스가 1960년대 IBM에서 일하며 얻은 경험을 바탕으로 전달하고자 하는 메시지는 더 많은 인원의 투입으로 빠른 결과를 원해서는 안 된다는 것이다. 프로그래머가 10명이라고 해서 5명일 때보다 더 빨리 프로젝트를 끝낼 수는 없고, 실제로는 더 많은 사람을 관리하는 데 따르는 오버헤드가 프로젝트 속도를 오히려 더 늦출 수 있다. 물론 팀에 자원이 부족한 경우도 있지만, 일정을 초과한 프로젝트에 계속 추가로 인력이 투입되는 상황이 발생하지 않도록 주의해야 한다. 사진 : SD&M via Wikipedia
“문서화는 작업 속도를 늦출 뿐입니다”
물론 코드의 기능에 대한 문서를 작성하는 일보다 실제 코드를 작성하는 데 더 많은 시간을 쓰고 싶겠지만 작업을 역추적할 수 있는 문서화를 게을리할 경우 필히 재앙으로 이어지게 된다. 실제로 무엇을 구축하는지 모두가 알 수 있도록 하는 요구 사항 문서부터, 작성자가 떠나고 오랜 시간이 지난 뒤에도 코드를 어떻게 사용해야 하는지 사람들이 알 수 있도록 하는 코드 문서화에 이르기까지, 문서화는 프로젝트가 뒤죽박죽 무질서한 상태로 진행되지 않도록 해주는 귀중한 요소다. 사진 : Quinn Dombrowski/Flickr
“IT 부서가 책임지고 하세요”
대부분의 IT 직원들은 경영진의 간섭을 받지 않고 일하고 싶어한다. 그러나 현실에서 정말 이 말을 듣는다면, 이는 회사 의사결정자들의 지지를 받지 못할 가능성이 큰 프로젝트를 진행하라는 뜻이고, 불안한 상태에 처하게 된다. 낮은 레벨의 일상적인 IT 업무라면 괜찮겠지만 예를 들어 ERP 프로젝트를 진행하는 중인데 이를 받쳐주는 “C”레벨 인사가 없다면, 결국 중도에 폐기될 무언가를 위해 시간과 노력을 들이는 꼴이 될 수도 있다. 사진 : 1981년 알 헤이그 미 국무장관은 레이건 대통령 암살 기도 당시 자신이 백악관을 통제하고 있다고 발표해 논란이 됐다. Wikipedia
“이걸 왜 다시 하죠?”
새로운 장난감에 무턱대고 끌리지 않을 사람은 없다(특히 IT 종사자라면). CRM 통합 전문가인 로렌스 뷰캐넌은 본말이 전도되지 않는 것이 중요하다고 말한다. 즉, 구체적인 용도를 결정하기 전에 새로운 도구부터 덥석 잡지 말라는 것이다. 회사의 고위 임원 중 누군가가 큰 구매 건이나 프로젝트에 대한 소식을 듣고 그것의 목적이 무엇인지 묻는다면 난처해질 수 있다. 그 질문에 대해 설득력 있고 구체적인 답변이 있어야 할 것이다. 사진 : *USB*/Flickr