[이력서] 나의 이력서 회고와 작성 방법 학습

0. 글을 적는 이유

나처럼 대차게 이력서를 까여본 개발자가 있을까 싶다. 지금까지 총 2번 현직 개발자에게 이력서를 들고 갔는데, 그 때마다 쓴 피드백을 많이 받았다. 받은 피드백을 3줄 요약해본다면, 다음과 같다.

이력서는 공식 문서임을 망각했다.

• SSAFY 등의 줄임말과 이모티콘은 제외해야 한다.
• 양식이 일관되어야 한다.

너무 과다한 줄글로 오히려 성과가 묻힌다.

• 본인 프로젝트를 아예 모른 채 읽는 개발자는 이것을 이해하지 못한다.

작년 SSAFY 컨설턴트님들에게 대차게 까인 후 재정비한 이력서였기 때문에, 자신이 있었으나, 또 이런 피드백을 받아서 좌절했다. 글을 과다하게 많이 적었던 이유는, 대동소이한 신입 개발자들 사이에서, 내 Detail을 어필하고 싶어서였다. 면접에 부를 개발자를 뽑을 때, 이력서가 재미 없으면, 포트폴리오는 보지 않은 채 넘어가는 경우가 많다고 들었기 때문이다.
이번 글에서는 요즘IT의 인기글이었던 뽑히는 개발자 이력서는 어떻게 만드나요?를 읽어보며, 작성 방법을 새롭게 재정의하고 가려고 한다.

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

0. '자신이 한 일을 사실 위주로 간결하게 써라'는 신입에게 오히려 역효과

이는 경력자들에게 유용한 방식이지, 신입에게는 아니다. 왜냐하면, 환경이 한정되어 있는 신입 개발자들의 경험은 대동소이하기 때문에, 이름과 연락처만 가리면 전부 똑같은 이력서가 되기 때문이다. 이러면, 경쟁자에게 좋은 이력서가 되어버린다.

그럼 어떻게?

'자신이 한 일'보다는 '자기 자신'을 이력서의 주제이자, 주인공으로 삼고 작성해야 한다.
나를 모르는 상대방의 머리에 나를 모델링하는 이력서를 적어야 한다.

1. 컨셉은 구체적으로 잡기

이력서에 한 줄 소개 컨셉을 그저 협업을 잘하는 개발자라고 두면, 너무 범위가 넓고 잘 와닿지 않음. 따라서 팀이 한 몸처럼 움직이도록 눈치 빠르게 협업하는 백엔드 개발자 수준으로 구체적으로 잡아야 한다.

이건 잘하고 있는 듯 함

2. 주제를 받쳐주는 힘이 강한 순서대로 쓰자.

보통 핵심 요약 ➜ 보유 역량, 기술 ➜ 경력 ➜ 학력, 교육 이력 순으로 적는데, 신입은 이력서의 주제 (아까 정한 컨셉)을 바쳐주는 힘이 강한 순서대로 배치하는 게 좋다.
왜냐하면, 아까 위에 한 줄 소개나 핵심요약을 던질 때 자신의 컨셉 (ex- 팀이 한 몸처럼 움직이도록 눈치 빠르게 협업하는 백엔드 개발자)으로 호기심을 일으켰기 때문이다. 그렇기에 자신이 던진 떡밥을 회수할 수 있는 설득이 그 이후에 이루어져야 한다. 그렇지 않으면, 읽는 이는 금방 호기심을 잃고 사라진다. 세뇌에 가깝게 자신의 컨셉을 반복 주장하고 설득하자

글쓴이는 굳이 프로젝트도 최신순일 필요가 없다고 한다.

이 점에서 나는 조금 혼란스러웠다. 왜냐하면 현직자에게 받은 피드백 중 하나는 최신으로 써라 였기 때문이다.

3. 왜, 어떻게, 그 결과 무엇을, 순으로 배치하자.

잘못된 이력서

• 프로젝트에서 '내가, 무엇을, 했다'만 나열
• 수행한 자기 자신보다 그 프로젝트 소개에 골몰됨.

제대로 작성하려면?

• 프로젝트 소개는 간단하게: 프로젝트가 주인공이 되지 않도록
• 문제 정의 : 내가 한 행동을 왜 했는지에 대한 내용
• 문제 해결: 문제를 어떻게 해결했는지에 대한 내용
• 결과: 결과적으로 무엇을 해냈는지에 대한 내용
• 자신이 선정한 주제와 상관 없는 내용, 기술 스택은 과감히 처내기: 이력서의 일관성이 중요

4. 분량보다는 내용이 더 중요하다.

위처럼 적는다면 내용이 다소 길어질 수 있다. (4~5 장) 이게 많아보인다고 해서, 무작정 줄이면 안된다. 분량보다 중요한 것은 내용이다. 볼 것 없고 짧은 이력서보다 읽을 것이 길며 흥미 있는 긴 이력서가 낫다.

흥미 있는 긴 이력서란?

• 읽는 이의 흥미가 식지 않게 주제를 받쳐 주는 내용이 끝까지 제시되는 이력서
• 단순히 프로젝트를 여러 개 나열하지 말고, 하나라도 '나'를 제대로 설명하고 설득할 수 있다면 그것에 대해 깊게 적고, 나머지는 쳐내라

그럼에도 내용을 좀 줄이려면?

• 내가 뒤에 배치한 것 (자신 없는 것, 이력서의 주제랑 좀 멀어진 것) 위주로 쳐내는 것이 좋다.
• 이력서의 주제를 잊게 만들거나 주의를 산만하게 만드는 것은 과감하게 잘라내기

5. 나만 알고 있다고 가정하자 (수상 관련)

상대방은 내가 지원한 해커톤 입상이 얼마나 대단한지 알지 못한다. 따라서, "자랑하려면 제대로 자랑" 해야 한다. 몇 명 중에 몇 등이며, 얼마나 힘든 건지 상세히 어필 해야 한다.

잘못된 방식

• 00 해커톤 금상 수상

올바른 방식

• 00 해커톤 100개 팀 중에서 3위 입상
  기여: 자세히 설명
  프로젝트 개요: 간단하게 설명
  세부 성과: 타팀이나 심사위원으로부터 받은 피드백 넣기

이력서의 주제는 프로젝트가 아닌 나 임을 상기해야 한다. 똑같이 상대방이 궁금한 건 내가 참가한 대회가 아니라, 대회에 참가한 나 이다.

6. 신입에게 기대하는 건 전문성이 아니다. (교육 항목 관련)

마찬가지로 교육사항 소개도, 교육 프로그램 자체 소개보다, 그것을 수료한 나를 소개하는데 집중해야 한다. 그러기 위해서는 상대방에게 익숙한 정보로 전달해야 한다.
(ex - 교육 참가 경쟁률, 수료율, 하루 평균 몇 시간 정도 집중하는 커리큘럼인지)

이러한 정보로 채용 담당자가 원하는 것?

지원자가 교육 기관을 수료하는데 들인 시간과 수료 이후의 성장폭이 얼마 정도인지 확인하고 싶어 한다.
왜냐하면, 그것을 통해 자사 시니어 개발자의 자원을 하루 평균 N%씩 몇 개월 들여야하며, 그 비용을 감수할 수 있는지 견적을 내고 싶어하기 때문이다.

7. 내가 인식하는 나를 상대방에게도 최대한 동일하게 인식시키자.

이력서를 읽고 나면, '나'를 머릿속에 그릴 수 있어야 한다.
좋은 이력서는 생전 만나본 적 없는 사람이 몇 장짜리 문서를 읽고 난 뒤에 '나'란 인간을 자신의 머릿속에 모델링할 수 있게 만드는 것이다.

8. 이력서 체크 리스트

• '내가 어떤 사람이다.' 라는 주제를 서두에 선언했는가?
• 읽는 사람의 생각이 주제에서 이탈하지 않고 계속 읽어나가도록 내용이 일관되었는가?
• 나의 프로젝트, 수상이력, 교육사항이 주연이고 내가 조연이 되지는 않았는가?

'서류 탈락을 거듭한 끝에 깨달은 신입 개발자 이력서 작성법' 글 요약

1. 관심을 끌 수 있는 타이틀 활용

• 현직자는 자기 할 거 하면서 서류도 봐야 하는데, 재미 없으면 안 읽음

2. 채용공고에 맞춰 기술 역량 커스텀

• 회사의 자격조건과 우대사항과 동떨어져 있으면 어필이 크게 되지 않고 오히려 가독성만 해친다.
• 따라서 모든 기술 경험을 나열하는 대신 회사의 자격 조건과 우대사항에 맞춰 불필요한 부분을 제거하자.

3. 보기 좋은 이력서 만들기

• 글씨 빽빽, 보기 힘든 이력서는 안 좋음 ➜ 시각적으로 매력적으로 보이게 하는 게 좋다.
• 글보단, 그림 많이
• 예쁜 디자인 필요 없음, 깔끔한 디자인

4. 문서화한 작업물은 링크 첨부하자.

• 트러블 슈팅 따로 안 적어 놓으면 면접관들이 잘 안 믿는다.

5. 필요 없는 정보 제거

• 품질 보증이 중요함.
• 비슷한 내용이거나 어필할 수 없는 내용은 과감히 삭제해서 가독성을 높이자.
• 해당 글의 글쓰이 또한 3개에서 2개로 프로젝트 줄였다고 함.

6. 스터디 및 커뮤니티 활동 작성

• 단순한 참여 내역이 아닌 활동과 배운 점, 어떤 역량을 키웠는지 서술하기

3. 래퍼런스

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

서류 탈락을 거듭한 끝에 깨달은 신입 개발자 이력서 작성법