[Tech Lead 관점] - 신입 개발자 이력서에서 제일 먼저 보는 3가지

채용하는 입장에서 말해볼게요.

“실력이 중요하죠.” 맞아요. 근데 그 실력을 보기 전에, 이력서에서 먼저 걸러지는 포인트가 있습니다. 제가 이력서 열자마자 습관처럼 확인하는 것 딱 3가지만 정리해볼게요.

결론부터 말하자면, 우리 회사 들어와서, "사고칠거 같냐? 아니냐?" 를 기준으로 잡습니다.
그걸 판단하기 위해서 다음 3가지를 가장 먼저 봅니다.

1) 구조 & 가독성 — 코드 보기 전부터 이미 점수 난다

이력서 파일을 열자마자 제일 먼저 보는 건 기술 스택이 아니라 구조예요. 제목/섹션/프로젝트가 한눈에 정리돼 있으면, 그 자체로 “일 잘하겠다”는 인상을 줍니다.

반대로, 글이 길고 흐름이 없으면 이런 생각이 먼저 들어요.

“실무에서도 정리 없이 던지고 끝내는 스타일이면 어떡하지?”

체크 포인트

• 프로젝트는 무슨 문제 → 내가 한 일 → 결과 순서가 제일 읽기 좋음

• “열심히 했습니다/많이 배웠습니다” 같은 문장 줄이고, 사실(근거)로 대체

2) 프로젝트에서 “내가 뭘 했는지”가 선명한가

신입 이력서에서 정말 많이 보는 문장이 있습니다.

“팀 프로젝트로 웹 서비스 개발”

이 문장 자체는 틀린 말이 아닌데, 정보가 거의 없어요. 실무 입장에서는 “그래서 본인은 뭘 했는데?”가 바로 떠오릅니다.

NO : 기능 나열만 있음

• 로그인/회원가입 구현
  

OK : 문제 + 선택 + 결과가 보임

• JWT 기반 로그인 구현. 토큰 만료로 인증 오류가 자주 발생해 refresh token 구조로 개선했고, 재로그인 빈도를 줄였다(예: 관련 이슈/로그 감소 등 근거가 있으면 더 좋음).

체크 포인트

• 역할/담당 범위를 1~2줄로 먼저 못 박기

• 가능하면 결과를 숫자/지표로(속도 개선 %, 오류 감소, 트래픽 규모 등)

3) 기술 스택 ‘많음’이 아니라, 기술 이해도가 느껴지는가

기술 스택을 잔뜩 적어두면 좋아 보일 것 같지만… 솔직히 말하면, 스택이 10개 넘어가면 오히려 신뢰가 떨어질 때가 있어요.

대신 이런 걸 봅니다.

• 왜 그 기술을 썼는지 설명할 수 있는지

• 어떤 트러블이 있었고 어떻게 해결했는지

• 하나라도 깊게 써본 흔적(설계/트러블슈팅/성능/테스트 등)이 있는지
  

팁
“써봤어요”보다 “이 상황에서 이 이유로 선택했고, 이런 trade-off가 있었다”가 훨씬 강합니다.

체크 포인트

• 기술 스택은 ‘나열’보다 프로젝트 문장 안에 녹이기

• 자신 없는 기술은 과감히 빼고, 자신 있는 2~4개를 더 탄탄하게

• 깊게 한 경험이 없으면 “학습/개인 실습”으로 분리 표기

마무리 — 신입에게 기대하는 건 ‘완성도’가 아니라‘태도와 근거’

신입에게 완벽한 실력을 기대하진 않아요. 대신, 정리할 줄 아는 사람, 배운 걸 자기 말로 설명하는 사람, 같이 일할 때 불안하지 않은 사람을 찾습니다.

이력서는 “저 이런 사람이에요”를 보여주는 첫 대화고요. 그래서 프로젝트가 화려하냐보다, 읽히냐/설명되냐/근거가 있냐가 먼저입니다.

—