프론트엔드 개발자를 꿈꾸며 공부를 시작했던 시점과 지금은 분명히 다르다. 채용 공고가 줄었고, 경쟁자는 늘었으며, 몇 년 전이라면 주니어 포지션으로 충분했던 조건이 이제는 ‘기본’이 됐다. 그러나 이 흐름을 ‘채용 절벽’이라는 한 단어로 뭉뚱그리면 정작 중요한 것을 놓친다. 시장이 좁아진 것이 아니라, 시장이 원하는 개발자의 기준이 높아졌다. 이 글은 그 갈림길에서 어느 방향으로 걷느냐가 앞으로의 커리어를 가른다는 전제 아래, 지금 당장 실행 가능한 방향을 구체적으로 짚는다.
왜 지금 프론트엔드 채용이 어려워졌는가
채용 시장의 냉각은 단순히 경기 탓만이 아니다. 지난 몇 년간 부트캠프와 온라인 강의를 거친 개발자 공급이 급격히 늘었다. 기업 입장에서는 선택지가 많아졌고, 자연히 기준이 높아졌다. 동시에 회사들도 팀 규모를 보수적으로 유지하면서, 한 명을 채용할 때 더 넓은 역할을 감당할 수 있는 사람을 원하게 됐다.
여기서 주목할 점은 ‘채용 자체가 멈춘 게 아니라는 것’이다. 실제로 여전히 프론트엔드 개발자를 뽑는 팀이 있고, 합격 소식도 들린다. 차이는 무엇인가. 비슷한 기술 스택을 가진 지원자들 중에서 ‘이 사람은 우리 팀에 들어오면 바로 기여할 수 있겠다’는 인상을 주느냐의 여부다. 이는 기술 목록의 문제가 아니라 역량을 증명하는 방식의 문제다.
또 하나의 변수는 AI 도구의 확산이다. Copilot 같은 도구가 단순 코드 생성을 상당 부분 대체하기 시작하면서, ‘코드를 짤 수 있다’는 것 자체는 예전보다 낮은 기준이 됐다. 이제 채용 담당자가 보는 것은 코드를 아느냐보다, 어떤 판단으로 코드를 쓰느냐다.
기술 스택보다 ‘문제 해결 서사’가 먼저다
포트폴리오를 리뷰하다 보면 반복되는 패턴이 있다. React, TypeScript, Tailwind를 썼다는 기록은 있는데, 왜 그 기술을 선택했고 어떤 문제를 풀었는지가 없다. 기술 스택은 도구일 뿐이고, 면접관이 알고 싶은 것은 그 도구로 무엇을 해결했느냐다.
프로젝트 하나를 설명할 때 다음 세 가지를 갖추면 훨씬 설득력이 생긴다. 첫째, 어떤 불편함이나 문제가 있었는가. 둘째, 여러 선택지 중 왜 이 방법을 골랐는가. 셋째, 그 결과가 사용자나 팀에 어떤 차이를 만들었는가. 이 구조로 서술된 프로젝트 두세 개가 기술 나열식 열 개보다 훨씬 강하게 기억된다.
실제로 개인 프로젝트를 다듬을 때, 구현보다 README와 회고 작성에 시간을 더 써야 할 수도 있다. ‘어떤 트레이드오프를 고민했고, 어떤 결론을 내렸는가’를 글로 정리하는 능력이 곧 시니어와 함께 일할 수 있는 사람이라는 신호를 준다.
스펙 쌓기보다 깊이 있는 영역 하나를 만들어라
많은 주니어 개발자가 이력서를 두껍게 만들려고 넓게 공부한다. 그러나 이미 같은 스택을 아는 지원자가 수십 명인 상황에서 ‘저도 알아요’는 차별점이 되지 않는다. 오히려 한 가지 영역에서 다른 지원자보다 명확히 깊은 이해를 보이는 것이 기억에 남는다.
예를 들어 웹 성능 최적화에 집중한다면, Lighthouse 점수를 올리는 방법만 아는 것이 아니라 Core Web Vitals가 실제 사용자 경험에 어떻게 영향을 주는지, LCP와 CLS를 개선하기 위해 렌더링 흐름을 어떻게 바꿨는지를 설명할 수 있어야 한다. 이 정도의 이해는 면접에서 “이 사람은 진짜로 해봤구나”는 인상을 남긴다.
깊이 있는 영역을 선택할 때 좋은 기준은 두 가지다. 첫째, 자신이 실제로 흥미를 느끼는 주제여야 유지할 수 있다. 둘째, 현업에서도 실질적으로 중요하게 다뤄지는 문제여야 채용 연결성이 생긴다. 접근성(Accessibility), 상태 관리 설계, 번들 최적화, 테스트 전략 등이 그런 주제에 해당한다.
코드 리뷰와 협업 맥락에서 자신을 증명하라
채용 과정에서 기술 면접 외에 점점 더 중요해지는 것이 ‘함께 일할 수 있는 사람인가’다. 특히 소규모 팀일수록, 온보딩 비용을 최소화할 수 있는 사람을 선호한다. 코드를 잘 짜는 것과 팀 안에서 잘 협업하는 것은 다른 역량이고, 면접관은 두 가지 모두를 확인하려 한다.
오픈소스 기여나 스터디 그룹 경험이 있다면 반드시 이력서나 포트폴리오에 포함시켜라. 단순히 ‘참여했다’가 아니라, 어떤 피드백을 주고받았고, 다른 사람의 코드를 어떻게 리뷰했는지까지 구체적으로 쓰면 훨씬 설득력이 있다. 깃허브 이슈 댓글, PR 리뷰 기록 같은 공개된 흔적은 증거가 된다.
협업 경험이 부족하다면 지금이라도 만들 수 있다. 오픈소스 프로젝트의 문서 개선 PR부터 시작해도 충분하다. 코드 한 줄보다 명확한 문서 개선이 더 빠르게 머지되고, 그 과정에서 메인테이너와 소통하는 경험이 쌓인다. 협업 역량을 보여주는 공개 기록이 점점 유효한 포트폴리오 자산이 되고 있다.
지원 전략: 넓게 뿌리기보다 정밀하게 조준하기
취업 준비생들이 자주 빠지는 함정 중 하나는 지원서를 대량으로 보내는 방식이다. 수십 군데에 같은 이력서를 돌리면 숫자는 채워지지만 실제 면접 전환율은 낮아진다. 반대로 열 군데를 정밀하게 조준하는 전략이 훨씬 효율적이다.
정밀 지원을 위한 체크리스트는 다음과 같다.
- 해당 팀이 지금 어떤 기술적 문제를 안고 있는지 채용 공고와 회사 기술 블로그를 통해 파악한다.
- 자기소개서에 ‘나의 경험이 그 문제와 어떻게 연결되는지’를 한 문단으로 구체적으로 쓴다.
- 포트폴리오에서 그 회사와 관련된 프로젝트를 앞으로 배치한다.
- 공고가 없어도 링크드인이나 커뮤니티를 통해 해당 팀 개발자와 접점을 만들 수 있는지 탐색한다.
- 1차 면접 전에 회사 제품을 실제로 써보고, 사용자로서 발견한 개선 포인트를 정리해둔다.
이 과정은 시간이 더 걸리지만, 면접에서 ‘이 회사에 관심이 있다’는 신호를 구체적으로 줄 수 있다. 이 신호는 생각보다 강하게 작동한다.
AI 도구 시대, 대체되지 않는 개발자의 조건
AI 코딩 도구가 확산되면서 ‘프론트엔드 개발자가 없어지는 것 아니냐’는 불안이 커지고 있다. 그러나 현실을 보면 AI는 특정 종류의 작업을 빠르게 처리해주는 도구가 됐을 뿐, 어떤 것을 만들지 판단하고, 사용자 경험을 설계하고, 코드 품질과 유지보수 가능성을 고민하는 역할은 사람에게 여전히 있다.
AI 도구를 잘 쓰는 것 자체도 이제 하나의 역량이다. Copilot이 제안하는 코드를 그대로 받아들이는 사람과, 그 코드를 비판적으로 읽고 더 나은 구조로 다듬을 수 있는 사람은 분명히 다르다. 도구를 활용하되 도구에 의존하지 않는 판단력이 앞으로 더 중요해진다.
결국 대체되지 않는 개발자는 코드를 많이 아는 사람이 아니라, 코드로 무엇을 해결할지 생각할 수 있는 사람이다. 기술 변화에 적응하면서도 핵심적인 문제 해결 능력과 협업 역량을 꾸준히 키워온 사람이 그 조건에 가장 가깝다. 이것은 지금 당장 시작할 수 있는 방향이기도 하다.
채용 시장이 어렵다는 말이 맞을 수 있다. 그러나 어려운 시장은 준비된 사람에게 오히려 기회가 된다. 경쟁자 대부분이 포기하거나 방향을 잃을 때, 구체적인 방향으로 꾸준히 움직이는 사람이 결국 면접 기회를 잡는다. 누스쿨 커뮤니티와 멘토링은 그 방향을 함께 점검하고 다듬어가는 공간이다. 혼자 고민하기 어려운 지점이 있다면, 비슷한 목표를 가진 사람들과 함께 이야기해보는 것이 가장 빠른 다음 걸음이 될 수 있다.
💬 댓글 0