5년 만의 이력서 다시 쓰기

뱅크샐러드에서 퇴사하고 5년 만에 이력서를 다시 썼다. 평소에 주기적으로 써오지 않아 이번 기회에 아예 백지에서 시작했다. 그동안 면접관으로 여러 이력서를 봐왔는데 어떤 이력서가 좋았는지 떠올리며 무슨 내용을 넣고 무슨 내용을 뺐는지, 이력서에 적을 내용을 어떻게 관리했는지, 어떤 형식으로 썼는지 적어본다.

이력서의 일부. 다시 쓴 이력서는 한국어 pdf, 영어 pdf로 각 링크에서 볼 수 있다.

무엇이 좋은 이력서였는지

면접관으로 다른 사람의 이력서를 볼 땐 타깃 하는 직무 역량 레벨과 트랙(엔지니어링 커리어 패스를 레벨과 함께 ic 트랙과 매니저 트랙으로 운영했다)에 따라 기대한 바는 조금씩 다르긴 했으나 좋은 이력서엔 주로 아래 내용이 있었다.

• 이력서만 봐도 관심사가 무엇이고 어떤 종류의 일을 해왔는지 상상할 수 있었다.
• 특정 분야의 전문성을 기대할 수 있었다.
• 어떤 형태로든 조직에 긍정적인 영향을 줄 것 같았다.
• 금방 온보딩해서 일을 해낼 수 있어 보였다.
• 프로젝트에서 어떤 역할을 맡았고 어떤 성과를 냈는지 알 수 있었다.
• 가능한 한 성과를 정량적으로 표현하려 했었다.
• 한 번에 잘 읽히는 이력서였다.

나보다 더 많이 이력서 스크리닝을 해왔던 엔지니어링 매니저는 "좋은 이력서는 프로젝트의 난이도와 성과가 나열되어 있어 이 사람에게 어떤 일을 시켰을 때 얼마큼의 확률로 해낼 수 있겠다 추론이 되어 테스트케이스가 되는 이력서"라고 말해줬는데 이 기준도 참고해 볼 만했다.

평소 이력서에 적을 내용을 관리하기

주기적으로 이력서를 갱신해 오진 않았지만 언젠가 해야 하는 순간은 올 것이기에 평소에 내가 업무 내용을 정리해 둘 필요가 있었다. 마침 뱅크샐러드는 lemonbase를 이용해 반기마다 역량 평가를 진행하는 조직이어서 그동안 했던 업무를 주기적으로 압축해 임팩트 순으로 정리해 올 수 있었다.

평가 자료로 쓰기 위해선 단순히 xxx 기능 개발, yyy 업무 진행이 아니라 업무의 컨텍스트와 함께 그 성과를 최대한 정량적인 숫자로 적어야 했던 점도 나중의 수고를 덜어줬다. 그 당시 컨디션에 따라 어떤 업무를 왜 했는지, 그 결과는 어땠는지 구체적으로 적었을 때도 있었고 그냥 지라 티켓, pr 링크만 bullet point로 적었을 때도 있었지만 결과적으로 평가 자료를 모아 이력서의 raw 자료로 만들어 활용할 수 있었다.

어떻게 적었는가

메인 브랜치 이력서 쓰기

5년간 해온 업무가 소위 말해 파운데이션, 프레임워크 같은 이름의 공통적인 성격으로 어느 정도 일관성 있긴 했다. 그럼에도 불구하고 어떨 땐 사용자들이 사용하는 기능을 개발했거나, 이걸 꼭 적어야 하나 싶을 정도로 애매한 성격의 업무들은 있었기에 일단 모든 업무가 담겨있는 하나의 메인 이력서를 작성했다. 모든 업무를 구체적으로 나열하진 않고 연속성 있거나 성격이 비슷한 업무는 "개발 및 운영", "이슈 대응과 성능 개선"으로 어느 정도 추상화하며 그룹화해 메인 이력서를 작성했고, 이를 기반으로 지원하는 포지션에 따라, 내가 강조하고 싶은 면모에 따라 내용을 취사선택해 브랜치 이력서로 만들 수 있었다.

가능한 한 수치와 함께 적기

해온 모든 일이 수치로 표현되진 않지만 그럴 수 있는 항목들은 최대한 정량적으로 작성했다. 'xxx sdk 사용', 'xxx 기능 개발'로 적기보단 'p90 기준 xx ms 유지', '속도 n% 개선', '20개의 api 구현' 이런 식으로 성과와 배경을 최대한 정량적으로 적으려 했다.

'생산성 향상'처럼 그 결과가 정량적으로 나타내기 어려운 항목도 물론 있었고 이런 항목들은 그 복잡도를 나타내거나 시간 연속성이 드러나도록 작성했다. 만약 성과를 뾰족하게 드러내기 어려운 업무라면 'x개의 api를 가진', '분당 x개의 요청을 처리하는'등의 수치를 함께 기재하는 것도 이력서를 읽는 사람 입장에서 업무의 복잡도, 난이도를 파악하는 데 도움이 되겠다. 비용이나 리텐션 같은 절대적 수치는 대외비일 수 있기 때문에 가능하다면 상대적인 숫자로 표현하려 했다.

이 외 참고할 만한 공개 자료

아래 이력서와 글도 참고할 만했다.

• 공개 이력서: 이동욱 님 이력서, 정원희 님 이력서
• 개발자 이력서 작성하기 (feat. 이력서 공개) | Wonny Log

어떤 내용은 뺐는가

여러 이력서를 봤을 때 아래 내용들이 없는 이력서가 오히려 좋은 인상을 주었다.

개인정보

요구하는 정보는 회사마다 다르긴 하겠으나 사진, 성별, 생년월일, 주소, 결혼 여부, 가족 관계 같은 개인정보는 이력서 스크리닝이나 면접 진행에 도움이 되는 정보는 아니었고, 도움이 되지도 않아야 한다. 특히 혼인 여부 수집은 위법이라 회사에서 요구하지 않아야 한다. 개인적으론 이름과 이메일 정도만 있어도 충분했기에 이번 이력서에선 전화번호도 제외했다.

스킬 숙련도

어떤 이력서를 보면 java 중급, python 70% 이런 식으로 스킬의 숙련도를 적는 경우가 있는데 별로 권장하고 싶지 않다. "100% 수준은 어떤 수준인가요" 질문했을 때 답변하기도 요원하고 어차피 하드 스킬 역량은 면접 진행 과정에서 파악된다. 차라리 담백하게 kotlin, spring, grpc, kubernetes 이런 식으로 스킬 셋을 적어두는 게 좋겠다.

빼는 게 좋을지 잘 모르겠는 내용

• 한 줄 카피, 한 단락의 짧은 소개
  • 보통 이력서를 보면 짧은 소개 - 경험 혹은 프로젝트 - 스킬 - 학력 - 외부 활동 같은 순서로 구성돼 있었고, 여기서 짧은 소개엔 "xxx한 개발자입니다", "yyy를 중요시합니다" 같은 문구가 들어가곤 했다.
  • 개인적으론 이런 소개는 블로그 about 페이지 같은 곳에 적어두려 하고 경력만으로도 어떤 개발자고 무엇을 중요시했는지 드러내고 싶었기에 이번 이력서에 포함하진 않았다.
  • 이를 이력서를 읽는 사람에게 어떤 식으로 포지셔닝하고 싶은지 전략적으로 활용할 수 있겠다.
• 학력
  • 학력과 실력은 상관관계가 거의 없다고 알려져 있다. 그럼에도 회사에 따라 요구하는 경우도 있을 수 있고, 졸업을 위해 뱅크샐러드를 퇴사하고 결국 10년 만에 졸업한 기념으로 최종 학력 정도만 포함해 두긴 했다.

꼭 피드백 받기

이력서 초안을 작성한 후엔 동료들에게 피드백을 부탁했다. 면접관 입장에서 좋은 내용과 없어도 될 내용이 있는지, 내가 한 업무 중에 이거 있으면 좋겠는데 빠진 건 없는지 등 리뷰를 받았다. 이를 기반으로 영문 이력서를 작성하고 어색한 표현은 없는지, 문법은 적절한지 다른 동료와 chatgpt한테 피드백을 받고 반영했다. 피드백 전과 후를 비교해 보면 그 질이 확연히 차이 났기에 조금 부끄럽다고 느껴지더라도 피드백은 꼭 받아보면 좋겠다.

동료에게 피드백을 받기 어렵다면 주변의 멘토나 지인에게 피드백을 요청해도 좋겠다. 본인이 아는 현업의 지인들, 아티클을 읽다 보면 보이는 다른 개발자의 블로그, 트위터나 disquiet, 이오플래닛 같은 커뮤니티에서 자주 보이는 분들 같은 경우 나도 그렇고 보통 정중한 피드백 부탁에 열려있는 분들이다. 메일 같은 수단으로 피드백을 부탁한다면 어떻게든 답변을 주시니 부끄럽다거나 실례라는 생각 때문에 주저하지 않으면 좋겠다.

어떤 형식으로 적었는가

• latest 정보가 먼저 오고 oldest 정보는 나중에 오도록 역순으로 적었다.
  • 연대기보단 보유 역량과 그 경험 순으로 적는 게 더 사용자 친화적이라는 김창준 님의 의견도 있고 이에 공감한다. 이번엔 관성적으로 시간순으로 적었지만 다음 이력서 작성 시엔 이를 참고해 봐도 좋겠다.
• 메인 이력서에서 편집한 공개용 이력서는 a4 1페이지로 맞춰봤다. 사실 이력서라고 해서 꼭 1페이지일 필욘 없지만 스스로 도전과제라 생각하며 맞춰봤다.
• google docs로 작성한 후 pdf로 내보내 관리했다.
  • 개인적으로 노션을 안 써서 구글 독스로 작성했지만 에디터는 무엇이든 혹은 프로그래머스, 로켓펀치, 링크드인 같은 플랫폼에 맞추든 상관없겠다.
  • 다만 지원할 때 pdf 같은 문서 파일 형식으로 요구하는 경우가 있기에 노션으로 관리하더라도 그 출력 결과가 내 의도와 같은지 검토해 보는 게 좋겠다.

더 나아갈 부분

이렇게 5년 만에 이력서를 다시 쓰며 무슨 내용을 넣고 무슨 내용을 뺐는지, 이력서에 적을 내용을 어떻게 관리했는지, 어떤 형식으로 썼는지 적어봤다. 아래는 이력서를 쓰며 느낀 어려움인데 추후 이를 해결해 주는 서비스가 있으면 좋겠다.

• source of truth 관리가 어렵다. 한 번만 작성하고 이를 pdf로도, 공개용 웹 페이지로도, linkedin으로도 관리하고 싶었으나, 구글 독스로는 웹으로 공유했을 때 스타일링이 내 의도와 달라지고 공유 링크가 permanant 하지 않은 문제가 있어 어려웠다. 지금은 구글 독스로 작성하고 이를 개인 블로그 /resume 링크로도, export 한 pdf로도, linkedin에도 레플리케이션 하는데 이 과정의 일관성 유지가 어렵다.
• 메인 이력서를 각 회사 지원 버전으로 가공하는 게 어렵다. 이는 굳이 1페이지로 맞추는 바람에 더 어려워진 부분도 있으나 손쉽게 토글이나 클릭만으로 브랜치 이력서를 만들 수 있다면 좋겠다.
• 어떤 프로젝트는 혼자가 아닌 여럿이서 진행했는데 이 내용을 여러 사람과 같이 공유하고 리액션이나 댓글로 서로 레퍼런스가 되어주는 방법이 있으면 좋겠다. 랠릿 같은 플랫폼이 이와 비슷한 문제를 풀어주는 듯했다.

이렇게 어떤 이력서가 좋았고, 평소에 적을 내용을 어떻게 관리했는지, 어떤 식으로 내용을 적었는지 정리 해봤다. 5년 만에 다시 쓴 이력서는 한국어 pdf, 영어 pdf로 각 링크에서 볼 수 있다.