뽑히는 개발자 이력서는 어떻게 만드나요?

25년 차 개발자로 꾸준히 멘토링을 하다 보니 신입 개발자의 이력서를 볼 일이 많습니다. 그중 신입 개발자로 취업을 준비하는 유남주(가명)님의 이력서는 깔끔하고 읽기 좋게 잘 다듬어진 이력서였어요. 분량도 너무 짧거나 부담스럽지 않게 세 장이었고요. 괜찮아 보이는데 왜 멘토링을 신청했냐고 묻자 뭔가 허전한 기분이 드는 위화감 때문이라고 합니다. 감이 좋은 친구네요. 느긋하게 진행해도 될 것 같습니다. 본격적인 멘토링을 시작하기 위한 질문을 던졌습니다.

“이 이력서의 주제는 뭐예요?”

가상의 신입 개발자 이력서

어제도, 그제도, 지난 주에도 받아본 이력서입니다 신입 또는 경력이 짧은 주니어 엔지니어의 이력서는 대체로 비슷합니다. 조금 과장해 표현하면, 이름과 연락처를 가렸을 때 모두 같은 사람이 낸 이력서처럼 보이기도 하죠. 특히 “자신이 한 일을 사실 위주로 간결하게 쓰라”는 조언을 따른 이력서는 더욱 분별력이 떨어집니다. 저는 이런 형식을 신입이나 주니어에게 추천하지 않습니다. 경력자에게 더 유용하고 유리한 형식이거든요.

자신이 한 일을 사실 위주로 간결하게 적는 형식 그 자체에 문제가 있는 게 아닙니다. 이를 신입 이력서에 적용하면 역효과가 나기 십상이라는 거죠. 경력이 없으니 이력서에 쓸 게 마땅치 않은데, 그마저도 사실 위주로 간결하게 적으면 자신을 드러낼 재료가 부족해집니다. 대부분 신입 개발자는 경험한 프로젝트도, 사용한 기술 스택도, 공부한 주제도 비슷합니다. 역량이나 생각이 부족하기보다 애초에 경험할 수 있는 환경과 상황이 한정되어 있으니까요. 그러니 신입이죠.

따라서 신입 개발자는 ‘자신이 한 일’이 아닌 ‘자기 자신’을 이력서의 주제이자 주인공으로 삼고 작성해야 합니다. 좋은 이력서를 쓰는 방법을 함께 알아봅시다.

상대방 머리에 나를 모델링하는 이력서 주제는 구체적으로 잡자

‘협업을 잘하는 백엔드 개발자’

유남주 님 이력서의 핵심 요약(Executive Summary) 단락에 있는 첫 문장이에요. 협업을 중요시하거나 잘한다고 스스로를 정의하고 소개하는 이력서는 굉장히 많이 봤는데요. 이야기를 나누거나 실제로 겪어보면 이들이 협업하는 방법은 서로 달랐어요. 각자 나름대로 협업하는 방법과 지향점이 있었죠. 즉, 모두 협업이라는 단어를 사용하지만, 자세히 들여다보면 다르다는 겁니다. 그러니 이력서의 주제를 단순히 ‘협업을 잘하는 개발자’로 두기보다는 ‘어떠한 방법으로 어떻게 협업을 잘하는 개발자’인지 구체적으로 잡는 게 더 좋아요.

다시 유남주 님과 이야기를 나눠보니, 이분은 자신과 팀의 상태를 틈틈이 파악하며 눈치 빠르게 팀 활동에 기여하는 유형이었어요. 세세한 건 나중에 다듬기로 하고, 이력서의 주제를 ‘팀이 한 몸처럼 움직이도록 눈치 빠르게 협업하는 백엔드 개발자’ 로 정했습니다.

주제를 받쳐주는 힘이 강한 순서대로 쓰자 이력서의 주제를 정했으니 내용을 정렬해야 합니다. 대개 이력서는 다음과 같은 순서로 소주제를 나열하죠.

핵심 요약 보유 역량, 기술 경력 학력, 교육 이력

좋은 구성입니다. 그런데 신입에게는 다른 관점도 필요합니다. 이력서의 주제를 받쳐주는 힘이 강한 순서대로 나열해 보는 거죠. 왜 그래야 할까요?

독자의 관심을 끌고 가는 거리

이력서의 주제는 채용 담당자가 이력서를 읽게 만드는 요인이에요. “팀이 한 몸처럼 움직이도록 눈치 빠르게 협업한다고?”라고 호기심을 일으켰으면, 곧바로 어떤 점에서 그런지 이를 설득하는 내용을 제시해야 합니다. 읽는 사람의 호기심과 관심은 빠르게 사라지거나 엉뚱한 데로 새기 일쑤니까요. 주제를 잊지 않도록 거의 세뇌에 가깝게 거듭 설득하는 거죠. 이력서를 읽다 말고 중간에 이탈하더라도 주제, 그러니까 이력서를 쓴 사람이 머리에 선명하게 남도록 만들어야 합니다.

그런 점에서 소설 ‘마션’은 아주 강렬한 첫 문장으로 도약하고, 이 힘을 최대한 살려가며 독자가 다음 장 다음 장을 펼치게 만드는 좋은 예입니다.

소설 마션 도입부

눈을 의심케 하는 비속어로 첫 문장으로 시작해 시선을 잡은 다음 주인공이 어떤 상황에 처했고, 넘어야 할 난관은 무엇이며, 그는 어떤 성격인지를 열 개 남짓한 문장으로 각인시킵니다. 첫 장의 내용 역시 이렇게 제시한 것들에서 뻗어나가죠. 주인공의 일관된 성격과 ‘ㅇ된 상황’을 끊임없이 상기시키면서요.

이처럼 신입 이력서의 항목은 최근순보다, 이력서의 주제를 받쳐주는 힘이 센 순서여야 합니다. 저 역시 게임 업계 사람에게 제 이력서를 줄 때는 20년 전에 참여한 프로젝트를 앞 장에 배치하고는 합니다. 대중적으로 성공한 프로젝트거든요. 때로는 게임 회사를 창업한 경력을, 때로는 CTO 경력을 앞에 배치하기도 하고요. 제 이력서를 받아볼 사람이 저에게 무엇을 궁금해하고 관심 가질지, 즉 이력서의 주제에 따라 내용과 구성을 조정합니다.

만약 주제를 가장 강하게 받쳐주는 것이 공모전 입상이라면 그 경험을 전면에 배치하세요. 예를 들어 볼까요? 제가 멘토링한 멘티 중에는 엄청난 추진력과 리더십, 실행력으로 와해할 위기에 처한 팀을 이끌고 공모전에서 좋은 성적을 거둔 사람이 있습니다. 제가 이 멘티를 기업에 추천한다면, 그 공모전 이야기를 가장 먼저 할 게 뻔하죠. 그가 어떤 사람인지를 가장 잘 설명하는 스토리거든요.

혹시 너무 이질적인 이력서를 작성하지 않을까 걱정하나요? 고민하지 마세요. 이력서 주제를 받치는 힘이 강한 순서로 나열해도 결국은 핵심 요약, 보유 역량, 경력, 교육 순으로 구성하게 될 가능성이 큽니다. 이 역시 오랜 시간, 많은 사람이 이력서를 작성하며 전수된 지혜니까요. 대부분 구성 그 자체보다는 이력서에 담고자 하는 내용이 달라질 겁니다.

왜, 어떻게, 그 결과 무엇을, 순으로 배치하자 다시 본 유남주 님의 이력서도 기존 배치를 바꿀 필요는 없었지만, 주제가 더 잘 드러나도록 내용을 다듬으면 좋겠습니다. 전형적인 ‘내가, 무엇을, 했다’ 형식으로 작성했으니까요. 특히 프로젝트 항목의 ‘푸딩캠프 클론 코딩 프로젝트’을 읽고 이 개발자가 어떤 사람인지 알 수 있을까요? 저는 잘 그려지지 않았습니다. 여기서는 프로젝트를 소개했지 그 프로젝트를 수행한 자기 자신을 내용에 담지 않았죠. 주제이자 주인공이 ‘개발자 유남주’가 아닌 ‘프로젝트’가 된 겁니다.

들어 보니 푸딩캠프 클론 코딩 프로젝트에서 주제와 관련된 핵심 작업은 백그라운드에서 API 응답 속도를 개선하는 일이었어요. 유남주 님은 팀이 처한 상황을 동료들과 함께 진단해 그 이슈를 백엔드에서 백그라운드 작업으로(Background task) 처리하는 게 가장 합리적이라는 결론을 도출했다고 합니다. 또 결과적으로 작업 대기열(Task queue) 기능을 구현했고요. 그래서 이런 내용을 담아보자고 제안했습니다.

제목: 맞춤형 경량 작업 대기열로 API 응답 속도를 높이고, 사용자 경험을 개선한 프로젝트 프로젝트 소개: 인공지능 API로 학습자가 올린 질문을 해결하는 데 도움이 되는 자료를 찾고 자동으로 제공하는 학습 서비스입니다. 기여: 팀과 프로젝트의 상태를 파악하고 팀에 부담을 주지 않는 구현 방안을 도출했습니다. 문제 정의: 동작에는 문제가 없지만 다소 답답한 사용자 경험이 발생한다는 걸 인지했습니다. 프론트엔드 부하가 커지는 상황이라는 걸 파악했습니다. 백엔드 동료 개발자는 생소한 기술스택을 사용하던 상황이라 스트레스받고 있었습니다. 문제 해결: 클라이언트로부터 요청받은 작업에 대해 작업 ID를 생성해 즉시 응답했습니다. 작업할 내용은 JSON으로 직렬화하여 PostgreSQL JSONB 컬럼에 저장했습니다. 작업 대기열은 멘토의 조언으로 PostgreSQL의 SELECT FOR UPDATE SKIP LOCKED을 이용해 구현했으며, 별도 기술 스택을 추가하지 않았습니다. FastAPI의 Background Task 기능으로 작업 대기열에 있던 작업을 가져와 백그라운드에서 비동기로 처리했습니다. 결과: 사용자가 질문을 게시하는 API를 호출할 때, 응답 속도를 80% 이상 개선했습니다. (400ms > 80ms 이하) 응답 속도 개선 이후, Google Analytics 지표상 질문 작성률이 20% 증가했습니다.

물론 푸딩캠프 클론 코딩 프로젝트에서 한 일은 더 다양했지만, 주제인 ‘팀이 한 몸처럼 움직이도록 눈치 빠르게 협업하는 백엔드 개발자’에 가장 가까운 작업을 추려낸 겁니다. 곧이어 어떻게 문제를 정의하고 해결했는지도 자세히 설명했죠. 그가 프론트엔드 개발팀의 상황과 동료 백엔드 개발자의 상황을 눈치 빠르게 파악했다는 점, 모르는 것을 연구하느라 시간을 지체하기보다 멘토에게 도움을 청해 빠르게 문제를 해결했다는 점, 이 두 가지를 전달하는 데 집중한 거죠.

만약 내용의 주제이자 주인공이 기술 스택에 맞춰져 있었다면, 상대방의 관심사는 자연스레 왜 Apache Kafka를 사용하지 않았는지, RabbitMQ나 Redis를 사용하는 것이 좋지 않았을지 등 ‘무엇’에 쏠리게 될 겁니다. 신입 개발자인 유남주 님은 작업 대기열 전문가나 응답 속도 성능 전문가로 지원하는 것이 아닙니다. 그러니 나라는 사람은 이런 사람이고, 어떻게 문제를 정의하고 해결하는지, 이 과정을 설명하며 자기 특성을 알려야 합니다.

분량보다는 내용이 더 중요하다 유남주 님의 프로젝트 항목을 주제 중심으로 바꾸자 이력서가 금세 다섯 장이 되었습니다. 다소 많은 편이죠. 그렇다고 무작정 분량을 줄여서는 안 됩니다.

분량보다 중요한 것은 내용입니다. 읽어 볼 것이 없는 짧은 이력서보다 읽을 것이 있는 긴 이력서가 낫습니다. 상대방이 이력서의 주제에 관심과 흥미를 갖게 하고, 갈수록 약해지는 관심과 흥미가 완전히 사라지지 않도록 주제를 받쳐주는 내용을 제시하는 것이 좋습니다. 애초에 관심을 끌지 못하면 이력서가 한 장이더라도 다 읽지 않으니까요. 반면 관심이 있다면 몇 번이고 다시 읽을 겁니다.

정 분량을 줄이려면 뒷장에 배치한 것부터 쳐내거나 설명을 줄여야 합니다. 앞의 조언을 잘 따랐다면 주제를 받쳐주는 힘이 약한 내용을 뒤에 배치했을 테니까요. 어떻게 보아도 이력서 주제에 어울리지 않는 프로젝트나 경험이라면 아깝더라도 과감히 잘라내기를 권장합니다. 이력서의 주제를 잊게 하거나 주의를 산만하게 만들거든요.

제가 이력서를 검토하거나 면접을 진행한 경험, 또 채용 과정에 참여한 실무자와 얘기한 경험으로는 신입이 아무리 프로젝트를 많이 해도 그 자체로는 별 인상을 받지 못합니다. 몇십 개, 몇백 개라면 모르지만요. 프로젝트가 하나여도 ‘나’, 즉 이력서의 주제를 제대로 설명하고 상대방을 설득할 수 있다면 그다지 아쉬워하지 않아도 괜찮습니다.

나만 알고 있다고 가정하자 당연하게도 다른 사람은 ‘나'와 ‘내 경험’을 잘 모릅니다. 그래서 내가 올린 성과가 얼마나 훌륭한지, 어떻게 대단한지 잘못 판단하기 쉽습니다. 성과만 달랑 적는 것 역시 전형적인 ‘무엇을, 했다’ 형식의 이력서입니다. 유남주 님 이력서의 입상 항목에는 ‘과학통신기술부가 주최한 푸딩 해커톤에서 금상을 받았다’는 부분이 있습니다. 만약 이력서를 제출한 회사의 채용 담당자가 같은 해커톤에 참가한 것이 아니라면, 이 상이 어떤 의미인지 모를 겁니다. 즉, 별 의미를 안 둘 가능성이 크다는 뜻이죠.

그래서 저는 이력서 멘토링을 할 때, “자랑하려면 제대로 자랑하라”고 제안합니다. 그 자랑거리가 이력서의 주제만 제대로 받쳐 준다면 말이죠. 과학통신기술부에서 주최한 대회라면 장관상이 걸린 큰 대회일 겁니다. 여러 개발자가 참가했겠죠. 물어보니 무려 100개 팀이 참가했다고 합니다. 그렇다면 이 항목의 제목을 ‘100개 팀이 참가한 해커톤에서 3위 입상’이라고 기재하는 건 어떨까요?

100개 팀이 참가한 해커톤에서 3위 입상, 과학통신기술부, 2023년 기여: {이력서 주제에 부합하는 활약이나 기여 내용} 프로젝트: 푸딩에 어울리는 커피를 인공지능으로 분석하여 개인화해 추천하는 웹 서비스

내 성과가 어느 정도 수준인지 알 수 있도록 강조할 부분을 먼저 제시합시다. 입상 과정에 어떻게 기여하고 참여했는지, 무슨 문제 정의와 해결 방법을 적용했는지 뒤이어 설명하고요. 그 결과, 무엇을 만들어 좋은 성과를 얻었는지 설명하고 마무리하면 됩니다. 심사평이나 다른 참가팀으로부터 받은 피드백을 인용해도 좋습니다. 한두 줄로 내가 만든 프로젝트를 모두 설명하기는 어려우니, 제 3자가 피드백해 준 강점으로 프로젝트를 간접 설명하는 거죠.

다시, 이력서의 주제이자 주인공은 무엇일까요? 바로 이력서 작성자, 자기 자신입니다. 상대방이 궁금한 건 내가 참가한 대회가 아니라 그 대회에 참가한 나입니다. 이력서를 읽는 사람에게 대회 정보를 짧지만 직접적으로 제공해, 관심사를 나에게 집중시켜야 해요.

신입에게 기대하는 것은 전문성이 아니다 이번에는 교육 항목으로 가보겠습니다. 유남주 님이 들은 ‘42Camp’가 혹독한 자기주도 학습과 동료 학습 중심 프로그램을 갖춘 교육이라고 해봅시다. 이 교육을 수료한 사람은 기초가 튼튼하고 학습 능력이 좋다고 업계에 은근히 소문도 났고요. 하지만 42Camp를 모르는 사람이라면, 교육 이력 항목에서 아무런 감흥을 느끼지 못할 거예요. 그렇다고 이력서에 42Camp를 자세히 소개하면 안 됩니다. 마찬가지로 이력서를 쓰는 것이지, 교육 프로그램 소개서를 쓰는 것이 아니니까요. 그 까다로운 교육 과정을 거친 결과 어떤 인재가 되었는지, 이를 상대방에게 익숙한 정보로 전달해야 해요.

‘익숙한 정보’란 이런 겁니다. 교육 참가 경쟁률이 몇 %인지, 수료율이 어느 정도인지, 하루 평균 몇 시간 정도 집중해야 하는 커리큘럼인지 등이죠. 이력서를 읽는 사람에게 42Camp 그 자체를 소개하기보다, 교육에 대한 평판과 신뢰 수준을 구체적인 정보로 전달하며 설득하는 게 낫습니다.

이런 교육 기관을 수료한 신입에게 채용 담당자가 기대하는 것은 무엇일까요? 물론 회사와 상황에 따라 다르겠지만, 대체로 학습 능력과 빠른 성장을 기대한다고 합니다. 몇십, 몇백 시간 만으로는 전문성을 갖추기 어렵습니다. 애초에 신입에게 전문성을 기대하는 것도 이상하죠.

회사에 들어가 프로젝트에 투입되면, 신입 개발자는 새로운 도메인과 기술, 팀 상황에 맞춰 많은 걸 새로 교육받고 학습해야 합니다. 따라서 채용 담당자는 지원자가 교육 기관을 수료하는 데 들인 시간과 수료 이후 성장 폭을 보고 학습 능력과 성장 수준을 유추합니다. 우리 회사에 입사했을 때, 이 개발자에게 어느 정도 자원을 투자해야 하는지 견적을 내는 거죠. 즉, 이 사람을 채용하면 교육을 위해 시니어 개발자 A의 자원을 하루 평균 N%씩 몇 개월이나 들여야 할지, 그 비용 을 감수할 수 있는지(또는 감수할 필요가 있는지) 알고 싶어한다는 뜻입니다. 그런 정보를 이력서에서 유추할 수 없다면, 면접 자리를 마련해 알아내기보다 서류 전형에서 탈락시킬 겁니다.

교육 항목에 쓸 내용이 이력서 주제를 받쳐주지 못하거나 성장 능력을 설명하기 어려운 경우도 있습니다. 그럴 때는 이력서에서 교육 항목이 차지하는 공간을 최소화해 짧고 건조하게 적으세요. 굳이 뺄 필요는 없습니다. 안 그래도 적을 재료가 부족한 데 일부러 교육받은 사실까지 뺄 필요는 없으니까요.

내가 인식하는 나를 상대방에게도 최대한 동일하게 인식시키자 이력서를 읽고 나면 ‘나’를 머릿속에 그릴 수 있어야 한다 좋은 이력서는 생전 만나본 적 없는 사람이 몇 장짜리 문서를 읽고 머릿속에 ‘나’를 모델링하도록 만듭니다. 나아가 더 알고 싶으니 만나보자는 생각이 들게 하죠. 다만 이력서에는 소설처럼 많은 분량을 할애하지 못합니다. 그래서 신입의 이력서는 작성하기 어려울 수밖에 없습니다.

신입 개발자 이력서의 주제를 내가 만들 요리, 다양한 경험을 음식 재료라고 해봅시다. 지금은 스팸, 베이크드 빈, 육수, 고추장, 햄, 다진 마늘, 라면 사리 같은 재료만 나열해도, 내가 만들 수 있는 요리를 상대방이 알 거라 여길 상황이 아닙니다. 처음부터 “내가 만들 요리는 부대찌개다”라고 강조해야 합니다. 혹은 당장 가진 재료라고는 감칠맛을 내는 조미료밖에 없지만, 재료 다듬는 방법, 육수 내는 법, 조리법을 빠르게 깨우쳐 맛있는 부대찌개를 끓일 수 있다는 걸 납득시켜야 하죠. 그런 만큼 더욱 요리 재료, 육수 내는 법, 조리법 등을 중심으로 이야기가 전개되지 않도록 유의해야 합니다.

내가 어떤 사람인지 구체화해 이력서의 주제로 선언하세요. 또, 읽는 사람의 생각이 주제에서 이탈하지 않은 상태에서 계속 읽어가도록 해야 합니다. 내가 다룰 줄 아는 기술스택, 내가 경험한 프로젝트를 주연으로 만들어 소개하고, 정작 나는 단역으로 빠지는 건 명백한 실수입니다. 많은 사람이 범하는 그런 실수를 해서는 안 됩니다.

내가 누구인지 일깨워줄 조력자를 찾자

유남주 개발자 “멘토님, 감사합니다. 제 이력서에서 이런 내용을 담을 수 있을 거라 생각하지 못 했어요.”

유남주 님과 멘토링이 끝난 다음, 이런 말을 들었습니다. 신입 개발자가 이력서를 작성하기 어려운 더 근본적인 이유가 여기 있습니다. 좋은 이력서를 쓰려면, 자기 자신을 깊게 들여다보고 나 스스로 어떤 사람인지 알아야 하기 때문입니다. 우리는 자기 자신을 잘 알고 있다고 생각하지만, 막상 글이나 말로 설명하려면 잘되지 않습니다. 그러니 어느 회사에 다니는 누구, 어느 학교에 다닌 누구, 누구와 함께 일해본 누구라고, 하다못해 내 MBTI는 무엇이라고 하죠. 즉, 나를 뒤에서 받쳐주는 배경을 내세워 나를 소개합니다. 그게 편하고 쉬우니까요. 실제 모습과 다를 수 있는데, 아니, 그 정도가 아니라 아예 전혀 엉뚱한 사람으로 인식할 가능성이 큰데도 말입니다.

여기에 ‘나'를 잘 알더라도 내가 생각하는 나와 다른 사람이 생각하는 나를 일치시키는 건 또 다른 문제입니다. 사람의 언어가 갖는 엄밀성의 한계도 있고, 상대방이 내게 기대하는 것에 따라 보고자 하는 면면이 달라지기도 하니까요.

한날 “남주 님의 머릿속에 있던 내용을 함께 찾아내 끄집어낸 거예요. 이미 알고 있는 것들이었죠. 새로운 건 없었잖아요?”

유남주 개발자 “실은 그래서 더 혼란스럽기도 해요. 제 이야기인데, 저는 인지하지 못하거나 도출하기 어렵다고 생각했거든요. 그렇다고 늘 멘토나 사수가 있기를 기대하기도 어렵고요.”

유남주 개발자가 멘토링 끝에 인식해야 할 문제를 놓치지 않았네요. 자신이 주제이자 주인공인 이력서를 쓰는 건 당장 해결할 표면적인 문제입니다. 본질적인 문제는 멘토링이 끝나도 그런 이력서를 쓰도록 누군가 코칭해 줄 환경을 갖추어야 한다는 겁니다. 쉽지 않습니다. 좋은 코치, 격려하고 응원해 주는 친구, 진정성을 갖고 나를 관찰하며 기록해 줄 동료가 있는 그런 환경이요. 마치 농구 만화 ‘슬램덩크’의 주인공인 강백호가 성장할 때, 코치인 안 선생님을 비롯해 소연이, 친구들 등 조력자가 이를 도왔듯 말이죠.

슬램덩크 강백호와 코칭

물론 이런 환경을 운에만 맡길 수는 없습니다. 직접 개척하며 구축할 수도 있죠.

나를 알고 내가 지원하는 분야도 아는 사람 나를 알지만 내가 지원하는 분야를 모르는 사람 나를 잘 알지 못하지만 내가 지원하는 분야를 아는 사람

이들 각자에게 내 이력서를 읽고 어떤 사람이 머릿속에 그려지는지 피드백을 요청할 수 있습니다. 일기를 쓰고 일정 주기로 복기하며 현재의 나와 비교하는 방법도 있고요. 또 1년에 한 번쯤은 취업 활동과 무관하지만, 마치 취업하려는 것처럼 이력서를 갱신하는 것도 좋습니다.

더 직접적으로는 안 선생님 같은 코치, 강백호 군단 같은 친구를 직접 찾아내는 방법도 있습니다. 자신의 상황에 맞춰 고민해 주는 사람이 있는, 그런 환경을 만드는 데 공을 들여야 하죠. 누가 자기 귀한 시간을 내어 코칭해 줄지 염려되나요? 너무 걱정 마세요. 생각보다 많은 선배가 마음을 열고 도와줄 겁니다. 저만 하더라도 그런 이유로 창업을 했고, 멘토 활동을 지속하고 있거든요.

마치며 신입 개발자의 이력서는 정말 작성하기 어렵습니다. 저만 하더라도 제 이력서를 작성할 때, 이렇게까지 공을 들이지는 않습니다. 이력서를 요청하는 사람이나 회사에 맞춰 가볍게 작성하는 편이지요. 25년간 쌓아온 경력 자체가 제가 어떤 사람인지 꽤 잘 설명하거든요. 그래서 신입이나 경력이 짧은 주니어 개발자에게 이력서 멘토링을 하다 보면, 막연하게 미안함과 안타까움이 들기도 합니다.

그래도 누구나 한 번쯤은 시간과 공을 들여 기준이 될 이력서를 만들어야 합니다. 그렇게 만든 기준이자 기반인 이력서를 지원할 회사에 맞춰 조금씩 다듬으면 수월해지죠. 내가 누구인지, 상대방도 나도 잘 모르지 않도록, 여러분 스스로 깊게 파고든 다음 이력서를 작성해 보세요.

“아참, 그런데 멘토님. 다음에는 포트폴리오 멘토링 부탁드려도 될까요?”

네, 다음에는 신입 개발자의 포트폴리오 작성법을 살펴보겠습니다.