2024년 개발자 이직 회고

안녕하세요. yeTi입니다.
오늘은 10월 4일부터 시작하여 11월 19일에 마무리한 이직 과정을 회고해보고자 합니다.

현재 상황

2024년 10월 4일부터 2024년 11월 19일까지 약 200여곳에 지원하여 30여회의 면접을 보고 4곳의 회사에서 최종 오퍼를 받았습니다.

• T사 : 게임 도메인, 신규 팀 빌딩
• V가 : 번역 도메인, 시니어 개발자
• H사 : 주차 도메인, 개발자
• M사 : 명품 패션 도메인, 개발 리더

그 중 H사 를 선택하여 입사일을 기다리고 있는 상태입니다.

동기

금번 이직에는 동기가 없었습니다. 주어진 상황이었으니까요. (feat. 2024년 퇴사 회고 )

다만 누군가의 남편으로 삼형제의 아버지로서 가정 경제를 꾸려나가야 하는 역할을 지속해야하는 입장을 가지고 있었습니다.

목표

그 동안의 경험상 이직을 함에 있어서 무엇을 지향할 것인지에 따라 전략이 달라집니다. 따라서 명확한 목표와 그 목표를 달성하기 위한 태도를 가지는 것이 중요한데요.

이번 이직에서는 최대한 다양한 곳을 다녀보고 다양한 사람들을 만나보는 것을 목표로 했습니다.

왜냐하면 12년이 넘는 시간동안 해보고 싶었던 것들 경험해 봤고 다양한 문화들을 경험해봤다고 느꼈기 때문에 특정한 목표를 가지고 집중하기 보다는 보다 다양한 환경을 접해보는 것이 저에게 좋은 경험으로 남을 것 같았기 때문입니다.

그 과정에서 느낀 경험들을 아래에 나열해 봅니다.

구인의 욕망

최근에 크고 작은 기업들의 희망 퇴직 흐름에 구직을 희망하는 개발자가 많다는 사실을 다양한 분들로부터 받았습니다.

처음에는 이러한 상황이 취업에 대한 막연한 불안과 부담으로 다가왔었습니다.

그러나 면접을 다니면서 다양한 개발자, 팀장, 임원분들과 대화를 해보니 조직 입장에서도 마음에 드는 사람을 만나기 위한 노력을 많이 한다는 것을 느꼈고, 조직에 도움이 된다는 확신을 가지면 얼마든지 투자를 한다는 것도 느낄 수 있는 계기가 되었습니다.

그래서 일자리가 없는 것이 아니라 어디에서 누구와 어떤 조건으로 일을 하느냐의 문제로 인식이 변하게 되었습니다.

회사 리뷰

이번 이직 활동을 하면서 행동 양식을 바꾼 것이 하나 있습니다. 바로 잡플래닛이나블라인드의 회사 평가에 연연하지 않는다는 것입니다.

연연하지 않는다는 것의 의미가 리뷰를 안 본다는 것이 아니라 이 조직에는 이런 관점을 가지고 생활하는 분들이 계신다고 아는 정도로 참고한다는 것입니다.

이렇게 행동 양식을 바꾸게 된 이유는 그 동안의 경험에서 기인하여 조직이라는 곳에서 모두가 만족하는 환경을 만들 수 없다는 확신이 생겼기 때문입니다. 그래서 보다 중요한 것은 조직을 이끌어 가는 인사팀이나 리더, 임원분들의 관점에서 그들이 가지는 입장이 중요하다고 생각했습니다.

그래서 면접시에 권한을 가진 분들의 입장에 내가 공감이 된다면 그 조직은 괜찮다고 평가하게 되었습니다. 나머지는 조직의 문제가 아니고 만들어가는 일로 보였기 때문입니다.

면접관과 궁합

면접이라는 과정이 저는 운칠기삼의 영역으로 생각하고 있습니다.

왜냐하면 한 사람의 역량을 몇 페이지의 이력서와 몇 시간의 대화, 기타 역량 평가의 절차로 알아차릴 수 없다고 믿기 때문입니다. (물론, 확률적으로 괜찮은 역량을 가진 사람일 확률이 높아지긴 합니다.)

게다가 사람은 이성적 동물이 아닌 감성적 동물이라고 믿기 때문에 면접관의 판단이나 평가조차 주관적이고 환경적이라고 믿습니다.

이러한 배경을 가지고 면접을 보다보면 이상하게 말이 꼬이는 면접관의 스타일이 있는 반면 대화하듯이 말이 풀리는 면접관이 있다고 느껴졌습니다.

그리고 당연하게도 대부분의 좋은 결과는 말이 잘 풀리는 면접 시간에서 만들어졌습니다.

한편으로는 저라는 동일한 경험과 동일한 이력서를 바탕으로 왜 그런 차이가 있는지 궁금하기도 합니다. 대략적으로 추정해보면 저는 단편적인 답을 말해가는 분위기보다 맥락이나 배경을 기반으로 인생에 대한 이야기를 할 때 좋은 말들이 나온다는 것을 느꼈습니다.

가령, MSA의 장/단점이 뭔가요? 라는 질문을 하는 면접관보다 MSA라는 것을 어떻게 생각하세요? 라는 질문을 하는 면접관과 대화할 때 대화의 폭이 넓어지고 저의 충분한 입장을 전달할 수 있는 시간을 가지는 경우가 많았습니다.

글을 쓰며 생각해보니 질문을 나에게 맞게 바꿀 나갈 수도 있다는 생각이 듭니다. 순간적으로 경험의 문제로 인식이 바뀌기도 합니다.

면접관을 공감하기

면접을 보다보면 가끔 그런 느낌이 들기도 합니다.

이 회사는 나를 뽑을 생각이 없어 보이는데. 무엇인가를 얻고 싶은 느낌이야.

그래서 때로는 면접관과 특정 주제를 두고 공감대를 형성하며 대화를 하기도 하고, 때로는 면접관이 궁금해하는 것들을 저의 입장에서 말해주기고 하고, 때로는 면접관을 응원해주기도 했습니다.

모든 상황에서 결과적으로는 불합격을 했지만 면접이라는 과정이 다양한 욕망속에서 발생할 수 있다는 것을 느끼기도 했습니다. 때로는 에너지를 많이 뺐겨 기분이 나쁘기도 하지만 역으로 저라는 사람을 알리는 기회로 생각하여 긍정적으로 생각하고 넘어가는 편입니다.

SI업계

이번 이직의 컨셉상 SI회사에도 다양하게 만남을 가졌습니다.

업계의 비즈니스 특성 때문인지 개발자의 역량보다는 인성과 단가를 맞춘다는 느낌이 강했습니다.

때로는 5분만에 면접이 끝나는 경우도 있었고, 대부분의 경우에는 그냥 이런저런 얘기하다가 나온다는 느낌이었습니다.

그래서 면접이 끝난 경우 어떻게 괜찮은 개발자인지 판단할까? 그런 것이 중요한 시장이 아닌가? 라는 생각이 스치는 경우가 많았습니다.

메타 인지의 과정

한달이라는 시간동안 30여회의 만남을 가지다 보니 메타 인지를 할 수 있는 기회가 되기도 했습니다.

나라는 사람의 경쟁력을 인식할 수 있는 계기가 된 것이죠.

나라는 사람의 경험에 흥미를 가졌던 조직은 대체로 새롭게 개발팀을 꾸리거나 기존의 개발팀에 변화를 주고 싶은 조직이었습니다. 더하여 기능 조직보다는 목적 조직을 지향하는 조직에서 긍정적인 입장을 가진다는 것을 느꼈습니다.

이러한 피드백이 단순이 적합한 조직을 찾는데 그치지 않고 저라는 사람이 추구하는 삶의 방향성과도 연결된다는 것을 느꼈습니다.

특히 최종적으로 두 회사 사이에서 선택하는 시간에 고민을 하면서 나다움을 가장 드러내는 순간은 특정 역할에 구애받지 않고 자유롭게 만들어 나갈 때라는 것을 알아차리게 되었습니다.

개발자 역량 점검

개발자의 역량을 점검하기 위해 다양한 것들을 시도한다고 느꼈습니다.

코딩 테스트, 과제 전형, 코드 리뷰 테스트, 화이트보드 코딩 테스트, 화이트보드 설계 테스트, 라이브 코딩, 역량 평가

각각에 대해 느낀 점들을 공유해보고자 합니다.

코딩 테스트

저는 개인적으로 코딩 테스트에 취약하다고 생각합니다. 그래서 정말 쉬운 문제들이 나와서 전형에 통과하는 편입니다.

실무를 경험한 개발자 입장에서 코딩 테스트가 가지는 의미가 코딩이라는 것을 할 줄 아는 분이다는 것을 식별하는 것 외에 무엇이 있을지 잘 모르겠습니다.

따라서 제가 도입을 한다면 쉬운 문제 위주로 실무에서 사용하는 자료 구조를 활용하는 방향성 내에서 출제를 할 것 같습니다.

과제 전형

개발자의 전반적인 역량이나 스타일을 보는데 적합한 전형이라고 생각합니다.

다만, 단점은 지원자의 시간과 노력을 많이 요구하는 전형이라 부담이 커서 전형 포기 확률이 높다고 알고 있습니다.

따라서 제가 도입을 한다면 실무에서 필요한 수준의 주제를 제공하되 AI를 적극적으로 활용하도록 가이드할 것 같습니다.

코드 리뷰 전형

O사 와 G사 에서 해당 전형을 경험한 적이 있습니다.

실무에서 코드 리뷰는 자연스럽게 자주 마주해야 한다고 생각하기 때문에 코드 리뷰 전형은 효율적으로 지원자의 역량을 평가할 수 있다고 생각합니다.

지원자 입장에서 시간을 많이 투여하지 않아도 되었고, 회사 입장에서도 커뮤니케이션 방식이나 정적분석, 프레임워크의 이해도까지 함께 볼 수 있기 때문이라고 생각합니다.

따라서 저라면 긍정적으로 도입해볼 것 같습니다. 다만 평가 기준을 명확하게 가져가는 것이 숙제라고 생각합니다.

화이트보드 코딩 전형

해당 전형은 M사 에서 한 번 경험을 했는데요. 생각보다 재미있는 과정이라고 생각했습니다.

면접관과 실시간으로 피드백을 주고 받으며 문제 정의하는 과정이나 해결책을 제시하는 과정, 해결책을 개선하는 과정까지 개발자라면 가져야할 역량을 검증할 수 있는 과정이라는 생각이 들었습니다.

다만, 이 경우 면접관의 노력이 많이 들어가기 때문에 회사의 입장에서 부담이 많이 가는 전형이라고 생각이 들었습니다.

따라서 저라면 도입에 대해 부정적인 면이 있습니다.

화이트보드 설계 전형

해당 전형은 M사 와 H사 에서 경험을 했습니다.

저에게는 어려운 전형으로 느껴졌습니다. 왜냐하면 설계라는 것이 해당 도메인에 대한 이해와 조직이 도메인을 바라보는 관점에 대한 이해, 주어진 조직의 상황과 인원 구성에 따라서 다르게 적용될 수 있다고 생각하기 때문입니다.

그런데 한 시간이라는 제약사항에서 어떻게 풀어나가야 면접이라는 요소에서 좋을 성과로 이어질지 잘 모르겠었습니다. 그러다보니 막연하게 화이트보드에 막연하게 개념들을 나열하고 흐름도를 작성하는 수준에서 면접 시간을 가지게 되었습니다.

결과적으로는 합격/불합격이 각각 있었습니다.

따라서 저라면 도입을 하지 않을 것 같습니다. 이유는 전형에 대한 이해가 부족하다고 생각하기 때문입니다.

라이브 코딩 전형

H사에서 회사에서 노트북 및 IDE & 코드 베이스를 제공하고 코드를 개선하며 대화하는 시간을 가졌습니다.

나름대로 재미있게 대화하는 시간을 가졌습니다. 프레임워크에 대한 이해도나 코딩 스타일, 설계 관점, 코딩 역량까지도 함께 볼 수 있다고 생각했기 때문입니다.

하지만 최근 AI와 협업하는 개발자가 늘어나는 가운데 개발자가 혼자하는 라이브 코딩이 어떤 의미를 가질지 의구심이 들기도 합니다. 추가적으로 면접관들의 시간과 노력도 함께 들기 때문에 전형을 유지하는 비용이 높다고 생각합니다.

따라서 저라면 해당 전형을 도입하지 않을 것 같습니다.

역량 평가 전형

T사 에서 사전 역량 평가라는 것을 경험했는데요. 2시간여 가량을 인적성 검사 같은 것을 진행했습니다.

해당 전형을 진행하면서 내가 뭘 위해서 이것을 하고 있나 라는 생각을 몇번을 할 정도로 동기부여가 안되었던 전형이기도 했습니다.

따라서 저는 해당 전형은 도입하지 않을 것 같습니다.

결론

갑작스러운 퇴직은 가정에 위기로 인식이 되기도 했습니다.

하지만 위기를 기회로 전환한다는 생각으로 이번 기회에 마음껏 회사를 지원해보고 마음껏 만나보자는 생각과 행동이 결과적으로 메타 인지를 강화하고 개발자 취업이라는 시장의 시야를 넓히고 다양한 비즈니스의 이야기를 들으면서 삶의 다양성을 느낄 수 있던 기회가 되었습니다.

나아가 이번 경험을 통해 주변분들의 도움이 큰 힘이 된다는 것을 느끼는 순간이었고, 삶과 커리어가 정렬되었을 때 스트레스가 아닌 재미의 요소로 다가올 수 있다는 것을 느낀 순간입니다.