쿠스랩은 이렇게 고객사 요구사항을 함께 정리합니다
지속적으로, 그리고 같은 패턴으로 발생하는 문제가 있습니다. 이 문제를 해결하기 위해 사람들은 문제 해결 방법 내지는 솔루션을 고안하고 실행하게 됩니다. 보통의 문제 해결 방법은, 규칙과 프로세스를 세우고 그리고 그 프로세스를 수행할 수 있는 사람을 지정하는 것입니다. 그런데 컴퓨터와 소프트웨어 기술이 발전하면서 사람의 특정 부분을 컴퓨터와 소프트웨어가 대체하기 시작했습니다. 규칙에 의해 주어진 프로세스를 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번 유저 스토리 기반으로 자신이 원하는 것이 무엇인지 작성해 본 클라이언트 분들은, 이후 미래에 훨씬 더 나은, 저 잘 정돈된 유저 스토리 기반의 요구사항 문서를 작성하실 수 있게 됩니다. 물론, 거듭 말하지만 유저 스토리가 요구사항의 전부는 아닙니다. 그럼에도 불구하고 잘 작성된 유저스토리 문서와 내용은, 기능 명세와 기획에 가장 큰 근거가 됩니다.