2020-12-29에세이

중니어 개발자의 2020년 회고

올해 2020년은 개인적으로든 전반적으로든 정말 다사다난했던 해였다. 특히 전 세계를 덮친 COVID-19로 인해 정말 많은 부분들이 바뀌었는데, 개인적으로는 사람을 많이 만나지 못 했던 게 조금 힘들었던 것 같다. (살면서 노래방을 이렇게 안 가본 게 처음…)

하지만 그 와중에도 이런 저런 일들을 많이 벌렸었는데, 그 중에는 성공한 것도 있지만 물론 실패한 것도 있었다. 하지만 실패했던 일이라도 나름의 배움을 얻었기 때문에 오히려 필자 스스로에게는 좋은 발전의 기회가 되었다고 생각한다.

이번 포스팅에서는 필자가 올해 겪었던 대표적인 일들을 한번 돌아보고 얻었던 러닝들을 회고하는 포스팅을 작성해보려고 한다.

토스에서 보냈던 1년

필자는 작년이었던 2019년 12월 9일에 토스라는 금융 플랫폼 서비스를 만드는 비바리퍼블리카에 입사했었다. 입사하자마자 보험 쪽 도메인을 다루는 인슈어텍 사일로에 배치되어 1년 동안 팀 이동없이 이 사일로에서 이루고자 하는 목표에 인볼브했었다.

BEP 달성했을 때 받았던 강철 플레이트

첫 출근했을 때를 떠올려보면, 필자의 자리에 딱 왔는데 기존에 있던 인슈어텍 사일로 팀원들이 굉장히 반겨주셨던 기억이 난다. 당시 인슈어텍 사일로는 프론트엔드가 공석이라, 프론트엔드 쪽을 건드려야 하는 일이 생기면 프로덕트 디자이너가 직접 마크업을 하거나 다른 사일로의 프론트엔드 개발자의 지원을 받고 있던 상황이었기 때문이다.

그래서 그런 기대들이 약간 부담스럽긴 했지만, 다들 필자가 잘 적응할 수 있도록 많이 도와주셨고 편하게 대해주셔서 빠르게 지난 히스토리들을 팔로우업하고 인슈어텍 사일로의 목표에 인볼브할 수 있었던 것 같다.

또한 토스팀은 다른 조직들에 비해 실패에 대해서 상당히 관대한 편이고, 이 실패에서 배운 러닝을 학습해서 다음 도전 때 써먹는 속도가 굉장히 빠르다. 그런 이유로 여기서 일하다보면 아이데이션, 의사결정, 개발, 배포, 결과 분석의 이터레이션이 쉴 새 없이 반복되기 때문에 재미도 있지만 상당히 정신이 없다.

그래서 그런지 다른 때보다 더 빠르게 지나간 한 해를 보냈던 것 같다.

레거시 코드 청산하기

입사 당시 필자가 맡았던 첫 제품은 보험과 관련된 내부 제품이었다. 당시 이 제품은 TDS(Toss Design System)도 붙어있지 않았고 워낙 급하게 개발된 제품이라 내부 설계도 탄탄한 편은 아닌데다가, 개발 환경이 토스의 다른 제품들과는 조금 다른 부분들이 있기도 해서 여러가지로 개선할만한 부분이 많은 제품이었다.

필자는 처음 어떤 제품을 맡게되면 그 제품의 커밋 히스토리를 한번 쭉 살펴보는데, 커밋 히스토리를 보면 이 제품이 비즈니스 맥락을 타고 오면서 개발이 되었었는지도 알 수 있고 필자 전에 이 제품을 맡았던 개발자가 어떤 방향의 설계를 하려고 했었는지도 대충은 알 수 있기 때문이다.

그리고 이 제품의 커밋 히스토리를 보고나서 가장 처음 든 생각은 “일정이 개 빡셌구나…” 하는 생각이었다. 보통 커밋을 보면 A기능에 대한 커밋들, B기능에 대한 커밋들처럼 개발되었던 기능 별로 어느 정도의 그룹을 나눠 볼 수 있는데 이 제품은 한 기능을 개발하고 다음 기능을 개발할 때의 텀이 굉장히 짧았고, 심지어 하루 안에 여러 개의 기능이 개발된 경우도 있었다.

하지만 늘 그렇듯이 빠르게 변하는 비즈니스 맥락을 따라 기능 개발을 진행하기도 바쁜 상황 속에서 리팩토링을 위한 시간을 따로 뺄 수는 없는 노릇이니, 최대한 보이스카웃 룰을 따르며 조금씩 리팩토링 할 수 밖에 없었다.

당시 필자의 리팩토링 목표는 그냥 이거였다.

토스에 있는 어떤 프론트엔드 개발자가 와서 이 제품을 맡더라도 위화감이 없도록 만들자!

필자는 작년 12월부터 올해 8월까지 대략 9개월 정도 이 제품을 맡았었는데, 당시에는 끝이 없을 것 같았던 리팩토링도 그냥 저냥 꾸준히 하다보니 어느 정도 성과가 있었던 것 같다.

처음 필자가 왔을 때는 배포도 수동으로 스크립트 돌려서 했었는데, 이제는 기능을 개발하고 PR을 올리고 CI/CD가 돌아가는 이 과정을 토스에 있는 다른 제품들과 동일하게 맞춰놓았기 때문에 다른 프론트엔드 개발자가 와서 이 제품을 만지더라도 동일한 개발 환경 안에서 기능 개발과 배포를 진행할 수 있게 만들어 놓았다.

또한 이 제품이 다루는 도메인의 특성은 모델 자체가 복잡하다는 것이었는데, 그에 따라 당연히 클라이언트 상태도 굉장히 복잡할 수 밖에 없었다. 당시 이 복잡한 상태를 전부 컨텍스트로 관리하고 있었기 때문에 컨텍스트는 상태를 담고 있는 객체와 상태를 변화시킬 dispatch 함수, 비동기 처리를 위한 또 다른 함수, 리듀서 등 이것저것 버무려져서 꽤나 복잡한 상태였다.

그래서 필자는 토스에서 많이 사용하고 있는 리덕스를 도입하고 비동기 처리를 하는 함수는 미들웨어로 따로 분리하고 스토어를 각 데이터의 도메인 별로 분리해서 그나마 조금 파악하기 쉽게 만들었었다. 뭐 사실 리덕스 도입 자체는 난이도가 높거나 그런 것도 아니고 리덕스를 붙혔다고 해도 여전히 상태 복잡도가 높긴 하지만, 토스 내의 다른 제품들과 개발 환경을 맞췄다는 의의가 더 크다고 생각한다.

그 외에 서버 상태와 클라이언트 상태를 싱크로나이즈해야하는 문제도 있었는데, 처음 이 제품을 개발할 당시에는 시간이 많지 않아서 1초에 한번씩 API를 호출하는 Poll 방식으로 개발이 되어있었다. 그래서 상태 변경도 1초에 한 번씩 발생했고, 설상가상으로 이 상태를 많은 컴포넌트들이 Context를 기반으로 Prop drilling을 통해 공유하고 있던 상태라 불필요한 렌더링도 1초에 한 번씩 발생하는 눈물나는 상황이었다.

그래서 리덕스와 react-redux가 제공하는 훅을 사용하여 렌더링 퍼포먼스를 개선하고 API를 Poll하던 부분도 Push 방식으로 변경하려고 했는데, 결국 리덕스 도입과 렌더링 최적화까지만 진행하고 이 제품을 필자 손에서 떠나보내게 되었다.

다행히도 필자 다음으로 이 제품을 맡아주신 FE 개발자에게 이 부분을 말씀드렸더니, 필자가 하려고 했던 작업의 방향에 공감해주셨고 이 분께서 최근 Poll 방식을 걷어내고 Push 방식으로 변경하며 리팩토링을 마무리해주셨다. (이 분 덕분에 마음의 짐을 하나 덜었다)

물론 여전히 아쉬운 부분들이 많기는 하지만, 그래도 처음에 비하면 많이 개선이 된 것 같아서 기분이 좋다. 이 제품 때문에 새벽에 퇴근한 적도 몇 번 있었고 기능 개발할 때마다 고생하기는 했지만, 그래도 9개월이나 애정을 가지고 만졌던 녀석이라 뭐랄까…약간 애증의 관계 같은 게 되어버린 것 같다.

#sig-주말작업 채널

필자는 회사 일 외에도 토이 프로젝트를 하기도 하고 블로그를 쓰기도 하기 때문에 주말에도 종종 친구들과 함께 모여서 같이 이쁜 카페에서 맛있는 것도 먹으며 같이 작업을 하곤 하는데, 이 이야기를 들은 어떤 분이 “그럼 그냥 토스 슬랙에 주말작업 채널을 만들어보는 건 어떰?”이라는 말씀을 해주셔서 토스팀 슬랙에 #sig-주말작업 채널을 만들었었다.

그렇게 열려서는 안 될 채널이 열려버렸고...

솔직히 채널을 만들 때만 해도 “몇 명이나 들어오겠어?”라는 생각을 하고 있었는데, 이 사람들이 도대체 어디서 냄새를 맡고 왔는지 여기저기서 막 채널에 들어오는 것이었다.

사실 필자는 전 직장에서도 “저랑 주말에 같이 작업하실 분?”이라는 제안을 많이 했던 편인데, 이 제안에 이렇게 적극적인 반응을 보이는 조직은 여기가 처음이었다. 그때 필자는 “이 사람들…진짜 일 좋아하는구나…”라는 생각을 했던 기억이 난다.

올해 4월, 양평에 있는 "강이다" 카페까지 가서 주말작업 하고 왔을 때

뭐 솔직히 저런 서울 교외에 있는 이쁜 카페에 가면 계속 일만 하는 건 아니다. 같이 경치도 보고 맛있는 것도 먹고 그냥 놀면서 작업도 하고 오는 것이다. 그래서 주말작업 멤버들이랑 같이 성수도 가고 양평도 가고 영종도도 가면서 재밌게 일했던 추억이 생겼다.

위에서 언급했던 Poll 방식을 Push 방식으로 변경하는 것도 일종의 사이드 프로젝트처럼 진행하던 일이라 당시 같은 사일로였던 백엔드 개발자와 주말에 홍대에서 만나서 진행했었다. 당시 한 1시간 정도 열띤 토론 끝에 각자 생각하는 방향성을 일치시키고 채널 인터페이스를 정의했었는데, 꽤 재미있었던 기억이 난다.

그 외에도 주말작업 멤버들이랑 같이 송도에 있는 터키 음식점에 갔었는데 한국인이 우리밖에 없어서 다들 외국온 기분이라고 하던 것도 재미있었고, 작업 마치고 회사 뒤에 있는 당구장가서 당구 내기 했던 것도 재미있었다.

최근 코로나 사태가 심각해지면서 예전처럼 주말에 만나서 작업하는 일이 없어지기는 했지만, 코로나가 조금 물러가면 이 채널도 다시 활성화되지 않을까 한다.

하나의 방향, 다양한 방법

어떤 회사든 일을 하다보면 의사결정을 해야하는 순간이 온다. 지금까지 필자가 경험했던 조직들은 조금 더 발언권이 센 누군가가 의사결정을 리딩하는 경우가 많았던 것 같은데, 토스팀은 딱히 발언권이 센 사람이라고 할 만한 게 없기 때문에 의사결정을 하는 과정에서 반드시 치열한 토론과 설득이 동반되었던 것 같다.

필자 또한 지난 1년 간 이런 토론을 굉장히 많이 했었는데, 확실히 처음 토스에 합류했을 때의 필자보다는 조금 더 다양한 부분들을 생각할 수 있는 시야를 가지게 된 것 같다는 생각이 든다.

개인적으로 이런 토론 과정에서 가장 많이 의견이 갈리는 주제는 Customer Centric 이라는 가치라고 생각한다. 아무래도 고객 중심이라는 가치가 추상적이다보니 사람마다 “이게 고객 중심이다”라고 생각하는 기준이 다르기 때문이다.

미팅하다보면 제일 많이 들리는 말

어떤 사람은 고객에게 가능한 많은 정보를 보여주고 자신에게 맞는 것을 입맛대로 찾을 수 있는 것이 고객 중심이라고 하는 사람도 있고, 또 어떤 사람은 고객에게 가장 필요한 정보만 보여주고 쓸데없는 고민을 하지 않게 만드는 것이 고객 중심이라고 하는 사람도 있다.

특히 Customer Centric은 토스팀에서 일하는 대부분의 사람들이 중요하게 생각하는 핵심 가치 중 하나이기 때문에 다들 자신이 생각하는 고객 중심이라는 가치관을 양보하기 어려운 것 같다. 실제로 여기서 일하다 보면 “이게 진짜 Customer Centric이 맞나요?” 라는 질문 자체를 상당히 많이 듣게 된다.

이렇게 서로에게 자신의 생각을 거침없이 말하는 조직에서 1년 동안 일을 하다보니, 비단 Customer Centric이 아니더라도 동일한 가치를 추구하지만 사람마다 그 가치를 이룩하기 위한 방법이 많이 다를 수도 있다는 것을 더 체감할 수 있었던 것 같다. 그리고 자연스럽게 이런 깨달음이 문제를 해결하는 방법을 다양한 각도에서 바라보는 것으로 이어지게 되었다.

6년 동안 같이 구르고 있는 루비콘

필자는 대학생 때부터 루비콘이라는 팀 활동을 해오고 있는데, 이게 뭐 거창한 건 아니고 처음에는 그냥 친구들끼리 모여서 만들고 싶은 것도 만들어 보고 같이 스터디도 하는 그런 팀이었다.

미팅 중인 루비콘 전우님들

이 팀을 처음 만든 게 2015년에 필자가 대학 복학했을 때 쯤이니 벌써 6년이나 이 사람들과 같이 구르고 있다. 사실 2019년에는 다들 회사일이 바빠서 같이 노는 것 외에 뭔가 활동을 하는 게 거의 없었는데, 2020년에는 함께 멘토링 프로젝트를 진행하게 되면서 다시 팀 분위기가 바빠지고 있다.

누군가를 멘토링 한다는 것

2020년 3월부터 루비콘 팀에서는 협업을 원활하게 할 수 있는 방법을 멘토링해주는 프로젝트를 시작했는데, 이 과정에서 개인적으로든 팀 단위로든 많은 실패와 러닝을 얻었던 것 같다.

사실 필자는 스스로에 대한 평가가 후한 사람이 아니다. 그래서 필자는 스스로 매일 채찍을 후려갈기면서 “아직 부족하다”를 매일 되뇌이면서 살고 있다. 이건 필자가 열정이 대단하다기보다 “이 정도면 잘 했지”라고 생각하는 순간, 성장을 하기 위한 노력을 안 하게 될 것 같다는 두려움 때문이기도 하다. (결국 이러다가 번아웃이 왔었지만, 습관은 잘 안 고쳐지더라…)

이번에 멘토링을 진행하면서 느낀 것 중에 하나는 필자가 이런 기준을 필자 스스로에게만 적용하는 것이 아니라 타인에게도 그대로 적용한다는 것이다.

필자는 실력이 좋고 나쁘고를 떠나서 항상 성장을 위해서 끊임없이 노력해야 한다고 생각한다. 그리고 이런 꾸준한 노력을 하기 위해서는 목표 설정과 동기 부여가 명확하게 되어있어야 한다.

그래서 필자는 개발자가 되기 이전에도 “내가 적당히 잘 하기도 하고 즐길 수도 있는 것”을 찾기 위해 비보잉, 작곡, 사운드 엔지니어링, 프로그래밍 등 최대한 다양한 것들을 경험하려고 했던 것 같다.

이게 필자가 지금까지 성장해온 방식이었기 때문에 당연히 이게 맞는 방법이라고 생각했다. 머리로만 각을 재봐야 아무 소용이 없으니 직접 몸을 움직여서 최대한 많은 도전을 해보고 결과를 본 다음 판단하고, 그 다음 도전을 이어나가는 방법 말이다. 그래서 멘토링을 할 때도 멘티들에게 이런 것들을 자주 이야기했었다.

멘티들이 회사일 때문에 프로젝트 진행이 힘들다, 실력이 안 늘어서 답답하다고 해도 잘 이해가 안 되었다. 솔직히 말해서 그냥 열정과 동기 부여가 부족한 것이라고 생각했었다. 그래서 필자는 멘티들에게 늘 이런 식으로 이야기했다.

에이 저도 했는데 여러분이 못 할 이유가 전혀 없어요. 한번 도전해보고 정 안 되면 그때 다시 얘기해보시죠!

회사를 다니면서 토이 프로젝트 할 시간이 부족하다는 건 당연한 거에요. 시간은 잠을 줄여서라도 스스로 만들어내셔야 해요.

절대 실력이 단기간에 빠르게 늘 수는 없으니 조바심 내지마세요. 그냥 꾸준히 하다보면 어느 순간 성장해있을거에요. 그러니까 하루에 조금씩이라도 코딩을 하시는 습관을 기르셔야 할 것 같아요. 힘들어도 견뎌보세요.

이건 뭐 말만 멘토지, 거의 프로 채찍러였다

사실 당시 필자가 했던 말들이 틀렸다고는 생각하지 않는다. 회사 일 때문에 개인적인 성장에 투자할 수 있는 물리적인 시간이 부족하다고 해서 회사 일을 하는 시간을 줄일 수는 없으니 그냥 잠을 줄이는 것이 나름 합리적인 방법이고, 아무리 힘들고 하기 싫어도 그 감정을 이겨내고 매일매일 조금씩이라도 꾸준히 수련을 하는 것이 실력을 늘릴 수 있는 가장 쉬운 방법이기 때문이다.

이렇게 3개월 동안의 멘토링을 진행하고나서 마지막 회고를 가졌는데, 당시 필자가 맡은 팀의 프론트엔드 개발자 분이 이런 얘기를 했었다.

동욱님이 해보라는 대로 잠을 줄이면서 토이 프로젝트를 했었는데, 잠이 부족하니까 계속 집중력도 흐려지고 몸 상태도 안 좋아졌었어요 😢

내색은 안했지만 이 말을 들었을 때 필자는 머리를 망치로 한 대 맞은 것 같았다. 그때서야 “아, 내가 그냥 저 분들보다 체력이 좋아서 그 미친 스케줄을 소화했던 거였구나”라는 생각이 들었다.

사람마다 학습을 효율적으로 할 수 있는 방법은 당연히 다를텐데 필자는 그냥 지난 6년 간 필자가 해왔던 방법이 맞다고 생각하고 무작정 들이밀었던 것이다. 물론 필자와 비슷한 방법의 성장 방법이 잘 맞는 분들도 있을 테지만 적어도 필자가 멘토링했던 분들은 이런 방법이 잘 맞는 분들이 아니었다.

결국 필자가 멘토로써 놓쳤던 중요한 것은 바로 공감과 다름이었다. 필자는 멘티들이 힘들다고 했을 때 그 문제에 대해 공감하고 함께 해결하려고 했던 것이 아니라, 그것들을 그저 투정이나 아마추어리즘으로 치부하고 스스로를 더 극한으로 몰아붙혀서라도 프로젝트를 제대로 마무리하는 것만을 강조했었다. (그리고 스스로 뭔가 꼰대 같다는 생각이 들어서 이걸 깨닫고 한동안 우울했었다)

여러분이 힘들다고 일을 안 하는 것이 반복되면 팀원들의 신뢰도 점점 사라질 것이다. 이 팀에는 프론트엔드, 백엔드, 디자이너가 1명씩 밖에 없으니 여러분이 한 명이라도 일을 안하면 프로젝트는 드랍된다. 책임감을 가져라. 동료에게 신뢰를 줘라. 같은 말들과 함께 말이다.

물론 이 말들이 틀렸다고 하기는 어렵지만 이런 식으로 밀어 붙히기만 하는 멘토는 좋은 멘토가 아니라 그냥 혼만 내는 선생님에 가깝다. 멘토라고 하면 멘티들의 모랄과 동기 부여도 어느 정도 해줄 수 있어야했는데, 필자는 그런 것보다 프로젝트를 런칭하는 것 자체에만 너무 포커싱했었다.

그래서 저번 달 까지도 필자는 계속 이 문제에 대한 해답을 고민하고 있었다. 마침 회사에서도 “개인의 성장 뿐 아니라 팀의 성장까지 생각할 수 있는 사람이 되어달라”는 피드백을 받았기 때문에 더욱 더 이 문제에 대한 해답을 찾고 싶었다.

하지만 아직도 잘 모르겠다. 무턱대고 공감만 해주는 것이 절대 멘티들의 성장에 도움이 될 것 같지는 않고, 그렇다고 채찍만 후려치는 것도 도움이 안 되는 건 마찬가지다.

결국 상대방에게 어떤 성장 방법이 잘 맞는 지 파악하고 그 분에게 적절한 동기 부여와 조언을 해주고 포텐셜을 끌어올려줘야 하는데, 컴퓨터면 몰라도 사람을 분석한다는 건 필자에게 아직 너무 어려운 일인 것 같다.

그 동안 다들 많이 굴렀구나…

사실 그 동안 루비콘 팀에서 했던 일에 대한 회고는 몇 번 했던 적이 있지만 이 팀 자체에 대한 회고는 별로 생각이 없었는데, 최근 오랜만에 이 친구들과 함께 진행하는 일이 많아지면서 예전에는 들지 않았던 몇 가지 생각들이 들기 시작했다.

앞서 이야기했던 멘토링 프로젝트를 진행하며 오랜만에 친구들과 제대로 된 일을 벌이기 시작했는데, 이렇게 친구들과 일을 하면서 최근 느낀 감정은 “다들 많이 구르긴 했구나…”하는 것이었다. (새삼스럽지만 말이다)

지금은 대부분 5~6년 정도의 경력을 가진 직장인들이 되었지만, 예전 대학생 때를 돌이켜보면 이 팀은 그냥 진짜 초짜들 모임이었다. 뭔가 토이 프로젝트 팀이라기보다 그냥 친구들 모임에 가까운 느낌이랄까. 제대로 협업하는 방법도 몰라서 맨날 싸웠었다.

물론 학기 중이든 방학 때든 매일매일 동국대학교 반야관 지하에 모여서 함께 아이데이션도 하고 개발도 하고 디자인도 하기는 했지만, 사실 그 시절에는 그냥 얘네랑 개발하는 것보다는 같이 노는 게 더 재밌었던 것 같다. 피씨방가서 게임도 몇 판 조지고 술도 마시고 당구장도 가고 노래방도 가고 가끔은 서로 욕도 해주고 그렇게 말이다.

그러다가 올해부터 갑자기 팀에 일이 많아지면서 협업의 양이 확 늘었는데, 여기저기서 빵빵 터지는 문제를 다들 알아서 척척 해결하는 모습들을 보고 있자니 조금 기분이 이상했던 것 같다. 내 기억 속의 루비콘은 삽질도 많이 하고 방법도 몰라서 매일 구글링하느라 시간 다 보내는 그런 팀이었는데, 어느 샌가 이 팀에서 일하고 있으면 그냥 회사에서 일 하는 것과 비슷한 느낌이 들 정도로 일의 진행이 스무스하다는 생각이 들기 시작했다.

최근에는 serverless 프레임워크로 만든 어플리케이션을 배포하다가 실수로 멘토링 프로젝트 신청자 데이터가 담긴 DB 테이블이 지워지는 대형 사고가 터졌었는데 나중에 알고보니 DevOps 역할을 맡고 있는 친구가 평소에 백업을 계속 하고 있어서 별 탈 없이 지나갔던 일도 있었고, 멘토링 프로젝트를 진행하면서 생겼던 프로젝트의 방향성이나 루비콘 팀의 아젠다와 같이 거시적인 가치관이 싱크되지 않아서 마찰이 생겼을 때도 각자의 의견을 잘 조율해서 해결했던 기억도 있다.

백업을 생활화합시다... 아찔했던 그 날의 기억

각자 걸어온 길은 조금씩 달라도 6년이나 실무에서 굴렀으니 대학생 때보다 성장한 지금이 당연한 것이라고 생각할 수도 있지만, 요즘 들어 유난히 예전 대학생 시절에 삽질했던 추억들이 생각나는 것 같다. 얼마 전에는 루비콘 친구 2명이랑 강남에서 오마카세를 먹었는데 어릴 때 같이 한솥도시락이나 짜장면 시켜먹던 게 생각나서 기분이 이상하더라.

앞으로도 이 친구들과 함께 루비콘 팀의 슬로건인 Growth and Share에 걸맞게 우리가 가지고 있는 것들을 다른 사람들에게 나누어줄 수 있는 다양한 활동을 했으면 좋겠다. ~~(팀 네임 밸류 키우자 짜식들아)~~

블로그 회고

필자는 작년 6월부터 블로그를 꾸준히 쓰고 있었는데, 지금까지 단편적으로 데이터를 보긴 했어도 처음부터 오늘까지의 전체적인 데이터를 본 적은 없었다. 그래서 이번에는 블로그에 대한 내용도 조금 공유해볼까 한다.

사실 필자는 블로그에 Google Analytics나 Amplitude 같은 이벤트 트래킹 솔루션을 연동시켜놓고 사람들의 행태를 관찰하고 있었다. (이렇게 말하니까 왠지 민간인 사찰 같다)

아무래도 이 블로그는 커머셜 서비스도 아니고 그냥 필자의 취미 공간이기 때문에 굳이 데이터 분석에 딥다이브할 필요는 없다. 그래서 그냥 필자의 블로그를 찾아주시는 독자 분들이 어떤 것에 관심을 가지고 있으며 어떤 정보를 얻어가는 지를 알아보는 정도로만 사용하고 있다.

블로그 방문자와 이탈율

필자는 작년인 2019년 6월부터 본격적으로 블로깅을 하기 시작했으니, 2019년 1월부터 지금 이 포스팅을 쓰고 있는 2020년 12월 30일까지의 블로그 방문에 대한 데이터를 한번 살펴보면 좋을 것 같다.

필자가 처음 블로그 활동을 본격적으로 시작하기 전인 2019년 5월에는 한 달 방문자 수가 60명 정도였는데, 블로그 활동을 본격적으로 시작한 2019년 6월은 4,000명 정도로 증가했다.

이때 뭔가 특별히 좋은 글을 썼다기보다 2019년 6월에만 9개의 포스팅을 올렸기 때문에 아마 유입량이 이 정도까지 드라마틱하게 늘지 않았나 싶다. 그리고 2020년 12월 현재는 한 달 방문자 수가 20,000명 정도, 총 페이지뷰 수는 470,000 정도 된다.

이 데이터에서 특이한 점은 이탈율이 64.94% 밖에 되지 않는다는 것인데, 사실 보통 블로그처럼 정보 전달을 목적으로 하는 서비스는 사용자가 원하는 정보를 취득한 시점에서 바로 이탈이 일어나는 경우가 높다. 그래서 블로그치고 이 정도 이탈율이면 나름 선방했다고 본다.

하지만 그렇다고 이탈율을 그냥 포기하기에는 조금 아쉬운 부분이 아직 남아있는데, 바로 이 데이터 때문이다.

이 차트는 지난 30일 동안 사용자가 블로그 포스팅을 한번 보고나서 다른 포스팅을 다시 보는 비율을 나타내는 차트이다. 맨 왼쪽에 있는 차트가 1개의 포스팅을 본 유저의 수이고 오른쪽있는 차트들은 2개, 3개, 4개, 5개의 포스팅을 본 유저의 수를 나타낸 것이다.

대충 차트만 봐도 맨 왼쪽의 차트에서 두 번째 차트로 넘어갈 때 유저의 수가 확 줄어드는 것을 볼 수 있는데, 이는 포스팅을 하나만 보고 이탈하는 유저가 그만큼 많다는 것을 의미한다.

여기까지는 아까 말했듯이 블로그라는 서비스의 특성 상 이탈율이 높은 것이 당연하기 때문에 이상할 것이 없지만, 재밌는 것은 저 퍼널들을 통과하는 사람들의 퍼센테이지가 점점 높아진다는 점이다.

post1	post2	post3	post4	post5
100%	16.9%	37%	51%	62.3%

post1은 포스팅 한 개를 본 사람들이고 이 수치를 100%으로 잡았다. post{n} 컬럼은 각각 앞 퍼널에서 넘어온 사람의 숫자의 퍼센테이지를 나타낸 것이다.

즉, post2는 처음 포스팅 하나를 읽고나서 두 번째 포스팅까지 읽는 사람이 16.9% 밖에 되지 않는다는 것을 의미한다. 마찬가지로 post3는 두 번째 포스팅까지 읽은 사람이 세 번째 포스팅까지 읽을 확률이 37%라는 것을 의미한다.

그런데 가만 보면 두 번째 포스팅을 읽은 이후로는 점점 숫자가 올라간다. 즉, 포스팅을 읽으면 읽을 수록 더 필자 블로그에 흥미를 느껴서 더 많은 포스팅을 다시 읽을 확률이 높아진다는 것이다.

그래서 필자는 이 데이터를 보고 이탈율을 개선해보려고 관련 포스팅도 넣어보고 태그 별로 묶어서 보여주기도 해보는 등 이런 저런 시도를 해보았는데, 결론만 말하자면 다 망했다. 이건 나중에 시간이 되면 조금 더 분석해보고 테스트를 돌려봐도 좋을 것 같다.

방문자 세그먼트

필자의 블로그는 기술과 관련된 내용이 많다보니 아무래도 필자 블로그의 유저 세그먼트는 IT업계에서 기술과 관련된 일을 하시는 분들로 제한된다. (가끔 마케터 분들이 GTM 포스팅을 타고 들어오시기도 한다)

토요일은 다들 쉬시는 것 같은데 일요일은 도대체 왜 들어오시는...?

이 도표는 진하게 표시될 수록 값이 크다는 것을 의미한다. 즉, 필자 블로그의 방문자들은 주로 평일 오전 8시부터 오전 12시 사이에 많이 접속하는데, 이는 아마 업무 중에 막히는 문제를 구글링하다가 필자의 블로그를 발견하고 접속하는 것으로 추정된다.

사실 하나하나 살펴보면 실질적으로 주말이라고 볼 수 있는 금요일 오후 7시부터 일요일 오후 11시까지는 진하게 표시된 부분이라고 해도 옅은 부분과 값이 크게 차이나지 않는다. 그냥 값이 1500을 넘어서 색이 저렇게 보이는 것 뿐이지 실제로 보면 저 시간대에는 1400 ~ 1600 사이의 값이 유지된다.

이런 것들을 보면 유저들이 필자의 블로그를 킬링타임용이 아닌 실무적인 부분에서 도움을 얻기 위한 목적으로 많이 방문하는 것이라는 가설을 세워볼 수 있을 것 같다.

그리고 또 다른 유저 세그먼트의 팩터로는 연령대와 성별이 있는데, 이건 아마 여러분들도 대충 예상이 가능할 것이라고 생각된다.

물론 예전에 비하면 개발 직군의 성비가 많이 좋아지기는 했지만 아직까지는 여전히 남초 직군이다. 필자의 블로그를 방문하는 사람들 역시도 남성이 77.7%, 여성이 22.3%로 남성의 비율이 훨씬 높은 것을 볼 수 있으며, 주 연령대는 25세 ~ 34세인 분들이 가장 많다는 것을 알 수 있다.

즉, 필자의 블로그를 주로 사용하는 사용자의 메인 페르소나는 20대 후반이나 30대 초반의 남성 개발자라고 생각해도 될 것이다. 물론 필자가 이 유저 세그먼트를 타겟으로 마케팅을 하거나 이벤트를 할 것도 아니고 그냥 기술적인 정보를 작성하는 블로그를 운영하는 것 뿐이기 때문에 크게 의미는 없는 분석이기는 하다.

검색 유입 키워드

대부분의 블로그가 그렇겠지만 필자의 블로그 또한 구글 같은 검색 엔진에서 흘러들어오는 오가닉 트래픽 유입으로 먹고 산다. Google Analytics의 채널 유입 데이터를 봐도 오가닉 트래픽이 50% 이상 차지하고 있는 것을 볼 수 있다.

1위인 오가닉 유입이 50.6%이고 2위인 SNS 채널 유입은 21.7%이다.

이런 상황이다보니 아무래도 사람들이 어떤 검색어를 통해 필자의 블로그로 유입되는지에 대한 관심이 생길 수 밖에 없는데, 이 데이터는 Google Analytics보다는 Search Console에서 더 자세히 볼 수 있다.

검색 결과 노출과 클릭 수는 우상향을 그리고 있지만, 정작 CTR은 잘 성장하지 않는다

필자의 블로그는 작년 1월부터 지금까지 총 1,800,000회 정도 검색 결과에 노출되었고 그 중 125,000회 정도 클릭되었다. 지금까지의 평균 CTR은 7% 정도이다.

그리고 차트의 맨 오른쪽 부분을 보면 지표가 쭉 떨어진 부분을 볼 수 있는데, 이렇게 연말에 지표가 하락하는 추세는 작년에도 동일하게 나타났었다.

작년에 이걸 보았을 때는 연말이라 약속이 많아서 떨어졌을 거라고 생각했는데, 코로나 때문에 약속을 잡지 못 하는 올해에도 마찬가지인 것을 보면 약속이 있든 없든 연말에 일을 많이 하지는 않는 것 같다.

최근 구글은 이런 데이터들을 정리해서 요약본으로 보여주는 Search Console Insights라는 기능을 런칭했는데, 확실히 여기서 보면 최근 한 달동안 사람들이 어떤 검색어를 통해 필자의 블로그로 많이 들어왔는지, 어떤 사이트에서 필자의 블로그를 백링크로 걸었는 지를 한 눈에 볼 수 있어서 편하다.

역시 부동의 1위는 CORS...

위 데이터에서도 알 수 있듯이 필자의 블로그로 유입되는 검색 키워드 상위 5개 중 4개가 CORS 정책 위반과 관련된 키워드이다.

실제로 CORS는 왜 이렇게 우리를 힘들게 하는걸까? 포스팅은 올해 5월에 처음 썼을 때부터 지금까지 꾸준히 트래픽이 유입되는 포스팅인데, 그 만큼 많은 사람들이 CORS 정책 위반을 해결하는 데 어려움을 겪고 있다는 것을 알 수 있다.

그리고 중간에 있는 backpropagation 키워드는 2018년에 작성했던 [Deep Learning 시리즈] Backpropagation, 역전파 알아보기 포스팅으로 이어지는데, 아마 머신러닝의 기초인 역전파 알고리즘을 하나하나 직접 손으로 풀고 코드로 포팅했던 내용이 머신러닝을 입문하시는 분들에게 도움이 되었나보다.

이외에도 HTTP3나 TCP, Git, 수학 같이 프로그래밍과 직접적으로 연관을 가진 주제들의 포스팅들이 주로 상위권을 차지하고 있고 비전공 개발자라던가 비즈니스에 대한 철학과 같은 포스팅은 상대적으로 밀리는 추세를 보이고 있다.

인프런 강의를 준비해보자!

작년에 작성했던 회고인 20대의 마지막, 2019년을 돌아보며라는 포스팅에서 2020년에는 발표나 강의를 도전해보고 싶다고 했었는데, 드디어 얼마 전부터 강의를 준비하게 되었다.

필자 주변에 개발자 3대 허언이 토이 프로젝트, 이직, 유튜브나 인프런이라고 말씀하시는 분이 있는데, 필자도 2020년 내내 허언만 하다가 2020년이 다 끝나갈 때가 되어서야 이 도전을 시작하게 되었다.

허언을 현실로 만들기 위해 한번 도전해보려고 한다

일단 강의 커리큘럼은 저번 주 쯤에 모두 작성했고 이제 대본을 작성하고 있는데, 이게 또 블로그나 책을 쓸 때와는 다른 느낌의 글쓰기라 여러가지로 난항을 겪고 있다. 아무래도 대본이다보니 문어체가 아니라 구어체로 작성해야 나중에 읽기가 편한데, 자꾸 습관처럼 문어체로 작성하게 되어서 막상 읽어보면 너무 딱딱한 글이 되어버리는 경우가 잦은 것 같다. (혼자 강의 원맨쇼하면서 쓰면 조금 잘 되는 것 같기도…?)

물론 아직 대본을 다 작성하려면 멀었지만, 시간이 조금 걸리더라도 꾸준히 매일매일 작성하는 걸 목표로 하고 있으니 언젠가는 끝낼 수 있지 않을까? 솔직히 반 정도만 쓰고나면 중간에 아무리 힘이 들더라도 지금까지 쓴 게 아까워서 무조건 끝낼 수 밖에 없다.

2020년을 떠나보내며

이번 2020년을 돌아보니 뭔가 드라마틱한 도전이 많지는 않았던 것 같다. 굳이 꼽자면 멘토링 프로젝트 정도랄까…?

올해 6월에는 성수 카우앤독에서 멘토링 데모데이도 진행했었다

사실 멘토링 하나만 해도 육체적으로나 정신적으로나 너무 힘들어서 다른 것을 할 엄두가 도저히 나지 않았다. 필자는 멘토링이라는 행위 자체가 이번이 처음이었기 때문에, 누군가에게 관심을 가지고 리딩을 한다는 것이 이렇게 리소스가 많이 드는 일이라는 사실을 몰랐었다.

지금까지의 필자는 나의 성장만 챙기는 개발자였다. 소프트 스킬이든 하드 스킬이든 각자의 성장은 각자가 알아서 챙겨야하는 부분이라고 생각했다. 그러면 결국 개인의 성장이 팀의 성장으로 이어질 수 있으니까. 만약 다른 팀원만큼 성장하지 못 하는 팀원이 있다면 당연히 최선을 다해서 도와줘야겠지만, 그렇게 도와줘도 끝까지 따라오지 못 한다면 최후에는 손절하는 것이 맞다고 생각했다.

하지만 이번 멘토링을 하면서 이런 생각이 틀렸을 수도 있다는 의심이 싹트기 시작했던 것 같다. 그냥 막연하게 도와주는 것이 정답이 아닌 것이다. 누가 어떤 방법으로 리딩하고 멘토링하냐에 따라서 이 사람의 포텐셜이 터져나올 수도 있고 그대로 죽어버릴 수도 있다는 생각이 들기 시작했다.

필자도 이제 점점 경력이 쌓여감에 따라 누군가에게는 멘토가 될 수도 있고, 누군가에게는 롤모델이 될 수도 있으며 혹은 어떤 팀을 이끄는 리더가 될 수도 있을텐데, 이런 상황이 되었을 때 필자가 그 역할을 제대로 수행할 수 있을지에 대한 깊은 고민이 슬슬 필요한 시점이 된 것 같다.

언제까지고 나의 성장만 챙기는 개발자일수는 없다. 이제는 나 스스로 뿐만 아니라 조직의 성장까지도 살펴볼 수 있어야 한다.

그래서 최근 주변 개발자들과 “시니어 개발자란 무엇일까?”와 같은 주제에 대해서 이야기를 나눠보기도 하고, 함께 자라기라는 책을 추천받아서 읽어보기도 하고 있지만 아직 뭐가 맞는 방법인지에 대한 해답을 찾지는 못 했다.

2020년에는 결국 이렇게 답을 찾지 못한 질문으로 회고를 마무리하지만, 내년 2021년 회고에는 이 질문과 고민에 대한 답을 찾아서 회고에 적는 것을 목표로 잡아야겠다.