2019.08.02

때론 포기하는 게 지혜··· SW 프로젝트가 지연되는 10가지 이유

Peter Wayner | CIO
오랫동안 컴퓨터 프로그래머로 일했으며, ‘괴델, 에셔, 바흐'라는 책을 쓴 더글러스 호프스태터는 자신의 이름을 딴 ‘호프스태터의 법칙’로 컴퓨팅 분야에서의 오랜 경험을 요약해 정의하고 있다. 

“늘 예상보다 더 많은 시간이 소요될 것이다. ‘호프스태터의 법칙’을 감안할지라도 그럴 것이다.” 


그러나 기업과 조직, 이해관계자, 프로젝트 매니저는 여전히 소프트웨어 프로젝트에 ‘일정’을 적용한다. 심지어 프로그래머들도 이렇게 한다. 그런데 ‘호프스태터의 법칙’이 프로그래머에게 좀더 유효할까? 아니면 프로젝트 매니저에게 더 통할까? 프로젝트 매니저는 API를 사용해 2개월 정도를 절약할 수 있다. 그러나 API에 129가지 옵션이 있으며, 이 가운데 회사에 필요한 것은 한 가지라는 것을 발견하는 사람은 개발자이다. 코드 빌드도 어렵지만, 8명의 프로그래머를 관리하는 일도 어렵다.

외부의 프로젝트 스폰서는 참을성 없게 회의 탁자 테이블을 두드린다. 한편, 현업 부문 사람들과 프로젝트 관리자는 프로그래머가 게을러 진전이 없다고 생각한다. 그러나 프로그래머는 자신이 직면한 어려운 문제들을 관리자, 감독자가 이해하지 못한다고 생각한다.

오래 전, 누군가 생산성과 ‘코드 줄’ 사이의 상관관계를 과학적으로 분석해 측정하려 시도했다. 페드릭 브룩스가 1975년 ‘맨먼스 미신(The Mythical Man-Month)’이라는 책을 통해 이에 대한 이론을 제시했다. ‘선형적 진행’에 대한 수학 모델과 가설이 적용되지 않음을 보여준 책이다. 

이후 프로젝트 완료를 가로막는 가시밭이 더 늘었다. 애자일과 지속적인 빌드 같은 개념은 국소적인 문제에서 일시적으로 효과가 있지만, 모든 것을 더 복잡하게 만든다. 즉, 복잡성이 궁극적인 문제이다. 고객과 이해당사자, 주주들은 갈수록 더 많은 것을 요구하고 있고, 이는 시간이 점점 더 길어진다는 의미이다. 

소프트웨어 딜리버리를 앞당길 수 있는 새로운 도구와 기법들이 다수 등장했음에도 불구하고 소프트웨어 프로젝트가 예상보다 지연되는 이유 10가지를 제시한다. 프로젝트 지연을 초래하는 모든 원인을 다 설명하지 못할 수도 있지만, 적어도 현장을 이해하는데 도움을 줄 것이다.
 
ⓒ Image Credit : Getty Images Bank



범위 추가
몇달 전에 시작한 프로젝트의 명칭이 바뀌지 않았을 지 모르지만, 그 사이에 범위와 목표 산출물(deliverables)이 너무 많이 바뀌어 프로젝트에 다른 이름을 붙이는 게 적절한 경우가 있다. 큰 목적과 목표는 기존과 같지만, 누군가 처음부터 모든 것을 다시 만들 정도로 아키텍처를 바꿨을 수 있다.

어쩌면 지연된 프로젝트를 하나의 프로젝트로 생각하는 것이 타당하지 않을 수도 있다. 첫 번째 프로젝트는 오래 전에 완료되었고, 이름만 같은 전혀 다른 새로운 프로젝트를 시작한 것이나 다름없기 때문이다. 아니 그 사이 몇달 동안 완료한 프로젝트가 여러 개일 수도 있다. 즉, 정확히 계산을 하면 하나의 프로젝트에 예상보다 많은 몇달을 추가 소비한 것이 아니라, 개발자들이 같은 이름을 가진 여러 프로젝트에 이 시간을 투자한 것일 수 있다.

심의
소프트웨어 개발자들은 개방형 사무실에 대해 투덜거린다. 코딩에 몰입하기 위해 고립된 공간과 큰 헤드폰을 요구한다. 그런데 정작 소프트웨어 디자인에 필요한 것들을 토론하느라 시간이 부족한 것처럼 보인다. 개발자들이란 업무을 완수하는 것보다 접근법에 대해 토론을 하는 것에 더 큰 만족을 느낀다고 생각될 정도다.

물론 메뉴 구성이나 스키마 디자인에 최선의 방법을 논의하는 미팅에 많은 시간을 투자하는 것을 비웃을 수도 있다. 그러나 중요한 사실은 단순한 프로젝트조차 새로운 ‘무엇’을 만드는 데 목적을 두고 있다는 것이다. 코딩은 로마 제국 시대부터 시작된 ‘도로 건설’과는 다르다. 과거 많은 경험이 없기 때문에 소프트웨어 최적화에 더 많은 시간이 소요되기 마련이다. 더구나 현재 비즈니스에 필요한 시스템, 스펙을 감안하면 더 그렇다.

애자일에는 한계가 있다.
매니저들의 경우, 프로세스가 ‘전부’이다. 속도를 유지하는 문제에 있어, 매니저가 가장 중요하게 여기는 최고의 솔루션은 프레임워크와 방법론이다. 소프트웨어 프로젝트 매니저는 최고의 개발 방법론에 대해 주장하기 좋아하지만, 이런 방법론은 모두 한계와 제약을 갖고 있다. 프레임워크는 가이드라인에 불과하며, 이론과 실무가 다른 경우가 많다. 이로 인해 프로젝트 일정이 촉박한 경우에도 반드시 해결해야 할 ‘예외 사항’이 발생하게 된다.

개발자는 애자일을 좋아하는 경향이 있다. 기여할 방향에 대한 선택에 있어 가장 많은 자유가 주어지기 때문이다. 그러나 ‘인도자’가 없는 경우, 혼란과 혼돈이 초래될 수 있다. 관리자 한 명이 내게 코드가 올바른 지 걱정할 필요가 없다고 말한 적이 있다. 이를 고치기 위해 새 애자일 ‘티켓’을 만들면 된다는 이유에서였다. 그런데 해결을 통해 인정받는 크레딧이 티켓의 2배는 된다. 2배에 달하는 성과를 달성한 것으로 간주되기 때문이다.

누구도 미래를 예측할 수 없음
미적분법을 만든 아이작 뉴튼은 “다른 사람보다 더 멀리 볼 수 있는 경우는 거인의 어깨 위에 앉아있을 때에만 해당된다”라고 말했다. 미적분법은 고등학교 수학의 '최고봉’이며, 많은 과학에서 ‘토대’ 역할을 한다. 그러나 몇몇 기본 연산법으로만 구성되어 있다. 워싱턴 DC와 푸에르토리코 같은 지역을 포함해 50개 주에서 모두 작동해야 하는 페이롤(급여 지불 처리) 시스템과 다르다.

소프트웨어 개발자들은 수 많은 공동체에 모두 작동하고 적용되는 시스템을 빌드하는 일을 하고 있으며, 따라서 머리 속에 모든 사람들의 니즈(필요 사항)를 계속 담아두는 것이 사실상 불가능하다는 이야기를 하는 것이다. 

미래를 예측할 수 없는 때가 많으면서 상황이 더 악화된다. 새로운 시스템은 ‘쿨’ 하기도 하지만, 동시에 과거의 모든 것을 파괴한다. 따라서 추상적으로 접근하는 모험을 할 수밖에 없다. 반복을 하면서 세부적인 부분을 고치고, 이후 최상의 결과를 기대한다. 모든 ‘장애물’을 극복하고 고치는 데 많은 시간이 걸린다. 다뤄야 할 세부 사항이 아주 많기 때문이다.




2019.08.02

때론 포기하는 게 지혜··· SW 프로젝트가 지연되는 10가지 이유

Peter Wayner | CIO
오랫동안 컴퓨터 프로그래머로 일했으며, ‘괴델, 에셔, 바흐'라는 책을 쓴 더글러스 호프스태터는 자신의 이름을 딴 ‘호프스태터의 법칙’로 컴퓨팅 분야에서의 오랜 경험을 요약해 정의하고 있다. 

“늘 예상보다 더 많은 시간이 소요될 것이다. ‘호프스태터의 법칙’을 감안할지라도 그럴 것이다.” 


그러나 기업과 조직, 이해관계자, 프로젝트 매니저는 여전히 소프트웨어 프로젝트에 ‘일정’을 적용한다. 심지어 프로그래머들도 이렇게 한다. 그런데 ‘호프스태터의 법칙’이 프로그래머에게 좀더 유효할까? 아니면 프로젝트 매니저에게 더 통할까? 프로젝트 매니저는 API를 사용해 2개월 정도를 절약할 수 있다. 그러나 API에 129가지 옵션이 있으며, 이 가운데 회사에 필요한 것은 한 가지라는 것을 발견하는 사람은 개발자이다. 코드 빌드도 어렵지만, 8명의 프로그래머를 관리하는 일도 어렵다.

외부의 프로젝트 스폰서는 참을성 없게 회의 탁자 테이블을 두드린다. 한편, 현업 부문 사람들과 프로젝트 관리자는 프로그래머가 게을러 진전이 없다고 생각한다. 그러나 프로그래머는 자신이 직면한 어려운 문제들을 관리자, 감독자가 이해하지 못한다고 생각한다.

오래 전, 누군가 생산성과 ‘코드 줄’ 사이의 상관관계를 과학적으로 분석해 측정하려 시도했다. 페드릭 브룩스가 1975년 ‘맨먼스 미신(The Mythical Man-Month)’이라는 책을 통해 이에 대한 이론을 제시했다. ‘선형적 진행’에 대한 수학 모델과 가설이 적용되지 않음을 보여준 책이다. 

이후 프로젝트 완료를 가로막는 가시밭이 더 늘었다. 애자일과 지속적인 빌드 같은 개념은 국소적인 문제에서 일시적으로 효과가 있지만, 모든 것을 더 복잡하게 만든다. 즉, 복잡성이 궁극적인 문제이다. 고객과 이해당사자, 주주들은 갈수록 더 많은 것을 요구하고 있고, 이는 시간이 점점 더 길어진다는 의미이다. 

소프트웨어 딜리버리를 앞당길 수 있는 새로운 도구와 기법들이 다수 등장했음에도 불구하고 소프트웨어 프로젝트가 예상보다 지연되는 이유 10가지를 제시한다. 프로젝트 지연을 초래하는 모든 원인을 다 설명하지 못할 수도 있지만, 적어도 현장을 이해하는데 도움을 줄 것이다.
 
ⓒ Image Credit : Getty Images Bank



범위 추가
몇달 전에 시작한 프로젝트의 명칭이 바뀌지 않았을 지 모르지만, 그 사이에 범위와 목표 산출물(deliverables)이 너무 많이 바뀌어 프로젝트에 다른 이름을 붙이는 게 적절한 경우가 있다. 큰 목적과 목표는 기존과 같지만, 누군가 처음부터 모든 것을 다시 만들 정도로 아키텍처를 바꿨을 수 있다.

어쩌면 지연된 프로젝트를 하나의 프로젝트로 생각하는 것이 타당하지 않을 수도 있다. 첫 번째 프로젝트는 오래 전에 완료되었고, 이름만 같은 전혀 다른 새로운 프로젝트를 시작한 것이나 다름없기 때문이다. 아니 그 사이 몇달 동안 완료한 프로젝트가 여러 개일 수도 있다. 즉, 정확히 계산을 하면 하나의 프로젝트에 예상보다 많은 몇달을 추가 소비한 것이 아니라, 개발자들이 같은 이름을 가진 여러 프로젝트에 이 시간을 투자한 것일 수 있다.

심의
소프트웨어 개발자들은 개방형 사무실에 대해 투덜거린다. 코딩에 몰입하기 위해 고립된 공간과 큰 헤드폰을 요구한다. 그런데 정작 소프트웨어 디자인에 필요한 것들을 토론하느라 시간이 부족한 것처럼 보인다. 개발자들이란 업무을 완수하는 것보다 접근법에 대해 토론을 하는 것에 더 큰 만족을 느낀다고 생각될 정도다.

물론 메뉴 구성이나 스키마 디자인에 최선의 방법을 논의하는 미팅에 많은 시간을 투자하는 것을 비웃을 수도 있다. 그러나 중요한 사실은 단순한 프로젝트조차 새로운 ‘무엇’을 만드는 데 목적을 두고 있다는 것이다. 코딩은 로마 제국 시대부터 시작된 ‘도로 건설’과는 다르다. 과거 많은 경험이 없기 때문에 소프트웨어 최적화에 더 많은 시간이 소요되기 마련이다. 더구나 현재 비즈니스에 필요한 시스템, 스펙을 감안하면 더 그렇다.

애자일에는 한계가 있다.
매니저들의 경우, 프로세스가 ‘전부’이다. 속도를 유지하는 문제에 있어, 매니저가 가장 중요하게 여기는 최고의 솔루션은 프레임워크와 방법론이다. 소프트웨어 프로젝트 매니저는 최고의 개발 방법론에 대해 주장하기 좋아하지만, 이런 방법론은 모두 한계와 제약을 갖고 있다. 프레임워크는 가이드라인에 불과하며, 이론과 실무가 다른 경우가 많다. 이로 인해 프로젝트 일정이 촉박한 경우에도 반드시 해결해야 할 ‘예외 사항’이 발생하게 된다.

개발자는 애자일을 좋아하는 경향이 있다. 기여할 방향에 대한 선택에 있어 가장 많은 자유가 주어지기 때문이다. 그러나 ‘인도자’가 없는 경우, 혼란과 혼돈이 초래될 수 있다. 관리자 한 명이 내게 코드가 올바른 지 걱정할 필요가 없다고 말한 적이 있다. 이를 고치기 위해 새 애자일 ‘티켓’을 만들면 된다는 이유에서였다. 그런데 해결을 통해 인정받는 크레딧이 티켓의 2배는 된다. 2배에 달하는 성과를 달성한 것으로 간주되기 때문이다.

누구도 미래를 예측할 수 없음
미적분법을 만든 아이작 뉴튼은 “다른 사람보다 더 멀리 볼 수 있는 경우는 거인의 어깨 위에 앉아있을 때에만 해당된다”라고 말했다. 미적분법은 고등학교 수학의 '최고봉’이며, 많은 과학에서 ‘토대’ 역할을 한다. 그러나 몇몇 기본 연산법으로만 구성되어 있다. 워싱턴 DC와 푸에르토리코 같은 지역을 포함해 50개 주에서 모두 작동해야 하는 페이롤(급여 지불 처리) 시스템과 다르다.

소프트웨어 개발자들은 수 많은 공동체에 모두 작동하고 적용되는 시스템을 빌드하는 일을 하고 있으며, 따라서 머리 속에 모든 사람들의 니즈(필요 사항)를 계속 담아두는 것이 사실상 불가능하다는 이야기를 하는 것이다. 

미래를 예측할 수 없는 때가 많으면서 상황이 더 악화된다. 새로운 시스템은 ‘쿨’ 하기도 하지만, 동시에 과거의 모든 것을 파괴한다. 따라서 추상적으로 접근하는 모험을 할 수밖에 없다. 반복을 하면서 세부적인 부분을 고치고, 이후 최상의 결과를 기대한다. 모든 ‘장애물’을 극복하고 고치는 데 많은 시간이 걸린다. 다뤄야 할 세부 사항이 아주 많기 때문이다.


X