작년 8월 말에 현재의 회사, 네이버 클라우드로 이직해왔다. 학교 다닐 적에는 전학 한 번 없이 스트레이트로 졸업까지 했건만, 직장인이 된 이후로는 어쩌다보니 이직을 꽤 자주 하고 있다.

매번 이렇게 다른 회사, 다른 포지션으로의 변화를 겪다보니 이직이 마치 여행과 같다는 생각을 하기도 한다. 익숙한 동네와 사람들을 떠나 새로운 곳에서 새로운 문화와 만나는 여정과 같으니 말이다. 밖에서 볼때는 어차피 똑같은 IT 회사에 똑같은 개발자로의 이직이니 다 비슷비슷하지 않겠느냐 하고 볼 수도 있겠지만, 실제로는 매번 이직 때마다 너무 다른 경험들을 하게 된다. 사람들이 다르고, 회사가 다르고, 향하는 목적지가 다르니 당연한 일이다.

업무 도메인의 변화

이직에 따른 나의 여정을 되짚어보니, 우연찮게도 나는 점점 더 low level 의 기술들을 다루고 있었다. 5년 전에는 RIDI 에서 웹 개발을 하고 있었는데, 그 이후에 SK C&C 에서는 클라우드 모니터링 서비스를 SaaS 형태로 만들었고, 현재 회사에서는 매니지드 Kubernetes 서비스에 대한 PaaS 를 만들고 있다. 의도했던 건 아니었고, 그냥 매 이직 때마다 마음에 드는 회사와 포지션을 쫓았을 뿐인데 어쩌다보니 이런 경향성을 띄게 띄었다.

생각해보면 참 우스운 일이기도 한게, 나는 원체 low level 에 약했다. 학교 다닐 적 졸업 작품에서 다뤘던 기술은 웹과 앱 개발 이었다. 당시에도 몇몇 친구들은 졸작으로 리눅스 기반의 네트워크 트래픽 제어 라던지, 심지어 선배 중에는 간단한 OS 를 만든 케이스도 있었다. 하지만 당시의 나로써는 설명을 들어도 그게 뭔지 이해도 다 못하는 수준이었다. 리눅스는 정말 기초적인 커맨드 외에는 아는 게 없었고, 학교에서 배우는 CS 관련 수업도 어찌어찌 따라가긴 했지만 어디가서 자랑할 만한 수준은 못되었다. 졸업 후 첫 회사에서 서버 개발자로 일하긴 했지만 그저 응용단 개발자에 지나지 않았다. 내가 작성하는 코드 기저의 추상화된 영역은 거의 알지 못했다. 반정도는 일종의 블랙박스였다. 단순히 코드 내에서 접속할 IP 주소와 포트 넘버를 지정해주면 원격지로 연결이 된다 정도 까지는 인지를 하고 있었다. 그리고 그 기저에서에는 수업에서 배운대로 TCP/IP 프로토콜을 통해 어떤 식으로든 패킷을 주고 받는다 정도의 피상적인 이해만 가지고 있었다. 실제로 패킷을 까본다던가 관련된 커맨드들을 활용해본 경험은 없었고, 사실 그렇게 할만큼의 충분한 지식도 없었다.

그러다 보니 이러한 OS 및 인프라 영역에 대한 내 지식은 대부분 실전에서 맨 땅에 헤딩을 하면서 알게 된 부분이 많았다. 가령 스토리지 용량이 충분한데 계속해서 발생하는 No space left on device 에러로그 앞에서 멘붕을 하며 하루종일 구글링을 하다가 inode 의 존재에 대해 알게 되는 식이었다. 문제가 생기면 에러 메시지를 구글링해보고, 스택 오버플로우의 고수들의 대답을 보면서 실제로 인프라 레벨에서의 동작 과정을 어렴풋이 가늠하곤 했다. 그러다 정 이해가 안되는 부분이 있으면 더 깊게 찾아보고 그래도 이해가 안되는 부분은 다시 블랙 박스로 남겨두기도 했다.

그래서 웹 개발의 영역을 벗어나 SK C&C 의 모니터링 서비스 개발이나, 현재 네이버 클라우드의 Kubernetes Service 개발 포지션으로 이직을 할 때 마다 내 솔직한 심정은 8할의 설렘과 2할의 걱정이었다. 매번 더 low level 의 영역을 향해 도전하는 셈인지라 새로운 경험을 쌓아갈 수 있다는 종류의 설렘과 함께, 이 일을 내가 잘 해낼 수 있을까, 지금 내 역량이 혹시 부족하지는 않을까 하는 심정이었다. 그간 어떻게든 적응을 하고 답을 찾아내었던 가닥이 있으니 이번에도 열심히 헤딩하면 어떻게 되지 않을까 하는 생각도 있었다.

입사 후 8개월 정도가 지난 현재 시점에서 돌아보면 이번 도전은 그간 다소 부진했던 학습/성장 곡선의 기울기를 다시 세워주고 있다는 체감이 든다. 그동안 어느 정도 경험이 있던 웹을 비롯한 응용 단의 개발 뿐만 아니라, 인프라 영역에서의 경험은 훗날 시니어 엔지니어로서의 좋은 자산이 될 수 있지 않을까 하는 희망을 가지게 된다.

적응 과정

경력직이라 하더라도 누구나 새로운 회사에서의 적응은 쉽지 않다. 회사에 괜찮은 온보딩 프로세스가 있다고 하더라도 적응 난이도가 드라마틱하게 쉬워지지는 않는다. 특히나 코로나 팬데믹으로 인한 재택 환경은 이러한 적응 과정의 난이도를 한층 더 높게 만들어 버렸다. 아무리 온라인을 통해 협업할 수 있다고 하더라도 실제로 오피스에서 같이 얼굴 보고 하는 것과는 차이가 날 수 밖에 없다. 회사의 분위기나 암묵적인 룰 같은 것들을 재택 환경에서는 알기 어려웠고, 동료들과의 정서적 거리감을 줄이는 일도 쉽지 않다. 그래서 개인적으로 full remote 업무 환경 보다는 어느 정도 오피스 출근을 하는 하이브리드 형 근무 형태를 더 선호하기도 한다.

입사 초기에는 담당 상품과 사내 공통 시스템 등을 파악하는 데에 거의 모든 시간을 쏟았다. 특히 사내 공통 시스템이 상당히 인상적이었는데 네이버 및 네이버 계열사들이 공통으로 사용하는 시스템들이 굉장히 많았다. 사실 이러한 시스템들을 조직이나 팀 별로 별도로 구축하려면 상당한 리소스를 필요로 하는데 공통 시스템화해서 별도의 담당팀이 셋업되니 이용하는 쪽에서는 상당히 편했다. 시스템 별로 가이드나 문의 시스템도 잘 되어 있고, 많이 사용되는 공통 시스템의 경우에는 사내 영상공유 플랫폼에 교육 영상도 올라와있기도 했다. 특히 n2c 라고 불리는 Kubernetes 공통 플랫폼은 상당히 인상적이었다.

코로나 팬데믹으로 인한 재택 환경 상에서의 이직은 처음이었기 때문에 평소와는 다른 종류의 소프트랜딩에 대한 어려움들이 있었다. 첫 번째로는 내 적응 과정을 알리고 그에 대한 언어적/비언어적 피드백을 받기가 쉽지 않다는 점이었다. 이를 위해 입사 한 달쯤 되었을 때 “입사 1개월 차 리뷰 리포트"를 작성해서 팀원들에게 공유했다. 지난 한 달간 어떤 업무를 진행했으며, 신규 입사자의 적응 관점에서 경험했던 허들과 긍정적인 경험들을 정리했고, 또 이후 신규 팀원을 위한 플러스 알파에 대한 의견을 적어보기도 했다. 누가 쓰라고 했던 건 아니었지만 코로나로 인해 서로 만나지 못하는 상황에서 “모니터 너머의 제가 이렇게 적응해가고 있습니다"를 공유하고자 하는 목적이었다. 오피스로 출근하는 상황이라면 오며가며 자연히 알게 되거나 티타임을 통해 나눌 수 있는 이야기들이기도 하다.

두 번째로는 얼굴도 보지 못한 동료들과의 협업이었다. 코로나 이전이었다면 사무실에서 오고 가며 인사도 주고 받고, 티타임도 가지면서 얼굴도 익히고 거리감도 줄였을 텐데, 재택 환경에서는 쉽지 않았다. 이를 위해, 입사 초반에 주변 동료들에게 메신저상의 1:1 대화를 통해서라도 일부러 인사를 전하기도 했다. 예전에 읽었던 [90일 안에 장악하라] 라는 책에서 “여러분의 집에 불이 났는데 이제야 이웃과 처음으로 인사하는 상황이 되어서는 안 된다” 라는 문장이 있었는데 일부러 인사를 하고 다녔던 것도 이러한 맥락이었다. 일단 온라인 상으로라도 안면을 터놓는 것이 앞으로의 업무 진행에도 긍정적일 거라고 생각했고, 사실 이러한 종류의 첫 인사는 입사 초기가 지나고 나면 할 수 없는 것이기도 했다.

경력직 이직자의 단상

대부분의 경력직들은 빨리 적응하고 한 사람 분의 퍼포먼스를 내고 싶어 초조해한다. 그리고 이런 감정에 대해 보통 너무 초조해하지 말고 여유를 가지라는 조언을 듣게 된다. 물론 초조함으로 일을 그르치는 것보다는 차분하게 가는 것이 낫다. 하지만 그럼에도 조심해야 하는 부분은, 현재 조직에서 자신의 역할과 방향성에 대한 계획 및 설정마저 늦어지면 차후 곤란을 겪게 되기 십상이다. 이 팀에서 어떤 역할의 기여를 할 수 있을 것인지에 대해 초반에 충분히 고민하고 본인의 영역을 설정해야 한다. 이 부분이 지체된 상태로 시간이 흐르면 나중에는 더 어려워질 뿐 더러 초반에 만들어진 첫인상은 생각보다 업무 및 평가에 많은 영향을 미치게 마련이다. 너무 초조해하지 않아야 하지만, 너무 여유를 가질 수도 없는 경력직의 어려움이다.