비전공자 신입 개발자의 소극적인 이력서를 멘토링하다

컴퓨터 과학/공학을 전공하지 않은, 일명 비전공 출신 신입 개발자인 유남주(가명)님의 이력서는 소극적이고 움츠러든 모습이 느껴지도록 했습니다. 자신이 비전공자라는 걸 지나치게 의식한 나머지 이력서에 자신을 담지 않고 전공자 못지 않다는 걸 보이려 하고, 그들처럼 프로젝트를 만들 수 있다는 걸 보이려 프로젝트 자체를 설명하는 데 그쳤거든요. 이력서 주제, 또는 주제를 정하는 데 참고할 핵심어를 찾으려 애썼지만, 멘토링 시간 안에서는 결국 찾지 못해서 아쉬웠던 멘토링 사례였습니다.

어떤 이력서였을까요? 유남주님이 소프트웨어 개발자로서 처음 작성한 이력서에 대해 멘토링한 내용을 함께 살펴 보겠습니다.

유남주님 이력서는 노션으로 작성한 이력서에서 흔히 보는 전형적인 배치로 구성되어 있었어요. 공간 효율이 떨어지고, 엉뚱한 곳에서 쪽(page)이 분절되어 있었죠. 이력서를 PDF 파일로 받는 곳이 많으니 여러분도 노션으로 이력서를 작성한다면 꼭 PDF 파일로 인쇄해 확인해보세요.

이력서 첫 번째 장, 그 중에서도 맨 윗부분은 이력서 영역 중 가장 비쌉니다. 따라서 이 부분에는 이력서 내용 전체를 관통하는 핵심 요약(Executive Summary)을 담는 게 좋습니다. 유남주님의 이력서를 보면 노션 페이지에 표지 이미지를 넣어서 이력서에도 이 이미지가 그대로 들어갔는데요. 이 비싼 영역을 이력서와 관련 없는, 혹은 관련 없어 보이는 이미지가 차지했습니다. 웹 브라우저에서 웹 페이지로 보는 것과 종이 또는 A4 용지 기준으로 내용이 배치된 PDF로 보는 건 차이가 크니 유의해야 합니다.

핵심 요약엔 이력서 주제가 포함되어야 해요. 이력서 작성자인 유남주님을 설명해야 하죠. 이력서 주제로 채용담당자가 관심과 호기심을 갖도록 하고, 이후에 전개되는 이력서 내용은 이력서 주제를 받쳐주며 주제를 설득하는 역할을 하여 채용담당자 머리 속에 작성자 자신을 각인시켜야 합니다. 이력서 주제는 명확하고 구체적이어야 해요. 추상적이거나 막연하거나 일반적이면 채용담당자도 추상적이거나 막연하거나 일반적인 인식을 할 수밖에 없어요.

유남주님의 경우 이력서에선 빠뜨렸지만, 협업을 잘하고 성장하는 개발자가 이력서의 주제라고 했습니다. 이 주제를 세 가지 요소로 이력서에 보충 설명한거죠. 그런데 협업을 잘한다는 건 구체성이 떨어져요. 여러분이 생각하는 협업을 잘한다는 건 어떻게 협업하는 건가요? 사람마다 다릅니다. 마찬가지로 성장한다는 것도 어떻게 어떤 능력이 성장하는 걸 의미하는지 알 수 없어요.

유남주님은 재기발랄하게 TMI로 표기한 영역을 넣었는데요. 저는 표현도 표현이지만, 이력서 주제와 관련없어 보이는 내용과 불친절한 내용이 더 눈에 띄었습니다.

만약 이력서 주제가 '개발 환경을 개선하여 개발 생산성을 높이는 개발자'라면 코드 에디터인 Vim에 대한 내용을 활용할 여지가 있을 거예요. 물론 지금보다 더 구체적으로 기술해야 하죠. 또는 코드 에디터, 코딩 관례(convention), 코드 형식 검사기(Linter)를 팀 내 소통 매체로써 활용해 코드를 관리한다는 식으로 현 이력서 주제에 맞출 수도 있습니다. 현 이력서 주제의 핵심어는 협업이나 팀 작업이니까요. 하지만 현 이력서에 코드 에디터에 관해 서술한 것은 단지 유남주님의 취향을 드러낼 뿐이라 이력서 주제와 연관된 내용을 바로 유추하지 못합니다.

팀 협력이 중요한 운동을 좋아한다는 내용은 이력서 주제와 관련 있어 보입니다. 하지만 이력서에는 관련 있어 보이는 데에 그치지 말고 관련된 내용을 구체적으로 직접 설명해야 합니다. 예를 들어, 유남주님이 협업에서 가장 중요한 것으로 팀이 같은 방향을 향해 동기화된 힘을 똑같이 내는 걸 꼽는다면, 그런 지향점이 조정 경기와 잘 맞다는 걸 이해할 수 있게 구체적으로 설명하는 거죠. 으레 상대방이 자신과 같은 생각을 하겠거니 하고 논리 과정의 중간 단계를 건너뛰면 상대방은 '맛있는 간식으로 알아서 사오라'는 주문처럼 느낄 거예요.

유남주님이 참여한 프로젝트는 정부 사업으로 선정되었어요. 눈길을 끌만한 경험이예요. 유남주님은 만들어본 프로젝트가 몇 개 더 있었지만, 다른 사람이 관심가질 프로젝트인 포트폴리에이션에 집중해 이력서에서 설명했다고 합니다. 이력서 주제를 잘 받쳐주는 정도로 선택과 집중하는 걸 저는 권장하지만, 어쨌든 선택과 집중을 한 판단은 괜찮아 보입니다.

아쉬운 점은 프로젝트를 소개하고 설명할 뿐, 유남주라는 사람을 느낄 수 없습니다. 소제목부터 프로젝트 이름을 표기했는데, 대개의 경우 프로젝트의 이름은 이력서에서 작성자 자신을 소개하는 데 효용이 없습니다. 자신이 프로젝트를 경험하는 과정에서 채용담당자에게 어필하고 싶은 점을 제목으로 표현하는 것이 낫습니다. 물론 그 내용은 이력서 주제를 뒷받쳐줘야 하고요.

포트폴리에이션 프로젝트에 관해 유남주님과 깊이 이야기 나눠보니 팀원들이 처음 사용하는 기술스택을 빠르게 적응해 활용할 수 있도록 활약했다는 점이 인상에 남았습니다. 자신도 처음 접한 기술스택이라 팀원들보다 시간을 더 들여 공부하고 실습해서 동료들에게 전수했대요. 동료가 난관에 부딪히면 가장 비용이 많이 드는 것을 우선으로 하여 유남주님이 적극적으로 돕고요. 비용을 책정한 기준을 묻자 병목 정도라고 하더군요. 그 이유인 즉, 팀 스포츠에서 팀의 역량은 가장 약한 팀원에 수렴하는 경험을 해서 자신은 늘 협업에서 병목으로 작용하는 요소를 파악하려 노력한다고 합니다.

자신이 협업하는 방식과 목표를 인식하자 유남주님은 프로젝트 설명 중 그 어디에도 그런 점이 내용이 없다는 걸 비로소 깨달았습니다.

유남주님이 프로젝트에 사용한 기술을 이름만 나열하지 않은 건 좋지만, 여전히 자신을 담지 않았습니다. 그래서 API 개발하는 데엔 Nodejs와 Express를 사용하고, 사진 저장하는 데엔 AWS S3를 사용한다고 기술 스택 용도를 소개하는 것같은 표현이 되고 말았습니다.

유남주님은 포트폴리에이션 프로젝트에 사용한 기술스택을 백엔드 개발자와 프론트엔드 개발자가 소통하는 비용을 낮추는 정도를 비교해 선택했다고 합니다. 그래서 프로그래밍 언어로 TypeScript를 선택했고, 그러니 Nodejs 환경에서 개발하는 것은 당연한 수순이었지요. 팀 내에 인프라와 관련된 지식이나 경험 있는 사람이 없었는데, 프로젝트에 대해 멘토링을 하는 멘토님이 AWS 전문가여서 인프라는 멘토님께 의존하자고 과감히 결단했대요. 물론 멘토를 적극 활용(?)하는 역할은 유남주님이 자처했다고 해요.

유남주님이 사용 기술 영역에 자신을 어떻게 담을지 감을 잡은 것 같아서 제가 중요한 점 하나를 강조했습니다. 신입 개발자에겐 전문성을 기대하지 않습니다. 학습 능력과 일머리, 잠재성을 기대하지요. 문제 정의를 할 줄 알고, 효율적으로 도움을 요청하는 협업 감각이 있으면, 기술같은 하드 스킬은 가르치면 됩니다. 즉, Why를 파악하고 해야할 일의 목적과 목표인 What을 이해하는 사람이며, 현재 부족할 수 있는 하드스킬인 How는 학습 능력이 좋아서 얼마든지 보완할 수 있다는 걸 보여주면 좋습니다.

제가 노션 이력서를 권장하지 않는 이유 중 하나는, 노션으로 작성한 이력서에 유독 이력서 외부 URL, 즉 링크를 활용하는 경우가 많기 때문입니다. 가능한 한 이력서 안에서 승부를 봐야 해요. 채용담당자의 관심이 이력서에서 벗어나지 않게 붙들어야 합니다.

유남주님은 구현 과정 설명은 중요한데 분량이 많고, 코드를 바로 확인하기 좋아서 GitHub 저장소를 링크로 넣었다고 했는데요. 이 말은 다르게 말하자면 링크를 눌러 방문하지 않으면 중요한 구현 과정을 보지 못한다는 걸 뜻합니다. 관심이 생기지 않아 그다지 궁금하지 않다면 일부러 구현 과정을 찾아 읽을 가능성은 낮습니다. 더구나 맥락도 없고 어떤 구현체인지도 모르는, 남이 짠 소스 코드를 일일이 리뷰할 가능성은 더욱 낮습니다. 코드 리뷰가 피곤하기도 하고, 주니어 개발자들이 작성한 구현체 코드는 예상이 될 정도로 대체로 비슷하기도 하고요.

체험도 마찬가지입니다. 실제 동작하는 프로젝트를 체험하는 URL을 넣어도 채용담당자가 방문하지 않으면 얼마나 매력있고 훌륭한 프로젝트인지 알지 못합니다. 체험하고 싶도록 호기심과 관심을 이력서에서 이끌어내는 것이 먼저입니다.

프로젝트를 체험하는 것이 대개 제 역할을 못하는 이유는, 채용담당자가 꼭 경험해야 할 요소에 도달하는 데 장애물이 많기 때문입니다. 모르는 서비스에 회원가입을 하다보니 비밀번호를 대충 짓기 일쑤이고, 그러다보니 로그인부터 원활하지 않은 경우가 많습니다. 회원가입과 로그인 기능이 체험해야 할 핵심 기능이 아니라면, 하드코딩을 해서라도 인증 과정을 건너뛰어 최대한 빨리 체험할 영역에 도달시켜 주는 것이 좋습니다.

바로 체험할 것을 요구하기 보다는 동영상으로 간접 체험을 먼저 하도록 하는 건 어떨까요? 물론 동영상에도 지루하게 회원가입과 로그인 과정을 굳이 담을 필요는 없습니다. 광고 영상을 만들듯이 몇 초 안에 체험하고 싶게 만드는 게 좋아요.

우리는 학교, 교육 기관 등 교육 받은 이력을 이력서에 적는데요. 신입에게 전문성을 요구하는 게 아닌데 왜 교육 이력을 적는 걸까요? 어떻게 활용해야 할까요?

제가 생각하는 중요한 활용처는 학습 능력이 좋다고 호소하는 거예요. 그런 점에서 유남주님이 교육 이력을 그냥 넘기지 않은 점이 좋습니다. 교육받은 것이 무엇인지, 즉 '자신이 무엇을 했다' 형식으로 기술한 점은 아쉽네요.

'이러한 교육을 받은 내 학습 능력 좋지?'라고 말하는 전개를 고민해보세요. 가령, 01부트캠프 수료율이 10% 내외라든가 또는, 하루 평균 8시간씩 힘들고 어렵게 공부하며 기초를 닦아 8주 커리큘럼을 4주 만에 소화해낼 수 있다고 설명하는 건 어떨까요? 누구나 익히 아는 입학하기 어려운 교육 기관에 입학하여 수료하면, 그 사람의 학습 능력이나 성실성을 사람들은 어느 정도 가늠하잖아요. 누구나 익히 아는 교육 기관이나 체계가 아니라면 명확하고 구체적으로 설명하여 가늠하도록 돕기를 권합니다.

물론 교육 이력을 활용하기 쉽진 않습니다. 그래서 대개는 교육 기관명이나 교육 주제 정도만 간결하게 적으며, 저 역시 활용할 내용이 마땅하지 않으면 그렇게 간결하게 적는 게 낫다고 하는 편이예요.

멘토링 이후 유남주님은 시간을 들여 자신을 깊게 돌아보았다고 합니다. 자신이 좋아하는 건 여러 사람과 어울려 뭔가를 하는 것이지만, 정작 주변에서 자신의 특성으로 꼽는 점은 진지하고 집중력 있게 몰입해서 배우고, 이를 잘 정리하여 동료에게 전파하며 함께 지식을 공유하는 점이라고 합니다. 그 이야기를 기준으로 놓고 지난 자신의 활동을 돌이켜보니 일맥상통하는 이야기가 보였대요. 멘토링에서 배운 내용을 참고하여 새 주제로 이력서를 다시 작성했고, 짧은 기간 동안 주니어 개발자를 여럿 채용한 한 회사에 입사했다고 전해왔습니다. 그 회사에서 유남주님에게 무엇을 기대하는지 알 것 같네요. 😊

이력서 파일 내려받기

🚨 본 컨텐츠에 등장하는 인물 중 글쓴이를 제외한 모든 인물의 이름은 가명이며, 지명, 시간, 단체나 기관, 사건은 각색하고 창작하였습니다. 일부라도 비슷하거나 겹치는 경우는 우연히 일치하는 것이니 이 점, 양지해주시길 바랍니다. 🚨