4년만의 회고 - Goodbye, My Twenties

참 시간이 많이 흘렀다. 마지막으로 쓴 회고는 2018년에 작성한 지난 3년의 기록: 대기업에서 스타트업으로다. 지난 4년간 노트에 많은 글을 썼는데 현생에 파묻혀 사느라 블로그에는 올리지 못했다. 그간 많은 일이 있었는데 세부적인 것은 각각 다른 글에서 다루기로 하고, 여기선 지난 4년을 대략적으로만 다뤄봐야겠다.

GDG Korea WebTech

2018년으로 거슬러 올라가, 이때 처음 다녔던 스타트업인 Ncode에서 프런트엔드 개발을 하면서 두개 정도의 개발 커뮤니티에서 활동을 하고 있었다. 하이닉스에서 인프라를 하다가 처음 프런트엔드를 시작했던 시기이기도 했고 IT와 스타트업 분야의 문화와 vibe가 궁금하기도 했다. 그리고 무엇보다 마치 외국어를 공부할때 soak brain into the pool 이라는 표현을 하는 것처럼 앞으로 소프트웨어 엔지니어링을 여러 관점에서 조명하면서 공부하고 제품을 만들어보고 싶었기 때문에 커뮤니티를 자주 찾아갔다.

그렇게 커뮤니티에서 질문도 올리고 답변도 하고, 페이스북과 블로그에 스타트업, 교육 등에 대한 글도 자주 쓰고있었다. 그러다 GDG 개발자 커뮤니티를 운영하시던 분께서 우연히 내가 쓴 글들을 보셨고 그걸 계기로 이야기를 나누다가 마침 커뮤니티 오거나이저가 부족했는지 개발자 행사를 만들어보면서 커뮤니티를 운영해보는 것을 제안해주셨다.

내가 프런트엔드 엔지니어였고 웹에 관심이 있었기 때문에 자연스럽게 GDG 내의 WebTech 챕터로 들어가게 됐다. 2018년 9월에 들어갔을때 이현섭님이 계셨고 뒤이어 많이 조인하셔서 현재는 장한보람님, 서유진님, 노태환님까지 총 다섯명이 오거나이징을 하고있다.

그렇게 2018년 9월부터 2020년 초 코로나가 터지기 전까지 여서일곱개 정도의 이벤트를 만들었다. 기술 세미나, 해커톤 형식의 코딩 대회, 고민을 나누는 네트워킹 파티, 라이트닝 토크 등의 형식으로 이벤트들을 만들었는데, 만드는 입장에서 돌아보면 커뮤니티나 이벤트가 주니어나 시니어 구분할 것 없이 모두에게 여러 방면으로 도움이 된다고 느꼈다. 주니어에겐 전반적인 분위기나 학습 방향을 파악해보는 장이 될 수 있고, 시니어에겐 기존의 관점을 다르게 바라보거나 바꿀 수 있는 계기가 되기도 하고 전에 받아보지 못했던 종류의 피드백을 얻어 리프레시할 수 있는 장이 되기도 한다. 코로나 이후로 딱 한번의 이벤트 밖에 하지 못했고 이런 장점을 얻을 수 있는 기회가 많이 사라진 것 같아서 아쉬운 마음이 크다.

첫번째 스타트업에서 두번째 스타트업으로

처음 다녔던 회사를 나와 Ncode에서 나의 첫 B2C 제품을 만들고 런칭을 했다. 이 런칭으로 앱 외의 곳에서 매출이 새로이 일어나는 것을 지켜보면서 참 설레었다. 2018년 이 시기에는 한창 스타트업들이 React를 도입하고 있던 시기였다. react-router-dom, redux, redux-saga, webpack(v3, v4) 등을 하나하나 문서를 보고 세팅하고 알파에서 터지고 고치고를 반복했었다.

당시에 머신러닝을 공부하려고 대학원 진학을 생각하고 있었는데 프런트엔드와 머신러닝을 같이 하면 재밌을 것 같다는 생각을 하고있었다. 그러다 생전 처음 다른 성의없는 헤드헌터와는 달리 일을 제대로 하는(?) 헤드헌터를 만나게 되어 스타트업 몇군데를 소개받았는데, 처음엔 별 생각이 없었다가 평소에 같이 일해보고 싶었던 두 프런트엔드 엔지니어가 있는 회사가 그중에 있어서 결국 그 스타트업으로 가기로 마음을 먹었다.

두번째 스타트업

그렇게 암호화폐 거래 서비스인 Gopax를 만드는 Streami로 가게 됐고, 이 곳이 두번째 스타트업이 되었다. 여기에 오기전에 경험치가 부족했다고 생각했지만 같이 일하고 싶은 엔지니어가 둘이나 있었고 좀더 어려운 문제를 풀 수 있는 환경에서 일해보면 어떨까라는 생각도 갖고있어서 문을 두드려봤다.

여기서 블록체인의 흥망성쇠를 짧게 경험했는데, 비트코인이 300만원대까지 떨어진 것을 보고 두가지 생각을 했다.

• 2천이 넘던게 300까지 갈 수도 있으면 거의 허상이 아닌가?
• 반대로는, 오히려 100원까지 하락하더라도 완전히 존재가 없어지지 않는다면 언제든 가치가 인정받게 되는 순간이 오면 다시 가격은 오르지 않을까?

그렇게 고팍스에 코드를 머지하면서 블록체인을 신뢰하는 정도만큼 계속 비트코인을 300만원 근처에서부터 매집하기 시작했다.

스트리미에서의 커리어는 순탄치 않았다. 이미 입사하기 전부터 대내외적으로 리스크가 커지고 있었고 그 여파 덕에 엔지니어들이 계속 이탈하고 있는 상황이었다. 심지어 블록체인 업계에 대한 정부의 규제가 하나둘 실현되면서 그 기조에 따라 본래 스타트업이 공격적으로 제품을 성장시키는 일들을 하기 어려워졌다. 그래서 같이 일하고 싶었던 두 프런트엔드 엔지니어와는 협업을 많이 하지 못했고, 하나둘 나가는 동료들을 보면서 출근할때면 나도 살려달라는 공허한 외침을 해대기 시작했다.

기술적으로 새로이 시도해보거나 넓은 관점에서 컴포넌트 구조를 재설계하고 케케묵은 코드들을 리팩토링 하는 등의 일들을 기대했으나 그렇게 많이 하지 못한채 시간이 흘렀기 때문에 커리어가 하락한 감은 있지만 회사에서 좋은 동료들을 많이 알게 됐다. 항상 로토, 오다, 루카스, 알마 모두에게 고마움을 느끼고 있다. 그래서 스트리미에 오기로한 나의 투자에 대한 net profit은 plus다.

세번째 스타트업

스트리미에서의 커리어가 더이상 나아질 기미가 보이지 않았다. 다행히 나를 채용했던 프런트엔드 엔지니어와 함께 같은 날 퇴사하고 Fullerton, CA에 기반을 둔 ODK Media라는 미국 스타트업에 2019년 초 같은 날 입사해서 한국 사업장에서 거의 풀재택으로 일하기 시작했다. 당시엔 캐나다나 호주로 이민을 생각하고 있어서 자주 있진 않았지만 영어로 커뮤니케이션을 해야하는 일이 생기면 거리낌 없이 참여했다. 일하는 환경이 상당히 괜찮아서 이제 드디어 재밌는 일을 좀 할 수 있겠다는 생각이 들었다. 그렇게 흩어졌던 고팍스 프런트엔드 멤버들도 다시 모였고 네이버에서 고통받던 중학교 친구인 지훈이도 프런트엔드 팀으로 합류했다. 이렇게 딱 모였을때 팀으로 뭔가 만들어 보기도 하고 기술을 깊게 공부해서 제품을 만들어나갈 생각에 되게 즐거워했던 기억이 난다.

OnDemandKorea와 Ad Tech

ODK에 와서 처음 기여한 제품은 OnDemandKorea다. 한국 콘텐츠를 미국과 캐나다에서 스트리밍하는 서비스이고 북미가 타겟이기 때문에 국내에선 VPN으로 접근해야 한다.

이 제품은 초기 창업자들이 엔지니어의 도움 없이 스스로 만들기 시작해서 중간에 python 기반으로 포팅됐는데, 내가 기여를 시작했을땐 python django + django template + jQuery으로 구성되어 있었다.

ODK에서 일하는 2년 3개월의 기간 동안 OnDemandKorea에는 소규모의 기능 추가나 업데이트, es3로 되어있는 일부 js 파일들을 es5 마이그레이션(어떻게 했지..), Google Ad Manager(+ GPT)를 기반으로 배너/동영상 광고 연동, 동영상 광고 최적화(Ad Rules) 작업들을 했다.

로토가 실험적으로 OnDemandKorea를 Next.js 기반으로 포팅하는 일을, 루카스와 지훈이가 GraphQL Server(내 기억엔 거의 GraphQL Gateway 였다)를, 봉과 오다가 디자인 시스템을 만들고 있을때 나는 기존에 연동돼있던 GAM을 PM, 광고팀과 지지고 볶으면서 일면식도 없던 광고 도메인을 하나씩 습득해가면서 광고 작업을 했다. 그 여정은 GAM에 대한 지난 글에서 찾아볼 수 있다. 원래 광고 작업을 할 생각은 추호도 없었는데, 기존에 광고 작업을 주로 하던 분이 없던 상황이어서 팀에서 누군가가 해야만 했다. 프런트엔드 엔지니어 입장에서 Ad Tech는 딱히 보편적이거나 잘 알려져있지 않아서 관심이 잘 안갔던 탓도 있고 평소에 사용자들이 많이 사용하는 B2C 제품을 만드는 것에 관심이 있었기 때문에 광고 작업을 딱히 하고싶지는 않았다. 그런데 ODK에 오기 직전에 휴식을 취하면서 어떤 삶을 살 것인가에 대해 정리한 결과로 뒤에서 이야기할 Business Oriented Engineer가 되어야겠다는 생각에 엔지니어링 회의에서 광고 작업을 누가 해볼래요라는 질문에 덜컥 해보겠다고 했다. Ad Tech가 웹 서비스에서 매출을 일으킬 수 있는 수단이기도 하고, 매출 최적화도 고민해볼 수 있으며 무엇보다 광고 도메인을 알게 되면 제품에 대한 고민의 폭을 넓힐 수 있고 이후에 회사를 새로 정하거나 비즈니스를 고민할때 적지 않은 도움이 되겠다는 판단이 있었다.

그렇게 광고 지식이 제일 많았던 엔지니어에게 질문하고 문서를 읽으면서 작업을 해나갔다. 동영상 광고 최적화 과정에서 이 작업을 실제로 진행하려면 무엇이 필요한지, 지금 빠져있는 것이 무엇인지를 회사에 남아있던 자료와 공식문서를 통해 찾은 자료를 통합해 정리했다. 그렇게 MRSS feed가 빠져있음을 알게 되어 당시 OnDemandChina를 맡고있던 PM과 논의해서 API를 백엔드팀에서 만들어주었고 OnDemandKorea를 위한 Ad Rules를 광고팀이 운영하게 됐다.

아마도 입사하기 전에 생각을 정리하지 않았다면 하지 않았을 작업이었는데 회사와 비즈니스 관점에서 꼭 해야하는 일을 마무리했고 매출이 꽤 큰 폭으로 상승한 것을 지켜보면서 앞으로 엔지니어로서 좀더 비즈니스에 집중된 일을 하려면 어떻게 하면 좋을지에 대해 감을 잡는 경험이 됐다. 그리고 당연하게도 이 매출 상승은 광고를 잘 운영하기 위해 디자인팀, 백엔드팀, 광고팀, PM 등 많은 동료들의 선행작업이 있었기 때문에 가능했다. 특히 광고팀이 수 많은 버전의 광고를 집행하고 내리는 등의 실험을 하지 않았다면 최적화는 불가능했다. 이 경험에서 프런트엔드 관점에서 무엇을 얻었는지는 잘 모르겠다. 그저 광고 도메인 상의 로직을 구현하는 것이 끝인 일이라 엔지니어링 관련 고민은 거의 하지 못했다.

끝나고 나서 나의 부족한 점이 굉장히 많이 보였다. 작업은 끝내긴 했지만 처음 배너광고를 시작할때부터 훨씬 더 proactive 하게 광고 도메인을 빠르게 학습하고, 매출이 현재 어떻게 나고있는지 파악한 뒤 어떻게 최적화할 수 있을지 고민할 수 있지 않았나 싶다. 배너광고 작업부터 동영상 광고, 최적화 작업까지 꽤 오랜 기간 작업을 했기 때문에 내가 더 주도적으로 진행했다면 도메인 지식의 정리, 종합 및 전사적인 전파, 현재 상황과 이상적인 상황 사이의 간극에 대한 이해를 바탕으로 한 기술적인 도달 방법을 더 일찍 제시하고 작업도 더 이른 시기에 마무리하는 extra mile을 경험했을 수 있었을 것 같다. 실제로 처음 광고 작업을 시작했을때 이런 고민을 잠깐 하긴 했었는데 실행으로 옮기지 못했다. 그래서 이런 부분을 반성해보고 다음에 다시 이런 비슷한 상황이 있을때 처음부터 어떻게 도전적으로 일을 해낼지 생각해보려고 한다.

OnDemandChina

OnDemandChina는 입사하고 세달쯤 됐을 시점인 2019년 봄에 로토의 리드로 루카스와 셋이서 CRA 기반으로 새롭게 만든 비디오 스트리밍 서비스다. 이때 처음 react hooks를 적용해서 제품을 만들었고 이때부터 Class Component는 거의 안쓰게 됐다. 이때 이 경험으로 React Hooks: 훅마법사의 시대 라는 행사에서 숟가락을 살짝 얹어 발표를 했다.

OnDemandChina를 만들때 일의 양에 비해 데드라인이 너무 빡빡하게 잡혀있었는데, 평소에 코드를 만들때 생각을 많이 하는 편이어서 아무래도 루카스, 로토에 비해 절대적인 기여량이 적었다. 그래서 두분께 미안한 마음이 컸다. 열심히 했음에도 왜 적었는지 당시에는 알지 못했는데 그간 스스로를 돌아보면서 왜 그때 그런 상황에 놓여있었는지 이제서야 조금 이해할 수 있게 됐다. 올해 특히 나의 이러한 생각 많음, 분주함, 쉽게 집중이 분산되는 나의 생각 및 정신에 대해서 면밀하게 살펴보고 개선해보려고 한다.

OnDemandKorea에서 겪었던 광고와 GAM을 더 학습해서 배너광고와 동영상광고, Ad Rules를 OnDemandChina에 적용했다. mau가 서비스 런칭에 들이부은 리소스 대비해서 눈물이 나는 수준이어서 매출이 많이 나와주지는 않았지만 한 축에서 검증된 매출 수단을 횡으로 늘리는 것의 가능성과 위험성에 대해서 생각해볼 수 있었다.

내 생각엔 ODC는 시장조사가 제대로 안이뤄졌거나 아예 시도조차 안된 것 같았다. 북미 시장에서 중국 콘텐츠를 아무리 싼 가격에라도 볼 사람이 얼마나 될 것인지, 북미에서 중국 콘텐츠에 대한 인식이 어떠한지, 북미에 있는 중국인이 볼 것을 가정했을텐데 그 중국인들의 비디오 스트리밍 서비스의 사용량과 사용 행태가 어떤지 등을 알아봤다면 혹은 뇌피셜으로라도 문서를 작성해서 사업부 전체가 공유를 했더라면 아마 다른 식으로 프로젝트를 시작하지 않았을까 생각했었다. 횡으로 매출수단을 그대로 적용하는 것은 지렛대까지는 아니지만 적어도 사업의 수에 비례하게 매출을 낼 수 있기 때문에 가능성 측면에서는 그정도의 upside가 있을 거라고 생각해볼 수 있다. 경험상 위험성은 프로젝트를 얼마나 작게 시작하는지가 큰 factor로 걸려있는 것 같다.

시장조사가 잘 되어있더라도 얼마든지 프로젝트가 안될 위험성은 존재하는데, 조사마저 잘 되어있지 않은 상황에서 만약 프로젝트의 덩치를 크게 만들어서 릴리즈한다면, 그 오랜 기간 동안 회사에서 투입하는 인력, 인력들의 심리적 에너지, 시간, 자본 등 투입한 모든 리소스의 배로 타격을 입게 된다. 따라서 top metric이 아닌 소프트웨어 제품으로 매출을 만들어 성장하는 회사는 어떤 상황에서든 크게 시작할 필요가 전혀 없어보인다. 아무리 성공이 보장되어 있어보이는 상황이어도 동일한 결론을 내릴 것 같다. 그 이유는, 누가봐도 성공할 수 밖에 없는 프로젝트여도 작게 시작하면 빠르게 시장에 딜리버리 될 수 있고 이미 그 시점부터 경쟁자보다 데이터를 더 빨리 얻고, 사용자들 또한 더 빨리 만나며, 그들로부터 피드백도 더 빠르게 얻고, 그걸 다시 제품에 반영할 수 있다. 너무 확실해서 크게 나간다? 그건 너무 오만하다 못해 거만하기까지 한 의사결정이 아닐까 한다. 성공의 가시성이 높은 제품도 이 정도인데 하물며 전혀 가시성이 보이지 않았던 ODC는 말할 것도 없고 그 의사결정들이 너무 실망스럽다. 이 점에 대해서는 높은 확신 때문에 어조를 강하게 했는데, 이 논리를 뒤집을 수 있는 케이스를 만난다면 생각을 바꿔보고 싶다. 아직까지는 그런 사례를 본 적은 없다.

ODC 프로젝트가 어떻게 준비되는지, 어떻게 미국과 커뮤니케이션 및 의사결정이 이루어지고 전달되는지를 지켜보면서 lean, agile한 조직이 어떤 것인지 반면교사 삼아 구체적으로 생각해보게 됐고 제품이 릴리즈되는 것과 조직이 운영되는 것에 사내 정보의 투명성, radical candor와 문제를 해결하는 문화가 얼마나 중요한지 절실하게 느끼게 됐다. radical candor에 대해서는 Ray Dalio의 Principle에서 Bridge Associate가 겪은 내용을 보고 어느정도 알고 있었다. 조직이 제품을 만들때 의사결정을 내리는 과정에서 의문이 생기거나 문제를 발견하면 그 조직의 문제를 나의 문제로 여기고 문제의식을 공유하고 문제 제기를 해 조직이 문제를 문제라고 인지하고 해결할 수 있도록 만드는 정신이라고 이해했다. 이런 관점에서 ODC는 정말 크게 나갔다. 홈페이지에 3개의 메인 컨텐츠(Cover Contents), admin으로 관리하는 추천 컨텐츠, 장르별 컨텐츠, 비디오를 재생하는 상세 페이지, 검색 페이지, 로그인 페이지, 반응형 대응까지 모두 하고 릴리즈했다. 실리콘밸리를 바로 옆에 두고있으면서도 start small 이라는 실리콘밸리의 격언의 무게를 무색하게 만드는 의사결정들이 범람했고 그 물결의 파동은 한국에까지 다가왔다. 자신감이라고 해야할까? 그 자신감이 놀라웠다.

이 사업이 성공할 수 있을지 빠르게 보고싶으면 추천하고 싶은 컨텐츠 10개 정도를 메인 컨텐츠로 보여주는 페이지, 재생하는 페이지 두개만 만들어서 릴리즈 했어도 됐다. 선보이고 싶은 중국 미디어 컨텐츠가 북미에서 유의미한 수준으로 소비될 수 있는지, 사람들이 유료 구독을 하고싶은 압력이 생길 수준인지를 파악하는 것이 사업 첫 스텝의 골자일텐데 메인과 추천 컨텐츠가 왜 나뉘어야 할까? 장르별 컨텐츠는 왜 있어야 할까? 검색 페이지는 왜 있어야 할까? 검색조차 안하고 싶을지도 모르는데. 로그인 페이지는 왜 필요할까? 그냥 빨리 보게 해서 컨텐츠 수요를 봐야하는거 아닌가? 반응형을 왜 처음부터 만들어야할까? 넓은 데스크탑에서 볼지 말지도 모르는데 테블릿과 모바일에서 접근을 하긴 할까? 진짜 중국 컨텐츠가 북미에서 소비될 가능성이 크다면 데스크탑에서도 충분히 확인할 수 있지 않을까? 그런데 여기서 iOS, Andorid 앱까지 만든다고? 와우~

정말 필요한 두 페이지만 만드는 선택을 했다면 한달만에 제품을 만들고 릴리즈 했을 수 있었다. 그렇지만 10개월 넘는 시간 동안 저걸 다 만들고 QA 다 돌리고 릴리즈하는 선택을 했다. 프로젝트를 시작하는 시점에 이미 이런 상황을 목격하고 있었고, 아직 이런 전형적인 실패하는 유형의 프로젝트(실패의 정의는 완전히 망하는 것이라기 보다는 제품이 sweet spot에 놓여있지 못한 상태로 오랜기간 유지되는 것이라고 해보겠다)를 진행해본 적이 없어서 한번 몸소 겪어보는 것도 좋은 반면교사 형태의 경험이 되겠다는 생각을 했다. 결과는 참혹했고, 결과가 좋았더라도 여전히 반면교사 케이스라고 생각했을 것이다. 이미 크게 나가는 바람에 요구사항에 작은 변경만 생겨도 코드 레벨에서는 여파가 매우 컸고, 그 과정에서 PM, 엔지니어, 디자이너 사이에서 필요없는 마찰과 커뮤니케이션이 너무 많이 오고갔다. 에너지 소모 뿐만 아니라 프로젝트에 참여하는 동료들의 심리적인 상태마저 깎였다. 그래서 결과가 좋더라도 제품 릴리즈 이후의 후속 처리가 부드러울 수 없는 것은 변함없는 사실이어서 이 경험 덕분에 이런 류의 프로젝트를 알아차릴 수 있는 안목을 얻게 됐다.

odx-web-player

ODK, ODC, ODL(OnDemandLatino)에서 공통적으로 쓰일 수 있는 비디오 플레이어 라이브러리를 팀 매니저셨던 손병대님과 정희수님 그리고 토스에 같이 와서 일하고 있는 양성민과 같이 만들었는데, mau와 매출이 가장 크게 일어나는 ODK에서 사용하는 써드파티 플레이어의 연 라이센스 비용을 알고 크게 놀라서 전체 엔지니어링 회의때 왜 프론트엔드 엔지니어 놔두고 그런 비용을 계속 지출하는지 의문을 제기했다. 이때 같이 일했던 PM도 왜 따로 만들지 않는지 궁금해했다. 그렇게 이의 제기가 받아들여진건지 원래 계획이 있었는지 여러 스트리밍 서비스에서 사용할 수 있는 플레이어 프로젝트를 시작했다.

먼저 ODK에 붙이는 것을 목표로 했었기 때문에 ODK에서 사용하고 있던 엔터프라이즈용 플레이어의 기능을 모두 대응했어야 했다. 그래서 프로젝트의 첫 사이즈가 커질 수 밖에 없었다. 이때는 ODC의 케이스에 비교하기는 조금 애매했다. 애초에 매출을 많이 일으키는 서비스의 고비용 플레이어를 대체하는 것이 목표였기 때문이다. 그러다 결국 어떤 이유로(이것도 참 답답한데) ODK보다 영향 범위가 훨씬 적은 ODC에 먼저 적용하는 것이 좋겠다는 의견이 우세해져(이럴거면 처음부터 강하게 ODC에 적용해야 한다고 의견을 냈어야하지 않았을까?) 만들어놓은 기능들을 대부분 감춰두고 mvp 버전으로 우회해서 ODC에 적용하는 것을 통해 첫 릴리즈를 했다.

플레이어를 만들면서 비즈니스에 대해 생각하는 나의 생각에 대해 메타적으로 바라볼 기회가 있었다. 엔지니어들 입장에서는 연에 억단위의 라이센스 비용을 책정하는 플레이어의 기능을 한번 살펴보면 "이거 쓰려고 이 돈을 낸다고?" 할 수 밖에 없다. 나 또한 그런 생각이 강렬하게 먼저 떠올랐고, 그 생각이 사고 전체를 지배하고 있었기 때문에 다른 관점으로 사안을 바라볼 기회를 스스로 놓치고 있었다는 것을 깨달았다. 누구나 어떤 대상에 대해 생각할때 자신에게 익숙한, 쉽게 접근할 수 있는 한두개의 관점에서 접근하고 생각하고자 하는 강렬한 이끌림을 느끼게 되는데, 비즈니스를 하고자 하는 입장에선, 즉 창업가/사업가가 되고자 하는 입장에선 필히 그 이끌림이 다가오는 것을 인지하고 어색하지만 꼭 필요한 다른 관점들을 떠올리고 이걸 이용해 그 대상을 조명하고 종합적으로 이해하는 노력이 매우 중요하겠다는 생각을 했다. 아마 본인이 쉽게 사용하는 관점이 두어개 있다는 메타인지를 얻는 것이 사고능력을 개선할 수 있는 첫번째 스텝일 것 같다.

Business Oriented Engineer

ODK를 다니면서 조직과 비즈니스 관점에서 이런 결핍들을 겪다보니 Business Oriented Engineer 혹은 Product Engineer가 무엇인지, 그렇게 되려면 어떻게 해야하는지에 대해 생각해보게 됐다. 이런 결핍을 유독 크게 느꼈던 것은 아마 내가 조직과 비즈니스에 기술만큼 혹은 그 이상으로 관심을 갖고있기 때문일 것이다. 위기는 기회라고 했던가, 회사에서 입사일부터 퇴사일까지 매일 어떤 일을 했는지, 배경은 무엇인지, 어떻게 진행했고, 무슨 문제가 있어서 어떻게 해결했는지 등을 담은 일지를 매일 작성하고 있었고 결핍을 인지할때마다 일지와 엮어서 작성하고 있었기 때문에 내가 앞으로 무엇에 집중해야할지 명확하게 이해하고 있었다.

BOE - 조직 체계에 대한 이해

이전에도 기능조직에 대해서는 알고 있었으나 ODK에서 기능조직과 목적조직의 차이, 기능조직의 실질적인 장단점을 절실히 체감했다. 기능조직과 목적조직에 대한 설명은 많은 자료를 찾아볼 수 있어서 따로 언급하지는 않겠다. 각 체계는 그에 걸맞는 제도적, 문화적 뒷받침이 없으면 제대로 움직일 수 없다는 것도 이해하게 됐다. 산업에 따라, 기업의 사이즈에 따라, 서비스의 특성에 따라, 비즈니스 모델에 따라 적합한 체계가 존재할 수 있고, 두개 모두 가능해서 선택의 문제로 남을 수도 있겠다는 생각을 했다.

회사에서 벌어진 여러 문제들이 어떤 구조적인 이유로 발생하게 됐는지, 해결하려면 근본적으로 어느 부분부터 뜯어 고쳐야하는지 여러번에 걸쳐 문서를 재작성 해보면서 사고실험을 해봤고 나름대로의 해결책을 내봤다. 불행히도 애초에 대부분의 경영진이 미국에 있었고, 수직적인 조직 덕택에 bottom up 방식의 문제 해결은 어려운 환경을 갖고있었기에 손에 해결책을 들고 입맛만 다시는 상황이 자주 연출됐다. 불행인지 다행인지 이런 대략적인 수준의 방안을 경영진에게 피칭을 하게 됐고 최소한의 문제 의식은 전달이 된 것 같았다. 실제로 조직적인 문제가 어느 누구에게나 보이고 있었고 해결하려는 움직임은 조금씩 있었기 때문이다. 더 늦기전에 인생의 방향에 대한 결정을 해야했기 때문에 안타깝게도 이것이 받아들여지는지 끝까지 지켜보지 못하고 퇴사를 했다.

기능조직과 목적조직에 대해서 정리하고 나서 Harvard Business Review의 Organizational Choice: Product vs. Function을 뒤늦게 읽게 됐는데 이 주제에 대해 정말 정리가 잘 되어있어서 앞으로도 계속 참고하고 싶은 문서다. 조직 체계에 대해 쓸 내용이 더 많은데 이건 따로 글을 써야겠다.

BOE - 비즈니스 모델을 생각해보는 계기

생각해보면 웹 제품에 광고를 붙이는 건 매출을 일으킬 수 있는 매우 단순한 방법이다. 광고로 매출을 일으킬 수 있으려면 일단 플랫폼에 들어오는 사람의 수와 체류 시간이 유의미한 수준으로 있어야한다. 광고 매출 최적화는 그 뒤에 비교적 아주 적은 노력으로 쉽게 해낼 수 있는 문제다. 그런데 보통 웹 제품에 광고를 붙일때는 Amazon, Facebook, Google 3사의 광고 솔루션(Ad Exchange, GAM 같은)을 사용하게 되는데, 애초에 광고 도메인이 매우 복잡하기도 하고 그 복잡성이 솔루션의 GUI에서까지 느껴질 정도여서 Ad Exchange 같은 단순한 제품 이상을 사용하고자 한다면 아예 회사에 광고만 집행하는 직원이 있어야 제대로 운영을 할 수 있다.

광고 도메인은 용어부터 난해하기 짝이 없는데 이건 전에 쓴 GAM에 대한 글에서도 여실히 드러나고, 뭔가 등록하고 집행하고 분석하는 것도 복잡하다. 스크립트로 연동하는 것도 이렇게까지 해야하나 싶은 난해성이 있다. 그래서 BOE 관점에서 이런 생각과 질문을 해볼 수 있다.

• 만약 Ad Exchange 이상의 복잡한 타게팅과 정확도를 가진 광고 솔루션을 매우 쉽게 설정하고 연동할 수 있다면 돈을 기꺼이 내고 사용할만한 기업이 있을까?
  • 그런 고객들은 보통 어떤 서비스를 운영하는 기업일까?
• 광고팀을 따로 채용하지 않고서도 GAM 같은 복잡한 솔루션을 사용했을때의 매출의 80%라도 낼 수 있는 사용하기 쉬운 광고 솔루션을 만든다면 기업 입장에서 어느정도의 비용 절감 혹은 매출 상승 효과를 볼 수 있을까?
  • 어쩌면 이게 창업각일 수도?
• 설정과 연동을 쉽게 할 수 있는 광고 솔루션 제품을 새로 만든다면 Minimum Viable Product은 어떤 형태일까?
• 연동을 지금도 어렵게 하는데, 이미 연동해본 패턴을 활용해서 GPT를 래핑한 써드파티 라이브러리를 만드는 것이 의미가 있을까?
  • 적어도 광고를 직접 연동하는 개발자를 가진 기업에선 사용할 수도?

ODK에서 이런 식으로 어떻게 하면 가치를 만들 수 있을까, 매출을 일으킬 수 있을까 같은 생각을 자주 하게 됐다. 스트리밍 서비스니까 구독료를 받거나, 구독 레벨을 차별화 하거나, 단순한 광고 솔루션을 새로 만드는 것이 쉽게 생각할 수 있는 방안들이다. 만약 광고 솔루션을 인하우스로 개발해서 광고를 직접 수주 받게 되면 GAM에 내는 비용을 없애고 자체적인 효과 분석을 통해 매출 구조가 상당히 많이 개선될 수 있겠다는 생각을 했다. 물론 만드는 데에 들어가는 시간과 비용을 생각하면 단기간에는 어려울 수 있을 것이다. 근데 이 BM을 생각해보는 것에 대해서는 아무래도 이 회사의 주된 비즈니스 범위 내에서 생각하는 경향이 생기다보니 다른 종류의 비즈니스에 대해서까지 폭넓게 생각해볼 수는 없었다.

BOE - 일을 한다는 것에 대한 좀더 세밀한 시도와 경험

회사에서 하는 모든 행위와 이벤트에 대해서 이것이 타당한지, 지금 해야하는지, 정말 필요한 것인지 질문하는 습관이 생겼다. 그리고 그렇게 질문을 통해 내린 답을 한두명에게 또는 여러 채널을 통해 공유해서 문제의식을 공유하고 어떻게 해결할 수 있을지 생각해보게 됐다. 그렇게 점점 일을 위한 일을 하는 것에 대한 경계심을 갖게 됐다. 이전엔 이런 생각이나 시도를 해보지 못했었다.

"비즈니스나 회사에 필요하다고 생각되면 가리지 않고 뭐든 하는 것"에 대한 개념을 전부터 어렴풋이 생각하고 있었다. ODK에서 폭 넓게 이 경험을 해보지는 않았지만, 프런트엔드건, GAM에서 자잘하지만 누군가는 해야하는 설정을 한다던지, 백엔드 코드를 봐야한다던지, 뭐가 됐든 회사에 필요한 일을 가리지 않고 하려고 시도했고 이 경험들을 통해 지금 회사에 무엇이 필요한가를 알아보는 눈이 조금 생긴 것 같다.

하고있는 일의 진행 상황에 대한 주기적 혹은 잦은 공유를 시도했다. 이전에는 딱히 그런 공유를 계속 하진 않고 회의에서 내 차례가 오면 말하는 경우가 대다수였다. 작은 일이던 큰 일이던 무슨 내용의 작업이고, 왜 필요하고, 어떻게 진행할거고, 언제 마무리될지 등의 내용을 정리하고 공유를 생각날때마다 했는데, 이런 주기적인 정리와 공유가 생활화되면 커뮤니케이션 비용을 상당히 낮출 수 있다는 것을 알게 됐다. 그리고 공유를 위한 글을 쓰다보면 일에 대해서 더 선명하게 이해하고 더 오래 기억하게 된다.

"최대한 빠른 응답과 피드백"도 스타트업에서 일하는 사람이라면 이런 문화에서 한번쯤 일해봤을 법 한데, 이 부분은 재택 환경에서 비동기로 일하는 것이 거의 디폴트였다보니 즉각적인 응답을 필요로 하는 일 자체가 구조적으로 많이 생기지 않았다. 조직과 일하는 방식에 대한 피드백은 전체 회의에서 여러번 했지만 거의 받아들여진 적이 없어서 흥미를 느끼지 못했다. 개인적인 피드백도 거의 하지 못했는데, Scott H Young이 쓴 Ultra Learnging에서 이야기하는 피드백에서 얻을 수 있는 이점을 거의 얻지 못했다. 반기별로 개인 평가 같은 것을 팀에서 받기는 했지만 그것이 매우 구체적인 수준에서 작성된 피드백이 아니었고 세밀한 레벨의 피드백을 자연스럽게 주고 받는 환경이나 문화가 조성되어 있지 않았기 때문에 피드백의 양 자체가 적었다. 그래서 지금 생각해보면 이 부분은 아쉬운 점으로 남는다.

협업 지점에 있는 모든 포지션과의 커뮤니케이션을 정밀하게 다듬어보려는 시도를 했다. 백엔드 엔지니어, 디자이너, PM, QA와는 프런트엔드 엔지니어이기 때문에 자연스럽게 커뮤니케이션을 했다. 이전에도 해왔지만 상대와 내가 함께 논의하는 주제를 명확히 하고, 상대가 익숙해하는 혹은 이해하기 쉬운 방법으로 바로 핵심을 이야기하고 필요한 결론에 빠르게 다다르는 식으로 커뮤니케이션을 하려고 했다. 이런 연습 아닌 연습을 계속 하다보니 이젠 1시간 이상 넘어가는 회의를 정말 싫어하게 됐고, 필요한 논의가 끝났더라도 이 회의에서 어디까지 이야기하는 것이 좋을지, 불필요한 내용을 어떻게 교통 정리하고 마무리할지 생각하는 것이 편해졌다. 이런 맥락에서 PO가 어느 수준까지 생각하고 있는지, 제품을 위해서 어느 맥락까지 쳐내고 관리하는지를 계속 살펴보는 습관도 생기게 됐는데, 회의나 자리에서 빠르게 어떤 짤막한 논의를 해야할때 큰 도움이 되는 것을 느꼈다.

물론 회사가 새로운 사업을 한다던지, 기존 사업을 재정비 한다던지, 조직 개편을 한다던지 등의 여러 상황에 따라 오랜 시간 동안 진행하는 회의가 필요할 수도 있고 심지어 며칠 내내 회의만 해야하는 상황도 있다는 것을 알고 있지만 이런 경우는 제외하고 나머지 경우에서의 회의는 1시간이 넘어간다면 그건 이미 그 조직이, 팀이 뭘 해야할지 제대로 모르는 상황을 나타내는 신호라고 생각한다. 이런 경험과 회고를 바탕으로 현재 회사에서는 디자이너, 백엔드 엔지니어, 대고객팀, Sales, Account Manager, BDM과도 이런 식으로 전방위적으로 세밀한 커뮤니케이션을 하려고 하고있고, 그들의 업무 영역에 대해서 간략하게 설명해달라고 한 뒤 그들의 업무 맥락을 가능한 많이 파악하고 전체적인 그림을 그려보는 일을 해보려고 한다. 이 작업을 통해 커뮤니케이션 코스트를 꽤 많이 줄일 수 있을 거라고 예상하고 있고, 디자이너, PO, 백엔드 엔지니어와 제품의 범위를 정하고 제품을 만드는 상황에서도 그리고 미래에 창업가로서 일을 하게 될 순간에도 큰 도움이 되리라 생각한다.

2021~2022년이 커리어나 인생의 전환점인건지 점점 더 Comfort Zone을 벗어나는 시도를 많이 하고있는 것 같다.

조직 문화에 대한 좀 더 깊은 이해

위에서 조직 체계에 대해 다뤘고, 이전에도 조직에 대해서 SK에서 나는 무엇을 배웠나와 지난 3년의 기록: 대기업에서 스타트업으로 두 글에서도 다룬 적이 있었는데 지난 4년간 보다 깊게 이해할 수 있게 됐다. 여러가지가 있는데 가장 많이 생각했던 두가지가 높은 수준의 내부 의사결정 공유와 문제를 문제라고 말할 수 있는 문화다.

높은 수준의 내부 의사결정 공유

ODK에서 일하면서 높은 수준의 내부 의사결정 공유가 너무나 필요하다고 느꼈다. 엔지니어는 제품을 직접적으로 만드는 메이커 포지션 중 하나이고 조직 체계나 문화에 따라 제품에 대해 PO만큼 혹은 그 이상의 의견을 제시할 수 있다. 직접 만드는 포지션이다보니 이 제품이 회사의 목표와 미래에 왜 필요한지, 제품이 회사에 어떤 가치를 가져다줄 수 있는지, PO가 생각하는 이미지에 다다르기 위해서 어떤 기능들이 실질적으로 필요한지, MVP 관점에서 요구사항 중 어떤 것이 불필요한지, 제품을 위한 어떤 사업적, 법적, 조직적 의사결정이 이뤄지고 있고 그 근거가 무엇인지에 대해 충분히 이해하고자 하는 필요를 엔지니어가 강하게 느끼는 것은 자연스러운 일이다. 그런데 조직 체계와 문화상의 이유로 이런 니즈가 빈번하게 방해받는데, 방해의 빈도가 올라가고 이에 대한 이슈 제기가 받아들여지지 않게 되면 제품 릴리즈도 영향을 받고 메이커가 탈출하는 상황까지 심심찮게 연출된다. 만약 메이커가 여기에 대한 관심이나 이해가 없다면 문제되지 않지만, 보통이라고 부를 수 있는 조직적, 문화적 수준에 올라있는 스타트업에 종사하는 메이커들이 있는 곳이면 높은 수준의 의사결정 공유가 지켜지지 않는 점은 회사를 매우 위태롭게 만드는 요인이 될 수 있다.

왜 그럴까? 왜 의사결정이 공유되지 않는 상황이 회사를 위태롭게 만들까? 그걸 아는게 그렇게 중요한가? 중요하다. 애초에 스타트업에서 일하려는 많은 사람들은 회사에서 고농도로 일하며 회사와 개인, 커리어의 빠른 성장을 함께 경험하고자 하는데, 중요한 사업적 의사결정, 조직의 구성이나 체계에 대한 의사결정, 예산 집행의 근거에 대한 공유 등을 모르고서야 그런 고농도의 집중을 할 수 있을까? 맥락이 빠져있는데 그런 집중을 할 수는 없다. 그런 공유가 곧 일에 대한 맥락을 제공해주고 메이커들은 맥락에 따라 집중 정도와 우선순위를 판가름한다.

이런 의사결정 공유의 결핍을 강하게 느끼다보니 일에 점점 몰입하기 어려워지는 것을 느꼈다. 그래서 의사결정 공유를 위한 제도적 장치 혹은 문화를 가진 곳으로 가서 경험해야겠다는 다짐을 했다.

문제를 문제라고 말할 수 있는 문화 혹은 환경

앞서 말한 종류의 메이커라면 회사의 다양한 영역에서 일을 해나가면서 수많은 문제를 맞닥뜨리게 되는데, 그 문제는 구성원들의 심리적 문제부터 조직 체계, 제도, 문화적 문제까지 모두 포함한다. 이때 경영진이 이런 메이커와 상생 및 공존하면서 어떻게 회사와 구성원 모두 성장할 수 있을까를 고민하지 않는 경영진이라면 문제가 된다. 단순하게 이런 고민의 유무에 따라 메이커와 경영진을 4가지 경우로 나눠서 살펴보자. A는 고민을 안하는 경우, B는 고민을 하는 경우다.

• A 메이커 + A 경영진
  • 오히려 이 경우가 서로가 편할 수 있다. 창업한 사람이나, 그 사람이 뽑은 직원이나 회사와 비즈니스가 빠르게 성장하기 위해서 무엇이 필요한지, 지금 뭘 해야하는지, 조직 체계에 구멍이 없는지 등을 애초에 논의하지 않기 때문에 되면 되고 안되면 안되는대로 자리잡혀 있는 비즈니스를 그대로 이어나가면 된다.
  • 물론 이 케이스는 빠르게 성장하기에는 어려운 시스템과 환경을 갖고 있어서 드라마틱하게 회사가 stand out 하거나 성장하지는 않지만 마르지 않는 샘물 같은 BM을 갖고 있다면 연명하는 데에는 문제가 없을 것이다.
  • 그래서 이런 케이스는 스타트업에서는 비교적 찾아보기 어려운 것 같다. 애초에 BM이 확립된 상태에서 시작하는 스타트업이 매우 드물기 때문이다.
  • 뚜렷한 BM이 없이 top metric 같은 최상위 지표를 키우는 것을 목표로 하는 스타트업이 많기 때문에 스타트업계에선 B+B를 지향하는 경우를 심심찮게 볼 수 있다. 물론 지향은 하지만 난이도가 매우 높기 때문에 그걸 제대로 이뤄내고 있는 기업도 손에 꼽는다.
• A 메이커 + B 경영진
  • 이 경우라면 경영진 입장에서는 크게 두가지 선택을 내릴 수 있을 것 같다. 자신이 가진 B의 정신, 문화 및 지식을 메이커들로 하여금 스스로 깨닫게 하거나 전파 및 학습을 도와서 A에서 B로 옮기는 것이 첫번째고, 새로 채용될 사람부터 전보다 훨씬 엄격한 Culture Fit 기준을 적용해 메이커를 구성하는 것이 두번째다.
  • 이렇게 보면 Culture Fit 면접은 정말 엄청나게 중요한 면접 과정이다. 애초에 B+B 조합이 갖춰져야 메이커 입장에서도 제대로 일할 수 있고, 경영진 입장에서도 제대로 회사를 빠르게 키울 수 있기 때문이다. 이런 맥락에서 컬쳐 면접, 임원 면접을 쉬운 혹은 그거 그냥 하는 면접 정도로 생각하는 메이커라면 아마도 A일 확률이 높고, 그렇게 생각하는 경영진(창업자)이라면 수준있는 기업으로 성장시킬 가능성은 많이 떨어질 수 밖에 없을 것이다. IT에서 벗어나 조금만 눈을 돌려봐도 그저그런 기업이 수두룩 빽빽한걸 보면 A+B, B+A가 대부분을 차지하는 것처럼 보인다.
• B 메이커 + A 경영진
  • 이 경우에는 십중팔구 메이커가 짧게는 몇주에서 길게는 2~3년까지 다니다가 참다 못해 제발로 나가거나, 전부터 들어오던 타사 오퍼의 유혹을 이기지 못하고 자의반 타의반으로 나가게 된다. 이 경우에서 답답함을 느끼는 건 상대적으로 메이커이기 때문이다.
• B 메이커 + B 경영진
  • 만약 B+B 케이스라면 직원들이 인식한 온갖 종류의 문제를 어떤 채널로든 문제라고 말할 수 있는 분위기가 형성되고, 그 분위기가 지배적이면 직원의 근속년수, 제품의 릴리즈 속도, 제품 장애 대응 속도, 브랜드 인지도 평가, 매출과 영업이익, 조직문화건강 점수 등 회사의 상태를 나타내는 거의 모든 지표가 B+B가 아닌 기업에 비해 압도적으로 좋을 것이라고 생각한다. 그런 통계를 찾아보지 않아도 이건 쉽게 알 수 있는 부분이다.
  • 물론 B+B 케이스에서도 각각의 B가 어느 수준이 도달해있는지, 메이커와 경영진 사이의 관계에서도 radical candor, feedback loop 등이 얼마나 지켜지고 촘촘히 연결되어 있는지에 따라서 다양한 수준이 있을 것이다.

QWER.GG

ODK 입사와 거의 동시에 알마가 이미 대부분을 만들어놨던 qwer.gg 사이드 프로젝트에 참여하게 됐다. 나도 대학생때 League Of Legend를 많이 할때 사용했던 OPGG는 개인 전적을 확인할때 주로 썼던 곳인데 프로경기에 관련된 곳은 잘 알려지지 않거나 사라지고 있던 느낌이었다. QWER은 롤을 좋아하는 사람들이 모여 프로경기 일정, 경기 결과, 분석, 빌드 검색, 커뮤니티 등을 할 수 있는 제품이다.

챔피언, 아이템, 스킬들의 Tooltip, 경기 일정 페이지 UI 업데이트, 경기 결과 카카오톡 공유 같은 작은 것들을 개발했다. 도메인이 게임이다보니 아무래도 데이터의 depth가 깊고, 프로퍼티가 정말 많고, 같은 entity여도 어느 페이지에선 a, b, e, f만 쓰는가 하면 어느 페이지에선 거의 모든 프로퍼티를 쓰는 경우가 있었다. 거기에 한 경기 데이터를 먼저 불러오면 경기 entity에 딸린 팀, 챔피언, 스킬 등의 다른 entity pk를 활용해 연달아 API를 호출해야 했기 때문에 복잡한 페이지에선 최종 렌더링에 소요되는 API 호출이 10개가 넘는 곳도 있었다. 그래서 백엔드와 DB, 인프라까지 다 하던 알마가 GraphQL을 적용해보면 어떻겠냐고 제안해주셔서 2018년에 공부했던 기억을 더듬으며 작업을 시작했다. 어떻게 할까 고민하다가 백엔드에서 기존의 API를 살려두되 DB의 entity 기준으로 스키마를 만들고 리졸빙이 복잡한 경우엔 기존의 API를 호출하고 간단한 경우엔 Mongoose로 DB에서 데이터를 가져와 리졸버를 만드는 식으로 진행했다. 그렇게 백엔드에서 경기에 관련된 스키마와 리졸버를 먼저 만들어서 GraphQL endpoint를 뚫고, 프런트엔드에선 Apollo Client를 붙여서 경기 결과 페이지를 먼저 리팩토링 및 GraphQL로 마이그레이션을 했다.

원래 서비스는 정적 애셋이나 서버가 각각 다른 인프라에서 운영되고 있었는데, 백엔드의 배포 및 롤백의 편의성, 실험적인 이유 등으로 Kubernetes를 적용해보자는 이야기가 나왔다. k8s는 공부했던 적이 없고 GDG 커뮤니티에서 k8s 스터디를 지원해줘서 그때 다른 역할을 하는 서버 인스턴스 여러대를 GCP에 kubectl로 올려본 것이 전부였다. 어쨌든 사이드 프로젝트가 아니고서야 k8s를 프로덕션에서 해볼 일이 없을 것 같아서 전반적인 새 인프라 구성을 그림으로 그려본 뒤 구성을 Pod, Service, Deployment로 나눠보고 먼저 Minikube에서 돌려봤다. 뭔가 되는 것 같아서 이번엔 GCP 상에 테스트용 클러스터를 만들어놓고 올려봤는데 아니나 다를까 제대로 동작하지 않았다. 3년이 지나고 회고하는거라 잘 기억이 나지 않는데 기억을 더듬어보면, 그렇게 클러스터에 올려서 임시 도메인으로 브라우저에서 접근해보니 HTML만 제대로 가져오고 이미지, CSS 등의 나머지 정적 애셋들을 가져오지 못해서 레이아웃이나 디자인이 다 깨져서 렌더링이 됐었다. 알고보니 정적 애셋들을 다른 오리진에서 리버스 프록시로 가져오는 설정이 기존의 nginx config에 있었고, GCP에 기존 구성을 그대로 가져와서 생긴 문제였다. 여기서부터 과부하가 걸렸는지 어떻게 해야할지 도저히 떠오르지 않아서 진행한 것 까지만 yaml 파일을 만들어서 PR을 올려두고 문제 상황을 공유하고 QWER 동료들에게 도움을 요청했다. 그뒤에 알마가 해결해서 k8s로 모두 마이그레이션 하고 프로덕션으로 나가게 됐다. 이렇게 QWER에 GraphQL과 k8s를 제품의 아주 일부분에 적용하는 경험을 했고 대부분은 동료들의 도움으로 해결했다.

나름 롤에 20대의 2년을 갖다 바쳤을만큼 롤과 게임 산업에 관심과 열정이 있었음에도 QWER에 많이 기여하지는 못했다. 서비스에 필요하다고 생각하는 또는 개선해보고 싶은 기능을 만들거나 적용해보고 싶은 기술을 팀에 공유하고 리팩토링을 해보는 등 이것저것 적극적으로 해보고 싶었는데 당시에는 ODK에서 적응하고 ODC 등의 여러 상황에 긴장을 하고 있었는지 QWER에 마음만큼 적극적으로 임하지는 못해서 아쉬움이 남는다.

알마와 해리가 제품의 방향을 찾아나가는 모습이, 비즈니스 모델을 생각하고 이것저것 시도하는 모습이 인상적이었고 요새도 일하다보면 가끔 그들을 떠올리곤 한다. 열정을 담은 사이드 프로젝트로 시작해 구색을 갖춘 제품/회사로 거듭나는 과정을 보면서 예상하지 못했던 많은 것을 배웠다. 1년이라는 짧은 기간 동안 이런 재밌는 프로젝트를 같이 할 수 있어서 즐거웠고 그런 기회를 준 알마와 동료들에게 고마운 마음이 크다. QWER에 대한 더 자세한 내용은 QWER.GG 를 떠나보내며에서 더 알아볼 수 있다.

세번째 스타트업에서 네번째 스타트업으로

이렇게 지난 스타트업들을 다니면서 시도한 것, 집중한 것 그리고 성장한 것들이 있었다. 그중에서도 애착이 가는 것은 첫번째 스타트업이었던 Ncode와 세번째 스타트업이었던 ODK Media다. 가족의 걱정을 뒤로하고 입사했던 Ncode에선 처음 프런트엔드 엔지니어로 일했었기 때문에 환경과 기술, 사람 모든 것이 새로웠고 그것들을 최대한 흡수하느라 눈과 마음을 모두 열고 분주하게 살았다. 2016년 스물여섯, 인생의 가장 큰 베팅이었기에 그날의 날씨와 공기마저 기억난다.

ODK에서는 입사한 2019년 2월부터 오랜 기간 재택을 하면서 이렇게 일할 수도 있구나를 처음 배울 수 있었고, 엔지니어로서 조직과 비즈니스에 대해 가장 많은 생각과 경험을 하게 해주었다. 그렇게 얻은 건강한 결핍은 나로 하여금 명확한 다음 스텝을 찾게 했고, 그렇게 네번째 스타트업인 토스로 오게 됐다.

토스로 오기 전에 3년치 회고를 해놓았다. ODK에서 어떤 결핍을 느꼈는지, 그 결핍을 메우기 위해 무엇을 시도했고 결과는 어땠는지, 그 이유는 무엇인지, 그 원인을 개인 수준에서 해결할 수 있는지, 없다면 어느 수준에서 해결할 수 있는지를 정리했고 나 스스로 이걸 읽었을때 결론을 납득할 수 있을때까지 고쳐 썼다. 이 과정에서 내가 어떻게 일하는 사람인지도 보다 명확하게 파악하게 됐고 내가 파악한 토스는 어떤 회사인지, 그게 나와 어울릴 수 있는지를 생각하고 연결지을 수 있었다. 그리고 이게 자연스럽게 Culture Fit 면접에 대한 준비가 된 셈이었다.

입사하고 토스페이 제품을 맡아서 개발을 해오고 있고, 토스페이가 토스페이먼츠에서 토스코어로 다시 넘어온 뒤에도 계속 하고있다. 이외에 토스페이먼츠 블로그와 토스페이의 결제 맥락에 맞닿은 토스앱 내 웹 제품들도 개발했었다. 벌써 어려워보이지만 올해부터는 B2C에서 한발자국 물러나 토스페이의 B2B 제품을 만들어보고자 한다.

토스에 온지 10개월차에 접어들고 있는데 이 짧은 기간 동안 많은 것을 느꼈다. 확인하고 싶은, 경험하고 싶은 것들도 어느정도 해보았는데, 토스에 대해서는 더 시간을 보내고 다른 글로 회고를 하는게 좋겠다.

3년간의 재택 환경

ODK는 입사했을때 이미 재택근무가 가능한 환경이었고 사실 가능하다기 보다는 거의 재택근무가 기본 근무환경에 가까웠다. ODK에서 근무한 2019년 2월부터 2021년 4월까지 2년 3개월간 총 근무일수의 대부분을 재택근무를 했다. 그리고 토스에 입사한 2021년 5월부터 지금까지 재택근무를 필요에 따라 하고있다. 토스 같은 문화적 환경에서는 재택보다는 출근을 하는 것이 훨씬 재밌고 일에 집중하기에 좋다는 생각을 하고있는데 이것도 토스에 대한 회고를 할때 같이 다뤄야겠다.

3년이 조금 넘는 시간동안 재택근무를 해오면서 풀재택 혹은 재택근무가 유지될 수 있는 이유 혹은 유지시키는 방법을 나름대로 생각해보게 됐다. 우선, 조직적인 혹은 전사적인 합의가 이루어져있어야 한다. 그렇지 않으면 구심점 없이 누구는 출근을 하고 누구는 재택을 하게 돼서, 상대적으로 업무 경험에서 차이가 벌어지기 때문에 자그마한 불만이 표출 되더라도 재택이 불가능한 환경으로 쉽게 변모한다.

두번째로는 누가 어떤 일을 하고있는지, 진행 상황이 어떤지, 중간 결과가 어떤지, 언제까지 될 예정인지 등에 대한 정보를 누구나 쉽게 접근할 수 있어야하고 필요한 일이 있으면 어디에나 편하게 질문하고 답변하는 환경이 조성되어 있어야한다. 이런 정보가 공유가 되지 않으면 그리고 브로드캐스팅 될 수 없는 환경이면 불신이 쉽게 싹트게 된다. 정반대의 관점으로 접근해보면, 상황에 대한 수시로 공유하는 것은 직원들이 일하는 방식에 대한 믿음과 동료들에 대한 신뢰가 생길 수 있는 첫 기반을 마련해줄 수 있다. 공유 행위 자체가 중요하다기 보다는 그 공유를 통해서 신뢰가 생기기 때문에 재택 환경을 유지하려면 이런 것들이 뒷받침되어야 한다고 본다. 이런 공유 말고 신뢰를 만들 방법이 있다면 그것을 선택해도 무방할 것이다. 신뢰가 쌓인 뒤부터는 무슨 일을 하는지 언제라도 알 수 있고 필요에 따라 언제든 협업할 수 있기 때문에 오히려 수시로 공유하는 것이 점점 줄어들게 된다.

재택이 가능한 회사와 불가능한 회사에 대해 글을 썼었는데, 적어도 IT 산업에 속해있는 기업이라면 대부분 재택을 도입할 수 있다고 생각한다.

경제, 금융 그리고 부자의 사고방식 해킹

커리어 초기엔 기술들을 하나씩 공부하고 뭔가 만드는 것에서 큰 재미를 느꼈는데, 요새는 그것도 재밌지만 기업가, 무언가 자신의 힘으로 성취한 사람, 부를 이룬 사람 등 현명한 사람의 사고방식을 알아내 내 사고방식을 그에 근접하게 만드는 것에 훨씬 큰 재미를 느끼고 있다.

2019년 말부터 2020년 초까지 답답함과 부침을 많이 느꼈는데, 공부하고 싶은 것도, 연마하고 싶은 것도, 해보고싶은 것도 많이 있었음에도 계속 그런 감정을 느꼈다. 그게 뭔지 모르고 계속 지내다 우연히 2020년 1월에 금융을 공부하기 시작했는데, 이때 뭔가 답답하게 느껴졌던 여러 퍼즐들이 하나로 맞춰지는듯한 느낌을 받았다.

나는 무엇이 답답했을까? 이 시기엔 창업에 대한 막연한 생각만 갖고 있었고 금융에 대해서는 완전히 무지했다. 그래서 평소에 하던대로 인문학, 물리학, 심리학, 역사, 프랑스어 등의 책을 읽고, 기술을 공부하거나 코딩을 하는 식이었는데 이렇게 4년을 지내보니 이젠 흥미나 재미를 훨씬 덜 느끼게 됐다. 이제 뭘 해야할지 모르겠고 마치 원동력을 잃어버린 느낌이었다.

그렇게 1월부터 소득의 종류, 세법, 개인연금, 퇴직연금, 기업 활동, 주식 시장 등의 개념들을 세달 내내 공부했고 주변의 2~30대들이 생각보다 자신에게 필요한 금융 지식을 얻는 데 어려움을 느낀다는 걸 인지하고 이왕 하는거 전자책을 만들었다. 이 과정에서 내가 살던 세계, 내가 이해하고 있던 범위가 굉장히 협소했음을 느꼈다. 이후로 3월 말부터 주식 투자를 하면서 기업에 대한 리서치, 기업 활동, Cash Flow Statement, Balance Sheet을 파악하는 방법 등을 공부하면서 투자 대상으로서의 좋은 회사에 대해 정의를 해보는 일을 자주 하게 됐다. 이게 되게 재미있는 것이, 이 활동 자체가 자산을 증식할 수 있는 행위이면서도(나락을 갈 수도 있지만) 나의 판단들을 시험할 수 있는 장이기도 하고, 동시에 창업을 생각하는 것에도 연결이 된다. 그러니까, 원래는 독립적으로 따로 생각했던 일들이 하나로 연결되면서 이제 무엇을 알아보고 싶은지 자연스럽게 생각하게 되면서 멈춰있던 정신이 다시 뭔가를 탐구하게 됐다.

그렇게 부자의 사고방식으로 옮겨가기 프로젝트를 20년 초부터 시작하게 됐고, 지금까지도 아래의 내용들을 실행하고 있다.

• 신용카드 없애기
• 나의 Cash Flow Statement 만들기
• 부채를 천천히 줄이고 자산 늘리기
• 의미없이 타는 택시 줄이기
• 주식
  • The Little Book of Value Investing의 격언에 따라 주식 시장에 계속 머무르기
  • 복리 효과를 누리기 for at least 30 years
  • 확신이 부족할땐 개별 종목 보다는 ETF
  • 내가 모르는, 공감할 수 없는 사업을 하는 기업은 거들떠도 보지 않기
  • 리스크를 회피 대상이 아닌 관리 대상으로 바라보기

확실히, 나는 부자가 되는 것보다 거대한 부를 이룬 사람들의 사고방식을 내것으로 만드는 것이 훨씬 재밌다. 어쩌면 이 체화와 확인(feedback from reality)의 과정 자체를 즐기기 위해 Chris Guillebeau와 Ryan Daniel Moran 같은 많은 사람들이 연쇄 창업을 하는 것 같기도 하다.

읽은 책들

지난 4년도 책과 신문은 손에서 놓지 않았는데, 생각을 크게 바꿔준 책들을 추려봤다. 이렇게 회고록에서 읽은 책을 나열할게 아니라 각 책에 대한 리뷰를 따로 남겨야겠다.

• 룬샷
  • 근 10년간 읽은 책중 가장 재미있었고 충격적인 책이다. 전체를 보는 방법과 더불어 복잡계이론을 기업에 적용해서 풀어낸 거의 유일한 서적인 것 같다.
• Surely You're Joking, Mr. Feynman!
  • 가장 애정이 가는 책이다. 파인만의 생각하는 방식과 탐구 정신을 본받고 싶고, 그렇게 연구와 일에 몰두하면서도 주변 사람을 놓치지 않는 그를 사랑하며 롤 모델로 삼고있다.
• 전체를 보는 방법
  • 2017년에 읽은 책인데, 처음으로 일반적인 물리학을 넘어서서 복잡계 관점에서 자연현상과 사회를 관찰할 수 있게 해준 책이다. 이젠 일을 할때도 이 관점으로 결과를 해석하곤 한다.
• The Upheaval
  • 총, 균, 쇠 다음으로 종합적인 관점에서 세상을 바라보는 것이란 이런 것이구나를 느끼게 해준 제러드 다이아몬드의 역작이다. 국가와 개인에게 여러번 찾아오는 중대한 위기를 각각 어떻게 해결해나가고 그 스케일에서 비롯되는 차이와 예시를 촘촘하게 설명하고 있다. 리더라면 꼭 읽어야할 책이라고 생각한다.
• 월가의 영웅
  • 얼마나 공감할지는 모르겠지만, 앞서 언급한 The Little Book of Value Investing과 함께 가치투자란 무엇이며, 그보다 먼저 투자를 왜 해야하는가를 제대로 알려준 책이다. 아마도 트레이딩 보다는 가치있는 것을 찾아서 오랜 기간 지켜보는 걸 좋아하는 내 성격 때문에 이 책에 특히 공감하지 않았나 싶다.
• Principle
  • 레이 달리오는 본받고 싶은 현인 중 한명이다. 보이는 것을 넘어서 경제와 금융이 어떤 원리로 움직이는지를 자신의 경험들을 예로 들어 쉽게 설명한다. 특히 조직에서 Radical Transparency 혹은 Candor가 왜 중요하고 어떤 원리로 조직에 긍정적인 영향을 미치는지 이 책을 통해서 처음 알게되었다.
• 울트라 러닝
  • 그간 너무나도 비효율적인 방식으로 "학습"해오고 있었다는 것을 극적으로 알게해준 책이다. 지인들에게 많이 전파했는데, 올해는 정교한 학습을 바탕으로 컴포트존을 깨볼 생각이다.
• 팀장의 탄생
  • 앞서 언급한 HBR의 조직에 관한 아티클을 읽기 전에 읽은 책인데, 조직 체계는 그 자체로 완전할 수 없고 그에 걸맞는 문화와 제도적 뒷받침이 필수적이라는 사실을 알게해준 책이다.

2022

커리어와 개인적인 모든 경험에서 스스로에 대해 아쉬운 점, 부족한 점, 꼭 개선하고 싶은 점들이 항상 있어왔다. 그리고 지금까지 이런 점들을 개선하는 일을 해왔지만 결과는 매번 만족스럽지 않았다. 토스에 합류하면서 어떻게 하면 이것들을 효율적으로 개선할 수 있을까에 대해서 다른 방식으로 시도해볼까 하는데 아직 갈피는 못잡았다.

우선 "의도적인 불편함 만들기"를 아래처럼 계속 해볼 생각이다.

Goodbye, My Twenties

이렇게 나의 20대가 지나갔다. 엄청 치열하게는 아니었지만 추구하는 방향 안에서 항상 배움을 얻으며 살아왔다. 그리고 결과가 어떻게 되든 이렇게 도전한 것에 대해서 어떤 후회도 미련도 남지 않는다. 생각보다 다양한 경험을 하지 못하고 너무 빨리 20대가 지나가버린 것 같아 종종 슬픔이 찾아오지만 아무렴 어떤가 살고싶은 대로 살고있는데. 올 2022년도, 무슨 일이 펼쳐질지 모르는 30대도 온힘을 다해 보내자. 후회하지 않게.

2017~2021 Gallery