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

들어가기 전에 — 이 글은 합격과 불합격의 기준이 아니다

채용에는 정답이 없다. 회사마다 기준이 다르고, 같은 회사 안에서도 면접관마다 보는 포인트가 다르다. 그래서 이 글은 "이렇게 쓰면 탈락한다"는 기준을 이야기하려는 글이 아니다. 내가 약 1400개의 경력직 백엔드 개발자 이력서를 검토하면서 반복적으로 자주 보였던 사례들을 정리한 회고에 가깝다.

먼저 내 위치를 정확히 밝혀두고 싶다. 나는 1차 서류를 검토하는 검토자 중 한 명이다. 내가 혼자 합격을 결정하는 자리가 아니다. 1차 검토 결과는 여러 사람의 의견과 함께 취합되고, 거기에 팀의 현재 상황, 채용 인원, 필요한 포지션의 성격이 더해져 최종 결정이 난다. 그래서 이 글에 나오는 이야기들은 "이런 이력서는 떨어진다"가 아니라 "내가 1차 검토를 하면서 이런 점이 아쉬웠다" 정도로 읽어주면 좋겠다.

회사는 직원 100명이 넘는, 그렇게 크지도 작지도 않은 회사다. 상호명을 말할 수는 없지만, 원티드에 채용 공고가 올라오면 나름 맛있어 보이는 공고를 올리는 회사 정도까지는 말할 수 있을 것 같다. 그러니 여기 정리한 내용은 어디까지나 내가 다니는 회사, 내가 검토한 범위에 국한된 지역적인 기준일 수 있다.

그리고 한 가지 더. 나 역시 완벽한 이력서를 썼던 사람이 아니다. 오히려 아래에 정리한 항목들은 예전의 내 이력서에도 그대로 들어 있던 것들이다. 이 글은 남의 이력서를 평가하려고 쓰는 글이 아니라, 내가 다음에 이력서를 쓸 때 이 함정들을 피하려고 정리해두는 글이다.

이 글의 초점은 "왜 탈락했는가"가 아니라 "이력서를 읽는 사람 입장에서 왜 이해하기 어려웠는가"에 있다. 1400개를 읽으면서 가장 많이 느낀 건 기술력의 문제가 아니었다. 잘한 일이 분명히 있는데도 그게 읽는 사람에게 전달되지 않아서 아쉬운 경우가 훨씬 많았다.

이번 글에서는 서류 통과율이 낮았던, 그리고 읽기 어려웠던 이력서에서 반복적으로 보였던 특징들을 정리한다. 다음 글에서는 반대로 잘 읽혔던 이력서들의 특징과, 내 이력서가 지향하는 방향을 정리해보려고 한다.

1. GitHub 링크는 있는데, 그 안에서 확인할 것이 없을 때

경력 3~5년 이상인 지원자의 이력서에 GitHub 링크가 걸려 있다. 그런데 눌러보면 저장소가 비어 있거나, 몇 년 전 커밋만 남아 있거나, 최근 활동이 알고리즘 문제 풀이 커밋뿐인 경우가 꽤 있었다.

기술 블로그 링크도 비슷한 패턴이 있었다. 링크를 눌러보면 가장 최근 글이 JPA의 기본 동작 원리나 N+1 문제의 개념 설명 같은 원론적인 주제인 경우다.

여기서 오해를 피하고 싶은 게 있다. GitHub가 비어 있다는 것 자체가 감점 사유였던 건 아니다. 회사 업무 코드를 개인 저장소에 올릴 수 없는 건 너무나 당연하고, 퇴근 후에 사이드 프로젝트를 하지 않는 것도 전혀 문제가 아니다. 실제로 GitHub 링크가 아예 없는 이력서가 링크가 비어 있는 이력서보다 불리했던 기억은 없다.

검토자 입장에서 아쉬웠던 지점은 조금 다른 데 있다. 링크를 건다는 건 "여기 오시면 저에 대해 더 알 수 있습니다"라는 안내다. 지원자가 스스로 추가로 보여주고 싶어서 넣은 항목인데, 정작 눌러보면 확인할 수 있는 게 없다. 기대를 만들어놓고 회수되지 않는 상태가 되는 것이다. 그래서 아무것도 걸지 않은 것보다 오히려 아쉽게 읽히는 경우가 있었다.

알고리즘 문제 풀이 커밋도 마찬가지다. 취업을 준비하는 신입이나 주니어에게는 충분히 좋은 신호다. 꾸준함이 보이고, 코딩 테스트 대비도 되어 있다는 뜻이니까. 다만 3년 이상의 경력직 포트폴리오로 놓고 보면, 그 커밋들에서 이 사람이 실무에서 어떤 문제를 어떻게 푸는 사람인지를 읽어내기는 어려웠다. 적어도 내가 경력직 이력서에서 확인하고 싶었던 건 "문제를 풀 수 있는가"보다 "복잡한 상황에서 어떤 판단을 하는가" 쪽에 가까웠던 것 같다.

블로그의 원론적인 글도 내용이 틀렸다는 이야기가 아니다. N+1 문제를 정리한 글은 그 자체로 좋은 글이다. 다만 그 주제는 이미 인터넷에 수천 개가 있어서, 3~5년차의 차별점이 되기는 어려웠던 것 같다. 같은 주제라도 이렇게 쓰여 있으면 완전히 다르게 읽혔다. 어떤 화면의 어떤 목록 조회에서 응답이 느려졌고, 그걸 어떻게 발견했고(APM인지 슬로우 쿼리 로그인지), 어떤 방식으로 고쳤고(fetch join인지 배치 사이즈인지 쿼리 분리인지), 왜 그 방식을 골랐고, 고친 뒤 무엇이 어떻게 달라졌는지. 개념 설명이 아니라 자신의 판단이 들어간 글이 되면, 그건 남이 대체하기 어려운 콘텐츠가 된다고 생각한다.

그래서 이렇게 바꾸면 좋았을 것 같다. 링크는 자신 있는 것만 걸어도 충분하다고 생각한다. 보여줄 것이 마땅치 않다면 걸지 않는 쪽이 나을 수도 있다. 그리고 굳이 화려한 사이드 프로젝트가 필요한 것도 아니다. 저장소 하나에 README만 잘 정리되어 있어도 프로젝트를 이해하는 데 큰 도움이 됐다. 블로그라면 회사 정보를 익명화해서 정리한 경험 기반 글 한두 개가, 개념을 요약한 글 서른 개보다 훨씬 강하게 읽혔다.

2. 기술 설명이 사실과 다를 때

이력서 안의 기술적인 부연 설명이 사실과 다른 경우가 있었다. 실제로 자주 봤던 예를 들면 이런 문장들이다.

• HTTP 통신을 TCP 통신으로 변경하여 성능을 개선했다
• OAuth 2.0은 JWT 토큰을 사용하는 인증 프로토콜이다

첫 번째 문장은 HTTP 자체가 TCP 위에서 동작한다는 점에서 표현이 성립하지 않는다. 두 번째 문장도 정확하지 않다. OAuth 2.0은 인가(authorization)를 다루는 프레임워크이고, 액세스 토큰의 형식을 규정하지 않는다. JWT를 쓸 수도 있고 불투명한(opaque) 문자열을 쓸 수도 있다. 사용자 인증 정보를 다루는 건 그 위에 올라가는 OIDC 쪽 이야기에 더 가깝다.

이런 문장이 있으면 검토자 입장에서는 추가적인 의문이 생기는 경우가 많았다. 지식이 부족하다고 판단하기 때문이 아니다. 서류 검토 단계에서 내가 확인할 수 있는 재료는 지원자가 쓴 문장뿐이라는 점이 핵심이다. 그 문장 중 하나에서 사실 오류가 보이면, 옆에 있는 다른 문장들의 신뢰도까지 함께 흔들린다. "응답 시간을 40% 개선했다"는 문장을 읽을 때 그 숫자가 어떤 기준으로 측정된 것인지, 그 해석이 정확한지 한 번 더 의심하게 되는 것이다. 기술적인 신뢰도가 떨어질 수 있는 지점이 여기다.

그런데 이 항목에서 내가 가장 아깝다고 느낀 건 조금 다른 부분이다. 이런 문장들은 대체로 실제로는 잘한 일을 잘못 표현해서 손해를 보는 경우였다. 앞의 HTTP와 TCP 예시도 실제 내용은 의미 있는 개선일 가능성이 높다. 요청마다 새로 커넥션을 맺던 구조를 상시 연결로 바꿨거나, REST 폴링을 소켓 기반 푸시로 바꿨거나, 내부 서비스 간 통신을 gRPC로 옮겼거나 하는 작업이었을 것이다. 그중 어느 쪽이든 원래 문장보다 훨씬 인상적이다. 실제로 한 일이 원래 문장보다 좋은데, 표현 하나 때문에 반대로 읽히는 셈이다.

그래서 이렇게 바꾸면 좋았을 것 같다. 무엇을 무엇으로 바꿨는지를 사실 그대로 쓰는 것이 가장 안전한 것 같다. 개념 용어로 요약해서 멋있게 만들려고 할 때 오류가 생기는 경우가 많았다. 그리고 기술을 깊게 아는 것보다, 모르는 부분을 과장하지 않는 편이 더 좋은 인상을 주기도 했다. "정확한 원인은 끝까지 규명하지 못했지만 이런 우회 방법으로 해결했다"는 문장이 있는 이력서가 오히려 신뢰를 얻은 경우도 있었다.

제출 전에 한 번 해보면 좋은 점검이 하나 있다. 이력서에 쓴 기술 문장을 소리 내어 설명해보는 것이다. 면접에서 "이 부분 조금 더 설명해주시겠어요?"라는 질문이 나왔을 때 편하게 이어서 말할 수 있는 문장만 남기면, 이 항목은 대체로 걸러진다.

3. 포트폴리오가 코드만 있고, 동작을 확인할 방법이 없을 때

포트폴리오 항목에 Git 저장소 링크만 있는 경우다. 코드는 잘 올라와 있지만, 이 프로젝트가 무엇을 하는 서비스인지, 실제로 어떻게 동작하는지 확인할 수 있는 경로가 없다.

이건 감점이 아니라 현실적인 이야기다. 저장소만 있는 포트폴리오를 제대로 보려면 클론을 받고, 의존성을 설치하고, DB와 환경변수를 맞추고, IDE에서 인덱싱이 끝나기를 기다린 다음에야 코드를 읽을 수 있다. 그런데 서류 검토는 대부분 업무 시간을 쪼개서 한다. 이력서 검토용으로 원티드에 MCP를 붙여서 자동으로 분석하는 게 아니라, 사람이 하나하나 직접 손으로 읽는 작업이다. 하루에 수십 개를 봐야 하는 상황에서 프로젝트 하나를 로컬에 세팅해서 열어보는 건 현실적으로 어렵다.

그래서 저장소만 있는 포트폴리오는 서류에서 감점 요소가 되지는 않지만, 솔직히 큰 도움이 되지도 않았다. 지원자가 몇 달을 들여서 만든 자산인데 검토 과정에서 거의 회수되지 않는 것이다. 개인적으로는 이게 이 글에서 가장 아까운 항목이라고 생각한다.

그래서 이렇게 바꾸면 좋았을 것 같다. 꼭 실제 서비스로 배포해야 한다는 뜻은 아니다. 클라우드 비용을 계속 낼 필요도 없다. README 하나만 잘 작성되어 있어도 프로젝트를 이해하는 데 큰 도움이 된다. 구체적으로는 이 정도만 있어도 충분히 달랐다.

• 이 프로젝트가 무엇을 하는 서비스인지 두세 줄
• 실제 화면 스크린샷 몇 장, 또는 30초짜리 GIF
• 구성 요소를 그린 간단한 아키텍처 다이어그램 한 장
• 왜 이 구조를 선택했는지, 어떤 대안을 검토했는지
• 만들면서 막혔던 문제 하나와 그걸 어떻게 해결했는지
• 코드 중에서 가장 보여주고 싶은 파일로 가는 직접 링크

이 중 마지막 항목은 특히 효과가 좋았다. "이 프로젝트에서 가장 고민한 부분은 여기입니다"라고 파일을 하나 지목해주면, 검토자가 프로젝트 전체를 파악하지 않고도 그 사람의 코드를 읽을 수 있다. 무료 티어로 데모를 띄워두거나 1~2분짜리 시연 영상을 남기는 것도 좋은 방법이라고 생각한다.

4. 공백 기간 동안의 활동을 확인할 수 없을 때

6개월에서 1년 이상의 공백 기간이 있는데, 그 기간에 무엇을 했는지 이력서에서 확인할 수 없는 경우다.

솔직하게 적으면, 6개월 정도라면 실무 감각이 둔해지기에 충분한 시간이라고 생각한다. 개발 환경도 바뀌고 도구도 바뀐다. 이건 검토자로서도 신경이 쓰이는 부분이다.

다만 문제가 되는 건 공백 자체가 아니었다. 확인이 안 되는 상태가 문제였다. 공백에는 각자의 사정이 있다. 건강 문제, 가족 돌봄, 학업, 이직 준비, 번아웃 회복까지. 그리고 그 사정을 이력서에 다 밝힐 필요는 없다고 생각한다.

검토자가 알고 싶은 건 그 사정이 아니다. 공백을 캐묻고 싶은 것도 아니다. 확인하고 싶은 건 딱 하나, "지금 바로 실무에 들어올 수 있는 상태인가"다. 그런데 공백 기간에 대한 정보가 아무것도 없으면 이 질문에 답할 재료가 없어서, 판단을 보수적으로 하게 되는 경우가 많았다.

반대로 그 기간에 무엇을 했는지 한두 줄만 있어도 이 부분은 대체로 커버됐다. 실제로 공백이 1년 가까이 있었는데도 그 기간 활동이 정리되어 있어서 별다른 우려 없이 넘어간 이력서들이 있었다. 거창한 활동이 아니어도 충분했다.

• 수강한 강의나 읽은 책
• 진행한 사이드 프로젝트
• 참여한 스터디나 커뮤니티 활동
• 취득한 자격증
• 오픈소스 기여나 번역

그래서 이렇게 바꾸면 좋았을 것 같다. 외부 활동란이나 기타 항목에 기간과 함께 한 줄만 남기면 된다. 예를 들면 "2025.03 ~ 2025.09, 개인 사유로 휴식. 해당 기간 중 쿠버네티스 관련 강의 수강 및 개인 프로젝트 배포 환경 구성 학습" 정도다. 사유를 자세히 쓸 필요는 없고, 공백이 비어 있는 시간이 아니었다는 것만 보이면 충분했다.

5. 무엇을 했는지만 나열되어 있을 때

이건 이 글에서 가장 많이 본 유형이다. 정말 압도적으로 많다. 체감상 이력서 10개 중 6~7개는 이런 형태로 들어온다. 항목들이 이렇게 쓰여 있는 경우다.

• A 시스템 개발
• B 프로젝트 참여
• C 서비스 마이그레이션 완수
• 사내 관리자 페이지 신규 개발

전부 사실이고, 전부 실제로 한 일이다. 그런데 검토자 입장에서 이 문장들만으로는 알 수 없는 것이 너무 많다. 이 사람이 그 프로젝트에서 어떤 역할이었는지, 혼자 했는지 다섯 명 중 한 명이었는지, 설계를 했는지 정해진 스펙을 구현했는지, 그 과정에서 어떤 판단을 했는지, 무엇이 어려웠고 어떻게 풀었는지, 결과가 어땠는지. 어느 하나도 읽어내기 어렵다. 사실은 적혀 있는데 사람이 잘 보이지 않는 상태에 가깝다.

서류 검토는 결국 "이 사람이 우리 팀에 들어와서 어떻게 일할까"를 상상하는 작업에 가깝다고 생각한다. 그런데 위와 같은 문장들로는 상상할 재료가 부족하다. 그래서 다음 단계로 넘기자고 말할 근거를 만들기가 어려웠다.

여기서 하나 짚어두고 싶은 게 있다. 이건 실력 문제가 아니라고 생각한다. 오히려 일을 많이, 잘 해온 사람들이 이렇게 쓰는 경우가 많았다. 본인에게는 매일 하던 당연한 일이라서 특별할 게 없다고 생각하고 한 줄로 압축해버리는 것이다. 실제로 면접에서 이야기를 들어보면 훨씬 흥미로운 내용이 나오는데, 그게 서류에는 담기지 않았던 경우도 있었다.

그래서 이렇게 바꾸면 좋았을 것 같다. 항목 하나를 상황, 문제, 내 판단과 행동, 결과의 순서로 풀어보는 것이다. 같은 경험이 이렇게 달라진다.

바꾸기 전이라면 이런 문장이다.

• 결제 시스템 마이그레이션 완수

바꾼 뒤라면 이렇게 쓸 수 있다.

• 기존 결제 모듈이 단일 PG사에 강하게 결합되어 있어 신규 PG사 추가에 2주 이상이 걸리던 문제가 있었음
• 결제 요청 인터페이스를 추상화하고 PG사별 구현을 어댑터로 분리하는 구조를 제안, 팀 리뷰 후 채택
• 운영 중 서비스였기 때문에 신규 구조와 기존 구조를 병행 운영하며 트래픽을 단계적으로 이전하는 방식으로 진행
• 결과적으로 신규 PG사 연동 소요 기간이 2주에서 2일 수준으로 줄었고, 이후 다른 팀원이 추가 연동을 단독으로 진행

숫자가 없으면 정성적인 결과라도 괜찮다. "이후 이 영역의 문의가 팀 채널에서 거의 사라졌다"거나 "다른 팀원이 내 문서만 보고 같은 작업을 할 수 있게 됐다"는 것도 충분히 좋은 결과다. 중요한 건 성과의 크기보다, 읽는 사람이 이 사람의 일하는 방식을 그려볼 수 있는가 쪽인 것 같다.

이것과 정반대로 쓰인 이력서들은 양식부터 눈에 들어왔고, 실제로 서류 통과율도 높았다. 그 특징들은 다음 글에서 자세히 다뤄보려고 한다.

6. 경력에 비해 이력서 내용이 너무 짧을 때

5년차, 6년차 이상의 개발자인데 이력서 전체가 3장 이하로 끝나는 경우다. 실제로는 2장 이하인 경우가 더 많았다.

이 항목은 사실 5번과 뿌리가 같다. 분량 자체가 기준인 건 아니다. 짧다는 건 결과일 뿐이고, 실제 문제는 이 사람이 어떤 업무 스타일을 가졌고 어떻게 문제를 해결하는지 파악할 재료가 부족하다는 것이다. 5년의 경력이 세 줄로 정리되어 있으면, 그 5년 동안 무엇이 쌓였는지를 읽어내기가 어려웠다.

그러니 길게 쓰라는 이야기로 읽히지 않으면 좋겠다. 억지로 늘린 이력서는 오히려 읽기 어려웠다. 모든 프로젝트를 빠짐없이 나열해서 열 장이 된 이력서보다, 대표 경험 두세 개를 깊게 쓴 네 장짜리 이력서가 훨씬 잘 읽혔다.

이력서가 짧아지는 이유는 대체로 세 가지였던 것 같다. 첫째, 회사에서 한 일은 보안 때문에 못 쓴다고 생각하는 경우. 둘째, 프로젝트 이름만 적어도 어떤 일인지 알 거라고 생각하는 경우. 셋째, 자세히 쓰면 자랑처럼 보일까 걱정하는 경우다.

첫 번째는 익명화와 추상화로 상당 부분 풀린다고 생각한다. 회사명이나 서비스명, 내부 시스템 이름을 쓰지 않아도 규모와 성격으로 설명할 수 있다. "OO페이 정산 배치" 대신 "일 평균 수십만 건이 처리되는 정산 배치"라고 쓰면 된다. 오히려 이렇게 쓰는 편이 외부 독자에게 더 잘 전달되기도 했다. 두 번째는 검토자가 그 프로젝트를 모른다는 전제로 다시 읽어보면 대체로 드러난다. 세 번째는 사실과 결과를 쓰는 것이 자랑이 아니라는 점만 짚어두고 싶다. 이력서 나를 파는 사업 제안서 이다.

7. 기술 스택에 상, 중, 하가 있을때

기술 스택 항목에 다룰 수 있는 도구를 나열하면서 각 항목 옆에 숙련도를 등급으로 표시한 이력서가 있다. 이런 식이다.

• Java (상), Spring Boot (상)
• MySQL (중), Redis (중)
• Kubernetes (하), Kafka (하)

정리해서 보여주려는 의도는 충분히 이해된다. 그런데 검토자 입장에서는 이 표기가 판단에 도움이 되기보다 오히려 판단을 어렵게 만드는 경우가 많았다.

가장 큰 이유는 그 등급의 기준이 지원자마다 다르다는 데 있는 것 같다. 겸손한 사람이 쓴 중과 자신감 있는 사람이 쓴 중은 실제 수준이 상당히 다른 경우가 많았다. 같은 글자인데 담긴 내용이 사람마다 다르니, 등급 자체만으로는 판단할 수 있는 게 거의 없었다. 정보를 주려고 넣은 항목인데 정보가 되지 못하는 셈이다.

그리고 조금 더 근본적인 문제가 있다. 우리는 돈을 받고 일하는 프로다. 이력서의 기술 스택 항목에 어떤 기술이 적혀 있다는 건, 기본적으로 그 기술로 실무를 할 수 있다는 뜻으로 읽힌다. 그런데 거기에 중이라고 적혀 있으면 읽다가 한 번 멈칫하게 되는 경우가 있었다. 이건 실무에 투입할 수 있는 수준이라는 뜻인가, 아니면 아직 부족하다는 뜻인가. 하라고 적혀 있으면 더 난감하다. 실무에 쓸 수 없다는 이야기인지, 써봤지만 자신은 없다는 이야기인지, 그렇다면 이걸 왜 이력서에 적었는지까지 의문이 이어진다.

결과적으로 이 표기는 지원자에게 유리하게 작동하지 않는 경우가 많았다. 하로 적힌 기술은 대체로 없는 것처럼 읽히고, 상으로 적은 기술은 면접에서 그 수준을 전제로 질문이 들어오는 경향이 있었다. 스스로 감점 요소를 만들거나, 스스로 면접 난이도를 올리거나 둘 중 하나가 되기 쉬워 보였다.

그래서 이렇게 바꾸면 좋았을 것 같다. 등급을 붙이는 대신 그냥 다룰 수 있는 기술을 명시하고, 그 대신 면접 준비를 더 탄탄하게 해오는 편이 훨씬 좋은 인상으로 남을 것 같다는 생각이 든다. 등급표를 고민하는 시간에 자신 없는 기술 하나를 더 복습하는 쪽이 실제로 남는 것도 많지 않을까 싶다.

굳이 구분을 두고 싶다면 등급보다 사실을 쓰는 방법이 있다. 사용 기간, 다룬 규모, 맡았던 역할 같은 것들이다. Kafka (중)이라고 쓰는 것보다 "Kafka — 2년, 일 평균 수십만 건 처리되는 파이프라인 운영 및 장애 대응"이라고 쓰는 편이 검토자가 훨씬 정확하게 판단할 수 있다. 등급은 주관이지만 이건 사실이라서 오해가 생길 여지가 적다.

8. 마지막으로, 꼼꼼함에서 새는 것들

내용과 별개로 아쉬웠던 것들이다. 개별적으로는 사소한데, 모이면 인상이 만들어진다.

• 오탈자를 검수하지 않은 흔적
• 지원하는 회사명이 다른 회사 이름으로 적혀 있는 경우
• 포트폴리오 링크가 열리지 않는 경우
• 노션 페이지가 비공개로 되어 있어 접근 권한이 없는 경우
• 첨부 파일이 손상되어 열리지 않거나, PDF 변환 과정에서 표와 레이아웃이 깨진 경우
• 경력 기간이 서로 겹치거나 앞뒤가 맞지 않는 경우

이 중 압도적으로 흔한 것은 링크가 열리지 않는 문제였다. 그리고 이건 대부분 본인이 알아채기 어려운 종류의 실수다. 본인 브라우저에는 계정이 로그인되어 있으니 잘 열린다. 남의 눈으로 볼 기회가 없어서 놓치는 것이다.

이런 항목들이 아쉬웠던 이유는 단순히 실수가 있었다는 것 때문은 아니다. 이력서는 지원자가 가장 공을 들여 만드는 문서다. 그 문서에서도 최종 확인이 빠져 있으면, 검토자는 자연스럽게 업무에서의 꼼꼼함까지 떠올리게 된다. 특히 백엔드는 꼼꼼함 자체가 직무 역량에 가깝다고 생각한다. 놓친 예외 처리 하나가 장애로 이어지는 일을 다들 겪어봤기 때문에, 이 연상은 생각보다 강하게 작동하는 것 같다.

그래서 이렇게 바꾸면 좋았을 것 같다. 제출 직전에 이 정도만 확인하면 대부분 걸러진다.

• 시크릿 모드나 로그아웃 상태의 브라우저로 이력서에 걸린 링크 전부 열어보기
• PDF로 변환한 최종 파일을 다른 기기에서 한 번 열어보기
• 지원 회사별로 다르게 쓴 문구가 남아 있지 않은지 확인하기
• 가능하면 다른 사람에게 한 번 읽어달라고 부탁하기

특히 마지막 항목의 효과가 컸다. 내가 쓴 글의 오탈자와 논리 구멍은 내 눈에 잘 안 보인다. 이력서 검토도 결국 남이 읽는 일이니, 제출 전에 한 번 남에게 읽히는 게 가장 정확한 리허설이 아닐까 싶다.

정리하면

여기 정리한 사례들은 몇몇 특이한 이력서의 이야기가 아니다. 1400개를 읽는 동안 아주 빈번하게 반복해서 보였던 패턴들이다.

1400개를 읽고 가장 많이 든 생각은 이것이다. 기술력이 부족해서 아쉬운 경우보다, 잘했던 일을 제대로 전달하지 못해서 아쉬운 경우가 훨씬 많았다. 좋은 개발자는 정말 많았다. 다만 좋은 개발자가 좋은 이력서를 쓰는 것은 또 다른 능력이었다.

그래서 나는 이렇게 생각하게 됐다. 이력서는 내가 무엇을 했는지를 적는 문서가 아니라, 읽는 사람이 나를 이해하도록 만드는 문서다. 이 기준으로 다시 읽어보면, 위에 정리한 여덟 가지가 사실 같은 이야기의 다른 얼굴이라는 게 보인다. 링크를 걸었는데 확인할 것이 없거나, 문장에 오류가 있거나, 코드만 있고 설명이 없거나, 공백이 비어 있거나, 무엇을 했다만 있거나, 너무 짧거나, 등급만 있고 근거가 없거나, 링크가 열리지 않거나. 전부 읽는 사람이 나를 이해할 수 없게 되는 경로다.

다시 강조하지만, 이건 절대적인 기준이 아니다. 회사마다 채용 기준이 다르고, 위 항목들은 내가 다니는 회사와 내가 검토한 범위에 국한된 지역적인 감점 사유일 수 있다. 다른 회사에서는 전혀 다르게 볼 수도 있다.

그리고 다행인 점이 하나 있다. 위에서 이야기한 대부분은 개발 실력을 키워야만 해결되는 문제가 아니다. 이미 해온 일을 읽는 사람 입장에서 다시 정리하는 것만으로도 충분히 개선할 수 있는 부분들이 많았다. 몇 년의 실무 경험이 필요한 일이라기보다, 주말 하루를 들여 다시 정리하는 것만으로도 꽤 달라질 수 있는 일이라는 뜻이다.

이 글의 취지도 결국 거기에 있다. 나 역시 위 케이스들을 피해서 다음 이력서를 쓰고 싶어서 정리해둔 글이다. 다음 글에서는 반대로 잘 읽혔던 이력서들은 어떤 특징이 있었는지, 그리고 내 이력서가 지향하는 방향은 무엇인지를 정리해보려고 한다.