2019.08.02

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

Peter Wayner | CIO


이해당사자의 변덕
소프트웨어 개발자가 자신의 업무 속도를 통제한다고 생각할지 모르겠다. 그러나 사실 그렇지 않다. 주어진 과업이 바뀌는 경우가 많기 때문이다. 고객이나 조직 내 다른 이해당사자가 많은 것을 바꿔 초래된 문제를 놓고 소프트웨어 팀을 비난하는 것은 부당하다. 이들은 계속해서 새로운 수정, 새로운 보완(강화)을 요구한다. 때론 아주 별것 아닌 듯 작은 것을 추가하지만, 이것이 아주 어렵고, 지금까지 달성한 많은 것을 망치는 결과가 초래될 수도 있다.

경직된 데이터 구조
데이터는 길들이기 힘든 야수이다. 그런데 소프트웨어 개발 업무 가운데 상당 부분은 밤에 이 야수를 자신의 외양간으로 몰고 가는 것이다. 가장 긴장되는 업무 중 하나는 데이터 모델을 구현하고, 데이터베이스가 적시에 완벽하게 정보를 저장하도록 만드는 것이다. 

또 데이터 모델은 대개 경직되어 있다. 예를 들어 설명하면, ZIP 코드 필드에는 9자리 숫자의 ZIP 코드만 있어야 한다. 그러나 한편으로는 아이러니하게도 데이터 모델이 유연한 것이 좋다. ‘마법의 막대기’를 흔들면, 캐나다의 누군가 숫자와 문자로 구성된 캐나다 우편번호를 등록할 수 있도록 만들기 위해서이다(이 경우에도 경직된 패턴으로). 이런 모델을 구현하는 데 시간이 걸리기 마련이다.

작동하는 구조가 필요하다. 그러나 변화나 변경은 이런 구조를 무효로 만들 수 있다. ‘끝이 없는 전쟁’이다. 한 사람 당 하나의 엔트리가 있는 것이 좋다. 그런데 이름을 바꾼 후에도 사람을 추적하고 싶어 지고, 2개의 엔트리가 만들어진다. 그러면 둘 모두 그저 그런 것이 된다.

‘거짓(Falsehood)’ 발생
일부 프로그래머는 ‘참’으로 보이는 단순한 명령 구문도 코드로 렌더링을 시도하기 전까지 별도로 분류하기 좋아한다. ‘하루는 24기간’이라는 구문이 이런 ‘거짓’에 해당된다. 언뜻 보기에 ‘참’으로 보인다. 그러나 서머타임 시간이 시작되거나 끝나는 날은 해당이 되지 않는다. 즉, ‘참’이 아니다. 더구나 매년 이런 날이 바뀌고, 유럽에서 일광 절약 시간이 시작되고 끝나는 날은 미국과 다르다. 다시 말해, 미국은 하루가 24시간이지만, 유럽은 25시간인 날이 있다.

프로젝트마다 이런 ‘거짓’을 새로 발견하게 될 것이다. 우리는 새 ‘거짓’이 쉽게 해결할 수 있는 ‘거짓’이고, 사용자가 이와 관련된 ‘불일치’ 중 하나에 직면했을 때 크게 화를 내지 않기 바랄 수밖에 없다.

복잡성 문제
프로그래머는 자신이 작업하는 시스템을 단순화시키기 원한다. 그러나 사용자와 이해당사자는 가능한 비즈니스 가치를 추구하면서 추가 ‘사례'와 기능을 추가해 시스템을 향상시키기 원한다. 기능은 좋다. 그러나 더 ‘스마트'하고 나은 기능을 추가하면 논리 또한 추가된다. 그러면서 논리가 기하급수적으로 복잡해지는 경우도 있다.

쉽게 추가할 수 있는 기능도 있다. 그러나 의도하지 않은 결과를 촉발하는 기능도 있다. 이 경우, 예상 못했던 문제에 대한 결정을 내리기 위해 계획에 없던 미팅을 더 많이 하게 된다. 코드에 또 다른 계층을 추가하거나, 데이터베이스에 행을 추가할 때 각별히 주의를 기울여야 한다. 그러지 않을 경우, 프로젝트가 걷잡을 수 없이 복잡해지고, 일정이 훨씬 더 많이 지연될 수 있다.

기능을 추가시키는 디자인 검토
디자인 검토는 개발 프로세스에 반드시 필요한 부분이다. 그러나 디자인 검토에 목적을 둔 미팅 때, 모든 사람이 소프트웨어 기능을 추가시키기 원하고, 개발자가 이런 기능 추가 요청을 기꺼이 받아들이는 경우에만 해당된다. 현재 진행하는 프로젝트 범위를 넘어서는 것이 분명해 이런 요청을 거부할 수 있는 때도 있지만, 이것이 명확하지 않은 요청들도 많다. 많은 기록이 필요한 요청들이다. 쉽게 추가할 수 있는 기능인지, 어려운지 여부를 파악하는 것에만 몇 시간을 투자해야 할 수도 있다.

그러나 이해당사자와의 디자인 검토를 피할 방법은 없다. 바람직한 개발 프로세스의 일부이기 때문이다. 따라서 추가할 수 있는 기능, 버전 2.0 또는 버전 5.0으로 남겨둘지 결정하기 위해 코드를 변경하는 일은 피할 수 없는 운명과 같다.

때로는 느린 것이 바람직하다
프로젝트 진행이 느린 것에 화가 날 수도 있지만, 소프트웨어 개발이 지연되는 것을 '버그’가 아닌 ‘기능’으로 봐야 한다. 중요한 부분을 서둘러 재촉할 경우 단점과 문제점이 발생하게 된다. 코더가 시간을 투자할 경우, 우리는 그 토대가 튼튼하고, 논리가 타당하도록 만전을 기해야 한다. 속도에 대해 불평을 하는 것은 집중에 방해가 되고, 프로젝트에 위험을 초래한다. 개발자들이 자신의 일에 집중하도록 놔둘 필요도 있다. 

*Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다.
 

ciokr@idg.co.kr

 




2019.08.02

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

Peter Wayner | CIO


이해당사자의 변덕
소프트웨어 개발자가 자신의 업무 속도를 통제한다고 생각할지 모르겠다. 그러나 사실 그렇지 않다. 주어진 과업이 바뀌는 경우가 많기 때문이다. 고객이나 조직 내 다른 이해당사자가 많은 것을 바꿔 초래된 문제를 놓고 소프트웨어 팀을 비난하는 것은 부당하다. 이들은 계속해서 새로운 수정, 새로운 보완(강화)을 요구한다. 때론 아주 별것 아닌 듯 작은 것을 추가하지만, 이것이 아주 어렵고, 지금까지 달성한 많은 것을 망치는 결과가 초래될 수도 있다.

경직된 데이터 구조
데이터는 길들이기 힘든 야수이다. 그런데 소프트웨어 개발 업무 가운데 상당 부분은 밤에 이 야수를 자신의 외양간으로 몰고 가는 것이다. 가장 긴장되는 업무 중 하나는 데이터 모델을 구현하고, 데이터베이스가 적시에 완벽하게 정보를 저장하도록 만드는 것이다. 

또 데이터 모델은 대개 경직되어 있다. 예를 들어 설명하면, ZIP 코드 필드에는 9자리 숫자의 ZIP 코드만 있어야 한다. 그러나 한편으로는 아이러니하게도 데이터 모델이 유연한 것이 좋다. ‘마법의 막대기’를 흔들면, 캐나다의 누군가 숫자와 문자로 구성된 캐나다 우편번호를 등록할 수 있도록 만들기 위해서이다(이 경우에도 경직된 패턴으로). 이런 모델을 구현하는 데 시간이 걸리기 마련이다.

작동하는 구조가 필요하다. 그러나 변화나 변경은 이런 구조를 무효로 만들 수 있다. ‘끝이 없는 전쟁’이다. 한 사람 당 하나의 엔트리가 있는 것이 좋다. 그런데 이름을 바꾼 후에도 사람을 추적하고 싶어 지고, 2개의 엔트리가 만들어진다. 그러면 둘 모두 그저 그런 것이 된다.

‘거짓(Falsehood)’ 발생
일부 프로그래머는 ‘참’으로 보이는 단순한 명령 구문도 코드로 렌더링을 시도하기 전까지 별도로 분류하기 좋아한다. ‘하루는 24기간’이라는 구문이 이런 ‘거짓’에 해당된다. 언뜻 보기에 ‘참’으로 보인다. 그러나 서머타임 시간이 시작되거나 끝나는 날은 해당이 되지 않는다. 즉, ‘참’이 아니다. 더구나 매년 이런 날이 바뀌고, 유럽에서 일광 절약 시간이 시작되고 끝나는 날은 미국과 다르다. 다시 말해, 미국은 하루가 24시간이지만, 유럽은 25시간인 날이 있다.

프로젝트마다 이런 ‘거짓’을 새로 발견하게 될 것이다. 우리는 새 ‘거짓’이 쉽게 해결할 수 있는 ‘거짓’이고, 사용자가 이와 관련된 ‘불일치’ 중 하나에 직면했을 때 크게 화를 내지 않기 바랄 수밖에 없다.

복잡성 문제
프로그래머는 자신이 작업하는 시스템을 단순화시키기 원한다. 그러나 사용자와 이해당사자는 가능한 비즈니스 가치를 추구하면서 추가 ‘사례'와 기능을 추가해 시스템을 향상시키기 원한다. 기능은 좋다. 그러나 더 ‘스마트'하고 나은 기능을 추가하면 논리 또한 추가된다. 그러면서 논리가 기하급수적으로 복잡해지는 경우도 있다.

쉽게 추가할 수 있는 기능도 있다. 그러나 의도하지 않은 결과를 촉발하는 기능도 있다. 이 경우, 예상 못했던 문제에 대한 결정을 내리기 위해 계획에 없던 미팅을 더 많이 하게 된다. 코드에 또 다른 계층을 추가하거나, 데이터베이스에 행을 추가할 때 각별히 주의를 기울여야 한다. 그러지 않을 경우, 프로젝트가 걷잡을 수 없이 복잡해지고, 일정이 훨씬 더 많이 지연될 수 있다.

기능을 추가시키는 디자인 검토
디자인 검토는 개발 프로세스에 반드시 필요한 부분이다. 그러나 디자인 검토에 목적을 둔 미팅 때, 모든 사람이 소프트웨어 기능을 추가시키기 원하고, 개발자가 이런 기능 추가 요청을 기꺼이 받아들이는 경우에만 해당된다. 현재 진행하는 프로젝트 범위를 넘어서는 것이 분명해 이런 요청을 거부할 수 있는 때도 있지만, 이것이 명확하지 않은 요청들도 많다. 많은 기록이 필요한 요청들이다. 쉽게 추가할 수 있는 기능인지, 어려운지 여부를 파악하는 것에만 몇 시간을 투자해야 할 수도 있다.

그러나 이해당사자와의 디자인 검토를 피할 방법은 없다. 바람직한 개발 프로세스의 일부이기 때문이다. 따라서 추가할 수 있는 기능, 버전 2.0 또는 버전 5.0으로 남겨둘지 결정하기 위해 코드를 변경하는 일은 피할 수 없는 운명과 같다.

때로는 느린 것이 바람직하다
프로젝트 진행이 느린 것에 화가 날 수도 있지만, 소프트웨어 개발이 지연되는 것을 '버그’가 아닌 ‘기능’으로 봐야 한다. 중요한 부분을 서둘러 재촉할 경우 단점과 문제점이 발생하게 된다. 코더가 시간을 투자할 경우, 우리는 그 토대가 튼튼하고, 논리가 타당하도록 만전을 기해야 한다. 속도에 대해 불평을 하는 것은 집중에 방해가 되고, 프로젝트에 위험을 초래한다. 개발자들이 자신의 일에 집중하도록 놔둘 필요도 있다. 

*Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다.
 

ciokr@idg.co.kr

 


X