Table of Contents

멘토링에서 자주 이야기 하는 이력서 피드백

일년에 몇 차례 멘토링을 진행할 때가 있다. 대학교 후배들 부터 직장 또는 커뮤니티에서 만나는 다양한 개발자 분들과 이야기를 나누게 되는데, 종종 이력서 피드백을 요청받고는 한다. 현업 면접관으로 참여한 경험도 있고 해서, 그 순간 ‘우리팀에 함께 했으면 하는 분은 누구일까?’ 라는 컨셉으로 이력서를 살펴보고 피드백을 드렸다.

그러다가 경험이 쌓이다 보니, 자주 이야기 하게 되는 내용들이 있어 이를 정리해보았다.

생각해 볼 것

이력서에 대한 피드백을 정리해보면, 결국 글을 어떻게 작성해야하는 가에 대한 질문으로 정리된다. 다음과 같은 주제를 고려해보자.

생각해 볼 것 1 - 이력서는 누가 읽을까?

이력서를 작성하는 순서는 대략 다음과 같다.

지원자는 자기 소개, 개발 스킬셋, 프로젝트 경험에 대한 내용을 이력서에 작성한다.
자신이 생각하는 어필할 수 있는 내용들을 채워넣기 시작한다.
여러차례 반복하며 이력서의 형태를 다듬는다.
마지막으로 빠진 부분이 없는지 체크하고 오타가 없는지 확인한다.

여기서 생각해볼 것은 “이력서도 하나의 글” 이라는 점이다.

따라서 독자가 있으며, 그 독자는 일차적으로 서류검토자, 나아가서 내가 일하게 될 팀의 리더가 될 확률이 높다.

생각해 볼 것 2 - 나는 누구인가?

이력서를 작성할 때 결국 나라는 사람이 드러나야 한다. 왜냐하면 결국 최종적으로 이력서를 통해서 결정하고자 하는 것은 나의 동료가 될 사람을 찾는 것 이기 때문이다.

따라서 자신이 문제 상황에서 어떤 점을 고려했고, 어떤 점을 중요하게 생각했는지 드러내는 것이 좋다. 자신의 가치관을 표현하는 것이다.

단순히 내가 수행한 이력들을 나열하는 것은 정보의 목록에 그칠 뿐이다. 이력서를 통해서 그 사람을 궁금하게 만드는 것이 필요하지 않을까?

문제점 요약 - 읽는 사람 입장에서 읽기 쉬운 이력서

결국 내가 공통으로 피드백하는 내용은 다음과 같다.

읽는 사람 입장에서 읽기 쉬운 이력서를 작성하자

내가 피드백한 대부분의 경우 이력서가 담고 있는 내용이 지원자의 관점에서만 고려되어 “나는 무엇무엇을 해보았다.“의 나열인 경우가 많아, 읽는 사람 입장에서 궁금증이 해소되기 어려운 경우가 많았다.

작성한 이력서를 지원자 입장이 아니라, 글을 읽는 독자의 관점에서 바라보자면, 결국 최종적으로 ‘나와 같이 일하게 될 팀의 리더’ 가 이 이력서를 바탕으로 나의 면접 통과 여부를 결정하게 된다.

그렇다면, 이력서라는 글은 독자의 입장에서 읽기 쉽게 작성되어야 하는 것이 좋지 않을까? 따라서 동료가 될 사람을 찾고 있는 팀의 리더 입장에서 궁금한 것들을 잘 정리해놓고, 지원자가 어떤 사람인지 무엇을 중요하게 생각하는지 생각이 잘 드러나는 내용이 있으면 좋겠다고 생각한다.

주요 점검 사항

문제점을 해결하기 위해서 다음과 같은 점검 사항을 요약해보았다.

읽는 사람을 위해 작성시 고려할 부분들

지원 포지션과 관련있는 내용으로 통일하기
- 이력서 전반에 걸쳐 경력 기간, 업무 내용, 경험해본 기술 스펙등이 일관되기를 기대한다. 종종 지원 포지션과는 무관한 경험이 분량을 위해서 채워져 있는 인상을 받을 때가 있는데 불필요한 내용을 읽는 느낌을 줄 수 있다.
불필요한 정보 제거하기
- 포지션과 무관한 학력정보(~~고등학교~~), 자격증(~~정보처리기사~~, ~~운전면허증~~), 연관성이 낮은 정보(~~다른 계통의 인턴경험~~)는 생략해서 핵심 내용을 부각시키는게 좋다.
스킬셋은 나열형식 보다는 조금 더 구체적으로
- 단순히 기술을 다룰 수 있다는 나열 대신에 사용한 최신 버전이나 실제 활용 경험, 본인이 다룰 수 있는 숙련도를 구체적으로 언급하는 것이 좋다.
프로젝트 경험
- 프로젝트 경험을 작성할 때는 팀의 규모, 본인의 위치와 역할을 추가하면 좋다. 실제 면접에서 주로 질문하는 내용들을 이력서 단계에서 파악할 수 있도록 작성하기
- 꼬리 질문을 생각해보고, 이 내용들을 이력서에 담아보자.
  - ‘이 프로젝트는 몇명이 진행한 프로젝트인가요?(이력서에는 기간만 있고 인원이 잘 표시되지 않아 질문하게 됨)’
  - ‘이 중에서 어떤 역할을 주로 담당하셨나요?(프로젝트의 전체 내용 위주로 작성되어 있고 어떤 역할을 중점적으로 수행했는지 잘 드러나지 않아 질문하게 됨)’
  - ‘프로젝트 진행중에 어떤 점이 가장 어려웠었나요?(트러블 슈팅 경험이 궁금함, 어떤 부분을 힘들어 하는지 알고 싶음)’
  - ‘그 과정에서 새롭게 알게 되었거나 배운점은 무엇이었나요?(경험을 통해서 어떤 부분을 성장시켜나갔는지 알고 싶음)’
- 정성적인 내용과 함께 정량적인 내용을 함께 작성하자.
  - “무엇무엇을 통해서 성능을 개선했습니다.” 보다, “무엇무엇을 통해서 성능을 30% 개선했습니다.” 라는 문장이 더 매력적이다.
  - 정량적인 내용이 어렵다면, 주위의 정성적인 의견 취합도 좋다. (ex) 이 작업 이후 동료들이 모두 긍정적인 효과를 체험했다고 이야기 해주었습니다.)

자신의 정체성을 드러내기 위해서

경험을 작성할 때 이야기를 쓰듯이 작성해보자. 내가 추천하는 방식은 S.T.A.R. 스토리텔링 기법이다.
- S : 상황(Situation) - 경험의 배경을 소개한다.
- T : 과제(Task) - 해결하고자 했던 문제를 구체적으로 작성한다.
- A : 행동(Action) - 문제 해결을 위해 구체적으로 어떤 행동을 했었는지 상세하기 작성한다.
- R : 결과(Result) - 도출된 결과를 정량적 데이터(예: 매출 20% 증가, 사용자 만족도 15% 상승 등)나 동료의 피드백을 통해 표현하면, 기여도를 효과적으로 어필할 수 있다.
소개에서 자신이 중요하게 생각하는 것들을 작성하자.
- ‘공유’, ‘생산성’, ‘커뮤니케이션’, ‘협업’, ‘UI/UX’ 무수히 많은 키워드 중에서 내가 핵심적으로 관심있고 중요하게 생각하는 가치를 뽑아서 드러내보자. 그러한 내용들을 실제 업무에서 어떻게 적용했는지 사례가 있으면 좋다.
- 경험에서 배운 점 강조 : 단순히 ‘무엇을 했다’가 아니라, ‘어떤 교훈을 얻었고 어떻게 성장했는지’를 작성해보면 좋다. 결국 이러한 내용들은 나중에 조직에서 어떤 시너지를 발휘할 수 있는지를 명확하게 보여주게 된다.

마무리하며

내가 피드백 하는 내용들이 항상 상황에 딱 들어 내용이라고 생각하지는 않는다. 다만, 여러번 경험하면서 검토자 입장에서 읽기 쉽도록 정리되어 있는 이력서가 좋은 이력서가 아닐까 생각한다.

결국 팀의 동료가 될 누군가를 찾고 있는 수많은 팀장들에게 ‘나 자신의 경험과 그 안에서 성장한 내용, 그리고 중요하게 생각하는 가치들’에 대해서 잘 설명할 수 있다면 초고속으로 합격통보를 보내지 않을까 한다.