첫 프로젝트 회고
눈물의 프로젝트 회고
세상의 모든 일은 사람과 사람이 만나서 이루어진다. 우리는 일하면서 배우고, 사람으로부터 배우고, 공부하면서도 사람을 사귀고, 함께 일하다가 또 친구가 되어 관계도 숙성해간다.
황선우, <사랑한다고 말할 용기>
이번 회고글의 시작은 개인적으로 애정해 마지 않는 황선우 작가의 에세이 <사랑한다고 말할 용기> 속의 한 구절을 인용하는 것으로 시작해 보고 싶다. 참고로 저 에세이의 원제는 사실 (일을) 사랑한다고 말할 용기라는 소문이 자자하다. 인용한 글을 보면 알 수 있듯, 일에는 기쁨과 슬픔 그리고 단짠이 공존한다. 이 감상이 지나가기 전에 눈물의 회고는 꼭 생생히 남겨야겠기에 서둘러 브런치를 켰다.
온보딩 회고 쓴 지 한 달도 안 지났는데(...)
발단
PO로 처음 진행하게 된 프로젝트는 [로드맵 페이지의 카드뷰 개선]이었다. 인프런은 유저가 자신의 수준과 커리어패스에 맞는 효과적인 학습을 할 수 있도록 다양한 강의를 로드맵의 형태로 제공하고 있다. 로드맵은 강의의 묶음 결제를 통해 할인 혜택을 받고 싶거나, 수준별/스킬별로 자신에게 필요한 학습을 하고 싶은 유저들이 주 이용 고객인데(소위 말해 뭐부터 들어야할 지 모르거나, 듣고 싶은 강의가 확실한 사람) 이번 프로젝트의 목표는 유저 개인의 수준과 커리어패스에 맞는 로드맵을 탐색하기 쉽도록 개선하는 일이었다.
다만 해당 시점에는 신규 채용 서비스 '랠릿'의 런칭을 앞두고 있었고, 기존 서비스의 유지보수까지 정신없이 돌아가고 있었던 상황이었기에 넉넉한 리소스를 가용하기는 어려웠다. 모든 일에는 우선순위가 있듯, 이 프로젝트 역시 그러했고 최대한 현재의 데이터 구조와 디자인 변경 없이 목표하는 지표를 상승시키는 것이 중요했다. 어찌보면 확실한 제약 사항이 처음부터 주어졌기에 한편으로는 마음이 놓였지만, 그렇다고 해서 현재의 상황이나 제약을 핑계로 '이 정도면 됐다!'라고 말하고 싶지는 않았다.
전개
로드맵 카드 영역의 CTR을 높이고, 궁극적으로 목표하는 Output metrics 를 개선하기 위해서는 유저들이 왜 로드맵에 흥미를 느끼는지 알아야했다. 로드맵을 수강하는, 수강할 사람들이 가장 먼저 확인하는 정보는 뭘까? 너무나 당연하게도 이 강의를 누가 가르치느냐이다. 아무래도 지식 콘텐츠이다보니 그 지식을 전달하는 이가 누구냐에 귀추가 쏠릴 수밖에 없다. (실제 수강 데이터를 봐도 그렇다.)
또, 현재 카드뷰의 레이아웃 상 로드맵의 썸네일이 주는 인상이 지배적일 수밖에 없다.
하지만 인프런은 잘 나가는 스타강사가 있다고 해서, 그 스타강사만 띄워준다는 기조의 서비스는 아니었다. 지식공유자들의 콘텐츠가 최대한 다양하고 공평하게 노출될 수 있도록 노력하는 내부적 방향이 있었다. 같은 점에서 강의 썸네일이나 로드맵의 카드 이미지 역시 너무 튀거나 주의를 끄는 이미지를 사용하는 것은 지양하고 있다.
그렇다면 그 외에는 또 뭐가 있을까? 로드맵의 핵심은 '수준과 스킬에 맞는 효과적인 학습'이다. 즉, 자신의 수준에 맞는 로드맵을 수강함으로서 어떤 스킬을 얻어갈 수 있느냐가 관건일 것이라 예상했다. 난이도와 토픽이 다른 여러 개의 강의가 합쳐진 형태이기 때문에, 로드맵 탐색 페이지에서는 최소한 그 두 포인트에 초점을 맞춰 쉽게 확인할 수 있어야했다.
(데이터로 확인할 수 있는 문제 상황은 본문에서 생략)
러프하게 가설을 세워보면 이렇다.
Situation : 유저가 로드맵 페이지에서 로드맵을 탐색할 때,
Motivation : 스스로의 관심 지식과 수준에 맞는 구성인지 확인할 수 있다면,
Expected Outcome : 로드맵 페이지에서 (/특정 지표/)들이 상승할 것이다.
위기
스킬태그는 이미 강의마다 포함되어 있으니, 노출 조건만 정립한다면 해결될 부분이었다. 그렇다면 수준(난이도)는 어떻게 정의하면 좋을까? 어려웠다. 로드맵 기능의 정체성과 자유도를 고려하면 단순히 '난이도'를 노출하는 방향이 정답이 아닐 수 있었다. 프로젝트 초기에는, 최대한 어려운 작업 없이 목표한 지표를 상승시키는 것이었기 때문에 기존 UX를 유지하되 카드 자체의 시인성을 개선하는 것에 집중하고자 했었다.
하지만 작업이 진행될 수록 Input metrics만 높이는 것에 매몰되는 듯한 기분이 들었다. 궁극적으로 개선하려던 문제가 뭐였지? 또, 별개로 볼 수도 있으나 특정 기준의 소팅 기능 없이 리스트만 쭉 나열해 준다면 유저가 로드맵을 일일이 탐색해야 한다는 문제가 있다는 점을 간과하기도 어려웠다. 로드맵 수는 점진적으로 증가하고 있고, 현재만 해도 200개가 넘는 상태인데 유저는 아직까지도 카드뷰 상의 타이틀만 보고 수준을 판단해야했다. 그런 고민을 PO파트 회고 시간에 털어놓았는데, 다른 PO분으로부터 한 가지 조언을 들을 수 있었다.
'그 기능을 반영함으로서 상승할 보조 지표는 뭐가 있을까요? 궁극적으로 개선하고자 하는 지표에 기여할 수 있는 보조 지표로 설득할 수 있다면 해봐도 좋을 것 같아요.'
개발 공수와 요구사항으로 확인했던 Input metrics를 최우선시한 나머지, 참고할 수 있는 보조 지표들을 활용해 설득하는 방안을 잊고 있었던 것이다. 설득의 논거가 충분하다면 굳이 안 해볼 이유는 없었다. 초기 기획 당시에 아이데이션에만 그치지 말고, 해야할 이유를 더 찾아보고 설득했더라면 중간에 개발 범주가 늘어날 이유는 없었을 텐데. 애초에 기능의 확장성을 고려하면 그렇게나 쉽게 포기할 수 없었을 텐데. 개인적으로 많이 아쉽고 속상했다. 그렇게 초기 기획에서 확장한 소팅 기능까지 디벨롭하게 됐고, 대신 크게 리소스가 들지 않는 방향으로 작업은 진행되었다. 디자인적으로는 기존에 있는 컴포넌트를 활용했고, 개발 역시 부하는 고려해야 했지만 산정한 일정에 큰 영향을 끼칠 정도는 아니었다.
절정
물론 모든 문제가 그렇듯, 언덕을 하나 넘으면 다음 언덕이 나왔다.
1) 하나의 로드맵은 다양한 난이도의 강의로 구성되고,
2) 그 구성의 자유도가 높으며,
3) 발행된 로드맵이라 하더라도 지식공유자에 의해 언제든 추가, 수정될 수 있었다.
유저가 애초에 로드맵의 시작부터 막히는 문제를 겪으면 안 되니, 위의 조건을 모두 감안할 수 있는 범위인 로드맵의 '시작 레벨'로 수준을 정의했다.
시작 레벨은 크게 입문, 초급, 중급으로 구분되는데 이 워딩에 대해서도 고민이 많았다. 로드맵 운영과 가장 밀접하게 연관된 콘텐츠 파트에서는 난이도의 기준을 유저는 인지하기 어려울 수 있으니, 아예 시청 타겟으로 구분해 보자는 의견을 주셨다.' (e.g. 주니어 / 시니어) 물론 내부적으로 정립되어있는 난이도의 기준은 있지만 유저는 이를 판단하기 어려울 수 있으니 다른 표현을 고민해볼 필요성이 있었다.
다만 개인적으로 우려스러웠던 점은, 어떠한 워딩을 사용하여 수준을 구분하건 그 기준치에 대해 유저가 이해하는 정도는 저마다 다를 것이며, 로드맵 상에 포함된 강의에서 노출되는 난이도와 사용한 워딩의 이해가 일치되지 않는다면 더 큰 혼란이 생길 수도 있다는 점이었다. 이건 위트 있는 워딩을 떠올리지 못해서 하는 변명이 아니다. 정말이다(..) 그렇게 워딩은 다른 페이지들에서 활용하고 있는 방식 그대로 노출하기로 했다.
반면, 스킬태그는 사실상 이미 강의마다 각자 고유한 값을 보유하고 있기 때문에, 어떻게 보여질 것인가에 대한 조건만 정리되면 카드뷰 상에 노출시키는 것은 크게 구현하기 힘든 범위는 아니었다. 무엇을, 왜 구현해야 하는가에 대해서 정리가 되어도 사실상 어떻게(How to)가 빠지면 소용이 없는 경우가 많다. 이 단계에서 현실적이면서 빠르게 구상할 수 있도록 친절하고 명확한 도움을 준 백엔드 개발자분들께 아직까지도 감사한 마음이 크다.
인프런은 신규 프로젝트를 진행할 때마다 새로운 슬랙 채널을 만들어 그 안에서 소통을 하고 있다. (히스토리와 신속한 내용 공유를 위해 DM으로만 소통하는 것을 지양하고 있다.) 디자인 시안이 최종 픽스 되고, 개발이 진행되고 있는 상황에서도 계속해서 부차적인 이슈가 발생했다. 디바이스마다 차이가 발생될 수 있는 해상도 관련 이슈부터 시작해서 그 외 개발 걱정점들까지. 과정에서 크고 작은 의사결정이 있었고, 함께 프로젝트를 진행해준 UX/UI 디자이너분과 프론트 개발자분의 도움 덕분에 무사히 고비를 넘길 수 있었다.
회고(결말)
이번 프로젝트를 진행하며 개인적으로 주요하게 아쉬웠던 점은 '빠릿빠릿하게 조율하지 못한 것'이었다. 초기 기획에서 변경되었거나, 기획서에 있더라도 리마인드 되어야 할 중요 내용은 디자인 문서에도 업데이트를 해두어야 소통 오류를 줄일 수 있다. 누구나 아는 내용이지만 간과하기 쉬운 부분이라 생각된다. 공동 편집이 가능한 툴의 이점을 포기하지 말자.
또 하나 아쉬웠던 점은 엣지 케이스에 대해 미리 산정하지 못한 것인데, 한다고 했음에도 놓친 부분들이 더러 있어 아쉬웠다. 덧붙여 같이 개선되면 좋을 점으로는 디테일이 있겠다. 수정, 변경될 요소가 제아무리 작은 것이라도 1) 유저의 UX를 고려하되 2)실험 지표에도 최소한 부정적 영향을 끼치지는 않을 방향으로 준비 되어야한다. 그 과정에서 근거 없는 뇌피셜이 끼어들 자리는 없는데, 질문이 들어왔을 때 부끄럽게도 직감에만 의존해 답변을 한 적이 있었다. 지금 생각해봐도 설득력이라고는 없는 대답이었다. (아직 논리가 준비되지 않았으면 조금 더 생각해 보겠다고 하면 되는 거였는데.)
마지막으로는 관련 기능과 밀접한 연관이 있는 팀과 더 많은 이야기를 나누지 못한 점이었다. 물론 착수 단계에서 의견을 구하고 듣기는 했으나, 충분하지는 못했던 것 같다는 아쉬움이 스쳤다. 개발 단계에서도 유연한 소통이 있었으면 어땠을까, 아니면 QA를 같이 진행할 수도 있었는데 그 점까지 생각이 닿지 않았던 점이 아쉬웠다. 비슷한 측면에서 좋았던 점들을 돌이켜보면 일을 진행하면서 로드맵과 관련된 기술 부채나 각 파트에서 가지고 있는 니즈, 궁금증에 대해서도 파악할 수 있는 기회가 되어 좋기도 했다. (이렇게 데이터로 디깅해 보면 좋을 연관 토픽들이 쌓여만 간다.)
그 외에도 개인적으로, 스스로에게 아쉬웠던 지점들이 몇 가지가 있지만 경험을 쌓아가며 메꿔나갈 수밖에 없는 부분이라 생각되어 포스트잇에 써두고 계속 읽으려한다. 이 글이 발행된 오전에 해당 페이지의 개선 버전이 실서버에 배포되었고 남은 건 결과를 지켜보는 일 뿐이다. 별다른 문제가 없길 바라며 조마조마한 마음으로 글을 줄인다.
