[이력서 가이드] 개발자 이력서 작성 가이드
들어가기 전에
- 해당 내용은 개인적으로 알아보거나 경험한 내용, 피드백을 취합한 내용이기에 정답이 아닌 의견입니다.
- 경험, 가치관, 자격 요건 등 기준에 따라 상반되는 의견도 존재할 수 있습니다.
- 면접자(구직자)의 기술 역량과 채용 공고의 자격 요건에 따라 내용과 순서가 달라질 수 있습니다.
- 해당 내용은 특별한 계기 없이도 언제든 수정될 수 있습니다.
이력서를 작성하기 전에
이력서란?
- 이력서는 구직자가 취직을 위해 제출하는 구직자의 정보, 기술 역량 등이 기록된 문서입니다.
- 사실 개발자의 이력서는
resume보다CV(Curriculum Vitae)에 가깝습니다.
- 사실 개발자의 이력서는
- 간단하게 말하면 구직자 판매를 목적으로 한 광고 전단지입니다.
- 따라서 이력서 작성 전에 구직자의 어떤 역량을 홍보하여 기업을 설득할 수 있는지 확인이 필요합니다.
이력서 파일 포맷
- 이력서 파일은 일반적으로
pdf로 변환하여 제출하도록 합니다.- 강제는 아니지만 다른 확장자 파일은 뷰어가 없다면 호환성 문제가 있을 수 있습니다.
- 최근에는
URL형태로 이력서, 첨부 자료(포트폴리오)를 제출하기도 합니다.
이력서 작성 시점
- 이력서는 항상 채용 공고에 맞춰 새로 작성해야 합니다.
- 자격 요건에 따라 이력서의 내용, 순서 등이 달라지기 때문입니다.
- 이와 별개로 항상 자신만의 이력서를 관리하는 것이 좋습니다.
- 자신만의 이력서를 갖고 있다면 채용 공고마다 새 이력서 작성이 쉬워집니다.
- 이력서의 갱신 주기는 짧을수록 좋기 때문에 항상 관리, 갱신하도록 합니다.
- 이직 의사가 없을 때도 관리하길 권합니다.
이력서 검토자
- 일반적으로 구직자(개발자)의 이력서 검토는 대부분 현직 개발자가 하게 될 것입니다.
- 개발자들은 본 업무 때문에 이력서를 보는데 대략
5~10분의 시간 정도만을 할애하게 됩니다. - 그래서 잘 읽히게 작성하여 짧은 시간 내에 나의 역량을 최대한 많이 보여줘야 합니다.
- 이것은 단순히 내 경험과 지식을 많이 나열하라는 뜻이 아닙니다.
- 요구되는 자격 요건에 부합하는 나의 역량을 잘 분별해야 한다는 뜻입니다.
- 이로써 그들이 나에 대해 흥미를 갖도록 만들어야 합니다.
- 개발자들은 본 업무 때문에 이력서를 보는데 대략
이력서 양식
- 자신의 역량을 제일 잘 어필할 수 있는 양식이 어떤 형태인지 고민해 보아야 합니다.
- 기존에 딱딱한 이력서 양식은 개발자의 기술 역량을 강조하기 어렵습니다.
- 일반적으로 정해진 양식이 없어 잘 읽히는 이력서라면 어떤 양식이라도 무방합니다.
- 간결하며 내용이 돋보여 기술 역량을 강조할 수 있는 양식을 선택하도록 합니다.
- 쉽게 읽히는 폰트와 크기를 선택해야 합니다.
- 기울기는 가독성을 이유로 되도록 사용하지 않는 것을 권합니다.
- 폰트의 굵기와 색상, 밑줄 등은 되도록 조금만 사용, 남발하지 않도록 합니다.
- 강조 목적으로 너무 많이 사용하면 오히려 읽기가 더 어려워집니다.
- 내용에 따라 글머리 기호를 활용하는 것도 가독성을 위한 좋은 예시입니다.
- 다채로운 색상과 불필요한 특수문자, 이모지 사용 등 화려한 양식은 지양합니다.
- 쉽게 읽히는 폰트와 크기를 선택해야 합니다.
- 기존에 잘 작성된 다른 분들의 이력서를 참고하면서 자신만의 이력서 양식을 만들도록 합니다.
이력서 분량
- 일반적으로 정해진 분량은 없으며 내용이 알차고 쉽게 읽힌다면 분량 자체는 크게 의미가 없습니다.
- 분량보다 더 중요한 것은 채워져 있는 내용입니다.
- 분량은 가볍게 훑어보기 좋은 정도면 충분하니 내용의 퀄리티를 고민합시다.
- 다만
word(pdf)와 같은 형식을 기준으로 대략5~10페이지 정도로 작성하는 것을 권합니다. - 너무 짧으면 볼 내용이 없고 너무 길면 강조 포인트를 찾기 어려워집니다.
- 다만
- 같은 내용도 폰트 크기에 따라 분량이 달라지기 때문에
1~2페이지 차이는 무관합니다. - 어떠한 목차라도 자격 요건에 부합하는 역량만을 작성하여 분량을 줄이도록 합니다.
- 요구되는 역량과 관계가 없거나 능숙하지 못한 역량을 빼도록 합니다.
이력서 작성 순서
- 기본 정보
- 자기 소개
- 주력 스킬(기술 역량)
- 경력 사항
- 재직 이력
- 수행한 프로젝트 이력 (프로젝트 경험)
- 그 외 활동
- 오픈 소스 프로젝트 or 사이드 프로젝트
- 기술 저서 출판 or 세미나 발표 or 강연/강의
- 수강한 강의
- 기타
- 학력 or 자격증
자격 요건이나 상황에 따라 기재 정보를 추가, 생략할 수 있습니다.
그 외 이력서 작성시 유의사항
- 모든 내용은 개발자의 관점에서 작성해야 합니다.
- 일반적으로 내 이력서를 읽는 사람도 나와 같은 개발자일 확률이 높습니다.
- 채용 공고의 기술 자격 요건, 포지션 등 조건을 꼼꼼하게 살펴봐야 합니다.
- 나의 역량을 해당 조건에 알맞게 녹여낸 이력서를 만들어야 합니다.
- 거짓말은 일절 하지 않으며 작성 내용은 반드시 증명 가능해야 합니다.
- 예를 들어 경험하지 않은 것을 경험한 것처럼 작성하는 행위는 하지 않습니다.
- 어렵겠지만 구체적인 내용을 간결하게 작성해야 합니다.
- 공식적이고 정확한 어휘를 구사하도록 합니다.
- 표준어를 사용하고 은어, 비속어, 신조어 등은 사용을 지양합니다.
- 애매하고 추상적인 표현보다 정확하고 구체적인 표현을 사용하도록 합니다.
- 축약어를 사용할 때는 되도록 명확하거나 널리 알려진 축약어를 사용합니다.
- 그 외에는 축약어가 처음 나오는 곳에 전체 뜻을 풀어 써주도록 합니다.
- 예 :
SEO->SEO(search engine optimization)or검색엔진 최적화
- 예 :
- 그 외에는 축약어가 처음 나오는 곳에 전체 뜻을 풀어 써주도록 합니다.
- 다른 부분보다 경력 사항 비중이 가장 높아야 합니다.
기본 정보
- 이름
- 메일주소
- 전화번호
- Github 주소
- 기술 블로그 주소
유의사항
- 상위 정보 이외에 나이, 자택 주소 등 자신의 역량과 무관한 정보는 빼도록 합니다.
- 깃허브, 기술 블로그 주소는 개발자의 역량 판단에 참고가 되는 자료일 뿐 필수가 아닙니다.
- 기재된 깃허브/블로그가 관리 되지 않는 상태라면 의미가 없습니다.
- 다시 말해 기재하지 않는다고 해서 감점 요인이 되는 것은 아닙니다.
- 하지만 개발자를 판단할 추가적인 자료, 지표가 되는 것 또한 사실입니다.
- 따라서 여유가 된다면 운영/관리하는 것을 권합니다.
자기 소개
자격 요건에 맞춰 나를 소개
- 간결하게
1~2문단, 전체5~10줄 미만의 분량으로 작성합니다.- 자신의 경험을 기반으로 주력 기술과 앞으로 어떤 개발자를 지향하는지를 설명합니다.
- 개발 업무에 적용시킬 수 있는 자신만의 차별화된 장점을 강조합니다.
- 꾸준한 학습 태도, 의사소통(협업 능력), 외국어 능력 등
유의사항
- 모든 내용은 증명 가능한 내용만을 작성하도록 합니다.
- 꾸준한 학습 태도를 강조하였다면 학습했던 이력들을 확인할 수 있어야 합니다.
- 개발과 무관한 사적인 내용은 의미 없이 분량만 늘리니 피하도록 합니다.
주력 스킬 (보유한 기술 역량)
기재할 기술
- 주력으로 사용하는 전문가 수준의 기술
- 이해도가 깊어 누군가에게 자신 있게 설명이 가능한 수준의 기술
- 이에 관련된 업무, 응용문제들을 문제없이 해결이 가능한 수준의 기술
기재를 고민해봐야 하는 기술
- 단순히
1~2번 사용해 본 기술
- 꼭 적어야 한다면 다른 주력 스킬에 강조 표시를 해두는 것이 좋습니다.
- 다룬 지 너무 오래되어 기억이 잘 안 나는 기술
- 해당 내용을 상기, 복습 후에 적는 것이 좋습니다.
- 자격 요건에 해당하지 않거나 별 메리트가 없는 기술
- 큰 의미 없이 장황하게만 보이는 경우가 대부분입니다.
유의사항
- 사용한 API는 기재를 지양하고 포괄적인 스킬을 작성할 것을 권합니다.
- 다른 누군가가 구현한 것을 그저 사용한 것에 불과합니다.
- 따라서 Bootpay API 등은 작성하지 않는 것을 권합니다.
- 가능하면 다음과 같이 카테고리를 분류해 작성하는 것을 권합니다.
- 예를 들어 FrontEnd/BackEnd/DevOps/Cloud/Collaboration 같은 분류를 추천합니다.
- 기술 스택은 단순히 많이 작성하는 것이 능사가 아닙니다.
- 단순히 경험 기술을 많이 나열한다고 해서 그 누구도 잘한다고 생각하지 않습니다.
- 이 경우 면접 시 모든 스킬에 대해 깊이 있는 답변을 하지 못한다면 오히려 감점입니다.
- 따라서 깊이 있는 답변이 가능한 기술만을 남겨두는 것이 바람직합니다.
- 해당 기술의 역량적 수준을 표시하지 않습니다.
- 자체적으로 평가한 수준을 아무도 믿지 않습니다.
- 다만 기업에서 자체 역량 수준을 요구하는 경우에만 기재합니다.
- 특정 대기업에서도 지원 이력서에 자체 역량 수준을 요구하는 경우가 있었습니다.
- 기술의 메이저 버전은 상황에 따라 기재 여부를 결정합니다.
- 만약 기재한다면 해당 버전의 특징을 모두 숙지하도록 합니다.
- 작성한 내용은 경력 사항이나 그 외 활동에서 증명되어야 합니다.
경력 사항 (경력 기술서)
이력서에서 제일 중요한 부분이며 재직 이력과 프로젝트 이력 모두 최신순으로 작성합니다.
재직 이력
- 소속 기업
- 기업명을 간략하게 작성합니다.
- 근무 기간
- 일반적으로
입사~퇴사순으로 일자를 연월 형식으로 작성합니다.- 근무 개월 수는 상황에 따라 기재 여부를 결정합니다.
- 주요 업무
- 자신의 역량이 드러난 프로젝트와 업무를 강조하여 간결하게 작성합니다.
- 사용 기술
- 재직 중 사용했던 기술들을 기재합니다.
- 채용 기업에 따라 필수 기재 요소가 아닐 수 있습니다.
유의사항
- 되도록 모든 재직 이력을
1~2페이지 분량으로 간략하게 작성합니다.- 경력이 적으시다면 1페이지 내로 작성하길 권합니다.
- 꼭 모든 이력을 다 기재할 필요는 없습니다.
- 예를 들어 수습 기간내에 퇴사하여 특별한 수행 업무가 없다면 생략 가능합니다.
- 재직 이력의 내용 또한 상황에 따라 기재 내용을 추가, 생략할 수 있습니다.
- 예를 들어 퇴직(이직) 사유 등은 상황과 본인 판단에 따라 기재 여부를 결정합니다.
- 기업의 경력 인정 조건에 따라 기재 가능한 경력이 달라 꼼꼼하게 확인해야 합니다.
- 예를 들어 다음과 같은 조건들이 있을 수 있습니다.
- 프리랜서 경력은 기재 불가 또는 인정하지 않는 경우
- 경력 증명이 불가능한 경우
- 수습 기간에만 재직한 경우
- 예를 들어 다음과 같은 조건들이 있을 수 있습니다.
수행한 프로젝트 이력
프로젝트명, 프로젝트 기간, 소속 기업명
- 프로젝트명은 쉽게 이해 가능한 이름을 사용합니다.
개발 환경
- 업무 수행 시 사용한 OS, 플랫폼, 언어, 프레임워크(라이브러리) 등을 작성합니다.
프로젝트 설명
- 어떤 프로젝트인지 정확한 용어를 사용하여 간단하게 설명합니다.
담당 업무
- 어떤 기술을 사용하여 어떤 방식으로 처리했고 어떤 성과를 이뤄냈는지 작성합니다.
- 추상적인 표현을 지양하고 정확한 용어를 사용하여 구체적으로 표현합니다.
- 이때 작성한 모든 내용에 대해서 깊은 이해도가 필요합니다.
- 사용 기술명은 상황에 따라 생략하기도 합니다.
- 예 : 사용 기술이 강조할 특징이 없는 경우
- 성과는 정확한 수치로 표현하는 것이 좋습니다.
- 프로젝트의 성과보다는 기술적인 성과를 작성합니다.
- 비약적인 성과가 아니거나 큰 메리트가 없는 경우 생략하기도 합니다.
결과 or 성과
- 강조할 성과가 있다면 담당 업무에 함께 작성하지 않고 별도로 빼내 작성할 수 있습니다.
- 최대한 정확한 수치를 통해 나타내는 것이 좋습니다.
문제 해결 사례 or 배운 점
- 자격 요건과 관련된 역량을 강조하기 위해 작성하는 부분입니다.
- 반드시 작성하지 않아도 되나 강조할 것이 있다면 간결하게 작성하도록 합니다.
- 기술적인 측면에서 문제 상황과 해결 방법, 배운 점을 작성합니다.
- 상황에 따라 협업 능력, 위기 대처 능력 등 소프트스킬을 강조하는 경우도 있습니다.
- 내용을 대체할 링크를 삽입할 수도 있습니다.
- 다만 링크를 보지 않는 경우도 많으니 간략하게라도 작성해두면 좋습니다.
기타
- 추가로 다음 링크(성과물)들을 첨부할 수 있습니다.
- 구현한 기능, 플랫폼, 서비스 페이지
- 사용 기술에 대한 특징 및 사용법, 이슈 등을 작성한 페이지
유의사항
- 프로젝트 경험을 의미하며 이력서에서 가장 중요한 부분이니 내용적으로 검토합니다.
- 해당 부분은 기술 면접까지 고려하여 작성해야 합니다.
- 따라서 정말 필요한 경력인지, 어필했을 때 메리트가 있는 기술인지 고민이 필요합니다.
- 자격 요건에 알맞는 기술을 사용한 프로젝트를 최상위에 작성하여 강조하도록 합니다.
- 프로젝트의 개수는 중요하지 않습니다.
- 자격 요건에 부합하는지와 내용의 퀄리티가 중요합니다.
- 팀원이 수행한 업무를 스스로 한듯이 포장하지 않아야 합니다.
- 간접 경험과 직접 경험은 반드시 티가 나게 되어 있습니다.
그 외 활동
경력 외 역량과 학습 태도, 개발에 대한 열정 등을 드러내는 것이 목적
- 다음과 같은 상황에서 작성합니다.
- 해당 부분 자격 요건을 경력만으로 증명하기에 부족한 경우
- 경력 이외 어필이 되는 활동인 경우
- 해당 부분은 경력 사항보다 강조되지 않아야 합니다.
- 단지 지원자의 관심사, 코딩 스타일, 실력 판단 등의 도움이 되는 참고 자료일 뿐입니다.
- 자격 요건을 증명할 경력이 많다면 작성하지 않아도 무방합니다.
- 만약 작성한다면 깃허브, 기술 블로그 또는 면접에서 증명할 수 있어야 합니다.
오픈소스 프로젝트 or 사이드 프로젝트
- 경력 사항과 분리하여 작성하는 것이 좋고 양식은 비슷하게 작성하여도 무방합니다.
- 오픈소스 프로젝트의 기여한 경험이나 업무 외적으로 개발한 사이드 프로젝트를 작성합니다.
- 자격 요건과 관련이 있으면 더욱 좋습니다.
기술 저서 출판 or 세미나 발표 or 강연/강의
- 출판한 저서, 세미나 또는 강연 경험에 대해 작성합니다.
- 콘텐츠 내용, 배운 점 등을 간략히 서술하거나 증명할 링크를 삽입합니다.
수강한 강의 (교육)
- 그동안 학습한 내용 중 자격 요건과 관련된 내용만을 작성합니다.
- 어떤 점을 배웠는지, 어떤 프로젝트에 어떻게 적용했는지 등을 설명합니다.
학력 / 자격증
- 최종 학력
- 대부분에 기업은 기업 내 연봉 테이블 등을 이유로 최종 학력을 요구하는 경우가 많습니다.
- 학점은 요구되는 경우에만 작성해도 무방합니다.
- 자격증
- 개발 직무와 자격 요건에 관련된 자격증만을 작성합니다.
- 자격증 발급 일자, 자격증명, 발급 기관 등을 명시합니다.
- 정보처리기사나 AWS 자격증과 같이 자격 요건, 업무에 관련이 있다면 명시하는 것이 좋습니다.
- 다만 일반 개발 관련 자격증은 크게 의미가 없는 경우가 많아 보편적으로 생략해도 무방합니다.
검토
모두 작성하였다면 전체적으로 다음을 확인합니다.
- 전반적으로 일관된 문맥을 갖고 있어 매끄럽게 읽히는가?
- 없어도 되는 내용, 표현, 어휘는 없는가?
- 전체 분량이 적당한가?
- 경력 사항이 다른 사항보다 분량이 더 많고 내용이 강조되었는가?
- 자격 요건에 따라 내용의 순서가 재배치될 필요가 없는가?
- 올바른 맞춤법을 사용하였는가?
- 띄어쓰기, 오타 등 오탈자는 없는가?
- 첨부한 링크는 접속이 잘 되는가?
- 주변 사람들의 첨삭/피드백을 받았는가?
댓글남기기