brunch

라이킷 33 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김효진 Dec 31. 2022

내가 성장하고 있음을

3년 차 프로덕트 디자이너의 회고

이직한 지 1년, 올해는 서비스 출시로 정말 바쁜 나날들을 보냈다.

이전에도 두 번의 서비스 출시 경험이 있었지만, 이직 후 경험한 이번 출시 과정은 나의 부족한 부분을 수면 위로 떠오르게 하였다. 그도 그럴 것이 이전 직장에서는 관공서와 연계된 수동적인 프로젝트에 참여하였지만, 현 직장에서는 실제 사용자를 대상으로 자발적인 아이데이션을 이끌어 내야 하는 차이가 있었다. 하지만, 오히려 좋다. 나의 부족한 부분이 무엇인지 발견하고, 채워나갈 수 있는 기회가 주어진 거라 생각한다.

여기서 잠시, 제가 참여한 프로젝트가 이번에 정식 출시를 맞춰 서비스에 대한 소개를 잠시 하려고 합니다!

오프오프(offoff)는 새로운 취미 모임이 필요할 때, 나와 공통 관심사를 가지고 있는 친구를 찾고 싶을 때, 언제, 어디서, 무엇이든 내 취향대로 오프 라이프를 시작해볼 수 있는 모임 서비스입니다.

Google Play, App Store

앱을 사용하면서 코멘트, 버그를 발견하셨다면, 아래 링크를 통해 보내주세요. 소중한 의견 놓치지 않겠습니다!

소리함

회고를 시작하기에 앞서 이전 글(이직을 위한 나만의 기준과 포트폴리오, 브런치를 하게 된 계기, 면접에 관한 내용이 담겨 있다.)에서 그 당시 세운 기준에 얼만큼 부합했는지 답을 달아보려고 한다.

∙ 내가 관심을 가지고, 재미있게 일할 수 있는 곳인가? - YES

헬스케어, 게임, 환전 솔루션, 육아, 소셜 마켓, 반려동물, 메디컬 서비스 등 다양한 범주 속, 내가 평소에 관심을 가지고 있는 분야, 내가 경험해본 분야는 무엇이 있는지 생각해 보았다. 이전 직장에서 스타트업 대표와의 1:1 식사 매칭 프로젝트에 참여하였다. 사람과 사람을 공통된 관심사로 이어주는 연결다리 역할을 할 수 있어 다른 프로젝트 대비 만족도가 높았으며, 이를 바탕으로 더 큰 규모의 프로젝트에 참여해보고 싶었다.

회사를 다니면서 '재미'있게 일을 할 수 있을까? 여기서 '재미'가 내포하고 있는 것은 무엇일까?

월급 받은 만큼 적당히 일하고 24시간 중 8시간을 조용히 보내다 시간에 맞춰 퇴근하는 반복적인 하루는 보내고 싶지 않았다. 이런 기능, 프로젝트, 이벤트가 아직 없다면 먼저 제안하고, 팀원분들과 의견을 주고받으면서 설득하기도 하고, 때론 다양한 분야의 인원이 있는 만큼 각자의 관점에서 내는 의견을 토대로 제안한 프로젝트를 발전시키기도 하는 다양한 경험을 해 보고 싶었다. 물론 나의 제안이 받아들여지지 않을 수도 있다. 그러나 이 과정에서 누군가를 설득하고, 논의하는 과정 또한 나에게 큰 자산으로 남지 않을까 싶다. 그래서 나는 면접을 중요하게 생각한다. 단순 평가받는 자리가 아닌 팀원분들과 의견을 주고받고, 현장의 느낌을 러프하게나마 느껴 볼 수 있는 자리이기 때문이다. 이직을 위한 면접에서 프로젝트를 통한 경험을 풀어가고 있었는데 "음.. 근데", "잠시만요" 이야기의 끝맺음이 제대로 이뤄지지 않은 채 다음 이야기로 넘어가는 곳이 있는가 하면, 과제 리뷰를 통해 오히려 더 발전된 무언가를 발견하고, 여기에 입사해서 제대로 의견을 주고받으며 문제해결을 하는데 동참하고 싶다고 느끼게 하는 곳이 있었다.

∙ 사용자의 피드백 반영과 성과지표 등 시각적으로 다양한 내용을 담을 수 있는 곳인가? - NOT YET

12월 29일 정식 출시 이후 voc가 쌓이고 있는 중이다. 다음 회고 때 다시 되짚어보려고 한다.

∙ 좋은 PdM(Product Manager)이 있는가? - NOT YET

내가 생각하는 좋은 PDM은 실제로 그 일(디자인, 개발, 마케팅 등)을 하지는 않지만 각기 다른 스킬셋을 가진 사람들이 하나의 목표를 위해 다 같이 일을 할 때, 의견을 조율해 주고, 방향성을 제시해주는 역할을 할 수 있는 사람이라고 생각한다. 또한, 제품의 탄생부터 발전, 소멸까지의 과정 속에서 사용성, 기업의 기술 스택, 사업성 측면에서 항상 고민하고 피드백 줄 수 있는 PDM과 함께 일하고 싶었다.

NO라고 답하지 않은 이유는 PDM 채용 계획이 있기 때문이다.

∙ 연봉은 직전에 받는 금액보다 높여 줄 수 있는가? - YES

연봉은 나의 가치를 입증하는 것들 중 하나이다. 이직을 준비하면서 느낀 건 첫 직장이 중요하다는 것이다. 연봉 협상의 기준이 되는 건 직전 연봉이다. 시작점이 낮다면 같은 금액을 올리더라도 납득시키기 쉽지 않을 것이다.

가끔 디자이너 단톡에 '졸업 후 경력 없는 신입인데, 최저를 받으며 배우는 마음으로 시작하는 게 맞는 걸까요.'라는 질문이 올라올 때가 있는데 난 '아니요'를 외친다. '신입=최저'라는 법칙은 그 어디에도 없기 때문이다. 생각해보면 나도 졸업 후 같은 생각을 할 때가 있었지만 선배의 조언이 아직도 생각난다.(..감사합니다..!) 나는 프로덕트 디자이너로 직무를 정한 이상 실무와 비슷한 경험을 포트폴리오에 녹여내는 것에 초점을 두었다. 학기 때 서비스 디자인 연구소, 학생 연구원으로 일하며 배운 내용, 퍼블리싱 공부하면 참여한 사이드 프로젝트에서 어떤 결과물을 도출했고 과정은 어떠했는지 이력서와 포트폴리오의 몸집을 부풀려나갔다.

이직을 위한 조용하지만 치밀한 작전

2년 차 프로덕트 디자이너 | 어떤 직군에 종사하건, 이직은 조심스럽기만 하다. 퇴사 후 바로 이직에 성공한다면 너무 좋겠지만, 계획했던 기간보다 길어질 수도 있고, 생각지 못한 변수를 만날

brunch.co.kr/@hyoi0303/72

회고는 왜 해야 할까?

쉼 없이 앞만 보고 달려가는 무한루프 속에서 한 번 끊고 다시 이어가는 과정은 꼭 필요하다. 더욱이 올해는 서비스 출시로 정신없는 나날을 보냈기 때문에 회고의 시간이 필요했다.

회사에서 2주 단위로 Sprint retrospection을 진행하고 있기 때문에, 이번엔 오롯이 나에 맞춰진 회고를 진행하기로 하였다. 다른 점이 있다면, 좀 더 솔직하고, 쓴소리를 할 수 있지 않을까 싶다. 주기는 회사에서 진행하는 것만큼 자주 잡지는 않았다. 그렇다고 이 주기가 맞다는 확신은 아직 없다. 하지만, 잦은 회고로 인한 스트레스는 오히려 자책과 위축이 되기 마련이며, 회고의 목적은 추진력을 얻기 위함이라는 점을 잊어서는 안 된다.

이번 회고의 목차는 내가 목표하는 것이 무엇이었는지 다시 짚어보고, 내가 한 일들이 목표와 부합하는지 확인하며, 잘한 점과 부족한 점을 객관적으로 바라본다. 그리고 나의 부족한 점을 개선하기 위해 무엇을 해야 하는지 찾아본다. 끝으로 앞으로 어떤 일을 해야 목표에 달성할 것인지 수행 여부를 확인한다. 나는 프로젝트를 시작하기에 앞서 작은 목표라도 세워놓고 움직이는 편이다. 이직 후 세운 목표는 '성공적인 서비스 출시와 작년보다는 성장했다는 것을 증명하는 것'이었다.

1. What did I do

∙ 서비스 기획 참여

∙ 서비스 화면 설계

제품의 전반적인 설계와 디자인을 진행하면서 프로덕트 디자이너는, 팀 내에서 가장 깊은 현장 이해도를 바탕으로 업무의 뼈대를 만들어야 하기 때문에, 실시간으로 업데이트되고 있는 이슈 사항에 대하여 빠르게 흡수하고 적용시켜야 한다는 것을 느끼게 하였다. 예를 들어, 상대방과 매칭된 상태에서 신고(내가 상대방을, 상대방이 나를), 제재(관리자가 제재한 경우 내 입장, 상대방 입장), 삭제(관리자가 삭제한 경우 내 입장, 상대방 입장), 매칭 해제(내가 or 상대방), 탈퇴(내가 or 상대방) 하였을 때, 각자의 입장에서 어떤 모습일지 상상하고, 빠르게 프로토타이핑 하여 적용시켰다. 복잡한 서비스일수록 Flow chart(플로우 차트: 프로세스 수행에 필요한 일련의 단계와 결과를 시각적으로 표현한 것)는 굵직한 기능을 한눈에 보고 싶으며 이를 통하여 세부항목을 구축해나가고 싶을 때, 신규 입사자에게는 온보딩스크린으로 도움이 많이 되었다. 사용자 여정의 각 터치 포인트를 노드로 표시하기 때문에 너무 많은 세부 항목까지 포함시킨다면 사용자의 전체 경험을 한눈에 확인할 수 있다는 장점을 살리지 못할 것 같아 굵직한 기능 위주로 배치시켰다.

∙ 프로덕트 디자인

∙ 디자인 시스템 구축

디자인 시스템은 팀이 제품을 설계, 실현 및 개발할 수 있는 모든 요소를 그룹화하는 단일 소스이다. 따라서, 디자인 시스템은 단순 결과물이 아니라 결과물의 집합이며, 제품 및 기술이 발전함에 따라 지속적으로 업데이트될 것이다. 이전에 디자인 시스템에 관한 글을 발행한 적이 있는데, 그때 와는 프로젝트의 규모와 환경이 달라졌기 때문에 보다 양질의 글을 발행해 보려고 한다. (브런치에 소리친 이상 지.. 지켜야 한다..!)

∙ 디자인 QA, 사용성 테스트

QA는 Quality Assurance의 약자로 ‘품질 보증’ 이란 뜻을 가지고 있으며, 서비스의 기능을 검증하고 관리하는 활동을 한다. 여기서 단순히 버그를 찾거나 서비스의 기능만을 테스트하는 것이 아닌, 프로젝트의 시작부터 최종 도착지점까지 모든 과정에 참여하여 각 단계벌로 직접 테스트해보며 우리가 세운 프로젝트의 방향성과도 부합하는지 검증해야 한다. QA 업무를 단순 반복적인 업무라고 볼 수 없는 이유가 이 때문이다.

이번 QA는 개발이 완료된 상태에서 팀 전체가 참여했으며, 테스트 기간은 대략 3주를(실제로는 한 달 정도 걸린 것 같다.) 잡고 크런치 모드일 때 진행되었다. 프로덕트 전체를 테스트 범위로 잡고 QA 시트에 대략 600여 개의 확인 내용이 작성되었으며, Android(S22, Z Flip 3, Note 10), iOS(SE2, 11, 13, 13 pro, 14 pro)를 배분받아 테스트 계정에서 QA를 시작하였다.

QA 시트

QA 시트 예시

QA 시트를 작성해야 하는 이유는 이 과정에서 고려되지 않았던 부분을 발견할 수도 있고, 팀 구성워들에게 확인 내용의 타당성을 점검하고 혹시 모를 오해를 방지하고자 함이 있다.

버그 리포트

본격적인 QA가 시작됨에 따라 발견된 이슈들 중 우선순위가 높은 사항은 지라에 티켓을 만들었다. 지라 티켓에는 다음 내용들이 포함된다.

버그 제목

발생 환경(os 버전, 디바이스 정보)

이슈 설명

실제 결과

담당

우선순위

첨부파일(재현 영상, 캡처 이미지)

번외) 사수가 없는 디자이너에 대하여

현재, 초기 스타트업으로 시니어 없이 일하고 있다.

'사수를 통해 얻고자 하는 것은 무엇일까? 사수가 없으면 왜 힘들까?'를 생각해 봤을 때, 사수의 디자인 피드백을 받고 싶고, 사용자를 위한 디자인을 함께 고민해줄 사람이 필요했다.

그렇다면, 내부에서 이런 나의 고민을 해결해줄 수 있는 포지션이 있는가?

CPO나 COO(제품 총괄)에게 현재 나의 고민과 방향성을 공유하는 것도 하나의 방법이 될 수 있다고 생각한다. 대화를 하다 보면 불현듯 연결 지어줄 수 있는 관련 직군이 떠오르거나 자신의 경험을 공유해줄 것이다. 'CPO나 COO는 어려워서, 먼저 나서서 이야기하기 어색해서' 이런저런 의미를 부여하기에는 시간은 흘러가고 있다. 그런데 이 두 가지를 해결해 줄 사람이 회사에 없다면 외부에서 찾아보는 것도 좋은 방법이 될 수 있다. 디자이너 단톡, 모임, 컨퍼런스를 통해 이어진 인연이나 다른 회사에 메일을 통해 티타임을 가져볼 수도 있다.

우린 표면적인 모습만 보고 사수가 있기를 희망하지만, 실질적으로 내가 먼저 움직여 책이나 컨퍼런스 참여, 스터디를 통해 습득한 내용을 실무에 대입해 봤을 때, 막히는 부분이나 의논하고 싶은 부분이 생겼다면 그때 도움을 받을 수는 있겠지만, 막연히 사수가 있다는 것에 의미를 두지는 않았으면 한다.

가끔 '이제 막 취업을 하였는데 사수가 없는 디자이너로 어디서부터 시작하면 좋을지 막막하다'는 글을 볼 때가 있는데, 물론 이게 정답이 될 수는 없지만, 앱스토어에서 산업군에 속한 모든 앱을 다운로드하는 것을 추천한다. 직접 사용해보면서 각 앱마다 장단점을 정리해 흡수하는 과정을 거치고, 새로운 기능, 이벤트가 업데이트될 때마다 이런 기능을 왜 넣었을까, UX 적으로 어떤 점이 좋은걸 까에 대해 생각해 본다. 사수가 없더라도 앞선 단계에 있는 회사들의 프로젝트만 봐도 어떤 방향성을 가지고 가야 할지 사수의 역할을 조금이라도 대신할 수 있다고 생각한다.

2. What went well

∙ 피드백에 대한 두려움

신입 때는 내 디자인이 완벽하지 않은 것 같아서, 피드백받기 애매한 것 같아서, 부정적인 피드백을 받고 싶지 않아서 최종 결과물이 나올 때까지 숨기다 짜잔 하고 완성된 결과물을 공유하곤 하였다. 문제는 기획적인 부분과 맞지 않아서, 서비스의 분위기와 맞지 않아 처음부터 다시 해야 하는 일이 발생하곤 하였다. 너무나도 비효율적인 작업 방식을 고수하고 있었으며, 모두에게 피해를 주고 있었다. 변화가 필요했다. 이를 위해 피드백에 대한 두려움을 과감하게 내려놓았다. 나의 작업물을 모두에게 공유하고 피드백을 받으며 다음 스텝을 밟아가는 이터레이션을 유지하고 있다. 오히려 이전보다 작업 속도나 불필요한 충돌이 줄어들었다.

피드백을 받다 보면 의견이 상충되는 경우가 발생하곤 한다. 여기서 중요한 건 두 의견이 모두 유저를 위한 관점일 수 있다는 것이다. 상대방 직군의 관점에서는 이런 생각을 했기 때문에 이런 설루션을 내릴 수 있겠다는 것을 참고하여 생각해봐야 한다. 그렇다고 모두의 의견을 수렴하자는 의미는 아니다. 스스로 생각하고 정의를 내릴 수 있는 힘을 길러야 한다는 의미이다.

∙ 메모하는 습관

사람의 기억력에는 한계가 있다. 하나의 반복적인 작업을 이어가지 않는 이상, 동일한 문제에 다시 마주쳤을 때 이전과 같은 고민을 하게 될 가능성은 매우 높다.

나는 아이폰의 빠른 메모 러버다. 위젯으로 설정해 놓을 수도 있어, 떠오르는 아이디어, 기억이 가물가물한 단어, 디자인 팁 등 모든 내용을 바로 정리할 수 있다. 분기별로 회고할 겸 노션에도 옮겨 놓기는 하지만 자주 손이 가는 건 역시 메모장이다. 타고 타고 들어가야 한다는 게 귀찮탈까..

경험사전 : 경험사전은 다른 분들도 꼭 작성했으면 하는 나의 추천 사전이다. 제품을 디자인하며 발견한 문제에 대해 이게 진짜 문제인지를 분석해보고 맞다는 판단이 내려진다면, 기획 의도를 되새겨본다. 함정이 있다면 기록한다. 그리고 해결방법에 대해 혼자 고민도 해보고(사용자의 입장에서 상상해 보는 것), 팀원과 의견을 주고받으면서 얻은 인사이트를 기록한다. 그리고 PM, COO와 몇 가지 시안을 통해 최종 변경될 디자인을 확정 짓는다. 이때 내 디자인에 담긴 의도, 디벨롭 과정을 기록하다. 이후 변경된 디자인에 대한 데이터를 다시 수집하며 최종 해결 여부를 PM, COO와 판단한다. 이 모든 과정을 기록한다.

voc : 출시 이후 쌓이고 있는 voc는 처음 겪는 나에게 충격으로 다가왔다. 사용자는 생각보다 냉철했고, 조금의 불편함에도 뒤돌아섰다. 물론 모든 사용자보이스를 수렴할 필요는 없지만 이건 모두가 이야기해보면 좋을 것 같은데라는 의견은 기록한다.

단어장 : 느낌적으로 알고 있는데 정확한 정의를 물어본다면 대답하지 못하는 단어를 기록한다.

아이데이션 미팅 : 미팅을 통해 공감한 내용, 추가적으로 생각해 보고 싶은 내용을 기록한다.

책 : 일련의 독후감 형식으로 기록한다.

전문 : 강의가 너무 인상 깊었는데 길지 않다면 전체를 텍스트로 옮기는 작업을 한다. 한 번 더 곱씹어 보고 싶기도 하고, 이 과정에서 이전에는 들리지 않았던 내용을 발견할 수 도 있다.

디자인 팁 : 이곳저곳에서 줍줍 한 디자인 팁을 기록한다.

브런치 : 글을 쓰다 보면 불현듯 글감이 떠올라 작성하기는 했는데 다시 읽어보니 글의 컨셉과 맞지 않아 삭제하려고 했을 때 아깝다고 느낀 문장, 단어를 기록한다.

면접질문 : 기본적인 면접질문 이외에도 실무에서 내가 면접관이라면 이런 질문을 해볼 수 있지 않을까 하는 내용을 기록한다.

몇 가지 파일을 추려보았다. 각자의 메모 형태는 다르겠지만 습관화하는 게 제일 중요할 것 같다.

∙ 일단 따라 해 보자

비핸스, 핀터레스트, 전시, 강의 다양한 경험에서 찾아낸 레퍼런스를 좋다!로 끝내는 게 아니라 좋군, 따라 해 봐야지! 를 실천 중이다. 저장만 해 놓기에는 나중에는 내가 저장했다는 사실을 잊은 채 똑같은 레퍼런스를 반복해서 저장하기 때문이다.

3. What didn’t go well

∙ 데이터와 실험

서비스 출시는 끝이 아닌 시작에 가깝다.

출시 후 서비스에 대한 사용자의 voc를 듣고, 사용 패턴을 분석하고, 새로운 기능을 추가함으로써 서비스를 꾸준히 개선해야 한다. 이전 출시 경험이 있지만, 전체 라이프 스팬 중 50%만을 경험하였기 때문에 데이터를 기반으로 무엇이 문제인지를 발견하고, 집요하게 개선해 나가려는 스킬은 부족한 상태이다.

그렇다면, 디자이너가 데이터 분석 능력이 필요한 이유는 무엇일까.

데이터는 디자인 산출물에 대한 강력한 근거를 제공하고 타 조직과 원활한 의사소통을 돕는 공용어 역할을 한다. 사실 산출물이나 업무에 대한 근거 확보는 디자이너만의 영역이 아니다. 디자이너는 물론 마케터와 기획자, 개발자가 모든 직무에서 자신의 의견을 구성원과 공유하고 행동으로 끌어내기 위해서는 반드시 근거 자료가 필요하다. 만약 자신이 누군가를 설득시켜야 하는 입장이라면, 데이터는 매우 효과적인 근거 자료가 될 수 있다. 또한, 단순히 심미적 가치의 디자인을 넘어 '고객의 불편함을 알고 그들을 위해 더 나은 서비스와 제품을 만드는 일'이다. 하지만 다양한 조직 구성원에게 자신의 디자인을 이야기하는 것은 절대 쉽지 않다. 이때 데이터는 다양한 조직 구성원이 쉽게 대화를 나눌 수 있는 핵심 공용어가 된다. 사실에 근거한 정보를 의미하고, 누구나 이해하고 쉽게 공감할 수 있기 때문이다.

디자이너는 최고의 디자인을 위해 긴 시간 고민하기보다 최적의 디자인을 위해 '가설 검증 자료'로서의 디자인에 중점을 두어야 한다. 동시에 사용자 데이터의 해석을 통해 논리적인 방향성과 사용자의 행동을 끌어내는 디자인이 무엇인지에 대한 집중적인 탐구가 필요하다. -『Data-Driven UX』포그리트, 2019

∙ why를 던질 수 있는 사람

당신에게 의미 있는 것을 찾는 강력한 방법은 스스로에게 ‘왜’라는 질문을 해보는 것이다. 우리 자신과 우리를 이끄는 힘에 대해 더 잘 이해할수록, 단순히 재정 목표만을 만족시키는 것이 아닌 옳은 결정을 한결 수월하게 할 수 있다. - 에밀리 와프닉『모든 것이 되는 법』웅진지식하우스, 2017

4. How to Improve

∙ 심리학 공부 그리고 데이터 공부

데이터 공부에 앞서 데이터를 생성해내는 주체인 인간에 대한 이해를 하는 게 우선시되어야 한다고 생각했다.

인간은 '자유의지'를 갖고 있으면서도 왜, 비슷한 브랜드에 열광하고, 인기 있는 같은 종류의 음악을 듣고, 특정 습관과 행동 양식에 스며들려고 할까, 책에서 설명하길 인간의 생각과 행동은 그리 합리적이지 않으며, 다분히 편의적이고, 즉흥적이며, 충동적이라고 한다. 이와 연결 지어볼 수 있는 현상이 다수의 선택이 옳은 것이라고 착각하게 되는 군중심리이자, 혼자라는 불안감 때문에 맹목적으로 다수의 길을 선택하는 오류이다. 군중이 되면 개개인의 이성적 사고는 사라지고 집단화된 무의식에 지배당하게 되며, 선동에 의한 집단최면에 걸리기 쉽다.

생각이나 마음은 약 1,000억 개의 신경소자와 1,000조 개의 시냅스(synapse)로 구성되어 있는 뇌의 활동의 산물로 인간의 심리는 복잡하면서도 단순하다. 이런 복잡 미묘함을 우린 이해하고 싶어 한다.

인간의 행동 뒤에 얼마나 많은 의도와 진실이 담겨있는지 우리는 때로 인지하지 못한 채 그러한 행동을 반복하며 막연하게 무의식이 만들어낸 행동이라고 생각한다. 하지만 사실 이러한 현상들 속에도 숨어있는 진실이 있다. 인간의 보이지 않는 속마음은 측정할 수 없지만, 집단을 만들면 몇 가지 패턴으로 수렴될 수 있다고 한다. 그래서 행동으로 인간의 심리를 추측하기도 한다.

심리학의 매력은 마음이라 표현하는 볼 수도, 만질 수도 없는 가상의 개념을 읽을 수 있기 때문 아닐까.

앱 심사 승인 이후 정식 론칭만을 남겨 놓고 있는 시점에서 앞으로 쌓일 사용자 데이터를 활용할 수 있는 공부를 겸하고 있다.(공부라기보단 발을 아주 살짝 넣어보는 정도..?) 처음 데이터에 대한 지식이 없는 상태에서 공부를 시작하려고 하니, 데이터 드리븐, 그로스 해킹, 린 스타트업 들어는 봤지만 그래서 어떤 공부부터 시작을 해야 하고, 내 서비스에서는 무엇을 대입해봐야 하는지 감이 잡히지 않았다.

우리의 목표는 데이터 사이언티스트(Data Scientist)가 되거나 퍼포먼스 마케터(Performance Marketer)가 되는 것이 아닌 데이터에서 찾아낸 인사이트를 바탕으로 제품이나 서비스를 지속적으로 개선해 나가는 방법을 익히는 것이다. 제품이나 서비스를 성장시키기 위해서는 특정 분야의 스킬 셋이 아니라 서비스를 만들고 운영하는 전체 프로세스에 대한 폭넓은 이해가 필요했다.

바이블부터 시작하기

책이나 아티클에서 모르는 주요 지표 및 용어 정리하기

딱, 여기까지 진행하고 있다. 모른 용어를 검색해 보고, 그 용어에 관련된 아티클을 읽다 보면 모른 것이 또 등장한다. 앞으로 아티클, 컨퍼런스, 참여할 수 있는 데이터 분석 스터디 이를 통해 배운 내용이 있다면 공유할 예정이다.