문제는 속도가 아니라 방향과 제어이다.

다른 산업과 달리 SW 산업은 제품을 만들어내는 기간을 정확하게 예측하기 어렵다는 것이다. 지금 진행되고 있는 프로젝트들을 포함해서 그동안 수많은 프로젝트들은 일정 관리라는 고유의 영역에서 전체 SW 개발 주기를 항목 단위별로 매일, 매주, 매월로 개발 상태를 관리하지만, 정해진 시간 내에 SW를 완성시키기란 상당히 힘들다는 것을 늘 느낀다.

만일, 개발 속도(velocity)를 수치로 표현할 수만 있다면, SW 제품을 만드는데 걸리는 시간을 계산할 수 있을 것이다. 따라서, 모든 프로젝트에서는 개발 속도, 즉 개발 생산성을 그 어느 것보다도 더 중요하게 생각하고 이를 매일 관리하도 한다. 개발 속도는 당연히 그 이면에 개발 범위(scope)라는 제약 변수가 있지만, 개발 범위는 늘 애매모호한 형태로 식별/분석되어서 기능이라는 단어로 포장되어 일정을 예측하게 만든다. 즉, 개발 속도(생산성)라는 단어로 늘 범위나 비즈니스 영역은 그 우선순위가 밀려나게 된다. 범위에 일정을 조정하거나 조율하는 형태가 아니라, 변화(증가)하는 범위는 고정된 일정에 맞추는 형태가 된다.

SW 개발에 있어서 문제는 허용된 고정 일정 내에 증가하는 범위의 기능을 구현한다는 것이다. 개발 속도는 늘 강력한 압박 속에서 경쟁적으로 몰아치지만, 비즈니스 관점의 요구사항이나 분석 수준은 초반의 문서들이 파일서버에 한 구석에만 틀혀박혀서 아무도 참고하지도 않은채 고이 모셔두고 있다는 것이다. 실용주의 입장에서는 소스 코드와 (설계) 문서의 간격을 최대한 줄이려는 노력들을 하고는 있지만, 소스 코드의 분량이 늘어나면 늘어날수록 점점 더 관리해야 하는 부가적인 (설계) 문서들이 늘어만 간다. (혹은 문서들은 점점 오래되어 현시점의 구현 내용을 반영하지 못한채 버리지도 변경하지도 못한채 흉물처럼 방치해 놓는다)

프로젝트 일정 산정, 과연 합리적일까?

프로젝트 초반, 수많은 사람들이 프로젝트를 착수하기 위한 다양한 활동들을 수행하는데, 그중에서 일정 산정은 가장 중요한 활동 중에 하나이다. 전체 범위를 구획화시키고 그 구획화된 업무들을 다시 중소규모의 업무로 나누어서 최소 단위의 업무로 구분하여 각 업무의 일정들을 산정하는 방식이 WBS(Work Breakdown Structure) 방식이다. MS에서 만든 MS Project가 대표적인 WBS 도구이며, 대부분의 프로젝트는 어느새 이 WBS 기반의 일정을 만들게 된다.

WBS는 나뉘어진 업무들이 상호 배타적(mutually exclusive)이어야 하며, 전체의 합이 100이 되도록 구성해야 한다. 물론, WBS가 일정을 체계적으로 관리하기 위한 하나의 기법으로 채택하는 것은 프로젝트의 수행자들의 선택이겠지만, 모든 프로젝트가 오로지 WBS 하나에만 의존하는 형태는 결코 바람직하지 못하다. 프로젝트에서 늘 문제가 되는 부분은 WBS 상에 표기된 기능이 과연 WBS로 관리할 수 있는 성격인 것인가이다.

요즘의 SW가 기능 체계도(functional decomposition)나 Top-Down 방식의 분해로 만들어지는 성격들이 아니기 때문이다. 그리고, 이와 같은 기법으로 기능을 명확하게 분류하기란 여간 까다롭고 시간이 걸리는 작업이기 때문에 짧은 프로젝트 기간에 이와 같은 기능 분류를 한다는 것은 거의 현실적이지 못하다. 예를 들어, A라는 기능이 해당 내용을 저장하는 기능이라면, 그 기능 속에는 다양한 업무와 다양한 제어 로직들이 포함할 수 있어서 단순한 저장이 아닌 조회/수정/삭제가 같이 발생하는 기능이 될 수도 있다. 이는 비즈니스 환경의 변화나 기술의 발전과도 무관하지 않은 것으로 높은 사양의 PC나 클라이언트가 나타나면서 한번에 더 많은 기능을 경쟁적으로 추가하기도 하며, 비즈니스 환경(고객의 요구)이 되도록이며 더 많은 자동화 요소를 요구하기 때문이다.

현실적인 관점에서 트리 형태의 기능 분류는 비즈니스 모델링의 상위 레벨 수준의 분류 정도만 가능하며, 시스템 레벨에서의 기능 분류를 모두 식별하기란 만만치 않은 작업이다. 그리고, 이러한 작업을 단순히 몇사람만(혹은 한명만) 작업해서 전체 일정을 결정한다는 것은 지금의 현실은 전혀 받아들이기 힘든 상황이다. (받아들이기 힘든 상황이 이루어지는게 현실이긴 하지만)

결론적으로, 프로젝트 일정 산정은 결코 신뢰해서도 안되며 신뢰될 수 있는 예측치에 불과하다. 그렇다고 계획을 세우는게 의미없는 활동이라는 의미가 아니다. 계획은 계획을 수립하는 활동 그 자체로 의미가 있다. 계획을 세우는 동안 수많은 연결고리들을 생각해볼 수 있으며. 특히 이러한 수립 활동을 단지 혼자나 몇몇이 아닌 전체가 공유한다고 하면 전반적인 프로젝트 범위를 사전에 미리 공유할 수도 있을 것이다. 산정된 프로젝트 일정은 결코 맹신하거나 꼭 지켜야 하는 마일스톤과는 다르다. 진척율이라는 개발 활동 결과 역시 수치적으로는 아무런 의미가 없을 수도 있다. 20%의 진척율이 의미하는 것이 기능의 중요한 부분이라면 이는 전체 개발 범위의 80%에 해당할 수도 있기 때문에 겉으로 드러난 수치에 대해서 민감하게 반응할 필요는 더더욱 없다. 이러한 수치가 과연 합리적이고 과학적으로 산정이 되었다면 어느 정도 현실의 진척율에 근접할 수도 있겠지만, 눈대중으로 엑셀에 수치를 적어서 관리하는 형태는 결코 프로젝트 일정 관리에 전혀 도움이 되지 못한다.

프로젝트 일정 산정 방식은 지금의 방식과는 다른 접근 방식을 취할 필요가 있으며, 이에 맞추어서 프로젝트가 진행되어야 한다.

범위는 과연 고정될 수 있는가?

프로젝트 관리자의 가장 훌륭한 역할 중에 하나를 꼽는 것이 고객의 끝없는 요구사항들을 쳐내거나 막는 행위로 보는 사람들도 많다. 즉, 요구사항이 변경되는 것이 가장 위험하며 이를 얼마나 효과적으로 통제할 수 있을 것인가가 PM의 중요한 역량으로 바라보는 것이다. 하지만, 요구사항이라는 단어 만큼 수많은 의미와 혼돈을 담고 있는 단어도 없다. 고객 입장에서는 단순한 기능이라고 하더라도 시스템 입장에서는 수많은 내부 설계를 바꾸어야 하는 것들이 있는가 하면, 고객은 엄청난 변화라고 생각하지만, 시스템에서는 단순히 데이터만 변경하면 되는 경우도 많다. 범위가 고정될 수 없는 속성을 가진다는 것은 고객이나 프로젝트를 수행하는 사람들에게는 모두 잘 알고 있고, 그러기에 중요한 위험 요소로 관리하고 있다.

SW 프로젝트에서는 이러한 동적인 범위를 관리할 수 있을 만한 효과적인 방법을 찾아내지 못하면 분석/설계 과정에서 모든 요구사항을 도출하고 여기에 꼬리표를 붙여서 관리하려는 욕구를 가진다. 결국 분석/설계 단계에서 고정된 범위는 개발이나 인도 단계까지에도 영향을 미치며 방향을 움직이지 못하는 차를 운전하는 것과 같은 현상을 만들어낸다. 예를 들어, 특정 구간이 차가 밀려 우회하여 다른 길로 돌아가도 큰 지장이 없고 오히려 효과적임에도 불구하고 방향을 움직이지 못하는 핸들로 인해서 앞에 밀려있는 차가 다 빠져나갈때까지 한없이 기다려야만 하는 현상이 나타나기도 한다.

범위(scope)라는 단어가 갖는 늬앙스로 인해서 촘촘한 식별작업이 SW를 구현할 범위를 결정짓는다는 환상을 갖게 만든다. 통상 범위는 하나의 뷰(view)로 정리되기 어려운 성질을 가지고 있다. 이해관계자의 관점(perspective)에 따라서 동일한 단어라 하더라도 이해하는 정도의 차가 존재하기 마련이며, 이를 고정한다는 것 자체가 SW의 본질적인 목적을 희석시키는 결과를 만든다. 때로는 추정(estimation)이라는 단어로 범위를 다른 해석을 바라보게 만드는 경우도 있다. 추정은 기반이 되는 여러 방향성들 중에서 최적의 방향을 결정짓는 방식으로 최소한 이전에 시도했던 방향을 이미 가지고 있어야 한다. 하지만, 범위 확정과 같은 의미로 추정을 사용함으로써 추정된 결정은 고착화된 결론으로 받아들여 추정을 잘못한다는 비난을 만들어내기도 한다. 추정은 말 그대로 잘못될 수 있음의 여지를 포함하는 단어로 추정이 잘못되었다고 하더라도 방향을 잘 유지한다면 그 자체가 비난받을 일은 아니다. (이는 마치 잘못된 골목길로 차를 모는 것과 같은 현상으로 제대로 된 길을 가기 위한 수많은 시도들 중에 하나이며, 그러한 시도가 전체 범위를 알아가는 노력으로 의미가 있을 수 있다.)

지도를 펼쳐놓고 (SW 개발에서 확정된 지도를 가지기란 불가능하다. 듬성 듬성 목표 지점만을 가지고 있으며, 이러한 목표 지점을 표시한 지도를 가지는 것 자체 역시 상당히 어렵다) 정해진 경로를 통해서 진행하는 방식을 SW 개발이라고 보면, 그러한 지도 역시 바뀐다는게 큰 특징 중에 하나이다. 지도 위에서 높은 등고선을 가진 산으로 표시되었던 내용은 시간이 지남에 따라 낮은 언덕이 되기도 하며, 앝은 개울가로만 보였던 내용은 깊고 넓은 호수로 변하는게 비일비재한 현상이다. SW 개발에 있어서 범위라는 제약사항은 결코 고정된 형태가 될 수 없는 성질을 가지고 있다.

아키텍처는 과연 고정될 수 있을까?

아키텍처를 논하려면 상당한 인내가 필요하고, 다양한 정의들을 필요로 한다. SW 개발에 있어서 아키텍처를 어떠한 관점에서 바라볼 것인가는 늘 논란거리가 되며, 그러한 논란을 어떻게 합일점을 이루는가도 역시 보이지 않는 많은 노력이 들어간다. 아키텍처는 SW의 틀과 같기 때문에 아키텍처를 얼마나 빨리 고정시킬 수 있을 것인지가 SW 개발에 중요한 요소이기도 하다. 만일 SW 아키텍처를 고정적인 요소로 본다면 SW의 비기능 요구들 역시 고정적이라고 봐야 한다. 하지만, 비기능 요구들 역시 시간의 흐름에 따라서 바뀌고 그 기준치 역시 바뀌게 마련이다. 지금 중요하게 생각하는 비기능들이 법제도나 비즈니스 환경에 따라서 얼마든지 바뀔 수가 있다. 예를 들어, 사용자 정보에 대한 보안이 사회적인 이슈로 나타나면서 보안성의 품질 요소는 인터넷 환경에서 상당히 중요한 요건이 되기 시작했다. 기존에 이러한 품질에 대해서 전혀 신경쓰지 못했던 SW라면 이러한 보안성을 어떻게 강화시킬 것인지가 SW 아키텍처에 표현되고 영향을 미치게 되어 있다. 보안에 대한 문제가 계속해서 나타나는 이유 중에 하나는 SW 아키텍처에 이러한 품질을 애초부터 크게 고려하지 않았다는 반증이기도 하며, 이미 많은 기능을 안고 있는 SW 아키텍처에 이러한 비기능 요소를 강화시키기에는 너무나도 많은 것들에 영향을 미치기에 힘든(혹은 많은 작업을 필요로 하는) 작업이 될 가능성이 높다.

즉, SW 아키텍처는 고정될 수 있는 성질을 지닌 형태로 설계되는 것보다 언제든지 SW를 바라보는 관점에 따라서 바뀔 수 있는 형태로 설계되어야 함을 의미한다. 아키텍처가 바뀔 수 있다(혹은 진화할 수 있다)라는 전제는 SW를 만드는 입장에서도 상당한 부담이 될 수 밖에 없다. 아키텍처는 최소한 품질 속성에 대해서 얼마든지 확장 가능하거나 대체 가능한 형태로 만들어져야 됨을 의미한다. 이는 비단 SW 아키텍처 설계만을 의미하는 것은 아니다, 그러한 형태로 만들어진 SW 아키텍처에 얻혀지는 기능 역시 동일한 품질 기준을 달성해야 됨을 의미한다. 확장 가능한 아키텍처 형태로 클라우드 개념을 도입했다면, 클라우드를 기반으로 하는 비즈니스 로직들이 느슨한 관계로 연결되지 않는 한 아무리 아키텍처를 바꾸어 본들 비즈니스의 유연성을 보장하기는 힘들다.

브레이크는 더 빨리 달리기 위한 장치이다.

SW 개발에서 개발속도는 많은 부분에 영향을 미치며 따라서 개발속도와 관련된 것들이 어떠한 형태로 영향을 미치는지를 가늠해볼 필요는 있다. 즉, 계기판에 나타난 속도계의 수치만을 보고 개발속도를 가늠하기도 한다. 그렇지만, 브레이크라는 장치가 없으면 자동차는 속도를 내기 힘들다. 브레이크 없이 자연적인 법칙으로 차를 세워야 한다면, 자동차는 빠른 속도를 낼 수 없다. 최소한 자연적으로 멈출 수 있을 만한 속도로 자동차를 몰아야 위급 상황에서 멈출 수 있다. 브레이크가 있다라는 의미는 얼마든지 원하는 지점에서 차를 멈출 수 있고, 다시 원하는 속도로 차를 몰 수 있다라는 의미이다.

Modarres Highway / Tehran by Hamed Saber

SW 개발에서 브레이크가 없는 개발속도는 더디게 마련이다. 브레이크는 자동차의 크기와 종류에 따라서 그 장치가 다르며, 수동이나 자동에 따라서 움직이는 메커니즘이 다르다. SW 개발에서 속도를 제어하기 위한 장치들은 오히려 속도를 높일 수 있게 하기 위해서 필요하다. 개발자들의 능력과 개발 문화에 어울리는 개발 환경, 전반적인 개발 내용을 파악할 수 있는 높은 수준의 문서들, 핵심내용을 표현하는 설계 문서, 지속적인 품질 향상을 위한 메커니즘들. 이러한 모든 것들은 개발 속도를 저해하는 것처럼 보이지만, 멈춰야 할 때와 어디로 가야하는지를 알려주는 브레이크나 핸들과 같은 것들이다. 브레이크나 핸들을 단순히 해당 기능만을 수행하도록 만들 수도 있겠지만, 좀더 운전자가 편리한 기능을 부여할 수도 있다. 가야하는 길들을 사전에 알려주는 기능이 추가된다면, 미리 방향성을 인지하여 마음의 준비를 할 수 있거나 차선을 바꿀 수도 있다. 기능이 사용되는 최종 모습을 알려준다면, 그리고, 현재 만들고 있는 기능이 그 안에서 어떤 부분을 차지하고 있는지를 안다면 방향을 바꾸거나 수정하는데 최소한 설계 측면의 고려를 하여 이를 반영할 수도 있을 것이다. 차를 멈추는데 급작스런 브레이크를 작동시키는 대신에 여러차례 나누어서 브레이크를 조정한다면 좀더 안전하게 (안락하게) 차를 제어할 수 있을 것이다. 마찬가지로 갑자기 설계 문서를 만들거나 품질을 점검하는 것보다는 점점 기능이 풍부해지는 과정을 설계 문서와 같이 표현하거나 품질을 자동으로 매일 점검하는 장치를 둔다면 SW를 좀더 안전하게 만들 수 있을 것이다.

SW는 겉으로 보기에 사람을 투입해서 완성해가는 인력 기반의 공정을 가지는 것처럼 보이겠지만, 브레이크와 핸들이라는 장치를 통해서 자동차가 더 빠르고 안전하게 달릴 수 있듯이 SW 개발과 관련된 사람들이 인지하고 공감할 수 있는 장치들을 통해서 제대로 된 방향과 그에 맞는 제어를 할 수 있는 분위기 역시 무시못할 요소 중에 하나이다.