|
오랫동안 컴퓨터 프로그래머로 일했으며, ‘괴델, 에셔, 바흐'라는 책을 쓴 더글러스 호프스태터는 자신의 이름을 딴 ‘호프스태터의 법칙’로 컴퓨팅 분야에서의 오랜 경험을 요약해 정의하고 있다.
“늘 예상보다 더 많은 시간이 소요될 것이다. ‘호프스태터의 법칙’을 감안할지라도 그럴 것이다.”
그러나 기업과 조직, 이해관계자, 프로젝트 매니저는 여전히 소프트웨어 프로젝트에 ‘일정’을 적용한다. 심지어 프로그래머들도 이렇게 한다. 그런데 ‘호프스태터의 법칙’이 프로그래머에게 좀더 유효할까? 아니면 프로젝트 매니저에게 더 통할까? 프로젝트 매니저는 API를 사용해 2개월 정도를 절약할 수 있다. 그러나 API에 129가지 옵션이 있으며, 이 가운데 회사에 필요한 것은 한 가지라는 것을 발견하는 사람은 개발자이다. 코드 빌드도 어렵지만, 8명의 프로그래머를 관리하는 일도 어렵다.
외부의 프로젝트 스폰서는 참을성 없게 회의 탁자 테이블을 두드린다. 한편, 현업 부문 사람들과 프로젝트 관리자는 프로그래머가 게을러 진전이 없다고 생각한다. 그러나 프로그래머는 자신이 직면한 어려운 문제들을 관리자, 감독자가 이해하지 못한다고 생각한다.
오래 전, 누군가 생산성과 ‘코드 줄’ 사이의 상관관계를 과학적으로 분석해 측정하려 시도했다. 페드릭 브룩스가 1975년 ‘맨먼스 미신(The Mythical Man-Month)’이라는 책을 통해 이에 대한 이론을 제시했다. ‘선형적 진행’에 대한 수학 모델과 가설이 적용되지 않음을 보여준 책이다.
이후 프로젝트 완료를 가로막는 가시밭이 더 늘었다. 애자일과 지속적인 빌드 같은 개념은 국소적인 문제에서 일시적으로 효과가 있지만, 모든 것을 더 복잡하게 만든다. 즉, 복잡성이 궁극적인 문제이다. 고객과 이해당사자, 주주들은 갈수록 더 많은 것을 요구하고 있고, 이는 시간이 점점 더 길어진다는 의미이다.
소프트웨어 딜리버리를 앞당길 수 있는 새로운 도구와 기법들이 다수 등장했음에도 불구하고 소프트웨어 프로젝트가 예상보다 지연되는 이유 10가지를 제시한다. 프로젝트 지연을 초래하는 모든 원인을 다 설명하지 못할 수도 있지만, 적어도 현장을 이해하는데 도움을 줄 것이다.
범위 추가
몇달 전에 시작한 프로젝트의 명칭이 바뀌지 않았을 지 모르지만, 그 사이에 범위와 목표 산출물(deliverables)이 너무 많이 바뀌어 프로젝트에 다른 이름을 붙이는 게 적절한 경우가 있다. 큰 목적과 목표는 기존과 같지만, 누군가 처음부터 모든 것을 다시 만들 정도로 아키텍처를 바꿨을 수 있다.
어쩌면 지연된 프로젝트를 하나의 프로젝트로 생각하는 것이 타당하지 않을 수도 있다. 첫 번째 프로젝트는 오래 전에 완료되었고, 이름만 같은 전혀 다른 새로운 프로젝트를 시작한 것이나 다름없기 때문이다. 아니 그 사이 몇달 동안 완료한 프로젝트가 여러 개일 수도 있다. 즉, 정확히 계산을 하면 하나의 프로젝트에 예상보다 많은 몇달을 추가 소비한 것이 아니라, 개발자들이 같은 이름을 가진 여러 프로젝트에 이 시간을 투자한 것일 수 있다.
심의
소프트웨어 개발자들은 개방형 사무실에 대해 투덜거린다. 코딩에 몰입하기 위해 고립된 공간과 큰 헤드폰을 요구한다. 그런데 정작 소프트웨어 디자인에 필요한 것들을 토론하느라 시간이 부족한 것처럼 보인다. 개발자들이란 업무을 완수하는 것보다 접근법에 대해 토론을 하는 것에 더 큰 만족을 느낀다고 생각될 정도다.
물론 메뉴 구성이나 스키마 디자인에 최선의 방법을 논의하는 미팅에 많은 시간을 투자하는 것을 비웃을 수도 있다. 그러나 중요한 사실은 단순한 프로젝트조차 새로운 ‘무엇’을 만드는 데 목적을 두고 있다는 것이다. 코딩은 로마 제국 시대부터 시작된 ‘도로 건설’과는 다르다. 과거 많은 경험이 없기 때문에 소프트웨어 최적화에 더 많은 시간이 소요되기 마련이다. 더구나 현재 비즈니스에 필요한 시스템, 스펙을 감안하면 더 그렇다.
애자일에는 한계가 있다.
매니저들의 경우, 프로세스가 ‘전부’이다. 속도를 유지하는 문제에 있어, 매니저가 가장 중요하게 여기는 최고의 솔루션은 프레임워크와 방법론이다. 소프트웨어 프로젝트 매니저는 최고의 개발 방법론에 대해 주장하기 좋아하지만, 이런 방법론은 모두 한계와 제약을 갖고 있다. 프레임워크는 가이드라인에 불과하며, 이론과 실무가 다른 경우가 많다. 이로 인해 프로젝트 일정이 촉박한 경우에도 반드시 해결해야 할 ‘예외 사항’이 발생하게 된다.
개발자는 애자일을 좋아하는 경향이 있다. 기여할 방향에 대한 선택에 있어 가장 많은 자유가 주어지기 때문이다. 그러나 ‘인도자’가 없는 경우, 혼란과 혼돈이 초래될 수 있다. 관리자 한 명이 내게 코드가 올바른 지 걱정할 필요가 없다고 말한 적이 있다. 이를 고치기 위해 새 애자일 ‘티켓’을 만들면 된다는 이유에서였다. 그런데 해결을 통해 인정받는 크레딧이 티켓의 2배는 된다. 2배에 달하는 성과를 달성한 것으로 간주되기 때문이다.
누구도 미래를 예측할 수 없음
미적분법을 만든 아이작 뉴튼은 “다른 사람보다 더 멀리 볼 수 있는 경우는 거인의 어깨 위에 앉아있을 때에만 해당된다”라고 말했다. 미적분법은 고등학교 수학의 '최고봉’이며, 많은 과학에서 ‘토대’ 역할을 한다. 그러나 몇몇 기본 연산법으로만 구성되어 있다. 워싱턴 DC와 푸에르토리코 같은 지역을 포함해 50개 주에서 모두 작동해야 하는 페이롤(급여 지불 처리) 시스템과 다르다.
소프트웨어 개발자들은 수 많은 공동체에 모두 작동하고 적용되는 시스템을 빌드하는 일을 하고 있으며, 따라서 머리 속에 모든 사람들의 니즈(필요 사항)를 계속 담아두는 것이 사실상 불가능하다는 이야기를 하는 것이다.
미래를 예측할 수 없는 때가 많으면서 상황이 더 악화된다. 새로운 시스템은 ‘쿨’ 하기도 하지만, 동시에 과거의 모든 것을 파괴한다. 따라서 추상적으로 접근하는 모험을 할 수밖에 없다. 반복을 하면서 세부적인 부분을 고치고, 이후 최상의 결과를 기대한다. 모든 ‘장애물’을 극복하고 고치는 데 많은 시간이 걸린다. 다뤄야 할 세부 사항이 아주 많기 때문이다.
이해당사자의 변덕
소프트웨어 개발자가 자신의 업무 속도를 통제한다고 생각할지 모르겠다. 그러나 사실 그렇지 않다. 주어진 과업이 바뀌는 경우가 많기 때문이다. 고객이나 조직 내 다른 이해당사자가 많은 것을 바꿔 초래된 문제를 놓고 소프트웨어 팀을 비난하는 것은 부당하다. 이들은 계속해서 새로운 수정, 새로운 보완(강화)을 요구한다. 때론 아주 별것 아닌 듯 작은 것을 추가하지만, 이것이 아주 어렵고, 지금까지 달성한 많은 것을 망치는 결과가 초래될 수도 있다.
경직된 데이터 구조
데이터는 길들이기 힘든 야수이다. 그런데 소프트웨어 개발 업무 가운데 상당 부분은 밤에 이 야수를 자신의 외양간으로 몰고 가는 것이다. 가장 긴장되는 업무 중 하나는 데이터 모델을 구현하고, 데이터베이스가 적시에 완벽하게 정보를 저장하도록 만드는 것이다.
또 데이터 모델은 대개 경직되어 있다. 예를 들어 설명하면, ZIP 코드 필드에는 9자리 숫자의 ZIP 코드만 있어야 한다. 그러나 한편으로는 아이러니하게도 데이터 모델이 유연한 것이 좋다. ‘마법의 막대기’를 흔들면, 캐나다의 누군가 숫자와 문자로 구성된 캐나다 우편번호를 등록할 수 있도록 만들기 위해서이다(이 경우에도 경직된 패턴으로). 이런 모델을 구현하는 데 시간이 걸리기 마련이다.
작동하는 구조가 필요하다. 그러나 변화나 변경은 이런 구조를 무효로 만들 수 있다. ‘끝이 없는 전쟁’이다. 한 사람 당 하나의 엔트리가 있는 것이 좋다. 그런데 이름을 바꾼 후에도 사람을 추적하고 싶어 지고, 2개의 엔트리가 만들어진다. 그러면 둘 모두 그저 그런 것이 된다.
‘거짓(Falsehood)’ 발생
일부 프로그래머는 ‘참’으로 보이는 단순한 명령 구문도 코드로 렌더링을 시도하기 전까지 별도로 분류하기 좋아한다. ‘하루는 24기간’이라는 구문이 이런 ‘거짓’에 해당된다. 언뜻 보기에 ‘참’으로 보인다. 그러나 서머타임 시간이 시작되거나 끝나는 날은 해당이 되지 않는다. 즉, ‘참’이 아니다. 더구나 매년 이런 날이 바뀌고, 유럽에서 일광 절약 시간이 시작되고 끝나는 날은 미국과 다르다. 다시 말해, 미국은 하루가 24시간이지만, 유럽은 25시간인 날이 있다.
프로젝트마다 이런 ‘거짓’을 새로 발견하게 될 것이다. 우리는 새 ‘거짓’이 쉽게 해결할 수 있는 ‘거짓’이고, 사용자가 이와 관련된 ‘불일치’ 중 하나에 직면했을 때 크게 화를 내지 않기 바랄 수밖에 없다.
복잡성 문제
프로그래머는 자신이 작업하는 시스템을 단순화시키기 원한다. 그러나 사용자와 이해당사자는 가능한 비즈니스 가치를 추구하면서 추가 ‘사례'와 기능을 추가해 시스템을 향상시키기 원한다. 기능은 좋다. 그러나 더 ‘스마트'하고 나은 기능을 추가하면 논리 또한 추가된다. 그러면서 논리가 기하급수적으로 복잡해지는 경우도 있다.
쉽게 추가할 수 있는 기능도 있다. 그러나 의도하지 않은 결과를 촉발하는 기능도 있다. 이 경우, 예상 못했던 문제에 대한 결정을 내리기 위해 계획에 없던 미팅을 더 많이 하게 된다. 코드에 또 다른 계층을 추가하거나, 데이터베이스에 행을 추가할 때 각별히 주의를 기울여야 한다. 그러지 않을 경우, 프로젝트가 걷잡을 수 없이 복잡해지고, 일정이 훨씬 더 많이 지연될 수 있다.
기능을 추가시키는 디자인 검토
디자인 검토는 개발 프로세스에 반드시 필요한 부분이다. 그러나 디자인 검토에 목적을 둔 미팅 때, 모든 사람이 소프트웨어 기능을 추가시키기 원하고, 개발자가 이런 기능 추가 요청을 기꺼이 받아들이는 경우에만 해당된다. 현재 진행하는 프로젝트 범위를 넘어서는 것이 분명해 이런 요청을 거부할 수 있는 때도 있지만, 이것이 명확하지 않은 요청들도 많다. 많은 기록이 필요한 요청들이다. 쉽게 추가할 수 있는 기능인지, 어려운지 여부를 파악하는 것에만 몇 시간을 투자해야 할 수도 있다.
그러나 이해당사자와의 디자인 검토를 피할 방법은 없다. 바람직한 개발 프로세스의 일부이기 때문이다. 따라서 추가할 수 있는 기능, 버전 2.0 또는 버전 5.0으로 남겨둘지 결정하기 위해 코드를 변경하는 일은 피할 수 없는 운명과 같다.
때로는 느린 것이 바람직하다
프로젝트 진행이 느린 것에 화가 날 수도 있지만, 소프트웨어 개발이 지연되는 것을 '버그’가 아닌 ‘기능’으로 봐야 한다. 중요한 부분을 서둘러 재촉할 경우 단점과 문제점이 발생하게 된다. 코더가 시간을 투자할 경우, 우리는 그 토대가 튼튼하고, 논리가 타당하도록 만전을 기해야 한다. 속도에 대해 불평을 하는 것은 집중에 방해가 되고, 프로젝트에 위험을 초래한다. 개발자들이 자신의 일에 집중하도록 놔둘 필요도 있다.
*Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다. ciokr@idg.co.kr
원문보기:
http://www.itworld.co.kr/news/127568#csidx0529ccb84c894e7bc6f78b6b9c25322
|
