** 주의: 현재 속해있는 조직 (회사, 팀)의 공식 정책/방향/입장이 아니다. 순전히 개인 의견이다.
데이터 과학자 채용을 위한 개별 인터뷰 질문 별로 언젠가는 글을 적기는 해야겠지만, 오늘은 지난 몇 년 동안 인재 영입 과정으로 서류를 검토하고 면접에 참여하면서 공통적으로 느낀 아쉬움에 관해서 적는다. 데이터 과학자뿐만 아니라 다른 개발 직군도 글에서 밝힌 것과 크게 다르지 않으리라 본다. 기획, 영업, 마케팅 쪽은 다소 다를 수도 있지만, 기본 원칙은 크게 차이가 없을 테니 독이 되지는 않을 거다.
제한된 경험이지만 백 명 넘는 지원자의 이력서를 검토했고 그중 수십 명은 직접 면접관으로 참여했다. 새로운 사람을 맞이하는 건 늘 설레기에 영입 시스템에 새로운 이력서가 등록되거나 면접 참석 요청이 오면 기쁘다. 이제는 내가 가를 직접 만드는 것보다 그런 기회와 환경을 제공하고 역량을 제대로 펼치도록 사람을 키우는 게 -- 쉽진 않지만 -- 더 중요하고 재미있다. (그래서 개인 성과는ㅠㅠ) 면접 참여가 업무를 방해해서 귀찮게 여기는 이들도 더러 있지만 나는 늘 설레고 더 많은 인터뷰에 들어가서 더 다양한 사람들을 만나보고 싶다. (아이러니하게도 일상에서 사람들을 만나서 대화하는 걸 좋아하지는 않는다.) 하지만 그 기쁨이 길지 않을 때가 많다. 이력서에 적힌 몇 문장만 읽고 또는 몇 개의 질문에 답변을 듣고 나서 바로 실망하는 경우가 흔하다. (역지사지로 내가 피면접자라면 나도 누군가에게 실망의 대상이 될 수 있다는 점에서 글이 다소 조심스럽다.) 이 글을 적기 위해서 며칠을 생각했는데, 실망의 원인은 '명확하지 않다'로 요약할 수 있다. 이력서가 명확하지 않거나 답변이 명확하지 않다는 거다.
이력서에 자기소개와 경력을 적을 때 좀 명확했으면 한다. 명확하다는 의미는 자세하지만 간결하다는 거다. 자세한 것과 간결한 것은 모순처럼 보이지만 서로 보완해서 명확함을 만든다. 사안을 쉽게 이해할 수 있을 만큼 -- 기밀을 누설하지 않는 범위 내에서 -- 자세해야 하지만 지루하지 않게 핵심에서 벗어나지 않아야 한다는 거다. 지원하는 부서나 맡을 업무가 있으면 대략 어떤 사람들이 서류를 검토하고 면접관으로 들어올지 뻔하다. 그러니 경력사항을 적을 때 청자 (면접관)가 이미 알고 있을 법한 내용은 생략하고 모를 것 같은 특징적인 것은 좀 상세히 적어야 한다. 자기만 알고 있는 도메인 지식이나 기술(명)을 설명 없이 짧게 적는다거나 누구나 알만한 내용을 중언부언 길게 적는 것 모두 바람직하지 않다. 창의성을 요구하는 시대지만 경력사항을 적을 때는 굳이 어설픈 창의성을 발휘할 필요는 없다. 그냥 참여한 프로젝트 개요, 그 프로젝트에서 자신이 맡았던 역할과 내세울만한 기여 내용, 그리고 -- 가급적 정량적 -- 프로젝트 결과/성과만 간결히 적으면 된다.
예를 들어, 광고 소재의 CTR 예측 모델을 개선하는 프로젝트에 참여했다. (CTR 예측 문제는 웬만하면 다 알만한 업무니 더 자세히 적을 필요가 없다.) 내 역할은 기존 모델의 성능 (정확도든 속도든)을 개선할 새로운 예측모델을 조사해서 구현/적용하는 거다. 기존에는 로지스틱 회귀 모형을 사용했는데, 피쳐들 간의 상호작용을 효과적으로 모델에 반영하는 FM계열의 모델을 구현하고 하이퍼파라미터를 최적화했다. 기본 설정의 FM모델을 적용하는 것만으로 RIG를 3.6% 정도 개선했는데 최적의 하이퍼 파라미터를 찾은 후에는 7.3%까지 개선됐다. (그런데, 계산량이 많아져서 속도는 10% 정도 더 증가해서 앞으로 속도의 개선이 필요했다.)... 현실을 반영한 가상의 시나리오/수치를 적은 거다. 이력서/경력사항에 굳이 단점까지 적을 필요는 없겠지만 때론 저게 지원자의 진실성 (= 사안에 대한 이해도)을 보여줄 수도 있고, (단점/한계점을 경력 사항에 적지 않았더라도) 면접 때 관련 질문이 나올 수 있으니 미리 생각해두는 건 좋다고 본다. (** 논문을 적을 때도 무조건 장점만 나열하지 말고 단점이나 보완점을 함께 적는 게 다른 연구자들을 위한 배려라는 게 오랜 지론이다.)
이런 내용으로 글을 적었다면 최소 2~3번의 퇴고는 거쳤으면 한다. 오탈자는 없는지, 이해하기 어렵거나 군더더기 내용은 없는지, 어색하거나 맞춤법/띄어쓰기에 어긋난 문장은 없는지, 또는 특히 정확한 문어체 문장인지 등... 사람마다 말버릇이 다르듯이 자기만의 글 버릇도 있다. 그래서 자기가 적은 글은 몇 번을 다시 읽어도 문제점을 찾지 못하는 경우가 흔하다. 그래서 글을 크게 소리 내어 읽어보라고 흔히 조언한다. 그리고 가능하다면 제출 전에 주변 지인들에게 먼저 보여주고 간결하고 명쾌한지를 검수받는 것도 좋다. 어릴 때부터 유독 국어에 약했기에 이런 조언은 내가 할 게 아니지만, 개발자/이과생이더라도 최소한 논리적이고 일관된 문장/표현으로 글을 적었으면 한다. 경력/소개글이 너무 어색해서 뽑히면 이걸로 계속 놀려야지라고 생각했던 지원자들이 종종 있었는데, 단 한 명도 지금 같이 일하고 있는 이가 없다. 학교에서 국영수를 그렇게 강조했는데, 데이터 과학자에게 국영수만큼 중요한 소양도 없다. 글을 논리적으로 제대로 적지 못하는 개발자가 과연 코딩은 제대로 하는 걸까?
면접도 명확해야 한다. 달변가는 아니지만 답변이 깔끔한 사람들이 종종 있다. (아쉽게도 나는 그런 사람이 아니다.) 확고한 지식과 사고의 체계를 갖췄을 뿐만 아니라, 그걸 논리적으로 표현할 수 있어야 한다. 그저 지식이 풍부한 사람을 채용하겠다면 면접 대신 많은 문항의 시험을 치르는 게 낫다. 나는 '지식을 내재화한 사람 그래서 그걸 자신만의 언어로 표현하는 사람'을 원한다. 모르는 걸 아는 척하는 것만큼 나쁜 답변은 없다. 아는 척한다는 것은 그저 달변으로 위기를 모면하는 것뿐만 아니라, 단순히 책이나 인터넷에서 읽은 내용을 그저 앵무새처럼 내뱉는 것을 포함한다. 몸담은 분야에 관한 자신만의 지식 체계를 갖췄으면 한다. 답변이 명확해지려면 질문의 의도를 제대로 파악하는 능력도 필요하지만 이건 나도 못한다. 때론 별 의도 없이 묻는 질문도 있기 때문에 때론 지나치게 깊이 고민할 필요는 없다. 제대로 의도를 파악해서 간결히 답변하는 건 결국 센스 문제다.
면접관들마다 채용 기준이 있겠지만 나는 이런 사람을 뽑고 싶다. 모두가 인정하는 '이 사람을 필히/웃돈을 주고서라도 뽑아야 돼'라고 생각되는 그런 천재는 당연히 뽑아야 한다. 하지만 지금껏 운 나쁘게도 그런 지원자를 만난 적이 없다. 내가 직접 면접에 참여해서 현재 함께 일하고 있는 동료를 디스 하려는 건 아니다. 어쨌든 10점 만점에 8점 이상은 아니었다. 그럼에도 지금 같이 일하고 있다는 건 그럴만한 이유 또는 장점을 봤기 때문이다. 면접은 '나는 모든 걸 잘해요' (물론 그런 사람도 있겠지만)를 알리는 자리가 아니라, 나의 장점은 이거다를 어필하는 자리다. 즉 자신의 장점이 무엇인지 확실히 인지해서 그걸 면접관이 보도록 만들어야 한다. 그게 명확한 거다. 사람마다 장점은 다양한데 그 장점이 지원한 회사나 팀 또는 업무와 잘 맞아야 한다. 그 부분을 파고들어야 하는데, 많은 지원자들이 자신이 어디에 지원했는지도 모른 채 그냥 인터뷰에 참석했다는 느낌을 받을 때가 종종 있다. 자신의 장점을 보여주고 그 장점이 당신들이 필요한 거야라는 걸 명확하게 어필해야 한다. 이 사람은 이런 장점이 있고 또 그게 우리의 부족한 부분을 채워줄 거야라는 판단이 서면 합격이다. 천재가 아니더라도 당장/장기적인 필요를 채워줄 사람을 뽑는다.
다른 경우는 지금 당장은 다소 부족하더라도 잠재력이 있는 지원자를 통과시킨다. 학교를 갓 졸업했거나 경력이 짧은 지원자에게서 베테랑의 향기를 느끼려 하면 안 된다. 그래서 경력이 짧은 지원자일수록 기초가 탄탄한지를 보려 한다. 때론 경력 사항에 따라서 최신의 유행하는 알고리즘에 관한 질문도 하겠지만, 가급적이면 아주 기초적인 것을 묻는 편이다. 인터넷에 검색하면 쉽게 찾을 수 있는 질문들, 예를 들어 probability와 likelihood의 차이점이 뭐냐? 과학습을 해결하는 방법 다섯 가지 정도만 나열해봐라. L1/L2의 장단점은 뭐냐? 등과 같은 아주 기초적인 질문을 하는 편이다. 당락은 어려운 질문이 아닌 쉽고 기초적인 질문에서 결정된다. 어려운 걸 맞췄다고 쉬운 걸 그냥 놓치는 사람을 뽑을 수는 없다. 어차피 경력 사항에 적힌 내용은 나보다 지원자가 더 잘 알기에 그걸로 그를 평가하는 건 다소 불합리하다. 물론 사용한 방법론이나 알고리즘을 제대로 알고 사용했는지 그리고 바른 practice로 문제를 해결했는지 정도는 확인한다. 앞서 적었듯이 그저 책에 적힌 내용을 그대로 읊조리는 것이 아니라 자신의 언어로 표현할 수 있어야 한다. 물론 탄탄한 기초에 창의력과 상상력을 더할 수 있어야 하지만 짧은 면접에서 모두 확인할 방법이 없다. 인터넷에 떠도는 유수 기업의 창의력 문제가 과연 도움이 될까? 어쨌든 창의력/응용력도 기초 위에서 빛을 발한다. 그리고 잠재력이 있다고 무조건 뽑는 건 아니다. 나 또는 팀 내의 다른 누군가가 부족한 부분을 채워줄 수 있어야 한다. 성장시켜줄 역량도 없으면서 무턱대로 사람을 채용하면 모두에게 불행이다.
길게 적었지만 진짜 똑똑한 사람이 아니라면, 현재 우리가 필요한 부분을 채워줄 수 있는가? 와 탄탄한 기초와 여러 의미에서 센스가 있는, 즉 성장 잠재력이 큰가? 가 나의 주요 면접 기준이다. (물론 나의 판단이 언제나 옳다는 건 아니다.) 나를 보완해주거나 내가 보완해줄 수 없으면 경력이 화려하더라도 나와 함께 일하기 곤란하다.... 나의 기준이 다소 허황되게 들릴지는 모르겠으나 이런 면접에 직접 참여해본 사람이라면 충분히 공감할 거라 생각한다. 조직 (회사나 팀)마다 사람마다 판단 기준이 모두 다르니 그냥 참고만 하기 바란다. 하지만 이게 최소한 실패하지 않는 방법이란 걸 명심했으면 한다.
명확하게 적고 말하고 했는데 정작 이 글은 너무 길다. 처음 의도와는 달리 글이 많이 거칠게 적힌 점은 송구하게 생각한다. 다만 데이터 과학자로 또는 다른 분야로의 커리어를 쌓는데 취업이 중요하다면 자신에게 주어진 기회를 좀 더 전략적으로 현명하게 사용했으면 한다. 잘못 적힌 글 때문에 모호한 태도 때문에 기회를 살리지 못하는 것은 매우 안타까운 일이다.
** 마침 카카오엔터프라이즈 티스토리에 테크니컬 라이팅 4대 원칙이란 글이 올라왔다. 본문에선 '명확성'이라고 묶어서 표현했는데, 카엔 글에선 명확성, 간결성, 정확성, 일관성으로 정리했다. https://tech-kakaoenterprise.tistory.com/102
** 글을 대강 마무리한 후에 '청바지 입은 꼰대'란 표현을 봤는데 이 글이 전형적인 꼰대 글로 보인다. 맞다. 난 꼰대다. 나의 조언이든 참견이든 아니면 그냥 오지랖이든 99명이 싫어해도 단 한 명에게라도 도움이 된다면 꼰대질을 멈출 생각이 없다. 꼰대가 없어져야 세상이 좋아질 것 같지만 다른 류의 꼰대는 또 등장한다. '넌 꼰대야'라고 지적하는 것조차 전형적인 꼰대다. 다만 나의 경험과 지식이 죽은 것이 아니길 바랄 뿐이다.
