(채용) 개발자 이력서

Posted Apr 12, 2025

By crispin

17 min read

우연치 않게 최근 회사 내부에서 채용 관련하여 이력서 검토 업무를 진행하게 되어 여러 이력서를 보면서
개인적으로 조금은 아쉬웠던 부분에 대해 적어보려 한다.

여러 사정이 있어 내가 잘 알고 있는 백엔드가 아닌 데브옵스 분들의 이력서를 검토하게 되었지만
(해당 사정에 대해서는 추후 포스팅 할 예정)

이력서를 보면서 공통적으로 느꼈던 아쉬웠던 부분에 대해 집중적으로 적어보려고 한다.

👓선 3줄 요약

이력서는 읽는 사람의 입장에서 포맷과 내용 모두 깔끔하게 정리하는 것이 중요하다.
링크는 최신 상태로 잘 관리되고 있는 것만 첨부하고, 검증 가능한 내용 중심으로 작성하자.
경험과 기술이 직무와 얼마나 관련 있고 성의 있게 표현됐는지가 합격 여부를 좌우할 수 있다.

‼️ 이것만은 지켰으면 하는 부분

이력서 포맷팅, 파일 형식

가끔 이력서를 받아보면 이력서를 보기 어려울 정도로 포맷이 전부 틀어져서 보기 어려운 경우가 생각보다 종종 있다.
이력서를 제출하기 전 꼭 이력서 포맷이 틀어져 있지는 않은지 확인해볼 필요가 있을것 같다.

개인적으로 가장 보기 편했던 파일 형식은 .pdf 형식이었다. 다양한 형식의 파일을 받아 봤는데 아무래도
.pdf 의 경우 웹 브라우저로 별도의 뷰어 설치 없이도 확인 가능하기 때문에 보기에 매우 편했다.

이력서를 제출하는 입장에서도 크게 불편함은 없는 파일 형식이라고 생각된다.

어떤 파일 형식을 사용하던 제출한 이력서를 볼 수 있는 방법은 있지만, 제출하는 입장에서 어떻게 이 이력서를 보게 될지
조금은 생각하고 배려해서 제출한다면 조금이나마 결과에 플러스 요인이 되지 않을까 생각한다.

관리되지 않은 링크

요즘 엔지니어 이력서에는 이력서 내에 GitHub, blog 등 여러 링크가 함께 첨부되는 경우가 매우 많은데 관리가
전혀 되지 않은 GitHub 이나 blog 의 링크는 오히려 마이너스 요소가 될 확률이 매우매우 높다.
GitHub 의 경우는 이 지원자가 평소에 작성하는 코드 스타일이나 학습하는 기술에 대해 보고싶은 경우에
보게 되는데 관리되지 않은 GitHub 이 대부분 이였다. 마지막 Contributes 가 몇년 전인 경우에는
이걸 왜 추가 했는지 의문이 들때가 많았다.

blog 의 경우도 관리가 되지 않는다면 그냥 빼는것이 좋다. 채용 담당자는 해당 blog 를 통해 지원자의 학습 방법이나
최근에 관심있는 기술 등을 보고 싶은 건데 이런 부분이 없다면 오히려 마이너스 요소가 될 확률이 높다.

개인적으로 생각하는 최악의 링크는 Notion 링크다. Notion 링크의 경우 고려해야할 부분이 몇가지 있다.

페이지에 접근 가능한 권한이 어떻게 되어 있는지
이 페이지에서 내가 보여주고자 하는 부분이 뭐가 있는지
회사 내부적으로 Notion 을 사용할 수 있는 회사 인지

3번의 경우는 자체적으로 확인할 수 있는 방법이 매우 적기 때문에 어쩔수 없지만,
최소한 1번 2번은 꼭 확인하고 제출했으면 하는 바람이 있다.

Notion 링크가 있어 접속 했는데 권한이 없다던가, 정리한 내용들이 파편화 되어 있어 뭘 봐야할지 모를때 매우 당황스럽다.

이왕이면 학습한 내용이 전부 있는 페이지 링크를 제출하는게 아니라, 경험 및 경력사항에 작성한 내용을 바탕으로
좀 더 보여주고 싶은 부분이 있을때 그 부분에 대한 링크만 함께 첨부하는것이 좋을것 같다.

제일 좋은것은 내가 보여주고 싶은 내용을 모아 별도의 포트폴리오를 만들어 제출하는것이다.

자격 요건

최소한 이력서를 제출하기 전에 자격 요건은 확인하자.
자격요건에 아래와 같이 적혀 있는데

Kubernetes 기반 인프라 운영 경험이 있으신 분
IaC에 대한 이해 및 사용 경험이 있으신 분

이력 및 경험에 k8s 를 사용해 본적이 없는데 지원을 했다면 과연 합격을 할 수 있을까?
무분별한 이력서 제출은 지원자 에게는 탈락이라는 아픔을, 채용 담당자에게는 업무 시간 낭비 라는 결과를 초래할 수 있다.

정말 정말 다시 한번 강조하고 싶은 부분이다.

💦 아쉬웠던 부분

검증

DevOps 이력서를 보면서 제일 당황스러우면서 아쉬웠던 부분은 지금까지 해왔던 경험이나 이력에 대해 검증할 수 있는
내용을 함께 보여주지 않는다는 부분 이였다.

예를 들어

- AWS 기반의 VM 및 컨테이너 환경 인프라 설계, 구축 및 운영
- EKS 마이그레이션 진행
- 온프레미스 환경에 k8s 구축 및 운영
- CI&CD 구축
- ArgoCD App of Apps 패턴을 사용한 GitOps 환경 구축
- AWS WAF를 이용한 보안 강화
- IaC 활용한 유지보수 운영 관리

위와 같은 내용이 이력서에 적혀 있는데, 딱 내용만 봤을때는 여러 경험이 있는것으로 보이지만 중요한건 저 경험들을 검증할수 있는 내용이 이력서에 없는 부분이다.

어떻게 인프라를 구축 했는지 아키텍처를 설명하거나 간단하게 그림으로 그려 첨부하면 더욱 좋지 않을까 생각한다.

- AWS 기반의 VM 및 컨테이너 환경 인프라 설계, 구축 및 운영 
  - 어떻게 설계하였고 구축과정에서 어떤 어려움이 있었는지

- EKS 마이그레이션 진행 
  - `EKS` 마이그레이션을 왜 진행하였고 마이그레이션 했을때 얻은 결과물이 어떻게 되는지

- 온프레미스 환경에 k8s 구축 및 운영 
  - 온프레미스 환경에 `k8s`를 구축할때 어떤 어려움이 있었고 그걸 어떻게 해결했는지

- CI&CD 구축 
  - 어떤 프로세스와 아키텍처로 구축을 하였는지

- ArgoCD App of Apps 패턴을 사용한 GitOps 환경 구축 
  - `App of Apps` 패턴을 왜 사용하게 되었는지

- AWS WAF를 이용한 보안 강화 
  - 왜 `WAF` 를 도입하게 되었는지

- IaC 활용한 유지보수 운영 관리 
  - 이전에는 어떻게 유지보수 및 운영을 했으며, 도입 했을 때 어떤 장,단점이 있었는지

위와 같이 적을 수 있는게 많은것 같은데 많은 이력서에 이런 내용이 함께 첨부되어 있지 않은걸 보고 많이 당황스러웠다.

이 부분에 대해 평소 알고 지내던 DevOps 엔지니어 분들께 많은 질문을 했었다. 원래 DevOps 이력서에는 경험이나
이력을 추상적으로 적는것인지, 검증할 내용을 함께 작성하여 첨부하는게 많이 어려운지 등 이력서를 보면서
아쉬운 부분에 대해 여쭤봤는데 어려운건 아니다 라는 답변이 돌아왔다.

성의

회사에 지원을 했을 때 어느정도의 성의는 보여야 한다고 생각한다. 물론 회사마다 별개의 이력서를 작성하는게 쉽지 않은
일이라는건 필자도 잘 알고 있는 부분이다 하지만 가끔 정말 쌩뚱맞은 내용이 적혀 있는 이력서가 들어올때가 있다.

대표적으로 자기소개서에 우리가 사용하고 있지 않은 기술인데 그걸 바탕으로 회사 인프라를 구성하고, 발전시켜 보겠다 는
내용 또는 회사 도메인과 전혀 상관없는 내용에 대해 작성 하고 고민 했었다 등의 내용이 있었는데 이력서를 제출하기전
지원 회사에 대해 관련 없는 내용이 적혀있는 부분은 없는지 한번쯤은 검토하고 지원했으면 하는 바람이 있다.

마무리

지금은 DevOps 분들의 이력서를 보고 있지만, 이전에 Frontend 도 채용 했었기에 Frontend 이력서도 봤었는데 분야에
상관없이 엔지니어 이력서에서 공통적으로 발견되었던 아쉬웠던 부분에 대해 글을 작성해 봤다.

이 부분은 개인적인 주관이 많이 담긴 부분 이기에 독자에 따라 불편함을 느낄수도 있을것 같은데, 개인적으로 너무나도
아쉬웠던 부분이라 해당 글을 접하는 분들은 이런 부분을 조금이나마 신경써서 좋은결과가 있길 바라는 마음으로 작성해봤다.

얼마뒤면 Backend 공고도 열릴 참이라 많이 기대가 되면서 걱정 또한 함께 되고 있는데, 지금 채용 시장이 많이 어려운 만큼
이 글이 조금이나마 도움이 되었으면 좋겠다.

이력서, 채용

채용

This post is licensed under CC BY 4.0 by the author.