[코드스테이츠 PMB 7기] 워터폴(Waterfall) 방식으로 구성해 보는 카카오톡의 멀티프로필 기능과 개선

728x90

생각을 시작하며...

어떠한 방법론을 대할 때 '언제나 새로운 것이 좋고 예전 것은 좋지 않다'는 인식으로 접근하는 경우를 많이 발견할 수 있다. 물론 새로운 방식은 대부분 예전 방식을 보완해서 나왔을 가능성이 높지만 그렇다고 기존의 방식을 완전히 대체할 수는 없을 가능성이 크다는 점도 염두에 두어야 할 것이다. 예전 방법이 오랜 기간에 걸쳐 사용되어 왔던 만큼 좋은 점도 있고 나쁜 점도 있다는 것이다.
그렇기 때문에 어떤 방법론을 고를 때는 그것을 사용하는 구성원들의 성향, 역량 등과 스케줄, 리소스, 서비스의 특징 등 주어진 상황에 맞게 취사선택해야 한다.

이번에는 카카오톡의 멀티 프로필에 대한 기획 과정을 유추해보는 시간을 가져볼까 한다.

(1) 카카오톡 멀티 프로필 화면 설계서

멀티 프로필의 핵심 기능 중 프로필 생성과 친구 및 채팅 추가의 기능의 화면 설계서를 작성해 보겠다. 나머지 기능들에 대하여는 기존 카카오톡 프로필 구성과 많이 다르지 않기 때문에 새로운 기능을 추가했을 때 화면을 어떻게 설계할 것인지를 초점에 맞췄다. (이런 입장으로 화면 설계서를 작성해보니 오히려 요구사항 정의서와 합쳐진 느낌이다.)

어차피 화면 설계서라는 것이 한 번 정해진 후 고정시키는 것이 아니라 단계별로 만들어 갈 수 있는 것이기 때문에 여러가지 형태로 표현할 수 있을 것이다. 또한 이 화면 설계서를 만들다 보니.... 와이어프레임을 말로 푸는 형식이라서 피그마의 프로토타입을 이용하면 굳이 이런 화면 설계서를 쓰지 않거나 혹은 최소화시킬 수 있을 것 같다고 느꼈다.

▶ Flow 및 화면설계서

친구 기본 화면 → 멀티 프로필 설정 → 멀티 프로필 메인 화면 → 프로필 친구 관리 → 채팅 추가 화면 → 친구 추가 화면 → 친구 관리 → 멀티 프로필이 추가된 친구 기본화면

화면 아이디	화면 이름	화면 경로	Description
MulP-1	친구 기본 화면	카카오톡 어플 실행 후 친구 탭 터치	> 기존 친구 탭의 멀티 프로필 설정 추가 - 기능: 멀티 프로필 생성 및 설정 화면으로 이동 - 위치: 내 프로필 바로 아래 블록 - UI 디자인: 둥근네모박스에 플러스 (사이즈 H/W) - UX Writing: Title: 내 멀티 프로필 설명: 친구별로 다른 프로필을 설정해 보세요! - 부가 기능: 아래의 블록들과 마찬가지로 열리고, 접히는 블록으로 만듦
MulP-2	멀티 프로필 설정	MulP-1에서 멀티 프로필 설정 터치	기존의 프로필 생성 및 설정 화면과 동일하게 구성 완료 후에는 멀티 프로필 홈으로 화면 이동
MulP-3	멀티 프로필 메인화면	MulP-2에서 완료 터치	> 멀티 프로필 노출을 위한 친구 관리 기능 추가 - 기능: 멀티 프로필로 보여줄 친구 밑 채팅방을 설정할 수 있는 화면으로 이동 - 위치: 프로필 편집 오른쪽 (간격 n px) - UI 디자인: 사람 모양 (사이즈 H/W) - UX Writing: 친구 관리 (설정 모양 아이콘 추가 (사이즈 H/W)
MulP-4	프로필 친구 관리	MulP-3에서 친구 관리 터치	> 친구 관리 화면 - 기능: 시나리오 A: 이미 설정한 친구가 있다면 친구관리 (MulP-7) 시나리오 B: 설정해 놓은 친구가 없다면 ‘지정친구 추가’ 설정 기능 추가 - 위치: 중앙에 ‘지정친구 추가’ - UI 디자인: 어피치, 튜브 캐릭터 이용 - UX Writing Title: 프로필을 보여줄 친구를 지정해 보세요 설명: 지정친구는 항상 이 프로필로 나를 보게 됩니다. 버튼: 지정친구 추가 - 부가기능: 프로필 설정으로 되돌아 가기
MulP-5	채팅 추가 화면	MulP-4에서 지정 친구 추가 터치	> 채팅 추가 화면 - 기능: A: 채팅 탭 친구를 추가하기 B: 채팅방 옆의 체크박스 터치 시 선택 - UI 디자인: 기존의 친구 편집 설정과 동일 - 부가기능: 프로필 설정으로 되돌아가기, 완료 (완료 왼쪽 체크된 친구 수 표시)
MulP-6	친구 추가 화면	MulP-5에서 친구 탭 터치	> 친구 추가 화면 - 기능: 채팅방 옆의 체크박스 터치 시 선택 - UI 디자인: 기존의 채팅방 편집 설정과 동일 - 부가기능: 프로필 설정으로 되돌아 가기, 완료 (완료 왼쪽 체크된 친구 수 표시)
MulP-7	친구 관리	MulP-5,6에서 설정 후 완료 버튼 터치	> 친구 관리 (추가, 해제, 검색, 편집 기능) - 기능 A: 친구 추가 (멀티 프로필을 보여줄 친구 추가 기능) B: 개개인의 해제 기능 (멀티 프로필을 보여줄 친구 해제 기능) C: 멀티 프로필을 보여주는 친구 검색 기능 D: 다수의 친구들을 편집하는 기능 - 부가기능: 프로필 설정으로 되돌아 가기,
MulP-8	멀티프로필이 추가된 친구 기본 화면	MulP-7에서 뒤로가기 터치 MulP-3에서 뒤로가기 터치	> MulP-3과 동일 추가된 멀티프로필을 선택 가능

(2) 유저 스토리와 솔루션 그리고 백로그

위의 화면 설계서를 작성을 해 보니 서비스를 개발하는 것에도 도움이 될 수 있지만 사용에 있어서 고객의 문제점을 발견해 낼 수 있다는 생각이 들었다. 그렇기 때문에 이제는 고객의 입장에서 유저스토리를 작성해 문제점과 서비스를 개발하는 목록인 백로그를 작성해 보려고 한다.

▶ 유저 스토리에 따른 문제점 발견

기본적으로 멀티 프로필을 사용하는 사람들의 페르소나 혹은 유저 스토리(User Story)를 살펴보면 자신을 숨기려는 목적이 있을 가능성이 크다. 다른 말로 하자면 '진짜 나'와 '다른 사람에게 노출되는 나'를 나누고 싶다는 점이다. 이런 목적이 있는 사람들의 대부분은 자신이 멀티 프로필을 설정했을 때 지정된 친구들이 이런 설정을 알아차리게 하고 싶지 않을 것이다.

하나의 페르소나로 초등학교 교사를 생각해 보자. 초등학교 교사는 크게 3개의 사회적 자아로 나누어 볼 수 있다. 1) 교사와 교사의 관계, 2) 교사와 학생/학부모와의 관계, 3) 개인적인 관계. 이런 자아들은 특성이 각각 다른데 만일 모든 상황에서 관계가 원만하다면 하나의 프로필로 사용하는 것이 문제가 되지 않는다. 하지만 각각의 상황에서 관계가 문제가 되거나 자아의 괴리가 심해지면 문제가 될 수 있다.

대표적인 사례가 교사가 자신의 SNS에 올린 것을 학부모가 보고 교육청에 클레임을 거는 경우가 있었다. 이런 경우에는 개인적인 관계에서의 자아와 학교 교사로서의 자아가 부딪힌 경우이다. 그래서 교사들 중에는 투폰이라는 서비스를 사용하거나 혹은 아예 휴대폰을 2개 사용하는 사람들도 어느 정도 있었다. 문제는 이렇게 투폰을 사용하는 경우에도 학부모들이 원래 전화번호를 알아내려고 하고 또한 학교에 역시 클레임을 거는 경우도 있었다.

이런 상황에서 멀티 프로필을 사용한다고 했을 때 내가 설정한 멀티 프로필을 상대방이 알아차리지 않아야 한다는 점이 핵심이다. 특히 원래 프로필에서 멀티프로필로 옮겨지는 경우에 이 상황은 더 심화가 된다고 할 수 있다.

그렇다면 유저 스토리(User Story)를 적어본다면 이런 식으로 풀 수 있을 것이다.

멀티 프로필을 사용하는 사람으로서, 기존의 프로필과 멀티 프로필의 차이점이 없게 되어 멀티 프로필을 보는 다른 사람들이 눈치를 못 채면 좋겠다.

이러한 유저 스토리의 핵심은...

멀티 프로필과 기존의 프로필이 차이가 없어야 한다.

▶ 솔루션

그렇다면 이 멀티 프로필을 사용했을 때 다른 점이 무엇인지 살펴보자. 멀티 프로필을 설정하고 들어가 보면 대부분 일반 프로필과 똑같이 기능을 한다. 선물하기, 송금 등을 할 수 있지만 한 가지 문제가 되는 것이 카카오스토리이다. 카카오스토리의 경우에는 원래 프로필과만 연동이 되고 멀티 프로필에는 연동이 되지 않는 것이다. 원래 카카오스토리가 공개가 되어 있지 않거나 혹은 사용하지 않는 경우는 상관이 없지만 만일 카카오스토리를 사용하고 있다가 멀티 프로필로 바꾸는 경우에는 사람들이 알아차릴 수 있는 단서(?)를 남기게 되는 것이다.

이런 문제를 해결하기 위해서는 여러 가지 방법이 있겠지만 3가지 방법을 소개해 보겠다.

기존의 카카오스토리를 멀티 프로필에도 연동이 되게 한다.
새로운 카카오스토리를 열 수 있도록 해준다.
기존의 카카오스토리에서 공개도를 멀티 프로필/오리지널 프로필로 나누어 준다.

1번 방법의 경우에는 서비스를 만드는 입장에서는 하나의 솔루션으로 볼 수도 있다. 왜냐하면 비교적 쉽게 구현할 수 있는 방법이기 때문이다. 하지만 이 경우에는 사용자가 멀티프로필을 만드는 의미가 없기 때문에 애초에 멀티프로필로 해결하려고 했던 고객 문제를 해결하지 못할 가능성이 크다.

2번 방법의 경우에는 그 프로필에 맞는 카카오스토리를 열 수 있게 해주는 것이다. 고객의 입장에서는 기존의 프로필과 다른 점이 없어지기 때문에 솔루션이 될 수 있고 또한 카카오측에서는 새로운 카카오스토리의 유저가 유입이 되는 것 이기 때문에 좋은 솔루션이 될 수 있을 것 같다.
하지만 이 경우에는 멀티프로필이 하나의 유저가 가지고 있는 서브개념이 아니라 멀티프로필 자체도 하나의 새로운 프로필로 만들어야 할 수도 있다. 이렇게 되면 카카오의 서비스에 하나의 유저가 정말로 멀티 아이디를 가지고 있는 것과 유사한 형태가 되어 너무 많은 DB의 소모와 함께 불필요하고 중복이 되는 데이터로 인해 서비스의 자체 운영이나 분석이 어려워질 수 있을 것이다.

궁극적으로 2번의 솔루션으로 방향이 정해지만 우선 멀티 프로필을 오리지널 프로필의 하부가 아닌 하나의 아이디로 생성하는 분리 작업이 선행이 돼야 할 것이다. 그리고 나서 카카오스토리를 그 아이디에도 붙이는 작업을 할 수 있다.

3번의 경우에는 2번보다는 아마도 들어가는 리소스가 적을 수 있다는 생각을 해본다. 2번의 경우에는 새로 개설하는 것이지만 2번의 경우에는 멀티 프로필과 오리지널 프로필을 굳이 나누지 않더라도 공개 범위만 설정을 해주면 될 것이다.

▶ 백로그 (Back log)

위의 솔루션으로 유저스토리에서 본 고객의 문제를 하기 위해서는 꽤나 많은 작업이 필요하다. 그렇기 때문에 백로그를 작성하는 것이 필요하다. 간략하게 에픽(Epic)을 통해 멀티프로필의 사용자에 대한 카테고리를 나누고 그에 따른 유저스토리 그리고 기능 구현을 위한 백로그를 작성해 보았다.

Epic	As a user	I want to	So that I can	Functional Backlog
Epic 1 멀티프로필 차이가 없게 하기	멀티프로필 사용자로서	멀티프로필과 기본 프로필의 차이가 없었으면 좋겠다	그래서 멀티프로필을 보는 사람들이 알아차리지 못하게 되었다.	1: 카카오스토리	A. 멀티프로필과 기본프로필의 아이디 분리 B. 멀티프로필과 기본프로필의 동일한 화면구성 C. 멀티프로필의 카카오스토리 공개기능 구현 D. 멀티프로필만의 카카오스토리 개설 기능
우선 순위 1 → 10, A → Z (내림차순)

이런 식으로 유저스토리에 맞춘 백로그를 구성할 수 있을 것이다. 이렇게 정리를 한 후에 로드맵을 작성하면서 DoD(Definition of Done)와 예상 시간을 정해주면 될 것이다.

생각을 마무리하며...

이번 글을 작성하면서 카카오 스토리의 연동은 이미 카카오 측에서 생각했을지도 모른다는 생각이 들었다. 하지만 2가지 정도 문제 때문에 이 기능을 구현하지 않았다고 유추를 할 수 있다. 우선 첫째는 DB구조인데 위의 솔루션 1에서 잠깐 언급했듯이 DB의 구조가 분리가 되어있지 않고 멀티프로필과 오리지널 프로필이 하나의 아이디로 연동이 되다 보니 이것을 멀티프로필의 DB로 따로 분리하여 정리하는 것이 어려울 것 같다는 생각이 든다. 이 작업의 경우 DB 자체를 고쳐야 하는 작업이기 때문에 일반의 작업보다는 오래 걸리고 DB를 분리하는 작업 후에 DB 데이터 용량이 하나로 연동이 되던 것과 다르게 용량 자체가 커질 수 있기 때문에 비용적인 측면에서도 쉽게 손을 대지 못할 수도 있다는 생각이 든다.

또한 2번째 유추해 볼 수 있는 문제는 카카오스토리의 서비스의 라이프 사이클이 그 끝에 다다랐기 때문에 다른 우선순위에 밀렸을 가능성이 있다. 어떠한 제품도 영원할 수는 없다. 카카오스토리는 처음에는 많은 사용자를 유치했지만 점점 다른 여러 서비스에 밀려 그 빛을 잃어가고 있는 상황이다. 그렇기 때문에 새롭게 구현하는 멀티프로필의 구현과 기본 프로필에서 있는 중요 기능들(송금, 선물하기, 전화 등)이 더 중요하다고 판단을 했을 것이다.

하지만 앞서 유저스토리를 통해 알아보았듯이 서비스를 사용하는 고객의 입장에서는 이러한 세심함이 필요할지도 모른다.

나는 예전에 워터폴 형식의 개발을 경험을 해 보았기 때문에 이 방식이 얼마나 효율적인가에 대하여 생각해보자고 하면 물음표를 떠올린다. 물론 이미 잘 구현되어있는 기능이나 혹은 마이너 개선점을 구현하기 위해서는 워터폴 방식이 오히려 애자일한 것보다는 속도나 효율면에서 맞다고 생각한다.
하지만 워터폴에서는 탑다운(Top-Down) 구조로 인해, 대화보다는 명령과 수행으로 업무를 진행하다 보니 팀원이나 팀 간의 오해가 생길 수 있게 된다. 경험 상 아무리 워터폴에서 커뮤니케이션을 강조를 하여도 회의가 산으로 가거나 처리가 되어야 할 일들이 되지 않는 경우들이 많이 있었다.

나는 아직 애자일하게 움직이는 조직을 경험하지 못했지만 이러한 워터폴의 문제를 보완하고 빠른 제품의 구현을 위해서 애자일 방식이 유용할 것 같다는 생각이 든다.

제가 공부하고, 이해해본 PM에 관련된 내용을 포스팅으로 남깁니다.
잘못된 생각이나 혹은, 이견, 참고자료 등은 댓글로 남겨주세요.
감사합니다