[Software Spec Series 4] 스펙의 역할

소프트웨어 프로젝트에서 스펙의 역할을 알아보자.

모든 프로젝트 이해관계자가 사용, 프로젝트의 중심

스펙은 프로젝트의 모든 요구사항이 모이며 프로젝트의 중심이 되는 문서다. 프로젝트의 모든 이해관계자가 스펙을 참조하거나 작성에 참여한다. 스펙은 다시 여러 프로젝트 이해관계자들이 받아서 자신의 역할을 수행한다. 프로젝트에서 가장 중요한 문서 하나를 꼽으라고 하면 스펙이다.

(프로젝트의 모든 이해관계자가 참조해야 하는 SRS)

고객, 마케팅 부서, 영업 부서는 어떠한 제품이 만들어지는지 알 수 있다.

스펙이 없거나 부실한 상태로 진행하는 프로젝트는 프로젝트가 완료되기 전까지 어떠한 소프트웨어가 개발될지 알기가 어렵다. 그러면 영업부서는 소프트웨어 개발이 완료되기 이전에 판매 준비를 하거나 계약을 할 수가 없다. 스펙이 잘 작성된 프로젝트인 경우 스펙만 보고도 최종적으로 개발될 소프트웨어가 무엇인지 정확하게 알 수 있다. 영업부서에서는 이를 보고 판매에 필요한 준비를 할 수 있다. 영업망을 확충하거나 세일즈 자료를 준비할 수 있다. 또한 고객을 만나서 개발도 완료되지 않은 소프트웨어를 미리 팔 수도 있다. 소프트웨어 개발이 완료된 후에 부랴부랴 판매를 시작한다면 이미 상당한 판매 기회를 놓치게 된 것이다. 그 외에 안전, 의료, 보안 등의 인증이 필요한 경우도 스펙이 잘 작성되어 있다면 소프트웨어 개발이 완료되지 않았음에도 인증을 신청해서 인증을 미리 획득할 수 있다. 인증은 종류에 따라서 1년 넘게 또는 수년이 걸리기도 한다. 소프트웨어 개발이 완료된 후에서야 인증을 진행하면 수년의 영업 기회를 날려버릴 수도 있다.

프로젝트관리자(PM)에게는 스펙이 프로젝트 관리의 기준이 된다. 일정산정, 인력 배분, 리스크 분석 등을 할 수 있다.

스펙이 제대로 작성되지 않는 프로젝트에서 프로젝트 관리자는 별로 할 일이 없다. 일정을 제대로 예측하기도 어렵고, 리스크 파악도 어렵다. 적정한 리소스 계획을 세우지 못한다. 프로젝트가 진행이 되도 정확하게 진척률을 파악할 수가 없다. 그래서 1년짜리 프로젝트가 8개월쯤 지나도 정확하게 1년 안에 프로젝트가 종료될지 예측이 안된다. 그러면 프로젝트 관리자는 프로젝트 성공을 위해서 무엇을 더 해야 하는지 알 수 없다. 그저 운에 맡기는 수밖에 없다. 프로젝트의 성격에 따라서는 단계별로 진행을 하여 짧은 주기로 여러 차례 업그레이드를 하면서 진행하는 경우도 있다. 이 경우도 주기만 짧을 뿐이지 짧은 주기에 해당하는 스펙을 적절히 작성하는 것도 똑같이 필요하다.

개발팀은 스펙을 통해서 개발팀이 개발해야 할 제품이 무엇인지 정확하게 알 수 있다.

스펙을 제대로 작성하지 않았다면 개발팀은 정확하게 무엇을 개발해야 하는지 파악하기 어렵다. 기획자나 분석 아키텍트에게 너무 많은 것을 수시로 물어봐야 해서 시간을 매우 낭비해야 한다. 개발자가 임의대로 생각해서 기능을 구현하게 되면 기획의 의도와는 완전히 다르게 되기도 한다. 개발자에게 주어진 너무 높은 자유도가 소프트웨어 아키텍처를 부실하게 만들기도 한다. 개발자에게 자유도는 필요하지만 소프트웨어 전체 아키텍처는 분석, 설계 시에 정해져서 개발자에게는 한정된 자유도만 주어야 한다. 그래야 기획 시 의도된 소프트웨어가 제대로 개발될 수 있다.

(프로젝트에서 SRS의 위치)

테스트팀은 스펙을 통해서 테스트 계획 및 테스트 케이스를 작성할 수 있다.

보통은 스펙 작성 후에 개발자들이 구현을 하는 동안 테스트팀은 테스트 준비를 한다. 테스트 계획을 세우고 테스트 설계를 해야 한다. 하지만 스펙이 없거나 부실하다면 테스트팀은 테스트 준비를 제대로 할 수가 없다. 소프트웨어가 개발된 후에 소프트웨어를 보면서 테스트 준비를 해야 하는데 이 방법으로는 테스트 일정도 예측할 수 없고 부실한 테스트를 할 수 밖에 없다. 소프트웨어 품질이 나빠지는 것은 당연한 결과다.

기술문서팀은 스펙을 통해서 매뉴얼과 도움말을 작성할 수 있다.

소프트웨어 스펙이 완성된 후에는 많은 일들이 벌어진다. 기술문서팀은 소프트웨어를 동작시켜 보지도 않고 매뉴얼을 미리 작성한다. 단지 화면 캡쳐만 소프트웨어 개발 후 추가할 뿐이다. 이뿐만 아니다. 고객지원 부서는 고객 지원에 필요한 준비를 해 놓고 교육팀은 교육 준비를 한다. 이처럼 소프트웨어 스펙을 보고 많은 사람들이 자신의 일을 수행해야 하는데 바쁘다고 스펙 없이 개발을 하는 것은 개발자 중심의 사고방식이며 프로젝트가 효율적으로 진행되지도 않는다.

외주 업체는 스펙을 통해서 외주 업무를 정확하게 파악하고 SRS를 기준으로 계약을 할 수 있다.

우리나라에서는 많은 소프트웨어 프로젝트가 스펙도 없이 진행이 된다. 대략의 요구사항을 기반으로 계약하고 진행되는 프로젝트는 정상적으로 진행되기 어렵다. 고객이 수시로 요구사항을 무리하게 바꿔도 하소연하기 어렵다. 또한, 분석을 제대로 하지 않고 진행을 하므로 요구사항만으로는 프로젝트의 규모를 제대로 산정하기 어렵다. 그래서 계약 시는 성공적인 계약으로 생각되지만 프로젝트를 진행할수록 손해를 보는 경우도 허다하다. 우리나라도 스펙을 기준으로 계약을 하는 관행이 자리잡아야 한다.

share with abctech.software

CMMI는 회사를 망칠 수도 있다

필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 

그동안 SI회사 등 여러 곳에서 CMMI를 적용하였던 회사의 직원들을 많이 만나봤지만 SI회사도 아닌 이 회사의 사례는 독특해 칼럼에서 소개할까 한다. 

CMMI를 폄훼하려는 의도가 있는 것은 전혀 아니니 오해는 하지 말아주기 바란다. CMMI에 대한 오해와 서투른 기대를 경계하자는 것이다. 이는 CMMI 뿐만 아니라 수많은 방법론에도 똑같이 해당한다. 

H사는 최근 촉망받는 분야의 서비스를 하는 회사다. 직원이 100명 가까이 되는 작지 않는 회사지만 개발에 관련된 변변한 문서가 하나도 없다. 스펙, 설계서 뿐만 아니라 문서는 전무하다 시피하다. 개발 프로세스라고 할 만한 것도 없다보니, 주먹구구식으로 개발을 하고 있었다. 

고참 개발자라고 하는 사람들도 코딩만 꽤 할 줄 알았지 개발 프로세스가 뭔지도 모르고 협업에는 별로 관심도 없는 상태였다고 한다. 

이에 H사 대표는 이대로는 안되겠으니 컨설팅을 받아봐야겠다고 생각 했다. 그래서 선택한 컨설팅 회사가 CMMI를 전문적으로 컨설팅하는 국내 회사인 P사였다. 

P사는 CMMI 레벨3를 적용하자고 제안했고 직원들은 회사 내부에서 관련 교육을 받았다. 외부에 나가서도 수차례 교육을 받았다. P사는 회사의 기존 프로세스와 그나마 있었던 문서를 분석해서 CMMI 레벨3 기준으로 개발 프로세스를 만들고 수십가지의 문서 탬플릿을 만들어서 제안했다. 

실제 프로젝트에 이 프로세스와 문서 탬플릿을 적용하기 시작했는데 교육을 받기는 했지만 요구하는 수많은 문서를 만들어내기는 보통 어려운 일이 아니었다. 또 촉박한 프로젝트 일정에 문서까지 추가로 만드는 것은 죽을 맛이었다고 한다. 이에 개발자 및 사업부에서는 반발이 매우 심했고, CMMI를 적용하느라 몇개 프로젝트는 포기를 해야 하는 상황까지 발생했다고 한다. 

이런 상황에서 개발자들이 선택한 방법은 어처구니는 없는 것이었다. 문서에 적어야 하는 기능의 개수를 줄이기 시작한 것이다. 

기능하나에 서로 연결해서 작성해야 하는 문서가 많아서 전체 문서 양이 매우 많았다. 예를 들어 실제로는 500개 기능인 프로젝트에서 문서에는 100개만 적으면 문서 개수가 많아도 전체 작성해야 하는 문서의 양은 줄어들게 된다. 그렇게 해서 요구하는 문서와 프로세스를 따랐다고 한다. 정해진 일정에 요구하는 문서를 만들어 내려면 어쩔 수 없다고 한다. 

CMMI를 적용한 프로젝트에 참여했던 S씨는 해당 프로젝트에서 20여가지 문서를 만들었지만 실제 프로젝트에 쓰인것은 SRS와 WBS 문서 2개 밖에 없다고 했다. 나머지 20여가지 문서는 컨설팅 회사에서 요구하기 때문에 만들었을 뿐이라고 한다. 프로젝트 중간이나 프로젝트가 끝난 후에도 나머지 문서들은 볼일이 없을 것이라고 한다. 

H사는 그 뒤로 개발역량 향상은 커녕 CMMI의 직접적인 영향을 아니겠지만 매우 어려운 상태에 놓이게 되었다. 

이론적으로 CMMI를 통해 SW공학의 성숙도를 측정하고 역량을 향상할 수 있다. 하지만 오해와 잘못된 적용 방식이 국내에서는 큰 문제가 되고 있다. 역량 수준이 한참 못미치는데 억지로 요구하는 수준에 맞추기 위해서 문서를 만들어내고 프로세스를 따르는 것이다. 그렇게 해서는 역량이 향상될리 없다. 이런 일이 빈번하여 한국이 블랙리스트에 올랐다는 소문도 파다하다. 

CMMI가 필요한 분야도 있다. 대표적인 분야가 국방일 것이다. 국방 프로젝트는 1달러짜리 나사를 사기 위해서 프로세스와 문서를 적용하여 50달러를 투입해야 할 때도 있는 프로젝트다. 민간 프로젝트와는 성격이 다른 중요도가 있는 프로젝트이다. 

그 외에도 CMMI 인증이 필요한 프로젝트가 있다. 역량이 안되더라도 비즈니스 목적으로 CMMI를 적용하는 것은 그럴 수도 있다고 생각한다. 개발에는 별로 도움이 안되고 영업에는 도움이 될 것이다. 

하지만 순수하게 소프트웨어 개발 역량을 높이기 위해서 단기간에 CMMI를 적용하는 것은 별로 좋은 방법이 아니다. 실전적인 방법으로 내실을 다지는 것이 더 낫다. 

적당할 예 일지는 모르겠지만 타이거 우즈가 CMMI 레벨5 수준으로 골프를 친다고 가정하자. 타이거 우즈는 CMMI 레벨5로 골프를 치기 위해서 골프 스윙시 25가지의 절차와 고려사항을 눈깜짝할 사이에 적용해서 공을 친다. CMMI 레벨5에서는 그 25가지의 절차를 잘 분석해 놨다. 

나는 주말골퍼인데 코치가 그 25가지 절차를 따르면 타이거우즈처럼 골프를 칠수 있다고 한다. 1년을 그렇게 연습한다고 타이거 우즈처럼 골프를 칠 수 있을까? 타이거 우즈는 이미 성숙도가 높고 몸에 완전히 베어 있어서 25가지의 절차를 아무렇지도 않게 수행할 수 있지만 나는 그렇게 할 수가 없다. 

그것을 따라하다가는 오히려 골프를 더 못치게 된다. 현재 상황에서 필요한 것을 하나씩 배우는 것이 훨씬 낫다. 또한 대부분의 실용적인 소프트웨어 개발 현장에서는 그 수준까지는 필요하지도 않다. 

사대주의도 아니고 바다건너의 멋진 모델에 현혹되는 사례가 유난히 우리나라에는 많은 것 같다. 실리콘밸리에서 오래 개발한 개발자들에게 물어봐도 CMMI는 관심도 없고 주변에 적용한 회사는 본적도 없다고 한다. 그만큼 실전적이고 실용주의적인 개발을 지향하는 곳이라면 성숙된 개발 문화와 개발 본연의 역량 향상에 힘을 쓴다. 뛰어난 아키텍트 발굴도 그 일환이다. 

이는 비단 CMMI만의 이야기가 아니다. 수많은 방법론도 마찬가지다. 그자체로는 훌륭할지는 몰라도 적절한 곳에 적용을 해야 하며 우리 회사에서 필요한 것인지는 잘 생각해봐야 한다. 

필자는 좀더 효율적으로 개발을 하기 위해서는 성숙된 개발문화를 정착하기 위해 노력해야 한다고 생각한다. 실용적이고 실전적이지 않은 모든 절차와 프로세스는 짐이 될 뿐이다.

이글은  ZDNet Korea에 기고한 칼럼입니다.

이건 기능이 아닌데

의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.

소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.

하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 

이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.

첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.

둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.

셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.

그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.

딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.

기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?

그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.

비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.