벌써 3개월이 지나고 2021년의 끝을 바라보고 있다.
2021년 한 해, 코로나로 인해 많은 활동을 하지는 못하였지만 가장 큰 전환점이라 하면 이직이 아닐수 없다. 면접과 입사 그리고 적응기를 간략하게 회고하며 2021년의 하반기를 정리해보고자 한다.
작년 말 초안 써놓고 귀찮아서 미뤘다가 벌써 2월이다.
또 다른 3개월이 지나가고 있는 이 시점에서 늦게나마 나의 적응기를 풀어보겠다.
2020년에 입사했던 위메프. 이전 글에서도 썼지만 정말 좋은 팀에 합류하여 많이 배우고 경험했다.내 느슨한 CS지식에 긴장감을 유발해준 팀원 분들 덕에 한 번이라도 더 공부할 수 있는 기회가 마련되었다. 또한 추상화와 온갖 디자인패턴이 겸비된 코드만이 좋은 코드라 여기던 나에게 상황에 맞는 인사이트를 부여해준 그룹장님.
(6개월이 지난 지금도 많은 인사이트를 전달해준 그룹장님과 팀원 분들에게 감사한 마음이 크다. 여담으로 내가 이직하던 시기 즘 나를 포함한 3명의 팀원들이 네이버로 이직하게 되었다.)
천천히 부족함을 채워나고 있던 어느 날, 난 불현듯 창업을 해야겠다는 생각이 들었다. 일과 창업 준비를 병행하며 프로토타입 개발과 사업계획서 쓰는 법을 공부하며 시간을 보냈다.
슬슬 더위가 다가오던 6월, 개발자 단톡에서 개인적으로 알던 분께 연락이 왔다. 네이버 입사 제의였다. 계획에 없던 이직준비라니. 나름 장황하게 짜놨던 내 로드맵에 급하게 이직 준비를 껴넣기 시작했다.
그리고 '급하게' 만든 포트폴리오.
포트폴리오 작성하며 '그간 뭘 했지?' 라고 되새겨보기엔 너무 많은 일을 장황하게 늘어놓아야 했다. 그래서 해당 블로그에 정리된 이슈들을 기준으로 포트폴리오를 작성해봤다.
이슈 해결 능력에 방점을 찍을 수 있는 내용이 나와서 나름 편리하게 써내려갔다.(그래도 반나절 넘게 걸림)
급하게 준비한 이직치고는 정말 아주 굉장히 운 좋게 합격하게 되었다. 허나 채용프로세스가 길어서 장장 3개월의 절차가 끝나고 9월이 되서야 첫 출근을 할수 있게 되엇다.
출근 3일전 즘 퀵 서비스를 통해 미리 임시장비를 받고 필수 프로그램 설치 안내를 받는다. 위메프와 크게 다를 것이 없어보였으나 예상을 빗나가고 알 수 없는 앱과 프로그램이 난무했다.
업무기기는 사내 업무기기 센터에서 구매가 가능했다. 신규 입사자에게 일정 금액이 주어지는데, 예산으로 장비를 구매했지만 하필 원자재 대란으로 맥북 공급이 원활하지 않았던 시기, 임시대여장비를 3달 가까이 쓰게되었다.
안 좋은점만 이야기한 거 같으니 좋은점도 이야기하자면.. 큰 규모의 기업답게 비대면 업무체계에 대해 많은 것이 갖추어져 있었다. 첫 입사날 부터 신규입사자를 위한 온보딩 프로그램이 진행되었고 그 이후에도 경영관련 부서에서 전담하여 네트워킹도 진행하였다.
팀 내 온보딩 주차가 끝나고 온보딩 수기(부제 : MSA를 향한 여정)를 전사발표(CIC 한정)하였다. 기여해보고 싶었던 것도 적어봤다. MSA환경에서의 테스트 전략과 구현과 CDC(Debezium)를 사용한 이벤트 드리븐 데이터 동기화를 간단하게 소개 해봤는데 다행히도 좋게 봐주셨다.
위 내용을 끝내고 수습완료가 되었는데 사실 수습통과하지 못하거나 평가를 안좋게 받을까봐 두려웠다. 눈치안보는 성격이라고 센 척 했지만 '이런 것까지 물어봐?'라고 생각할 것 같아 쫄리는건 어쩔수 없다. 하지만 난 빠가사리라 그냥 물어봤고, 감사하게도 다들 좋게봐주셔서 성공적인(?) 온보딩을 진행할 수 있었다.
업무에 들어가며 가장 먼저 눈에 들어왔던건 MSA + EDA로 이루어진 분산 아키텍처였다. 선망의 대상이었던 EDA는 서비스간의 의존도를 낮춘 대신 그만큼 데이터 동기화 구간이 많아진다는 것을 의미했고 이는 나에게 큰 챌린지로 다가왔다.
위메프에 있었을 당시 주로 대용량 데이터 처리 배치 프로그램을 작성하였기때문에 동시성이나 트랜잭션 성능에 초점을 두었었다. 하지만 사용자와 직접적으로 만나는 서비스는 그보다 더 넓은 관점에서의 고민 즉, 전체적인 데이터 흐름(flow)을 자연스럽게 하는 것에 초점이 맞추어졌다.
자연스러운 데이터 흐름을 위해 각각의 microservice는 가벼운 상태를 유지해야했다. micro cache, remote cache와 같이 구간과 상황에 맞는 캐시를 적극적으로 사용했고 각 microservice에 맞게 물리적으로 분할된 DB는 rsocket을 통해 통신하는 방법을 채택하였다. (연결지향성 rsocket은 http 통신보다는 더 나은 퍼포먼스를 내지만 로드밸런싱의 어려움이 있다. 하여, 현재 팀 내 client side 로드밸런싱을 통한 해결책을 만들어가는 중이다.)
많은 데이터 동기화 구간과 자연스러운 흐름을 제어한다는 것은 그만큼 많은 모니터링과 지표를 동반해야했다. http 혹은 rsocket의 응답속도 지표는 api endpoint별로 표시되어 병목을 쉽게 찾을수 있도록 하였다. 또 k8s 환경에서 동작하는 서비스인 만큼 serviceName + pod 별 시스템리소스 할당 & 사용 지표도 손쉽게 볼 수 있도록 설정되었다.
처음에는 이렇게까지 해야하나..?라는 생각이 들기도 했는데, 간단한 join문으로 해결할 수 있는 내용들이 불필요한 통신을 유발시키는 것처럼 보였기 때문이다. 하지만 적응을 거듭할수록 그 진가는 더욱 잘 드러났는데, 바로 SRE(Site Reliability Engineering) 지향 아키텍처로 장애격리에서 그 빛을 발휘했다. zookeeper에 예약된 값을 통해 실시간으로 기능을 on/off 하는가 하면 circuitbreaker의 적극활용 또한 빠른 장애감지와 대응이 가능하도록 했다. 마지막으로 이와 잘 맞물린 알람 시스템은 장애 상황을 모르고 지나칠수가 없는 환경을 만들었다.
업무초기에는 이미 구성된 아키텍처에 숟가락을 얹는 이방인 같은 느낌이었다. 스터디를 하면서 굉장히 동경해왔던 MSA와 EDA였지만 실상 접했을 때 그 낯설음은 생각보다 크게 다가왔기 때문이다. 허나 업무가 진행되며 하나씩 익혀나가고 서비스에 조금씩 기여하고 나니 스스로 메카닉이 된 느낌을 받았다. (서비스 화면 보여주면서 '내가 이거 만들었어!'라고 할 수 있는 뿌듯함)
2020년 코로나와 함께 시작된 커리어에 대한 고민은 이 블로그에 고스란히 담겨있다. 어찌보면 2년 남짓 나의 성장기가 담긴 것인데, 새삼 운이 좋았다는 생각이 든다. 같은 시기에 입사하신 분들의 어마어마한 스펙을 보면 난 비교적 짧은 시간의 노력으로 좋은 환경에 이르렀다.
그럼 인생은 운빨X망겜일까? 당연히 아니다. 그럼에도 불구하고 내가 감사하게 생각하는 부분은 무언가 바꾸고자 노력하였을 때 조그마한 변화라도 쉽게 체감할 수 있었다는 부분이다.이제까지 각 단계에서 나를 맡이해준 사람들 다음 단계로 나를 이끌어준 사람들 덕분에 좋은 경험을 할 수 있었다. 이분들에게 무한감사를 표한다!
이직 한 번 했다고 내 인생이 바뀌지는 않을 것이다. 자유를 위한 삶의 로드맵은 계속 그려가며 '맨 땅에 헤딩하리라'는 생각도 계속 될 것이다.
마지막으로..
인플루언서 검색 서비스 많.관.부!!
https://in.naver.com/