[스타트업] 파비의 인재 채용과 복지 – 3

0
473

여느 IT 스타트업과 마찬가지로, 파비에서도 개발자 채용이 쉽지 않다. (사실 모든 자리에 채용이 쉽지 않다ㅋ) 외부 요인만 보면, 개발자 공급대비 수요가 훨씬 더 많고, 투자금이 남아도는 몇몇 스타트업들이 엄청난 금액을 질러대면서 개발 인력들을 데리고 가기 때문이다. 더 중요한 내부 요인을 보면, 작은 회사라고 피하는 사람들이 대부분인데, 우리는 눈이 높다. 우리 나름대로는 합리적인 기준이라고 세워놨는데, 기본기만 보고 있는데, 다른 회사들은 안 그런지 주변에선 다들 높다고 그러더라. 그런 질러대는 스타트업도 우리보다 채용 기준이 덜 빡빡하다고, “니네가 네X버, 카X오도 아니면서 그렇게 뽑으려면 사람이 어떻게 뽑히냐?”는 질문을 받는데, 우리가 그런 대형 IT회사는 아니지만, 그래도 나름대로의 꼰대스러운 기준을 좀 갖고 있고 싶다.

왜? 세상에 땅파서 장사하는 회사 없다. 오신 분들이 업무를 해서 결과물이 나와야 우리도 돈 벌고, 보너스도 드리고, 연봉도 올려드리지 않겠나? 우리 업무의 일부를 “할 수 있다”고 주장하는 많은 분들이 가지고 있는 문제들을 어느 스타트업 투자 전문가 분이 이렇게 표현하시던데

Your ego writes a check that your body can’t cash

공감이 참 많이 되더라. 같이 일하다보면 왜 이렇게 실력이 없지? 왜 이렇게 커뮤니케이션을 못하지? 라는 생각이 드는 분들이, 그렇게 빡빡하게 골라서 채용했지만, 은근히 있기 때문이다. (물론 문제는 많은 경우에 쌍방임을 인정한다.)

그런데 1시간 남짓 만나보고 어떻게 결과물이 잘 나올지를 파악하냐고? 우리랑 잘 맞을지 어떻게 파악하냐고? 100명 남짓의 개발자 면접을 보고 얻은 경험을 바탕으로 아래에 나름대로의 기준을 소개해본다.

(언젠가 1,000명을 만나보고 나면 또 달라질 수도 있음을 미리 인정한다.)

1. 블록체인, 인공지능 같은 단어가 들어간 이력서 Out!

이력서에 블록체인 회사에 다녔다는 단어가 들어가 있으면 일단 의심의 눈초리를 뜬다. 거기서 빨리 도망나오지 않고 길게 다녔다고 그러면 보통은 Out이다.

인공지능 어쩌고하면서 제대로 수학 공부한 티가 안 나는 개발 이력서도 자동 Out이다. 블로그도 운영하고, 포트폴리오도 있다고 그래서 GitHub 페이지들도 보지만, 아직까지 Keras 프레임워크 갖다 쓸 줄 아는 수준 이상의 개발 인력을 단 한 명도 본 적이 없다. 아마 장담컨데, 시장 상태가 지금처럼 유지된다면 앞으로 오랜 시간동안 학부 회귀분석 이상의 수학적인 이해도를 갖춘 인력을 볼 일이 없을 것이다. 개발은 수학 훈련을 받은 사람들의 직군이 아니니까.

이건 꼭 인사 업무자나 데이터 사이언티스트들의 관점만이 아닌게, 개발팀장님이 어느 날 면접 끝내고 이렇게 말씀하시더라.

백엔드 한다면서 당장 자료구조론의 기초도 모르는데, 집에가서 전공 교과서 보고 쫓아오기 바빠야될 사람이 블록체인이니 인공지능이니 이러고 있으면서 온라인 커뮤니티 돌아다니면 안 되는거 거든요.

몇 달 지났지만 잔뜩 찌푸린 얼굴이 아직도 생생하다.

속칭 인공지능이라는 데이터 패턴 매칭 지식이 단순한 프레임워크 베껴쓰는 수준의 지식이 아니라, 엄청나게 긴 시간 동안 책으로 배워야하는 지식, 손으로 수식을 써가며 이해해야하는 지식, 대학원 연구실에서 머리를 쥐어짜며 습득해야하는 지식, 이쪽 지식으로 수학 실력 없으면 나가리되는 박사과정이 있다는 사실을 전혀 인지 못하고 있는 것과 똑같은 맥락으로, “머신러닝 엔지니어” 라는 타이틀이 그냥 하다보면 배우게 되는 거겠지라고 생각하고 있는 것이다.

(가끔 이력서 뒤지다가 머신러닝 엔지니어라고 써 놓은 사람들 골탕 먹이려고 전화해서 그냥 Keras 코드 베낀 경험 있는 Copy & Paste 전문가라고 이력서 타이틀 바꾸라고 냉소지으려다가 그냥 참고 넘어간다ㅋㅋ)

블록체인도 파비의 시리즈 글에 나와있듯이 온갖 문제점을 가진 하나의 보안 시스템에 불과한데, 비트코인을 위시한 코인 열풍에 휩쓸려가는 추종자형 인간이 아니라면 진작에 발을 빼는게 당연하지 않을까? 지구가 평평하다고 믿는 광신도들 무리에 들어갔더라도, 합리적인 판단을 하는 인간이라면 과학적 근거를 이해하고 그 광신도 무리에서 발을 뺄 것이다.

개발 지식 중에는 손으로 코드치며 배울 수 없는 지식이 무수히 많고, 그런 지식들을 배워야 건설현장의 막노동꾼이 아니라 시스템 설계자의 위치에 올라갈 수 있다는 사실을 깨닫고나면 자료구조론 모르는 개발자가 질낮은 양산형 머신러닝 책의 예제만 베끼고 있을까? 머신러닝이 개발이 아니라는 사실을 왜 못 깨닫는거지?

저런 개발자들은 미래가 없다.

왜? 기본(적인 지식)이 없기 때문이다.

(주: 통밥으로 때려맞추기 in English)

 

2. 기본기 없으면 Out!

IT 개발자 업무의 상당부분이 건설현장의 그것처럼 손으로 직접 익히며 배워야하는 지식이다. 말을 바꾸면, 추상화된 논리를 바탕으로 큰 설계도를 그리는 능력, 그 능력을 뒷받침하는 이론적 체계에 대한 이해가 보통의 개발자에게, 최소한 당장 결과물을 내기 바쁜 보통의 개발업무에서 딱히 필요하지 않기도 하다.

그렇다보니, 개발자 인력 풀이 학교에서 배우는 지식을 등한시하는 경우가 너무 많다. 근데, 아무리 Hands-on-knowledge 위주의 노동 시장이라고 하지만 교과서적인 이해가 필요없는 것은 아니다. 오히려 일을 잘하기 위해서는 교과서에서 배운 이론에 대한 이해가 필수적이다. (사실 모든 산업의 업무가 그런 것 같기는 한데…)

당장 자료구조론을 한번 생각해보시라. DB의 테이블들을 구성할 때, 속도와 안정성에 대한 고민이야 한 쪽을 고르는거라고 하지만, 효율적으로 테이블을 설계하면서 데이터 무결성 (Integrity)을 지키도록 만드는 고민은 단순히 “통밥”으로만 채우기 어려운 점이 있다. 경력직 면접 중에 왜 그렇게 DB 설계 해 놨냐고 물어보면, 이상한 걸 알았지만 Legacy 시스템이라 갈아엎을 수가 없어서 말을 못했다는 이야기를 은근히 자주 듣는다.

SI성 개발 업무 경력이 긴 분들일수록 개발을 만만하게 보고 “통밥”으로 채워넣을 수 있는 것처럼 생각하는 경향이 짙던데, 특정 언어가 설계된 구조를 이해하고, 그 언어 구조에 가장 맞는 코드를 짜는 내공은 언어에 대한 이해가 경험적인 수준을 넘어서서 구조적인 차원의 이해가 맞물려야 가능한 이야기다. 그 언어의 기초 Document들을 꼼꼼하게 봐야하는 이유가 바로 여기에 있다.

시중에 나와있는 싸구려 교과서들이야 웹페이지에서도 쉽게 찾을 수 있는 만만한 지식일지 모르지만, 학교에서 이론적으로 탄탄한 훈련을 받은 사람들만이 그런 구조적인 이해를 갖고 컴퓨터 시스템에 접근할 수 있다는 사실을 꼭 지적해보고 싶다.

Node.js로 서버 개발을 했다는 분께, 상속의 개념과 Closure가 쓰이는 방식에 대한 질문을 던지면서, Closure가 왜 Java같은 언어와 다르게 작동하는지를 질문했을 때, JavaScript 언어로 개발을 몇 년씩 했다는 개발자들임에도 제대로 대답하는 경우를 별로 보질 못했다. (비동기식 언어가 동기식 언어와 어떤 차이를 갖고 있는지 이해 못하는데 Copy & Paste 이상의 개발이 가능한가? 왜 이런 기본 질문도 대답 못하는데 개발 경력이 쌓일 수 있는거지???)

Stack에서 코드를 베끼더라도, 왜 이렇게 돌아가는지 이해를 하고 넘어가는게 당연하지 않나? 왜 다들 개념이해는 없이 그냥 돌아가기만하는 서비스만 만들어놓고 그걸 경력과 포트폴리오에 자신있게 추가하실 수 있는지…

경험적으로, 2번 문제를 갖고 있는 개발자들이 1번 문제도 함께 갖고 있는 것 같다.

우리가 개발자 면접을 볼 때는 항상 이론적인 이해가 얼마나 되어 있는지, 그걸 실무에 적용하면서 이해도를 어떻게 깊게 만들었는지에 초점을 맞춘다. (이건 데이터 사이언티스트 면접 때도 똑같이 적용될 관점인 것 같다.)

 

2-1. 신기술 배우고 싶다면서 문서 안 읽어보고 코드만 찾아다니는 개발자 Out!

위의 기본기 안 배우는 부분과 맥락을 같이 하는데, 많은 개발자들이 신기술을 배우고 싶다면서 이런저런 모임에 열심히 참석한다. 그런데 정작 그 세미나에서 말하는 주제로 공부한 내용은 누군가가 써 놓은 Medium 글 하나와 한글로 번역된 글 1-2개 정도가 전부더라. 그런 모임에 계속 참여하다보면 지식이 쌓인다고 생각하는걸까?

왜 그 신기술이라는 내용의 기본 문서는 안 읽어볼까? React.js와 Vue.js라는게 뜬다고 하니 JavaScript 기본 공부는 안 하고 React 코드만 카피하려고들 하는 프론트 개발자를 여럿 봤었다. Vue보다 React가 코드 찾기 더 좋아서 React를 선택했다는 말을 듣고 기가찼던 적도 있었다. 결정적으로 둘 중 어느 하나를 선택해서 공부하더라도 기본적인 JavaScript 문법과 체계는 다 알아야할 것 아닌가? 왜 기본은 안 하고 신기술 노래만 부르는거지?

한번은 Kotlin과 GoLang 같은 새로운 프레임에 관심이 많다면서 그런 언어 쓰는 회사에 가고 싶다고 하는 분을 만났었다. 아마 백엔드 개발자인 것 같은데, Kotlin이나 GoLang 공부하신건 뭐가 있냐고 물어봤더니 아직까지 공부한 적이 없단다. 그래서 다른 언어로 백엔드 개발 경력이 어떻게 되냐고 물으니 Java가 나오던데, 정작 평소에 물어보는 백엔드 관련 기본 지식이 하나도 없고, 왜 Java에서 GoLang으로 넘어가려고 하냐고 물어보니 말을 뱅뱅 돌리는데 결국은 좀 멋있어 보여서 그걸 하고 싶단다.

기본기가 있으면 언어A를 쓰다가 언어B로 넘어가는데는 길어봐야 1달, 짧으면 1주일 밖에 안 걸린다. 개발이라는게 결국은 구현하고 싶은 결과물에 맞춰 로직을 짜서 프로그램이 돌아가도록 컴퓨터와 대화하는 언어처리 작업인데, 언어들이 최소한 문법과 어휘는 비슷비슷하기 때문에 한 언어로 기본기를 탄탄하게 갖춰놓은 분은 쉽게쉽게 다른 언어로 넘어갈 수 있다. 2개 이상의 언어를 쓰면서 이해가 깊어지는 경우도 나타난다. 그런데, 기본기가 안 갖춰진 상태로 개발하고 있으면 신기술을 배우는게 아니라, 코드를 베끼는 수준에서 성장이 정지된다.

본인이 성장하지 못하고 있다는 걸 체감하고 변화를 주려면서 정작 문서를 읽고 이해하는 고생길(?)은 피하고, 누군가 가르쳐 줄 사람을 찾아다니는 분들도 참 많더라. (ex. Java, PHP로 경력 5년차 백엔드 개발자가 코드 리뷰를 해줘도 시원찮을 판국에 코드 리뷰 좀 받고 싶다고 하거나, 배울 사람을 찾아다닌다거나…)

장담컨데 기본기 없이 주워듣기로 성장하려는 사람보다, 기본기를 갖추고 (똑똑한) 시니어와 대화하는 사람이 몇 배는 더 빠른 속도로 성장할 것이다. 연봉 상승폭은 덤이다.

 

3. 지원하는 회사에 대해 공부하지 않는 개발자 Out!

개발자들과 업무를 같이하는 사람들에게 흔히 들을 수 있는 말이

‘개발자들은 용병 마인드가 너무 심하다’

는 불평이다. 가까운 개발자 친구 하나는

“내가 왜 우리 회사 사람들에게 호감인줄 아냐? 개발자는 도구라는 사실을 인지하고 그 분들을 만나기 때문이지.”

라더라.

글 첫머리에 언급했듯이, 수요-공급이 한 쪽으로 확 치우친 시장이기 때문에, 상당수 개발자들은 오늘 여기서 짤려도 내일 다른 직장가면 된다는 마인드가 강하다. (같은 맥락으로 당신 없어도 새로 사람 뽑으면 되는 평범한 일을 하고 있다는 걸 가끔 강조해주고 싶어지긴 한다ㅋㅋㅋ)

아마 투자금 많이 받아서 여유 있다고 연봉 질러대는 스타트업이 높은 연봉을 제시하는 이유가

‘우리 회사에서 쫓겨나면 이런 연봉 못 받아’

라는 압박을 주려는 목적도 있을 것이다.

이런 상황이다보니 개발자 면접보면서 회사에 대한 정보를 열심히 찾아보고 오는 경우를 별로 못 본다. 당연히 그 분들은 회사가 잘 되는데 아무런 관심이 없다. 자기 기분 나쁘면 그냥 나갈 사람이다.

좀 더 심각한 문제를 가진 분들이 있는데, 아주 조금의 노력만 들여놓고는 회사가 뭘 하는지 다 알고 있다는 식으로 뻔뻔한 개발자들이다. 예를 들면, 파비 오면서

인공지능하는 회사인가보네요, 저도 Python으로 머신러닝 좀 돌려봤거든요

수업에 딥러닝 (같은 신기술)도 가르치나요? 전 Tensorflow로 딥러닝 포트폴리오 많거든요

라고 하는 분들은 기본기 없이 겉멋이 들어서 문제가 아니라, 파비 블로그의 데이터 사이언스 섹션 글을 몇 개라도 제대로 읽어볼 생각조차 안 했다는 걸 자기 입으로 증명해줬기 때문에 문제인 것이다. (2-3개만 제대로 읽어봤어도 무서워서 그런 말 못 꺼낼텐데)

주니어 서버 개발자 중 하나는, 데이터 사이언스와 머신러닝과 딥러닝은 각기 다른 학문기술이고, 딥러닝이 가장 우월한 기술이라고 하더라. 파비 블로그 글을 몇 개만 읽었어도 데이터 사이언스가 Computational Statistics의 다른 이름이고, 머신러닝은 컴퓨터로 그 계산 방법을 돌리는 여러가지 테크닉에 관한 학문이고, 딥러닝은 머신러닝의 여러 모델 중 하나라는 사실을 이해했을 것이다. 그런 주장을 하신 시점에 이미 면접은 끝났다고 봐야한다.

(3번 문제를 가진 분들이 1번, 2번 문제를 다 갖고 있는 것 같다는 생각이 든다ㅋㅋㅋ 결국 공부를 제대로 안? 못? 하니까 생기는 문제다.)

모든 인력이 100%의 Commitment를 갖고 일을 하지는 않는다. 오히려 Over-commitment는 회사에 해가 될 수도 있다. 하지만, 자기 커리어에 한 줄이 들어갈 회사를 이렇게 아무 생각없이 찾아가는 사람이 일 잘하는 사람이 될 수 있을까? 비단 개발자에게만 해당되는 이야기는 아닐 것 같지만…

 

4. 개발 머리 나쁜 개발자 Out!

신입 면접을 볼 때 가끔 던지는 질문인데, 포트폴리오의 어떤 앱, 웹 페이지를 만드느라 꽤나 고생했겠다, 게시판 만드느라 고생했겠다, DB 테이블 설계도 좋네 같은 이야기를 하다가,

“게시판에서 댓글의 댓글은 DB Table에 어떻게 등록해요?”

라고 물어본다.

신입은 물론이고, 경력직도 이 질문에 제대로 대답 못하는 경우를 은근히 많이 본다.

조금만 더 나가보자. Queue를 만들어서 서버 부하를 조절하는 시스템을 만든다고 생각해보자. Queue의 데이터 구조는 어떻게 짜야하고, 어떤 방식으로 처리해야 해당 비지니스 목적에 맞을까?

Array라는 개념, LIFO / FIFO 같은 개념을 학부 시절에 안 배웠다면 전공자가 아닐 것이고, 6개월 자바 학원만 다녔어도 그런 개념을 배웠을 것이다. 초등학교 시절 Basic으로 프로그래밍하면서 배웠던 저 개념과 Queue라는 구조를 경력 2-3년차 백엔드 개발자가 이해 못하고, 질문 받은 자리에서 머리 굴려서 답할 수 없다면 솔직히 말해서 개발 머리가 매우 나쁜 분이라고 밖에 할 수 없다.

지난 몇 년간의 경험을 바탕으로 볼 때, 저렇게 개발 머리가 나쁘면 밑에서 치고 올라오는 똘똘한 후배들에게 밀려나게 된다. 너무 늦기 전에 전직하시라고 권유 드리고 싶다.

5. (실력없이) 몸 값만 높은 개발자 Out!

여느 노동 시장과 마찬가지로, 개발자도 경험치와 실력에 따라 연봉 수준이 어느정도 정해져 있다. 물론 지르는 스타트업들처럼 예외적인 경우도 있겠지만, 그런 회사가 그렇게 많지는 않기 때문에 시장이 어떻게 돌아가는지 고용주나 고용인 모두 어느 정도의 감이 있을 것이다.

이런 종류의 Equilibrium은 단순히 노동 시장에서의 수요-공급에만 영향을 받는게 아니라, 그 업무가 적용되는 산업이 얼마나 돈을 잘 벌고 있는지, 다른 생산요소 공급시장은 어떤지에도 영향을 받는다. 복잡한 경제학 개념을 굳이 가져올 필요는 없을 것 같고, 세상의 모든 요소들이 다 영향을 줘서 지금의 개발자 급여 수준이 정해져있다고 생각하면 된다.

간단한 예시를 하나 들면, 회사가 얼마를 벌어오고 있기 때문에 직원들에게 얼마의 월급을 주면서도 회사가 성장할 수 (at least 버틸 수) 있는 것이다. 아슬아슬하게 버티고 있는 회사라면, 직원들이 단합 투쟁을 해서 급여를 더 올려달라고하면 고용주는 폐업을 고민할 수 밖에 없기 때문에, 그런 한계 기업 상황에서 노동자들이 급여를 더 올려달라고 어떤 시도를 해도 급여가 올라가지는 않는다.

지난 몇 년간 이 쪽 시장을 보면서 알게 된 사실은, 이직이 워낙 쉽다보니 증권업계나 IT업계 모두 노동조합이 별로 강하지 않다. 덕분에 위의 단합 행동 사례들을 업계에서 쉽게 찾아보기는 어렵다.

집단 행동이 없는 대신, 연봉 “투쟁”을 하는 개인 행동은 자주 본다. 실력이 있는 분들이면 자본주의 사회에서 당연한 권리 요구라고 생각하지만, 실력은 없으면서 몸 값만 높게 부르는 개발자들이 생각보다 매우 많더라. 실력이 매우 뛰어나더라도 개발 업무라는 것 자체가 Rocket Science가 아니라 한 사람이 할 수 있는 일의 크기가 어느정도 정해져있기 때문에 2-3명의 월급을 몰아주는 것도 쉽지 않다. 그럼에도 불구하고 억대 연봉을 부르면서 정작 신입 개발자 2명(은 커녕 1명) 몫도 못 하는 경우들이 수두룩하다.

(게임 3D 엔진 같은 넘사벽의 개발 실력이 필요한 예외적인 사항은 제외하자ㅋㅋ)

말을 바꾸면, 개발자가 고액 연봉자가 되고 싶으면 “밥 값”을 해야하는데, 정작 자기가 굉장히 실력이 좋은 줄 착각하고 있으면 분쟁이 생길 수 밖에 없다. 기억나는 사례를 몇 개 들면, 신입보다 쪼끔 더 나은 실력의 만 2년차 개발자인데 2년동안 실력이 저거 밖에 안 늘었냐는 의구심에 많은 갈등을 하다가 오퍼를 던졌더니, 4-5년차 개발자 연봉을 달라고 고집을 피우면서, “니네 회사는 악덕 기업이다”라고 했던 개발자도 있었고, 대기업 포함해서 경력이 엄청나게 긴 분인데 연봉 올려달라고 장기간 줄다리기를 해놓고는 정작 신입 개발자들에게도 “왜 저렇게 실력없는 사람 뽑았냐”고 불평을 하도록 만들었던 분도 있었다.

우리 개발자 분이 면접 끝나고

“요즘 개발 인력 풀은 늘어났는데, 실력 있는 사람들 뽑기가 정말 힘든 것 같네요 ㅠㅠ”

라고 하더라. 면접 보면서 정말 공감한다.

연봉 잘 드릴 생각하고 채용하지만 “밥 값” 못하고 “몸 값”에만 혈안된 개발자와 함께 할 수는 없다.

 

** 만드는 걸 좋아한다? 문제 해결하는 걸 좋아한다!

많은 개발자들의 이력서에는

“뭔가 만드는 걸 좋아한다”,

“어릴 때부터 만들어보는게 취미였다”

는 표현이 들어가 있다. 개발 작업이라는게 결국 프로그램을 “만든다”라고 생각하면 자기 적성이라고 생각할 수 있는데, 요즘와서 곰곰히 생각해보면 만드는 걸 좋아하는 사람과 문제를 해결하는데서 쾌감을 느끼는 사람은 약간 다른 사람이고, 한 회사에서 개발자를 길게 채용해서 서로 Win-Win 하려면 역시 문제 해결에 만족감을 느끼는 사람이어야 할 것 같다.

둘의 가장 큰 차이는 특정 프로그램의 1.0 버젼이 나왔을 때 나타난다. 만드는 걸 좋아하는 사람은 이제 다 만들었다는 생각이 들기 때문에 다른 프로그램으로 넘어가야한다. 근데, 세상의 거의 모든 프로그램이 1.0 버젼일 때 완성형이 아니다. 이제부터 수많은 디버깅과 에러처리를 통해서 1.0.1 버젼부터 1.9.9 버젼이 나오다가 2.0 버젼이 출시되는게 우리가 흔히 보는 프로그램들이다. 이 때 문제 해결에 쾌감을 느끼는 사람들의 진가가 드러난다. 도대체 무슨 문제가 있길래 저런 오류가 나오는걸까를 곰곰히 따져가며 하나씩 문제를 해결할 때 만족감을 느끼고 직업의 보람을 느껴야 그 프로그램의 완성도를 높인 2.0, 3.0 버젼을 출시하는 개발자가 된다.

사실 거의 모든 업무가 그런 것 같다. 꼭 개발에 국한되지 않고, 기획업무도, 디자인 업무도, 심지어 세일즈 같은 업무도 단순히 만드는 것만 좋아하면 매뉴얼을 보고 따라해서 완성품을 만들고, 그 다음으로 넘어가기 쉽상이다. 그런데, 해결사 스타일은 내가 모르면 계속 뒤져본다. 끝까지 파고들어서 어떤 문제인지 찾아내고, 그 문제를 해결하는 방법을 또 계속해서 뒤져본다. 세상에, 최소한 프로그래밍 업무에 해결책이 없는 경우는 거의 없다. 1-2줄 코드로 해결못하고 몇 백줄의 코드를 쳐야할지도 모르지만, 어쨌건 대중을 위한 프로그래밍 작업을 하면서 못한다는 건 없는데, 그걸 내가 반드시 하겠다는 책임감은 “만드는 걸 좋아하는” 사람에게서가 아니라, 문제를 “해결하는 걸 좋아하는 사람에게서 나타나더라. (우리 개발팀장님의 채용 철학이기도 하다.)

 

나가며 – Win-Win하는 방법

예전에 어떤 Front 개발자 면접 중에 들었던 질문이다.

이 회사 내일 모레 망하고 그런건 아니죠?

사무실 리모델링 비용만해도 당신의 1년 연봉보다 더 큰 금액을 쓴 사무실에 면접 오신 분에게 듣기에는 좀 기분 나쁜 질문이었는데, 스타트업에 그런 오해를 갖는 건 그럴 수 있다고 이해하고 넘어갔다. 대신 JavaScript 기본기가 너무 없어서 개발팀에서 단칼에 거절했는데, 어느 블록체인 회사에 정말 ㅎㄷㄷ 연봉을 받고 이직을 하셨더라. 연봉 금액도 놀라웠지만, 기본기가 모자란데도 경력이 길게 있다는 사실, 그리고 또 취직이 된다는 사실이 모두모두 놀라운 사건이었다.

출근하신 다음날 이직하신 회사 대표가 사기치고 있다는 신문기사가 떴고, 다시 한 달간 구직 사이트에서 이력서가 꾸준히 업데이트 되는걸 봤었다.

가까운 지인들 말대로, 우리는 회사도 대단찮은 주제에 눈이 높다. 주제를 모르는건가는 의구심을 항상 갖고 있다. 욕심을 갈무리 못하지만 그래도 양심은 있어야된다는 생각에 우리는 그 구직자에 대한 정보를 최대한 수집해서 결정을 내리려고 노력한다. (연봉은 실력에 맞춰 최대한 챙겨드린다.) 단순하게 이력서만 읽는게 아니라, 온라인에서 찾을 수 있는 모든 정보를 다 찾고, 필요하면 Refer-check도 한다.

구직자 분들 중 여러가지 합이 맞아 우리 회사에 면접을 오시는 분이나, 혹은 다른 회사에 면접을 가시는 분들도 자기 커리어가 걸려있다는 생각으로 좀 더 꼼꼼하게 회사 정보를 찾는다면 어떨까? 제대로 알아보지도 않고 내일 모레 망하고 그러는거 아니냐고 (기분나쁜) 질문만 하실게 아니라, 좀 자료조사하고 회사에 대해서 상세하게 공부해봤으면 그런 결정을 내리지는 않았을 것이다.

글을 다시 읽어보니, 역시 스스로 정보를 찾는 사람은 매뉴얼대로 따라 만드는 걸 좋아하는 사람이 아니라, 자기가 직접 찾아서 해결하는데서 쾌감을 느끼는 해결사 타입인 것 같다. 그런 타입이 블록체인, 인공지능 관련 코딩 학원 수준의 껍데기 지식을 따라 베끼기 하는데서 만족하지는 않겠지. 기본기부터 쌓으시겠지.

기본기만 너무 여러번 반복한 것 같다.