개발자 취업을 준비하는 분들이 한 번씩은 검색해 본 키워드는 무엇일까요? 아마도 "이력서 쓰는 법"이지 않을까 하는 생각이 들 만큼 이력서를 어떻게 구성해야 할지 많은 분들이 고민하고 있을 텐데요. 그래서 이번 아티클에서는 실제 백엔드 주니어 개발자인 도근 님이 취업 준비 기간에 어떻게 이력서를 준비했는지 생생한 경험을 공유해 주실 겁니다. 실제 주니어 개발자 입장에서 어떻게 합격하는 이력서를 만들 수 있었는지 실질적인 조언이 듣고 싶으신 분들은 이번 아티클에 주목해 주세요.
안녕하세요, 백엔드 주니어 개발자 유도근입니다. 본격적인 이력서 내용으로 들어가기에 앞서, 오늘 제가 말씀드릴 내용의 신뢰도를 높이고자 간단히 자기소개부터 하겠습니다. 아래는 제 이력인데요, 이력이 다소 특이하다는 것을 알 수 있을 것입니다. 원래는 컴퓨터공학을 전공했으나, 다른 업계에서 잠시 경력을 쌓다가 부트캠프를 통해 개발자로 직무를 전환했습니다. 부트캠프 수료 기간을 보시면 조기 취업에 성공했다는 사실도 짐작하실 수 있죠.
2022년 7월 15일 기준으로, 서류를 약 110군데 지원하긴 했으나, 그 중 경력직 공고도 서류에서 20군데나 합격하는 상당히 괜찮은 결과를 얻었습니다. 그래서 오늘은 당시에 이력서 작성 과정에서 어떤 준비를 하고, 어떤 점들을 고려했는지 여러분께 자세히 공유해 드리고자 합니다.
- 2015.03 ~ 2019.02 컴퓨터공학 초대졸(2년제)
- 2018.07 ~ 2022.01 반도체 Set-Up Engineer
- 2022.03 ~ 2022.06 부트캠프 백엔드 과정 진행
- 2022.07 경력직 서류 합격 20건
이 글은 매우 깁니다. 제가 2주간 이력서를 작성하며 수많은 분들의 피드백을 받아왔고, 3주간의 면접 과정에서 겪은 다양한 경험이 담겨있기 때문이죠. 그만큼 이 내용들이 필요하다고 느꼈기 때문에 처음 이력서를 작성하시는 분들은 처음부터 끝까지 흐름에 맞게 읽는 것을 추천드리고, 어느 정도 이력서를 써본 분이라면 본인의 경험과 빗대어 필요한 부분만 선택적으로 읽으시는 것을 추천드립니다. 이번 글은 개인적으로 1개 이상의 프로젝트를 진행해 본 부트캠프 수료생들과, 독학으로 개발 공부를 하여 개인 프로젝트 경험이 없는 분 모두에게 도움이 될 것이라고 생각합니다.
Part 1. 주니어 개발자 이력서는 어떻게 작성해야 할까?
우선 저는 조기 취업으로 회사에 입사했기 때문에 이력서를 작성해 본 경험이 없었습니다. 이력서를 어떻게 써야 할지 고민하던 중, 부트캠프에서 수료 시, 수료생들에게 제공하는 템플릿이 있다는 것을 알게 되었지만, 그 템플릿을 사용하지 않기로 했죠. 이전 기수 졸업생들에 대한 정보를 잘 몰랐기 때문에 그대로 사용하는 것은 위험하다고 생각했고, 유튜브에 이력서 작성하는 법을 찾아보던 중 다음과 같은 영상을 보게 됩니다.
개발바닥 유튜브 채널에 본인의 이력서를 직접 공개하신 분이 계셨고, 이 분이 작성한 글을 참고하여 하나씩 작성해 나갔습니다. 이력서 작성 체크리스트도 있고, 중요한 정보들이 많았기 때문에 참고할 수 있는 내용이 많았지만 어느 순간 주니어 개발자는 이런 방식으로 이력서를 작성하면 안 된다는 것을 깨달았습니다. 이유는 다음과 같습니다.
- 주니어는 경력자들처럼 증명할 수 있는 객관적인 자료가 절대적으로 모자랍니다.
- 채용 담당자들은 이력서 하나만을 보고 다음 단계로 넘길지를 고민합니다.
- 그렇기 때문에 짧게 쓰는 것이 아니라, 최대한 자세하게 자신을 소개해야 합니다.
제가 이렇게 말씀드릴 수 있는 이유는 처음엔 저도 간결하게 이력서를 작성하고 지원했기 때문인데요. 하지만 안타깝게도 서류 전형에서 번번이 탈락하는 결과를 맞이했습니다. 이에 저는 왜 이런 일이 발생하는지 고민해보았고, 앞서 언급한 3가지 이유들이 떠올랐습니다. 그래서 이력서를 수정해서 다시 지원했더니, 이전에는 바로 탈락했던 회사들로부터 서류 합격 소식을 받을 수 있었죠. 자, 그럼 주니어 개발자만을 위한 이력서 작성법을 시작해보겠습니다.
Part 2. 이력서 작성 전, 생각해볼 3가지
1) 이력서 형식
이력서를 작성할 때는 한글, 워드, 파워포인트, 노션 등 다양한 도구를 사용할 수 있는데요. 개인적으로는 '노션'을 추천드리고 싶습니다. 많은 분들이 노션 이력서를 추천하지 않는 이유는 PDF로 추출했을 시 레이아웃이 크게 달라질 수 있기 때문인데요. 레이아웃이 달라지면 가독성을 해칠 수 있기 때문에 이런 상황을 대비해서 꼭 레이아웃 비율을 조정하셔야 합니다.
어떻게 보면 단순한 문제라고 생각할 수 있지만, 이력서를 수없이 많이 보는 채용 담당자 입장에서는 왼쪽 이력서를 보자마자 불합격을 누를 수 있습니다. 그렇기 때문에 꼭 계속 비율을 바꿔보고 확인한 것을 제출하셔야만 합니다. 그리고 노션 링크만 제출하는 것을 절대 하지 말아야 하고, 기왕이면 PDF로 변환시킨 노션 페이지를 구글 드라이브에 올려서 제출하는 것을 추천드립니다.
2) 이력서 레이아웃
이력서의 레이아웃은 크게 두 가지로 나눌 수 있습니다. 위에서 아래로 떨어지는 세로형과, 옆으로 갔다가 아래로 내려가는 가로형이 있는데요. 여기서 고려해야 하는 사항이 있습니다. 생각보다 채용 담당자들은 웹이 아닌 모바일로 이력서를 검토한다는 사실입니다. 일반적인 핸드폰으로 볼 때, 가로형 레이아웃은 읽기에 흐름이 깨질 가능성도 있기 때문에 개인적으로 세로형 레이아웃을 추천드립니다.
하지만 가로형 레이아웃으로 이력서를 제출한다면 면접관에게 새로운 인상을 줄 수 있습니다. 다른 사람들과는 차별화된 구성으로 자신만의 특별함을 강조하는 것도 좋은 전략이 될 수 있을 것이라고 생각합니다. 레이아웃은 개인의 선택에 달려있는 문제이기에, 본인을 더 잘 보여줄 수 있는 레이아웃을 구성해보시기 바랍니다. 저는 면접관에게 "이력서 구성은 뻔한데, 내용이 뻔하지 않아서 얼굴이 보고 싶었습니다"라는 말을 자주 듣곤 했습니다. 이는 수많은 이력서를 검토하는 과정에서 뻔한 이력서는 눈에 들어오지 않는다는 의미와도 비슷한 대답이라는 생각이 드는데요. 따라서 이력서 작성 시 레이아웃뿐만 아니라 내용의 독창성과 개성을 살리는 것이 중요합니다.
3) 거짓된 정보는 금물
이력서를 작성할 때 잊어서는 안 되는 점 중 하나가 절대로 거짓을 적으면 안 된다는 것입니다. 이 부분을 강조하고 싶습니다. 다른 직종에서는 '자기소설'이라는 표현도 사용되던데, 개발 업계는 적용되지 않습니다. 기술 면접에서 꼬리 질문을 받으면 결국 다 드러나기 때문이죠. 이력서는 자신을 어필하는 글입니다. 따라서 부정적이거나 약한 모습을 보여주기보다는 강렬한 인상을 남기는 것이 중요합니다. 하지만 자신의 장점을 최대한 부각시키되, 거짓이 없는 진실된 내용으로 이력서를 작성하는 것이 가장 좋은 방법입니다.
Part 3. 이력서의 구성
이력서 구성은 조금씩 차이는 날 수 있지만, 큰 틀에서는 아래와 같은 내용으로 구성해주셔야 합니다. 그럼 하나씩 살펴볼까요?
- 제목(자율)
- 인적사항
- 스킬
- 자기소개
- 경험
- 공부이력
- 학력, 경력
- 자격증, 어학능력
1) 제목
제목은 정해진 형식이 없습니다. 자유롭게 본인이 강조하고 싶은 내용을 담으면 됩니다. 제목은 가능하면 간결하게 나타내는 것이 좋고, 면접관으로 하여금 궁금증을 유발할 수 있는 위트 있는 제목이면 더욱 좋겠죠.
2) 인적사항
저는 면접관에게 제 이력서에 대한 피드백을 요청드리는 편인데요. 많은 면접관분들이 인적사항은 지원자와 직접 대화를 해봐야 아는 부분이기 때문에 유심히 보지 않는다고 말씀해 주시더군요. 하지만 인적사항이 없으면 이력서에 공백이 느껴지기 때문에 넣어주는 것을 추천드립니다. 제 이력서를 살펴보면서 확인해 보죠.
사진
이력서에 사진 첨부가 필수가 아니라면 사진을 첨부하지 않는 것도 괜찮습니다. 저도 사진을 넣을지, 넣지 말아야 할지에 대해 고민을 깊게 했습니다. 저는 이력서에 여백이 많아지는 것을 우려해서 사진을 넣는 방안을 선택했지만, 이는 본인의 선호에 따라 선택해주시면 될 것 같습니다. 면접관들도 사진이 있는 걸 선호하시는 분들이 있는 반면, 사진이 있는 이력서를 그다지 선호하지 않는 면접관도 있습니다. 만약 사진을 넣는 것을 선택했다면 자신을 잘 보여줄 수 있는 깔끔한 사진을 넣는 것을 추천드립니다.
개인 정보
저같은 경우에는 개인정보를 자바스크립트 코드로 포인트가 될 수 있게 표현했습니다. 그리고 성별, 나이, 거주지 같은 상세한 정보를 모두 담기보다는 아래 5가지 정보만 담아도 충분합니다. 한편, 면접관들로부터 들은 피드백 중 하나를 공유하고 싶습니다. 바로 "1남 1녀 중 막내" 등의 가족 관계에 대한 내용은 자제해 달라는 것입니다. 물론 가족 관계가 자신의 성장 배경이나 가치관 형성에 큰 영향을 미쳤다면 언급할 수도 있겠지만, 대부분의 경우 이런 정보는 자기소개서에 꼭 필요하지 않습니다.
- 이름
- 깃허브
- 블로그
- 이메일
- 핸드폰번호
깃허브 프로필 만들기
면접에 들어가면, 내가 진행한 프로젝트의 코드를 바탕으로 질문하는 경우가 많은데요. 이때 깃허브 프로필을 통해 면접관이 내가 한 프로젝트와 코드를 한눈에 파악할 수 있도록 하는 것이 좋습니다. 거창하게 작업할 필요는 없고, 깔끔하게 구성해서 신경을 썼다는 것을 어필할 수 있을 정도로 만들어주시면 됩니다.
인적 사항
저같은 경우는 블로그에 꾸준히 기록한 문서들을 저의 강점으로 어필했습니다. 이런 식으로 개발자로서 나의 하드 스킬, 소프트 스킬을 어떻게 하면 잘 보여줄 수 있을 지를 자기 소개서에 간략하게 보여주세요. 자기소개란에 대표적으로 적어야 하는 것이 있습니다.
- 간단한 자기소개
- 어떤 스택으로 뭘 했는지
- 왜 개발자가 되려고 하는지
- 개발자 커리어의 목표
- 자기 어필할 수 있는 포인트
특히 개발자가 되려는 이유에 대해선 꼭 적어주셔야 합니다. 면접에서 100%의 확률로 질문을 받을 수 있기 때문에 꼭 고민하셔서 잘 적어두는 것을 추천합니다. 단순히 인기 있는 직업이어서 선택했다고 말하지 말고 내 경험과 빗대어 개발자를 하고 싶은 이유를 설명할 수 있어야 합니다. 뿐만 아니라 개발자로서의 목표, 어필 포인트를 잘 생각하셔서 이력서에 간단하게 녹여서 면접까지 대비하는 이력서를 완성하시기 바랍니다. 저같은 경우는 블로그에 꾸준히 기록한 문서들을 저의 강점으로 어필했습니다.
3) 기술 (스택)
기술 내용을 적을 때는 2가지 전략이 있습니다. 첫 번째, 잘 숙지하고 있는 내용만을 기술할 것, 두 번째 사용한 것을 모두 기술하는 것이 있죠. 제가 많은 분과 이야기해본 결과 첫 번째 방안이 더 담백하고 적절하다는 이야기를 많이 들었습니다. 만약 이력서를 풍부하게 구성하고 싶어서 두 번째 방안을 선택하셨다면, 기술한 모든 내용들을 면접 전까지 충분히 숙지해야겠죠. 이력서에 In-Memory DB인 Redis를 사용했다고 적었다면, 면접관에게 어떤 질문을 받을 수 있을까요? 제가 받았던 꼬리 질문의 형식으로 리스트를 만들어 보겠습니다.
- Redis를 어떤 목적으로, 왜 사용했는지
- In-Memory DB의 특징은 무엇인지
- Redis의 특징은 무엇인지
- In-Memory DB인 Memcached도 있는데, 왜 많은 사람들이 Redis를 사용하는지
- Redis와 Memcached의 차이점은 무엇인지
저는 사용한 기술 스택에 대해 질문을 받으면, 위의 질문들처럼 짧게는 5단계에서 길게는 8단계까지 꼬리 질문이 이어졌죠. 이런 내용은 단순히 외워서 대답할 수 있는 것이 아닙니다. 오직 자신이 관심을 가지고 깊이 있게 찾아보았을 때만 대답할 수 있는 내용입니다. 사실 신입에게 이런 질문을 하는 것은 다소 과한 면이 있습니다. 하지만 반대로 생각해 보면, 이런 깊이 있는 질문에 모두 대답할 수 있는 신입은 매우 매력적일 것입니다. 특히 개발 공부를 한 기간이 짧음에도 불구하고 그렇게 할 수 있다면, 그 사람은 효과적인 공부 방법을 가지고 있으며 빠르게 성장할 수 있는 잠재력을 지녔다고 볼 수 있습니다. 그러나 이런 수준에 도달하기 위해서는 엄청난 공부량이 필요하기 때문에, 가급적 이런 방식을 추천하지는 않습니다. 대신 자신이 사용한 기술에 대해 깊이 있는 이해를 하고, 그 내용을 자신의 언어로 설명할 수 있도록 준비하는 것이 더 현실적인 접근 방법일 것입니다.
또 하나 강조드리고 싶은 부분이 있습니다. 기술 내용을 적을 때 별점을 매기거나, 상중하 등의 등급을 매기는 것은 피하는 것이 좋습니다. 최근에 이력서 관련해서 받은 피드백 중에 "요즘 신입들은 별점이나 등급을 붙이던데, 이 이력서에는 그런 것이 없어서 좋네요." 라는 피드백이 생각이 나는데요. 면접관님의 말씀에서 알 수 있듯이, 별점이나 등급이 매력적인 이력서로 보이는 데는 도움이 안 된다는 걸 알 수 있습니다. 단계를 나누는 것이 매력적이지 않는 이유는 그런 단계를 나누는 기준이 모호하기 때문입니다. 신입인데 '상'으로 표기한 것 자체가 모순적이고, 게다가 '상'으로 표시한 스킬들에 대해서는 꼬리 질문이 엄청나게 들어옵니다.
- 자바스크립트는 프로토타입 기반 객체지향인데, 프로토타입에 대해 알고 계신가요?
- 그렇다면 프로토타입과 일반 객체지향 언어의 차이점은 무엇일까요?
- 이미 프로토타입이 존재하는데, 왜 자바스크립트는 클래스를 도입했을까요?
- 자바스크립트의 클래스는 다른 언어의 클래스와 어떤 점이 다른가요?
이런 질문들에 제대로 답하기란 쉽지 않습니다. 결국 스킬을 과대평가한 것이 드러나게 되죠. 따라서 이력서에 별점이나 등급을 매기는 것은 피하는 것이 현명합니다. 대신 자신이 해당 기술을 어떻게 사용했는지, 어떤 경험이 있는지를 구체적으로 서술하는 것이 더 좋은 방법입니다. 그럼 기술 스킬을 어떻게 적어야 할지 궁금한 분들도 계실거라고 생각하는데요. 이 부분은 정답은 없습니다. 제가 쓴 예시를 보여드릴게요.
이런 방식으로 이력서를 작성하면 면접에서 어떤 질문이 나올지 어느 정도 예측하고 대비할 수 있습니다. 제 이력서를 기준으로 실제로 받았던 질문들을 정리해 보겠습니다.
- JS에서는 무슨 이유 때문에 예기치 못한 에러가 발생하며, TS를 사용할 경우에는 어떤 차이가 있을까요?
- ES6에 추가된 문법 중, 중요하다고 생각하는 것을 몇 가지 이야기해 주세요.
- Express와 Nest의 차이는 무엇인가요?
- Nest만이 가지고 있는 특징은 무엇인가요?
- IoC, DI, 싱글톤 패턴은 무엇인가요?
- 객체지향에서 중요한 것이 무엇인가요?
- MySQL이 아닌 다른 RDBMS는 무엇이 있고, 어떤 차이가 있나요?
- NoSQL과 SQL의 차이, 그리고 언제 어떤 것을 사용하면 좋을지 알려주세요.
- In-memory DB의 특징은 무엇이 있으며, Redis는 다른 메모리 DB와 어떤 차별점이 있나요?
- ORM을 사용하는 이유는 무엇인가요? 또한, ORM이 아닌 SQL을 사용할 줄 아시나요?
- Docker를 사용하면서 얻을 수 있는 이점은 무엇이 있나요?
- Docker가 생기기까지 어떤 과정이 있었나요?
- 클라우드 시스템을 왜 사용하게 되었을까요? AWS, Azure에 대해서는 들어보셨나요?
- OAuth2에 대한 지식이 있으신가요?
- Serverless라는 의미에 대해서 말씀해 주세요.
- Kubernetes는 무엇이고, 왜 사용하는 것인가요?
- CI/CD는 무엇인지 설명해 주세요.
- Git flow에 대하여 알고 계신가요?
- Git flow의 브랜치들이 어떤 목적에서 사용되는지 설명해 주세요.
- 엘라스틱서치의 특징을 알려주세요.
- 분석기에 대해 아시나요?
- 엘라스틱서치의 토크나이저에 대해서 아는 것을 모두 말씀해 주세요.
- Logstash를 사용하면서 얻을 수 있는 장점이 무엇일까요?
- GraphQL과 REST API의 장단점을 이야기해 주세요.
- RESTful하다는 것은 어떤 의미를 가지고 있나요?
- REST에 대해서 알고 계실까요?
이렇게 질문을 유도할 수 있습니다. 이런 질문들이 나올 것으로 예상하고 준비한다면 훌륭한 답변을 할 수 있을 것입니다. 저는 위 질문의 90% 이상은 답변할 수 있을 것 같습니다.
4) 자기소개
이제 이력서의 꽃이라고 할 수 있는 자기소개 파트에 대해 이야기해 보겠습니다. 개발자들의 이력서에는 보통 자기소개서가 포함되지 않기 때문에, 이 파트가 더욱 중요합니다. 여기서 가장 중요한 점은 자신을 어필할 수 있는 모든 것을 자세하고 길게 적어야 한다는 것입니다. 하지만 이것이 무조건 5줄, 10줄씩 적으라는 의미는 아닙니다. 가급적이면 3~5줄 내외로 간결하게 마무리하되, 그 안에 자신의 강점, 경험, 가치관 등을 최대한 담아내는 것이 좋습니다.
신입 개발자의 이력서는 왜 자세하고 길게 작성해야 할까요? 이는 신입이라는 특수성 때문입니다. 경력직의 경우 이미 결과물이 존재하지만, 신입은 대부분 결과물이 없기 때문입니다. 회사 입장에서는 신입을 뽑는 것이 리소스 낭비로 여겨질 수 있고, 경력직을 선호하는 것이 사실입니다. 그럼에도 불구하고 회사에서 신입을 뽑는 이유는 단 하나, 바로 "숨겨진 다이아몬드 원석"을 찾기 위해서입니다. 많은 개발자들은 "개발은 누구나 할 수 있지만, 진정한 개발자가 되는 것은 어렵다"고 말합니다. 단순히 코드를 따라 치는 것이 아니라, 이해하고 자신만의 스타일로 코드를 작성할 수 있는 사람을 개발자라고 부르는 것이죠.
이는 단순히 공부를 잘하는 것과는 다른 영역입니다. 그래서 개발 업계에서는 학벌을 그다지 중요하게 여기지 않습니다. 만약 학벌을 본다면, 현재 업계에 있는 수많은 비전공자가 존재할 수 없을 것입니다. 본인의 실력을 증명할 수 있다면 누구든 인정받을 수 있습니다. 따라서 신입 개발자는 자신이 누구인지, 어떤 가치를 가지고 있는지를 보여주기 위해 이력서를 자세하고 길게 작성해야 합니다. 이는 사람마다 다르겠지만, 이력서의 자기소개란에 자신의 강점을 좀 더 세부적으로 설명할 수 있는 공간입니다. 자기소개란에는 다음 4가지 요소인 강점, 가치관, 경향성, 경험을 포함하여 작성하고, 이를 뒷받침할 수 있는 경험을 서술해야 합니다. 이론만으로는 이해하기 어려울 수 있으니, 제가 작성한 이력서의 일부를 예시로 들어 설명해 드리겠습니다.
- 강점
- 자신이 알고 있는 것을 문서로 만들 수 있는 사람
- 가치관
- 저는 어릴 때부터 알고 있는 것들을 토대로 글을 작성하는 것을 즐기곤 했습니다.
- 경향성
- 이해가 되지 않는 부분을 정리해서 포스팅을 하는 것으로 배운 것에 대한 복습을 하기 시작하였고
- 경험
- 벌어진 다양한 문제를 매일매일 포스팅하였고 비슷한 문제가 발생할 때마다 적어놓았던 것을 찾아서 금방 해결할 수 있게 되었습니다.
자기소개서를 작성할 때, 앞서 설명한 구조를 따라 작성한다면 높은 평가를 받을 수 있습니다. 특히 저 같은 경우에는 문서화를 강조했기 때문에, 저는 자기소개서 하단에 제 블로그 링크를 첨부하여 증거 자료로 제출했습니다.
5) 경험(프로젝트)
개발자 이력서에서 경험 파트는 자기소개보다 더욱 중요한 부분이라고 할 수 있습니다. 이 부분에 대해서는 제가 자신 있게 이야기할 수 있을 것 같습니다. 왜냐하면 수많은 피드백을 받으면서 이 부분에 대해 "더할 나위 없다"는 평가를 받았기 때문이죠. 저는 부트캠프에서 총 3개의 프로젝트를 진행했습니다. 혼자 만드는 미니 프로젝트, 메인 프로젝트, 그리고 프론트엔드, 백엔드, 디자이너가 함께 만드는 팀 프로젝트였죠. 하지만 초창기에 만든 미니 프로젝트는 코드도 난잡하고 배포조차 되지 않은 상태라 공개하기에는 부끄러운 수준이었습니다. 그래서 저는 팀 프로젝트에 모든 것을 걸기로 결심했습니다. 팀 프로젝트를 시작하기 전, 전 기수의 발표 시연 영상을 보면서 한 가지 생각이 들었습니다. 단 3주 만에 기획부터 발표까지 마무리한다는 것이 쉽지 않아 보였던 것이죠. 마땅한 기획이 나오기 어려울 것 같았기에, 제 메인 프로젝트의 기획을 보완하고 볼륨을 키워 팀 프로젝트에서 활용해 보기로 했습니다.
팀원이 랜덤으로 정해지고, 각자 하고 싶은 프로젝트에 대해 투표를 진행했습니다. 그 결과 제가 건의한 프로젝트가 채택되었고, 저는 팀 리더와 PM(Project Manager)의 역할을 맡게 되었습니다. 이로써 프로젝트의 모든 것을 책임져야 하는 상황에 놓이게 된 것이죠. 프론트엔드, 백엔드, 디자이너 모두가 저에게 의견을 묻고, 제 답변을 기다리는 상황까지 이르렀습니다. 하지만 이는 바람직하지 않다고 판단했습니다. 그래서 모든 팀원이 자유롭게 의견을 개진하고, 할 수 있는 것은 모두 해보자는 방향으로 프로젝트를 이끌어 나갔습니다. 그러나 이런 과정도 중요하지만, 결국에는 이를 증명할 수 있는 결과물이 있어야 의미가 있습니다. 그래서 저는 팀원들에게 "모두가 매일 회고록을 작성하자"고 제안했습니다.
팀 프로젝트에서 기획부터 체크까지 모든 것을 담당하다 보니 작업량이 엄청났습니다. 팀원들 간의 분쟁이 발생하면 중재해야 했고, 같은 백엔드 팀원과도 다툼이 있어 조율해야 했죠. 하지만 저는 이 모든 과정을 매일 회고록으로 작성하기 시작했습니다. 회고록에는 좋은 내용만 있는 것이 아닙니다. 제가 올바르지 못한 선택을 해서 다툰 일, 그리고 그에 대해 반성하는 내용도 포함되어 있죠. 하지만 저는 이것이 옳다고 생각했습니다. 사람은 완벽할 수 없고, 문제가 발생해도 그것을 해결하며 성장한다는 것이 저의 확고한 신념이기 때문입니다. 면접관이 부정적으로 볼 수 있다는 우려에도 불구하고, 저는 모든 것을 솔직하게 적었습니다.
그리고 이 회고록은 면접에서 엄청난 무기가 되었습니다. 회사에서도 팀을 이뤄 일하게 마련이고, 그 과정에서 다양한 갈등이 발생하기 때문입니다. 저는 회고록을 통해 그런 상황에서 어떻게 대처했는지, 팀장으로서 어떤 역할을 했는지 구체적으로 설명할 수 있었습니다. 또한 회고록은 제가 사용한 기술 스택에 대한 증명이 되기도 했습니다. 신입이 사용한 신기한 기술에 대해서는 분명 질문이 있을 것이라 예상했기 때문입니다. 프로젝트 당시에는 바빠서 세부적인 내용까지 알아보지 못했지만, 부트캠프 수료 후 회고록을 보충하는 글을 작성하며 부족한 지식을 채울 수 있었습니다. 덕분에 저는 경험 파트에 대해서는 "제가 정답"이라고 자신 있게 말씀드릴 수 있습니다. 특히 팀 프로젝트가 사실상 유일한 결과물인 부트캠프나 국비 교육 수료생들에게는 더욱 중요한 부분이라고 생각합니다.
6) 학력, 경력
경력 사항을 이력서에 포함시키는 것에 대해서는 다양한 의견이 있을 수 있습니다. 어떤 분들은 개발 경력이 없다면 아예 적지 않는 것이 좋다고 조언하기도 합니다. 하지만 저는 개인적으로 경력 사항을 적어야 한다고 생각합니다. 만약 아무것도 적지 않고 공백 기간이 길다면, 사회성이 부족한 사람으로 비춰질 가능성이 높기 때문입니다. 이는 서류 전형에서 불이익으로 작용할 수 있습니다.
반면에 다른 회사에서 일했다는 사실 자체가 어느 정도 사회성을 보장한다고 여겨집니다. 특히 개발자 커뮤니티에서는 커뮤니케이션 능력을 중요하게 여기기 때문에, 경력 사항은 오히려 긍정적으로 받아들여질 수 있습니다. 물론 업계가 바뀌어서 걱정이 될 수 있습니다. 다만 경력을 바꾼 이유에 대해서는 면접에서 명확히 설명할 수 있다면 남들과 차별화된 강점으로 어필할 수 있을 것입니다.
7) 자격증, 어학 점수
제가 특별한 자격증이나 어학 점수가 없어서 이력서에 쓰진 않았지만, 본인이 어필할 수 있는 부분이 있다면 꼭 적으시기 바랍니다.
Part 3. 이력서 제출 전 꼭 해야할 것
이력서 작성이 끝났다고 해서 바로 제출하는 것은 좋지 않습니다. 아무리 글쓰기에 능숙한 사람이라도 한 번 작성한 내용을 처음부터 끝까지 꼼꼼히 읽어봐야 합니다. 그러면 오타, 어색한 문장, 강조하고 싶었지만 미흡한 부분 등이 보일 것입니다. 이런 부분을 개선하기 위해 작성한 이력서를 바로 제출하지 말고 다른 사람의 피드백을 받아보는 것이 좋습니다. 이력서를 다른 사람에게 보여주는 것은 가장 효과적인 방법입니다. 누구에게 보여주든 상관없습니다. 자신의 이력서를 부끄러워하지 말고 많은 분께 피드백을 요청하세요.
저의 경우 이력서를 작성하는 데 2주가량 시간을 투자했고, 약 30명에게 피드백을 받아 수정을 거듭했습니다. 먼저 부트캠프 동기, 친형, 개발자 지인들에게 이력서를 보여주었습니다. 하지만 아직 부족한 점이 있다는 것을 느꼈고, 그때부터는 커뮤니티에 도움을 요청했습니다. "신입 이력서를 작성해 봤는데, 피드백을 받고 싶습니다."라고 글을 올리면 생각보다 많은 개발자분이 리뷰를 해주십니다. 그들도 취업 준비 시절에 비슷한 고민을 했기 때문에 공감하고 조언을 아끼지 않습니다. 이렇게 다양한 사람에게 이력서를 보여주다 보면 공통적으로 지적되는 부분이 있습니다. 그런 피드백을 반영하여 이력서를 수정해 나가면 더욱 완성도 높은 이력서가 완성될 겁니다.
채용 과정에서 운이 상당 부분 작용하는 것은 사실입니다. 특히 지원 시기가 운에 큰 영향을 미치죠. 완벽한 역량을 갖췄다고 해도 타이밍이 맞지 않으면 원하는 결과를 얻기 어려울 수 있습니다. 반면 운 좋게도 회사에서 딱 필요로 하는 시기에 지원하면 좀 더 수월하게 취업에 성공할 수 있습니다. 하지만 이런 불확실성 때문에 지나치게 일희일비할 필요는 없습니다. 취업은 단기전이 아닌 마라톤과 같습니다. 한두 번의 실패로 좌절하기보다는 꾸준히 역량을 쌓아나가는 것이 무엇보다 중요하죠.
취업을 준비하는 주니어 개발자들을 위해 제 경험을 바탕으로 이력서 작성과 면접 준비에 대한 조언을 담아봤습니다. 부족한 글이지만 여러분에게 조금이나마 도움이 되기를 바랍니다. 최대한 많은 분들에게 유익하길 바라며 글 마치겠습니다.
🚢 개발자 이직 준비, 어떻게 시작해야 할지 모르겠나요? 한 단계 더 도약하는 험난한 항해에서 든든한 메이트가 되어드리겠습니다.
성장의 한계를 느끼고 있는 주니어 개발자들은 항해 플러스와 함께 하시면 됩니다. 기본기 역량 강화부터, 커리어 점프시켜 줄 TDD/성능최적화 프로젝트와 이직 코칭까지 한번에 할 수 있습니다. 성장을 향한 강한 의지만 있다면 항해 플러스 10주 성장 코스로 이직을 도전해보세요.
CREDIT
글 | 백엔드 주니어 개발자 유도근
Share article
Subscribe to our newsletter