포트폴리오에서 진짜 중요한 것

예쁜 사이트가 합격을 만드는 건 아니다

포트폴리오 사이트 디자인에 2주를 투자하는 사람을 많이 봤다. 스크롤 애니메이션, 파티클 효과, 3D 모델 회전, 마우스 따라다니는 커서. 멋있긴 한데, 이 말을 해야 할 것 같다.

채용 담당자는 포트폴리오를 30초 이상 보는 경우가 드물다. 이력서 100개를 스크리닝할 때 한 사람에게 5분 쓸 수 있으면 많이 쓰는 거다. 그 5분 안에 "이 사람을 면접에 부를 가치가 있는가?"를 판단해야 한다. 5초 안에 핵심을 못 찾으면 넘긴다.

(나도 화려한 포트폴리오 사이트를 만들겠다고 2주를 쓴 적이 있다. Framer Motion으로 온갖 애니메이션을 넣었는데, 정작 프로젝트 설명은 대충 썼다. 그때 그 시간에 프로젝트 설명이나 잘 적어놓을 걸.)

첫 5초에 뭐가 보여야 하는가

세 가지다. 이 사람이 뭘 할 수 있는지(역할과 기술), 어떤 프로젝트를 했는지(경험), 연락처가 어딨는지(이메일이나 깃허브). 이 세 가지가 랜딩 페이지에서 바로 보여야 한다.

스크롤 세 번 내려야 프로젝트가 나오고, 클릭 두 번 해야 상세 설명이 나오면 이미 절반은 놓친 거다. 첫 화면에서 승부를 봐야 한다.

프로젝트 설명에 숫자를 넣어라

프로젝트를 나열하는 건 누구나 한다. 차이를 만드는 건 깊이다. "React로 커머스 사이트를 만들었습니다" 대신 "상품 목록 페이지 초기 로딩을 3.2초에서 0.8초로 줄였습니다. Next.js ISR과 이미지 lazy loading을 적용해서 달성했습니다" — 완전히 다른 인상을 준다.

숫자가 없는 성과는 감상문이다. 성능 개선이든 사용자 수든 코드 라인 수 감소든, 측정 가능한 수치를 넣어라. "사용자 경험을 개선했습니다"보다 "페이지 이탈률을 35%에서 15%로 줄였습니다"가 100배 설득력 있다.

숫자를 만들어내라는 게 아니다. 프로젝트 하면서 실제로 측정해라. Lighthouse 점수, 번들 사이즈, API 응답 시간. 측정하는 습관 자체가 좋은 개발자의 자질이다.

깃허브가 더 많은 걸 말해준다

화려한 포트폴리오 사이트보다 깃허브의 커밋 히스토리가 더 많은 걸 말해준다. 나는 지원자 깃허브를 볼 때 이걸 본다.

커밋 메시지가 의미 있는가 — "feat: 로그인 기능 추가"와 "asdf", "fix", "update"는 하늘과 땅 차이다. 코드 구조가 일관적인가, 폴더 구조와 네이밍이 통일돼 있는가. 이슈와 PR을 활용하는가.

혼자 하는 프로젝트에서도 이슈 만들고 PR로 머지하는 습관이 있다면, 협업 준비가 된 사람이라는 신호다. 근데 이것도 사람마다 다를 수 있다. 내가 보는 포인트일 뿐이다.

블로그가 있으면 가산점이다

매주 글을 쓸 필요 없다. 프로젝트 하면서 겪은 트러블슈팅 2~3개만 정리해놓으면 충분하다. "React에서 무한 스크롤 구현 중 메모리 누수 해결 과정" 같은 글이 있으면, 이 사람은 문제를 겪으면 기록하고 정리하는 습관이 있구나라는 인상을 준다. 이 습관은 실무에서 매우 유용하다.

모바일에서 깨지면 게임 오버다

프론트엔드 포트폴리오가 모바일에서 깨지면, 설득력이 없다. 채용 담당자가 출퇴근 지하철에서 핸드폰으로 볼 수도 있고, 면접 전 회의실에서 태블릿으로 볼 수도 있다.

놀라울 정도로 많은 포트폴리오가 모바일 대응이 안 돼 있다. 프론트엔드 개발자라면서 반응형이 안 되는 건 좀 아이러니하다.

일단 내놓고 시작해라

완벽한 포트폴리오를 만들려다 영원히 못 내놓는 사람이 많다. "디자인 좀 더 다듬고", "프로젝트 하나만 더" 하면서 2개월이 지나도 공개를 못 한다.

차라리 Notion이나 GitHub Pages로 간단하게 시작해서, 프로젝트 생길 때마다 업데이트하는 게 현실적이다. 포트폴리오는 "완성"되는 게 아니라 계속 "업데이트"되는 거다. 1.0을 내놓지 않으면 2.0은 영원히 안 온다.

포트폴리오의 목적은 딱 하나다. 면접 기회를 만드는 것. 화려함이 아니라 명확함이 무기다.