1400개의 경력직 백엔드 이력서를 읽으며 좋게 읽혔던 이력서의 5가지 공통점 (2편)

들어가기 전에 — 1편의 반대편 이야기

지난 글에서 1400개의 경력직 백엔드 이력서를 검토하면서 반복적으로 아쉬웠던 점들을 정리했다. 

1400개의 경력직 백엔드 이력서를 읽으며 반복해서 보였던 아쉬운 점들 (1편)

그 글의 마지막을 이렇게 마무리했었다. "다음 글에서는 반대로 잘 읽혔던 이력서들은 어떤 특징이 있었는지, 그리고 내 이력서가 지향하는 방향은 무엇인지를 정리해보려고 한다." 이번 글이 그 내용이다.

전제는 1편과 같다. 채용에는 정답이 없고, 나는 1차 서류를 검토하는 검토자 중 한 명일 뿐이다. 최종 결정은 여러 사람의 의견과 팀 상황, 채용 인원이 함께 얽혀서 난다. 그래서 이 글도 "이렇게 쓰면 합격한다"가 아니라 "내가 검토하면서 이런 이력서는 확실히 좋게 읽혔다" 정도로 읽어주면 좋겠다.

한 가지 배경을 먼저 밝혀두고 싶은 게 있다. 이 글에 나오는 관찰이 어떤 조건에서 나온 것인지와 직접 연결되기 때문이다.

내가 재직 중인 회사는 서류 검토 단계에서 성별, 출신 학교, 나이를 보지 않는다. 이런 항목들은 판단 근거에서 아예 빠져 있고, 오직 경력기술서만으로 검토가 이루어진다. 그러니까 이 글에 정리한 특징들은 좋은 배경을 가진 사람들의 공통점이 아니라, 자신이 해온 일을 잘 서술한 문서들의 공통점에 가깝다.

이게 왜 중요하냐면, 아래에 나오는 항목 중 어느 것도 타고나야 하는 게 아니기 때문이다. 전부 어떻게 쓰느냐의 영역이고, 이미 해온 일을 다시 정리하는 것만으로 대부분 만들 수 있는 것들이다. 1편에서 아쉬웠던 점들이 실력이 아니라 전달의 문제였던 것처럼, 이번 글의 좋았던 점들도 대부분 전달의 문제다.

1. 문제 정의, 수행 내용, 성과가 함께 적혀 있을 때

이 항목 하나가 나머지를 다 합친 것만큼 중요하다고 생각한다.

먼저 요즘 들어 부쩍 자주 하게 되는 생각부터 적어두고 싶다. 이제 "OO 기능을 구현하였음"이라는 문장은 이력서에서 예전만큼의 무게를 갖기 어려워진 것 같다.

구현은 기본값에 가까워졌다. 조금 세게 말하면, 프로로서 구현을 해내지 못한다는 건 이제 곤란한 일이 됐다고 생각한다. 그리고 AI가 코드를 만들어주는 시대에 "만들 수 있다"는 사실만으로 변별력을 갖기는 점점 어려워지고 있다. 만들었다는 것 자체는 이제 출발선에 가깝다.

그렇다면 무엇이 남는가. 내 경험으로는 서사가 남았다.

어떤 문제가 있었고, 그 문제를 어떻게 바라봤고, 무엇을 시도했고, 어떤 걸 버렸고, 결국 무엇이 달라졌는지. 이 흐름이 담긴 이력서는 일단 읽는 것 자체가 재미있었다. 하루에 수십 개를 연달아 읽다 보면 문장이 눈에서 미끄러지는 구간이 오는데, 서사가 있는 이력서는 그 구간에서도 눈이 멈춘다.

• 배치 성능 개선 작업 수행

이 문장에서 알 수 있는 건 사실상 없다. 반면 이렇게 쓰여 있으면 이야기가 완전히 달라진다.

• 문제 정의: 야간 정산 배치가 데이터 증가에 따라 4시간을 넘기기 시작했고, 업무 시작 시각까지 결과가 나오지 않는 날이 생기기 시작함
• 원인 분석: 처음에는 쿼리 문제로 보고 인덱스를 조정했으나 개선 폭이 크지 않았고, 프로파일링 결과 실제 병목은 건별로 외부 API를 호출하는 구간이었음
• 수행 내용: 외부 호출을 벌크 요청으로 묶고, 실패 건만 개별 재시도하는 구조로 변경. 재처리 가능하도록 중간 상태를 별도 테이블에 기록
• 성과: 실행 시간 4시간에서 1시간 40분으로 단축. 이후 데이터가 늘어도 선형으로 증가하지 않게 되어, 다음 해까지 추가 작업 없이 유지됨

여기서 눈여겨보게 되는 건 사실 개선 수치가 아니다. "처음에는 쿼리 문제로 봤는데 아니었다"는 한 줄이다. 이 문장 하나로 이 사람이 가설을 세우고 검증하고 틀렸을 때 방향을 바꾸는 사람이라는 게 드러난다. 그리고 그건 어떤 성과 수치보다 강력한 정보다.

성과가 꼭 숫자일 필요도 없다. 오히려 숫자로 표현하기 어려운 성과를 정직하게 쓴 이력서가 좋게 읽힌 경우가 많았다. 이후 관련 문의가 팀 채널에서 사라졌다거나, 신규 입사자가 문서만 보고 같은 작업을 할 수 있게 됐다거나, 새벽에 울리던 알람이 멈췄다거나 하는 것들이다.

그리고 하나 더. 결과가 실패였던 경험도 충분히 좋은 서사가 됐다. 도입을 검토했다가 결국 접었던 기술, 끝내 원인을 찾지 못한 장애, 롤백했던 배포. 왜 접었는지와 그때 무엇을 배웠는지가 함께 적혀 있으면, 성공 사례만 늘어놓은 이력서보다 오히려 신뢰가 갔다. 실무는 원래 성공만으로 채워지지 않기 때문이다.

여기에 실용적인 이유를 하나 더 붙이고 싶다. 서사가 있는 이력서는 면접에서도 유리하게 작동하는 것 같다.

면접 질문은 대체로 이력서에서 나온다. 이력서에 적힌 문장을 짚어가며 물어보는 게 가장 자연스럽기 때문이다. 그런데 이력서에 "OO 시스템 개발"만 적혀 있으면 질문할 지점이 없으니, 면접관은 결국 일반적인 질문으로 넘어간다. 준비하기 어려운 질문이 나올 확률이 그만큼 올라간다는 뜻이다.

반대로 문제와 판단이 적혀 있으면 질문이 그 위에서 시작된다. "그때 인덱스를 먼저 의심한 이유가 있나요", "벌크로 묶을 때 실패 처리는 어떻게 하셨어요" 같은 식이다. 전부 본인이 실제로 겪어서 가장 잘 아는 영역이다. 결국 이력서를 어떻게 쓰느냐가 면접이 벌어질 땅을 미리 정하는 셈이다.

물론 모든 경력 항목을 이렇게 쓸 필요는 없다고 생각한다. 오히려 전부 이 형식으로 채우면 읽기가 버거워진다. 가장 자신 있는 경험 두세 개만 이렇게 풀고 나머지는 간결하게 두는 편이 전체적으로 더 잘 읽혔다.

정리하면 이렇다. 무엇을 만들었는지보다 무엇을 어떻게 판단했는지가 남는 이력서가 잘 읽혔다.

2. 기술 도입의 '왜'가 설명되어 있을 때

1번과 뿌리가 같은 이야기인데, 조금 다른 것이 보이는 항목이라 따로 적어둔다.

특정 기술을 도입한 경험을 쓰면서 그 기술을 왜 골랐는지가 함께 적혀 있는 이력서가 있다. 이런 문장들은 검토자 입장에서 유독 오래 붙잡고 읽게 됐다.

이유는 이렇다. 회사에서 기술을 새로 도입하는 일은 혼자 결정할 수 있는 일이 아니다. 아무리 좋은 기술이라도 팀의 동의가 필요하고, 운영 부담을 나눠 질 사람들의 납득이 필요하고, 때로는 결정권자를 설득해야 한다. 그래서 기술 도입 경험에는 기술 이야기만 들어 있는 게 아니라 그 사람이 조직 안에서 어떻게 일하는지가 같이 들어 있다.

그런데 이력서에 "Redis를 도입하여 조회 성능을 개선함"이라고만 적히면, 그 과정이 통째로 사라진다. 남는 건 결과뿐이고, 어떤 논의를 거쳤는지는 알 수 없다.

반면 '왜'가 적혀 있으면 이런 것들이 함께 읽힌다.

• 어떤 대안들을 검토했고 왜 그것들을 버렸는지
• 무엇을 얻고 무엇을 포기하기로 했는지, 그 트레이드오프를 인지하고 있었는지
• 팀 안에서 반대 의견이 있었는지, 있었다면 어떻게 좁혀갔는지
• 도입 이후에 운영 부담이 늘어난 부분은 어떻게 처리했는지

도입해보니 예상과 달랐던 부분, 지금 다시 한다면 다르게 했을 지점 같은 것들이다. 기술을 도입해본 사람은 많지만, 그 결정을 나중에 다시 평가해본 사람은 생각보다 적다. 이런 이야기를 쓰려면 대단한 기술 도입이어야 한다고 생각하는 경우다. 그렇지 않았다. 메시지 브로커를 새로 얹은 이야기만 '왜'가 되는 게 아니다. 오래된 라이브러리 하나를 교체한 일, 로깅 방식을 바꾼 일, 배포 스크립트를 정리한 일에도 판단은 들어간다. 규모보다는 판단이 있었는가가 중요했다.

반대로 도입 결정에 본인이 관여하지 않은 경우도 있을 것이다. 이미 그렇게 구성된 환경에 합류했다면 '왜'를 쓸 수가 없다. 그럴 때는 그팀에서 왜 이 기술을 도입했는지를 이해하고 기술 도입에 문제가 있다면 그 문제는 무엇이고 이 기술이 도입될 수 밖에 없는 이유라면 그 이유 또한 알고있는게 중요한것 같다.

3. 회사가 지금 필요로 하는 경험과 맞아떨어질 때

이 항목은  솔직히 편향적인 항목이고, 보편적인 기준으로 보기는 어렵다고 생각한다.

내용은 단순하다. 지원한 회사가 쓰고 있는 기술 스택을 이미 다뤄본 지원자, 그리고 그 회사가 지금 당장 필요로 하는 경험을 가진 지원자는 서류 통과율이 확실히 높았다.

특히 후자가 크게 작용했다. 예를 들어 회사가 보안 관련 인증이나 자격 취득을 앞두고 있는 시기라면, 그 과정을 실제로 겪어본 사람의 이력서는 다르게 읽힌다. 그 경험이 있다는 것만으로 앞으로 몇 달의 리스크가 줄어들기 때문이다. 같은 이력서라도 반년 전에 들어왔다면 그렇게까지 눈에 띄지 않았을 수 있다.

그래서 이 항목은 실력보다 타이밍의 영역에 가깝다. 운이 상당히 따르는 부분이라는 뜻이다.

이 이야기를 굳이 넣는 이유는 두 가지다. 첫째, 이런 요소가 실제로 작동한다는 걸 숨기고 싶지 않았다. 좋았던 점만 골라 쓰면 이 글이 실제보다 공정한 그림이 된다. 둘째, 그렇기 때문에 서류에서 떨어진 것이 실력 부족을 뜻하지 않는다는 1편의 이야기가 여기서도 그대로 이어진다. 회사가 그 시점에 필요로 했던 것과 어긋났을 뿐인 경우가 정말 많다.

다만 지원자 입장에서 아예 손쓸 수 없는 영역인 것도 아니다. 채용 공고는 생각보다 많은 걸 말해준다. 요구사항에 유독 구체적으로 적힌 항목이 있다면 그건 지금 그 회사가 겪고 있는 문제일 가능성이 높다. 자격 요건에 두루뭉술하게 적힌 항목들 사이에 갑자기 구체적인 문장 하나가 끼어 있다면, 그건 누군가가 실제로 겪고 있는 일을 그대로 옮겨 적은 것일 수 있다. 내 경험 중에 거기에 닿는 것이 있다면, 이력서 아래쪽에 묻어두지 말고 앞으로 끌어올리는 것만으로도 다르게 읽힐 수 있다.

한 가지 덧붙이면, 스택이 겹친다는 사실 자체가 통과를 만들어주지는 않았다. 같은 기술을 썼다고만 적혀 있고 그 안에서 무엇을 했는지가 없으면 결국 1편에서 이야기한 문제로 되돌아간다. 스택 일치는 눈길을 끄는 요소였지 판단 근거는 아니었다는 뜻이다. 그리고 해보지 않은 경험을 공고에 맞춰 억지로 끼워 넣는 건 권하고 싶지 않다. 그 부분은 면접에서 거의 반드시 질문이 들어오고, 그때 답이 흔들리면 다른 진짜 경험까지 함께 의심받게 된다.

4. 만들어본 경험뿐 아니라 운영해본 경험이 있을 때

이력서를 읽다 보면 프로젝트 참여, 프로젝트 참여, 신규 시스템 개발, 또 다른 신규 시스템 개발로 이어지는 경우를 자주 본다. 만들고, 다음 것을 만들고, 또 만든다.

그 사이에 하나를 오래 붙잡고 운영해본 경험이 있으면 확실히 눈길이 갔다. 그리고 그 부분은 자세히 읽게 됐다.

이유는 만드는 일과 굴리는 일에서 드러나는 게 서로 다르기 때문이다. 만드는 과정에서는 설계 능력과 구현 속도가 보인다. 반면 운영에서는 다른 것들이 보인다.

• 장애가 났을 때 어떻게 파악하고 어떻게 복구했는지
• 무엇을 모니터링하기로 정했고, 왜 하필 그 지표였는지
• 쌓인 기술 부채 중 무엇을 먼저 갚기로 했고 무엇은 두기로 했는지
• 운영하면서 발견한 설계상의 실수를 어떻게 인정하고 고쳐나갔는지
• 그 시스템을 다른 사람에게 넘길 수 있게 만들어두었는지

이건 시간을 들여야만 얻어지는 종류의 경험이다. 그래서 대체하기가 어렵다.

그리고 개인적으로는 여기서 애착 같은 것도 읽힌다고 생각한다. 자기가 만든 걸 오래 돌봐본 사람은 시스템을 대하는 태도가 문장에서 조금씩 드러난다. 어디가 약한지 알고 있고, 그걸 알면서 왜 아직 안 고쳤는지도 설명할 수 있다. 그런 문장은 만들어낼 수가 없다.

운영 경험에서 특히 눈여겨보게 되는 건, 그 사람이 다음 사람을 위해 남겨둔 것들이다. 장애를 겪고 나서 알람 조건을 조정해뒀다거나, 대응 절차를 문서로 정리해뒀다거나, 같은 실수가 반복되지 않도록 검증 로직을 추가해뒀다거나 하는 것들. 이런 문장이 있으면 이 사람이 팀에 들어와서 무엇을 남길지가 자연스럽게 그려진다.

그래서 이렇게 쓰면 좋을 것 같다. 운영 경험이 있다면 기간과 규모를 함께 적고, 그중 기억에 남는 장애 사례 하나를 골라 원인과 대응, 그 이후 무엇을 바꿨는지까지 적으면 된다. 화려한 장애일 필요는 전혀 없다. 오히려 사소한 장애를 어떻게 다뤘는지가 그 사람의 일하는 방식을 더 잘 보여주는 경우도 많았다.

5. 실제로 동작하는 포트폴리오와 그 설명이 함께 있을 때

1편에서 저장소에 코드만 올라와 있는 포트폴리오가 아쉬웠다고 썼는데, 이 항목은 정확히 그 반대편이다.

실제로 동작하는 서비스가 있고, 그것이 어떤 기술과 어떤 인프라 위에서 돌아가는지, 설계는 어떤 방식으로 했는지가 함께 정리되어 있는 포트폴리오. 이런 경우 서류 통과율이 눈에 띄게 올라가는 경향이 있었다.

이유는 단순하다. 검토자가 확인할 수 있는 것의 양이 압도적으로 다르기 때문이다. 링크 하나를 눌러 화면이 뜨는 순간, 이 사람이 무엇을 만들 수 있는지에 대한 의문은 대체로 끝난다. 거기에 구조 설명까지 붙어 있으면 어떻게 생각하는 사람인지까지 함께 확인된다. 서류 한 장으로 할 수 있는 일 중에 이보다 효율이 좋은 건 별로 없다고 생각한다.

이걸 가장 잘 보여주는 사례가 하나 있다. 우리 회사는 신입을 채용하지 않는다. 그래서 신입 지원자의 이력서는 원칙적으로 검토 대상이 아니다. 그런데 잘 만들어진 포트폴리오를 가진 신입 이력서를 두고 "이런 지원자라면 한 번쯤 기회를 줘야 하는 것 아닌가"라는 의견이 나온 적이 있었다. 채용 계획 자체가 없는 포지션에서 그런 이야기가 나왔다는 건, 그 포트폴리오가 그만큼 강하게 작용했다는 뜻이라고 생각한다.

경력직에게는 사실 이런 포트폴리오가 필수는 아니다. 실무 경력 자체가 더 강한 증거이기 때문이다. 다만 있으면 확실히 유리하게 작동했다. 특히 경력에서 다루지 못한 영역을 개인 프로젝트로 채운 경우가 그랬다. 업무에서는 모놀리식만 다뤘지만 개인 프로젝트로 컨테이너 기반 배포를 구성해봤다거나 하는 식이다. 이력서에서 비어 보이던 칸이 그렇게 채워지면, 부족한 부분을 스스로 인지하고 메우는 사람이라는 인상까지 함께 남는다.

규모가 클 필요도 없었다. 오히려 크게 벌여놓고 절반쯤에서 멈춘 프로젝트보다, 작지만 끝까지 간 프로젝트가 훨씬 좋게 읽혔다. 기능이 세 개뿐이어도 인증이 붙어 있고, 배포되어 있고, 에러가 났을 때 로그를 볼 수 있게 되어 있으면 그것만으로 한 사이클을 완주한 증거가 된다. 완성도는 크기가 아니라 완결성에서 나온다고 생각한다.

주의할 점도 하나 있다. 포트폴리오가 오히려 마이너스로 작용하는 경우가 있는데, 대부분 방치된 상태로 링크만 남아 있을 때다. 접속이 안 되거나, 데모 계정으로 로그인이 안 되거나, 화면이 깨져 있는 경우다. 이건 1편의 마지막 항목과 그대로 이어지는 이야기다. 지원 전에 로그아웃 상태의 브라우저로 한 번만 들어가 보면 대부분 걸러진다.

그래서 이렇게 쓰면 좋을 것 같다. 화려할 필요는 없다. 실제로 접속되는 주소 하나, 어떤 구성으로 돌아가는지 보여주는 다이어그램 한 장, 왜 그 구조를 선택했는지 서너 줄. 이 정도만 있어도 저장소 링크만 있는 것과는 완전히 다르게 읽힌다.

그 외에도 보게 되는 것들

위의 다섯 가지 말고도 좋게 읽혔던 요소들이 물론 더 있다. 예를 들면 이런 것들이다.

• 혼자 한 프로젝트 외에 협업 경험이 충분히 드러나는지
• 솔루션을 만들어 납품해본 경력이 있는지
• 팀을 이끌어본 경험이 있는지

다만 이런 항목들은 회사마다 판단 기준이 정말 천차만별이다. 리더 경험을 크게 보는 곳이 있는가 하면, 실무 밀도를 더 중요하게 보는 곳도 있다. 솔루션 경력도 마찬가지다. 어떤 조직에서는 강점이고 어떤 조직에서는 결이 다르다고 판단한다.

그래서 이 항목들은 "보편적으로 이렇다"라고 쓰기가 어려웠다. 위의 다섯 가지만큼 확신을 갖고 이야기할 수 없어서, 있다는 것만 언급하고 넘어가려고 한다.

정리하면

두 편에 걸쳐 쓰고 나니 결국 하고 싶었던 이야기는 하나로 모이는 것 같다.

앞에서도 적었지만, 이제 "무엇을 해봤다", "어떤 기술을 써봤다"는 형태는 이력서 양식으로서 한물간 게 아닌가 싶다. 나열할 수 있는 경험의 목록은 이제 변별력이 크지 않다. 만들 수 있다는 것도 마찬가지다.

대신 이런 것들이 남는다고 생각한다. 문제를 어떻게 바라보는지, 팀원들과 어떤 방식으로 소통하고 합의에 이르는지, 어떤 성실함으로 시스템을 오래 돌봐왔는지, 그리고 무엇을 개선하려는 의지를 갖고 있는지.

공교롭게도 이 네 가지는 AI에게 넘기기 가장 어려운 영역이기도 하다. 코드는 대신 써줄 수 있어도, 어떤 문제를 먼저 풀지 정하는 일이나 팀을 설득하는 일, 새벽에 울린 알람을 받고 나가는 일은 결국 사람이 한다. 이력서가 보여줘야 할 것도 그쪽으로 옮겨가고 있는 게 아닐까 싶다.

두 편을 관통하는 문장을 하나만 남긴다면, 1편에 썼던 것을 그대로 다시 적고 싶다. 이력서는 내가 무엇을 했는지를 적는 문서가 아니라, 읽는 사람이 나를 이해하도록 만드는 문서라고 생각한다. 1편이 그 이해를 막는 것들에 대한 이야기였다면, 이 글은 그 이해를 돕는 것들에 대한 이야기였다.

이게 요즘 채용 시장의 정답이라는 이야기는 아니다. 그렇게 말할 만한 위치에 있지도 않다. 다만 내가 다음에 내 이력서를 쓴다면 이걸 무기로 삼으려고 한다는 뜻이고, 두 편의 글은 사실 그 준비 과정을 정리해둔 것에 가깝다.

그래서 이 글이 정답으로 읽히지 않으면 좋겠다. 회사마다 기준이 다르고, 내가 놓친 좋은 지원자도 분명히 있었을 것이다. 이 글을 읽는 분들께는 5퍼센트 정도의 참고만 되어도 충분하다고 생각한다.

이력서를 쓰고 있는 모든 분들이 건승하시면 좋겠다.