All of Software: 프로젝트/요구사항분석에 대한 검색결과

검색어 프로젝트/요구사항분석에 대한 글을 관련성을 기준으로 정렬하여 표시합니다. 날짜순 정렬 모든 글 표시

2009년 11월 13일 금요일

SRS에 대한 인식의 변화

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.

이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다.

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다.

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.

그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

2008년 11월 19일 수요일

SRS(Software Requirements Specification)의 중요성

본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만,

특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다.

"소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다.

그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다.

먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다.

요구사항 분석

소프트웨어 프로젝트에 있어서 가장 흔한 실수 중의 하나가 요구사항이 불명확한 상태에서 급하다는 이유로 일단 설계, 구현을 시작하는 일이다. 어떤 경우는 스펙문서가 아예 없는 상태에서 프로젝트를 진행하는 경우도 있다. 또는 간단한 요구사항 목록을 가지고 스펙이라고 착각하는 경우도 많다.

제대로 된 요구사항 개발 없이 프로젝트를 성공적으로 수행하는 것은 거의 불가능하다. 고객의 요구사항을 상세히 기술하였다고 해서 좋은 요구사항은 아니다. 고객도 자신이 원하는 것을 자세히 모르는 경우가 아주 흔하기 때문이다. 고객의 요구사항을 단순히 기술한 정도의 요구사항은 프로젝트 후반에 많이 바뀔 수 있는데, 요구사항 개발 시 간단히 해결할 수 있는 것을 프로젝트 후반이나 유지보수 시까지 와서야 처리함으로써 수십 배의 비용을 추가로 치르는 경우도 있다.

요구사항 개발은 단순히 요구사항을 옮겨 적는 일이 아니다. 요구사항을 수집하고, 분석하고, 정리하고, 리뷰하는 일을 반복하여 완성도를 높여가는 일이다.

책을 보고, 샘플을 보고, 템플릿을 이용해서 독학함으로써 SRS를 잘 쓰는 것은 거의 불가능하다. 책이 도움은 될 수 있으나, SRS를 제대로 쓰려면 제대로 된 회사에 가서 몇 년 동안 일하면서 배워야 한다. 때에 따라서는 전문가에게 컨설팅을 받는 것도 좋은 방법이다. SRS는 기능공처럼 기법에 따라 작성하면 되는 것이 아니라 인간의 판단이 핵심인 문서이기 때문에 작성이 생각처럼 간단하지 않다.

요구사항의 중요성

요구사항 문서는 프로젝트에서 작성하는 산출물 중에서 가장 중요하다. 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.

소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대 한도로 많은 정보를 파악하는 것이 좋다.

잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. (출처, Software Requirements, Karl E. Wiegers, Microsoft Press)

완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.

요구사항 오류는 개발 단계가 지나가면 갈수록 그 수정 비용이 기하급수로 증가한다. 유지보수 단계에서 요구사항 오류를 바로 잡으려면 요구분석 단계에서 바로 잡는 것보다 200배의 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.

SRS란?

요구사항 분석 문서의 종류는 수없이 많다. 개발 방법론에 따라서 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 여기서 소개할 문서는 SRS이다. SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다.

SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 SRS Template을 가지고 있어야 한다.

2017년 8월 9일 수요일

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다.

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

약속된 일정 내에 제품 또는 서비스를 출시 못했다.
소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
프로젝트에 꼭 필요한 기술 개발에 실패했다.
아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
프로젝트에 계획된 예산보다 많은 비용을 지출했다.
프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.

고객의 요구사항을 충분히 파악하지 못함
제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다.

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

2009년 2월 12일 목요일

요구사항 분석의 출발점

소프트웨어 개발에 있어서 요구사항 분석이 가장 중요하다는 것은 앞에서도 이미 주지한 사실입니다.

2008/11/19 SRS(Software Requirements Specification)의 중요성

2009/02/04 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?

요구사항 분석의 산출물은 SRS, 요구사항분석서 또는 다양한 방법론에 의해서 다른 문서들이 나올 수 있겠죠. 그럼 요구사항분석의 출발은 무엇일까요? 어떤 기능을 제공하기를 원하나 조사하는 것일까요?

"왜 이 프로젝트를 하려고 하는가?"입니다.

프로젝트를 하는 목적과 목표를 알아야 모든 요구사항이 일관성을 갖게 됩니다.

이걸 누구나 다 알고 있다고요?

제 경험에 의하면 그렇지 않습니다. 프로젝트 구성원에게 각각 물어보면 프로젝트의 목적에 대해서 서로 다른 얘기를 합니다. 프로젝트의 목적이 공유가 안되어 있거나 심지어는 심각하게 고민도 해보지 않은 경우 입니다. 그렇다면 프로젝트는 산으로 가는 경우가 많습니다. 수많은 의견 충돌 시 프로젝트의 목적에 맞게 합리적인 결정이 이루어지지 않습니다.

지금 프로젝트를 하고 있다면 프로젝트의 목적이 정확하게 공유되고 같은 생각을 하고 있는지 확인해보세요.

개발자끼리가 아닙니다. 개발자, PM, PL, QA, 영업, 마케터 등 프로젝트 관련자 모든 사람이 같은 프로젝트 목적을 공유하고 있는지 입니다.

그럼, 서로 팀워크가 착착 맞아서 눈빛만 보면 서로 다 안다고 하면 서로 같은 생각을 할까요? 이런 경우에도 프로젝트 목적이 뭔지 명확하게 정의해서 공유하지 않으면 각기 다른 생각을 하는 일은 매우 흔합니다. 요구사항 분석 산출물의 맨 앞에는 프로젝트 목적을 명쾌하게 정리해서 모두 공유할 수 있도록 해야 합니다. 물론 모든 관련자가 동의를 하는 내용이어야 합니다.

프로젝트를 시작하면 왜 이 프로젝트를 하는지 명확하게 알아내고, 정의하고, 공유해야 합니다.

2012년 8월 30일 목요일

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.

1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.

위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."

위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.

99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.

스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.

1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구

이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.

프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.

변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.

변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.

변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.

이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.

또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.

스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다.

스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.

2019년 12월 26일 목요일

[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

우리 주변에서 실패한 소프트웨어 프로젝트를 보는 것은 어려운 일이 아니다. 프로젝트를 성공하는 방법을 배우기 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패하는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
프로젝트에 꼭 필요한 기술 개발에 실패했다.
아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
프로젝트에 계획된 예산보다 많은 비용을 지출했다.
프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

고객의 요구사항을 충분히 파악하지 못했다.
제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당히 많은 시간을 소모하여 정작 개발 기간이 부족하게 되었다.
스펙과 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 하였다.
작성된 스펙을 프로젝트 이해관계자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발하였다.
프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어졌다.
변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 하였다.
상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작했다. 나중에 잘못된 코드를 고치느라고 시간이 더 소요되었다.
충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕하느라고 시간을 많이 지체했다.
일정관리를 대충해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못했다.
리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패했다.
프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 했다.
프로젝트 팀원들의 팀워크에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트가 산으로 갔다.
도입한 외부 필수 기술이 기대처럼 동작하지 않았다. 이것을 프로젝트 막바지에 알게 되었다.
테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못했다.
회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해졌다.

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가도 소프트웨어를 무사히 완성하기도 한다. 소수의 경험 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 찰떡 같이 알아듣고 개발을 잘하기도 한다. 하지만, 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 인수 테스트 계획이 필요하다.

소규모 프로젝트에서의 성공 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 반대로 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사에서는 이런 함정에 종종 빠진다. 개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아서 수시로 바뀌는 요구사항을 문서에 제대로 반영하지 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 이해관계자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

share with abctech.software

2009년 1월 19일 월요일

그냥 쓸 수 있겠네요.

소프트웨어를 개발하면서 가장 어려운 일은 고객의 요구사항을 파악하는 일이라고 알려져입니다.

고전적인 Waterfall 방식부터 Agile까지 요구사항에 대해서 다양한 방법으로 상당히 신경을 쓰고 있습니다.

특히나 우리나라에서는 고객이 요구사항을 잘 가르쳐 주지 않습니다. 물론 자신의 요구사항을 완벽하게 자세히 알고 말해주는 고객은 전세계 어디서도 찾아보기 어려운 것이 사실입니다. 정도의 차이가 있을 뿐이죠. 그만큼 요구사항 파악은 어려운 일입니다.

우리나라에서 요구사항 파악 시 고객이 이렇게 얘기하는 경우가 흔합니다.

"자세한 요구사항은 나중에 알려줄 테니 일단 구현을 시작해주세요."

그래서 일단 제품을 다 만들어 놓고 고객에게 시연을 하면 그 때서야 고객이 "여기는 이렇게 고쳐달라", "이 기능을 넣어달라", "저 기능은 빼달라" 주문을 하기 시작하죠. 그렇게 제품을 고치고, 시연하고 하면서 고객의 요구사항을 만족시켜 가는 방법이 우리나라에서는 그리 드문 일이 아닙니다. 심지어는 요구사항 분석에 경험이 적은 개발자들은 그냥 그렇게 하는 방법에 익숙해져 있기도 합니다.

이 방법은 대단히 비효율적이고 비용이 많이 드는 방법입니다.

고객의 말 한마디에 몇 주간 노력해서 만든 기능이 빠질 수도 있습니다. 그리고 황당한 요구사항이 갑자기 추가될 수도 있고, 도저히 초기에 일정을 예측할 수도 없죠.

개발자들이 고객의 요구사항을 너무 잘 알고 있고, 오히려 개발자가 고객을 리드하는 경우라면 일부 효과가 있을 수 있어도, 대부분의 경우 비싼 방법입니다.

이와 같이 자세한 스펙을 쓰기 전에 미리 만들어서 보여주는 방법을 "Prototyping"이라고 합니다. 그 중에서 고객의 요구사항을 파악하고 요구사항을 명확하게 하기 위한 방법은 "1회용 Prototyping"이라고 합니다. 왜 "1회용"이냐 하면 이는 요구사항을 파악하기 위한 것이기 때문에 Fix된 요구사항이 아닙니다. 제품에 기능으로 추가될지 빠질지 알 수 없고, 기능이 어떤 형태로 변하게 될 수 예측할 수 없으므로 제대로 만들면 비용과 시간이 많이 들기 때문에 아주 간단하게 만들어 보는 겁니다. UI에 대한 요구사항을 명확하게 하고 싶으면 UI만 동작하도록 해서 고객과 의논할 수 있고, 특정 기능에 대해서 자세히 알고 싶으면 그 기능이 어떻게 동작하는 지만 간단히 만들어 보는 겁니다.

이때는 제대로 제품을 만들듯이 에러처리를 꼼꼼히 하지도 않고, 회사의 코딩 규칙을 지키기 위해서 주석을 제대로 달지 않아도 되며 속도를 위해서 코드를 개선하지 않고, 메모리 최적화도 필요 없습니다. "1회용 Prototyping"은 요구사항을 얻고 명확하게 하기 위한 것이 목적이므로 최단시간에 최소한의 비용으로 만들면 됩니다.

이렇게 만들어진 "1회용 Prototype"을 고객이나 영업부에 보여주면 "다 됐네?", "그냥 쓸 수 있겠군요."라고 하는 경우가 많습니다. 이는 마치 모델하우스를 보고 거기에 들어가서 살겠다고 하는 거와 비슷합니다.

"1회용 Prototype"은 요구사항을 명확하게 하기 위한 활동이고, 이를 통해서 요구사항이 정해졌으면, "1회용 Prototype"은 버리고 다시 만드는 겁니다. 하지만 개발자들은 이를 다시 써먹으려고 하는 경우가 많습니다. "Prototype"에 너무 많은 노력을 들였거나, 시간이 촉발할 때 그냥 쓰고 싶을 수도 있는데, 이는 나중에 제품의 품질에 영향을 주기 때문에 "1회용 Prototype"은 참조는 할 수 있지만, Copy & Paste해서 쓰면 안 됩니다.

"1회용은 1회용일 뿐"

Prototype을 만드는 도중에 Project는 중단이 되는 것이 아니고, 요구사항 분석을 계속해 나가면서 1명의 개발자나 소수의 인원이 Prototype을 만들어 보는 겁니다. 물론 Prototype을 만드는 일도 계획되어야 하며, 적절한 Prototype 작성은 프로젝트의 시간과 비용을 절약해줍니다. 또한 나중에 생길 가능성이 있는 요구사항의 변화를 줄여줘서 Risk도 감소시켜주는 효과도 있습니다. 모든 기능을 다 Prototype을 만들어야 하는 것은 아니고 꼭 필요한 부분만 Prototype을 만들어서 확인할 수 있도록 적절히 판단하는 것도 경험이 필요합니다.

2020년 4월 12일 일요일

[Software Spec Series 10] 요구사항과 스펙의 차이

스펙에 대해서 얘기할 때 종종 혼동해서 사용하는 것이 요구사항이다. 영어로는 Specification과 Requirement(s)다. 두 용어는 같은 것일까? 다른 것일까? 가끔은 혼용해서 사용하지만 우리는 스펙의 원리를 정확하게 이해하기 위해서 두 용어의 차이를 명확하게 구분하는 것이 필요하다.

“요구사항"이라는 용어는 소프트웨어 업계 외에서도 일반적으로 의미와 비슷한 뜻으로 사용된다. 고객이나 이해관계자가 요구하는 것을 뜻한다. 하지만 소프트웨어 “스펙”은 좀 다른 의미를 가지고 있다. 그래서 수많은 회사에서 또, 여러 개발자들이 그 의미를 미묘하게 서로 다르게 생각하고 있나보다. “스펙”도 소프트웨어 업계 외에서도 많이 사용한다. 취업 시장의 후보자도 “스펙”이란 용어를 쓰고, 스마트폰 등 디바이스도 “스펙”이란 용어를 쓴다.

일반적인 의미로 소프트웨어도 “스펙”은 비슷한 의미를 가지고 있지만, 소프트웨어 “스펙”이라고 하면 머리 속에 그려지는 모습이 있다. 그리고 그 모습은 전세계 개발자들이 공통적으로 생각하는 것이 있다. 적어도 이런 내용들이 포함되어 있고 이런 절차를 통해서 만들었을 것이라는 생각을 할 수 있다.

그래서 요구사항은 한 줄 또는 몇 줄에 불과하지만 그 요구사항을 잘 분석해서 스펙을 작성하면 수 페이지 또는 수십, 수백 페이지의 문서가 될 수도 있다. 그래서 스펙을 제대로 작성하지 않고 요구사항만 가지고 프로젝트를 시작하면 큰 재앙이 닥칠 수 있다. 특히 외주 프로젝트라면 그 재앙은 회사를 매우 어렵게 할 수도 있다.

내부에서 진행하는 프로젝트든 외주나 SI로 진행하는 프로젝트든 스펙을 제대로 작성하지 않고 요구사항 수준의 요청으로 진행을 하면 분석이 제대로 되지 않았기 때문에 프로젝트를 진행하는 내내 수많은 문제가 발견되고 난상토론, 불 끄기, 고치기 반복이 발생한다. 물론 스펙을 적절히 잘 작성하면 이런 문제 상황을 훨씬 줄어든다.

지금도 수많은 사람들이 “요구사항”과 “스펙”이란 용어를 혼동해서 사용을 하고 있다. “요구사항”과 “스펙”의 차이를 사전적으로 아무리 설명해도 그 차이를 실감하기는 불가능하다. 외울 수는 있어도 금방 잊어버려서 실전 개발 프로젝트에 적용을 하지 못한다. 유일한 방법은 소프트웨어 “스펙”의 원리를 제대로 이해하면 “요구사항”과 “스펙” 차이를 명확하게 알게 된다. 그래서 이 시리즈에서는 “스펙”의 원리에 대해서 자세히 다루고 있다.

(요구사항과 스펙의 차이)

share abctech.software

2013년 3월 14일 목요일

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.

소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다.

소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다

하지만 우리나라에서 "요구사항분석" 역량을 제대로 갖춘 개발자를 만나보는 것은 매우 어렵습니다. "요구사항분석"은 교과서를 통해서 배울 수 없고 실전을 통해서 익혀야 하는데 우리나라는 자수성가한 개발자들로부터 시작되고 이어져 왔기 때문에 이를 가르쳐 줄 수가 없었습니다. 대기업에서는 대규모 방법론이나 비싼 툴을 사용하여 "요구사항분석"을 해보려고 하는데 아무리 비싼 골프채가 있어도 골프를 잘치는 것은 딴 얘기이듯이 툴이 이것을 해결해주지는 않습니다.

결국은 요구사항분석의 핵심을 꺠닫고 꾸준히 현실 프로젝트에서 경험을 쌓아가는 것이 유일한 방법입니다. 그래서 그 실전적인 방법을 공유하고자 세미나를 개최합니다. 많은 성원 부탁합니다.

시간과 장소는 아래 URL 참조하세요.

http://projectresearch.co.kr/2013/03/11/대한민국-개발자들이여-깨어나라-올바른-sw-개발-방법/

참석하실 분들 댓글 달아주시고, 여기(http://onoffmix.com/event/13214)로 신청하시면 됩니다.

2020년 1월 19일 일요일

[Software Spec Series 4] 스펙의 역할

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

share with abctech.software

2025년 12월 11일 목요일

리스크 기반 버퍼: 불확실성을 숫자로 관리하기

"이 프로젝트 언제 끝날까요?"

"음... 버퍼 20% 넣어서 6주요."

잠깐, 왜 20%인가요?

"그냥... 경험상?"

이제 추측이 아닌 계산으로 버퍼를 정합시다.

버퍼의 딜레마

프로젝트 버퍼, 어떻게 정하시나요?

대부분 이렇게 합니다:

"무조건 30% 추가"
"지난번에 늦었으니 50%"
"중요한 프로젝트니까 100%"
"그냥 느낌상..."

결과는? 너무 적으면 프로젝트 지연, 너무 많으면 자원 낭비와 파킨슨 법칙.
적정선은? 아무도 모릅니다.

리스크 점수 시스템

리스크를 측정하면 버퍼를 계산할 수 있습니다.

class RiskBasedBuffer {
  calculateBuffer(baseEstimate, risks) {
    // 리스크 요소별 가중치
    const factors = {
      신기술_사용: { weight: 3, score: risks.newTech },
      팀_경험_부족: { weight: 3, score: risks.teamExp },
      요구사항_불명확: { weight: 3, score: risks.unclear },
      복잡도: { weight: 2, score: risks.complexity },
      의존성: { weight: 2, score: risks.dependency },
      변경_가능성: { weight: 2, score: risks.changeProb }
    };
    
    // 리스크 점수 계산 (0-100)
    let totalRisk = 0;
    let maxRisk = 0;
    
    for (const factor in factors) {
      const f = factors[factor];
      totalRisk += f.weight * f.score;
      maxRisk += f.weight * 10;
    }
    
    // 리스크 비율로 버퍼 계산
    const riskRatio = totalRisk / maxRisk;
    const bufferPercentage = 10 + (riskRatio * 60); // 10-70%
    
    return {
      baseEstimate,
      bufferPercentage: Math.round(bufferPercentage),
      bufferDays: Math.round(baseEstimate * bufferPercentage / 100),
      totalEstimate: baseEstimate + Math.round(baseEstimate * bufferPercentage / 100)
    };
  }
}

실제 적용 예시

두 프로젝트를 비교해보겠습니다.

고위험 프로젝트: 블록체인 결제 시스템

const highRiskProject = {
  base_estimate: 60, // 일
  
  risks: {
    newTech: 8,      // 블록체인 첫 도입
    teamExp: 9,      // 팀 경험 없음
    unclear: 7,      // 스펙 미완성
    complexity: 7,   // 분산 시스템
    dependency: 6,   // 외부 API 다수
    changeProb: 8    // 자주 바뀜
  }
  
  // 계산 결과:
  // 리스크 점수: 67/100
  // 권장 버퍼: 50% (30일)
  // 최종 예상: 90일
};

저위험 프로젝트: 관리자 페이지 CRUD

const lowRiskProject = {
  base_estimate: 30, // 일
  
  risks: {
    newTech: 1,      // 익숙한 스택
    teamExp: 1,      // 경험 풍부
    unclear: 2,      // 명확한 스펙
    complexity: 2,   // 단순 CRUD
    dependency: 1,   // 독립적
    changeProb: 2    // 거의 없음
  }
  
  // 계산 결과:
  // 리스크 점수: 15/100
  // 권장 버퍼: 15% (5일)
  // 최종 예상: 35일
};

똑같이 "경험상 20%"를 넣었다면?
블록체인 프로젝트는 실패하고, CRUD는 자원을 낭비했을 겁니다.

동적 버퍼 관리

버퍼는 한 번 정하고 끝이 아닙니다.
매일 소비를 추적하고 패턴을 분석해야 합니다.

class DynamicBufferManager {
  constructor(totalBuffer) {
    this.totalBuffer = totalBuffer;
    this.consumed = 0;
    this.projectProgress = 0;
  }
  
  updateStatus(progress, bufferUsedToday) {
    this.projectProgress = progress;
    this.consumed += bufferUsedToday;
    
    const consumptionRate = this.consumed / this.totalBuffer;
    const idealRate = this.projectProgress;
    
    // 버퍼 소비가 진행률보다 빠르면 위험
    if (consumptionRate > idealRate * 1.5) {
      return {
        status: "🔴 위험",
        action: ["근본 원인 분석", "스코프 재검토", "자원 추가"]
      };
    } else if (consumptionRate > idealRate * 1.2) {
      return {
        status: "🟡 주의",
        action: ["리스크 재평가", "일정 조정 검토"]
      };
    }
    
    return {
      status: "🟢 정상",
      remainingBuffer: this.totalBuffer - this.consumed
    };
  }
}

몬테카를로 시뮬레이션

더 정교한 예측을 원한다면 시뮬레이션을 돌려보세요.

import random

def monte_carlo_buffer(tasks, iterations=1000):
    """1000번 시뮬레이션으로 적정 버퍼 계산"""
    
    results = []
    
    for _ in range(iterations):
        total_time = 0
        
        for task in tasks:
            # 각 작업은 최선/최악 케이스 사이에서 랜덤
            best_case = task["estimate"] * 0.7
            worst_case = task["estimate"] * 2.0
            
            # PERT 분포로 시뮬레이션
            simulated = random.triangular(
                best_case, 
                worst_case, 
                task["estimate"]
            )
            total_time += simulated
        
        results.append(total_time)
    
    # 결과 분석
    results.sort()
    p50 = results[500]  # 50% 확률
    p90 = results[900]  # 90% 확률
    
    recommended_buffer = p90 - p50
    
    return {
        "base": p50,
        "buffer_90": recommended_buffer,
        "confidence_90": p90
    }

# 사용 예시
tasks = [
    {"name": "설계", "estimate": 5},
    {"name": "개발", "estimate": 15},
    {"name": "테스트", "estimate": 8}
]

result = monte_carlo_buffer(tasks)
print(f"50% 확률: {result['base']:.0f}일")
print(f"90% 확률: {result['confidence_90']:.0f}일")
print(f"권장 버퍼: {result['buffer_90']:.0f}일")

버퍼 소비 패턴 분석

버퍼가 왜 소비되는지 추적하면 다음 프로젝트를 개선할 수 있습니다.

class BufferConsumptionTracker {
  recordConsumption(day, consumed, reason) {
    this.history.push({ day, consumed, reason });
    
    // 패턴 분석
    const triggers = this.identifyTriggers();
    
    if (triggers[0].reason === "요구사항 변경") {
      console.log("⚠️ 요구사항 동결 필요");
    } else if (triggers[0].reason === "기술적 이슈") {
      console.log("⚠️ 기술 검증 강화 필요");
    }
  }
  
  identifyTriggers() {
    // 원인별 버퍼 소비 집계
    const reasons = {};
    this.history.forEach(h => {
      reasons[h.reason] = (reasons[h.reason] || 0) + h.consumed;
    });
    
    // 상위 3개 원인 반환
    return Object.entries(reasons)
      .sort((a, b) => b[1] - a[1])
      .slice(0, 3)
      .map(([reason, days]) => ({ reason, days }));
  }
}

실전 사례: 결제 시스템 리뉴얼

한 핀테크 회사의 실제 사례입니다.

초기 계획 (경험적 버퍼)

예상: 3개월 + 20% = 3.6개월
실제: 5.5개월 (실패!)

리스크 분석 후 재계획

리스크 평가:
- PCI 규정 준수: 9점
- 레거시 연동: 8점  
- 실시간 처리: 7점
- 보안 경험 부족: 8점

리스크 점수: 72/100
권장 버퍼: 55%
새 예상: 4.65개월

결과

실제: 4.5개월 (성공!)
버퍼 사용: 85%

리스크 기반 버퍼가 프로젝트를 구했습니다.

체크리스트

리스크 기반 버퍼 도입 시:

리스크 요소 정의 (기술, 팀, 요구사항)
각 요소 0-10점 평가
가중치 적용하여 점수 계산
버퍼 비율 산출 (10-70%)
일일 버퍼 소비 추적
주간 리스크 재평가
트리거 포인트 설정
버퍼 소비 원인 분석
패턴 기반 개선

마무리

리스크 기반 버퍼는 "감"이 아닌 "계산"입니다.

불확실성은 제거할 수 없지만, 측정하고 대비할 수는 있습니다.

다음 프로젝트에서 리스크 기반 버퍼를 시도해보세요.
추측이 아닌 데이터로 프로젝트를 관리하는 첫걸음이 될 겁니다.

체계적인 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.

suvery button