SW 개발에서 가장 중요한 문서

소프트웨어를 개발하다 보면 많으나 적으나 문서 산출물이 나오게 된다. 그 중에서 가장 중요한 문서를 하나 선택하라고 하면 무엇일까.

소프트웨어 개발과 관련된 분야에는 시스템소프트웨어 개발, 응용소프트웨어 개발, 용역개발, ERP 구현, 전산실의 자체 개발, 펌웨어(Firmware) 개발 등을 들 수 있다.

이런 다른 종류의 소프트웨어 개발에 참여해본 사람들은 자기분야에서의 경험에 기준을 두고 소프트웨어를 얘기하게 된다. 산출물도 각각 다를 수 밖에 없다.

필자가 지금까지 경험해 본 소프트웨어 프로젝트를 보면 똑 같은 산출물을 요구하는 프로젝트는 한번도 없었다. 그 만큼 프로젝트가 다양하다는 것을 의미한다. 그래서 여러가지 방법론이 존재하고 새로 생겨나기도 한다.

기본적으로 대형 프로젝트를 하게 되면 수십개, 수백개나 되는 많은 산출물이 요구되고 그러다 보면 중복된 정보가 여기저기 나타나게 된다. 회사가 커지면 나타나는 피할 수 없는 관료적인 비효율성의 문제와 비슷하다. 작은 프로젝트는 2-3개의 문서만 작성해도 충분할 지 모른다.

산출물 문서중에 'Software Requirement Specification(SRS)'이라는 문서가 있다. 개발방법론이나 회사에 따라 '요구사항명세서', '요구분석서' 등 다른 이름으로 호칭되기도 하나 근본적으로 동일한 목적을 가지고 있다. 개발하려는 것이 무엇인가를 정의하는 것이다. 단순히 기능정의서만으로 생각하면 오산이다. 기능정의는 SRS의 일부분이다. 뒷부분에서 부연 설명을 하겠다.

필자가 미국의 국방산업체인 록히드와 수행한 프로젝트의 예를 들어보자. 첫 회의에서 프로젝트의 개요와 우리가 할 수 있는지를 확인했다. '록히드쪽에서 RFP(제안요청서)를 쓰고 우리가 제안서를 쓰고 진행할 것인지', 아니면 '록히드가 RFP와 함께 SRS를 쓰고 우리가 구현만 할 것인지'를 의논한 결과 SRS를 록히드가 작성하기로 하고 우리는 SRS에 기초해서 제안서를 내기로 했다. 이 제안서에는 SRS에 모든 기능이 명시되어 있기 때문에 기능에 대한 명시는 없이 가격과 개발기간 등 그 외에 제안서에 필요한 정보만 포함되었다. 물론 SRS를 우리가 작성하기로 했다면 가격은 더 비쌌을 것이다.

SRS와 함께 'Acceptance Test Plan(ATP)'도 록히드가 작성했다. 프로젝트의 검수는 주어진 ATP에 있는 테스트케이스만 통과하면 되는 것이었다. 명확하게 우리가 해야 할 일을 프로젝트 시작과 동시에 알고 있는 것이다. 이것보다 프로젝트의 내용이 더 정확히 정의될 수는 없을 것이다. ATP를 통과하는 것 자체가 검수승인을 의미한다. 그 후에 발견되는 결함들은 당연히 유지보수 비용을 받고 수정해 주게 된다. 그러므로 록히드쪽에서도 완벽을 기하려고 한다.

그 대신 우리가 SRS에 약속했던 기능을 구현해 주지 못하면 상당한 불이익을 받는다. 비용을 못 받을 수도 있고 고소를 당할 수도 있다. 소프트웨어 회사 중에 처음에는 잘 나가다가 너무 급격히 성장하면서 고객에게 무리한 약속을 해서 실패한 회사도 많다. 대부분 부실한 SRS 때문이다.

록히드 프로젝트 경우에 구현해야 하는 기능에 대해서 주관적인 판단은 거의 없었다. 커뮤니케이션에 오류가 있을 확률이 매우 낮았다는 것이다. 내가 수행했던 다른 프로젝트들이 이렇게 완벽하게 진행된 것은 아니었지만 적어도 프로젝트가 객관적으로 서로 동의한 기능구현을 목적으로 수행되어야 하는 것은 매우 중요하다.

패키지를 개발하든지 SI 업체로서 프로젝트를 수주하든지 기능을 원하는 측과 기능을 구현하는 측이 얼마나 빨리 서로 일치하느냐가 성공의 관건이다. 서로 일치하는지를 확인하는 가장 좋은 방법이 문서이다. 제안서나 제품기획서는 소프트웨어 개발의 첫 단계인 기획 단계에서의 커뮤니케이션의 핵심이다.

제품기획이 완성되면 개발팀으로 넘어와 소프트웨어적인 측면에서 SRS를 작성하게 된다. 여기에서 모든 기능이 확정되고 모든 부서가 동시에 일을 추진하게 된다. 그래서 SRS는 개발팀, 마케팅, 기술문서, 테스트팀, PM 등 모든 팀과의 커뮤니케이션의 중심이 된다.

소프트웨어 개발에 있어 가장 중요한 하나의 문서를 꼽으라면 단연코 SRS이다. SRS에는 가능설명이외에도 성능요구사항, 인터페이스요구사항, 국제화, 하드웨어와 소프트웨어의 환경 등, 이 소프트웨어가 무엇을 하는지를 알 수 있는 모든 항목이 들어 있다.

프로젝트 매니저(PM)가 개발계획을 정확히 수립할 수 있도록 기능도 세세히 분리해야 한다. 각 기능항목을 2시간~ 2일 사이로 시간 측정 가능하도록 나누어야 한다고 주장하는 사람도 있으나 필자는 1일~2일 정도의 단위가 적당하다고 본다. 전체 소프트웨어 결함중에 56%가 요구사항분석 단계, 27%가 설계단계, 7%가 코딩에서 생긴다는 통계가 있다. 요구사항 분석단계에서 대충 SRS를 작성하기 때문에 생기는 결과이다.

개발방법론을 한번이라도 접해본 사람들은 다 들어본 적이 있는 '1:10:100 법칙'이라는 것이 있다. 요구사항 단계에서 잘못된 것을 발견해서 수정하는 것과 설계단계에서 수정하는 것과는 10배의 시간과 비용이 들고 코딩단계에서 발견하면 100배의 시간이 더 든다는 것이다. 책과 머리로는 이해하나 이것을 진실로 이해해서 제대로 실천하는 사람은 보기 드물다. 요구사항을 정확히 정의해야 하는 중요성은 전 개발과정중의 핵심중의 핵심이라고 아무리 강조해도 지나치지 않다.

이런 중요한 문서를 대충 적고 넘어가는 이유는 많다. 기능을 구현해 보지 않고는 할 수 있는지가 확실하지 않다는 이유가 그 중의 하나이다. 이런 경우의 판단은 두 가지 방법에 의존할 수 밖에 없는데 최단기간 내에 프로토타입을 만들어 보던가 아니면 경험자의 판단을 믿든가이다. 프로토타입을 만드는데 사용한 코드는 버리고 다시 개발하는 것이 좋기 때문에 당연히 경험자의 판단으로서 하는 것이 시간적으로 효율적인 것은 두말할 나위도 없다.

작은 프로젝트에서 발생하는 극단적인 케이스는 개발 종료후 보고서 제출용으로 SRS를 작성하려는 경우도 심심치 않게 본다.

잘 작성된 SRS는 결국 소프트웨어의 개발기간을 단축시켜 준다. SRS를 안 적거나 대충 적는 이유의 대부분이 시간이 없다고 한다. 잘 씌여진 SRS는 시간을 절약하게 해준다. '시간이 없어서' SRS를 정확하게 작성하지 않았다면 다음 개발단계를 빨리 시작할 수는 있으나 최종개발이 끝나는 시점은 더 늦어지게 된다. 그 외에도 부실한 SRS는 미래에 많은 문제를 파생시키게 된다.

정확한 SRS의 중요성은 강조했으나 이를 성취하기 위해서는 프로젝트의 종류에 따라 다르지만 소위 '갑' 이라고 하는 발주업체나 제품기획자의 능동적인 협조가 필요하다. '나중에 생각나면 추가하자'는 생각은 실패의 지름길이다. 한번 시작하면 변경하지 못한다는 생각으로 임해야 한다.

반대로 개발자의 입장에서도 무엇을 할 수 있는지, 자기의 능력도 확실히 알아야 한다. 할 수 없는 것을 할 수 있다고 해서 나중에 난감한 상황에 빠진 경험을 한번쯤은 가지고 있을 것이다. 좋은 소프트웨어가 나오기 위해서는 '갑'과 '을', 혹은 제품기획자와 개발자의 협력과 많은 시간투자가 초기단계에서 필요하다.

/김익환 SW컨설턴트 ik_kim@yahoo.com