요구사항 정리
스타트업 김대표는 최근 고객 만족도를 높이고자 새로운 모바일 앱을 개발하기로 결심했습니다. 김대표는 “우리 회사에도 카카오톡 같은 앱 하나쯤 있어야지!“라고 생각하며, 급하게 개발사를 찾아갔습니다. 문제는 김대표가 IT나 소프트웨어 개발에 대해 아는 것이 거의 없었다는 점입니다. 그는 상세한 요구사항이나 유저 스토리를 준비하지 않은 채 그저 “대충 이런 기능들이 있으면 좋겠어요”라는 막연한 생각으로 프로젝트를 시작했습니다.
개발팀은 김대표의 요구를 들으며 속으로 걱정이 가득했습니다. ‘대충 이런 기능들’이란 말은 IT 개발자들에게는 악몽 같은 표현이기 때문입니다. 하지만 고객의 요구에 따라 프로젝트가 시작되었습니다. 첫 번째 버전이 완성되자, 김대표는 앱을 사용해보고 깜짝 놀랐습니다. ‘왜 로그인 기능이 없죠?’ 김대표가 개발팀에 물었습니다. 개발팀은 “로그인 기능에 대한 명확한 요구사항이 없었고, 초기에 말씀해주신 ‘카카오톡 같은’ 이라는 요청을 기준으로 작업했습니다”라고 답했습니다.
’아, 그럼 로그인 기능을 추가해주세요.’라고 김대표가 요청하자, 개발팀은 다시 수정 작업에 들어갔습니다. 수정이 이루어지고 나서도 김대표의 불만은 계속되었습니다. ‘왜 메시지 전송이 이렇게 느리죠?’ ‘사용자들이 버튼을 자꾸 잘못 누른다고 하네요.’ ‘이 기능은 생각한 대로 동작하지 않네요.’ 김대표의 요구는 끝이 없었고, 개발팀은 김대표가 새로 요구한 기능을 추가하느라 정신이 없었습니다.
이렇게 시작된 무한 반복의 수정 작업은 프로젝트를 점점 늪으로 빠뜨렸습니다. 김대표는 개발이 계속 지연되는 데 대해 불안해졌습니다. 그는 “도대체 왜 이렇게 시간이 오래 걸리는 거죠? 개발팀이 일을 잘 못하는 건가요?“라고 따졌지만, 사실 문제의 원인은 김대표 자신에게 있었습니다. 처음부터 명확한 요구사항과 유저 스토리가 있었다면, 이러한 반복적인 수정 작업과 시간 낭비는 피할 수 있었을 것입니다.
프로젝트는 원래 예정보다 두 배 이상 길어졌고, 예산도 눈덩이처럼 불어났습니다. 원래 예상했던 개발 비용은 5천만 원이었지만, 추가 수정과 기능 변경 요청으로 인해 비용은 1억 2천만 원까지 치솟았습니다. 개발팀은 밤낮 없이 일했지만, 피로와 스트레스는 커져만 갔고, 팀의 사기는 바닥을 쳤습니다. 심지어 김대표의 회사 내부에서도 불만이 터져 나왔습니다. ‘왜 이렇게 앱 개발이 늦어지나요?’ ‘정말 필요했던 기능이 제대로 구현되지 않은 것 같아요.’
이 모든 혼란 속에서 김대표는 중요한 교훈을 배웠습니다. IT 프로젝트에서 요구사항을 명확히 하는 일은 단순히 서류 작업 이상의 의미가 있다는 것입니다. 요구사항 문서와 유저 스토리 작성은 프로젝트의 나침반과도 같아서, 방향을 명확히 잡아주고, 목표를 잃지 않도록 도와줍니다. 김대표가 처음부터 유저 스토리를 작성했다면, 사용자가 원하는 것이 무엇인지, 어떤 문제를 해결하고자 하는지, 그리고 그 과정에서 어떤 기능이 필요한지 명확히 정의할 수 있었을 것입니다.
요구사항 문서의 필요성
김대표의 사례에서 보듯이, 요구사항이 명확하지 않으면 소프트웨어 개발은 필연적으로 시간과 금전, 인력을 낭비하는 결과로 이어집니다. 비즈니스 리더들이 이러한 과정을 경험하지 않도록, 프로젝트를 시작하기 전에 반드시 자신이 원하는 바를 명확히 적고 정리하여 내외부 개발팀과 많은 소통을 통해 명확히하고 개선하는 것이 필수적입니다. 요구사항을 작성하는 것이 비록 어렵고 번거로워 초기 시간을 많이 소모하는 것처럼 보일 수 있지만, 명확한 요구사항에 대한 이해 없이 누구도 원치 않는 결과를 위해 모두가 시간과 비용 낭비를 하는 것보다 낫습니다.
누가 도와줄 수 있나요
그러나 요구사항을 적고 정리한다는 것은 결코 쉬운일이 아니며, requirement engineering 이라는 전문 영역이 있을 정도로 숙련되지 않으면 제대로 작성하기 어렵습니다. 이러한 이유로 많은 기업들이 외부 전문가를 찾아 요구사항 문서를 작성하고 프로젝트를 진행하곤 합니다. 그러나 대부분의 기업은 이런 전문가들에게 큰 비용을 주고 요구사항을 작성할 정도로 비용의 여유가 있지 않습니다. 따라서 현재 프로젝트를 진행시켜야 하는 PM, 대표님들이 직접 지금 배워서 진행하지 않으면 그 누구도 도와주기 어렵습니다. PM을 고용하면 되지 않냐는 질문이 있을 수 있는데, 필자가 경험해본 바로는, 요구사항을 잘 작성하고 개발 프로젝트를 원할하게 이끌 수 있는 PM을 찾고 채용하는 것보다 보통은 직접 배우는 것이 빠릅니다. 대부분의 포지션이 그렇지만, 훌륭한 PM을 찾는 것은 정말 하늘의 별따기 입니다. (프로젝트 매니저, 프로덕트 매니저 모두에게 해당됩니다) 그리고 현재 이 글을 읽는 분들은 그런 PM을 알아보는 안목을 가지고 있지 않을 확률이 높습니다.
직접 배워서 하셔야 합니다
다시 결론은, 지금이라도 직접 배우지 않는다면 희망이 없습니다. 언제나 그렇듯이 늦었다고 생각할 때가 가장 빠를 때이니깐요. requirement engineering을 배우자는 것은 아닙니다. 우리가 할 수 있는 선에서 원하는 것이 무엇인지 표현하는 방법들을 점진적으로 구체화하고 명확화 하는 것을 배우자는 것입니다. 사실, 도구와 방법은 다양할 수 있습니다. 글을 작성해도 되고, 그림을 그려도 좋습니다. 다만, 일관된 방식으로 읽는 사람 으로 하여금 나와 비슷한 이해도를 갖게 하는 것이 목표입니다.
유저 스토리
필자가 여러 고객사들과 그리고 대표님들과 이야기하고 프로젝트를 진행해 본 결과, "유저 스토리"라는 요구사항 정리 방법이 배워서 써먹기에 가장 현실적인 것을 경험을 통해 알게 되었습니다. 왜냐하면 유저스토리는 기술 적인 언어와 프로세스가 반드시 담겨야 하지 않아도 제품과 서비스가 비즈니스 안에서 어떻게 돌아가야 하는지 사용자 중심으로 기술할 수 있기 때문입니다. 또한, 기획자나 PM의 언어가 아니어도 일상적인 언어로 표현할 수 있는 장점도 있습니다. 개발팀, 디자이너, PM, 비즈니스 이해관계자(stakeholder) 모두가 공유 가능한 언어로 제품에 대해 이야기해볼 수 있는 거의 유일한 방법이기도 합니다. 동시에 유저스토리는 프로젝트 처음부터 끝까지 모든 기능(function)의 역할들이 사용자 고객에게 집중하는 데 유도해주기도 합니다. 개발 프로젝트를 진행해 보신 분들은 아시겠지만, 생각보다 프로젝트에 다양한 역할로 참여하는 사람들이 비즈니스 목표를 이해하거나 집중시키는 것은 매우 고난이도의 일입니다.
이렇게 장점이 많고, 배우기에 (상대적으로) 쉬운 유저스토리에 대해 앞으로 사례와 함께 자세히 소개하도록 하겠습니다.
물론, 해당 비즈니스 도메인 분야에 전문성이 반드시 필요합니다. 해당 분야의 전문성이 없는데 무언가를 만들어야 하는 상황은 도움을 받기 어렵습니다. 최소한 문제 정의를 할 수 있고, IT 제품 없이도 해당 문제가 어떻게 해결되는지, 될 수 있는지 설명할 수는 있어야 합니다.