기고 | 정부 SW 프로젝트로부터 얻는 3 가지 아이디어

필자는 애자일 기법을 지지한다. 그러나 정부 프로젝트에서는 애자일 프랙티스를 거의 찾아볼 수 없다.. 간트 차트(Gantt Chart) 와 PERT 다이어그램을 대중화하는 이들이 현대 소프트웨어 프로젝트에 도움이 될 수 있을까? 그리고 Healthcare.gov의 거대한 실패와 관련 있었던 사람들을 잊어서는 안 된다.

그러나 한 현자는 "지혜란 자신보다 어리석은 사람으로부터 배울 수 있는 능력이다"고 말했다. 오늘은 우리가 정부로부터 배울 수 있는 3 가지 소프트웨어 개발법에 관해 알아보도록 하자.

일몰법(Sunset Laws)을 이용하자
똑똑한 정부 관료들은 법률의 자동 파기, 즉 일몰 규정을 지지하곤 한다. 시간이 지나면서 기준이 바뀌는 민사 및 규제 문제에 대해서는 더욱 그렇다. 일몰 규정이 없다면 적절하지 못한 법률은 의회의 의안 또는 대법원의 결정에 의해서 삭제해야 한다. 이 때문에 지역, 주, 연방 법전에는 무용지물일 뿐 아니라 어리석은 조항이 넘쳐난다.

IT 부문에서도 변하지 않는 규칙과 요건으로 인해 같은 일이 발생한다. 뛰어난 비즈니스 분석가라면 시스템 개선 중 거의 발생하지 않는 상황을 처리하도록 수립된 형편 없고 과장된 비즈니스 프로세스를 다수 발견할 수 있을 것이다.

이런 포 시그마(Four Sigma) 이벤트는 직접 처리하는 것이 더 나으며, 자동화는 더 많은 문제를 야기할 가능성이 있다. 메인프레임(Mainframe) 융합 프로젝트를 분석하는 스탠디시 그룹(Standish Group)의 연구에서 이런 현상을 탐구했다. 결과는? 기존 코드의 기능 중 90% 가 더 이상 필요 없었다.

교훈 : 중요한 소프트웨어 요건을 위해 사용자들이 (또는 기타 실행자들이) 처음부터 시작해 필요를 다시 파악하도록 하는 자동 만료일을 실시한다. 이것이 중요한 이유는 가짜 요건의 이행을 막을 수 있기 때문이다.

시험할 수 없다면 요건이 아니다
이 교훈은 야생 거위 쫓기 요건을 피하기 위해 공군 시스템 사령부가 사용한 (그리고 여전히 사용하고 있을) 아이디어를 조합해 얻은 것이다. 폭포수 방식의 세계에서는 제공 가능한 모듈 또는 시스템의 모든 세부사항을 명시해야 하는 방대한 문서를 발견하는 경우는 흔하다.

하지만 이런 두꺼운 책들에서는 저자가 방향을 못 잡고 요건의 모호함이나 노골적인 상충부분을 인지하지 못하는 부분을 흔히 포함하고 있다. 수용성을 구성하는 정확한 조건을 명시하는 요건 프로세스를 실시하면 이런 문제가 드러난다.

다소 극단적으로 적용하면, 시험 코드를 작성하고 검증할 때까지는 실행 가능한 코드를 작성할 수 없다. 이는 특히 익스트림 프로그래밍(Extreme Programming)의 시험 우선 또는 시험 중심적 개발법의 정의지만 그 시초가 되는 민첩한 폭포수 같은 프로젝트에도 동일하게 적용할 수 있다.

프로젝트 전반에 걸쳐 이 교훈을 따른다면 사용자 수용 시험은 단순한 시연 또는 교육 세션에 불과하기 때문에 굳이 수행할 필요가 없다. 사용자가 테스트 구체화에 에너지를 쏟을 생각이 없다면 프로젝트 종료 시 거부할 수 있는 권한을 얻지 못한다. (물론, 기관의 정책이 닿을 수 없는 일관성과 장기적인 기억이 있을 경우의 이야기이다).

정찰가를 원한다면 대가를 지불해야 한다
CFO와 폭포수형 프로젝트를 선호하는 사람들은 정찰가 프로젝트를 선호한다. 관리가 쉬울 뿐 아니라, 확인사항을 작성하고 제공물이 UAT 마감선을 지나칠 때 체크만 하면 된다.

그러나 소프트웨어에서는 특히 기존의 CRM 시스템을 업그레이드 할 때는 알려지지 않은 비용의 덫이 존재하기 마련이다. 비즈니스 프로세스 세부사항, 기존 스토어의 데이터 품질 , 실행 가능한 통합 코드의 기존 버그, 기능적 수용 기준이 바로 그것이다.

매우 세부적인 요건 문서 없이 정찰가 입찰서를 제출하려는 벤더는 바보이거나 "알려지지 않은 것"을 처리하기 위한 주문 변경서를 끝없이 발생할 수 있다고 생각하는 것이다.

진정한 정찰가 프로젝트를 뒷받침하기 위해 충분히 세부적인 요건 문서를 작성할 수 있음은 자명한 사실이다. 하지만 프로젝트 입찰에 앞서 이 모든 노력을 기울일 수 있을까? 그리고 궁극적인 문제가 남아 있다. "이런 요건 문서의 정확도는 얼마나 유지될까?"

정찰가 프로젝트의 대가는 스스로 많은 것을 처리해야 하거나 선택한 통합자와 함께 진행하는 검토 프로젝트가 될 것이다. 대형 정부 소프트웨어 프로젝트에서 요건 문서화와 예산 합리화에 소요하는 시간은 프로젝트 납기에 소요되는 시간보다 길 수도 있다.

필자는 민첩함이란 "통합된 사양 프로세스"를 단축시켜 이런 문제를 방지하는 것이라고 말하고 싶다.

하나의 통합된 프로젝트는 각각 작은 것들을 검토하는 일련의 소규모 프로젝트로 다시 정의할 수 있다. 심지어 검토가 끝나기도 전에 프로토타입 개발이 시작된다. 수 주 안에 기능이 납품된다. 요건 문서를 실제로 작성하는 경우는 없으며, 그 이유는 실제 문서와 시스템 시험에 이미 포함되어 있기 때문이다.

*David Taber는 ‘세일즈포스닷컴 성공의 비밀(Salesforce.com Secrets of Success)’의 저자며 세일즈포스닷컴의 공식 컨설팅 업체인 세일즈로직스 CEO다. ciokr@idg.co.kr