2개월 차 회고
2개월 차 피드백을 받았다.
인프랩에 PO로 합류한 지도 어느덧 2개월이 지났다. 주변에서는 아직도 수습 기간이 안 지났냐며 놀라기도 했고(이미 3개월이 지난 줄 알았다고 한다.), 인프랩에 입사를 고민하고 있는 이들은 넌지시 회사 분위기가 어떠냐며 그간의 소회를 물어오기도 했다.
입사 1개월을 지나, 2개월로 넘어가는 이 시점에 사적으로도 많은 일들이 있었기에 쉬이 입이 떨어지지 않았다. 갑작스레 코로나에 확진되기도 했고, 집 건물 보수 문제로 골치를 앓기도 했으며, 개인적으로 정리가 필요한 일들을 하나씩 마음에 수납하는 시간을 갖기도 했다. 이제 와서 생각해보면 그 사이의 적당한 바쁨이 생활의 균형을 맞춰주었던 게 아닌가 싶다.
내가 생각하는 인프랩이라는 회사
1개월 차, 누군가 내게 인프랩에 대해 물었을 때는 두리뭉실하게 '좋은 것 같다. 아직 적응하는 중이다.'라고 대답하고 넘겼다. 말 그대로 1개월 차이기도 했고, 직무 과제를 진행하며 사내 분위기를 파악해 나가는 단계였기에 무어라 말을 하기도 어려웠다. 2개월 차가 지난 지금이라고 해서 파악이 그리 능숙해졌을까만은, 적어도 지난달보다는 피부로 체감되는 요소들이 많아졌다.
1) 속도감 있는 조직
속도감이라는 것도 사람마다 체감하는 정도의 차이가 있고, 애초에 기준점부터가 다를 수 있어 명확히 정의하기는 어려울 수 있다. 그러나, 적어도 내가 가진 경험치와 기준에서는 일이 빠르게 진행되는 조직이라 느껴졌다. 인프랩은 현재 약 60명 정도의 인원으로 두 개의 서비스를 운영하고 있다. 하나는 IT 지식공유 플랫폼 인프런, 또 하나는 최근 런칭한 IT 인재 채용 플랫폼 랠릿이다.
내가 입사했던 시점은 막 신규 서비스 런칭을 앞두고 있었던 때였다. 당시의 나는 직무 과제와 더불어 인프런 서비스의 개선점을 스스로 찾아보고 제안 거리를 만들어 공유하기도 했었는데, 본격적으로 업무에 투입되면서부터 전혀 다른 속도감을 느끼기 시작했다. 이미 회사의 방향성과 로드맵, 할 일과 목표들이 모두 설정되어 있는 상황이다 보니 실제 액션이 중요했다. 그와 맞물려 처음에 가장 애를 먹었던 일도 프로젝트의 일정 산정이었다. 웹, 앱 서비스에 대한 경험이 부족하다 보니 얼마만큼의 일정이 소요될지 예상하기가 어려웠다.
물론, 경험 많은 PO라 해도 실 프로젝트를 진행하는 담당자만큼 예상 소요 시간을 면밀히 파악하기는 어려울 테다. 이 부분은 담당 개발자나 프로덕트 디자이너께 여쭤보고 일정을 싱크 하면 되는 부분이기는 하나, 이상하게 마음이 초조하고 어려웠다. (사실 PO 입장에서는 모든 게 ASAP이기 때문이다.) 이 초조함이 같은 프로젝트를 진행하는 팀원들에게 압박으로 와닿을까 걱정스러웠는데, 아니나 다를까 소통을 진행하는 과정에 있어 이러한 기색을 드러냈던 것 같아 개인적으로 아쉬웠다. (*갑자기 회고가 되었는데 이 글은 처음부터 끝까지 회고의 반복, 번뇌의 굴레가 될 테니 미리 감안하고 읽어주시면 좋을 것 같다.)
그만큼 기획부터 디자인, 개발과 QA, 배포까지 소요되는 일정이 길지 않기에 '효율'의 측면이 자주 강조된다. 즉 해결하고자 하는 문제에 중점을 두고 최소한의 리소스를 들여 빠른 시일 내 서비스에 반영시키는 것인데, 이상적인 문장과는 다르게 막상 해보면 실제 행동으로 옮기기 쉽지 않다. 목표와 요구사항을 얼라인 해놓고 가더라도 아이데이션 도중 목표와는 무관한 이야기로 새기도 하고, 편의성과 심미성을 고려하다 안 해도 될 일을 더러 스펙에 포함시키는 경우도 실제로 생기기 때문이다.
그러다 보면 프랑켄슈타인이 된다. 내가 느낀 바로는, 그럼에도 인프랩은 철저히 효율 중심의 의사결정을 지향한다는 점이다. 물론, 나의 가설이나 주장에 힘을 실을 수 있는 데이터가 있다면 이야기는 전혀 달라진다. 결과적으로 불필요한 일은 최대한 줄이고 그 시간에 더 임팩트 있는 일을 한다는 방향이다 보니, 나 역시도 우선순위를 항상 염두에 두고 사고하는 습관을 기르려고 하고 있다. 다만, 이 임팩트의 크기를 무엇을 기준으로 산정하는 게 맞을지 아직까지는 모호하게 느껴져서 힘든 부분이 있다. 쉽게 떠올릴 수 있는 것은 매출이겠지만, 그게 전부는 아닐 테다. 우선순위의 산정 기준은 쉬이 명시화 할 수도 없고, 되어서도 안 된다고 생각해서 고민이 깊어진다.
2) 회고 문화 정착
이전에 다녔던 코드스테이츠 역시 이런 문화가 잘 정착되어 있다고 생각하는데, 복이 많은 건지 인프랩 역시도 그랬다. 내부의 각 파트별로 업무와 연관된 또는 연관되지 않더라도 개인의 성장에 도움이 되는 다양한 스터디와 슬랙 채널이 운영되고 있다. 사실 학습만큼 중요한 것이 회고라고 생각하는데, 최근 각 파트 또는 프로젝트에서 진행되는 회고를 보면 느끼는 점이 아주 많다. 막연한 감상 수준의 회고를 쓰다가 다른 팀원이 작성한, 매우 정량적이고 구체화된 회고를 들여다볼 때면 이마를 세게 치게 된달까(...)
KPT, 3FS 등 회고의 방식도 중요하지만 결과적으로 이번에 잘한 것과 못한 것(어려웠던 것)을 돌이켜보고 다음에는 어떻게 잘할 수 있을지 책임을 전가하지 않고 투명하게 논의하는 것이 핵심이 아닐까 싶다. 이러한 방면에서 잘 나아가고 있는 것 같아 개인적으로는 배울 점이 많다. 업무 회고의 경우, 이전의 히스토리는 잘 모르지만 쭈와 CTO인 향로가 적극적으로 권장하는 부분이기도 하고, 어렵지 않게 회고를 할 수 있도록 전사적인 분위기와 공감대를 조성해 주셨다고 생각한다. 덕분에 신규 입사자인 나 역시도 크게 어색하지 않게 녹아들 수 있었다.
3) 불필요한 회의가 적다.
이건 1번의 '속도감' 항목과도 이어질 수 있는 부분인데, 불필요한 회의가 많지 않은 느낌이다. 아니, 이건 느낌이 아니라 확신이다. 물론 꼭 진행해야 할 논의는 당연하게 이루어지는데, 관성에 의해서 또는 공유만을 위한 미팅은 지양하는 분위기다. 덕분에 업무에 몰입하는 시간을 확보할 수 있다. (하지만 이슈가 터져서 슬랙이 울리면.. 눈물. 이건 별개의 문제니까..)
나는 PO 할 깜냥이 되는 사람인가
어느 날 그런 생각이 문득 들었다. '나는 PO라는 직무에 적합한 사람인가?'
1개월 차 동료 피드백을 받았을 때도 그랬지만, 최근 2개월 차 피드백을 받고 나서 그 고민이 더 깊어졌다. 고민이 깊어진 까닭은 단순히 좋은 피드백이 많거나 적어서가 아니었다. 고민 끝에, PO는 정답을 만들어 나가야 하는 사람이라는 결론에 도달했기 때문이다. 그게 어떤 수단을 통해서이든 간에.
정답이 없는 직군인 만큼, PO로서 자신만의 스페셜티를 찾아나가는 과정이 중요하다고 생각됐다. 물론, 프로젝트를 총괄할 만한 기본적인 역량과 스킬셋이 갖춰졌다는 전제 하의 이야기이겠지만. 그게 데이터를 보고 인사이트를 도출하는 능력이든, 개발적인(수학적인) 역량이든, 비즈니스를 보는 관점이든 자신이 가진 뾰족한 강점이 있다면 그게 PO로서 좋은 무기가 되겠구나 느꼈다. 적고 보니 모든 게 논리력 기반이기는 하다. 메이플스토리에서 주사위를 굴려 이상적인 스텟을 맞추려 노력했던 그 시절이 아련하게 스쳐 지나갔다.. 4-4-4-4는 나오지 않는단다..
출처 - https://www.instiz.net/pt/2526578고민만 하고 있으면 변하는 건 없다. 당장은 스스로가 무지렁이로 느껴지더라도 계속 그 상태에 머물러 있지 않는 것이 중요했다. 그렇게 마음가짐을 막 바꾸려던 찰나, 환경적으로도 변화가 생겼다. 입사 초기에는 직무 과제와 함께 인프런의 기능 개선 또는 신규 기능 티켓들 위주로 업무를 진행했었다면, 현재는 랠릿 서비스의 B2C 쪽 티켓을 담당하고 있다. 나로서는 입사 후 두 개의 서비스를 모두 경험해 볼 기회가 주어져 기뻤지만, 그만큼 단기간에 양 서비스에 대한 이해도를 큰 폭으로 높일 필요성이 있었다. (한 마디로, 왕초보 사냥터에서 달팽이 잡다가 갑자기 발록을 잡게 된 느낌이었다.)
이후 2개월 간 배운 것들을 3F(Facts, Feelings, Findings) 형태로 정리해 보았다.
Facts
입사 후, 서비스에 대한 이해도를 빠르게 높이기 위해서 테이블 구조와 정책서를 파악했다.
프로젝트를 진행할 때마다 담당 팀원과 슬랙 채널을 만들어 빠르게 소통했다. 단 하루, 이틀 내로 개발과 배포가 가능한 버그나 기능 수정 건은 제외했다.
프로젝트 킥오프 시 제품 관점에서도, 개발 관점에서도 더 나은 대안을 찾기 위해 프로덕트 팀원들과 충분히 아이데이션 하는 자리를 가졌다.
진행한 프로젝트의 정량적인 결과를 도출하기 위해 다양한 툴들을 활용했다. (GA, 핵클, 핫자 등)
1개월 이상 소요되는 장기 프로젝트에 참여하며 짧은 주기로 진행되는 스프린트를 경험했다.
티켓팅 및 개발 프로세스를 파악하고, 현재 운영 방식에 대한 CX/콘텐츠/비즈니스/마케팅 파트와 프로덕트 파트 간의 시각 차이를 확인했다.
Feelings & Finding
같은 서비스라고 해도 B2B, B2C, Admin은 저마다 다른 사용자 경험을 설계하기 마련이다. 이 차이에 기반해 생길 수밖에 없는 수많은 차이를(권한에 따른 정책 차이, 기능 노출 유무 등) 이해하고, 더 나아가 동반될 수 있는 엣지 케이스까지 미리 연상할 수 있다면.. 얼마나 행복할까. 안타깝게도, 입사 초기의 나는 정리되어 있는 정책서를 읽으며 머리로만 유저 여정을 그려보았던 것 같다. '차라리 그 시간에 어드민을 조금 더 들여다보았더라면 얻는 게 더 많지 않았을까'하는 생각도 들었다.
물론 테이블을 들여다보는 것도 좋은 방법이지만, 단순히 데이터만 파악하는 것과 어드민 상에 어떤 정보와 기능이 축적 및 활용되고 있는지 아는 것은 분명 다르다고 생각된다.
직무 과제 회고 때도 이야기했지만, GTM 사용이 미숙해서 데이터 트래킹에 이슈를 겪은 적이 있었다. 이후, 개발 파트 일타강사 빠삐코와 리온의 도움으로 이제는 어렵지 않게 이벤트와 태그 세팅, 작업공간 관리가 가능해졌다.
친절한 UX만이 정답인 줄 알았다. 한때는 문구 하나를 바꾸어 전환율 상승을 만들어내는 UX Writing을 신봉하기도 했었다. (슬프게도 현재까지는) 막상 데이터를 확인했을 때, 기대했던 것만큼 드라마틱한 변화를 만들어내는 마법은 없었다. 유저 편의성과 접근성이 충분히 고려되어야 하는 것은 맞지만, 단순히 그것만을 위해 전체적인 효율성을 해치는 의사결정을 해서는 안 된다는 쭈의 이야기 되새기기.
어디까지가 MVP인가?
프로젝트의 생산성 측정을 원활히 하기 위해 ITS를 충분히 활용하고, 과정에서 얻은 lessons learned를 스프린트 플래닝 및 회고에 적용할 수 있어야 한다. (e.g. 플래닝에서 목표했던 작업 양과 실제 작업 양을 비교해 어떤 병목이 있었는지 역산해보기) 최근 데브옵스 팀의 선비가 공유해준 모 기업 테크 블로그의 생산성 관리 아티클을 읽었는데, 팀마다 그리고 기업마다 적용되는 규칙이 다르다는 것을 이해할 수 있었다. 우리 팀에 맞는 방식은 무엇일까?
공부하면서 터득한 것 혼자만 알지 말고 가이드화해서 컨플루언스에 올리고 공유하자. 막상 해보면 크게 시간이 들지도 않는다. 넓게 보면 모두의 시간을 절약하는 길이 될 수 있다. 학습 비용 들일 건 들이고, 줄일 건 줄이자.
빠른 업무 공유와 명확한 의사소통, 어떻게 하면 더 잘할 수 있을지 고민이 된다. 비개발자이다 보니, 운영 파트와 논의나 소통을 할 때는 큰 이슈 없이 서로의 언어로 잘 컴케가 이루어지는 느낌을 받는다. 다만, 프로덕트 팀과 협업 또는 논의 시 기획적으로 놓친 엣지 케이스들이 발견되거나, 커뮤니케이션 로스가 종종 일어나 나조차도 요구사항에 대한 불명확성이 증가하는 것처럼 느껴질 때가 있다. (e.g. 예를 들어, 테스트 케이스를 작성하더라도 사용자 관점의 수행 절차 위주로 써 내려가다 보니 기술적 분기 처리에 대한 확인이나 시험 항목을 빼먹는 경우가 생긴다.)
여러 태스크를 병렬적으로 진행하다 보니 기획적인 디테일을 챙기거나 깊게 사고(소위 말하는 딥 다이브) 하기 어려운 상황이 종종 발생된다. 투두 리스트 툴도 쓰고 있고, 최대한 시간관리를 잘해보려고 노력 중인데.. 흑흑. 이건 모르겠다.
마무리
더 나아가기. 이전 회사의 동료 분이 조언했듯, 늘 자긍심을 갖고 일을 해나가고 있지만(출근길 플레이리스트는 늘 그렇듯 블랙핑크 노래로 시작한다. 어깨 뻠삥.) 매일매일 눈앞에 산재한 퀘스트를 깨 가며 나의 부족함을 마주하는 건 생각보다 쉽지 않은 일이었다. 자긍심이나 자신감과는 별개로 현실은 현실이니까. 그럼에도 하루하루 경험치를 축적해 나간다는 생각으로 일단 해나가다 보면 뭐라도 되어있지 않을까. 그 과정에서 함께 고생해주는 동료들에게는 늘 고맙고 미안한 마음이다.
최근 프로젝트를 진행하면서 심적으로 부담이 되어 멍한 기색을 못 숨겼던 때가 있었는데, 그때마다 힘이 되어준 건 동료들이었다. 회사 근처를 거닐며 앞으로의 협업 방식에 관해 메리와 편히 이야기를 나눌 때도, 멍하게 앉아있는 나를 불러내 차(no car, yes tea)를 사주며 조용히 이야기를 들어줬던 꾸기도, 여지껏의 경험과 느꼈던 감상을 토대로 실효적인 조언을 주는 파트원들도, 모각글 파티원이자 입사 동기 아셀도, 처음이니 그럴 수 있다며 차분하게 느낀 지점과 함께 작은 조언을 건네주었던 스댕도. 생각하다 보니 고마운 일만 투성이다. 얼른 2차 전직을 해야 하는 이유가 생겼다.
