금새 화석이 되거나 괴물이 돼버릴 시스템을 구축하고 싶은 게 아니라면, 그럴듯해 보이는 다섯까지 고정관념을 버려야 한다.
데이터 마이그레이션과 시스템 개발 프로젝트의 많은 사례에서 필자는 정해진 기한 내에, 예산에 맞춰 프로젝트를 완수하지 못한 사례들을 봐 왔다.
그리고 이 사례들에서는 몇 가지 공통점이 발견됐으며 이를 공유하고자 한다.
시스템 개발뿐 아니라 대규모 클라우드 프로젝트에서도 차질은 생긴다.
이런 좋지 못한 결과물에 대한 대립적인 장려책, 부적절한 메트릭스, 협업 인프라의 부재 등 다수의 기여 요인이 존재하지만 이런 것들이 근본 원인은 아니다.
뭔가 일이 잘못되고 있다면, 협업이나 운영에 문제가 있는 것이 아니다.
개발 프로젝트는 불필요한 코드를 낳는다
더 스탠디시 그룹(The Standish Group)은 대규모 Y2K 프로젝트 분석을 수행하면서 전환 프로젝트의 성공보다는 전환되는 구형 코볼 시스템을 평가했다. 해당 기업은 본래의 프로젝트 규모가 클수록 현재 실제로 기능을 사용하는 코드를 찾아보기 어렵다는 사실을 발견했다.
이 중 일부는 물론 이런 거대 시스템이 20년 이상 발전하는 과정에서 수명과 관련 있었다. 하지만 이것은 단지 규모가 클수록 소모적인 프로젝트가 될 가능성이 높다는 점만을 시사할 뿐이다.
2,000만 줄의 소스 코드로 된 청구서 프로그램을 유지한다고 할 때 그 중 절반이 대체 무엇을 하고 있는지 알 수 없는 상황을 상상해 보자.
메인프레임 프로젝트 그룹에서 분석했을 때, 기존 프로그램 기능의 90% 이상을 새로운 대체 시스템에서는 재생성할 필요가 없다는 것을 발견했다.
여기서 핵심은 과거에 이 프로그램의 모든 기능을 위해 자금과 노력을 투자했지만 실제로 비즈니스 목적을 달성한 경우는 한시적이었거나 최악의 경우에 단지 상상의 수준에 머물렀다는 점이다.
건설 업계의 비유를 빌리자면 우리는 개발 프로젝트에 과잉 투자하지 않기 위해서 가치 공학(Value Engineering)을 끊임없이 적용해야 한다.
그리고 프로젝트를 진행하면서 매 순간마다 "이 문제를 해결할 수 있는 더 간단한 방법이 없을까?"라는 질문을 던져야 한다. 이것은 미시적 수준에서 무언가 섹시하거나 우아한 것에 대한 ‘만족스러운’ 대안을 가차없이 찾음으로써 겪는 혁신기업의 딜레마에 적용된다.
정치적인 논리와 맞서 이길 수 없다는 것을 명심하라
모든 기업에서 스트레스와 논란이 불거질 때 정치적 결정이 우세하게 된다. 의사결정의 질을 높이는 방법은 프로젝트가 처음부터 난관에 봉착하지 않도록 하는 것이다.
다음에서 말하는 5가지 ‘아이디어’는 어떤 개발 프로젝트라도 망가뜨릴 수 있을 것이다.
첫째, 시스템 사양서가 꼼꼼해야 성공적인 프로젝트를 만든다. 자주 등장하는 말이지만 이것은 비즈니스 부분은 적게 다루고 경제적인 목표는 전혀 다루지 않는, 과하게 자세하고 두꺼운 기술서를 의미한다.
운이 없다면 무언가 구축하기 너무 어려운 것을 명시하여 그 가치보다 더 큰 비용을 지출하게 될 것이며, 프로젝트의 중반 즈음에서야 그런 사실을 깨닫게 될 것이다. 그 해결책은 마음가짐을 바꾸는 것이다.
비즈니스 애널리스트들이 비즈니스적 목표를 설정하도록 하고 소프트웨어 이행에 관한 세부사항은 해당 팀에게 맡기도록 하자.
둘째, 그래도 시스템 사양서가 꼼꼼해야 성공적인 프로젝트를 만든다며 다시 논의하다. 사양서는 프로젝트가 시작되기 전 분석 및 관찰 단계에서 작성되는 경향이 있다. 실제 프로젝트 개발이 시작되면 일반적으로 사양서 작성은 멈추게 된다. 하지만 필요조건의 영향은 종종 사양서 작성을 완료한 후에야 이해할 수 있다.
게다가 비즈니스적 필요조건은 프로젝트 중간에 종종 극적으로 수정되기도 한다. 사양서는 짧은 문서로 만들되 꾸준히 발전시키고 협업 시스템 내에서 자동으로 수정될 수 있도록 하면 더욱 좋다.
셋째, 기존 시스템과 동일한 기능을 제공하도록 노력하라. 진정한 의미의 개척 프로젝트는 매우 드물며 대부분의 경우에 프로젝트가 기존의 시스템을 대체하거나 업그레이드, 또한 개선하는 데 그친다.
문제는 기존에 존재하는 시스템이 이상적이기 않기 때문에 프로젝트를 진행하는 것이며 해당 시스템이 이해하기 힘든 비즈니스 프로세스 생태계의 일부분을 구성한다는 점이다. 결과적으로 대체 시스템의 배치를 시작하면 알 수 없는 부작용이 발생하게 된다.
여기서 해결책은 프로젝트를 비즈니스 시스템이 일개 구성요소에 불과한 비즈니스 프로세스에 대한 업그레이드로 생각하는 것이다. W. 에드워드 데밍은 이런 말을 남겼다. "지금 하고 있는 일을 비즈니스 프로세스로써 설명할 수 없다면, 당신은 자신이 무엇을 하고 있는지 모르는 것이다."
넷째, 타사의 사례와 예산을 기준으로 활용하라. 자주 겪는 일이지만 비즈니스 사례는 자신이 기업에 실제로 도움이 되는 프로젝트가 무엇인지 알고 있다는 환상만을 심어줄 뿐이다.
여기서 해결책은 심도 깊고 지속적으로 관여해 현재 나타나고 있는 비즈니스 사례를 끊임없이 검토하는 능동적인 의사결정 루프를 프로젝트 마다 반복하는 것이다.
다섯째, 사용자에게 항상 "네"라고 대답하라. 필자가 항상 말하지만 사용자 중심적인 디자인은 단순히 UI만을 위한 것이 아니라 프로젝트 전체를 위한 것이다. 애자일이 제 역할을 하는 이유는 사용자들이 모든 단계에 참여하기 때문이다. 하지만 사용자들은 개인적인 기여자 일뿐이며 기업의 부사장이 아니다.
물론 부사장은 비즈니스적 관심을 대표하지만 뉘앙스를 왜곡시키고 문제가 존재하는 곳에서 세부사항을 무시하는 정보 거품 속에 살고 있다. 분명, 정치적으로 강력한 구성 성분에 "아니다"라고 말하는 것은 어렵다.
하지만 "네"는 말에서 가장 약한 단어다. 이 말을 너무 자주 하게 되면 우스꽝스러운 아키텍처, 과장된 필수조건, 엉성한 자원 할당, 프로젝트 실패를 경험하게 될 것이다. 클라우드 또는 애자일의 그 어떤 것도 이 문제에 대응할 수 없다.
시스템 개발 프로젝트를 승리로 이끄는 길
소프트웨어 개발에서 절대로 사라지지 않는 2가지 진리가 있다. 그런데, 알고 보면, 둘 다 완전히 잘못 짚었다.
• 소프트웨어 프로젝트는 비즈니스 환경이 바뀌지 않는 것처럼 관리할 수 있다. 이 말은 지금 만들고 있는 것이 ‘화석’이라는 뜻이다.
• 기업들은 소프트웨어 시스템을 완성하기 전에 그 결과를 예측할 수 있다. 이 말은 지금 괴물을 만들고 있다는 뜻이다.
다음에는 품위를 지키면서도 효과적인 방법으로 사용자들에게 "아니오"라고 말하는 방법에 관해 설명하겠다.
