이력서에 수치만 나열 하셨나요?

이력서는 항상 준비를 해야만 하는 것이라고 생각한다. 나중에 몰아서 쓰려고 하면 어떤 것들을 했는지 기억하기 어려우며 자세한 사항을 키워드별로 정리해놓지 않으면 말하는 사람도, 이 것을 보는 사람도 뭘 했다는건지 전달하기 어렵다.

그래서 나는 이력서를 ‘결과물’이 아니라 ‘기록물’로 관리해야 한다고 생각한다.

취업 시즌이 다가와서 급하게 정리하는 문서가 아니라, 일을 하면서 바로바로 쌓아두는 로그에 가깝다.

특히 기술 직군에서는

• 무엇을 만들었는지
• 왜 그 문제를 풀었는지
• 어떤 제약 조건이 있었는지
• 그 선택이 어떤 결과를 만들었는지

이 네 가지가 빠지면, 아무리 화려한 기술을 나열해도 실체가 없는 이력이 된다.

그래서 나는 프로젝트를 끝낸 뒤가 아니라, 프로젝트를 진행하면서

• 핵심 의사결정 포인트
• 반복 작업을 자동화한 이유
• 실패하거나 다시 설계했던 지점
• 수치로 설명할 수 있는 변화

를 키워드 단위로 정리해두려고 한다. 이 과정이 쌓이면, 이력서를 쓰는 행위는 ‘작성’이 아니라 ‘편집’이 된다.

또 하나 중요한 점은, 이력서는 나 자신을 설득하는 문서이기도 하다는 것이다.

“내가 이 문제를 왜 이렇게 풀었지?”라는 질문에 스스로 답할 수 없다면, 면접에서 다른 사람을 설득하는 건 더 어렵다.

그래서 이 글에서는, 단순히 무엇을 했는지를 나열하기보다는 왜 이 일을 해야 했고, 어떤 맥락에서 판단했고, 그 결과 무엇이 달라졌는지를 중심으로 정리해보려고 한다.

이력서를 미리 준비한다는 건, 결국 내가 어떤 문제를 해결하는 사람인지 스스로 정의하는 작업이라고 생각한다.

그래서 수치화 해서 넣었는데?

많이들 하는 실수는 결과만 넣는 행위다. 예를들어 운영 효율을 30% 개선했다, 배포시간을 단축했다. 등 결과만 나열하는 것들이 가장 큰 실수라고 생각한다. 그래서 우리는 왜 개선을 했는지가 필요하다.

먼저 내 이력서의 예시를 들어보겠다.

멀티 클러스터 Kubernetes 환경에서 CI/CD 자동화 체계를 구축하여, Git 저장소 생성, Jenkins 잡 프로비저닝, SonarQube·Nexus·Harbor 연동을 스크립트로 표준화했고, 전체 초기 설정 시간을 기존 3시간 이상에서 1시간 이내로 단축했습니다.

3시간에서 1시간으로 줄였다는 건데 여기서도 문제는 왜 그렇게 해야 했으며, 어떠한 의사결정으로 해야했는지가 없다. 그래서 ? 아 그렇구나.. 라는 느낌에서 끝난다. 그리고 면접을 준비하는 입장으로서, 궁금하게 만들어야 하는것도 구직자의 일이라고 생각한다.

어떻게 개선해볼까?

프라이빗 클라우드 기반 신규 플랫폼 구축 프로젝트에서 향후 40여 개 서비스 온보딩을 전제로 한 KPI가 설정되어 있었으며, 초기 서비스별 CI/CD 환경을 수작업으로 구성할 경우 일정과 품질을 동시에 확보하기 어렵다고 판단했다. 이에 멀티 클러스터 Kubernetes 환경에서 CI/CD 초기 설정 과정을 자동화하여 Git 저장소 생성, Jenkins 잡 프로비저닝, SonarQube·Nexus·Harbor·Argo CD 연동을 스크립트로 표준화했고, 서비스별 초기 CI/CD 구축 시간을 기존 3시간 이상에서 1시간 이내로 단축했다.

내용을 조금 길어지더라도 사례기반으로, 어떠한 배경에 어떻게 했는지를 써 내려가는게 좋다. 그 전보다 훨씬 맥락성이 유지하여 보기가 좋아졌다. 이렇게 함으로써, 물어 볼 만한 질문 포인트들이 많아졌다.

• CI/CD 초기 설정을 “자동화해야 한다”고 판단한 기준은 무엇이었나요?
• 멀티 클러스터 Kubernetes 구조는 어떻게 설계했고, 클러스터 간 역할 분리는 어떻게 했나요?
• Jenkins와 SonarQube, Nexus, Harbor 연동 구조를 설명해 주세요.
• ArgoCD는 어떤 시점에서 개입하며, CI와 CD의 경계는 어떻게 나눴나요?
• 초기 CI/CD 구축 시간이 3시간에서 1시간 이내로 줄어든 핵심 요인은 무엇이었나요?
• 자동화 스크립트의 재사용성과 유지보수는 어떻게 고려했나요?

하지만 좀 더 아쉬운 것은..

한가지 더 고려해야 하는 점은, 이력서를 보는 면접관에게 주어진 시간이 많지 않다는 점이다. 결국 눈에 들어오고 보기 좋게 요리해서 전달해야 한다는게 핵심이다. 이 관점에서 더 개선해볼 여지가 있다.

구조는 다음과 같다.

문제 → 판단 → 해결

40여 개 서비스 온보딩을 전제로 한 프라이빗 클라우드 신규 플랫폼 구축 프로젝트에서, 서비스별 CI/CD 환경을 수작업으로 구성할 경우 일정 지연과 품질 편차가 반복될 것으로 판단했다. 이에 멀티 클러스터 Kubernetes 환경에서 CI/CD 초기 설정 전 과정을 자동화하고, Git,Jenkins,SonarQube,Nexus,Harbor,ArgoCD 연동을 표준화하여 서비스별 초기 구축 시간을 3시간 이상에서 1시간 이내로 단축했다.