이직을 결정하다
이직을 하게 되었다.
이런저런 이유가 있었지만, 결국 원하는 회사로 옮기고 싶어 내린 결정이었다. 다만 내가 떠난 뒤에는 현재 담당하고 있는 업무를 이어갈 사람이 필요했다. 이로 인해 아주 짧은 기간 동안 채용 담당자가 되어 이력서 검토부터 기술면접까지 참여하게 되었다.
지금까지는 항상 지원자의 입장에서 채용을 경험했지만, 이번에는 반대편에 앉아 누구를 뽑을지 고민했다.
그 전체 과정을 회고해 보려고 한다.
왜 이직을 하게 되었나
우리 회사는 빠르게 다양한 PoC를 진행하는 스타트업이었다. 여러 시도가 시장에서 좋은 반응을 얻으면서 매출도 가파르게 성장했다.
그 조직에서 성과가 즉각적으로 드러나는 주력 서비스의 개발을 담당할 수 있었던 것은 큰 행운이었다. 하지만 아직 안정권에 들어서지 않은 서비스의 매출은 일정하지 않았다. 상승세와 하락세가 반복됐고, 사업과 조직에도 여러 변화가 생겼다. 이런 과정에서 나 역시 앞으로의 커리어를 다시 고민하게 되었고, 그 고민이 이직을 결심하는 계기가 되었다.
그렇게 여러 회사에 이력서를 제출했다. 생각보다 많은 곳에서 서류 합격 연락을 받았고, 운 좋게도 인터뷰 결과도 긍정적이었다. 최종적으로는 내가 원하는 곳을 선택해 이직을 결정할 수 있었다.
그러나 나의 퇴사는 곧 조직의 인력 공백으로 이어진다. 특히 빠르게 움직이는 스타트업에서 한 사람의 공백은 생각보다 크게 느껴질 수 있다. 퇴사 면담에서도 이런 우려를 전달받았고, 나 역시 맡은 소임을 최대한 마무리하고 떠나고 싶었다.
예상하지 못한 채용의 시작
처음부터 대체 인력 채용에 직접 참여할 계획은 없었다.
현재 진행 중인 프로젝트를 마무리하고 퇴사하기로 합의했지만, 우연한 계기로 후임 채용도 함께 시작되었다.
왜 이렇게 되었을까..
사실, 퇴사 면담 이후 지인에게 이직 소식을 알렸고, 그 지인이 후임자로 적합할 것 같은 사람을 추천해 주었다. 빠르게 후임자를 채용할 수 있다면 업무 공백을 최소화할 수 있을 것 같았다.
나는 CTO님께 추천받은 분의 이력서와 함께 인터뷰 의사를 여쭈었다. CTO님도 긍정적으로 검토하셨고, 곧바로 인터뷰 일정이 잡혔다.
이 상황을 공유받은 다른 임원분이 정식 채용 공고를 올리면서 채용은 예상보다 큰 규모로 진행되었다. 그렇게 나는 어느새 여러 지원자의 이력서를 함께 검토하고 있었다.
지금까지 채용 과정에서는 항상 지원자였다.
어떻게 해야 합격할 수 있을지를 고민했지만, 이번에는 누구를 합격시켜야 하는지를 고민하게 되었다.
서류 검토
채용 공고가 올라간 뒤 이틀 동안 40명 이상의 지원자가 몰렸다.
경력 무관 공고였고, 당시 흔치 않았던 Flutter 개발자 채용이었기 때문에 많은 지원자가 관심을 가져준 것 같다.
모든 이력서를 내가 직접 검토한 것은 아니었다. 1차로 검토된 이력서 중 실무적인 판단이 필요한 지원서가 나에게 전달되었다.
지원자의 경력은 신입부터 4년 차까지 다양했다.
경력이 있는 지원자는 관리 역할이나 제품 기획에 참여한 경험을 가지고 있었다. 신입 지원자의 이력서에는 여러 프로젝트를 비롯해 부트캠프, 대회수상, 동아리 같은 다양한 활동이 담겨 있었다. 이것이 현 개발자 채용시장의 현주소다. 다들 스펙이 매우매우 좋았다.
어떤 기준으로 서류를 검토했는가
돌이켜보면 가장 먼저 개선했어야 할 것은 면접 질문이 아니라 채용 공고였다.
우리는 공고에 사용하는 기술 스택과 원하는 인재상을 담았지만, 당시 조직이 처한 상황까지 충분히 전달하지는 못했다.
우리가 찾던 사람은 단순히 Flutter로 기능을 개발할 수 있는 사람이 아니었다. 합류 후 짧은 시간 안에 운영 중인 앱을 인수하고, 문제가 생겼을 때 스스로 원인을 파악해야 했다. Flutter뿐만 아니라 Android와 iOS의 네이티브 코드, 외부 SDK 연동, 앱 배포와 운영 이슈까지 마주할 가능성이 컸다.
하지만 지원자는 이런 상황을 알 수 없었다.
지원자가 알 수 없는 조건을 기준으로 이력서를 평가하면서 자연스럽게 검토 기준은 높아졌다. 일반적인 경력 무관 Flutter 개발자 공고에 지원했지만, 실제로는 비교적 빠른 시일 안에 서비스의 운전대를 잡을 수 있는 사람을 찾고 있었던 셈이다.
조직 내부의 상황을 조금 더 정리해 공고에 표현했다면 어땠을까 하는 아쉬움이 남는다. 지원자에게도 합류 후 기대받는 역할을 미리 판단할 기회가 필요했기 때문이다.
서류에서는 여러 항목을 살펴봤지만, 가장 중요하게 본 것은 프로젝트 경험이었다.
어떤 기능을 만들었는지뿐만 아니라 그 안에서 어떤 역할을 담당했는지, 문제를 어떻게 발견했고 어떤 판단을 내렸는지를 확인하려 했다. 기술 자격이나 외부 활동, 학습 경험 등은 주요 판단을 보완하는 요소로 활용했다.
검토 결과 기술면접에 모실 지원자는 네 명 정도로 정리되었다.
채용 일정이 촉박했던 만큼 더 많은 분을 면접에 모시기는 어려웠다. 이 과정에서 충분한 역량이 있음에도 함께 이야기하지 못한 지원자가 있었을 것이라는 아쉬움이 남는다.
기술면접
각각의 이력서를 최대한 꼼꼼하게 읽다 보니 궁금한 점이 꽤 많았다. 지금 생각해 보면 궁금했다기보다는 흥미롭게 느껴진 내용에 가까웠던 것 같다.
프로젝트에서 어떤 역할을 맡았는지, 특정 기술을 선택한 이유는 무엇이었는지, 문제를 해결하는 과정에서 어떤 판단을 내렸는지 물었다.
이력서에 적힌 결과만 확인하기보다 그 결과에 도달한 과정을 듣고 싶었다.
이력서에 작성된 경험 외에도 Flutter의 기본적인 동작 원리에 관해 질문했다.
Dart의 Isolate가 무엇인지, StatefulWidget과 State의 생명주기는 어떻게 흘러가는지, 상태관리는 왜 필요한지, InheritedWidget은 어떤 역할을 하는지 등을 물었다. 우리 업무의 특성상 Flutter와 네이티브 영역이 MethodChannel을 통해 어떻게 통신하는지도 함께 질문했다.
처음에는 이런 질문이 너무 기초적이지 않을까 고민했다.
실제 개발에서는 상태관리 라이브러리와 다양한 패키지를 사용한다. 각각의 개념을 직접 구현하거나 항상 의식하지 않아도 기능을 만드는 데 큰 문제가 없을 수 있다. 그러나 우리가 채용하려는 사람은 새로운 프로젝트에 합류해 여유롭게 학습할 수 있는 상황이 아니었다. 이미 운영 중인 앱을 넘겨받아야 했고, 문제가 발생하면 직접 원인을 좁혀야 했다.
화면이 예상하지 못한 시점에 다시 그려진다면 위젯과 State의 생명주기, 상태의 소유 위치를 살펴볼 수 있어야 한다. 무거운 작업으로 UI가 멈춘다면 Dart의 실행 구조와 Isolate를 떠올릴 수 있어야 한다. 하위 위젯까지 상태가 전달되는 과정에서 문제가 생겼다면 상태관리 도구의 사용법뿐만 아니라 그 기반에 있는 InheritedWidget의 역할을 이해하는 것이 도움이 된다. Flutter 코드에서는 정상적으로 보이지만 네이티브 SDK와 연동하는 과정에서 문제가 발생한다면 MethodChannel의 호출 구조와 각 플랫폼의 실행 흐름을 확인해야 한다.
물론 이런 개념의 정의를 정확히 말하지 못한다고 해서 문제를 해결하지 못하는 개발자라고 단정할 수는 없다.
반대로 개념을 유창하게 설명한다고 해서 실무 문제를 잘 해결한다고 보장할 수도 없다.
내가 확인하고 싶었던 것은 정의를 외우고 있는지가 아니었다.
문제가 발생했을 때 해당 현상을 어떤 구조와 연결해서 바라보는지, 원인을 좁혀갈 수 있는 기준을 가지고 있는지가 궁금했다.
특정 라이브러리를 사용할 줄 아는 것뿐만 아니라, 라이브러리가 예상과 다르게 동작할 때 그 아래의 구조까지 내려가 문제를 바라볼 수 있는지를 확인하고 싶었다.
합류 후 바로 기존 앱이라는 버스의 운전대를 잡아야 했다. 충분한 온보딩 기간도, Flutter 문제를 함께 살펴볼 다른 개발자도 보장하기 어려웠다. 따라서 특정 라이브러리를 사용해 본 경험뿐만 아니라, Flutter의 동작 방식을 실제 문제와 연결해 사고할 수 있는지를 중요하게 볼 수밖에 없었다.
개념을 아는 것과 문제를 해결하는 것
면접을 진행하면서 한 가지 어려움도 느꼈다.
기초 개념을 묻는 질문은 답변 여부가 비교적 명확해 보여 평가하기 쉽다. 하지만 그것만으로 지원자의 문제 해결 능력까지 판단하기는 어려웠다.
어떤 지원자는 개념을 매끄럽게 설명하지 못했지만, 실제 프로젝트에서 발생한 문제와 해결 과정을 구체적으로 이야기했다. 반대로 개념적인 답변은 잘했지만 그 지식을 실제 경험과 연결하는 과정에서는 답변이 모호해지기도 했다.
결국 개념 질문의 정답 여부뿐만 아니라, 해당 개념을 실제 경험과 연결할 수 있는지를 함께 살펴보려 했다.
StatefulWidget과 State의 생명주기를 설명한 뒤에는 실제로 생명주기와 관련된 버그를 겪어본 적이 있는지 질문했다.
상태관리 도구를 사용한 경험에 대해서는 왜 그 도구를 선택했는지, 상태의 범위와 소유 위치를 어떻게 결정했는지를 물었다.
Isolate 역시 정의를 묻는 데서 끝내지 않았다. 어떤 작업을 별도로 분리하는 것이 적절한지, 모든 비동기 작업에 Isolate가 필요하지는 않은 이유가 무엇인지 이야기를 이어갔다.
이력서에 적힌 경험을 중심으로 Flutter의 기본적인 동작 원리와 어떻게 연결되는지를 보고 싶었다.
배운 점
이 과정에서 과거 내가 받았던 기술면접 질문들을 다시 생각하게 되었다.
지원자일 때는 실무에서 프레임워크가 알아서 처리해 주는 내용을 왜 물어보는지 의문이 들 때도 있었다.
하지만 운영 중인 프로젝트를 넘겨받을 사람을 찾는 입장이 되자, 면접관이 기본적인 개념을 묻는 이유를 조금은 이해할 수 있었다.
평소에는 프레임워크와 라이브러리가 많은 부분을 대신 처리해 준다. 그러나 추상화가 의도대로 동작하지 않는 순간에는 결국 그 아래의 구조를 이해해야 문제의 원인을 좁힐 수 있다.
다만 이런 질문이 모든 Flutter 채용에서 반드시 동일한 중요도를 가지는 것은 아니다.
충분한 온보딩 기간이 있고 여러 개발자가 함께 문제를 해결할 수 있는 조직이라면 잠재력과 성장 가능성을 더 중요하게 볼 수 있다. 반면 당시 우리 조직은 기존 서비스를 빠르게 인수할 사람이 필요했다.
같은 지원자라도 조직이 처한 상황과 채용 시점에 따라 평가가 달라질 수 있다는 의미다.
나는 완벽한 채용을 진행했을까
결과적으로 우리는 당시 조직의 상황과 인터뷰에서 확인한 역량을 바탕으로 새로운 분을 모실 수 있었다.
그러나 과연 나는 완벽한 채용을 진행했다고 말할 수 있을까
촉박한 일정과 불충분한 채용 공고
촉박한 일정은 자연스럽게 지원자의 검증 기준을 높였다.
충분한 역량과 성장 가능성이 있었지만 당시 우리가 요구한 즉시 전력의 기준과 맞지 않아 함께하지 못한 지원자도 있었을 것이다.
다시 돌아간다고 해도 퇴사 일정을 늦추거나 채용 기간을 크게 늘리기는 어려웠을 것 같다.
그러나 채용 공고는 개선할 수 있었다.
합류한 뒤 어떤 역할을 담당하게 되는지, 기존 서비스를 어느 정도 독립적으로 인수해야 하는지, Flutter 외에 네이티브 연동과 앱 운영 경험이 왜 필요한지를 조금 더 명확하게 적었어야 했다. 지원자가 자신의 적합성을 판단하려면 회사 역시 현재의 상황과 기대하는 역할을 충분히 공개해야 한다.
조직이 원하는 조건을 제대로 설명하지 않은 채, 지원자가 그 조건을 충족하는지만 평가하는 것은 공정한 과정이라고 보기 어렵다.
기술면접에서의 태도
기술면접을 진행하면서 지원자가 자신의 경험과 생각을 최대한 잘 표현할 수 있도록 분위기를 만들었어야 했다.
하지만 지원자의 답변이 내가 기대한 방향과 다르거나 아쉽게 느껴졌을 때, 그 감정이 표정이나 반응에서 드러났을 수도 있다.
그것은 지원자의 잘못이 아니다.
질문을 건넨 내가 의도를 모호하게 전달했을 수도 있다. 질문의 범위가 너무 넓거나, 지원자의 경력에 비해 지나치게 깊은 내용을 물었을 가능성도 있다. 지원자의 첫 답변이 내가 생각한 방향과 다르더라도, 질문을 다시 정리하거나 구체적인 상황을 제시해 답변을 이어갈 수 있도록 도왔어야 했다.
면접관은 질문을 던지는 사람이면서 동시에 지원자가 가진 경험을 충분히 꺼낼 수 있도록 돕는 사람이기도 하다.
미래에 다시 면접관을 맡게 된다면 지원자가 질문의 의도를 명확히 이해할 수 있도록 정돈된 질문을 건네고 싶다.
정답을 맞히는 자리가 아니라 서로의 경험과 생각을 확인하는 대화가 될 수 있도록, 지원자가 어떤 답변이든 편하게 제시할 수 있는 분위기를 만들고 싶다.
불합격이 반드시 부족함을 의미하지는 않는다
채용에 참여하기 전까지 나는 서류전형이나 면접에서 불합격하면 주로 내 부족함부터 찾았다.
경험이 부족했는지, 답변을 제대로 하지 못했는지, 이력서가 매력적이지 않았는지를 되짚었다. 실제로 부족한 부분을 찾아 개선하는 과정은 필요하다.
하지만 이번 경험을 통해 채용의 결과가 지원자의 역량만으로 결정되지는 않는다는 것을 알게 되었다.
채용하는 조직에는 지원자가 알 수 없는 사정이 있다. 당장 해결해야 하는 문제가 있을 수 있고, 충분한 온보딩 기간을 제공하지 못할 수도 있다. 기존 구성원에게 부족한 경험을 가진 사람을 찾을 수도 있고, 특정 시점에는 잠재력보다 즉시 업무를 수행할 수 있는 역량이 더 중요할 수도 있다.
이번 채용 역시 그랬다.
경력 무관 공고였지만, 실제로는 짧은 시간 안에 운영 중인 앱을 인수할 수 있는 사람이 필요했다. 지원자가 이력서와 면접을 아무리 잘 준비하더라도 미리 알기 어려운 조건이었다. 신입이라면 빠르게 새로운 기술을 학습하고 구현했던 경험을 강조했다면 좋았을 것이다.
이번 채용에서 불합격한 모든 지원자님들은 다른 회사에서는 충분히 합격할 수 있는 분들이라고 생각한다.
조직의 상황과 채용 시점이 달랐다면 결과 역시 달라졌을 것이다.
따라서 채용에서 불합격했다는 사실을 자신의 전체적인 가치에 대한 평가로 받아들일 필요는 없을 것 같다.
통제할 수 있는 이력서와 답변은 계속 개선해야 한다. 하지만 아무리 되짚어도 명확한 이유를 찾을 수 없다면, 내가 알 수 없는 회사의 내부 상황이 결과에 영향을 줬을 가능성도 있다.
반대로 어떤 회사가 나를 선택했다는 사실 역시 내가 다른 지원자보다 모든 면에서 뛰어났다는 의미는 아닐 것이다.
그 시점에 회사가 필요로 한 역할과 내가 가진 경험이 잘 맞았다는 것일지 모른다.
마무리하며
나는 운이 좋은 개발자였다고 생각한다.
함께 일했다는 사실이 영광스럽게 느껴질 정도로 좋은 동료들과 스타트업에서 다양한 경험을 했다. 성과가 빠르게 드러나는 서비스를 담당했고, 기술뿐만 아니라 서비스 운영과 비즈니스에 관한 값진 경험도 얻었다.
퇴사를 준비하는 과정에서는 이력서 검토와 기술면접까지 참여했다. 아직 경험이 많지 않은 개발자에게는 과분할 정도로 값진 경험이었다.
아주 짧은 기간이었지만 지원자와 면접관의 자리를 모두 경험하면서 채용은 가장 뛰어난 사람을 순서대로 선발하는 과정이 아니라는 것을 알게 되었다.
채용은 그 시점의 조직이 가장 필요한 사람을 찾는다.
지원자는 회사의 모든 상황을 알 수 없고, 면접관 역시 짧은 이력서와 제한된 면접만으로 지원자의 모든 역량을 알 수 없다. 채용은 양쪽 모두 불완전한 정보를 가지고 중요한 결정을 내리는 과정이었다.
이 경험을 바탕으로 다음 조직에서는 단순히 기술을 잘 다루는 개발자가 아니라, 팀이 처한 상황을 이해하고 필요한 역할을 채울 수 있는 개발자가 되고 싶다.