2021년 회고 - 이직 후기

Everything

원래는 2 편의 글로 2021년을 마무리하려고 했습니다. 다른 글에서는 제가 올 해 겪었던 일들을 써 보려고 했었어요.

예를 들어 작년 10월에 촬영했었던 This is My Architecture 영상이 공개되었다거나, 매월 블로그에 글 하나씩 쓰는 것을 목표로 했는데 목표를 달성했다거나, 낮에는 개발하고 밤에는 복면 쓰고 락 밴드를 하는 사람들을 소재로 소설을 쓰려고 했는데 반 정도만 쓰고 말았다거나, 장롱면허여서 운전 연수를 받았다거나, … 아무튼 여러 일들이 있었습니다.

그러다가 ‘시시콜콜한 이야기를 하는 게 무슨 의미가 있나?‘라는 생각이 들었어요. 그래서 이직 과정을 주제로 한 편의 글을 써 보려고 합니다.

이 글을 읽으시는 여러분들은 어떤 생각을 하실 지 모르겠습니다. 그냥 이런 사람도 있구나… 라는 생각으로 가볍게 한 번 읽어주시면 좋을 것 같아요.

만약 제가 1 년 후에 이 글을 봤을 때, 초심을 잃지 않고 있다면 좋겠다는 생각으로 써 봅니다.

내 커리어에서 자랑할 수 있는 점, 또는 부족한 점 생각해 보기

어필할 수 있는 부분

  • 첫 직장은 네트워크 장비 회사였기 때문에, 네트워크에 대해 어느 정도 이해하고 있다. 클라우드 기반으로 인프라를 구성할 때에도 이 점이 많은 도움이 되었다.
  • 아예 모르는 게 있어도 어떻게든 배워서 써먹었다. 처음에 데이터 파이프라인을 구축할 떄도 여기저기서 도움을 받아 5~6개월 만에 혼자 구축해 낼 수 있었다.
  • 팀이 커지면서 새로 합류한 사람이 있을 때, 적절하게 온보딩 프로세스를 제공해 본 경험이 있다.
  • 원래 낯을 많이 가리는 성격이지만, 내가 아는 것들을 대내/대외적으로 공유하려는 성향이 있다. 이런 점을 통해 조직 내/외부에 기여할 수 있다고 생각한다.

부족한 것들

  • 남들이 들었을 때 바로 알 수 있는 회사에 있어본 적이 없다. 게다가 커리어 흐름에 일관성이 없다. 임베디드 하다가, 공공 기관에 있다가, 교육 회사?
  • 대량의 트래픽을 겪어보지 못했다. 많은 트래픽을 순간적으로 받았을 때, 어떤 부분에 문제가 발생할 수 있는지 경험한 적이 거의 없다.
  • 특정 클라우드 벤더(AWS)에서 제공하는 서비스를 주로 쓰다 보니, 범용적으로 쓰는 기술 스택에 대해 질문이 들어오면 대답을 제대로 할 수 없다.
  • 표현력이 부족한 편이고, 특히 말로 뭔가를 설명해야 할 때 조리있게 설명하지 못할 때가 있다. 상황에 따라서는 싸가지 없다는 생각이 들 수도 있다.

회사를 선택한 기준

이전 직장에서는 데이터 엔지니어 겸 DevOps 엔지니어를 맡고 있다 보니, 다음에는 어떤 목표를 가지고 커리어를 이어 가야 할 지 많은 고민을 했습니다.

게다가 조금 부끄러운 이야기지만, 일을 하며 서버가 터질 정도의 트래픽을 겪어본 적이 없었습니다. 그래서 다음 회사에서는 좀 더 다양한 경험을 해 보고 싶었어요.

그러다 보니 처음에는 좀 더 큰 규모의 회사, 또는 제가 들어본 적이 있거나 서비스를 써 본 경험이 있는 회사를 먼저 찾았습니다.

하지만 커리어를 따져봤을 때, 그런 회사들에 어필할 수 있는 부분들이 없다는 생각이 들더라구요. 당연히 서류, 코딩 테스트, 면접 모두 결과가 좋지 않았습니다.

그러다 보니 눈높이를 낮추게 되었고, 주변 분들의 도움을 받게 되었습니다. 그러면서 제 나름대로 기준을 세워보기 시작했는데요. 제가 세운 기준은 다음과 같습니다.

제가 잘 모르는 회사인 경우, 아래와 같은 질문을 드리고 나서 지원 여부를 결정했습니다.

(1) 사업 모델

  • 기존 시장에 어떤 문제가 있다고 판단하였고, 이 문제를 어떻게 해결하려고 하는지?
  • 문제를 해결하는 과정에서 어떻게 수익을 창출할 것인지?
  • 경쟁사가 있다면, 다른 회사에 비해 어떤 차별성이 있는지?

(2) 투자유치 여부

  • 국책 연구과제에 의존하는 회사는 제외 (과제와 관련해서 대응하기 귀찮았던 적이 종종 있어서…)

(3) 조직 구조

  • CTO의 존재 여부: CEO 정도는 아니더라도, 의사 결정 시 개발 부서가 비개발 부서와 동등하게 의견을 제시할 수 있어야 함
  • (직급/지위 무관하게) 자유롭게 구성원 간 의견 제시 가능한지?
  • 실무자의 의견도 회사의 의사 결정에 적절하게 반영되는지? (특히 적절한 검토 없이 일정이 fix되는 경우가 있다면 지원하지 않음)
  • 개발 ↔ 기획, 사업, 지원 부서 간 협업 시 어려움은 없는지?
  • 개발 팀원 구성은 어떻게 되는지? (인원 수, 직무별 비중) ※ 주요 직무: 백엔드, 인프라, 프론트엔드, 데이터 엔지니어, 데이터 사이언티스트 등
  • 채용하려는 부서의 주요 이슈는 무엇인지? (예: 사업 확장, 결원 다수 발생)
    • 결원 다수 발생 시 이유가 무엇인지? 회사 차원에서 문제를 인지하고 있으며, 어떤 노력을 하고 있는지?

(4) 기타

  • 앱 또는 서비스의 경우, 실제 사용자의 리뷰 확인 (부정적인 평가가 많은 경우 지원하지 않을 예정)
    • 부정적인 평가의 예시
      • (게임의 경우) 확률에 의존하는 아이템이 많음
      • (소개팅 앱의 경우) 유료 아이템을 구입하였으나, 매칭이 제대로 되지 않음

헤드헌터나 제가 잘 모르는 회사의 채용 담당자로부터 제안을 받으면, 이 질문을 글로 써서 드렸습니다. 대개 4번 항목은 생략한 적이 많았습니다.

이렇게 질문을 드렸을 때, 제대로 답변을 받은 경우는 딱 한 번 있었습니다. 어떤 스타트업의 대표셨는데, 정말 친절하게 대답해 주셔서 감사했습니다. 아쉽지만 제가 도움을 드리기에는 저의 능력이 부족하다는 생각이 들어서, 조심스럽게 거절의 메시지를 드렸습니다.

응답이 없는 경우가 종종 있어서, 사람이 없으면 바쁘니까 그럴 수도 있겠다는 생각이 들었는데요. 심지어는 ‘그런 질문을 하실 바에는 사업을 하시죠’ 라는 답변을 주신 헤드헌터도 있었습니다.

앞으로 상황에 따라 질문은 바뀔 수 있을 것 같은데요. 스타트업의 경우는 1~3 번에 대해 좀 더 물어보고(특히 1, 2번), 어느 정도 알려진 회사라면 3번에 대해 좀 더 자세히 물어볼 것 같습니다.

최근 2년 간 지원했던 회사들과 결과

문제가 발생할 가능성을 막기 위해, 회사 이름이 드러나지 않도록 작성했습니다. 아래의 표시는 참고로 봐 주세요.

  • (H): 헤드헌터를 통해 지원한 경우
  • (A): 지인을 통해 지원한 경우

2020년 (총 5 건)

  • 판교에 있는 중견 IT 기업 / 플랫폼 경력 채용 / 과제 탈락
  • 글로벌 기업에 인수된 스타트업 / DevOps / 코딩 테스트 통과, 1차 면접 탈락
  • 네카라쿠배 중 한 곳 / SRE / 코딩 테스트 통과, 1차 면접 탈락
  • 네카라쿠배 중 한 곳의 자회사 / 데이터 관련 서비스 개발 / 2차 면접 탈락
  • 네카라쿠배 중 한 곳의 자회사 / 데이터 엔지니어 (H) / 코딩 테스트 탈락

2021년 (총 14 건)

  • 네카라쿠배 중 한 곳 / 커리어 전환 프로그램 / 코딩 테스트 탈락
  • 외식/배달 관련 서비스 회사 / DevOps / 서류 탈락
  • OTT 서비스 회사 / 데이터 엔지니어 / 서류 탈락
  • 네카라쿠배 중 한 곳 / 데이터 엔지니어 / 코딩 테스트 통과, 1차 면접 탈락
  • 패션 관련 쇼핑몰 / DevOps / 1차 면접 탈락 (코테 없음)
  • 대형 게임회사의 자회사 / 데이터 엔지니어 (H) / 임원 면접 탈락 (코테 없음)
  • O2O 스타트업 / 데이터 엔지니어 (H) / 서류 탈락
  • O2O 스타트업 / DevOps (H) / 1차 면접 탈락 (코테 없음)
  • 광고 관련 스타트업 / DevOps (H) / 1차 면접 탈락 (코테 없음)
  • 게임 회사 / DevOps (H) / 1차 면접 탈락 (1차 면접에 과제 포함)
  • 네카라쿠배 중 한 곳의 자회사 / AI 서비스 백엔드 개발자 (H) / 코딩 테스트 통과, 전화 인터뷰 탈락
  • 금융 관련 스타트업 / 데이터 엔지니어 (A) / 서류 탈락
  • 스타트업 / 데이터 엔지니어 (H) / 최종 합격 (코테 없음)
  • 스타트업 / DevOps (A) / 최종 합격 (코테 없음)

인상적이었던 전형 과정

여러 전형 과정을 겪다 보니 별별 일들이 있었습니다. 가장 기억에 남는 전형 과정을 추려서 써 보았습니다. 참고로 모두 다른 회사입니다.

(1) “왜 이 회사에 지원하셨나요?

면접 때 “왜 이 회사에 지원하셨나요?” 라는 질문을 받을 때가 있었습니다. 대개 위에서 말씀드렸듯이 트래픽이 많은 회사, 특히 교육 외 다른 분야의 회사에서 경험을 해 보고 싶다는 점을 강조했는데요. SRE로 지원한 회사에서 “왜 하필이면 이 회사에 지원하셨나요?“라는 질문을 들었을 때, “그냥 개발 문화가 좋은 것 같아서요.“라고 대답했었습니다. 당연히 탈락했는데, 지금이라면 “개발 블로그나 자체적으로 하시는 컨퍼런스를 보면서, 새로운 시도를 많이 하시고 이러한 것들을 공유하는 문화가 좋아 보여서 지원하게 되었습니다.” 라고 할 것 같습니다.

(2) 좋은 분위기로 끝나도 방심하지 말자

DevOps로 지원한 회사 중 한 곳에서는 1차 면접을 1시간 동안 진행하기로 되어 있었는데, 어쩌다 보니 1시간 20분 동안 면접을 진행하게 되었습니다. 혹시 좋게 봐 주신 거 아닌가 하고 기대를 했지만 결과는 탈락이었네요. 대개 분위기가 확실히 안 좋으면 탈락인 경우가 많았구요. 좀 애매하다 싶으면 통과할 때도 있었는데요. 좋은 분위기로 면접을 끝냈다고 방심해서는 안 되겠습니다.

(3) 오래 걸리는 전형

전형에 어마어마한 시간을 쏟는 곳들도 있었습니다. 기술 면접에 2 시간을 쓰는 회사가 있었구요. 면접과 시험을 포함하여 전형 하나에 4 시간 정도를 썼던 곳도 있었구요. (오후 반차를 썼는데 끝나고 나니 퇴근 시간이랑 비슷해졌네요) 또 다른 곳 중에는 코딩 테스트를 봤을 때 6시간 동안 시험을 보는 회사도 있었습니다. 6시간 동안 본 코딩 테스트는 통과했지만 전화 면접에서 밑천이 다 드러나서 망했습니다.

(4) 언제 결과가 나오나요?

결과가 나오는 데 1개월 넘는 시간이 소요되는 곳도 있었는데요. 한 곳은 1차 면접 결과가 나오는 데 1개월 정도가 걸렸습니다. 탈락했다고 생각했는데 갑자기 2차 면접을 보자고 하네요. 2차 면접이 끝나면 금방 결과가 나올 줄 알았는데 또 한 달이 걸렸습니다. 문의 메일을 보냈더니 2일 만에 탈락 메시지가 왔습니다.

이력서 피드백 모음

계속 면접이나 이력서에서 탈락하는 상황이 이어지면서, 이력서에 대한 피드백을 요청드린 적이 있습니다. 전 직장에서 다른 곳으로 이직하신 분과 헤드헌터 분을 통해 피드백 받은 내용은 다음과 같습니다.

  • 프로젝트 기한이 긴 편인데, 이에 비해 인상적인 결과가 부족하다는 생각이 듦
  • 업무 내용에서 어떤 어려움이 있었고, 어떻게 극복했는지 생각한 뒤 이를 이력서에 반영하면 좋을 것 같음
  • 바로 윗 레벨의 회사로 올라가는 건 어려울 수도 있음. 돌아가더라도 비슷하지만 좀 더 큰 규모의 회사로 이직을 해보면 좋을 것 같음 (제가 조언을 얻었던 두 분께서 비슷한 의견을 주셨습니다)
  • 전체적인 인프라 구성을 이력서에 표현하면 좋을 것 같은데, 문장으로 표현하는 것이 어려울 수도 있을 것 같음
  • (데이터 엔지니어로서) 수집, 정제, 활용 등 각 프로세스의 디테일이 부족함. 어떤 기술을 사용해서 어떤 것이 좋아졌는지 설명할 필요가 있음
  • 잘 하는 것을 윗부분에서 간략하게 소개해 주면 좋을 것 같음

이 자리를 빌어 도움 주신 분들께 정말 감사드립니다.

면접과 서류 피드백 모음

특히 헤드헌터를 통해 제안을 받은 경우, 탈락 시 피드백을 요청드렸습니다. 대부분 친절하게 피드백을 주셔서 감사했습니다.

제가 받은 피드백을 정리해 보면 다음과 같습니다. 개인적으로 굵게 표시한 부분 때문에 많은 생각을 하게 되었습니다.

  • 대형 게임회사의 자회사 / 데이터 엔지니어: 해당 파트를 리드해 주실 분을 찾고 있어서 진행하기 힘들다고 함 (임원 면접까지 본 뒤에 들은 내용임)
  • O2O 스타트업 / DevOps: Kubernetes 경험을 중요하게 생각해서 진행하기 힘들다고 함
  • 광고 관련 스타트업 / DevOps: 긴장하셨는지 실수를 하신 듯하고, 회사에서 기대한 수준에는 미치지 못하여 2차 인터뷰를 진행하지 않기로 함
  • O2O 스타트업 / 데이터 엔지니어: 테크 스택 자체는 비슷하신데, Hadoop 기반의 데이터 파이프라인 운영 경험을 중시하는 편이었음
  • 게임 회사 / DevOps: 혼자서 팀의 인프라를 구축하고 운영한 경험을 좋게 보았으나, 현재 팀에서 사용 중인 기술 스택과는 맞지 않았음 (특히 오픈 소스 사용 경험이 부족하다는 이야기를 들음)

최종 결정

저는 2021년 10월부터 식스샵에서 DevOps 엔지니어로 일하게 되었습니다.

식스샵은 코딩에 익숙하지 않더라도 쇼핑몰을 만들 수 있는 서비스입니다. 쇼핑몰을 디자인 할 때도 마우스를 이용하여 쉬운 방법으로 디자인 요소를 수정하거나 순서를 바꿀 수 있습니다.

참고로 제가 응원하는 축구 팀인 대구FC의 쇼핑몰이 식스샵으로 만들어진 사이트입니다. (식스샵으로 이직한 이유 중 하나이기도 합니다)

입사 초기에 온보딩 과정이 있는데, 온보딩 과정을 거치다 보니 식스샵을 이용한 사이트를 만나면 “이런 방법으로 만들었겠구나.“라는 생각이 먼저 들더라구요.

앞으로 어떻게 일해야 할까?

저는 회사에서 처음으로 DevOps 엔지니어로 입사하게 되었습니다. 회사에 계시는 여러 분들을 통해 많은 도움을 받고 있습니다.

그리고 업무를 진행하며, 어떤 방향으로 일을 해야 할지 고민하게 됩니다. 제가 생각한 방향은 다음과 같은데요.

  • (주로 클라우드 환경에서 일하다 보니) 특정한 클라우드 벤더에 의존하지 않는 방향을 고민한다.
  • 똑같은 문제를 반복해서 겪지 않기 위해, 기록하는 습관을 들이고 더 좋은 방법을 고민한다.
  • 예전에 해 봤던 것도 좋지만, 새로운 것에 적극적으로 도전한다.
  • 의견이 있으면 적극적으로 이야기 하자. 물어볼 게 있으면 고민하지 말고 물어보자.

현재 DevOps와 관련하여 혼자 실무를 담당하고 있지만, 점점 더 많은 분들과 협업을 하다 보면 방향이 바뀔 수도 있겠다는 생각이 들었습니다.

진짜 마무리

기술 스택의 측면에서 DevOps는 Kubernetes 및 컨테이너 관련 기술들, 데이터 엔지니어에게는 Hadoop이나 이에 기반하는 기술들을 요구하는 경우가 많았습니다. 전 직장에서 일했던 경험을 정리해 봤을 때, 그런 경험들이 부족해서 떨어진 경우가 많았던 것 같습니다. 그런 상황을 극복하기 위해 사이드 프로젝트도 진행해 봤는데요. 개인적인 생각으로는 사이드 프로젝트로도 부족하고, 프로덕션 환경에서 많은 사람들이 쓰는 기술을 써 본 적이 없다면 어필하기 힘들겠다는 생각이 듭니다. 또한 제가 주로 사용하는 언어는 파이썬이었는데, 백엔드 개발자로 일하고 싶다면 선택지가 많이 줄어드는 느낌이었습니다. 그나마 DevOps나 데이터 엔지니어로 지원했을 때는 지원 요건에 있는 경우가 종종 있어서 써 볼만 했습니다. 그렇다고 마냥 파이썬만 믿고 가기에는 어렵겠다는 생각이 들었는데요. 자바 및 스프링을 기반으로 하는 서비스들이 여전히 많고, Kubernetes, Terraform과 같은 툴은 고(Golang)로 작성된 경우가 종종 있다 보니 다른 언어도 써 봐야겠다고 생각했습니다.

또한 최근 몇 년 간 개발자 채용과 연봉 인상이 큰 이슈였습니다. 그만큼 사회적으로 개발자의 수요가 높아졌고, 대우가 점점 좋아진 것은 사실입니다. 저도 이런 상황에 따라 수혜를 입었다고 볼 수 있겠습니다. 하지만 기업 입장에서는 이러한 채용과 온보딩 과정에 큰 비용이 들기 때문에, 기업 규모에 관계 없이 많은 기업들이 채용 과정을 까다롭게 가져가려는 경향이 있다는 생각이 들었습니다. 주로 제가 약점으로 생각했던 부분은 기술 스택이나 대규모 트래픽의 경험이라고 생각했는데요. (코딩 테스트도 탈락한 곳이 몇 군데 있었지만, 이 부분은 꾸준히 연습함으로써 커버할 수 있다고 생각합니다) 이런 조건에 안 맞으면 서류 통과부터 걱정해야 하는 상황이었습니다.

역으로 회사의 입장에서 보자면, 스타트업이나 기술 기반의 기업이 아니라면 개발자를 채용하기 위해 어떤 점을 어필할 것인지 고민해 보아야 할 것 같습니다. 최근 개발자가 필요한 기업들은 자체적으로 테크 리크루터나 Developer Relation 부서를 두는 것에 비해, 개발자가 필요하다고 해도 크게 노력을 하지 않는 경우를 종종 보았기 때문입니다. 특히 대기업은 아닌데 어느 정도 규모가 있고 기술이 주력 사업이 아닌 회사들이 그런 경향이 있는 것 같습니다.

마지막으로, 채용 프로세스 중 관련 있으신 분들과 커뮤니케이션을 할 때 반성이 필요하다는 생각이 들어 사례를 남깁니다.

헤드헌터를 통해 어느 스타트업에 지원을 하게 되었습니다. 최종 합격과 처우 협의까지 끝난 상태였는데요. 그러다가 도중에 식스샵의 제안을 받고 전형 및 처우 협의를 마무리 지은 뒤, 카운터 오퍼를 요청드렸습니다. 제가 실수한 부분은 채용 담당자 뿐만 아니라 CEO까지 메일이 간 상태였고, 어조가 공격적이었다는 점이었습니다. (예를 들어, 언제까지 답변이 없으면 여기서 마무리하겠다…) 실수를 깨닫기에는 이미 늦었고, 헤드헌터와 회사에 사과 메일을 다시 보냈습니다. 결국 해당 회사에서는 커뮤니케이션 문제가 발생할 것 같다는 이유로 채용을 취소하셨습니다. 개인적으로는 헤드헌터를 통해서 지원을 했을 때, 이슈가 발생하면 헤드헌터에게 상황을 설명해 주는 것이 좋겠다는 점을 깨닫게 되었습니다. 또한 오퍼 레터가 와도 수락을 하든 거절을 하든 커뮤니케이션은 깔끔하게 마무리가 필요하다는 점을 깨달았습니다. 이 자리를 빌어 관련 있으신 분들께 죄송하다는 말씀을 드립니다.

읽어주셔서 감사합니다.