들어가며,
본격적인 회고에 앞서, 간단히 배경설명을 좀 해보려고 한다.
회사를 옮긴지 2년이 지났다. 엄밀히는 회사를 바꿔본 경험이 적은 편은 아니지만, 큰 맥락에서는 어찌보면 첫 이직이었다.
이력서 상으로는 여러번의 이직이지만, 실제로는 한 회사의 신입 공채로 입사하여, 그 회사에서 나를 안고 '사업'이 네번이나 회사를 옮겼다. 덕분에, 해당 사업에 적을 두고 있는 나도 회사를 네번이나 옮겼지만, 늘 같은 그룹사 안에서 이동하다 보니, 크게 이직을 했다는 생각이 들어본 적은 없었다. 특히, 같은 사업부 사람들이 주로 같이 이동했던지라, 본부나 팀을 옮긴 것 정도의 생소함이 있을 뿐,회사가 바뀐다는 느낌 보다는 그저 사무실이 바뀌고 복지나 분위기가 좀 바뀐다는 느낌 정도였다.
8년의 대기업 생활 후에 내가 합류한 회사는, 전체 직원은 100명 남짓이지만(입사 당시)Product manager는 나 하나, 개발자를 포함한 엔지니어를 모두 합쳐도 30명 남짓한 '작은' 회사였다. 물론, 한국 지사가 작을 뿐 Global하게는 완전 대기업인데다, 또 기업의 외연적인 측면을 생각하면 작은이란 단어가 글을 쓰는 지금도 매우 어색하게 느껴지지만, 여기서 작다는 의미는 우리 오피스의 직원 수에 그 방점을 둔다.
특히, 실제로 내가 함께 일하는 개발자는 3명~5명 정도를 오갔다. 여기에 함께 일하는 디자이너 1명, 정책과 실무, 운영을 함께 논의하는 동료 1명 정도의 소규모 그룹이, 내가 몸담은 Product 조직이다.
이직 2년차, 대기업 vs. 스타트업까지의 큰 차이는 아니지만, 아래의 비교 정도라 할 수 있겠다.
- 큰 조직 vs. 작은 조직 (엄밀히는 이 회사도 인원은 많지만, 한국지사는 약 100명)
- 국내 대기업 vs. 외국계 대기업(?)
쓰다 보니 글이 길어져서, '대기업 시절'의 회고를 먼저 간단히 적어보려고 한다. 결국 PM의 입장에서 큰 조직, 작은 조직의 비교를 소회로 풀어보고자 글을 쓰기 시작한 것이니 말이다.
"하면 좋은 일"이 많았던 대기업 기획자 생활
서비스를 만들다 보면, 되게 자주 쓰는 단어가 있다. 영어로는 Nice-to have. 직역하면 "있으면 좋을만한 (기능)".
주로 다음 버전에 들어갈 기능이나, 이번 분기 할일 등을 정리하다 보면 나오는 이야기. 그리고 문자 그대로의 의미와는 정 반대로, 주로는 "일단은 안 만들" 기능이다. 당장 필요는 없으니, 언젠가 다시 생각해보겠다는 의미. 하지만 Project manage를 해보면, 이렇게 한번 backlog로 들어간 일은 좀처럼 Icebox를 나오지 못한다.
하지만, 지금에 와서 생각해보면 대기업에서 업무의 많은 부분은 '하면 좋은 일'로 채워져 있었던 것 같다.
대기업에서의 '일'은 하늘에서 떨어진다.
함께 일하는 사람들에게 일의 배경을 설명할 때, 개인적으로 좋아하는 표현이 있다.
"하늘에서 떨어진 일."
그러니까, 실무자나 Product Owner가 보기에 필요한 일이 아니라, 어디선가 위에서 내려온 바로 그 일. 그 요구사항. 그 기능 같은 것들.
특히, 그런 하늘에서 떨어진 일 중에는 아래와 같은 특징을 가진 일들이 많았다.
- 도무지 우리 서비스의 주요 고객들은 사용하지 않을 것 같은 기능
- 하지만 옆 회사 '경쟁(이라고 매번 보고서에 올라가는)' 서비스에서 출시하거나, 업데이트 한 그 기능
- 혹은 그 회사에서 그런 걸 할 거라고 '언론'에 보도했지만 실제로는 있는지 잘 모르겠거나, 임팩트 전혀 없는 기능
- 하지만 안타깝게도, 우리도 곧 넣어야 하는 바로 그 기능.
개인적으로 대기업에 오래 근무하면서 늘 염두에 두고 있는 점 중 하나는, 회사에서 요구하는 일을 최대한 좋은 품질로 수행하는 것 또한 직장인에게 중요한 덕목 중 하나라는 것이다.
특징에 적은 것처럼, 이러한 일들은 무엇보다 동기부여가 어렵다. Product manager의 입장에서 보아도 우선순위가 그렇게 높지 못하며, 이 프로젝트를 통해 달성하고자 하는 바도 명확하지 않은 경우가 많았다. 무엇보다, 그 일을 시작하게 된 계기가 말 그대로 '위에서부터 내려온 지시'인 만큼, PM인 나부터도, 명확하게 이를 동료들에게 설명하기 어려운 경우가 많았다. 나야 어떻게든 "월급을 받았으니까" 라며 스스로 동기부여를 해볼 수 있겠지만, 아무리 회사원이라 해도 기계는 아니다. 모두가 그러긴 어렵다.
그렇게, PM도 설득이 되지 않고, 개발자도 디자이너도 공감이 가지 않는, '하늘에서 떨어진 일'은 많이 양보해 봐야 Nice to Have다. 있으면 좋겠지만, 지금 급하진 않은 그런 일들.
물론, Top-down이 반드시 나쁘기만 한 것은 아니다. 때로는 Top-down이 아니면 추진할 수 없는 일도 분명히 있다. 하지만 적지 않은 빈도로, 사업적으로 공감이 가지 않거나, 왜 해야하는지 잘 와닿지 않는 기능이 우선 순위가 올라오는 일들이 많았던 것 같다.
대기업의 장점
그럼 대기업에 장점은 없냐? 오직 복지만 보고 다녔던 거냐? 절대 아니다. 작은 조직에 오니, 절대로 해볼 수 없는 일도 분명히 많다. 예를 들면, 이 회사로 옮긴 뒤에는 예산이 크게 소요되는 프로젝트는 상대적으로 맡기 어려워졌다.
특히 내가 8년간 몸담았던 스트리밍 서비스가 아주 대표적이다. 일단 서비스를 굴리는데만도 돈이 엄청나게 많이 든다.
아주 러프하게, 계산해보면 다음과 같다.
- YouTube 권장 화질 (8Mbps)로 1명이 10분간 비디오 시청: 4800Mbps = 8Mbps x 60s x 10min
- 4800 Mbps는 Gigabytes로 전환 시 0.6 Gbytess
- 위 비디오를 1000번 시청하면, 600 G
- Amazon 비디오 스트리밍 서비스를 기준으로, 1000번 시청에 5.1 USD
- 참고로 YouTube의 공식 발표 '일' 조회수는 하루 40억 건이다.
당연히 YouTube는 직접 스트리밍 서버를 구축하니, 저것 보다는 저렴한 스트리밍 비용을 부담하긴 하지만, 함부로 스타트업이 들어갈 수는 없는 영역이 비디오 스트리밍라는 이야기가 하고 싶었다. (하지만 그 힘든 것을 왓챠가 해냅니다. 그것도, 무려 5년을 넘게 살아남고 계신다.)
그리고 다시 한발짝 나와서, 저런 엄청난 돈이 드는 서비스를 작은 조직에선 당연히 상상조차 못한다. (물론 현재 회사도 엄밀히는 대기업이고, 절대 돈이 없는 회사는 아니지만, 지사이다 보니 어느정도 한계가 있긴 하다.)
종합해보면,
결국은 대기업에서의 프로젝트는, 작은 조직에서 맡기 어려운 규모의 프로젝트이긴 했지만, 동시에 Product Manager 입장에서 '당장 이걸 하지 않으면 우리가 망합니다!' 같은 우선 순위가 높은 프로젝트는 아니었던 느낌이다.
나는 결국 그 점이 아쉬워서 큰 조직을 떠났다.
위에서 정한 우선 순위나, 사업 방향 등에 공감이 가지 않는데, 일을 꾸역꾸역 해내야 하는 점에 지쳐서.
일종의 자기 결정권이랄까? 대기업은 당연히 그런 부분이 좀 부족하다.
결론적으로 만족하냐고? 현재는 만족한다. 그러니 2년이나 작은 조직으로 옮기고도 살아남을 수 있었다고 생각한다. 그런 의미에서, 다음 글에서는 작은 조직(?)에 와서 좋았던 점들을 한번 정리해볼까 한다.
'Retro' 카테고리의 다른 글
작은 조직에서의 Product Roadmap 관리 이야기 (0) | 2021.02.09 |
---|---|
이직 2년차 회고: Global 게임 회사의 Product manager - (1) (4) | 2021.02.01 |