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

여기서 말하는 프론트엔드 개발자는 사용자가 브라우저나 앱 속 웹 화면(웹뷰)에서 보고 조작하는 화면을 코드로 만드는 개발자입니다. 서비스 화면을 만드는 일, 운영팀이 쓰는 백오피스를 만드는 일, 다른 프론트엔드 개발자가 쓰는 공통 컴포넌트와 개발 환경을 만드는 일이 여기에 들어갑니다. React Native나 Swift·Kotlin으로 앱 자체를 만드는 자리는 대개 모바일 개발자 공고로 나옵니다. Node.js로 API 서버까지 맡는 풀스택 자리라면 서버 쪽 경력은 따로 나눠 적습니다. 이 직무의 이력서에는 React, TypeScript, Next.js 같은 기술 이름을 길게 나열하고 그 아래 "React 기반 웹 서비스 개발", "프론트엔드 성능 최적화" 같은 줄을 붙이는 경우가 많습니다. 목록에 React를 적는 일은 누구나 할 수 있어서 담당자는 목록만으로 실력을 판단하지 않습니다. 담당자가 본문에서 확인하려는 것은 그 기술로 무엇을 판단했고 화면이 어떻게 달라졌는지입니다. 카카오페이의 프론트엔드 개발자(자산 서비스) 공고는 지원서 작성 팁에서 담당했던 업무를 단순히 나열하지 말고 목표를 달성하기 위한 노력이나 고민한 부분이 드러나도록 작성해 달라고 했습니다(2026년 10월 분석 기준).

백엔드 개발자·프로덕트 디자이너와 다른 점

프론트엔드 개발자는 백엔드 개발자, 프로덕트 디자이너와 같은 화면을 두고 일합니다. 그래도 세 직무의 결과물은 다릅니다.

• 백엔드 개발자: 화면이 부르는 API와 그 뒤의 데이터, 서버 성능
• 프로덕트 디자이너: 화면의 구조와 흐름, 그 설계를 고른 근거
• 프론트엔드 개발자: 그 설계를 사용자의 기기에서 실제로 돌아가게 만든 코드와 로딩·반응 속도·오류 처리·접근성처럼 화면이 동작하는 방식

그래서 프론트엔드 경력 문장의 결과 자리에는 사용자의 기기에서 화면이 어떻게 달라졌는지가 와야 합니다. 첫 화면이 뜨는 시간, 조작에 반응하는 시간, 화면 오류 비율, 같은 컴포넌트를 쓰는 화면의 수 같은 것입니다. 전환율이나 매출은 기획·디자인·마케팅이 함께 움직이는 숫자라서 그것만 있으면 지원자가 코드로 바꾼 것이 보이지 않습니다. 서버 쪽 경력을 적는 방법은 백엔드 개발자 이력서 작성법에서 볼 수 있습니다.

도구 이름보다 그 도구를 고른 이유

같은 React 경력 3년이라도 이력서에서 드러나는 수준은 크게 다릅니다. 차이는 어떤 도구를 썼느냐보다 왜 그 도구를 골랐는지가 적혀 있느냐에서 납니다. 상태 관리를 "Redux 사용"이라고만 적으면 담당자가 얻는 정보가 없습니다. 서버에서 받은 데이터는 TanStack Query로 캐싱하고 화면 안에서만 쓰는 상태는 Zustand로 분리했다고 적으면 서버 상태와 클라이언트 상태를 구분해 설계했다는 것이 드러납니다. 토스증권의 Frontend Developer 공고는 쓰는 기술을 소개하는 대목에서 React-Query, Recoil, Jotai로 서버와 클라이언트 상태 관리를 용도에 맞게 한다고 밝혔습니다. 렌더링 방식도 마찬가지입니다. Next.js를 썼다는 사실만으로는 부족합니다. "검색 유입이 중요한 페이지는 서버에서 렌더링하고(SSR) 내용이 거의 바뀌지 않는 페이지는 빌드할 때 미리 만들었다(SSG)"처럼 페이지마다 방식을 고른 근거가 있어야 도구를 이해하고 쓴 사람으로 보입니다. 카카오페이 공고는 Next.js 같은 도구로 SSR 환경을 구축·운영하며 SEO와 초기 로딩 성능을 개선해 본 경험을 우대합니다. 고른 이유에는 포기한 것도 들어갑니다. SSR로 첫 화면이 빨리 뜨게 했다면 늘어난 서버 부하와 캐시를 어떻게 다뤘는지까지 적어야 판단 전체가 보입니다.

성능 숫자에는 측정 조건을 붙인다

프론트엔드에서 전후 숫자가 가장 분명하게 남는 일이 성능입니다. 구글이 정한 지표도 있습니다. Core Web Vitals는 LCP(가장 큰 콘텐츠가 보이기까지의 시간), INP(한 페이지에서 일어난 조작 가운데 가장 느린 편에 드는 반응이 다음 화면에 그려지기까지의 시간), CLS(화면이 밀리는 정도) 세 가지입니다. "페이지 로딩 속도 개선"은 검증할 방법이 없는 문장입니다. "첫 화면 밖 이미지는 지연 로딩하고 대표 이미지는 preload하고 코드 스플리팅으로 첫 번들을 줄여 LCP를 4.1초에서 1.8초로 줄였습니다"처럼 숫자가 있어도 담당자는 어느 기기와 네트워크에서 잰 값인지를 묻습니다. 개발자 PC에서 Lighthouse로 잰 값(실험실 데이터)과 실제 사용자 기기에서 모은 값(현장 데이터)은 크게 다를 수 있기 때문입니다. INP는 사용자의 실제 조작이 있어야 잴 수 있어서 주로 현장 데이터로 봅니다. 그래서 숫자에는 측정 도구와 기기, 기준과 기간을 함께 적습니다. 현장 데이터라면 "모바일 사용자 기준 배포 전후 각 4주간 p75"처럼 조건을 밝히면 됩니다. 공고에도 성능 경험이 나옵니다. 토스증권 공고는 브라우저 렌더링 성능을 고려해 개발하고 최적화한 경험이 있는 사람을 찾는다고 적었습니다. 레브잇의 [올웨이즈] Frontend Platform Engineer 공고는 웹이나 앱의 렌더링, 메모리, 번들 사이즈 최적화를 직접 해 본 경험을 자격 요건으로 요구했습니다. 컬리의 커머스 시니어 프론트엔드 개발자 공고는 웹서비스의 정량적 성능 평가와 최적화 경험을 우대합니다. 번들 크기를 줄였다면 몇 KB에서 몇 KB(gzip 기준)로 줄었고 그 결과 어떤 지표가 달라졌는지, 리렌더를 줄였다면 어떤 조작을 무엇으로 쟀는지까지 씁니다. 배포 뒤 화면 오류를 Sentry 같은 도구로 모아 오류 비율을 얼마나 낮췄는지, E2E 테스트로 어떤 핵심 흐름의 회귀를 막았는지도 같은 방식으로 숫자를 남깁니다.

접근성은 구현한 것과 확인한 방법으로

"반응형·웹 표준 준수" 수준의 서술로는 다른 지원자와 차이가 나지 않습니다. 접근성 경험이 있다면 무엇을 구현했고 무엇으로 확인했는지를 적어야 합니다. 시맨틱 마크업으로 화면 구조를 잡았는지, 모달과 드롭다운에서 키보드 포커스가 어디로 가는지 처리했는지, 오류 메시지를 스크린 리더가 바로 알려 주게 했는지(aria-live) 같은 것입니다. 확인 방법은 axe나 Lighthouse 같은 자동 검사와 VoiceOver·TalkBack으로 흐름을 끝까지 따라가 본 수동 검사를 나눠 씁니다. 자동 검사로는 못 잡는 문제가 많기 때문입니다. 기업 채용 분석의 프론트엔드 개발자 공고 18건 가운데 5건이 지원자에게 바라는 조건에 접근성을 적었습니다. 카카오페이 공고는 W3C 웹 표준과 웹 접근성에 대한 높은 이해도를 자격 요건으로 요구하고 스크린 리더 사용자처럼 다양한 환경의 사용자를 고려해 서비스를 개선한 경험을 우대합니다. 페이타랩의 Web Frontend Developer 공고는 반응형 디자인·웹 접근성·웹 표준을 적용해 본 사람을 찾습니다. 결과도 숫자로 남길 수 있습니다. 주요 흐름 몇 개를 스크린 리더로 끝까지 진행할 수 있게 됐는지, 자동 검사 위반이 몇 건에서 몇 건으로 줄었는지, 새 코드에도 검사가 돌게 했는지입니다.

공통 컴포넌트는 몇 팀이 어떻게 쓰게 됐는지

공통 컴포넌트나 디자인 시스템을 만든 경험은 혼자 화면을 만드는 단계를 지나 팀이 함께 쓰는 기반을 만드는 단계로 넘어갔다는 신호입니다. NHN Link의 FE개발 담당 공고는 재사용 가능한 공통 UI 컴포넌트를 설계하고 사내 표준으로 만드는 일을 업무로 적었습니다. 쿠팡페이의 Staff Front-end Engineer (Rocket Pay) 공고는 가용성, 확장성, 재사용성이 높은 UI 컴포넌트를 만든 경험을 자격 요건으로 요구했습니다. 디자인 시스템에서 색과 글꼴, 간격 같은 규칙과 컴포넌트의 모양은 디자이너와 함께 정합니다. 프론트엔드 개발자의 경력은 그 규칙을 디자인 토큰(CSS 변수·테마)으로 옮기고 컴포넌트를 쓰는 방법을 설계한 부분입니다. 여기에 들어가는 것은 props를 어떻게 설계해 여러 화면의 변형을 한 컴포넌트로 받았는지, 키보드 조작과 접근성 속성을 컴포넌트 안에서 처리해 쓰는 사람이 따로 신경 쓰지 않게 했는지, Storybook 문서와 테스트, 버전 관리와 배포를 어떻게 했는지입니다. 결과는 몇 개 팀, 몇 개 화면이 그 컴포넌트를 쓰게 됐고 무엇이 줄었는지로 씁니다. 토스증권 공고는 이력서 작성 안내에서 복잡하거나 반복되는 문제를 단순한 형태로 추상화한 경험을 설명해 달라고 했습니다. 여러 화면에서 반복되던 코드를 컴포넌트 하나로 묶은 일이 그런 경험입니다. 규모가 작아도 괜찮습니다. 버튼과 폼 몇 개라도 팀마다 따로 만들던 것을 하나로 모아 작업 방식을 바꿨다면 경력이 됩니다. 디자이너 쪽에서 무엇을 적는지는 프로덕트 디자이너 이력서 작성법에서 볼 수 있습니다.

같은 경력을 이렇게 적으면

강한 문장에는 어떤 화면의 어떤 문제였는지, 원인을 무엇으로 확인했는지, 지원자가 어떤 방법을 골랐는지, 결과를 어떤 숫자와 조건으로 쟀는지가 들어 있습니다. 같은 React와 Next.js를 썼더라도 강한 문장에서는 지원자가 그 화면에서 무엇을 판단했는지가 드러납니다.

자리마다 보여 줄 경험

같은 프론트엔드 공고라도 어떤 화면을 만드는 자리냐에 따라 이력서에서 보여 줄 경험이 다릅니다. 앱 안의 웹 화면을 만드는 자리에서는 네이티브 앱과 연결한 경험이 경력이 됩니다. 토스증권 공고는 Android, iOS 앱의 웹뷰에서 동작하는 모바일 제품과 PC 브라우저용 데스크탑 제품, 백오피스를 만드는 일을 업무로 적었습니다. 메가존의 [MZD] 프로젝트 투입 Web/Front-End 공고는 iOS WKWebView와 Android JavaScript Interface 구조를 바탕으로 Web↔Native Bridge 인터페이스를 설계·개발하는 일을 업무로 꼽았습니다. 이런 자리라면 브릿지로 무엇을 주고받았는지, 앱 버전마다 다른 동작을 어떻게 처리했는지, 웹뷰에서 난 오류를 어떻게 모아 봤는지를 보여 주면 됩니다. 프론트엔드 플랫폼 자리는 화면보다 다른 개발자가 쓰는 환경을 만듭니다. 레브잇의 Frontend Platform Engineer 공고는 이 포지션이 새로운 화면을 만드는 역할이 아니라고 밝혔습니다. 대신 SRE와 협업해 빌드 시간 단축부터 배포까지 이어지는 프론트엔드 CI/CD 파이프라인을 설계하는 일을 맡깁니다. 플랫폼 자리라면 빌드와 CI 시간, 번들 크기가 커지는 PR을 미리 막은 건수처럼 동료 개발자의 작업이 어떻게 달라졌는지를 숫자로 씁니다. 배포 플랫폼과 인프라 자체를 맡았다면 DevOps·SRE 엔지니어 이력서 작성법도 함께 참고하면 좋습니다. 백오피스는 쓰는 사람이 회사 안에 있습니다. 페이타랩 공고의 업무에는 내부 구성원이 반복 작업 없이 빠르게 운영하도록 돕는 백오피스 개발이 들어 있습니다. 백오피스 경력은 운영자의 작업 시간이나 처리 건수가 어떻게 달라졌는지로 보여 줍니다.

연차에 따라 달라지는 포트폴리오의 역할

프론트엔드는 결과물이 눈에 보이는 직무라 포트폴리오 이야기가 많이 나옵니다. 신입에게는 회사 경력이 없으니 포트폴리오가 판단 근거의 대부분이지만 경력직에게는 경력기술서가 본체이고 포트폴리오는 보조 증거입니다. 경력직이라면 참여한 서비스의 실제 URL과 그 안에서 맡은 화면, 성능 개선 과정을 숫자와 함께 정리한 기술 글이 포트폴리오 역할을 합니다. 회사 코드와 공개되지 않은 화면은 포트폴리오로 내지 않습니다. 직접 만든 라이브러리나 오픈소스 기여가 있다면 GitHub 링크와 함께 씁니다. 뤼튼테크놀로지스의 Frontend Engineer 공고는 주간 평균 다운로드 수가 100회에 근접하는 오픈소스 라이브러리에 기여해 본 경험과 LOC 10,000 이상의 TypeScript, JavaScript 라이브러리를 직접 작성해 본 경험을 우대합니다. 서류 다음에 코드를 직접 보는 단계를 두는 공고도 있습니다. 토스증권과 뤼튼테크놀로지스 공고는 서류 다음이 과제 전형이고, 카카오페이와 NHN Link 공고는 1차 인터뷰에서 라이브 코딩을 합니다. NHN Link의 라이브코딩은 바닐라 JavaScript로 구현하는 테스트라 프레임워크 없이 짜는 연습도 필요합니다.

회사에서 해 볼 기회가 없을 때 만들 수 있는 것

신입·주니어이거나 지금 회사에서 성능이나 접근성을 다룰 일이 없었다면 직접 만들 수 있는 것이 있습니다. 기준은 남이 확인할 수 있는 결과와 기록입니다.

• 실제로 배포해 사용자가 쓰는 서비스(접속 주소, 사용자 수, 오류 모니터링 기록 포함)
• npm에 올려 다운로드와 이슈 대응 기록이 남은 라이브러리
• 지금 맡은 화면을 Lighthouse와 실사용자 데이터로 재고 원인을 찾아 고치기 전후를 비교한 기록
• 서비스의 주요 흐름을 키보드와 스크린 리더로 끝까지 따라가 보고 고친 기록

로컬에서만 돌아가는 클론 코딩은 몇 개를 만들어도 담당자의 판단을 바꾸기 어렵습니다. 공고의 경력 요건도 실제 사용자가 쓰는 제품을 기준으로 합니다. 당근의 Software Engineer, Frontend - 로컬 잡스 공고는 React 기반으로 실제 사용자가 쓰는 제품을 3년 이상 만들어 본 사람(또는 그에 준하는 역량을 가진 사람)과 함께하고 싶다고 밝혔습니다. 반대로 수백 페이지 규모의 레거시 마이그레이션이나 여러 팀이 쓰는 디자인 시스템 운영은 개인 프로젝트로 만들 수 없습니다. 이런 경험은 회사 경력으로만 보여 줄 수 있습니다. 없는 경험을 부풀리기보다 증명할 수 있는 항목을 자세히 쓰는 편이 서류에서 유리합니다.

배포한 날 숫자를 남겨 둔다

LCP를 몇 초에서 몇 초로 줄였는지, 그때 왜 그 렌더링 방식을 골랐는지는 작업 직후가 아니면 다시 찾기 어렵습니다. 성능 대시보드와 QA 기록은 회사 도구 안에 있어서 회사를 옮기면 볼 수 없습니다. 그래서 개선 작업을 배포한 날 바꾼 것과 측정한 숫자를 몇 줄로 남겨 두는 것이 좋습니다. 무엇을 왜 골랐는지, 어느 기기에서 어떤 기준으로 쟀을 때 숫자가 어떻게 달라졌는지만 적어도 충분합니다. 회사 밖에 적어도 되는 숫자인지는 보안 규정에서 먼저 확인합니다. GridResume 커리어 기록에 이렇게 남기고 해당 경력·프로젝트에 연결해 두면 AI가 그 기록을 문제와 선택, 결과의 흐름으로 정리해 이력서 문장으로 다듬어 줍니다.

정리하면

프론트엔드 개발자 이력서에 들어가야 할 것은 다섯 가지입니다.

• 도구와 렌더링 방식을 왜 골랐고 무엇을 포기했는지
• 성능을 어떤 지표로, 어느 기기와 기준에서 얼마나 바꿨는지
• 접근성을 어떻게 구현하고 무엇으로 확인했는지
• 공통 컴포넌트를 몇 개 팀과 화면이 쓰게 됐는지
• 연차에 맞게 남이 확인할 수 있는 결과물이 있는지

공고 자격 요건에 적힌 기술은 목록에서 빼지 않습니다. 다만 목록에 기술 이름을 하나 더 얹는 것보다 이미 쓴 기술 하나에 고른 이유와 측정한 숫자를 붙이는 편이 서류에서 훨씬 큰 차이를 만듭니다.