안녕하세요. ABC Studio의 김영재입니다. 저는 LINE이 2020년에 인수한 일본 최대 규모 딜리버리 서비스 데마에칸(出前館, Demaecan) 프로덕트를 담당하고 있습니다.

데마에칸에서는 레거시 문제를 해소하고 시스템 전체를 리빌딩하는 프로젝트를 진행하고 있습니다. 서비스를 급격히 확장하고 발전하면서 자연스럽게 겪는 과정이라고 볼 수 있는데요. 수백 명의 직원과 수십 명의 경영진으로 스테이크홀더가 매우 많은 조직이기에 처음 리빌딩 프로젝트를 시작할 때는 사람들마다 생각하는 서비스의 기대치가 달라서 파편화된 요건 정의만 거듭했습니다.

그러던 어느 날 동료가 가로축을 사용자 여정(user journey)으로 정의하고 세로축을 기능의 특성에 따라 세 단계로 나눠서 요건을 정리해 보자는 의견을 제안했습니다. 의견을 따라 몇 번 정리해 보니 꽤 좋은 템플릿이라는 것을 깨달았습니다. 모든 스테이크홀더를 불러서 이 템플릿에 맞춰 액티비티를 몇 차례 진행했고, 프로젝트 합의에 큰 도움을 받았습니다.

저희는 이 구성을 'BANEX 템플릿'이라고 이름 지었습니다. BANEX는 'Basic, Additional, New value for an End-user eXperience'의 약자입니다. 해석하면 '사용자 경험을 위한 기본 기능, 부가 기능, 신기능 분류표'라고 할 수 있겠습니다.

BANEX 템플릿은 경영진을 비롯한 모든 프로덕트 스테이크홀더의 눈높이를 맞춰 주면서 엔지니어에게는 좋은 아키텍처를 구성할 수 있는 인사이트를 준다는 장점이 있는데요. 이번 글에서는 거대한 프로젝트를 시작하면서 약 한 달간 BANEX라는 템플릿으로 모두의 인식과 눈높이를 동일하게 맞추는 작업을 진행했던 경험을 나누고자 합니다.

BANEX 템플릿 구성

BANEX 템플릿은 다음과 같이 구성됩니다.

템플릿의 세로축 기준은 아래와 같습니다.

• Basic: 없으면 부끄러운 기능
• Additional: 있으면 좋거나 경쟁사 제품에 특별하게 있는 기능
• New Value: 다음 비즈니스를 바라보는 기능

가로축은 서비스마다 다를 텐데요. 위 예시에서는 일반적인 전자 상거래 서비스에서 사용자가 구매하는 과정의 핵심 단계를 기록했습니다. 만약 네이버 지식iN에서 답글을 쓰는 사용자라면 '질문 선택 > 질문 읽기 > 답변 쓰기 > 답변 올리기'라는 흐름이 될 수 있겠습니다.

템플릿 안에 놓이는 블록은 엘리먼트(Element)라고 부르며 주로 기능(feature)을 적습니다. 예를 들어 '상품 가격의 할인율 표시' 같은 것입니다.

요약하면 BANEX 템플릿은 Basic, Additional, New Value를 사용자 경험의 흐름 관점에서 보며 기능을 정리한 것입니다. 세로축은 전통적인 우선순위 표시인 MSCW(Must Have / Should Have / Could Have / Would Have) 분류와 비슷하지만, 이를 3단계로 간소화하면서 Must Have의 기준을 보다 까다롭게 정의했습니다. 또한 모든 스테이크홀더의 의지를 반영하기 때문에 New Value의 실현 가능성이 Could Have, Would Have 보다 높다는 차이가 있습니다. 

BANEX 템플릿 사용 방법

워크숍에서 종종 진행하는 브레인스토밍 액티비티처럼 BANEX 템플릿으로 액티비티를 진행할 수 있습니다. 어떻게 액티비티를 진행하는지 말씀드리겠습니다.

액티비티 진행 방식과 진행 기간 결정

먼저 액티비티를 어떤 방식으로 진행할지 결정하고 진행 기간을 설정합니다. 

BANEX 템플릿으로 액티비티를 진행할 때는 오프라인에서 화이트보드와 포스트잇을 사용해도 되고, 온라인에서 Miro나 draw.io 등의 온라인 협업 도구를 쓰는 것도 좋습니다. 저는 draw.io에서 퍼실리테이터 한 사람이 템플릿 작성을 전담하면서 Zoom으로 화면을 공유하는 방식으로 진행했는데요. 엘리먼트를 하나씩 검토하는 경우 이와 같이 한 사람이 전담하는 게 엘리먼트가 함부로 옮겨질 위험이 없어서 좋았습니다.

액티비티 기간과 관련해서는 일단 시작하면 길어도 2주 이내에 완료할 수 있도록 압축해서 진행하는 것이 좋습니다. 이 회의에서는 앞으로 최소 1년, 길면 2년간 구현할 내용을 다루기 때문에 중요도가 매우 높다고 참여자들을 설득할 필요가 있습니다.

회의 시간은 한 템플릿당 두 시간 정도가 적당했습니다. 참여자는 본문 제목 대로 거의 모든 스테이크홀더이고, 제 경우에는 10여 명 정도로 모든 경영진과 주요 관계자가 참여했습니다. 보통 3자 중계 플랫폼에서는 최소 세 가지 유형의 최종 사용자가 있으므로 세 번에 걸쳐 두 시간씩 진행했습니다.

BANEX 템플릿에 엘리먼트 생성 및 배치

서비스를 만들 때 종종 서로 상식이 달라서 충돌하는 경우를 볼 수 있습니다. 예를 들어 리뷰 기능에 사진을 올리는 기능이 당연히 있어야 한다고 생각하는 사람이 있는 반면, 글자만 입력해도 충분하다는 사람도 있습니다. 누군가는 아예 리뷰가 필요 없다고 생각할 수도 있습니다. BANEX 템플릿은 이처럼 서로 다른 상식을 엘리먼트를 만들어 배치하는 과정을 통해 의도적으로 충돌시켜 가시화하는 효과가 있습니다. 그 과정을 살펴보겠습니다. 

Basic - 이 정도는 상식 아냐? 응 아니야

Basic 수준에 엘리먼트를 배치하는 것은 모두가 공감하는 상식이라고 합의된 경우에만 가능합니다. 앞서 Basic의 기준을 '없으면 부끄러운 기능'이라고 정의했는데요. 뒤에서 한 번 더 강조하겠지만 이 기준을 엘리먼트마다 엄격하게 적용하는 것이 이 템플릿을 효과적으로 사용하는 제일 중요한 원칙입니다.

예를 들어, 리뷰 기능에서 리뷰를 글로 쓰는 것은 Basic이지만 사진을 올리는 것은 Additional일 것입니다. 물론 서비스마다 Basic의 눈높이가 다를 수 있습니다. 만약 리뷰에 사진이 없으면 서비스 아이덴티티가 흔들릴 정도로 사진이 중요한 서비스라면 사진 올리는 기능까지 Basic이어야겠지요.

참고로 BANEX 템플릿을 작성할 때는 이미 구현한 기능도 다 써놓으면 좋습니다. 프로덕트가 커지면 어떤 기능이 있는지 참여자들이 잘 모르는 경우도 많기 때문입니다. 나중에 엘리먼트마다 '이미 있음 / 없음' 표시도 할 것입니다. 

Additional - 이 정도는 있어야지

초반에 회의를 진행하면 많은 아이디어가 Additional에 모입니다. Additional을 다르게 표현하면 NICE-TO-HAVE라고 할 수 있는데요. 회의 초반에는 보통 자신만의 상식을 주장하기에 앞서 적당히 좋은 기능을 자유롭게 말하기 때문입니다. Additional에 너무 많은 엘리먼트가 쌓인다고 느끼면 아래 그림과 같이 대화하며 하나씩 Basic과 New Value로 옮기는 작업을 진행합니다.

Additional에 잔뜩 쌓인 엘리먼트를 살펴보면서 '우리의 서비스 아이덴티티에 맞게 이 정도는 필수로 있어야지 않겠냐'라고 되물으며 Basic으로 하나씩 내리는 작업은 서비스의 아이덴티티를 더 명확히 정립하는 데에도 도움을 줍니다.

예를 들어, 리뷰 경험을 무척 강조하고 싶은 서비스라면 글뿐 아니라 사진을 등록하는 기능까지 Basic으로 내리고, 더 나아가서 동영상 촬영 기능을 Additional로 새롭게 추가할 수도 있습니다. 또한 아이디어를 더 끌어내 촬영한 사진과 동영상을 서버가 자동 편집해 노출하는 기능을 New Value에 놓을 수도 있습니다.

New Value - 꼭 실현하고 싶은 프로덕트의 미래

New Value는 대략 2년 정도 후에 실현할 수 있거나, Additional의 여러 요소를 다 충족하면 가능해지거나, 사용자에게 제공할 우리만의 독창적인 경험 또는 장기적인 비즈니스 로드맵을 실현하기 위한 기능을 주로 놓습니다. 공감받지 못하는 뜬구름 잡는 엘리먼트가 아니라 모두에게 비전을 제시할 수 있는 엘리먼트를 주로 놓습니다.

당장 실현할 안건이 아니라고 New Value의 가치가 뒷전으로 밀리는 것은 아닙니다. New Value는 특히 엔지니어들에게 크게 다가옵니다. 프로덕트를 설계할 때는 몇 년 후에도 큰 변경이 없도록 아키텍처를 만들어야 하는데요. New Value는 눈앞의 기능을 개발하면서 먼 곳을 볼 수 있게 해줍니다. BANEX 템플릿의 가장 큰 가치라고 할 수 있습니다.

사업 팀은 당장 매출을 끌어올릴 수 있는 요구 사항을 말하고, 엔지니어는 미래의 요구 사항까지 소화할 수 있는 아키텍처를 말합니다. IT 역사에서 이 둘 사이에 접점을 만들기가 참 어려웠는데요. BANEX 템플릿은 사업 팀에서 생각하는 이른바 '뇌피셜' 기능까지 쏟아내게 만들어 접점을 형성하는 데 도움을 줍니다. 물론 사업 팀은 이후에도 새로운 기능을 또 밀어 넣고 싶어지겠지만 그래도 이렇게 한 번 짚고 넘어가면 미안하단 말 한마디는 들을 수 있겠죠.

위 그림처럼 BANEX 템플릿의 New Value는 시스템을 설계하는 엔지니어가 더 나은 판단을 할 수 있도록 도와줍니다. 안건 하나하나 개발하기에 급급하면 기존 코드를 조금씩 변경하면서 대응하다가 이윽고 큰 변화에는 구조적인 한계로 대응하지 못하는 문제가 발생하는데요. 엔지니어가 미래에 실현될 가능성이 높은 기능을 New Value에서 볼 수 있다면 YAGNI(You Ain't Gonna Need It) 문제에 빠지지 않으면서도 미래 지향적인 아키텍처를 생각할 수 있습니다. 

이와 같이 세로축 기준에 따라 엘리먼트를 생성해서 배치하는 작업을 완료하면 여러 가지 가치 판단에 도움을 받을 수 있습니다. 예를 들어 아직 Basic을 다 구현하지 못했는데 어떤 팀에서 New Value에 해당하는 프로젝트를 진행하고 있다면 이를 중단하거나 연기하는 판단을 내릴 수 있습니다. 혹은 그 팀에서 해당 프로젝트를 충분히 독립적으로 진행하고 있다면 그 팀에서 미래 가치를 만드는 중이라고 이해하고 넘어갈 수도 있습니다. BANEX 템플릿은 이처럼 영역별 프로덕트와 팀의 고도화 수준을 보여주기도 합니다.

엘리먼트 정리와 태깅

엘리먼트를 최대한 쏟아내고 세로축 기준에 맞게 어느 정도 배치했다면 이제 엘리먼트에 색을 입히고 태깅하며 정리할 차례입니다. 이 작업은 회의 마지막 20분에 몰아서 해도 좋고, 엘리먼트를 추가하며 진행해도 좋습니다. 엘리먼트 중에는 이미 진행 중인 프로젝트도 있을 텐데요. 일단 표시합니다. 경쟁사에 이미 있는 기능도 표시할 필요가 있습니다. 그것이 곧 사용자의 눈높이이기 때문입니다.  

우선 엘리먼트에 배경색을 칠합니다. 앞서 이미 있는 기능도 모두 엘리먼트에 기록하기를 권했는데요. 구현이 완료된 기능은 회색으로 칠합니다. Basic에 해당하는 엘리먼트에서 몇 개는 빨간색으로 칠해서 시급하다고 표시해 놓으면 좋습니다. 이미 진행 중이거나 다시 개발할 필요가 있거나 부족해서 손을 봐야 할 필요가 있는 엘리먼트는 노란색으로 표시합니다.

다음으로 태그를 붙입니다. 저희는 세 개의 태그(경쟁사에 있음, 재개발 필요, 이미 논의된 프로젝트 이름)를 사용했습니다. 사업 팀에서는 이미 있는 기능에 추가로 노력을 들일 필요가 없다고 생각할 수 있지만, 데마에칸처럼 레거시 문제를 해소하기 위해 많은 컴포넌트를 재설계해야 하는 경우에는 '재개발 필요' 태그가 꽤 중요한 의미를 지닙니다.

엘리먼트 중 이미 계획하고 있거나 진행 중인 프로젝트에 속한 것에는 '프로젝트 이름' 태그를 붙여 넣습니다. '경쟁사에 있음' 태그는 주로 Additional 엘리먼트에 붙이며, 필요하면 New Value에도 붙입니다. 우리의 몇 년 후를 경쟁사에서 이미 실현해 놓았다는 기분은 착잡하지만 현실이니 받아들이고 열심히 만들어야 합니다. Basic에는 굳이 붙일 필요 없습니다. 경쟁사 상황과 상관없이 어차피 꼭 구현해야 하는 엘리먼트이기 때문입니다.

완성된 모습은 아래와 비슷할 것입니다.

빨간색, 노란색, 회색 엘리먼트의 상태를 보면 가로축에서는 Listing 영역의 경쟁력이 매우 떨어진다는 것을 알 수 있습니다. 제대로 구현된 게 없으니 사용자가 목록을 조회하는 경험은 완전히 갈아엎어야 한다고 판단할 수 있겠습니다.

반면 Cart 사용자 경험은 Element 10과 11이 모두 구현돼 있습니다. Additional까지 구현한 셈이니 상대적으로 완성도가 높은 수준인데요. 경쟁사에 있는 Element 12 기능을 추가로 개발할지 검토할 필요가 있겠습니다. 만약 그리 중요한 기능이 아니라면 Listing을 개발하는 데 힘을 쏟는 게 낫다고 판단할 수 있습니다.

BANEX 템플릿에서는 Basic 기능을 최대한 다 실현한 후에 Additional 기능을 실현하기를 권합니다. 이것은 자동차 바퀴부터 하나씩 만들어서 자동차를 만드는 게 아니라, 자전거부터 만든 다음 자동차를 만드는 MVP(Minimum Viable Product) 실현 방법과 상통한다고 볼 수 있습니다.

아키텍처 설계 및 개발 일정 수립

이와 같이 스테이크홀더들이 프로덕트에 기대하는 모든 기능을 나열하고 난 뒤 이를 어떤 아키텍처로 구성할지는 엔지니어의 몫입니다. 아키텍처를 구성한 후에는 각 컴포넌트마다 담당하는 엘리먼트를 매핑할 필요가 있습니다. BANEX 템플릿 안에서 태그로 붙여도 되고, 별도 아키텍처 다이어그램을 그려서 엘리먼트를 매핑하는 방법으로 시각화할 수도 있습니다.

엔지니어는 어느 Basic 엘리먼트를 어느 컴포넌트에서 개발할지 PM(product manager)과 논의합니다. 각 컴포넌트의 릴리스 시기는 물론, 전체 사용자 경험 관점에서 Basic이 충족되는 보다 큰 단위의 일정도 함께 논의하는데요. 이를 통해 최종적으로 전체 Basic 충족 시기를 가늠할 수 있습니다.

설계 후 일정은 현재 개발 상황과 맞닿아 있습니다. 당면한 업무들을 진행해야 하는데 새로운 엘리먼트를 개발하자고 할 수는 없는 노릇이기 때문입니다. 이때 팀원들이 새로운 엘리먼트 개발에 집중할 수 있도록 PM이 스테이크홀더들과 기존 안건을 과감히 조정해 기존에 진행하고 있는 프로젝트를 최대한 줄이거나 없앨 필요가 있습니다. 

PM의 단계별 계획 수립과 진행

PM은 엘리먼트마다 개발하는 단계(phase)를 적절히 나눠서 릴리스까지의 체계를 수립하고 일정을 관리해 프로덕트 완성 시기와 전체 완성도를 예측할 수 있게 만드는 역할을 합니다. PM의 정의에는 여러 가지가 있지만 BANEX 템플릿에서는 이 역할이 중요합니다.

사용자 경험의 모든 엘리먼트를 담는 BANEX 템플릿은 다루는 규모가 크기 때문에 PM은 가급적 단계를 짧게 나눌 수 있도록 노력해야 합니다. 그 과정에서 엔지니어 측과 종종 충돌하며 씨름하게 될 수 있습니다. 예를 들어 개발자 입장에서는 리뷰 기능을 개발할 때 Basic의 글쓰기 기능과 Additional의 사진 업로드 기능을 함께 구현하는 게 API 설계 관점에서나 환경 설정 관점에서 편할 수 있는데요. 이때 PM은 그럼에도 두 기능을 나눠서 릴리스할지 아니면 전체 단계에서 문제가 없다면 Additional이 포함돼 있음에도 한 번에 개발하는 것으로 진행할지 논의하고 결정할 필요가 있습니다.

PM 입장에서는 Basic을 모두 해소하기 전에는 가능하면 Additional 진행을 최대한 억제할 필요가 있습니다. 프로덕트를 만드는 사람으로서 Additional 기능이 대체로 재미있는 기능들이 많기 때문에 자꾸 욕심나기 마련인데요. 그럼에도 전체 프로덕트 관점에서 '부끄럽지 않은 수준'부터 충족할 수 있도록 릴리스하는 게 중요하다고 본인은 물론 팀에도 꾸준히 주지시켜 줄 필요가 있습니다. 물론 Basic을 다 만들고 여유가 생기거나 다른 컴포넌트와의 의존성 문제로 시간이 비어서 Additional을 진행할 여력이 생긴다면 그때는 미리 진행해도 문제없겠습니다. 

아래 그림을 예로 들어보겠습니다. 크게 세 팀(Listing 팀, Selection 팀, Cart 팀)이 독립적으로 각각의 영역에서 개발하고 있다고 가정하겠습니다. 

위 그림 Phase 1을 보면, 모든 팀이 빨간색을 최우선으로 진행하되 상대적으로 완성도가 높은 Selection 팀은 Basic 완료 후 남은 기간에 Additional을 진행하는 것을 볼 수 있습니다. 이를 통해 Selection 영역은 기본적인 수준은 달성됐다고 판단하고 그 자원을 Listing 또는 Cart 팀의 Basic을 구현하는 데 더 공헌하도록 조정할 수 있습니다. 혹은 해당 업무에 배경지식이 많이 필요하거나 팀을 조정하는 데 부담이 있거나 Selection 영역을 고도화하는 편이 서비스 전체 관점에서 더 의미가 있다고 판단하고 Selection 영역만 Additional을 더 많이 구현하도록 결정할 수도 있습니다.

앞서 언급한 대로 전체적으로는 Basic부터 차근차근 채워 나가는 것이 이상적인 모습입니다. 하지만 현실에서는 팀마다 스케줄이 다르므로 Basic 구현을 다 끝내고 다른 컴포넌트와의 의존성이나 릴리스 시기 때문에 기다려야 하는 개발 팀이 있을 수 있습니다. 이런 경우에는 이미 BANEX 템플릿에 Additional이 무엇인지 다 나와 있기 때문에 개발 팀에서 기능 릴리스를 브랜치로 적절히 제어해서 PM의 'Basic 우선 릴리스'라는 요구에 응하면서도 미리 Additional을 구현할 수 있겠습니다. 

그 외 사용 팁과 노하우

BANEX 템플릿을 사용할 때 알아두면 좋을 팁과 노하우를 몇 가지 더 소개하겠습니다.

• 퍼실리테이터는 처음에 서로 엘리먼트를 쏟아낼 때 너무 넓은 범위로 생각이 튀지 않도록 계속 범위를 좁히는 일을 담당해야 합니다. BANEX 템플릿도 본질적으로는 이런저런 기능을 도출해서 배치시키는 활동으로 브레인스토밍의 특성이 있는데요. 처음에는 Basic으로 범위를 좁혀서 엘리먼트를 만들 수 있도록 유도하고, '없으면 부끄러운 기능인가?'라는 기준으로 서로 질문하게 만들 필요가 있습니다.
• BANEX 템플릿의 가로축이 반드시 최종 사용자의 여정일 필요는 없습니다. 제 경우 최종 사용자 외에도 복잡한 운영 영역(정산, 파트너 등록 등)을 몇 개 진행했는데요. 프로세스가 갖춰져 있다면 어떤 주제든 BANEX 템플릿을 활용할 수 있습니다.
• BANEX 템플릿 액티비티 회의가 끝난 후 좋은 아키텍처를 만들기 위한 액티비티도 이어서 진행하면 좋습니다. 제가 번역한 개발자에서 아키텍트로 책을 보면 아키텍처 플립북과 인셉션 덱 등 활용하기 좋은 38가지 액티비티를 소개하고 있으니 참고하시기 바랍니다.

마치며

BANEX 템플릿을 활용하다 보니 프로덕트의 수준과 현장의 상황에 따라 새로 개발할 엘리먼트의 Basic과 Additional, New Value의 비율이 다르다는 점을 알 수 있어서 흥미로웠습니다. 완성도가 높은 프로덕트는 비율이 2:5:3 정도였고, 완성도가 낮은 프로덕트는 5:4:1 정도로 엘리먼트의 절반이 Basic인 수준이었습니다. 비율만 봐도 미래(New Value)를 바라보며 나아가고 있는 프로덕트와 지금 상태로는 너무 부끄러우니 빨리 기본기를 올리자는 마음으로 만들어야 하는 프로덕트가 무엇인지 알 수 있었습니다.

BANEX 템플릿은 시각적으로 서비스의 크기와 복잡도를 보여주기도 합니다. 최종 사용자에게 기대하는 시나리오가 단순하면 전체적으로 엘리먼트 수가 적습니다. 예를 들어 음식점에서 사용하는 주문 확인 소프트웨어는 기능이 단순한 편이므로 엘리먼트 수가 적은 반면, 사용자가 음식을 주문하는 소프트웨어는 아주 많은 기능이 필요해서 엘리먼트가 빡빡하게 들어서며 세로축이 부쩍 길어지곤 합니다. 이런 차이가 자연스럽게 프로덕트의 크기와 복잡도를 시각적으로 보여주며, 경영진에게 프로젝트 수행 비용을 가늠할 수 있는 힌트를 제공합니다. 

프로덕트 릴리스 사이클이 계속 돌아가면 점차 Basic은 다 실현되고 Additional이 새로운 Basic으로 자리 잡습니다. 이에 따라 사용자의 눈높이와 경쟁사의 수준도 올라가겠죠. 이처럼 변화를 관찰할 수 있는 것도 BANEX 템플릿의 또 하나의 매력이라고 할 수 있습니다. 프로덕트를 만드는 팀이라면 어디든 의미 있게 활용하시길 기대하며 이만 마치겠습니다.