목록으로
들어가며
6개월 안에 취직하지 못하면 길에 나앉게 된다는 말을 듣고는 얼른 이해하지 못해 되물었습니다. 나앉게 된다는 말이 나앉게 될 수도 있다는 말로 바뀌긴 했지만, 유남주(가명)님의 말은 여전히 저를 당혹시킨 내용이었고요.
유남주님은 취업 상태에서 대출을 받았고, 몇 개월 후 소프트웨어 엔지니어로 전직하려고 퇴사를 했습니다. 그리고 한 부트캠프에 등록해서 열심히 공부하고 있었습니다. 얼마 후, 유남주님은 대출을 해준 금융기관으로부터 미취업 상태에서는 대출 연장을 할 수 없으니 만기 상환을 해야 한다는 연락을 받았는데, 하필이면 그 시기가 현재 살고 있는 집의 전세 계약이 만료되는 시기라서 대출 계획이 꼬인 것입니다. 유남주님은 취업 준비조차 하지 않은 상태였기에 제게 급히 멘토링을 요청한 것이죠.
유남주님은 제게 눈을 마주치지 못하고 자신의 이력서에 시선을 묻은 채, 급히 작성했다고 변명하듯 설명했습니다. 그는 마치 금융기관의 대출 창구 앞에 어깨를 작게 말고 앉아있는 사람을 떠올리게 했습니다. 대출이 처음이라는 건 그가 말하기도 전에 알 것 같았습니다.
이력서 멘토링
이력서 주제가 있는 것 같지만 없네요
유남주님의 이력서 첫 번째 장에선 자신에 대해 짧게 소개하고, 자신의 특징 세 가지를 설명합니다. 유남주님이 호소하는 특징을 요약하면 이렇습니다.
-
자기 인식과 그에 따른 성장
-
능동적인 협업
-
코드 탐구와 토론
소재가 좋은데, 이 특징을 종합하는 핵심 문장, 즉 이력서 주제가 없습니다. 어디를 졸업했고, 어떤 교육을 듣고 있는 주니어 프론트엔드 개발 지망자가 이력서 주제는 아니니, 결국 이력서 주제는 없는 셈입니다. 유남주님은 세 개 단락, 즉 자신의 특징 세 가지가 주제라고 했다가 곧 실수라는 걸 깨달았는지 실없이 웃었습니다. 짧은 문서인 이력서에 주제가 세 개라면 잘못 썼다고밖에요.
30여 분 시간 동안 유남주님이 프로젝트를 어떻게 임했는지, 교육 기관에서 지내고 있는 이야기, 첫 직장 생활을 했던 수학 강사 경험에 대해 두루 이야기를 나눴습니다. 유남주님의 이야기들엔 자기 인식이라는 키워드가 일관되게 나왔고, 그 자신도 막연하게 인지하고 있던 것 같습니다. 조금만 더. 조금만 더.
마침내 유남주님은 이력서 주제를 도출했습니다. 유남주님은 어떠한 상황이든 “왜?”라며 이유나 원인을 이해하려 노력하고, 그렇게 이끌어낸 “왜”를 자신은 어떤 관점과 가치관으로 바라보는지를 무의식 중에 사고하였습니다. 그가 호소하는 특징 세 가지는 그런 태도와 자세가 투영된 행동 양식이었던 거지요.
주제를 찾았다고 해서 저절로 문장으로 만들어지는 건 아니죠. 한참 낑낑대며 이력서 주제를 잘 서술한 문장을 쓰려 애썼지만, 어떤 건 장황하고, 어떤 건 억지로 한 문장으로 만들어 잘 읽히질 않고, 어떤 건 두루뭉술했습니다. 이야기 나눌 게 많았기에 저는 중단시키고 이력서 주제 문장을 숙제로 내주었습니다.
장황한 핵심 요약
유남주님의 핵심 요약이 다소 길어서 왜 그런가 봤더니, 첫 번째 장의 첫 번째 절(section)을 핵심 요약이 아닌 자기 소개를 담아서 그랬습니다. 다소 내용이 긴 자기 소개를 한 이유를 유남주님에게 묻자 자기소개서에 자신을 잘 설명하는 내용이 있는데, 자기소개서는 채용담당자가 잘 읽지 않는다는 말을 들었기 때문이라고 합니다. 즉 별첨 서류인 자기소개서를 잘 읽지 않을 것 같으니 자기소개서 내용을 줄여서 이력서 첫 장에 담은 것이죠.
같은 이유인지는 모르겠지만, 이력서 첫 번째 장에 할애하기엔 다소 길게 자기 소개를 하는 신입 또는 1년 내외 경력을 가진 주니어의 이력서를 종종 봅니다. 자신을 소개하고 설명하는 의도는 좋으나 첫 번째에 긴 문장으로 표현하면 집중력과 전달력을 떨어뜨립니다.
유남주님에게 이력서 주제, 그리고 그 주제를 설명하는 유남주님의 특징 세 가지를 3~4줄로 요약할 것을 제안했습니다. 자기 소개에 담은 설명은 프로젝트 경력 등 다른 절(section)에 녹여내고요.
능력 평가 기준을 제시하세요
자신의 기술에 점수를 책정하는 서술법에 대해 여러 의견이 있지만, 대체로 만류하는 편입니다. 여러분이 생각하는 만류 이유는 무엇인가요?
저는 두 가지 이유를 듭니다. 첫 번째 이유는, 작성자가 제시하는 평점 기준이 모호한 것입니다. 가령, 유남주님은 코드 독해를 가장 기본이자 기초 역량으로 책정했는데, 프로그래밍 언어의 문법 차원에서 코드를 읽는 것과 구현체의 설계와 의도를 읽어내는 것 사이엔 큰 간극이 있습니다. 주력으로 사용한다는 것도 익숙한 것인지 능숙하다는 것인지 알기 어렵죠.
두 번째 이유도 첫 번째 이유와 비슷한데, 이력서를 보는 사람의 평점 기준도 모호합니다. 유남주님은 자신의 JavaScript 역량을 3으로 평가했는데, JavaScript 전문가인 채용담당 실무자는 자신의 JavaScript 역량을 2라고 (진심으로) 겸손하게 생각할지도 모릅니다.
정량적으로 서술한다고 해서 구체적이고 명확한 것은 아닙니다. 정량적인 수치의 비교 기준이 있지 않는 한 말이죠. 반대로 그런 기준을 설득력 있게 제시할 수 있다면 역량 수준을 정량적으로 서술해도 괜찮습니다. 쉽진 않긴 합니다.
이력서 주제가 드러나는 경험을 설명하세요
유남주님이 이력서에 기술한 경험엔 세 가지 개선 사항이 있습니다.
첫 번째, 이력서 주제가 담겨 있지 않습니다. 주제 뿐만 아니라 유남주님이 꼽은 자신의 특징 세 가지에 대한 내용도 담겨 있지 않지요.
두 번째, 자신의 경험을 제목으로 쓴 게 아니라 경험이 이뤄진 환경의 이름을 제목으로 썼습니다. 자신의 경험을 제목으로 쓰는 예를 들어보겠습니다.
-
처음 컴퓨터과학을 배운 사람들이 팀을 만들어 해커톤에서 대상 수상
-
직장인 지역 스터디 모임 최초로 지역 모임 웹 페이지 개발
-
학원 내 수학 성적 관리 서비스 개발하고 도입, 운영
세 번째, 설명이 지나치게 간단합니다. 첫 번째 경험엔 제 관심을 끄는 유남주님의 이야기거리가 몇 가지 있었습니다.
-
첫 컴퓨터과학 학습
-
선발 경쟁율 8 대 1
-
처음 배우는 C/C++이 너무 어려워서 진도를 가늠할 수 없었고, ChatGPT를 이용해 수시로 자신의 현재 학습 상태를 파악하고, 커리큘럼에 맞는 학습 주제를 구체적으로 도출해 학습 효율을 높였음
-
C/C++을 처음 접하는 다른 동료를 가르치면서 학습 효과를 높임
-
해커톤에서 만든 팀은 자신을 제외한 전원이 프로그램을 만든 경험이 없어서 팀이 소화할 수 있는 기술스택과 구현 방법을 선정하는 데 노력을 기울임
-
장관상을 수상했는데, 참가팀이 10개였음.
-
교육 취지를 잘 이행한 학생으로 선발됨.
이력서엔 수박 겉 핥듯이 간단명료하게 설명했는데, 유남주님 자기 자신은 상황과 맥락을 알지만, 유남주님을 모르는 채용담당자가 이력서에서 그러한 상황과 맥락을 읽어내도록 할 설명은 없는 것입니다.
성과가 얼마나 대단한지 알려주세요
산학협력 해커톤에서 대상, 그것도 장관상을 받은 것은 자랑할 일입니다. 그런데 제목이 담백해서 아쉽습니다. “프로그램 개발이 처음인 팀으로 해커톤에서 대상(장관상) 수상”이라고 쓰고, 무엇을 잘했기에 대상을 수상했는지 당당하게 설명하면 더 좋아 보입니다.
프로젝트 설명이 아닌 자신을 설명하세요
프로젝트 설명에 이력서 주제가 전혀 보이지 않고요. 프로젝트에 대한 설명이 50%, 프로젝트에서 자신이 한 일이 25%, 프로젝트에 대한 자신의 생각 25%로 유남주님이 드러나는 부분은 고작 25%입니다. 자신이 한 일도 포함해야 하지 않느냐고요? “무엇을 했다”는 설명만으로는 자신이 드러나지 않습니다. 저런 “무엇을 했다”는 것은 다른 사람도 다 하는 일입니다.
유남주님이 프로젝트에서 맡은 일엔 이력서 주제와 관련된 맥락이 있습니다. 자기 인식과 팀 상황을 인식하였는데, 팀에서 프로그램을 만들어본 사람은 자신 한 명 뿐이었고, 다른 사람이 작성한 코드(오픈소스 프로젝트)를 읽고 활용해본 사람도 자신 한 명 뿐이었습니다. 그래서 기술스택에 대해 욕심 부리지 않고 자신과 팀이 빠르게 학습해 활용할 수 있는 것을 고르고, 구현할 기능도 매우 현실적으로 정한 것입니다. 프로젝트에서 유남주님이 경험한 개발 과정에 대한 진짜 이야기지요.
“무엇을 했다”고만 서술하는 실수를 방지하는 방법은, 나는(who) 왜(why), 어떻게(how), 그 결과 무엇을(what) 순서로 설명하는 거예요.
-
프로그램을 만들며 라이브러리 코드를 본 적이 있는 내가(why)
-
팀이 만들고자 하는 컨텐츠 관리 시스템의 핵심 구현에 집중하고자 푸딩보울 프로젝트를 선정해 구현하자고 제안했고(how)
-
그래서 푸딩보울 프로젝트를 분석하고, 이를 기반으로 API 스펙을 설계(what)
포트폴리오 멘토링
문제는 포트폴리오였습니다. 유남주님 말대로 정말 6개월 후에 대출 문제가 발생하면 골치 아프니 취업 준비에 시간 제한이 있다고 봐야 합니다. 유남주님이 이력서 주제를 무엇으로 할지 감을 잡았으니 이력서는 빠르게 정리할 겁니다. 유남주님은 포트폴리오를 보강하고 나서 취업 활동을 하려 하길래 취업 활동은 일단 시작하라고 했습니다. 이력서를 다듬는대로 바로 취업 활동을 시작하는 거죠. 그러면서 포트폴리오 작업을 병행해야지요.
아직 포트폴리오 문서를 작성하진 않았지만, 제 생각엔 유남주님이 참여한 Pudding-Plate로도 충분히 눈길을 끄는 포트폴리오를 만들 수 있었습니다. 하지만 유남주님은 Pudding-Plate가 포트폴리오를 염두에 두고 작업한 것이 아니라서 불안하다고 했습니다. 오롯이 자신이 만든 프로젝트를 하나라도 확보하고 싶어 했습니다. 이력서는 수정하면 되지만 포트폴리오는 코드 이력(commit)이 남으니 프로젝트 시작부터 포트폴리오를 염두에 두고 만들고 싶다고도 하고요.
Pudding-Plate의 코드를 보며, 그리고 유남주님에게 기술 질문을 몇 가지 하며 유남주님의 엔지니어링 수준을 가늠했습니다. 뭔가를 만들어낼 순 있지만, 기본기는 부족했습니다. 보기에 따라서는 이상한 데서 기술을 엉뚱하게 배운 사람이라 오해를 살 것 같았죠. 자기 인식력이 좋아서 오히려 개성 넘치는(?) 코드를 작성한 건 아닐까 생각했습니다.
성장과 변화하는 스토리를 만들자
유남주님이 포트폴리오에 보강하는 방향은 성장으로 정했습니다. 큰 흐름에서 성장을 드러내기 위해 프로젝트는 세 개를 만드는데, 첫 번째 프로젝트는 2주, 두 번째 프로젝트와 세 번째 프로젝트는 4주 동안 만들기로 하고, 완료 기준은 서버에 배포해서 출시하는 것으로 설정했습니다.
이 세 프로젝트는 어떻게 보면 한 프로젝트입니다. 버전 1, 2, 3으로 구분해도 어색하지 않지요. 중요한 것은, 코드 저장소 하나에서 연속해서 작업을 하지 않고 구분하는 것입니다. 왜냐하면 각 프로젝트에서 설정하는 문제 정의가 다르거든요.
첫 번째 프로젝트 : 구현
첫 번째 프로젝트에서는 프로젝트의 핵심 기능을 최대한 빠르게 구현합니다. 기존에 개성있게(?) 코드를 작성하던 그대로 구현을 하기로 했지요. 유남주님은 Pudding-Plate 이후 성장하지 않은 것으로 오해할 것이라며 불안해했는데, 공부한 걸 억지로 코드에 녹여내지 말고 자연스레 작성하는 코드를 담는 게 중요합니다. 게다가 출시해야 하는 프로젝트를 2주만에 만들어야 하기 때문에 시간이 없으니 최대한 익숙한 방법으로 구현하는 게 좋습니다.
첫 번째 프로젝트를 출시하고 1주일 동안 운영합니다. 또한 이 기간 동안 학습을 하는데, 개발하며 느꼈던 문제점과 운영하며 발견하는 문제점을 해결하거나 개선할 방법을 학습하는 거지요. 클린 코드니 디자인 패턴이니 말을 하길래 현 시점에선 고려하지 말라고 일축했습니다.
두 번째 프로젝트 : 원래 하던 것, 더 잘하기
1주일 동안 운영하며 학습한 건 두 번째 프로젝트에서 활용합니다. 두 번째 프로젝트는 개발 생산성을 높이는 데 목표를 둡니다. 가령, 테스트 코드를 작성하는 것인데, 코드를 리팩터링하거나 기능을 추가하면서 기존 구현체에 변경을 가하면 검수하는 데 시간이 적잖이 듭니다. 첫 번째 프로젝트를 작업할 때엔 새로 작성하는 코드인데다 기능도 얼마 없어 손으로 검수해도 큰 지장은 없었지만, 두 번째 프로젝트는 빠르게 구현에 급급한 첫 번째 프로젝트를 기반으로 하니 챙길 게 늘어나거든요. 물론, 테스트 코드를 작성하는 건 예시일 뿐이며, 자신이 느끼고 경험한 걸 토대로 판단하고 직접 결정해야 합니다.
두 번째 프로젝트를 출시하면 마찬가지로 1주일 동안 운영합니다.
세 번째 프로젝트 : 새로운 것, 도전하기
마지막 세 번째 프로젝트에서는 프로젝트와 관련해서 기술적으로 도전할 과제를 한두 개 정합니다. 첫 번째 프로젝트에서 기간이 짧아 포기한 것을 구현해도 좋고, 새로운 과제를 정해도 좋습니다. 심오하거나 복잡하거나 신 기술일 필요는 없습니다. 여태까지 만든 프로젝트와 관련되며, 감당이 안 되어 포기할 정도는 아닌 수준으로 도전 과제를 설정하고 소화합니다. 예를 들어, 지도 SDK를 이용해 지도를 출력하는데, 화면에 핀(pin)이 많을 때마다 웹 브라우저가 뻗는다면, 이 문제를 해결하는 걸 도전 과제로 삼습니다. 확대 단계(zoom level)에 따라 표시되는 핀 개수를 조절하거나 묶어주는(clustering) 식이죠.
두 번째 프로젝트에서 학습하고 경험한 것을 녹여내고 활용해야 합니다. 예를 들어, 의존성 주입에 대해 이해하고 활용하게 됐다면 세 번째 프로젝트에서도 필요한 곳에 의존성 주입을 합니다. 테스트 코드 작성을 학습했다면 세 번째 프로젝트에서도 테스트 코드를 작성하고요.
마치며
멘토링을 한 긴 시간 중 반 정도는 안심시키는 시간이었습니다. 자기 인식을 잘하다보니 이력서 주제를 빠르게 도출했고, 그동안 겪어온 경험에서도 자기 인식이 작용한 사례를 금방 찾아냈거든요. 불안해서 이것도 하고, 저것도 하고, 그것도 하자는 유남주님을 안심하도록 조심히, 그리고 자세히 포트폴리오 계획의 목표와 의도를 설명했습니다. 더 욕심내지 말고 제가 제안한 계획의 의도와 목표에 집중하도록 말이지요. 유남주님이 자기 인식을 잘하니 그에 맞는 과제를 내주었지만, 제 제안을 실제로 수행하는 건 만만치 않거든요.
유남주님이 세 번째 프로젝트를 수행하던 어느 날, 유남주님에게서 대출 문제가 해결되었다는 소식을 전해왔습니다. 세 번째 프로젝트를 계속 진행할 거냐고 묻자, 자신의 색깔이 또렷히 보여서 취직을 해도 세 번째 프로젝트까지 꼭 완성하고 싶다며 💪 이모지를 보내왔습니다.
🚨 본 컨텐츠에 등장하는 인물 중 글쓴이를 제외한 모든 인물의 이름은 가명이며, 지명, 시간, 단체나 기관, 사건은 각색하고 창작하였습니다. 일부라도 비슷하거나 겹치는 경우는 우연히 일치하는 것이니 이 점, 양지해주시길 바랍니다. 🚨
푸딩캠프 뉴스레터를 구독하면 학습과 성장, 기술에 관해 요약된 컨텐츠를 매주 편하게 받아보실 수 있습니다.