스타트업 김대표는 최근 고객 만족도를 높이고자 새로운 모바일 앱을 개발하기로 결심했습니다. 김대표는 “우리 회사에도 카카오톡 같은 앱 하나쯤 있어야지!“라고 생각하며, 급하게 개발사를 찾아갔습니다. 문제는 김대표가 IT나 소프트웨어 개발에 대해 아는 것이 거의 없었다는 점입니다. 그는 상세한 요구사항이나 유저 스토리를 준비하지 않은 채 그저 “대충 이런 기능들이 있으면 좋겠어요”라는 막연한 생각으로 프로젝트를 시작했습니다.

개발팀은 김대표의 요구를 들으며 속으로 걱정이 가득했습니다. ‘대충 이런 기능들’이란 말은 IT 개발자들에게는 악몽 같은 표현이기 때문입니다. 하지만 고객의 요구에 따라 프로젝트가 시작되었습니다. 첫 번째 버전이 완성되자, 김대표는 앱을 사용해보고 깜짝 놀랐습니다. ‘왜 로그인 기능이 없죠?’ 김대표가 개발팀에 물었습니다. 개발팀은 “로그인 기능에 대한 명확한 요구사항이 없었고, 초기에 말씀해주신 ‘카카오톡 같은’ 이라는 요청을 기준으로 작업했습니다”라고 답했습니다.

’아, 그럼 로그인 기능을 추가해주세요.’라고 김대표가 요청하자, 개발팀은 다시 수정 작업에 들어갔습니다. 수정이 이루어지고 나서도 김대표의 불만은 계속되었습니다. ‘왜 메시지 전송이 이렇게 느리죠?’ ‘사용자들이 버튼을 자꾸 잘못 누른다고 하네요.’ ‘이 기능은 생각한 대로 동작하지 않네요.’ 김대표의 요구는 끝이 없었고, 개발팀은 김대표가 새로 요구한 기능을 추가하느라 정신이 없었습니다.

이렇게 시작된 무한 반복의 수정 작업은 프로젝트를 점점 늪으로 빠뜨렸습니다. 김대표는 개발이 계속 지연되는 데 대해 불안해졌습니다. 그는 “도대체 왜 이렇게 시간이 오래 걸리는 거죠? 개발팀이 일을 잘 못하는 건가요?“라고 따졌지만, 사실 문제의 원인은 김대표 자신에게 있었습니다. 처음부터 명확한 요구사항과 유저 스토리가 있었다면, 이러한 반복적인 수정 작업과 시간 낭비는 피할 수 있었을 것입니다.

프로젝트는 원래 예정보다 두 배 이상 길어졌고, 예산도 눈덩이처럼 불어났습니다. 원래 예상했던 개발 비용은 5천만 원이었지만, 추가 수정과 기능 변경 요청으로 인해 비용은 1억 2천만 원까지 치솟았습니다. 개발팀은 밤낮 없이 일했지만, 피로와 스트레스는 커져만 갔고, 팀의 사기는 바닥을 쳤습니다. 심지어 김대표의 회사 내부에서도 불만이 터져 나왔습니다. ‘왜 이렇게 앱 개발이 늦어지나요?’ ‘정말 필요했던 기능이 제대로 구현되지 않은 것 같아요.’

이 모든 혼란 속에서 김대표는 중요한 교훈을 배웠습니다. IT 프로젝트에서 요구사항을 명확히 하는 일은 단순히 서류 작업 이상의 의미가 있다는 것입니다. 요구사항 문서와 유저 스토리 작성은 프로젝트의 나침반과도 같아서, 방향을 명확히 잡아주고, 목표를 잃지 않도록 도와줍니다. 김대표가 처음부터 유저 스토리를 작성했다면, 사용자가 원하는 것이 무엇인지, 어떤 문제를 해결하고자 하는지, 그리고 그 과정에서 어떤 기능이 필요한지 명확히 정의할 수 있었을 것입니다.

요구사항 문서의 필요성​

김대표의 사례에서 보듯이, 요구사항이 명확하지 않으면 소프트웨어 개발은 필연적으로 시간과 금전, 인력을 낭비하는 결과로 이어집니다. 비즈니스 리더들이 이러한 과정을 경험하지 않도록, 프로젝트를 시작하기 전에 반드시 자신이 원하는 바를 명확히 적고 정리하여 내외부 개발팀과 많은 소통을 통해 명확히하고 개선하는 것이 필수적입니다. 요구사항을 작성하는 것이 비록 어렵고 번거로워 초기 시간을 많이 소모하는 것처럼 보일 수 있지만, 명확한 요구사항에 대한 이해 없이 누구도 원치 않는 결과를 위해 모두가 시간과 비용 낭비를 하는 것보다 낫습니다.

누가 도와줄 수 있나요​

그러나 요구사항을 적고 정리한다는 것은 결코 쉬운일이 아니며, requirement engineering 이라는 전문 영역이 있을 정도로 숙련되지 않으면 제대로 작성하기 어렵습니다. 이러한 이유로 많은 기업들이 외부 전문가를 찾아 요구사항 문서를 작성하고 프로젝트를 진행하곤 합니다. 그러나 대부분의 기업은 이런 전문가들에게 큰 비용을 주고 요구사항을 작성할 정도로 비용의 여유가 있지 않습니다. 따라서 현재 프로젝트를 진행시켜야 하는 PM, 대표님들이 직접 지금 배워서 진행하지 않으면 그 누구도 도와주기 어렵습니다. PM을 고용하면 되지 않냐는 질문이 있을 수 있는데, 필자가 경험해본 바로는, 요구사항을 잘 작성하고 개발 프로젝트를 원할하게 이끌 수 있는 PM을 찾고 채용하는 것보다 보통은 직접 배우는 것이 빠릅니다. 대부분의 포지션이 그렇지만, 훌륭한 PM을 찾는 것은 정말 하늘의 별따기 입니다. (프로젝트 매니저, 프로덕트 매니저 모두에게 해당됩니다) 그리고 현재 이 글을 읽는 분들은 그런 PM을 알아보는 안목을 가지고 있지 않을 확률이 높습니다.

직접 배워서 하셔야 합니다​

다시 결론은, 지금이라도 직접 배우지 않는다면 희망이 없습니다. 언제나 그렇듯이 늦었다고 생각할 때가 가장 빠를 때이니깐요. requirement engineering을 배우자는 것은 아닙니다. 우리가 할 수 있는 선에서 원하는 것이 무엇인지 표현하는 방법들을 점진적으로 구체화하고 명확화 하는 것을 배우자는 것입니다. 사실, 도구와 방법은 다양할 수 있습니다. 글을 작성해도 되고, 그림을 그려도 좋습니다. 다만, 일관된 방식으로 읽는 사람으로 하여금 나와 비슷한 이해도를 갖게 하는 것이 목표입니다.

유저 스토리​

필자가 여러 고객사들과 그리고 대표님들과 이야기하고 프로젝트를 진행해 본 결과, "유저 스토리"라는 요구사항 정리 방법이 배워서 써먹기에 가장 현실적인 것을 경험을 통해 알게 되었습니다. 왜냐하면 유저스토리는 기술 적인 언어와 프로세스가 반드시 담겨야 하지 않아도 제품과 서비스가 비즈니스 안에서 어떻게 돌아가야 하는지 사용자 중심으로 기술할 수 있기 때문입니다. 또한, 기획자나 PM의 언어가 아니어도 일상적인 언어로 표현할 수 있는 장점도 있습니다. 개발팀, 디자이너, PM, 비즈니스 이해관계자(stakeholder) 모두가 공유 가능한 언어로 제품에 대해 이야기해볼 수 있는 거의 유일한 방법이기도 합니다. 동시에 유저스토리는 프로젝트 처음부터 끝까지 모든 기능(function)의 역할들이 사용자 고객에게 집중하는 데 유도해주기도 합니다. 개발 프로젝트를 진행해 보신 분들은 아시겠지만, 생각보다 프로젝트에 다양한 역할로 참여하는 사람들이 비즈니스 목표를 이해하거나 집중시키는 것은 매우 고난이도의 일입니다.

이렇게 장점이 많고, 배우기에 (상대적으로) 쉬운 유저스토리에 대해 앞으로 사례와 함께 자세히 소개하도록 하겠습니다.

지속적으로, 그리고 같은 패턴으로 발생하는 문제가 있습니다. 이 문제를 해결하기 위해 사람들은 문제 해결 방법 내지는 솔루션을 고안하고 실행하게 됩니다. 보통의 문제 해결 방법은, 규칙과 프로세스를 세우고 그리고 그 프로세스를 수행할 수 있는 사람을 지정하는 것입니다. 그런데 컴퓨터와 소프트웨어 기술이 발전하면서 사람의 특정 부분을 컴퓨터와 소프트웨어가 대체하기 시작했습니다. 규칙에 의해 주어진 프로세스를 1) 쉬지도 않고 잠도 자지 않으면서 (24/7/365), 그리고 2) 실수 없이 수행할 수 있는 것이 바로 사람에 비해 컴퓨터 소프트웨어의 장점이 되겠습니다. 물론, 여전히 정의한 규칙과 프로세스를 벗어나는 상황에서 컴퓨터와 소프트웨어는 사람을 이기기 어렵습니다. 하지만 이런 한계점에도 불구하고 잘 구축된 시스템과 소프트웨어는, 수 많은 사람의 인력을 대체할 수 있는 지점이 많습니다.

이 때문에, 새롭게 사업을 시작하는 많은 창업자 분들, 혹은 현재의 사업을 확장하기 위한 경영진과 대표님들은 IT 시스템을 구축하여 이 사업화와 확장의 문제를 해결하려는 수요가 있습니다. 이제부터 이런 부류의 사람들을 '클라이언트' 라고 부르겠습니다.

클라이언트가 실제 IT 제품, 시스템을 개발해 본 PM 혹은 개발자 경력을 가지고 있지 않는 이상, 직접 개발을 하진 않을 것입니다. 그렇다면 방법은 2가지인데 제품 개발팀 (PM, 개발자, 디자이너 등)을 직접 채용하여 구성하거나, 아니면 외부의 개발사에게 의뢰하는 것입니다. 사실 개발팀을 채용해서 구성하거나 외주를 하거나 둘 모두 결국 유사한 문제에 봉착하게 되는데 바로 '문제 정의'와 그 문제를 해결하는 제품 혹은 솔루션을 만들기 위한 '제품 요구사항 정의'입니다. 물론 그 뒤에 '제품 기획'등 추가적인 부분이 있겠지만 해당 주제는 이번 글에서 다루지 않도록 하겠습니다.

클라이언트들은 모두 머리속에 대략 문제 정의와 요구사항들이 담겨있습니다. 그리고 사실 꽤나 자신 만만하게 해당 내용을 구두로 잘 설명할 수 있다고 생각하시는 경우가 많습니다. 그래서 서면으로 요구사항을 전달 부탁드리면 지금까지 경험 상, 20% 미만의 분들만 무언가 정리된 문서로 전달을 주시곤 했습니다. 나머지 클라이언트 분들은 유사한 서비스 혹은 서비스들의 조합으로 간략한 문장을 써주시거나 아니면 문서로는 전달이 어렵다는 답변을 많이 받았습니다. 그런데 문서로 전달을 못 주시는 클라이언트 분들이 오프라인 미팅에서 구두로 제대로 된 요구사항을 전달 주실 확률은 극히 적습니다. 적은 확률로, 문서 전달은 못하셨지만, 오프라인 미팅에서 화이트보드와 노트를 가지고 구두로 잘 설명주신 분들이 계셨는데 이 분들은 단순히 문서 작성에 '시간'이 부족해서 전달을 못 주셨던 것입니다. 대부분의 분들은 '시간'이 부족해서가 아니라 요구사항을 정돈된 '문서'로 작성할 줄 모르기 때문에 전달을 못 주신 것을 알게 되었습니다.

사실 내가 무엇을 원하는지 상대방에게 명확하게 표현하고 전달하는 것은 결코 쉬운 일이 아닙니다. 사실 소프트웨어 쪽에선 "requirement engineering"이라는 분야가 있을 정도로 요구사항이라는 것은 꽤나 전문적인 영역입니다. 그렇다고 모든 클라이언트들이 이런 요구사항 엔지니어링이라는 전문 영역을 공부하기 위해 다시 학교를 가서 학위를 딸 수는 없는 노릇입니다. 그렇다고 이런 영역을 학교 가서 공부한다고 좋은 요구사항 문서를 작성하는 역량이 탑재된다는 보장도 없습니다. 더 나쁜 뉴스는, 개발자와 PM을 큰 비용을 들여 고용한다고 해서 역시 좋은 요구사항 문서를 대신 모두 만들어주는 것 역시 보장되지 않는다는 사실입니다. 아무리 개발자와 PM이 많아도 실제 이해관계자와 내부 고객이 무엇이 필요한지 설명하지 못한다면, 문제를 해결하는 제품이 만들어지기는 커녕, 개발 착수 조차 하지 못하는 것이 현실입니다.

결국, 가장 큰 비즈니스 이해관계자인 클라이언트(대표, 리더 등)가 최소한의 적어도 "내가 원하는 것은 이것이다"라고 상대방이 이해할 수 있는 문서를 직접 만들고 관리할 수 있어야 합니다. 당연히 처음부터 잘 할 수는 없습니다. 그럼에도 불구하고 직접 해 보면서 많은 관심과 정성을 가지고 배워야 합니다. 왜냐하면 결국 누구도 "내가 원하는 것이 무엇인지 설명하는 일"은 대체해줄 수 없으며, 누군가가 도와 주더라도 결국 시작 지점은 필요하기 때문입니다.

불행히도, 이 요구사항 문서를 작성하기 위한 교육 콘텐츠들은 찾아봐도 별로 없습니다. 그나마 요구사항 및 기능 명세를 작성할 수 있는 시트 템플릿은 몇몇 외주 플랫폼에서 제공해서 활용할 수 있겠지만, 템플릿 만으론 충분치 않습니다. 그래서 필자가 클라이언트 쪽과 요구사항 관련 이야기를 할 때는 계약 결정 전 2번의 미팅을 가집니다. 1번째 미팅은 그냥 인사하고 대략적으로 어떤 문제를 가지고 계신지 중점적으로 질문합니다. 그리고 무얼 만들고 싶어하시는지 구두로 문의하지만 제대로 된 응답을 크게 기대하진 않습니다. 1번째 미팅 이후, 우리는 요구사항 혹은 기능 명세서 대신, "유저 스토리" 템플릿을 제공해 드립니다. 유저 스토리란, 해당 제품을 이용하게 될 유저(사용자)들이 무엇을 할 수 있어야 하는지에 대한 서술의 묶음입니다. (유저스토리에 대한 자세한 내용은 이후에)

클라이언트 분께 소프트웨어 요구사항 명세서를 적어달라고 하는 것보단 훨씬 더 현실적이지만, 그렇다고 유저스토리 작성이 쉽다는 것은 아닙니다. 그래서 일단 템플릿을 전달드리고, 작성하실 수 있는 만큼만 작성해 달라고 요청합니다. 그리고 약 2번째 미팅을 가지게 됩니다. 2번째 미팅에선 사실 상 "유저 스토리 작성 방법"을 교육해 드립니다. 미비하게 작성된 스토리를 중점적으로 함께 보완해 나가면서, 또는 잘 작성된 부분은 왜 잘 작성되었는지 피드백을 드립니다. 클라이언트 분은 자신이 꼭 만들어야 하는 내용과 직접 작성 (실습)해 본 내용을 바탕으로 교육/학습이 이뤄지기 때문에 정상적인 사람이라면 짧은 시간임에도 불구하고 굉장히 높은 밀도로 빠르게 유저스토리 작성 방법을 숙지하시게 됩니다. (2번째 미팅은 통상 90분 정도 진행됩니다) 모든 유저스토리를 함께 다룰 수 없기 때문에, 쟁점이 되는 부분만 함께 건드리고, 이후엔 다시 숙제로 드립니다. 클라이언트는 이제 좀 더 나은 경험과 지식을 가지고 나머지 유저스토리를 작성해 오십니다. 이제 3번째 미팅에선 모두 작성된 유저 스토리를 빠르게 리뷰하고 보완하여 유저 스토리 1차 fix를 하게 됩니다. 이후 우리는 각각의 유저 스토리와 기능 명세를 mapping 하여 작성하고 연결합니다. 도출된 기능과 난이도, 시간 소요를 바탕으로 견적 비용과 프로젝트 개발 기간을 전달/제안 드립니다.

이렇게 1번 유저 스토리 기반으로 자신이 원하는 것이 무엇인지 작성해 본 클라이언트 분들은, 이후 미래에 훨씬 더 나은, 저 잘 정돈된 유저 스토리 기반의 요구사항 문서를 작성하실 수 있게 됩니다. 물론, 거듭 말하지만 유저 스토리가 요구사항의 전부는 아닙니다. 그럼에도 불구하고 잘 작성된 유저스토리 문서와 내용은, 기능 명세와 기획에 가장 큰 근거가 됩니다.

고객 문제​

사실 모든 회사는 얼마냐 심각한지 정도의 문제이지 대부분 내부 데이터 관리의 문제를 가지고 있습니다. 특히 고객 데이터가 잘 관리되고 있다면, 그것은 분명 내부의 누군가/내부 조직이 의지를 가지고 설계하고 관리하고 운영하는 것이 필요합니다. 마지막으론, 타 조직 구성원들이 이를 어렵지만 따라주어야 합니다. 이는 결코 쉬운 일이 아닙니다. 데이터가 관리 가능한 수준으로 쌓여있지 않다면, 당연하지만 데이터 활용도를 높이긴 어렵습니다. 필요할 때 필요한 데이터를 조회하거나 추출해야하는데, 이게 불가능하기 때문입니다. 그리고 이 문제를 방치하고 시간이 지날수록, 계속해서 데이터 문제를 해결하기 위한 난이도는 더욱 어려워지게 됩니다. 의뢰하신 기업 고객도 이와 비슷한 문제를 가지고 있었습니다.

N년간 다양한 회사 내부 저장 공간(여러 다른 SW 시스템, 장부 등)에, 다양한 데이터 형태로 고객 관련 데이터가 흩어져 있음. 이유는 다음과 같습니다.

1. 회사가 운영되어오면서 시스템과 도구 변경이 이루어졌지만 그에 따라 적절한 데이터 이관이 이뤄지지 않음.
2. 동시에 다양한 운영 시스템/도구를 사용하다보니 복수의 저장소에 동일한 데이터가 저장되기도 하지만, 이벤트 종류에 따라 한 쪽 저장소에만 고객 데이터가 저장되기도 함.

흩어져있는 데이터를 보면, 각 고객 데이터에 고유키가 없을 뿐더러, 심지어 중복된 데이터가 많았습니다. 중복된 데이터들끼리의 칼럼과 데이터 형식도 달랐구요. 각기 다른 데이터 저장소에서 동일한 고객 데이터임에도 불구하고 한 쪽에선 이메일이 누락되어있다면, 다른 쪽에선 대표자 분 모바일 번호가 누락되어있다든지 등의 사례도 존재했습니다.

이런 상황에선 각 데이터 소스(저장소)에서 고유키를 생성해서 병합(merge)한다고 해결될 문제는 아니었습니다.

고객 의뢰 사항​

흩어져있는 고객 데이터를 하나의 데이터 저장소에 통합하여 관리하고 싶음.

Wordpress 는 전 세계 콘텐츠 관리 시스템 (CMS) 시장의 64% 점유, 그리고 전체 웹페이지 시장으로 보면 43%를 점유하고 있는 전 세계에서 가장 많이 사용되고 있는 웹 혹은 CMS 시스템입니다. 고객은 워드프레스 기반의 랜딩페이지를 운영하고 있었고, 고객 문의 form 을 통해 방문자 고객을 리드 고객으로 전환하고 있었는데요.

고객 의뢰 사항​

기업 고객 조직 구성원들의 업무가 모두 하나의 데이터베이스에 기록되어 구성원들의 리소스와 성과가 계산될 수 있도록 해 달라는 의뢰를 받았습니다. 의뢰인인 대표님께서는 업무와 프로젝트가 관리되기 위해선 먼저 업무가 시각화되고 추적되어야 한다는 것을 아주 잘 이해하고 계셨습니다.

많은 조직들이 수 많은 업무 관리도구를 사용하고 있지만, 왜 사용해야 하는지, 어떻게 사용해야 하는지 경영자 분과 조직원들이 제대로 알고 사용하는 경우는 드뭅니다. 그래서 안타깝게도 업무생산성을 올리고 조직의 목표달성을 위해 도움이 되어야 할 업무 관리 도구가 오히려, 생산성을 저해하는데 사용되거나 조직원들의 동기를 저하시키기도 합니다. 업무 관리에 대한 목적과 방법에 대해 자세한 내용은 쿠스랩의 업무 관리 아티클,을 확인해 보세요.

기업 고객 문제 해결 사례들 내용 중심으로 블로그 글들이 게시될 예정입니다. 기대해 주세요.