주니어 개발자의 이력서엔 어떤 내용이 들어가야 할까?

📌 글 작성

기술 문화에 관심이 많은 F-Lab 백엔드 멘토 Kyle
성장에 목마른 NAVER 출신 시니어 엔지니어 🧑🏻‍💻

이력서의 사전적 정의를 살펴보면, 주로 취업을 목적으로 자신의 정보(학력, 경력, 스펙 등)를 기록하는 서류이자 공식적으로 본인이 입사 및 입학 등의 지원 분야와 관련된 무슨 일을 했는지에 대해 기록하는 문서라고 나와있습니다. 각 기업에서는 입사 전형의 가장 처음에 등장하여 서류심사의 기준이 되곤 하죠. 본인의 기술이 매우 뛰어나다고 할지라도 이력서 작성을 잘 못하면 면접의 기회조차도 얻지 못하는 경우도 다반사인 것 같습니다. 개발자의 채용에서도 마찬가지입니다. 채용의 종류가 신입이든 경력이든 우선 이력서를 제출한 다음에 과제나 코딩 테스트를 진행하며 면접을 진행하기 위한 최소한의 자격을 검증하고 있는데요. 이러한 이력서를 단순히 취업을 하기 위한 최소한의 절차로만 봐야 할까요?

이번 글에서는 개발자로서 이력서에 대해 어떤 관점을 가지고 있어야 할지, 어떻게 작성하고 어떤 식으로 관리를 해 나가야 할지에 대해 다양한 시선으로 이야기해 보고자 합니다.

# 이력서란 무엇일까?

앞서 이야기 한 것처럼 회사에 취업을 하기 위해 가장 첫 관문으로 활용되는 게 바로 이력서입니다. 소개팅을 나갔을 때 첫인상이 중요하여 외모를 신경 쓰는 것처럼 이력서도 회사 입장에서 수많은 지원자들 중에 “괜찮은 지원자”를 거르기 위한 도구로 활용되는데요. 그렇기에 이력서를 가볍게 여기며 별 고민 없이 작성하거나, 너무 과장하여 있지도 않는 거짓 경험이나 허위 능력을 적는다면 소개팅에서 다음 약속 잡는 것에 실패하는 것과 같이 서류 전형에서도 탈락할 확률이 매우 높습니다. 뒤에서 자세히 이야기하겠지만 이력서가 단지 서류 전형에서만 활용되는 것은 아닙니다.

먼저 개발자의 채용 프로세스는 일반적으로 아래에 명시된 단계로 진행됩니다. (각 단계는 생략되거나 몇 차례 더 진행되는 경우도 있습니다.)

1. 서류전형(이력서 검증) 
2. 코딩 테스트 또는 개발 과제(온라인, 오프라인으로 코딩 능력 검증) 
3. 기술면접(1:1 혹은 1:N으로 회사 실무자와 대화를 하며 기술에 대한 집적적인 검증) 
4. 인성면접(리더 혹은 임원과 회사의 문화에 어울리는 사람인지 검증)

이러한 채용 프로세스에서 이력서는 기술면접이나 인성면접에서 면접관에게 전달되는 정보로 활용되기 때문에 신중하게 작성해야 합니다.

특히 개발자에게 이력서는 다른 직군과는 조금 다른 형태로 작성이 되어야 합니다. 단순히 어느 학교를 나왔고 무슨 일을 해왔으며 어떤 자격증이 있다 정도가 아닌 보다 기술적인 내용이 중심이 되어야 합니다. 그래서 개발자들에게 “기술 이력서”라는 명칭이 더 어울리지 않나 싶은데요. 회사에서 주어지는 양식(템플릿)에 맞추어 이력서를 작성하기도 하지만 그전에 나를 잘 표현할 수 있는 형식을 골라서 언제라도 지원할 수 있을 정도의 범용적인 이력서를 작성해두는 것 또한 중요합니다. 그렇다면 개발자의 이력서에는 어떤 내용이 들어가야 할지 차근차근 살펴보도록 하겠습니다.

# 이력서엔 어떤 내용이 들어가야 할까?

이력서의 양(크기)는 얼마나 돼야 한다고 생각하시나요?

이력서를 작성할 때 보통의 경우 “내가 하고 싶은 말”을 쓰기에 급급하다 보니 하나부터 열까지 모든 내용을 구구절절 작성하는 경우가 많습니다.

하지만 이력서라는 존재의 이유를 잘 생각해 보면 내가 하고 싶은 말을 작성하는 것이 아니라 면접관 즉, “남이 듣고 싶은 말”을 써야 하죠. 만약 이력서의 양이 A4 기준으로 10장이 넘어간다면 면접관 입장에서는 어떤 생각부터 들까요? 아무리 훌륭하고 정말 좋은 경험을 해온 개발자일지라도 이력서의 “양”을 보고서 부담부터 느끼지 않을까 싶습니다.

그래서 이력서의 양은 최대한 압축을 해서 A4 기준 2~3장 내외로 작성하는 게 좋다고 생각합니다. “압축” 과 “제외”는 엄연히 다릅니다. 적게 작성하라는 이야기가 그저 제외를 하라는 메시지로 이해해선 안되고 수많은 내용 중에 나에게 득이 될만한, 그리고 기술적으로 어필해서 이력서를 보는 사람으로 하여금 궁금함이 느껴질 부분들만 요약 또는 압축을 하며 작성을 하는 게 핵심 포인트죠. 이력서의 양(limit)을 정했다면 안에 내용을 채워보도록 합시다.

1. 1~2문장 정도의 간단한 자기소개와 얼굴이 잘 나온 사진
2. 회사 안 또는 회사 밖에서의 기술적 경험
3. 마지막으로 본인이 사용할 수 있는 기술이나 관련 자격증 등 기타 항목

필자가 생각하는 일반적인 이력서의 포맷은 위 순서대로 정리하는 방식이라 생각합니다.

기술적 경험 영역에서는 단순히 무엇을 했다고 적는다거나 기술적 내용이 아닌 사업적 혹은 서비스 소개가 중심이 되기보다는 어떤 어려움 혹은 요구사항을 해결하기 위해 어떤 기술이나 방법을 사용하였고 그에 따라 기술적으로 어떤 효과 혹은 성과가 있었는지에 대해 어필하는 것이 더 좋습니다. TPS나 %(퍼센트) 같은 수치가 있으면 더욱 신뢰도가 높아지기도 하고요. 관련해서 내용을 구구절절 다 적기 어렵다면 미리 작성한 블로그 링크를 걸어두면서 그저 문제 해결만 하는 것이 아니라 기록(정리)을 해간다는 좋은 인상을 줄 수도 있을 겁니다.

이력서에는 본인이 어떤 부분에 관심을 가지고 개발을 하는가가 드러나야 합니다. 회사에서 시킨 일만 해서는 본인의 개발 색깔이 나타나기엔 다소 제한적이죠. 그렇기에 회사 안에서가 아닌 회사 밖에서의 활동을 정리하면서 시킨 일도 잘 하지만 시키지 않은 일도 잘 한다 혹은 회사 안에서도 잘 하지만 회사 밖에서도 개발 실력을 키우는데 노력하고 있다는 부분을 어필할 수 있어야 합니다.

# 이력서를 어떻게 활용할 수 있을까?

우리는 이력서를 신입사원으로 취업을 하기 직전이나 이직을 하기 직전에만 작성하곤 합니다. 대부분 평소에는 이력서를 작성할 이유나 생각조차 나지 않는 게 일반적인데요. 저는 이러한 이력서를 평소에도 관리를 해야 한다고 생각합니다. 여러 가지 이유가 있는데 언제라도 이직을 할 기회가 찾아오는 경우 부랴부랴 이제까지의 이력서를 정리하기엔 다소 시간이 부족할 수밖에 없죠. 더불어 가장 중요한 포인트는 이력서란 나 자신을 가장 잘 체크할 수 있는 거울이 된다고 생각합니다. 1개월 혹은 3개월, 6개월 적당한 주기를 정하고 그때마다 이력서를 업데이트하면서 얼마나 잘 성장하고 있는지 반대로 업데이트할 내용이 없다면 반성하는 기회로 삼고 다시 동기부여를 얻을 수도 있죠. 이처럼 주기적으로 계속 업데이트를 해가며 “나”라는 퍼스널 브랜드를 가꿔나가면 좋겠습니다.

이력서의 포맷은 정말 다양합니다. 워드나 한글 같은 파일로 작성하기도 하고 요즘엔 노션을 활용하기도 하죠. 저는 개인적으로 github에서 제공하는 호스팅 서비스를 활용해 공개적인 웹사이트로 만드는 것을 추천드립니다. 아무래도 git을 사용하다 보니 git log가 결국 이력서 업데이트 기록이 되어 이력서 관리를 잘 하고 있는지에 대한 기준이 되기도 하고 외부공개를 하게 되면 누군가 이력서를 보고 새로운 기회가 생기거나 외부에 공개한다는 약간의 압박이 이력서를 더 잘 가꾸게 만드는 동기부여가 되기도 하더라고요.

이렇게 개발자가 이력서를 활용하는 방법에 대해 살펴보았습니다. 마지막에 이야기했던 것처럼 이력서를 단지 회사 취업의 수단으로만 활용하는 것이 아니라 본인의 개발 역사가 잘 만들어지고 있는지에 대한 거울로써 활용해 보면서 차곡차곡 개발 경험들을 만들어 나가면 좋지 않을까 생각해 봅니다.