프론트엔드 개발자 이력서 작성법 - 담당자는 기술 스택 목록을 믿지 않습니다

프론트엔드 개발자는 지원자가 많은 직무입니다. 부트캠프와 국비 과정에서 매년 쏟아지는 인원의 상당수가 프론트엔드로 시작하고 그만큼 서류 경쟁도 치열합니다. 그런데 막상 쌓인 이력서를 열어보면 상당수가 비슷하게 생겼습니다. React, TypeScript, Next.js 같은 기술 이름이 위쪽에 죽 나열되고 그 아래 참여 프로젝트가 몇 줄씩 붙는 구성입니다. 문제는 담당자가 이 기술 목록을 거의 믿지 않는다는 데 있습니다. 목록에 React를 적는 데는 아무 비용이 들지 않으니까요. 그래서 담당자는 목록이 아니라 본문에서 그 기술을 진짜로 다뤄본 흔적을 찾습니다. 프론트엔드 이력서에서 그 흔적이 어디서 드러나는지를 정리해봤습니다.

스택 이름이 아니라 선택의 이유가 신호다

같은 React 경력 3년이라도 이력서에서 드러나는 수준은 크게 갈립니다. 갈리는 지점은 어떤 도구를 썼느냐가 아니라 왜 그 도구를 골랐는지가 적혀 있느냐입니다. 예를 들어 상태 관리를 "Redux 사용"이라고만 적으면 담당자가 얻는 정보가 없습니다. 반면 서버에서 오는 데이터는 TanStack Query로 캐싱하고 화면 안에서만 쓰는 상태는 Zustand로 분리했다는 식으로 적히면 이 사람이 서버 상태와 클라이언트 상태를 구분해서 설계할 줄 안다는 게 바로 보입니다. 이 구분은 현재 프론트엔드 생태계의 표준 감각이라 담당자 입장에서는 지원자의 동시대성을 확인하는 빠른 기준이 됩니다. 렌더링 전략도 마찬가지입니다. Next.js를 썼다는 사실보다 이 페이지는 검색 유입이 중요해서 SSR을 택했고 저 페이지는 갱신이 드물어 SSG로 돌렸다는 선택의 근거가 적혀 있을 때 도구를 이해하고 쓰는 사람으로 읽힙니다.

성능 개선은 수치가 남는 대표 작업이다

프론트엔드 업무 중에서 전후 숫자가 가장 깔끔하게 남는 영역이 성능입니다. 그리고 성능에는 이미 업계 표준 지표가 있습니다. Core Web Vitals, 그러니까 LCP(로딩), INP(반응성), CLS(화면 흔들림)입니다. "페이지 로딩 속도를 개선했습니다"는 검증할 방법이 없는 문장입니다. 같은 일을 "이미지 lazy loading과 코드 스플리팅으로 LCP를 4.1초에서 1.8초로 줄였습니다"라고 적으면 측정하고 개선하는 사람이라는 증거가 됩니다. 담당자는 숫자 자체보다 측정 도구(Lighthouse, 실사용자 데이터)를 놓고 일하는 습관을 봅니다. 번들 사이즈 감축, 리렌더 최적화 같은 작업도 전부 수치로 표현할 수 있는 일들입니다. 만약 지금 다니는 회사에서 이런 개선을 해본 적이 없다면 이력서를 쓰기 전에 하나 만들어두는 것도 방법입니다. 성능 측정과 개선 제안은 팀 규모와 무관하게 시작할 수 있는 일이라 주니어에게도 열려 있는 대표 작업입니다.

접근성과 디자인 시스템은 연차를 가르는 신호다

비슷한 경력끼리 견줄 때 담당자 눈에 차이를 만드는 영역이 두 가지 있습니다. 하나는 접근성입니다. "반응형으로 만들었습니다" 수준의 서술은 이제 변별력이 없습니다. 시맨틱 HTML과 키보드 내비게이션을 챙기고 axe나 Lighthouse로 검증했다는 서술이 있으면 사용자를 넓게 보는 사람으로 읽힙니다. 접근성은 법적 요구와 함께 채용 시장에서 비중이 계속 커지는 영역이라 적어둘 경험이 있다면 빼지 않는 편이 좋습니다. 다른 하나는 디자인 시스템입니다. 공통 컴포넌트를 추출해서 Storybook으로 문서화하고 팀이 같이 쓰게 만들었다는 경험은 혼자 화면을 만드는 단계를 지나 팀이 딛는 기반을 만드는 단계로 넘어갔다는 신호입니다. 규모가 작아도 괜찮습니다. 버튼과 폼 몇 개라도 중복 구현을 정리해서 팀 전체의 작업 방식을 바꿨다면 그 자체가 시니어 방향의 근거가 됩니다.

포트폴리오의 무게는 연차에 따라 다르다

프론트엔드는 결과물이 눈에 보이는 직무라 포트폴리오 이야기가 많이 나옵니다. 다만 그 무게는 연차에 따라 다릅니다. 신입에게는 회사 경력이 없으니 포트폴리오가 판단 재료의 거의 전부지만 경력직에게는 경력기술서가 본체고 포트폴리오는 보조 증거입니다. 실제로 경력 채용에서는 별도 포트폴리오 대신 과제 전형이나 라이브 코딩으로 검증을 대체하는 회사가 늘고 있습니다. 연차와 무관하게 기본이 되는 건 GitHub 링크입니다. 담당자가 꼼꼼히 읽지 않더라도 코드를 공개할 수 있다는 사실 자체가 신뢰의 바탕이 됩니다. 회사 일에 밀려 잔디가 비어 있어도 크게 감점되지 않으니 링크를 빼는 것보다 넣는 쪽이 낫습니다. 경력직이라면 여기에 참여한 서비스의 실제 URL과 그 안에서 맡은 부분 한 줄이 사실상의 포트폴리오 역할을 합니다. 성능 개선 과정을 수치와 함께 정리한 기술 글이 있다면 별도 포트폴리오 문서보다 강하게 작동합니다. 신입과 주니어가 개인 프로젝트로 증명하려 할 때는 완성도의 기준선이 있습니다. 실제 배포까지 간 서비스, npm에 올려 다운로드와 이슈 대응 기록이 남은 라이브러리처럼 남이 확인할 수 있는 결과와 기록이 있어야 합니다. 로컬에서만 돌아가는 클론 코딩 목록은 몇 개를 쌓아도 담당자의 판단을 바꾸지 못합니다. 반대로 수백 페이지 레거시 마이그레이션이나 대규모 조직의 디자인 시스템 운영 같은 규모의 경험은 개인 프로젝트로 만들 수 없습니다. 이건 정직하게 회사 경력에서 보여줄 몫입니다. 포트폴리오에 없는 걸 부풀리기보다 증명 가능한 항목의 완성도를 올리는 쪽이 서류에서는 유리합니다.

정리하면

프론트엔드 개발자 이력서에서 담당자가 확인하는 건 기술 이름이 아니라 그 기술을 놓고 한 판단과 그 결과입니다. 도구를 왜 골랐는지, 성능을 어떤 지표로 얼마나 바꿨는지, 팀이 함께 쓰는 기반을 만들어봤는지, 남이 확인할 수 있는 결과물이 있는지가 그 판단을 읽는 자리입니다. 이 네 가지가 본문에 있으면 스택 목록은 짧아도 됩니다. 문제는 이런 재료가 이력서를 쓰는 시점에는 대부분 기억에서 사라져 있다는 점입니다. LCP를 몇 초에서 몇 초로 줄였는지 같은 숫자는 개선 직후가 아니면 복원하기 어렵습니다. GridResume를 만들면서 이 지점을 신경 썼습니다. 평소에 커리어 기록으로 한 줄씩 남겨두면 AI 작성 보조가 그 기록을 문제와 선택, 결과의 흐름으로 정리해 이력서 문장으로 다듬어줍니다. 이력서·포트폴리오 진단에서는 프론트엔드 직무 기준으로 지금 이력서에서 어떤 신호가 비어 있는지도 짚어드립니다. 스택 목록에 이름을 하나 더 얹는 것보다 이미 쓴 기술 하나에 선택의 이유와 결과를 붙이는 편이 서류에서는 훨씬 크게 작동합니다.