프론트엔드 개발자 = 리액트 개발자 ?
이 물음은 이제 개발 업계에서 거의 반사적으로 거의 그렇다라는 대답을 받는다.
프론트엔드 채용 공고나, 강의, 교육 부트캠프, 심지어 바이브 코딩을 시작한다 하고 "...프로젝트 만들어 줘"라고 프롬프트를 작성하면 AI는 React 프로젝트로 작성을 해준다... 이런 걸 보면 리액트는 사실상 프론트엔드의 디폴트가 되지 않았나... 싶다..
[항해 플러스 프론트엔드] 6주차 회고(챕터2 종료) - 튜닝의 끝은 순정이다
이전 주차 포스팅 2025.05.02 - [항해99 플러스/회고] - [항해 플러스 프론트엔드] 4주차 회고 - 화요일의 저주 { sel.value = 'p1'; ad" data-og-host="s-o-o-min.tistory.com" data-og-source-url="https://s-o-o-min.tistory.com/entry/
s-o-o-min.tistory.com
위는 필자가 항해 플러스 교육과정을 밟았을 때 작성했던 회고 글이다. React는 결국 Js의 라이브러리일 뿐 결국은 Js를 잘해야한다 라는 생각을 가져왔고 지금도 그렇게 생각하고 있다.
그런데 현실에선 결국은 React를 잘해야만 프론트엔드 개발자의 길을 걸을 수 있는 것인가 의문이 생겼다.
정말 프론트엔드가 곧 React일까? 그리고 이 현상은 앞으로도 유지 될까?
1. 프론트엔드의 원래 의미
프론트엔드는 단순히 "화면을 만든다" 이상의 역할을 가진다고 생각한다.
브라우저라는 제한된 환경에서 최고의 사용자 경험(UX)을 구현하는 모든 영역을 아우른다. (개인적인 생각으로 이 부분은 프롬프트 작성을 할 때 정말 명확히 설명하지 않는 한 AI로 대체가 힘들다고 생각한다.)
- 기초 기술: HTML, CSS, JavaScript
- UX 완성도: 반응형 웹, 접근성(A11y), 국제화(i18n)
- 성능: 네트워크 최적화, 렌더링 최적화, Web Vitals
- 관리 플랫폼 API: Service Worker, WebSocket, WebGPU, WebAssembly
- 도구 체계: 빌드, 번들링, 테스트, 배포
리액트는 이 중 UI 렌더링을 돕는 하나의 라이브러리일 뿐이다. 그럼에도 현재 시장에서 React가 FE 그 자체처럼 인식이 되는 이유는 무엇일까...
2. 왜 FE ?? 'React' 가 되었는가
2-1 컴포넌트 기반의 표준화
2013년 등장 당시 React의 컴포넌트 기반 접근법은 단순히 “코드를 잘게 나눈다” 수준을 넘어, UI를 재사용 가능하고 예측 가능하며 독립적으로 테스트할 수 있는 모듈로 구조화하는 방법을 제시했다.
기존 jQuery나 Vanilla JS 시절의 DOM 직접 조작은 데이터 변경이 있을 때마다 화면 갱신 로직을 직접 건드려야 했다. 반면 React는 `상태(state) → 화면(view)`의 단방향 데이터 흐름을 채택해, 상태 변경만으로 화면이 자동 업데이트되도록 했다.
컴포넌트는 입력(props)과 출력(UI)이 명확히 분리돼 재사용, 테스트, 유지보수가 용이했고, 이 구조는 이후 Vue, Angular 등 다른 프레임워크에도 영향을 주며, “컴포넌트 기반 개발”이라는 패러다임을 프론트엔드의 표준으로 자리잡게 만들었다.
2-2 대규모 서비스에서의 검증
React의 신뢰도는 기술 자체의 장점뿐 아니라, 대규모 트래픽 환경에서 검증되 었기 때문에 신뢰가 급상승하지 않았나 싶다.
Facebook이나 Instagram은 수억 명이 매일 이용하는 서비스인데, React는 이 환경에서 안정적으로 동작하고, 사용자에게 빠른 UI 반응성이나 높은 개발 생산성을 보여줬다.
이러한 실전 검증은 신규 서비스나 스타트업이 프레임워크를 선택할 때 안정적인 선택지로 React를 고르는 결정적인 요인이 아닐까 싶다.
2-3 생태계의 확장
React의 생태계는 단순한 UI 라이브러리를 넘어섰고, 하나의 거대 플랫폼 수준까지 올라가지 않았나 싶다.
- Next.js, Remix: 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 라우팅, API 연동까지 통합 지원
- React Native: 모바일 앱까지 코드 재사용을 확장
- 상태 관리: Redux, Zustand, Jotai 등 다양한 옵션
- 데이터 패칭: TanStack Query, SWR 등 비동기 데이터 관리 도구
결과적으로 React를 사용하게 되면 웹·모바일·SSR·데이터 관리까지 프론트엔드 대부분의 요구사항을 처리할 수 있다.
2-4 교육과 학습의 표준화
위에서도 언급했듯이 React는 단순히 업계에서 쓰이는 기술을 넘어, 프론트엔드 학습의 기본 커리큘럼이 됐다.
필자는 처음 개발을 접했을 때 Java로 시작해 Vue에 매력에 빠져 Vue를 독학으로 학습했는데, 그때나 지금이나 Vue 커리큘럼의 부트캠프는 거의 보이질 않는다.
국내외 부트캠프나, 온라인 강의, 심지어는 대학 커리큘럼에서 초급자 교육 중심이 React로 고정되어 있어, 학습자들이 첫 프레임워크로 접하는 경우가 대부분이라고 한다.
채용 시장이 React 인력을 선호하고, 학습 자료도 풍부하니 수요와 공급이 서로를 강화하며 React는 사실상 프론트엔드 입문 표준이 되었다.
3. 온 세상이 React
국내 IT 대기업과 유망 스타트업의 채용 공고를 살펴보면, 프론트엔드 포지션의 대부분이 React를 요구한다. 카카오, 네이버, 토스, 당근마켓, 쿠팡 등 주요 기업들은 React 또는 React 기반 스택(Next.js 포함)을 사실상 표준처럼 사용한다.
해외도 마찬가지로 GitHub Octoverse, Stack Overflow Developer Survey에서 수년째 프론트엔드 프레임워크/라이브러리 1위를 유지 중이다.
아래 그래프는 249명의 개발자분들이 참여한 설문 그래프이며, React가 압도적으로 많은 것을 알 수 있다.
이는 단순 유행이 아니라, 이미 팀과 조직, 생태계 전체가 React에 맞춰 구조화되고 있다는 의미다.
이렇게 온 세상이 React화된 현재 상황에서, 취업 준비생이든, 이직을 준비하는 개발자든, React를 전혀 모른다는 것은 곧 시장 경쟁에서 자발적으로 빠져나는 것과 다름없다.
물론 React가 전부는 아니지만, 2025년의 채용 시장에서 React 경험은 더 이상 선택이 아닌 진입하는 입구에 가깝다고 생각한다.
4. 하지만 React가 FE의 전부는 아니다
React는 분명 좋은 도구지만, 도구가 개발자의 전부는 될 수 없다고 생각한다. 프로젝트를 진행하다 보면, React가 아닌 영역에서 답을 찾아야 하는 순간은 매번 찾아온다.
- 프로덕트의 성공은 기술 스택이 아니라 경험에서 나온다.
- 빠른 초기 로드, 부드러운 인터랙션, 명확한 정보 구조… 이런 것들은 React로 구현할 수 있지만, React 자체가 보장해주는 것은 아니다. 예를 들어, 쇼핑몰의 구매율을 높이는 데 필요한 건 프레임워크가 아니라 결제 흐름의 단순화, 이미지 최적화, 로딩 시간 단축 같은 UX 개선이다.
- 사용자는 React를 썼는지도 모른다.
- 사용자는 버튼이 눌린 뒤 화면이 빠르게 반응하는지, 스크롤할 때 버벅임이 없는지, 레이아웃이 잘 배치되어 있는지 이런 상호작용이 잘되는지가 전부다. 그 과정에서 React, Vue, Svelte를 썼는지는 사용자 관심사가 아니다. 오히려 개발자가 React 내부 최적화에 몰두하느라, UX 테스트나 접근성 검증을 소홀히 하면 본질에서 멀어지지 않을까..
- 기술은 변하지만 문제는 남아있다.
- `WebSocket`, `WebGPU`, `PWA` 같은 브라우저 기능이 늘어날수록, 우리는 프레임워크, 라이브러리 밖의 영역과 마주해야 한다. 그 의존도가 높으면 높을수록 계속해서 늘어나는 브라우저 기능에 적응이 늦어질 수 밖에 없다.
5. 우리 FE 개발자가 가져야 할 관점
React를 잘쓰는지 못쓰는지를 판단하는 것은 이미 경쟁력 있는 스펙은 아니라고 생각한다. 진짜 경쟁력은 넓은 시야나 다양한 선택지에서 나오는 것이 아닐까 생각한다.
"React로 만들 수 있는가?" 보다는 "이 문제를 가장 단순하고 안정적으로 풀 수 있는 방법은 무엇인가?"가 먼저 나와야 한다. 단순한 랜딩 페이지라면 Js로 끝낼 수도 있고, 무거운 클라이언트 렌더링이라면 SSR이 더 적합하니 SSR을 채택하는 것처럼, 기술보다는 문제를 쉽게 해결할 수 있는 기술을 사용하는 것이 중요하다. React는 그 기술 중 하나인 것 뿐이다.
프레임워크는 결국 HTML/CSS/JS 위에서 동작한다. DOM구조, 브라우저 렌더링 파이프라인, 이벤트 버블링, CSS 레이아웃 등등 정말 기본적인 것들만 이해하면 어떤 프레임워크나 라이브러리를 써도 빠르게 적응할 것이다. 기본기가 탄탄하면 새로운 프레임워크나 런타임 환경을 배울 때 언어만 바뀐 것처럼 느껴지기 때문에 기본기는 절대 잃으면 안된다.
Angular의 전성기는 약 6~7년간 이어졌고, 그 뒤를 React가 지금까지 주도해왔다. 최근에는 Svelte, Solid, Qwik이 더 빠른 초기 로드와 최소한의 런타임을 무기로 등장했고, WebAssembly 기반 UI 프레임워크도 서서히 주목받고 있다.
이런 기술들은 몇 년 전부터 “React의 대항마”라는 이름으로 소개되었지만, React 역시 그동안 가만히 있지 않았다. 물론 React만 사용하라는 뜻은 아니다.
다만, 프론트엔드 프레임워크는 지금도 계속 진화하고 있으며, 이 변화에 대비하는 사람과 그렇지 않은 사람의 격차는 기술을 배운 속도가 아니라 변화를 받아들이는 속도에서 갈린다고 생각하기 때문에, 계속해서 React에만 기대고 있는 것은 좋은 생각이 아니라는 말을 하고싶다.
React는 FE의 도구일 뿐이다
2025년 현재, 프론트엔드 개발은 여전히 React 중심으로 돌아간다. 그러나 프론트엔드의 본질은 특정 기술이 아니라, 브라우저에서 최고의 경험을 만드는 능력이다.
React는 그 목표를 달성할 수 있는 수많은 방법 중 하나일 뿐이다. 물론 그 도구를 잘 다루는 역량은 중요하지만, 도구에 종속되지 않고 문제를 정의하고 해결하는 능력을 유지하는 것이 더 오래 가는 가치라고 생각한다.
기술은 늘 유행 주기에 따라 바뀌었다. jQuery의 시대가 지나고, Angular의 전성기가 끝났듯이, React도 언젠가는 주류 자리에서 내려올 것이다.
하지만 세대가 바뀌어도 변하지 않는 것은 문제 해결 능력이고, 그것이 개발자의 가장 오래가는 자산이다. 이제 여기에 새로운 패러다임이 빠르게 스며들고 있다.
바로 AI다. 코드 자동 생성, 디자인-개발 간 간극 축소, 접근성 개선, 성능 최적화 제안… AI는 이미 프론트엔드 개발의 많은 부분을 보조하거나 대체하기 시작했다.
과거엔 “이 기술 스택을 얼마나 잘 다루는가?”가 평가 기준이었다면, 앞으로는 “AI를 어떻게 활용해 더 나은 제품 경험을 만드는가?”가 경쟁력을 가르는 척도가 될 가능성이 크다.
실제로 채용 공고를 보면, Cursor나 Copilot 같은 AI 도구를 기술 스택이나 우대 요건으로 명시하는 사례가 간간히 보인다.
이는 단순히 새로운 툴을 배운다는 차원을 넘어, 개발자의 일하는 방식 자체가 바뀌고 있음을 보여주는 신호다. 따라서 미래의 프론트엔드 개발자는 단순히 프레임워크를 잘 다루는 사람을 넘어, 기술 변화와 AI를 결합해 더 빠르고 정확하게 문제를 해결할 수 있는 사람이어야 한다.
React 이후의 세상뿐 아니라, AI와 함께 진화하는 프론트엔드 생태계를 준비하는 것이 곧 다음 시대의 필수 역량이다. 결국, 기술은 사라질 수 있지만, 변화에 적응하는 힘은 사라지지 않는다.
앞으로의 경쟁력은 새로운 프레임워크를 얼마나 빨리 배우는지가 아니라, 변화를 얼마나 유연하게 받아들이고, 그것을 실제 문제 해결에 어떻게 녹여내는지에 달려 있다.
그 변화의 흐름 속에서, AI와 함께 문제 해결의 지평을 넓히는 개발자가 진짜 오래 살아남지 않을까 생각한다.
마치며
이 글을 읽는 현직 개발자 분들, 취업 준비하시는 분들 읽느라 고생하셨습니다.
요즘 프론트엔드 취업 시장이 쉽지 않습니다. 다른 업계도 마찬가지겠지만..
새로운 기술은 매일 쏟아지고, 채용 공고는 줄어드는 것 같고, 서류 합격의 벽은 넘기도 힘든 거 같고, 막상 서류 합격해도 면접 과정마저 길고 치열하고,
그러다 보면 ‘내가 가고 있는 길이 맞나’ 하는 생각이 들 때도 있습니다. 하지만 기술의 유행은 바뀌어도, 문제를 정의하고 해결하는 힘은 쉽게 사라지지 않는다고 생각합니다.
그 힘을 키우고 유지하는 사람은 어떤 환경에서도 다시 기회를 만나지 않을까요?
React 이후의 변화든, AI든 뭐든 결국 그 흐름을 타는 건 우리가 가진 시야와 태도라고 생각합니다.
지금은 속도가 느린 것 같아도, 차곡차곡 쌓은 기본기와 경험은 어느 순간 큰 힘을 발휘할 것이고, 화면 하나, 버튼 하나에도 ‘사용자를 위한 경험’을 담으려는 개발자는 반드시 살아남는다고 믿고 있습니다.
여러분이 지금 배우고 고민하는 모든 순간은, 곧 미래의 경쟁력이 될 거라고 믿고, 지치지 말고, 포기하지 마시길 바랍니다.
'밥줄 > React' 카테고리의 다른 글
[React] React 학습 (9) - Hooks (Hook의 규칙, Custom Hook) (0) | 2025.01.08 |
---|---|
[React] React 학습 (8) - Hooks (useMemo, useCallback, useRef) (4) | 2024.11.05 |
[React] React 학습 (7) - Hooks (useState, useEffect) (2) | 2024.11.04 |
[React] React 에러 해결 - Component Key (2) | 2024.11.04 |
[React] React 학습 (6) - State & Lifecycle (2) | 2024.11.04 |