소프트웨어 개발자 입사 지원서(이력서) 작성시에 주의사항

입사 지원서는 새로운 회사에 입사하거나, 이직을 위해 제출하는 문서이다. 흔하게 이력서라고도 한다. 본인을 표현하는 문서이고, 지원하는 업무에 본인 적합하다는 것을 증명해야 하는 문서인데, 이를 몇장에 담기에는 결코 쉬운 일은 아닐 것이다.

여기서는 소프트웨어 개발자가 이력서를 작성하면서, 너무나 당연하면서도, 누구나 쉽게 실수하거나 착각하게 되는 항목에 관해서 설명하고자 한다.

자기소개는 업무 관련 내용만 넣어라!

신입 사원들이 자기소개서를 작성하면서 많이 실수하는 것 중의 하나는, 본인의 성장기나 가족 사항, 성격 등을 넣는 것이다. 예전에는 이게 맞았을 수도 있다. 어떤 환경에 어떻게 살았는지를 사람의 인성을 표현하기 위해서 필요했을 수 있기 때문이다.

하지만, 개발자 이력서에 있어서는 별로 크게 도움이 되지 않는다. 말 그대로 기술직으로 면접을 보는 것이니 개발 업무를 할 수 있게끔 얼마나 큰 노력을 하였고, 어떤 경력이 있는지는, 어떤 활동을 하였는지, 본인이 개발 업무에 어떤 열정을 가졌는지에 대해서 작성만 해도 충분하다. 가득이나 넣은게 많은데, 최대한 어필할 수 있는 글이 더 많은게 좋을 것이다.

이력서 활용할 수 있는 기술만 있으면 됐지, 자기소개서는 구지 안 써도 되는 거 아니냐고 생각하는 사람이 있을 수도 있는데, 면접 시간은 생각보다 짧다. 그 지원자의 단순 이력만 봐서는 채용 여부를 판단하기 힘들다. 채용은 일을 잘하는 사람을 뽑아야 하기도 하지만, 옆에 동료와 함께 일을 잘 진행할 사람을 뽑기 위함이기도 한다. 자기소개서는 이런 자격 요건을 이를 표현하는 수단으로 생각한다면, 결코 간과해서는 안 된다.

개발 스펙은 본인이 아는 내용만 써라!

이력서에 본인이 참여했던 프로젝트에 활용된 개발 스펙을 작성하면서 실수하는 것이 프로젝트의 스펙을 그대로 적는 경우가 있다. 그러다 보면, 적힌 기술 스펙이 본인과 연관된 경우도 있지만, 본인이 담당이 아니어서 기술에 대한 지식이 전혀 없는데도 들어가는 경우가 생기기도 한다. 이력서를 검토하는 면접관에 입장에서 보면, 당연히 적힌 스펙이 면접자가 이미 보유한 기술로 인식하게 되어 질문을 하게 되는데, 그러면 “제가 담당했던 업무가 아니어서 모르겠습니다.“라는 답변밖에 할 수 없게 될 것이다.

이력서에는 프로젝트에 활용된 개발 스펙 중에 본인이 직접 담당했던 기술만 들어가야 하고, 혹은 본인이 담당하지 않았더라도 기술에 대한 충분히 지식을 가지고 있고, 설명을 할 수 있다면 넣어도 된다. 그렇지 않으면 면접 질문 공격에 대상이 될 수 있음을 명심하자.

내용은 핵심만 전달 하자!

보통 면접관들은 지원자가 쓴 글을 다 보려고 하지 않거나, 다 보고 싶어도 다 볼 수 없는 경우가 많다. 그래서, 빠르게 본인이 보고 싶어서 하는 것만 보기 마련이다. 그러기에 문장은 짧게 핵심을 위주로 이력서를 작성해야 한다. 내용을 많이 채우려고 하기보다는 최대한 많이 전달할 수 있게끔 작성하는 것이 좋다.

경력이 쌓이다 보면 참여한 프로젝트가 많아지게 되는데, 그 모든 프로젝트를 그대로 다 나열할 필요는 없다. 오히려 기간이 짧은 프로젝트라면 괜한 오해받을 수 있다. 예를 들어, 짧은 기간의 프로젝트는 제대로 진행되지 않아 보이기도 해서, 오히려 안 좋게 보일 수도 있다.

내용에 스토리를 만들자! 이력서는 그렇게 재미있는 문서는 아니다. 특히 채용을 위해 면접관이 여러 이력서를 보다 보면, 내용이 거진 비슷하길 마련이고, 보는 사람이 지루할 수밖에 없는건 어쩔 수 없을 것이다. 이럴 때, 조금은 눈에 들어올만한 내용이 첨부되면 좋을 수 있다.

예를 들어, 본인의 경험에 의한 문제 해결 방법이나 트러블 슈팅, 프로젝트 성과 등 내세울 만한 내용으로 이야기를 넣는건 어떨까 싶다. 너무 길어서도 안되겠지만, 대략적으로는 본인의 열정과 프로다움의 모습을 보여줄 수 있는 글이라면 면접관의 눈에 띄는 이력서가 될 수 있지 않을까 싶다.

면접관이 이해할 수 있는 내용을 쓰자! 소프트웨어 개발에 기술은 무수히 많다. 이력서는 검토하는 사람, 즉, 면접관이 모든 것을 알고 있을 거라는 생각은 착각일 수도 있다. 물론 많이 알고 있는 사람이 면접관으로 들어와야 하지만, 아닌 경우도 있기 때문이다. 그래서, 이력서는 어렵게 쓰는 것보다 최대한 많은 사람이 이해할 수 있게끔 쓰는 것이 좋다.

이력서를 검토하는 입장에서 모르는 단어가 나오면, 내용을 파악하는 게 방해가 된다. 당연히 알 거로 생각하는 용어가 많은 사람이 모를 수 있을 거라는 생각이 든다면, 아예 빼거나 통상적인 단어로 변경하거나 풀어 써야 한다. 특히, 전 직장에서만 사용하던 용어 및 서비스명을 아무렇지 않게 쓰는 경우도 있는데 이는 최대한 피해야 한다.

활발히 활동하는 기술 블로그만 이력서에 넣자!

개발자들은 본인의 기술을 개인 블로그나 사이트에 작성하는 경우가 많은데, 본인의 생각을 정리할 수도 있고, 나중에 잊었을 때 찾아보기 위한 용도를 쓰일 수 있기에 좋은 습관이라고 생각한다. 요즘에는 이런 블로그를 이력서에 많이 넣기도 한다.

그런데, 내용이 별로 없거나 활동이 드문 본인의 기술 블로그나 사이트를 이력서에 아무 생각이 없이 넣는 경우가 있는에, 이는 오히려 독이 될 수 있다. 개발자는 항상 기술 트랜드 및 학습이 중요하기에, 기술 블로그는 본인의 이런 활동을 증명하기 위한 수단으로 활용될 것이다. 그런데, 아무런 내용도 없고 활동도 드문 블로그는 이력서를 넣는 건 아무 의미도 없을뿐더러, 이력서를 검토하는 입장에서는 있어서도 좋지 않은 인식이 생길 수밖에 없다.

본인의 이력서를 널리 알려라!

이력서를 다 정리하고 나서는 바로 제출하기보다는 지인들에게 전달하여 피드백을 받는 것이 좋다. 피드백을 해주는 사람이 경력, 학력 등은상관없다. 어느 누가 보든 피드백을 해줄 수 있는 사람이면 된다. 다른 사람의 의견이 많으면 많을수록 좋다. 날카롭게 지적을 해준다면 오히려 더 고맙다. 그 내용이 단순 비난이 아닌 진실이라면 뭐든 겸허히 받아들여야 하는 자세가 필요하다.

이력서 작성은 끝이 없다.

이력서는 아무리 잘 작성했더라도, 보는 사람의 관점이나 시간이 흐르고 나서 보게 되면 틈새가 보이기 마련이다. 이 말인즉슨 수정을 계속 하더라도 완벽할 수는 없다는 뜻이다. 사람의 생각은 모두 다르고, 다 같은 생각을 할 수가 없기에 언제나 다른 의견을 나올 수밖에 있다. 다만, 모든 사람이 만족하는 이력서는 작성할 수 없어도, 많은 사람들이 만족할 수 있는 이력서는 작성할 수 있을 것이다. 그리고, 시간을 흐르면서 본인의 상황과 이력은 계속 변화가 올 것이다. 그러면서 이력서도 같이 변화가 있어야 한다. 신입을 때와 경력이 쌓이면서 이력서는 분명히 달라야 하고, 세월에 따른 트렌드에 따라 수정에 되어야 한다.

그래서 이력서는 수시로 보완하고 정리하는 습관이 좋다. 당장 이직할 마음이 없더라도, 시간이 지나면 기억이 나지 않은 경우 생길 것이다. 그러기에, 본인의 업무가 마무리나 되거나, 기억해야 할 것이 있다면, 이력서에 계속 추가하고 정리를 하기를 추천한다.

마무리

최근에 아끼는 후배가 급작스럽게 이직해야 했다. 그러면서 내게 이력서 피드백을 요청하였고, 뭔가 정리해서 전달해 주면 좋지 않을까 하는 생각에 이글을 작성하게 되었다. 이력서는 면접 자리에서 나를 알리기 위한 문서이다. 내 이력서를 보는 사람, 즉 면접관의 입장을 한 번 더 생각해 보면서 작성한다면, 좋을 이력서를 작성할 수 있을 것이다.

위에서도 언급했지만, 사람의 생각은 모두 다르다. 내가 쓴 글이 다른 사람과 이견이 있을 수 있다. 그래도, 내 글이 어느 누군가에에 조금이라도 도움이 되었으면 하는 마음으로 이글을 마무리한다.