백엔드 이력서 쓰는 법

by 그릿 | GROWTH_ESSAY | 2026-07-18

백엔드 이력서를 잘 쓰는 방법은 단순합니다. 읽는 사람의 시간을 아껴주면 됩니다. 문제는 대부분의 개발자가 자기 시간을 기준으로 씁니다.

기술 스택을 나열하는 건 이력서가 아닙니다

200명 넘게 이력서 피드백을 하면서 가장 많이 본 패턴이 있습니다. "Java, Spring Boot, MySQL, Redis, Kafka, Docker, AWS EC2, S3, RDS, Git, Jenkins..." 이런 식입니다.

채용 담당자는 5초 안에 이 목록을 스캔하고 넘깁니다. 기억에 남지 않습니다. 기술 스택이 많을수록 "이 사람이 뭘 잘 하는 거지?"라는 의문만 생깁니다.

백엔드 이력서에서 기술 스택은 최대 5개만 써야 합니다. 그것도 "잘 안다"는 걸 증명할 수 있는 것만. JPA를 쓴다고 적고 N+1 문제를 모르면 면접에서 바로 걸립니다. 적지 않은 게 차라리 낫습니다.

프로젝트 설명에서 빠져있는 한 가지

"쇼핑몰 백엔드를 Spring Boot로 개발했습니다. 회원, 상품, 주문, 결제 기능을 구현했고 REST API를 설계했습니다."

읽어도 이 사람이 무엇을 해결했는지 모릅니다. 개발은 했는데 왜 했는지, 어떤 문제가 있었는지, 결과가 어땠는지가 없습니다.

멘토링 3주차에 나오는 말이 있습니다. "아, 그때 결제 동시성 문제가 있었는데 분산 락으로 해결했어요." 처음부터 그 얘기를 했어야 합니다. 실제로 11주차에 처음 꺼낸 사람도 있습니다. 당시 동시 주문이 들어올 때 재고가 음수가 됐다가 나중에 발견했다는 이야기였습니다. 그게 이력서 한 줄이 됐습니다.

API 응답 속도를 몇 ms 줄였는지, 에러율이 몇 퍼센트 개선됐는지. 숫자가 없으면 최소한 "어떤 제약이 있었고 어떻게 선택했는지"는 있어야 합니다.

신입인데 수치가 없으면 어떻게 하나요

자주 받는 질문입니다. 수치가 없다고 생각하지만 대부분은 있습니다. 못 보고 있을 뿐입니다.

사이드 프로젝트에서 API를 직접 테스트해봤다면 응답 시간이 있습니다. DB에 데이터를 넣고 조회해봤다면 그 양이 있습니다. 팀 프로젝트였다면 팀원 수, 개발 기간, 구현한 API 개수가 있습니다.

"DAU 1000명 서비스"가 아니어도 됩니다. "팀원 3명, 6주 개발, REST API 18개 구현" 이것도 수치입니다. 없는 것보다 훨씬 낫습니다. 내가 그 프로젝트에서 무엇을 판단하고 결정했는지가 핵심입니다.

어디서부터 고쳐야 할까요

지금 이력서를 소리 내어 읽어보세요. 막히는 문장이 있으면 그게 고쳐야 할 부분입니다.

다음은 프로젝트 설명에서 "구현했습니다", "개발했습니다" 같은 동사를 지우고 "어떤 문제가 있었고 어떻게 해결했는지"를 쓰는 겁니다.

200명 넘게 이력서를 보면서 한 가지는 분명했습니다. 서류를 통과하는 이력서는 길이가 짧습니다. 하고 싶은 말이 아니라 읽는 사람이 알고 싶은 것만 있습니다.

이력서가 계속 같은 피드백을 받는다면, 방향을 점검해보세요. https://teamgrit.co/direction