서류에서 계속 떨어지던 신입 백엔드, 이력서에서 바꾼 4가지

이 글은 부트캠프를 수료한 신입 백엔드 지원자 여러 명의 경험을 한 사람의 이야기로 재구성한 사례예요. 특정 인물이 아니라 자주 보이는 상황을 모은 것이라, 편의상 '지원자 A'라고 부를게요.

A는 6개월 과정을 마치고 Spring Boot로 만든 쇼핑몰 API 프로젝트와 팀 프로젝트 하나를 들고 지원을 시작했어요. 몇 달 동안 꾸준히 냈지만 서류 단계에서 연락이 거의 오지 않았어요. 스펙을 더 쌓아야 하나 고민하던 A가 실제로 바꾼 건 기술 스택이 아니라 이력서의 문장이었어요.

A의 첫 이력서 프로젝트 항목은 'Spring Boot와 JPA로 쇼핑몰 REST API 개발', 'JWT 기반 회원 인증 구현', 'AWS EC2 배포' 세 줄이었어요. 틀린 말은 하나도 없지만, 같은 과정을 들은 동기들의 이력서와 거의 같은 문장이었어요.

팀 프로젝트 항목은 더 흐릿했어요. '5인 팀으로 예약 서비스 개발'이라고만 적혀 있어서 A가 그 안에서 무엇을 맡았는지 알 수 없었어요. 읽는 사람은 팀이 한 일과 A가 한 일을 구분하지 못하면, 대개 A의 몫을 작게 짐작해요.

A는 프로젝트를 다시 열어 보면서 가장 오래 붙잡고 있었던 문제를 찾았어요. 동시에 주문이 들어오면 재고가 음수가 되던 버그였어요. 당시엔 고치고 넘어갔지만, 고치는 과정에 선택지 비교와 판단이 있었어요.

그런 문제가 기억나지 않는다면 기록을 거꾸로 훑어보세요. 커밋 메시지에 'fix'가 여러 번 연달아 붙은 구간, 팀 채팅에서 같은 이야기가 며칠 이어진 날, 코드 리뷰에서 의견이 갈렸던 부분이 후보예요. 시간이 오래 걸린 곳에는 거의 항상 판단이 숨어 있어요.

신입 프로젝트에 실사용자 수치가 없는 건 당연해요. 그래서 A는 측정해서 숫자를 만들었어요. 측정해 본 경험 자체가 성능 문제를 다뤄 본 증거가 되기 때문이에요. 중요한 건 숫자의 크기가 아니라 같은 조건에서 전과 후를 비교했다는 사실이에요.

이력서 맨 위 요약도 바꿨어요. 성격을 설명하는 문장은 누구나 쓸 수 있어서 판단 근거가 되지 못해요. A는 요약을 무엇을 만들고 검증할 수 있는 사람인지 보여 주는 세 줄로 다시 썼어요.

A는 이력서 한 장을 모든 곳에 내던 방식도 멈췄어요. 공고(JD)의 자격 요건과 우대 사항을 옮겨 적고, 자기 이력서에 이미 있는 것과 없는 것을 나눠 봤어요.

이미 있는 키워드는 공고에 나온 순서대로 프로젝트 설명 앞쪽으로 옮겼어요. 빠진 키워드는 억지로 끼워 넣지 않았어요. Redis는 실제로 조회 캐시를 붙여 본 뒤에야 넣었고, 해 보지 않은 메시지 큐는 비워 뒀어요. 면접에서 설명할 수 있는 것만 쓴다는 원칙이었어요.

문장을 바꾸자 서류 연락이 오기 시작했고 면접 질문도 달라졌어요. 예전엔 개념을 확인하는 질문이 대부분이었다면, 이제는 이력서에 쓴 판단을 파고드는 질문이 나왔어요. 직접 겪은 일이라 오히려 답하기 편했다고 해요.