[칼럼]IT프로젝트에서의 '불분명한' 요구사항

최영석입력 :2011/07/26 10:13

최영석

프로젝트는 모든 산업 분야에서 공통적으로 사용되는 용어다. 건설업에서는 건물이나 교량을 완공하는 개별 공사를 프로젝트라고 부르고, 제조업에서는 신제품을 개발해서 시제품 또는 양산까지 이끌어내는 것을 프로젝트라고 부른다.

IT조직에서는 기존에 없던 새로운 IT서비스(시스템)을 창조해 내거나, 기존에 있던 낡은 IT서비스를 전면적으로 개편하는 ‘큰 단위의 변경’을 IT프로젝트라고 부른다.

프로젝트가 완료된 이후의 모습들은 안팎으로 자랑스럽기 그지없다. 그러나 완성된 프로젝트의 외양 속에는 프로젝트의 과정에 숨겨져 있는 불편한 진실들이 존재하는 경우가 많다.

설비와 IT가 포함된 국내와 해외 프로젝트 현장을 모두 방문한 적이 있는 지인의 목격담에 따르면, 국내 프로젝트는 해외의 것에 비해 프로젝트 요구사항에서 구축에 이르기까지의 과정이 불분명하다고 한다. 그래서 프로젝트가 완료 되더라도 여러 가지 문제점이 발생할 가능성이 높다는 설명이다.

프로젝트에 있어 ‘요구사항’은 프로젝트의 완결성을 보장하기 위해서 필요한 기준점이 된다. 요구사항이 불분명한 프로젝트는 나머지 과정의 문제점을 야기할 뿐만 아니라, 프로젝트 이후에 발생한 결함들의 근본 원인을 찾아나가는 데 한계를 제공한다.

IT에서도 예외가 아니다. IT프로젝트에서 발견할 수 있는 불분명한 요구사항에 대해서 이야기 해보자.

■화려한 방법론, 그러나 빈약한 요구사항의 내용

국내 IT조직들이 수행하고 있거나 완료한 IT프로젝트를 들여다보면첫 단계부터 고개를 갸우뚱하게 하는 경우들이 있다. IT프로젝트의 거창한(?) 방법론에는 하나같이 프로젝트의 첫 단계로 요구사항을 정의하도록 되어 있다.

하지만 완료되거나 한창 진행 중인 IT프로젝트의 요구사항을 살펴보면, 요구사항이라기 보다는 프로젝트의 배경을 장황하게 기술하고 있거나 심지어 유사 프로젝트의 요구사항을 복사해서 기술하고 있는 경우를 목격하게 된다.

이러한 상황은 해당 IT프로젝트가 요구사항들을 제대로 담아내지 못했거나 요구사항들을 단순히 문서화하지 않은 것인지의 두 가지 중에 하나다. 필자의 경험에 의하면, 이 두 가지가 복합적인 경우가 대부분이다.

■업무를 잘 모르는 사용자 대표?

IT프로젝트의 기본 요구사항은 ‘사용자’로부터 온다. 업무의 자동화 또는 효율성을 위해 사용자가 원하는 것들이 IT프로젝트의 요구사항에 담기는 것이다.

그러나 다수 업무의 사용자들이 동시에 요구사항을 내놓게 되면 혼란이 일거나 중복되는 부분들이 있기 때문에 사용자 대표를 통해서 요구사항이 전달되게 된다. 그래서 IT프로젝트를 담당하는 IT조직은 이 사용자 대표와 의사소통을 하게 된다.

만약 사용자 대표가 사용자들의 업무를 잘 이해하지 못하거나 IT조직이 사용자 대표의 요구사항을 잘 해석하지 못하면, 해당 IT프로젝트의 요구사항은 불분명해질 수 밖에 없다.

사용자 대표가 사용자 업무를 잘 알지 못하는 상황을 언뜻 이해하기 어렵겠지만 등에 떠밀려 사용자 대표가 되거나 업무를 잘 모르는 신입 직원을 사용자 대표로 결정하는 경우는 가끔씩 있는 일이다.

노련한 IT프로젝트의 담당자는 업무 베테랑과 의사소통을 원활하게 하기 위해 ‘부족한’ 사용자 대표를 코디네이터로 활용한다. 노련한 IT프로젝트 담당자는 코디네이터 역할을 성공적으로 수행하는 부족한 사용자 대표가 ‘정상적인’ 사용자 대표의 역할을 대체할 수 있다는 것을 잘 알고 있다.

■서로 다른 언어

업무를 잘 알고 있는 사용자 대표가 IT프로젝트에 참여하더라도 또 하나의 장벽이 존재한다. 사용자 대표와 IT프로젝트 담당자간의 의사소통 문제다. 사용자 대표는 ‘업무 언어’로만 얘기 하고, IT프로젝트 담당자는 ‘IT 언어’로만 얘기하는 경우 둘 사이에는 장벽이 존재한다.

업무들을 IT서비스로 잘 ‘전환’하기 위해서는, 사용자 대표나 IT프로젝트 담당자 둘 사이의 언어 장벽을 없애야 한다. 이를 위해서는 사용자 대표가 IT언어를 배우거나 IT프로젝트 담당자가 업무 언어를 배워야 한다.

IT프로젝트는 양자간의 협상이 아니라 공동의 목적을 향한 협업이므로 한쪽 편만 상대편 언어를 배우는 수고를 하면 된다. 일반적으로 이러한 수고는 전문가로 알려진 IT프로젝트 측의 몫이다.

IT프로젝트 측이 이러한 수고를 게을리한다면 그 결과는 역시 불분명한 요구사항의 탄생이다. 업무언어를 잘 모르는 IT프로젝트 담당자는 요구사항을 제대로 적어 낼 수가 없으며 궁여지책 끝에 선택하게 되는 것 중의 하나가 유사 IT프로젝트의 복제다.

■다큐멘테이션 기술의 부족

IT프로젝트를 관찰하면서 안타깝게 느끼는 중의 하나가 문서 작성에 대한 IT프로젝트 담당자들의 태도다. IT프로젝트 담당자는 사용자 대표와 의사소통하고 프로그램화 시키는 활동을 IT프로젝트의 중심활동으로 생각한다. 그러나 문서 작성에 대해서는 귀찮거나 부가적인 활동으로 오해하고 있다.

사용자 대표와의 의사소통과정에서 발생하는 새로운 요구사항이나 기존 요구사항의 변경을 문서화하고 문서화된 요구사항을 사용자 대표와 공유하거나 합의하는 과정은 프로그램을 만들어내는 것 이상으로 중요하다.

글로벌 IT프로젝트의 경우 견고하게 작성된 문서를 통해서 사용자 대표가 요청했거나 변심(?)한 요구사항들의 이력을 잘 찾아 볼 수 있도록 도와줌으로써, IT프로젝트 전 과정에서 발생할 수 있는 이슈나 사용자 대표와의 분쟁을 성공적으로 해결해나간다.

국내 IT담당자들의 개별 기술 능력은 뛰어나지만 문서 작성을 홀대하는 문화는 지금에까지도 그 면면을 이어오고 있는 것 같다. 문서화의 노력은 IT프로젝트의 중요한 업무 중에 하나라는 것을 받아들여야 한다.

■다양한 경로의 요구사항들

IT프로젝트의 요구사항은 사용자들로부터만 오는 것이 아니다. 비즈니스에서 정보의 중요도와 IT 의존도가 높아지고 있는 사회적인 추세는, IT프로젝트에 추가적인 요구사항을 제시하고 있다. 그 대표적인 것이 정보보안 요구사항과 비즈니스 연속성 요구사항이다.

글로벌 회사의 경우 IT프로젝트의 요구사항을 전달하는 과정에 정보보안조직이나 비즈니스연속성 조직이 반드시 참여한다. 정보보안조직은 IT프로젝트를 통해 만들어지는 신규 IT서비스가 보안 취약점을 포함하지 않도록 감시할 뿐만 아니라 특별한 보안 기능을 요구한다.

예를 들면 사용자들이 조회하거나 다루게 되는 정보의 등급에 따라 민감도를 분류하고, 분류된 등급에 맞게 사용자들의 접근을 유연하게 통제하고, 이를 모니터링 할 수 있는 기능들이 필수 보안 기능으로 반영될 것을 IT프로젝트에 요구한다.

비즈니스 연속성 조직은 어떤 업무가 IT프로젝트의 대상이 되는가에 주목한다. 반나절만이라도 중단되면, 제품 생산이나 서비스 제공에 큰 피해를 주는 민감한 업무가 IT프로젝트의 대상으로 선정이 된다면, 비즈니스 연속성 조직은 IT프로젝트에게 해당 업무의 IT기능들은 어떤 일이 있더라도 반나절 이내에 다시 사용할 수 있도록 해달라고 요구한다.

그러나 민감한 업무와 민감하지 않은 여러 개의 업무들이 동시에 하나의 IT프로젝트에 포함되는 경우 문제가 발생한다. 업무 별 IT기능들의 재사용 요구 시간은 다르지만, 이것을 한 통의 IT서비스로 묶어서 단일의 재사용 요구 시간을 가지게 하는 경우, 비용 낭비가 발생하거나 민감한 업무의 재사용 요구시간을 만족하지 못하게 된다.

■탄탄한 요구사항의 중요성

언젠가 힐러리 클린턴의 의료 개혁 프로젝트에 대한 이야기를 읽은 기억이 난다. 당시 프로젝트의 모토는 ‘계획에 실패하면, 모든 것에 실패한다’ 였다. 힐러리 클린턴은 이러한 모토를 바탕으로 프로젝트의 90% 노력을 계획에 쏟았다라고 얘기했다.

IT프로젝트 계획은 요구사항에서 시작한다. 사용자 대표와 다양한 경로로 올 수 있는 IT프로젝트의 요구사항을 정확하게 담아내지 못하면 해당 IT프로젝트는 부실하게 완료될 가능성이 크다. 부실한 IT프로젝트를 통해 만들어진 IT서비스는 사용자와 IT운영조직에 더 큰 고통을 준다.

▲사용자의 업무와 맞지 않거나 오히려 업무에 부담을 주는 IT 메뉴들 때문에 높아지는 사용자들의 불만 ▲사용자 접근권한 관리 기능이 없어서 보안 감사 때마다 고통 받는 IT보안담당자 ▲끊임 없이 발견되는 프로그램 오류를 뜯어 고치느라 여전히 바쁜 IT개발담당자.

이러한 모습들은 IT프로젝트로부터 물려받은 유산의 하나인 경우가 많다. 이것들을 해결하기 위해 IT프로젝트를 거슬러 올라가봤자 불분명한 요구사항으로 인해 더 이상 얻을 것이 없다라는 사실을 발견하게 된다.

■연속적인 IT프로젝트와 운영

IT조직에서는 IT서비스를 최초로 생산해내는 ▲IT프로젝트와, 사용자들의 IT서비스 접속이 시작되는 ▲IT운영의 단계를 분리해오고 있다. 이는 프로젝트의 관리 방법과 운영에서의 관리 방법이 다르다는 데 기초하고 있다.

그러나 이러한 이분법적인 구분은 IT조직 내의 관리상의 노하우 일뿐 IT서비스를 사용하게 되는 사용자들의 입장에서는 아무런 관심이 없는 사항이다. 사용자들은 본인들의 요구사항들이 IT프로젝트를 관통하여 IT서비스를 이용하게 될 때까지 잘 전달될 것이라고 굳게 믿고 있다.

관련기사

IT프로젝트의 불분명한 요구사항이 IT운영에까지 악영향을 미치는 상황은 장기적으로 사용자들에게 IT조직의 능력에 대해 불신을 일으키게 한다. IT조직들이 도입하고자 노력하고 있는 EA나 ITIL v2와 같은 IT모델들은 [비즈니스->업무->IT프로젝트->IT운영]이 매끈하게 연결되도록 도모하는 것이 하나의 목적이다.

불분명한 IT프로젝트의 요구사항들은 이런 매끈한 연결관계를 부러뜨리고 IT능력의 불신을 초래하게 한다는 것을 IT조직들은 잘 이해하고 있어야 한다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.