흔히들 말한다. 서비스 개발 도중에 미리 이야기되어 있지 않은 기능이 추가되거나, 엉뚱한 방향으로 기능이 변경되는 것은 상당한 유지 보수 비용(Cost)을 불러온다고… 누군가는 이를 두고, 공사 중인 빌딩을 옆으로 몇 미터 옮기는 것에 비유하기도 했다. 커다란 빌딩을 옮기는 일은 고작 몇 미터일지라도 매우 큰 공사비가 필요할 테니 말이다. 또, 어떤 개발자는 잘 나가고 있는 소설의 주인공이 갑자기 바뀌는 맥락과 같다고 이야기하기도 한다. 해리포터의 주인공이 갑자기 말포이로 바뀐다면… 상상하기도 어렵다.

그런데 프로젝트를 진행하다 보면 갑작스럽게 서비스의 특정 기능이 변경되거나, 기존의 DBA에 위협을 주는 신규 기능 개발 제안이 들어오곤 한다. 노련한 PM이나 기획자라면 응당 이를 막거나 기획적으로 풀어내야겠으나 도저히 그럴 수 없는 상황이 발생하기도 한다. 1화에서 이야기했던 “비즈니스”가 그것이다. 예측하지 못한 방향으로 매출이 발생하거나, 비용이 발생한다면… 이런 경우 경영자는 서비스의 큰 방향성에 대해 재고할 수도 있다. 정도에 따라서는 프로젝트가 중단될 수도 있다.

그런데 위와 같은 이야기는 그리 낯설지 않을 것이다. 빠른 속도로 변화하는 IT업계에서 프로젝트의 방향성이 바뀌는 경우는 비일비재하기 때문이다. 물론 위와 같이 큰 방향성이 바뀌는 경우는 극단적인 예시이며, 일어나서는 안 될 일이다. 보통은 조금 골치 아픈 수준의 변경이 대다수다.

이번 이야기를 시작하기에 앞서 이러한 이야기를 하는 것은, 최초로 설계한 Structure가 런칭까지 이어지기 어려움을 설명하기 위함이다. 마찬가지로 운영과정에서도 변경이 잦을 수 있다. 그리고 이 고된 역경 앞에서 흔들리지 않고, 굳건한 구조를 설계해나가는 것은 서비스 기획자의 숙명이다.

어떻게 하면 탄탄한 구조를 만들 수 있을까? 나는 서비스의 구조 설계를 크게 3가지로 구분하여 생각한다. 그 첫 번째는 정보구조 설계이다. 전체를 바라보는 그림. 그리고 화면과 퍼널 설계를 통해 정보를 올바른 방향으로 보낼 도로를 설계한다. 마지막은 모든 것을 아우르는 인프라, 실무 파이프라인 설계이다.

1. Information Architecture

IA. 정보구조 설계라고도 불리는 이 것은 그림 그리기로 비유하면, 밑그림을 그리는 과정이다. 그리고, 서비스에 대한 모든 정보가 담겨있는 도식이다. 과장해서 이야기하자면 사이즈의 제한이 없는 캔버스에 정보구조를 빠짐없이 그려내는 것만으로 세상의 모든 서비스의 형태를 완벽하게 보여줄 수 있다. 멀리서 보면 서비스의 전체적이 모습이 보이고, 돋보기를 들고 들어가면 각 화면이나 플로우에서 가능한 액션, 결과물까지도 파악할 수 있는 것이다. (물론 프로젝트에 따라 작업의 범위는 매우 상이하다.)

정보구조는 어떻게 설계하는 게 좋을까? 그전에 정보구조는 왜 설계하는 것일까? 어차피 스토리보드를 읽어보면 각 기능을 더욱 섬세하게 이해할 수 있는데 말이다.

그거다. 개발자가 IA를 관심 있게 들여다보지 않고, 스토리보드만 들여다본다면, 특히 그 개발자가 DBA담당이라면, 이번 프로젝트… 아즈카반의 죄수 즈음에는 주인공이 말포이로 바뀔 예정이다.

정보 구조를 보면, 이게 어떤 서비스인지 대략적으로 알 수 있어야 한다. 실무 관계자들에게 우리가 만들어야 할 서비스를 이해시킬 수 있는 가장 기본적인 도구가 되는 것이다. 그냥 거미줄에 글자 그려진 박스 몇 개가 얹어진 정도로 정보 구조를 설계했다면, 그리고 설명 없이는 아무도 이 정보구조를 이해할 수 없다면 아무리 꼼꼼하게 잘 만들었다고 해도 협업에는 실패한 정보구조다.

기획자는 서비스의 전반적인 형태를 그리기 위해 정보 구조를 설계한다(Input). 개발자도, 사업 기획자는 전반적으로 서비스를 이해하기 위해 정보 구조를 읽는다(Print). 그러므로 정보구조는 단순히 뼈대를 만드는 작업이 아니라 작업지시서와 곁들여 볼 수 있는 부록이라고 생각하면 좋다.

또, 정보 구조는 아주 큰 흐름을 보여주는데 최적화되어있다. 단순히 정보를 배치하고 종속 여부만 보여주기엔 너무 아쉽다. 서비스 내에서 각 기능 간의 정보 흐름을 보여주는 방법은 그리 많지 않다. 오로지 정보구조에서만 전체적인 흐름 파악이 가능하다. 그러니 각 어떤 식으로 상호작용하는지 동적으로 파악할 수 있도록 보여주는 것은 매우 좋은 방법이다.

정보구조는 잘 설계하는 것만큼 잘 이해시켜야 한다.

2. Display & Funnel

플로우 대신 퍼널이라는 단어를 사용했다. 퍼널은 마케팅에서 많이 사용되는 용어다. 이해만 되면, 어디다가 써도 상관없다고 생각한다. 퍼널은 뾰족한 꼭짓점을 향해 가는 긴 터널이다. 정확한 목표를 가지고 설계되어야 한다는 것이다. 그리고 이 목표를 향해 가는 길에 문제를 발견하고 해결하기 위해서는 화면이 어떻게 생겼고, 이 화면에서 유저가 어떤 행동을 하는지 이해해야 한다.

화면과 퍼널을 두 번째로 뽑은 이유는 “서비스의 목적”과 이 “목적에 방해되는 모든 요소”를 인식하기 위해 가장 적당한 주제이기 때문이다. 화면에는 다양한 요소들이 존재한다. 버튼, 텍스트, 이미지. 각 요소는 굉장히 단순하기도 하고 굉장히 복잡하기도 한데 각각 분명한 존재가치를 가지고 있다. 그리고 각 요소들은 유저로 하여금 반드시 “어떤” 행동을 하게끔 유도하는 장치가 된다.

예를 들어 작성된 댓글은 클릭하면 삭제하거나, 신고할 수 있다. 댓글 작성을 클릭하면, 댓글을 작성할 수 있다. 여기까지는 단순히 한 화면에 대한 이야기다.

이번엔 상품의 상세페이지를 예로 들어보자. 구매하기 버튼이나, 옵션 선택 버튼을 클릭하고 난 다음은 어떤 일이 발생할까? 장바구니나 주문서 작성으로 이동하게 될 것이다. 유저는 그 화면에서 최종적으로 해당 상품을 구매하게 된다. 이번에는 한 화면에 배치된 구성요소가 “구매전환”이라는 목표까지 염두하고 설계됨을 보여주는 예시다.

플로우 대신 퍼널이라는 단어를 사용한 이유다. UX는 유저가 편리하게 행동할 수 있도록 돕는 역할을 하지만, 안내견보다는 양을 몰고 다니는 양치기견에 가깝다. 유저가 어디로 가야 할지 알려주고, 다양한 정보 속에서 기업에 유익한 방향으로 고객을 유인하는 것이다. 그래서 화면과 퍼널 설계는 그래서 운영과 매우 가까운 관계다.

끊임없이 변화하고 개선되어야 한다는 소린데, 문제는 여기서 발생한다. 변화가 가장 잦은 부분인 만큼 자칫하면 해리포터가 마법사가 아니라 사냥꾼이 될 수 도 있는 것이다. 그런 일이 생기지 않도록 구조와 개선 사이에서 줄다리기를 해야 하니, 서비스 기획에서 가장 재미있는 부분이라고 개인적으로 생각한다.

3. Pipeline

서비스 기획자의 마지막 구조 설계는 서비스 그 자체보다는, 실무 파이프라인에 대한 설계다. 그러다 보니 PO 역할을 하는 서비스 기획자에 해당하는 이야기이다. DevOps는 원활한 개발을 위한 인프라 세팅과 협업 구조를 설계하는 역할을 한다. 무수한 데이터를 제대로 다루기 위해 반드시 데이터 거버넌스가 사전에 정의되어야 하는 것도 같은 맥락이다.

어떻게 기획하고 전달하면 서비스 개발에 기여할 수 있을지 고민하는 것이 파이프라인 설계의 핵심이다. 어떻게 하면 좋을까? 기획서를 어떤 주기로 어떻게 공유할지 정하는 것부터 시작이다. 개발자와의 커뮤니케이션을 어떤 방식으로 하면 좋을지 작은 규칙을 만드는 것으로 확장해보면 좋다. 개발환경에 알맞은 디자인 시스템을 설계하면 디자인, 개발 직군이 상호 간에 공유할 수 있는 업무 가이드라인이 될 수 있다. 여기까지는 서비스 기획에 영역에서 어렵지 않게 해 볼 수 있는 일이다. (한 문단으로 설명했지만, 사실 이 과정들은 매우 길고 복잡하며, 프로젝트의 특성별로 상이하다.)

좀 더 나아가서 “서비스” 자체를 위한 업무 파이프라인을 설계하는데 기여할 수도 있다. 서비스 기획을 하다 보면 본의 아니게 다른 실무자들의 업무 프로세스를 파악하게 된다. 특히 서비스의 백오피스나 사내 ERP, 업무용 프로그램을 기획하게 되면 당장 해당 직무에 신입으로 취업해도 될 것 같은 기분이 든다. 농담 반 진담 반.

서비스 기획자의 관점으로 보기 때문에 실무 그 자체보다는, 이들의 업무가 효율적인지, 그렇지 않다면 무엇이 문제이며 어떻게 하면 효율화할 수 있을지에 대한 관점으로 바라보게 된다. 이들도 나에게는 고객이다. 아닌 게 아니라 쇼핑몰의 관리자 페이지를 기획할 때 회사의 MD는 고객이 맞다. 그러면 파이프라인 설계는 기능적인 부분에서 이들의 서비스 사용경험을 개선하고, 업무를 효율화하는 것으로 시작되며, 그 끝은 생각보다 넓은 영역이 될 수도 있다.

위 내용을 요약하자면 서비스 기획의 구조설계는 전체적인 설계, 운영을 위한 설계, 업무 효율을 위한 설계로 구분되는 것이다.

그리고 중요한 것. 서비스 구조 설계는 비즈니스 설계로부터 후행되는 것이 아니라, 특정 시점부터는 끊임없이 상호작용하며 변화한다는 점이다. 큰 변화로 인해 실패를 맛 본 서비스 기획자는 굉장히 가변적인 기획을 하기도 하는데 Cost가 충분치 않다면 절대로 해서는 안될 일이다. (경험담이다.) 어째 쓰면 쓸수록 쓰고 싶어지는 말들이 많아지는 것 같다. 오늘 이야기한 내용들을 예시를 통해 자세히 다뤄볼 기회가 있으면 좋겠다.

beyes 님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.