DATOR


요구 관점에서 바라보는 프로젝트...(주)엔코아 김효식 수석 연구원 커버 스토리


coverstory.jpg


필자는 현재 모 보험사에서 프로젝트 수행 중이다. 10년 전에 처음 모 통신사 사업에서 개발사 PM을 했고, 2년만에 다시 PM을 하고 있다.


그동안 회사에 새로운 식구가 들어오면 선배로서 이런 저런 이야기를 해주곤 했는데, 그 내용들을 정리하여 ‘요구 관점에서 바라보는 프로젝트’라는 제목으로 여러분께 전해 드리려 한다.



프로젝트의 특징
조직에서 IT의 문제점이나 Needs가 발생하면, 이것을 해결하는 것이 우리의 핵심 역량으로 축적이 될 것인가를 고민해서 자체적으로 만들 것인지 아니면 구매할 것인지(Make or Buy) 판단하게 된다. 이 때 자체적으로 만들면 내부 프로젝트고, 패키지를 도입해서 커스터마이징하거나, 외부 용역으로 만들라 하면 외부 프로젝트가 되겠다. 이후 제안과 협상을 거쳐 계약이 되면 프로젝트가 시작된다. 


프로젝트는 반드시 시작과 끝이 있고, 언제나 유니크하다는 특징(아무리 같은 제품이라도 고객이 다르면 프로젝트는 많이 다르다)이 있고, 점진적으로 구체화되는 특징이 있다.


프로젝트를 수행하다 보면 어떻게 해야 덜 일하고 빨리 끝낼 것인가에 사고가 갇힐 수가 있는데, 우리가 잊지 말아야 할 것은 고객은 어떤 필요성이 있어 전문가인 우리에게 맡겼고 우리는 고객의 필요성에 대한 솔루션을 제공해야 한다는 점이다.



프로젝트의 3중 제약
프로젝트에는 3중 제약(범위/일정/예산)이라는 것이 있다. 이 요소들은 하나가 늘어나거나 줄어들면 다른 둘도 영향을 받게 된다. 범위가 늘어나면 일정과 예산도 늘어나야 한다. 일정이 짧아지면 범위와 예산도 축소되어야 한다. 예산이 늘어나면? 예산이 먼저 늘어날 리는 거의 없다.


그래서 범위 관리를 잘해서 예산 내에 납기를 준수하는 것이 가장 좋다. 납기일에만 잘 맞춘다고 좋은 것일까? 꼭 그렇지만은 않은 것 같다. 품질을 고려해야 하기 때문이다. 결과물의 품질이 떨어진다면 그 프로젝트는 끝없는 유지, 보수의 나락으로 빠져들거나 영업 대표만 간절히 바라보는 골칫덩이가 될 것이다. 그래서 하나 더, 품질이라는 제약을 하나 더 추가하겠다.


cs01.png


프로젝트의 품질
그러면 품질이란 무엇일까? "사용자의 기대에 부합하고, 요구를 만족시키는 수준"이라고 할 수 있겠다. 비즈니스 환경에서 사용자의 기대나 요구는 그 비즈니스나 서비스, 제품 등에 따라 다양할 것이고, 프로젝트를 수행하는 우리는 그것을 요구 사항으로 발굴해서 명문화시켜야 한다. 그렇게 나오는 산출물이 요구 사항 정의서, 요구 사항 명세서 등인데 이건 나중에 인수 시험(UAT)의 기준이 된다.



요구 관리
요구 사항에는 “기능 요구 사항과 “비기능 요구 사항”이 있다. 비기능 안에 제약조건(Cross-Browsing 지원 등)을 넣기도 하고, 요구공학 쪽에서는 제약조건을 따로 빼기도 한다. 기능 요건이야 요구 사항 추적표를 통해 설계 문서, 소스, 단위 테스트 케이스, 통합 테스트 시나리오에 매핑이 되니 말할 것도 없고, 비기능은 보통 간과하기 쉬운데 꼭 측정이 가능하도록 정량화시킨 문서로 고객의 승인을 받아야 한다.



불분명한
요구 사항 사례

저는 홈페이지 느린 것 질색이에요. 바로 바로 나오게 해주세요
à홈페이지의 각 화면은 빠르게 표시되어야 한다.”

올바르게 정의된
요구 사항 사례

그래프가 포함되었거나 통계 정보를 보여 주는 페이지는 메뉴 클릭 후 X초 이내, 그외 페이지는 X초 이내 (테스트 조건 동시 접속자 X, 네트워크 환경은 ~~~~)”


보통 분석 단계가 초반이다 보니 아직 고객과 관계가 서먹한데 꼬치꼬치 캐묻는 것 같아서 차일피일 미루다가 프로젝트 마무리하는 시점에 얼굴 붉히는 일이 발생할 수 있다.


다만, 위의 표 같은 예에서는 고객이 산업 표준이 몇 초 정도인지 모를 수도 있으니 미리 조사해서 참고 자료를 제공하는 게 배려이다. 아무래도 전문가는 우리 쪽이니까 말이다.


앞서 언급했던 3중 제약 중에서 범위 관리가 바로 요구 사항 관리인데, 필자는 이 요구 관리가 정말 중요하다고 생각한다. 가장 어려운 부분이기도 하며, 품질이 요구 만족이라고 해서 무한정 수용했다가는 프로젝트의 시작은 있으되 끝은 없고, 끝이 있더라도 누군가 볼모로 남게 되기 십상이다.


사석에서 동료들과 프로젝트 현실에 대한 이야기를 나누다 보면, 한국적인 IT라는 시니컬한 말들을 많이 듣지만, 필자의 생각에는 다른 나라도 차이는 없어 보인다. 


새로운 방법론이 나오는 주요 동인은 현재 방법론의 문제 해결이다. 그리고 필자는 “요구 사항에 대한 효과적인 대응”이 그 문제 중 하나라고 생각한다. 아래는 십 몇 년쯤 전에 봤던 그림 ”How Projects really Work”이다(2014년 1월 커버스토리에도 등장했었던 그림이다). 지금은 번역본도 돌고, 더 상세화된 버전도 있다고 한다. 우리나라 IT 프로젝트를 딴 나라 사람이 그린 건 아닐 것이다. 그래서 이 그림의 풍자 대상은 우리나라의 현실이 아니라 IT의 현실이라고 생각한다.



cs02.jpg


<낯설지 않은 선진국들의 프로젝트 현실>

<원문: http://www.mobileindustryreview.com/2010/08/how-projects-really-work.html>


요구 사항에 대한 대응 전략, 방법론
프로젝트에서 요구 사항에 대한 대응은 계약 관계가 아닌 개발 프로세스의 근원적인 부분에서 찾아야 한다는 말인데, 몇 가지 방법론의 예를 보겠다.


  • 상식적인 순서로 개발 공정을 나열한 “폭포수”,
  • 결과물에 대한 간단한 초안(모형) 제시로 요구 사항 도출을 쉽게하는 “프로토타입”,
  • 폭포수를 반 접어서 요구에 대한 검증 매핑, “V모델”
  • 조금씩 나눠서 개발하고 있을 테니 요구 변경아 덤벼라, “애자일”


이런 방법론의 추이를 보면, 곤혹스런 요구 관리가 비단 특정 국가의 왜곡된 갑을 관계가 원인이 아니라는 것을 말해준다. 요구 사항의 대응 측면에서 위의 방법론 사례들을 하나씩 살펴보겠다.


폭포수 모델
일단 만들고 오류 나면 고치자는 “Build & Fix” 방식에서 IT 영역의 확대로 인해 IT프로젝트가 점차 대형화, 복잡화되면서 분석>설계>구현>시험>전개의 “폭포수” 방법론이 나오게 된다. 


※ 사실 폭포수는 방법론이 아니라 생명 주기이다. 생명 주기는 각 공정 단계를 구분해 놓은 것이고 방법론은 생명 주기의 공정의 세부 활동마다 무슨 일을 해야 하고 무슨 산출물을 만들어야 하는지를 정의하지만, 여기서는 구분 없이 사용하겠다.


이 방법론의 특징은 진척 단계가 명확하기 때문에 관리하는 입장에서 좋다. 그런데 요구 사항이 초반에 나오고 그만인 적이 있는가? 오히려 뭔가 가시적인 결과가 보이는 설계, 구현, 심지어는 시험 단계까지도 요구 사항들이 쏟아진다. 그럼 다시 요구 사항을 “분석”하고 “설계”하고 “구현”하는 동안 일정은 저 멀리 떠나 버린다. 이를 통제하기 위해 고객과 “변경통제위원회(Change Control Board)”를 구성해야 한다고 하기도 하지만 어지간한 프로젝트에서는 그게 쉽지 않다.



프로토타입
예전엔 수도 시설이 좋지 않아서 펌프를 썼다. 이 펌프는 한 바가지 정도의 물만 위에 부어 넣으면 지하의 물을 펑펑 끌어올릴 수가 있었다. 이 한 바가지의 물을 마중물이라고 부른다. 프로토타입은 요구 사항의 마중물이라 할 수있다. 


필자가 사원 시절 ERP 프로젝트에서 CBO개발(Custom Bolt On, ERP 패키지 외 추가 개발)을 했던 적이 있다. 당시 요구 사항을 내야 하는 물류 계열사의 현업이 “나는 눈에 보이는 게 없으면 요구 사항을 못 내!” 라고 선언했다. 그간의 업무가 IT와 무관했기 때문이다. 대신 이면지에 화면이라도 그려 주면 정말 예리하게 핵심 기능을 콕콕 짚어 냈다. 이런 것도 프로토타입이의 한 방법이라 할 수 있겠다.


사실 초반에는 이슈가 없던 요구 사항이 코딩이 어느 정도 완료된 시점에 쏟아지는 이유도 프로젝트가 진행되면서 고객의 이해도가 높아지고 시스템이 눈에 보이기 시작해서 일 것이다. 그 시기를 좀 앞당겨 보자는 것이다.


필자의 생각에 프로토타입은 다른 방법론에서도 요구 도출 기법으로 활용해도 좋을 것 같다. 다만 너무 잘 만들면 고객이 다 만든 것으로 오해하거나 프로토타입을 개발하는 시간이 오래 걸린다는 점은 고려할 사항이다. 



V모델
V모델은 기존의 폭포수 모델의 코딩 단계를 기준으로 V모양으로 반 접은 형태이다. 여기서 품질 쪽에선 꽤 유명한 V&V(검증과 확인)기법이 나온다.


이 방법론은 요구 사항의 도출보다는 초기 요구 사항을 완료 시점까지 단계적으로 검증(Verification) 및 확인(Validation)하려는 데 그 목적이 있다. 요구 관리를 제대로 하지 않으면 자신만의 우물에 빠져 중요한 요구 사항이 누락되기도 하니까 말이다. 중요한 것은 분석 단계부터 각 단계 말(末)에 이전 단계의 결과가 이번 단계에서 모두 반영됐는지 검증한다는 컨셉이다. 즉 구현뿐만 아니라 분석, 설계 단계에도 품질 활동이 있으며 또 필요하다는 것이다.




cs03.png






애자일
Agility는 기민함, 민첩성이라고 한다. 필자의 생각에 애자일(Agile) 방법론은 요구 변경에 대한 민첩한 대응이다. 대표적인 애자일 방법론에는 XP, SCRUM 등이 있다. 지난 몇 년간은 이 애자일 방법론이 유행이었다. 단지 문서 산출물을 안 만든다고 해서, XP의 12개 실천 항목 중에 “주 40시간 근무, 연속 야근 금지”가 있다고 해서 인기가 있었던 것은 아닐 것이다. 그럼 기존의 방법론과 차이는 무엇일까?


기존의 IT의 방법론들은 PDCA기반이었다. PDCA란 계획(Plan) 또는 설계하고, 실행 또는 구현(Do)하고, 제대로 됐는지 확인(Check)하고 잘못된 점은 조치(Act)하는 것을 지속적으로 반복하는 구조다. IT감리나 CMMI, SP품질인증 심사도 조직이 정한 방법론에 따라 PDCA가 이뤄졌는지를 확인하는 것이 중요한 요소이다.


그러나 애자일 방법론의 경우는 계획(또는 설계)에 따른 실행보다는 실제 코딩에 중점을 두고, 만들어야 할 결과물을 짧은 주기로 만들어내는 것을 반복해서 하나의 커다란 제품을 만들어 간다. 그러다 보니 경량급(Light Weight), 실용 주의, 경험 주의 방법론이라고도 한다.


XP는 요구 사항(User Story)을 가지고 반복 주기 동안 구현 한다. 처음 유저 스토리는 구현물에 대한 인수 시험의 테스트 시나리오가 된다. XP는 12개의 실천 항목이 있는데 정말 프로젝트에서 가져다 쓸만한 내용들이 많다.


SCRUM은 만들어야 할 제품의 요구 사항(Product Backlog)을 쌓아 놓고 일부(Sprint Backlog)를 빼서 반복 주기(Sprint)동안 전력을 다해 만든다. 그리고 매일 스크럼 미팅을 통해 전 날 한 일과 일하는 데 장애가 되는 부분, 그리고 오늘 할 일을 공유한다. 인수 테스트는 따로 없지만 매 회의 스프린트가 종료 될 때마다 팀 리뷰를 통해 만든 제품(또는 기능모듈)을 평가하고 다음 스프린트에 만들 기능의 우선 순위를 조정한다.


요구 관리 관점에서 볼 때 이들 애자일 방법론은 애초에 기능을 작게 쪼개서 조금씩 만들어내고 그 다음 만들어 낼 것을 정하다 보니 구현 전에 전체에 대한 설계를 먼저 작성하고 구현하는 방식 보다 나중에 요구 사항이 추가 변경되더라도 영향이 크지 않다.  다만, 프로젝트에 외부 감리가 있을 경우 설계 문서가 없어서 문제가 될 수 있는데, 이 경우 반복 주기 하나를 문서 산출물을 만드는 기간으로 잡아 대응하기도 한다.



끝으로
지금까지 프로젝트의 품질, 요구 관리, 그리고 몇 가지 방법론들을 살펴 보았는데, 지면과 시간 관계상 이쯤에서 줄이도록 하겠다. 필자가 기술한 내용은 실제 프로젝트를 진행할 때 일부 차용하여 사용할 수 있도록 설명하고자 했는데, 이 같은 뜻이 잘 전달되기를 바란다. 끝으로 여러분의 프로젝트에 고객을 만족시키는 품질이 항상 함께 하기를 바라며 글을 마친다.





Tag :

Leave Comments