프론트엔드 신입 포트폴리오를 몇 번씩 다듬어도 계속 서류에서 막힌다면, 문제는 기술 스택의 개수가 아닐 수 있습니다. React, TypeScript, Next.js, Tailwind를 빼곡히 적어두고도 면접까지 가지 못하는 지원서를 1년에 수백 장 봅니다. 기술을 적게 써서 떨어지는 게 아니라, 오히려 나열만 많은 포트폴리오일수록 더 빨리 넘어갑니다.
프론트엔드 신입 채용에서 개발팀이 실제로 확인하는 것과, 취준생이 공들이는 것 사이에는 생각보다 큰 간극이 있습니다. 8년간 스타트업과 IT 서비스 기업에서 프론트엔드 개발자를 뽑으면서 본 합격자들의 공통점은 화려한 기술 스택이 아니었습니다. 기술 스택보다 먼저 보는 3가지를 정리합니다.
1. 무엇을 만들었는가보다, 왜 그렇게 만들었는지 설명할 수 있는가
프론트엔드 신입 포트폴리오를 준비하면 대부분 강의를 따라 만든 클론 코딩 결과물부터 채웁니다. 넷플릭스 클론, 쇼핑몰 클론, 트위터 클론 같은 프로젝트가 줄지어 들어 있습니다. 8년간 채용하면서 클론 프로젝트의 개수를 이유로 합격시킨 신입은 없었습니다. 같은 강의를 들은 지원자가 수백 명이고, 결과물이 거의 똑같기 때문입니다.
채용 담당자가 보는 것은 그 다음입니다. 같은 화면을 만들었더라도 왜 그 구조를 택했는지 설명할 수 있는가입니다. 상태 관리를 왜 전역으로 뺐는지, 컴포넌트를 왜 그 단위로 쪼갰는지, 그때 다른 선택지는 없었는지를 말할 수 있는 사람과, "강의에서 그렇게 했어요"에서 멈추는 사람은 완전히 다릅니다. 프론트엔드는 결국 수많은 선택 사이에서 근거를 가지고 결정하는 직무이기 때문입니다.
이 설명 능력은 거창한 프로젝트가 없어도 보여줄 수 있습니다. 이미 만든 클론 프로젝트라도, README에 "이 부분은 처음에 이렇게 짰는데 이런 문제가 생겨서 이렇게 바꿨다"를 한두 줄 적어두는 것만으로 충분합니다. 면접에서 "이 프로젝트에서 가장 고민했던 부분이 뭐였나요"라는 질문에 이렇게 답하는 신입은 바로 눈에 띕니다. 따라 만든 결과물 열 개보다, 한 개라도 자기 언어로 설명할 수 있는 프로젝트가 훨씬 강합니다.
한 가지 더 기억할 것이 있습니다. 설명할 수 있다는 것은 잘된 부분만 자랑하는 일이 아닙니다. 처음 잡은 구조가 왜 막혔는지, 무엇을 다르게 바꿨는지를 말할 수 있는 사람이 채용 담당자에게는 더 믿음직합니다. 신입에게 완벽한 설계를 기대하는 회사는 없습니다. 막힌 지점을 솔직하게 마주하고 거기서 배운 점을 정리해본 흔적이, 매끈한 결과 화면 하나보다 신입 단계에서 의외로 더 큰 신뢰를 만듭니다.
2. 기술 스택 나열보다, 하나라도 제대로 동작하고 배포된 결과물이 강하다
프론트엔드 신입 포트폴리오에서 가장 자주 보는 것이 "사용 기술" 목록입니다. 그런데 그 목록에 적힌 라이브러리를 실제로 어디에 어떻게 썼는지는 비어 있는 경우가 많습니다. 합격자들의 포트폴리오에는 규모가 작아도 실제로 배포되어 접속 가능한 결과물 하나가 들어 있었습니다. 깃허브 저장소 링크뿐 아니라, 클릭하면 바로 동작하는 배포 URL이 있는 것입니다.
배포된 결과물이 강한 이유는 기술 스택 목록으로는 증명할 수 없는 것을 보여주기 때문입니다. 끝까지 완성해본 경험, 에러를 만나도 포기하지 않고 동작하는 상태까지 끌고 간 끈기, 그리고 남이 실제로 써볼 수 있게 만든 마무리 감각이 담깁니다. 화면 캡처 다섯 장보다 동작하는 링크 하나가 채용 담당자에게 훨씬 분명한 신호입니다. 미완성 프로젝트가 열 개인 것보다, 끝까지 배포한 작은 프로젝트 하나가 신입 단계에서는 더 큰 신뢰를 만듭니다.
이것은 다른 직무의 포트폴리오에서도 똑같이 통합니다. UX 디자이너 신입 포트폴리오에서 채용 담당자가 가장 먼저 보는 것도 결국 완성도와 끝맺음의 흔적입니다. 아직 배포해본 프로젝트가 없다면 지금이라도 만들 수 있습니다. 이미 만든 것 중 하나를 골라 깃허브 페이지나 무료 호스팅에 올리고, 실제로 동작하는지 모바일에서까지 확인해두는 것입니다. 그 링크 하나가 기술 스택 열 줄을 이깁니다.
3. 혼자 돌아가는 코드인가보다, 남이 읽을 수 있게 썼는가
프론트엔드 신입 면접에서 코드를 함께 볼 때 가장 많이 드러나는 차이가 이 지점입니다. 화면은 똑같이 잘 동작하는데, 막상 저장소를 열어보면 커밋이 "수정", "또 수정", "최종"으로만 쌓여 있고, 폴더 구조도 규칙이 보이지 않습니다. 혼자 만들 때는 문제가 없지만, 협업하는 순간 읽기 어려운 코드입니다. 실무는 거의 모든 코드를 다른 사람과 함께 읽고 고치는 일이기 때문에, 채용 담당자는 여기서 멈칫합니다.
합격한 신입들은 달랐습니다. 화려한 코드가 아니라, 남이 읽기 쉬운 코드를 썼습니다. 커밋 메시지에 무엇을 왜 바꿨는지가 적혀 있고, 폴더와 파일 이름에 일관된 규칙이 있고, README만 봐도 이 프로젝트가 무엇이고 어떻게 실행하는지 알 수 있었습니다. 신입에게 천재적인 알고리즘을 기대하는 회사는 거의 없습니다. 함께 일했을 때 내 코드를 읽고 이어받기 쉬운 사람인가를 봅니다.
이것은 결국 협업 가능성에 대한 신호입니다. 경험이 부족해도 합격하는 신입들의 공통점도, 혼자 잘하는 사람이 아니라 함께 일하기 쉬운 사람이라는 인상을 남겼다는 점입니다. 지금 내 저장소를 처음 보는 사람의 눈으로 한 번 열어보세요. README가 비어 있고 커밋 메시지가 의미 없다면, 코드 실력과 무관하게 그 포트폴리오는 협업 신호를 잃고 있는 것입니다.
지금 준비하고 있는 것을 한 번 점검해보세요. 빼곡히 적어둔 기술 스택과 클론 프로젝트 개수가, 채용 담당자가 검증하는 3가지 — 선택의 근거를 설명하는 능력, 끝까지 배포한 결과물, 남이 읽을 수 있는 코드 — 와 얼마나 연결되어 있는지 확인하는 것이 프론트엔드 신입 취업 준비의 핵심입니다. 연결되지 않는 준비는 아무리 쌓아도 서류를 통과시키지 못합니다.
프론트엔드 신입 취업은 기술 스택을 몇 개 적느냐의 문제가 아닙니다. 선택의 근거를 설명하는 능력, 작더라도 끝까지 배포한 결과물, 남이 읽을 수 있게 쓴 코드 — 이 3가지가 스택 목록보다 먼저입니다. 합격한 신입들이 특별히 어려운 기술을 다뤘던 게 아닙니다. 자기가 만든 것을 설명하고, 끝맺고, 함께 읽을 수 있게 남겼을 뿐입니다. 지금 준비하고 있는 것이 이 방향에 맞는지 점검해보세요.