이력서에 사이드 프로젝트 잘못 쓰는 법

프로젝트가 많다고 좋은 게 아니더라

이력서 스크리닝을 하다 보면, 사이드 프로젝트가 많을수록 좋은 인상을 줄 거라 생각하는 사람이 많다. 두 페이지 가득 채운 프로젝트 목록. 열정적으로 보이려는 의도는 이해하지만, 솔직히 5개 나열했는데 전부 투두 앱 수준이면 "같은 수준에서 벗어나지 못하고 있구나"라는 인상을 준다.

차라리 안 쓰는 게 낫다.

(나도 1년 차 때 투두 앱 3개를 이력서에 올렸던 흑역사가 있다. 하나는 React, 하나는 Vue, 하나는 바닐라 JS로 만들었는데, 지금 보면 전부 같은 수준이었다.)

기술 스택만 나열하면 면접에서 터진다

"React, TypeScript, Tailwind, Zustand, React Query, Prisma, PostgreSQL, Docker, AWS"를 한 프로젝트에 다 썼다고 적어놓은 이력서를 자주 본다. 화려해 보이려는 건 알겠는데, 면접에서 물어보면 Docker는 블로그에서 Dockerfile 복붙한 수준이고, AWS는 S3에 이미지 올린 게 전부인 경우가 많다.

Prisma는 ORM 쓴다는 것만 알고 raw query는 작성할 줄 모르고, PostgreSQL 인덱싱은 들어본 적도 없다. 이런 경우 면접에서 꼬리 질문이 들어가면 바로 드러난다.

"React Query로 API 캐싱을 적용해서 불필요한 네트워크 요청을 63% 줄였습니다"와 "React Query 사용"은 완전히 다른 메시지다. 그 기술로 어떤 문제를 해결했는지가 중요하다.

클론 코딩의 함정

넷플릭스 클론, 인스타 클론, 당근마켓 클론. 학습용으로는 좋지만 이력서에 쓰면 "유튜브 강의 따라 했구나"라는 인상을 준다. 면접에서 "이 부분은 직접 설계하신 건가요?" 물으면 대부분 답을 못 한다.

차라리 작더라도 내가 실제로 겪은 문제를 해결한 프로젝트가 훨씬 강하다. 매일 카페 가는데 자리가 없어서 만든 좌석 현황 앱, 사내 회의실 예약이 불편해서 만든 슬랙 봇, 부모님 약 복용 알림이 필요해서 만든 알림 앱. 이런 프로젝트는 면접에서 할 말이 넘친다. 왜 만들었는지, 어떤 어려움이 있었는지, 반응이 어땠는지.

배포 안 한 프로젝트는 반쪽이다

깃허브 링크만 있고 배포 URL이 없는 프로젝트는 신뢰도가 반으로 떨어진다. "동작하는 프로젝트"와 "코드만 있는 프로젝트"의 차이는 크다. Vercel이나 Cloudflare Pages에 올리는 데 10분이면 된다.

"로컬에서만 돌아가는 프로젝트"는 "완성 안 한 프로젝트"랑 같은 의미로 읽힌다. 배포 과정에서 만나는 환경 변수 관리, 도메인 설정, HTTPS 적용 같은 경험도 어필할 수 있는 내용인데, 그걸 안 하고 넘어가면 아깝다.

README가 기본값 그대로인 사람이 놀라울 정도로 많다

리포에 들어갔는데 "Getting Started with Create React App" 기본값 그대로인 경우. 혹은 README 자체가 없는 경우도 있다. 이건 디테일에 신경 안 쓰는 사람이라는 신호다.

스크린샷 2~3장, 핵심 기능 3줄, 기술 선택 이유 2줄, 실행 방법 정도만 적어도 인상이 완전히 달라진다. README 작성 30분이 코드 10줄 추가하는 것보다 이력서에는 더 효과적이다.

내가 겪어보니까 이렇게 쓰는 게 낫다

프로젝트 한 줄 소개, 해결하려 한 문제, 핵심 기술 의사결정 12개, 결과와 배운 점. 이 네 가지를 각각 12줄로 쓰면 된다.

특히 "왜 A 대신 B를 선택했는가"를 설명할 수 있으면, 면접에서 대화가 자연스럽게 이어진다. "상태 관리로 Context API를 쓸까 고민했는데 리렌더링 이슈 때문에 Zustand를 선택했습니다" 같은 한 문장이 기술 이해도를 보여주는 증거가 된다.

(근데 나도 이렇게 깔끔하게 쓴 건 4년 차부터였다. 그 전까지는 기술 스택 나열만 했다. 부끄럽지만 사실이다.)

프로젝트 수보다 깊이

10개의 얕은 프로젝트보다 1개의 깊은 프로젝트가 낫다. 6개월 동안 하나를 운영하면서 피드백 반영하고, 성능 개선하고, 장애 대응한 경험이 있다면 그것만으로 면접 30분을 채울 수 있다.

실제 사용자가 있는 프로젝트라면 더 좋다. 사용자가 5명이든 50명이든, "실제 사용자에게 배포하고 피드백을 받았다"는 경험 자체가 차별화 포인트다. 채용 담당자가 보고 싶은 건 기술 목록이 아니라 사고 과정이다.