#이직
#결혼식
#번아웃
#해피엔딩
2022년은 호기롭게 이직준비와 결혼준비를 동시에 한 해였다. 모든 걸 끝마치고는 갑자기 번아웃이 세게 왔었다. 지금은 다행히 회복했다. 정말 다사다난한 해였다. 그게 2022년의 요약이다.
그랬다. 작년에 몇몇 개발자분들의 회고를 흥미롭게 읽었고, 올해도 어김없이 그분들의 회고가 기다려졌다. 기다리지만 말고 올해부터는 나도 회고 쓰는 사람이 되어보기로 했다.
—
상반기: "더 이상은 NAVER(?)"
상반기까지는 네이버에 있었다. 2016년초부터 다녔으니 햇수로는 올해가 7년째였다. 많은 사람들이 내가 여기서 무언가 결여를 느껴서 이직을 했을 것이라 추측하곤 하는데 오히려 그 반대였다. 재직중 만족도로 치면 올해가 1~2번째로 뽑을 수 있는 연도였을 정도로 정말 재미있게 다녔었다.
기억에 남는 프로젝트
무엇보다 프로젝트가 아주 흥미로웠다. 한마디로 네이버쇼핑 검색 서비스의 플랫폼 체질을 개선하는 완전한 개발 과제였다. 체질 개선이라는 표현이 잘 와닿지 않을 것 같아서 간략하게 소개하자면 …(생략)…이다. 적다보니까 결국 백엔드 개발자가 아니면 설명을 읽어봐도 안 와닿는 건 매한가지일 것 같아서 생략했으니 궁금하신 분들은 아래의 화살표를 눌러 펼쳐 보시면 되겠다.
가장 기억에 남는 프로젝트: 네이버쇼핑 노출용 데이터 파이프라인 구축
- 한마디로, Read 해오기에 가장 적합한 형태로 데이터를 미리 가공해놓는 과정을 신규 구축하는 과제였다.
- 조금 더 구체적으로는, 네이버쇼핑에서 사용하는 메인DB인 PostgreSQL에서 발생한 원천 데이터의 변경사항(Create/Update/Delete)을 CDC 형태로 Kafka에 전부 연동 받고 Worker 애플리케이션단에서 서비스 노출에 적합한 형태로 Denormalize한 뒤 MongoDB와 Redis에 Eventually consistency하게 싱크해놓는 것이라고 설명할 수 있겠다. 이로써, 서비스에 노출할 때에는 단순히 읽어온 그대로 서빙만 하면 되는 것이다.
- 메인DB와 디커플링된 별개의 노출용DB를 만듦으로써 서비스 안정성, 효과적인 데이터 서빙 두마리 토끼를 잡고자 했다. (이 외에도 이 프로젝트의 의도, 설계 과정, 기대 효과 등을 설명하려면 이 회고 글 만큼의 분량이 추가로 필요하기 때문에 그건 나중에 따로 다루고, 여기서는 이쯤에서 생략하고자 한다.)
이 프로젝트는, 돌이켜보면 내 개발 커리어에 큰 전환점이었던 것 같다. 단순히 특정 feature의 백엔드 혹은 프론트엔드를 담당해서 요구사항을 구현해내는 형태가 아니라, 플랫폼 관점에서 전체적인 시스템을 설계하고 요구사항을 스스로 만들어내면서 구현해나가는 경험을 했고 결과적으로 프로덕트를 바라보는 시야가 확 달라졌다고 느꼈다. 기획 경력이 있으니 좀더 유저향 feature 개발이 적성에 맞을 거라는 막연한 추측이 있었지만 이러한 백엔드 시스템 개발도 무척이나 적성에 잘 맞다고 느꼈던 점이 무엇보다 내가 얻은 가장 큰 수확이었다.
2022 NAVER Engineering Day 발표
플랫폼적으로 의미있는 도전을 했던 덕에, 2022 NAVER Engineering Day
라는 전사 개발자 행사의 백엔드 세션에 “피지(PGSQL)해변의 카프카(Kafka) 몽고(MongoDB)로 가다”라는 제목으로 지식/경험도 공유했다. 이러한 개발행사 참여는 아주 네임드 개발자나 할 수 있는, 나와 무관한 ‘남의 이야기’라고만 그간 생각해왔었는데, 이번 기회로 막상 발표를 하고 나니 반응도 괜찮았던 것 같고 앞으로도 또 이런 좋은 기회가 있다면 나서고 싶어졌다.
NAVER 신입 개발/비개발 직군 Soft Skill 강연
개발 외적으로도 몇가지 일들이 있었다. 작년에도 네이버 개발 직군 신입 100여 명 정도를 대상으로 강연을 했었긴 하지만, 올해는 그에 추가로 비개발 직군 대상으로도 “직군 간 커뮤니케이션의 이해”이라는 소프트 스킬 주제의 강연을 했다. 동일한 주제임에도 개발/비개발 따로 강연을 하는 거였다보니, 각각의 직군 관점에서의 발표자료를 각각 만들어야 취지에 맞다고 생각해서 밤을 꼴딱 새고도 강연 직전까지 두 벌의 발표자료를 만들었던 기억이 난다.
NAVER People
HR
→ 서비스기획(PM)
→ 개발(FE로 시작해서 결국 BE로)
순서로 직군을 전환했다는 특이한(?) 커리어 때문에 네이버 피플
로 선정되어 촬영도 했다. 카메라가 각도별로 한 4대 정도 있고, 당시 내 촬영 전담 스탭도 한 스무 명 쯤되는… 꽤 큰 규모의 인터널 브랜딩 영상 촬영이었고 무엇보다 회사를 대표한다는 생각이 들어서 큰 부담이었다. 어쨌든 몇 달에 걸쳐 영상 릴리즈를 준비했었는데 내가 퇴직을 하게 되면서, 유튜브/네이버TV/링크드인 등 외부 채널에는 릴리즈하지 않기로 결정되었고 네이버 사내 포털에만 게시되어있는 상태다.
첫 이직: “안녕 네이버, 안녕 당근마켓!”
직군을 전환하다보니 일이 지겹기는커녕 매년 새로웠던 것 같다. 네이버에 신입으로 들어온 이후 그렇게 어느새 6년이 넘는 기간을 재직했지만 생각보다 훨씬 짧게 느껴졌다.
직군을 옮길 때 늘 고통스러웠다. 누구나 그렇겠지만 변화를 맞이한다는 건 정말 힘든 일인 것 같다. 하지만 경험해본 결과, 변화가 많으면 그만큼 배우는 게 많은 것 같다(“다른 조건들이 동일할 때, 두 집합 사이 교집합이 적으면 합집합이 커진다”라고 생각한다!). 그래서 머지 않은 시기에 이직을 해서 변화를 줘야 한다고 생각했다.
시기를 정할 때 고려했던 것
내가 생각하는 적절한 이직의 시기는 ASAP은 아니었다. 앞서 다른 직군을 거치며 어느새 길어져버린 내 경력이 점차 부채로 느껴지고 있었다. 이 부채를 대부분 없앤 후 마침내 별다른 수식어 없이 그냥 ‘n년 경력의 개발자’라고만 나를 소개해도 상대방으로부터 인정받을 수 있을 것 같은 때가 적절할 거라고 생각했다.
중요한 프로젝트를 진행하면서 감사하게도 팀 내에서 시니어로 조금씩 인정과 신뢰를 받고 있다고 느꼈고, 채용시장에 나가서도 인정을 받을 수 있을지 궁금해졌다. 이 프로젝트를 마무리할 쯤으로 이직의 시기를 마음 속으로 정했다.
회사를 정할 때 고려했던 것
- 목적조직 하에서 직군에 구애받지 않고 기여하고, Product를 유저의 니즈 중심으로 발전시켜나가는 문화가 있는 곳
- 회사의 성장과 나의 성장이 서로 유의미하게 엮여있는 곳
-
(백엔드 개발자로서) 아래 3가지중 최소 2개 이상의 전제조건을 가지고 개발할 수 있는 곳
- 대규모 트래픽을 다루는 환경
- 동시성/정합성/무결성 등에 민감한 환경
- 어느 정도 확장가능성을 고려한 설계가 가능한 환경
원래는 비바리퍼블리카 등 Toss계열을 떠올리고 있었다. 하지만 채용 프로세스를 거치며 더 깊게 알게 된 스타트업들도 있었고, 심지어 아예 몰랐던 스타트업중에서도 미래가 크게 기대되는 회사들이 있었다. 결과적으로 토스계열을 포함하여 위 조건들을 충족하는 회사들 너댓 군데에 합격했고, 그중 당근마켓으로 합류를 결정하게 되었다.
이직 결정
당근마켓에 최종합격한 게 3월이었는데, 감사하게도 3~4개월 기다려주셔서 7월에 입사했다. 덕분에 기존에 네이버에서 하고 있던 프로젝트 마무리도 할 수 있었고, 혹시나 다음 프로젝트 리소스 계획에 차질이 없으시도록 리더분께 몇 개월 후의 퇴직 계획을 미리 말씀드렸다.
돌이켜 보면 직장 다니기 전까지 가장 오래 속해있던 조직은 초등학교(6년)였다. 네이버는 초등학교보다도 더 오래 다닌 회사였다보니 막상 그만두려고 했을 때 예상보다 더 느낌이 이상했다. CEO도 세 분을 겪었고, 신사옥 부지가 무료 주차장으로 쓰이던 완전한 공터였을 때가 엊그제 같은데 어느새 다 짓고 입주도 진행되었다. 꽤 긴 기간이었다.
인사담당자 시절, 기획자 시절, 개발자 시절 동료/지인분들에게 퇴직인사 메일을 쓰고 보니 수신인이 거의 200명 정도 되었다(교집합이 적을수록 합집합이 큰 게 역시 맞는 것 같다ㅎㅎ). 그 중에서도 특별히 감사했던 분들은 직접 뵙거나 따로 DM을 드리는 등 감사 마음을 최대한 잘 전달하려 노력했다.
—
하반기: "당근이세요?"
🥕
그렇게 퇴직 후 하반기에 당근마켓에 입사 했을 때에는 내가 생각했던 것보다 더 느낌이 달라서 꽤나 놀랐다. 무엇보다 인상 깊었던 것은 나보다 나이 많은 사람이 그리 흔하진 않다는 점이다. 그 외에도 일하는 방식, 분위기 등 많은 점에서 어쩌면 정반대의 성격을 가진 회사라는 생각이 들었다. 한편, 인사 제도 만큼은 오히려 딱 내가 네이버에서 인사담당자로 일하던 때의 네이버 인사 철학, 방향성, 제도들과 너무나 비슷해서 쉽게 공감이 되기도 하고 한편으로는 우려(?)도 되면서 아무튼 신기했다.
당근마켓에서 사용할 영어이름은 Travis
로 정했다. 내가 좋아하는 여행(Travel)
의 느낌도 좀 담아보고 싶었고, 개발쪽으로도 의미를 살짝 엮어보고 싶었는데 Travis CI
라는 기술 이름의 Travis
가 실제 쓰이는 남자 이름이라서 여기서 이름을 따왔다.
네이버를 다닐 때에도 네이버보다 오히려 당근마켓을 더 많이 사용했을 정도로 당근마켓 헤비유저라, 가장 좋아하는 서비스를 업무적으로 접하게 되었을 때의 느낌이 기대되었다. 이 회사를 다니는 동안 매너온도 99도를 달성하고 활동 배지를 다 모으는 게 목표다. 현재는 50도가 갓 넘은 정도라 매너온도는 아직 갈 길이 멀고(진짜 안오르는데 조금만 활동을 안하면 금방 떨어진다…), 활동배지는 딱히 모으려고 노력하지 않았음에도 어느새 다 모아간다.
기억에 남는 프로젝트
당근마켓에 와서는 (중고거래 컨텐츠가 아니라) 동네가게 컨텐츠를 유저에게 피딩해주는 일을 하고 있다. 단골(=구독)에 대한 피드/알림 서버 개발도 했지만 가장 기억에 남는 프로젝트는 추천(=비구독) 시스템을 새로 만들었던 것이다.
머신러닝을 통한 추천은 아니고, ElasticSearch(이하 ES)
를 이용해서 그 유저에게 적합한 컨텐츠를 가져올 수 있도록 적절하게 쿼리한 후 그 결과를 서빙하는 것이었다. 이 시스템을 내부적으로 추천풀이라고 부르는데, 검수 → 서빙 → 성과판단
이렇게 3가지 영역 중에 나는 서빙을 맡았다. 머신러닝 없이 추천이란 게 가능할지에 대한 의구심이 있었는데 막상 서빙을 구현하다보니 생각보다 ES로 할 수 있는 게 많았고, 계획했던대로 추천풀은 나름대로 CTR, CVR 모두에서 괜찮은 개선이 있었다.
추천풀을 새로 만들면서 추천에 대해 좀더 딥하게 고민해볼 수 있었다. 단순히 전환률(CVR)만이 중요한 게 아니라, 궁극적인 목표는 “전환수”이기 때문에 노출수 * CTR * CVR = 전환수
라는 걸 생각하면, 이 셋 중 부작용으로 떨어지는 게 있어선 안되었다. 셋다 기존보다 더 높아지거나 최소한 기존 수준을 유지해야 했기 때문에 적절한 밸런스를 찾는 지점에서 고민이 많았다. 그리고 버그로 인해 추천에 이상이 생긴 때에는 나 때문에 동네가게가 한 명의 고객이라도 놓치게 될까봐 죄책감이 들어서 최대한 빨리 고치려고 했다. 그래도 컨텐츠 소비의 효율을 개선하는 과제였어서 비즈니스적으로 바로 결과를 볼 수 있다는 점이 흥미로웠다.
이 외에도 내가 제안한 아이디어가 적용돼서 전환률이 +50% 이상 증가한 사례도 있었는데, 비즈니스 임팩트에 기여하고 있다는 생각이 들어 뿌듯했다. 관련해서 ‘비즈니스적인 성과’라는 것에 대해 많은 생각을 하게 되었는데 이 회고에 쓰기엔 양이 많아서 이번 회고에서는 생략한다.
네이버에서 개발할 때와 많이 달랐던 점
네이버에서는 효율보다 효과(성능)에 초점을 두고 개발했었던 것 같다. 노출용DB 프로젝트가 바로 그런 사례였다. 사실상 중복 데이터를 한벌 더 들고 있는 셈이지만, 가볍게 서빙할 수 있다는 장점과 장애 격리가 된다는 장점을 달성할 수 있어서 유효한 프로젝트였다.
- 메시지 컨슈머의 throughput이 좋지 않다면, 해당 Kafka 토픽의 파티션과 컨슈머 그룹의 컨슈머(pod)수를 늘려서 병렬 처리하는 방향을 먼저 떠올린다.
- 조회속도도 높이고 DB 부하도 줄이기 위해, 쓰기보다 읽기 용도 위주의 데이터라면 캐싱(caching)은 사실상 다다익선에 가까웠다.
- 애플리케이션 내에서 동기적으로 당장 수행되어야 하는 로직이 아니라면 Kafka에 미뤄두고 컨슈머에 로직을 위임하는 식으로 비동기적으로 수행하곤 했다.
그런데 당근마켓에 와서는 물론 효과도 중요하지만 효율이 좀 더 중요한 관점이라고 느껴졌다.
- 메시지 컨슈머의 throughput이 좋지 않다면, 파티션 늘리는 형태의 인프라적 방법을 생각하기 전에 비즈니스 로직 개선에 초점을 맞춘다.
- 이것저것 캐싱을 다 했다가는 캐시 사용량(트래픽, 저장용량)이 과도하게 높아져서 오히려 위험(?)을 맞이할 뻔 했다.
- 너무 Kafka 컨슈머에 로직을 많이 위임했더니 Lag이 걷잡을 수 없을 만큼 단기간이 폭증하기도 했다.
한마디로 “인프라를 비교적 아껴써야 했다”는 것인데, 효율
과 효과
관점에서 밸런스를 찾는 부분에서 많이 시야가 넓어진 것 같다.
TV 지상파 출연
당근마켓 직원을 대상으로 KBS 오케이?오케이!
라는 프로그램 출연 섭외 요청이 있었는데 내가 3명중 1명으로 출연하게 되었다. 1인당 10분 조금 넘는 분량이었다. 평소 팬이었던 오은영 박사님을 뵐 수 있어서 좋았다. 개인적으로 별로 내키는 내용의 촬영은 아니었어서 나름 마음고생을 좀 했었던 기억이 난다.
당잘알 모의고사 (공동)우승
작년부터 당근마켓 송년회에서 당잘알 모의고사라는 행사를 한다. 당근마켓과 관련된 A to Z에 대한 문제가 나오면 짧게 주어진 시간 내에 각자의 정답을 제출하는 것이다. 올해 당잘알 모의고사가 어렵긴 했지만 20문제중에서 12문제를 맞힌 내 점수가 전사에서 1등이었을 줄은 전혀 예상 못했다. 나 말고도 1명 동점자가 있었는데 1등 상품(아이패드)은 1개 뿐이었어서 가위바위보를 했고, 나는 거기서 져서(ㅜㅜ) 결국 2등 상품인 애플워치8을 받게 되었다.
당근마켓에서 일하면서 들었던 생각들
- 이미 가장 좋아하던 서비스라, 억지로 서비스를 써보려 추가적인 노력을 할 필요가 없어서 좋았다.
- 젊다. 멋사에서 활동할 때와 비슷한 느낌을 받았다. 대학교 동아리처럼 밝고 서로 협조적이며 의욕적인 분위기이다.
- 체계적이다. 스타트업은 주먹구구식일 거라는 편견을 가진 사람들이 많을 텐데, 내가 본 당근마켓의 일하는 방식은 매우 체계적이었다.
-
PM(Product Manager), PD(Product Designer), 개발자 할 것 없이 데이터를 열심히 분석하고, 직군간 구분 없이 일하는 게 인상적이었다.
- 처음 들어갔던 회의는 한 10명 정도 규모의 회의였는데 회의가 끝날 때까지 누가 어떤 직군인지 전혀 매칭이 불가능했다. 그냥 모두가 PM 같았다.
- 워낙 자유롭고 수평적인 환경에서 의견을 주고 받는 분위기다보니, 나도 어느새 기획적/개발적 의견을 내고 싶어서 입이 근질거리는 성향으로 바뀌어있었다. 이게 진짜 신기한 경험이었다.
- MBTI가
INTJ
혹은ENTJ
인 사람들이 직군 불문하고 엄청 많이 보여서 신기했다. 이정도면 당근마켓의 인재상과 유의미한 상관관계가 있는 게 아닐까 하는 개인적인 추측이다. -
이직으로 인한 스트레스는 생각보다 강했다. 경력입사자라는 신분적(?) 부담감을 안고, 수습기간이라는 이름으로 주어진 3개월내에 스스로를 잘 증명할수있을지. 개인적으로, 나의 러닝커브는 중장기적 관점에서 남들보다 더 가속이 빠르게 붙는 편이지만 단기적 관점에선 초기속도가 느린 편이라고 평가하기 때문에 더욱 그랬다.
- 코드와 도메인 지식도 새로 파악해야하고, 무엇보다 그간 네이버에서 자체 개발한 인프라만 사용해왔다보니 인프라도 처음 써본 것 투성이라 결과적으로 동일한 무언가를 개발하기 위해 투자해야하는 시간이 초기에는 거의 3배 정도 들었던 것 같다.
- 신뢰가 쌓인 상태에서 뭔가를 하는 것과 신뢰가 아직 쌓이지 않은 상태에서 증명을 해야하는 것은 완전히 그 심적 부담감이 다르다는 걸 깨달았다.
- 신기하게도 1 on 1을 통해서 “내가 지금 잘하고 있나요?”에 대해 물어보고 피드백을 듣는 형태로 정면 승부를 보고나면 오히려 안정감을 찾을 수 있었다. 당근마켓 업무 문화적으로 신뢰라는 키워드를 강조하는 이유를 알 것 같았다.
- IT 겨울이라고 하지만, 일단은 스타트업으로 넘어오길 잘했다고 생각중이다. 다른 스타트업들은 어떻게 일하나 매우 궁금해졌다.
—
스터디 & 개발 블로그 📝
이직을 하면서 작년 만큼 스터디를 많이 하지는 못했던 것 같다.
올해는 Kafka
, ElasticSearch
, MongoDB
, Redis
등을 주제로 스터디를 했었다. 책에서 정한 목차에 따라 스터디하는 것보다는, 따로 교재를 정하지 않고 토픽만 하나 정해서 각자 다른 관점, 다른 교재에서 정리해오고 그걸 공유하고 토론하는 스터디 방식을 좀더 선호했기 때문에 주로 그런 식으로 진행했다.
이런 식으로 스터디를 진행하다보니 개발 블로그 콘텐츠로 올릴 만한 주제가 많았고, 컨텐츠 초안을 써놓은 게 꽤 되는데 아직 블로그에 정식 업로드하진 못했다. 날 잡고 조금 다듬어서 어서 업로드 해야겠다.
개발 블로그는 올해 잘 관리하지 못했음에도 꾸준히 방문자가 유입되고 있다. 구글 검색을 통한 유입이 압도적으로 많은 비중을 차지하고, 그 외에 다른 블로그 등에서 레퍼런스로 사용되어 링크로 걸리기도 하는 것 같다. 개발 블로그에 한번 광고를 붙여보고 싶다는 생각은 계속 했었는데 시간이 안났어서 연말이 돼서야 드디어 광고를 붙였다. 덕지덕지 붙이고 나니까 커피값 정도 벌게 되었다. 광고 양은 점차 적절한 수준을 찾아갈 예정이다. 그나저나 구글 애드센스 스크립트를 추가하고 난 뒤 몇몇 버튼이 작동되지 않는 버그가 생긴 걸 방금 발견해서 골치가 아파졌다.
결혼 🤵♂️👰♀️
웨딩플래너 없이, 거의 모든 것을 셀프로 준비했다. 그래서 체력적으로나 심적으로나 매우매우매우 힘들었다. 웨딩촬영, 본식 플래닝도 직접 하고 종이청첩장도 직접 만들었는데 모바일청첩장까지 100% 셀프로 만들었다. 아내와 함께 기획한 뒤, 아내가 디자인하고 내가 개발하는 형태의 일종의 ‘사이드 프로젝트’였다. 도메인주소는 결혼식 하는 당일의 날짜를 담아 5-22.today
로 정했다.
필요하다고 생각하는 컴포넌트들과 그 순서를 정의했고 UX를 설계했다. 필요에 따라 특정 컴포넌트는 신랑측/신부측 분기 처리했다. 그리고 야외결혼이었다보니 참석인원 파악이 가장 중요했기에 플로팅 버튼
을 띄워서 참석여부 컴포넌트로 앵커링
을 걸었고, 지도를 클릭하면 네이버지도 앱
을 통해 결혼식장을 도착지로 지정해서 네비게이션
을 바로 연결해주는 등 사용성 측면도 많이 공을 들였다.
사용성과 더불어 가장 중요하게 생각했던 부분은 개인화였다. 모바일청첩장을 수신하는 하객들마다 다른 이름과 메시지 내용을 넣고, 짧게나마 진심을 담은 초대 편지글을 써넣었다. 그리고 그 청첩장을 받은 하객들이 참석여부/식사여부를 선택해주시면 그 결과가 우리가 보는 어드민에서 집계되는 스펙이었다.
궁금하신 분을 위해: 좀더 자세한 기술 스택은 여기를 펼쳐보세요
프론트엔드와 어드민은 React.js로 개발했고, 개인화용 데이터는 Upstash라는 솔루션으로 서버리스로 서빙했으며 Redis에 캐싱했다. Redis에 개인별 특정 룰에 맞게 key를 generate해뒀다가 이를 URI의 쿼리파라미터로 사용해서 JSON value를 꺼내 사용하도록 했고, 여기서 특히 key는 청첩장 받은 본인이 아닌 이상 알아낼 수 없도록 특정 룰에 의해 해싱한 값을 사용해서 보안에 신경썼다. 배포는 Github에 push하면 Netlify로 자동배포 되도록 해두었다.
디자이너 아내 + 개발자 남편
조합이라는 우리만의 개성을 녹여 결혼을 준비했던 의미있는 경험이었다. 이것도 일종의 가내수공업(?)이라는 생각이 들어서 footer쪽에 현상수민 가내수공업
이라는 이름도 새겼다.
궁금하신 분들을 위해 예시 링크를 첨부한다. https://5-22.today/?groupId=501237983
번아웃 💣
최근 몇 년 동안 IT업계에서 번아웃
이라는 단어가 참 많이 들렸던 것 같다. 내가 듣기엔 너무 모호한 표현 같았고 이게 진짜 실재하는 질병 같은 것인지 아니면 단순히 “나 힘들다”라는 감정에 대한 절박한 표현인지 잘 모르겠었다.
1분기
이직 준비와 채용 프로세스와 2분기
결혼 준비와 결혼식, 그리고 네이버 퇴직, 그리고 3분기
당근마켓 입사 후 적응 및 수습기간 등, 이 역대급 중요한 임무들을 일단락 짓고 나면 안정을 찾게 될 거라 기대했다. 하지만 그와는 반대로, 오히려 심적 여유가 없고 인생 통틀어 가장 불안한 심리 상태가 되었다. 이를 해소하고자 몇 차례 심리상담을 받았는데 상담사분께서 내 상태를 ‘내적 소진’이라고 설명해주셨고, 그게 영어로 번아웃이었다. 내적 소진이라는 표현을 듣고 나니 확실히 번아웃이 뭔지 와닿았다. 내적(심적)으로 에너지가 소진되어 더이상 무언가를 이겨낼 힘이 남아있지 않은 상태가 맞았다. 알려진 것처럼, 일이 재미 없거나 하기 싫어지는 류의 증상은 아니었다. 나의 경우는 뭘 해도 ‘쉽게’, 그리고 ‘많이’ 스트레스를 받고 불안을 겪게 되는 증상이었다.
다행히 지금은 모두 회복하고 안정을 되찾았고, 이 회복과정에서 나를 많이 알게 되었으니 해피엔딩이다.
오픈소스 기여 😢
올해는 오픈소스 기여에 노력을 별로 기울이지 못했다. egjs-flicking
, mochajs
, elastic 가이드북
에서 매우 마이너한 도큐먼트성 기여를 한 정도였다.
오픈소스 컨트리뷰톤에서 함께 했던 모카팀 팀원들 + 아웃사이더님과 최근에 함께 모임을 가졌는데, 컨트리뷰톤 때가 많이 생각났다. 이 기운을 잘 끌고 가서 내년에는 백엔드 관련된 오픈소스에도 제대로된 기여를 해봐야지.
[기타] 커리어 전환에 성공한 분들에 대한 축하 🎉
비개발 일을 하고 있는 분 중에 개발자로 커리어 전환을 희망하시는 분들과 종종 상담을 하게 된다. 재작년쯤 두분(네이버 기획자로 일하고 있던 김경일님, 카카오 HR담당자로 일하고 있던 문승현님)을 대상으로 몇 주 정도 무상으로 웹개발 수업을 해드렸었는데 그 이후 두분 다 열심히 하셨는지 올해 결국 개발자가 되셨다는 소식을 들었다.
그때 나는 프론트엔드를 위주로 가르쳐 드렸었는데 아이러니하게도 두분 다 현재는 백엔드개발자셔서 내 수업이 커리어 전환에 직접적인 영향은 아니었겠다는 생각은 한다. 아무튼 나와 같은 도전을 한 분들이 좋은 결과를 얻어서 기뻤다. 정말 축하드리는 마음이다.
[기타] 개발 관련 올해 Special thanks to 🙏
네이버쇼핑에서 개발자로 일했던 멋사 친구들
: 함께 스터디하며 진짜진짜 많이 배울 수 있었다.챌린징한 프로젝트를 맡겨주셨던 김득중(리더)님
: 완전히 맡겨주셔서 더 오너십을 가지고 주도적으로 임할 수 있었다.지금 같이 일하고 있는 Neil, Jenny, 그리고 옆팀의 Andy
: 진짜 배울점 많고 업무적으로 자극이 많이 되는, 나이/경력이 믿기지 않는 개발 고수들이다.
2022년 총평 🚀
- 올해도 무척이나 바빴고 밀도 있게 보냈다.
- 유독 카메라 앞에 설 일이 많았다.
- 자아성찰을 많이 했고 내 자신에 대해 더 잘 알게 된 한 해였다. 내가 뭘 잘하고 뭘 못하는지, 뭘 좋아하고 뭘 싫어하는지 좀더 명확하게 알고 받아들일 수 있게 되었다.
- 그동안 “넓게 파야 깊게 팔 수 있다”는 생각을 가지고 넓게 파고 있었는데 이제 그 파편화 되었던 것들끼리 네트워크 효과 비스무리한 게 일어나고 있는 것 같다. 내년에는 왠지 올해보다 훨씬 성장할 수 있을 것 같은 느낌이 든다.
내년은 토끼의 해인 만큼 당근이 떡상했으면 좋겠다.
올 한해도 모두 수고하셨습니다!