처음 프런트엔드를 공부할 때 솔직히 React만 잘하면 되는 거 아닌가?라고 생각했습니다.
화면을 예쁘게 만드는 직무라는 이미지가 강했기 때문입니다. 그런데 실제로 프로젝트를 해보니 생각이 완전히 달라졌습니다.
프런트엔드 개발자에게는 화면 구현 이상의 것이 요구된다는 것, 지금부터 제 경험을 바탕으로 풀어보겠습니다.
프런트엔드 기본기 - React보다 먼저였어야 할 것들
혹시 이런 경험 있으신가요? 프레임워크로 화면을 뚝딱 만들었는데, 정작 레이아웃이 왜 깨지는지 원인을 못 찾아 한참을 헤매는 경험. 저는 있습니다. 제가 직접 겪어보니 React를 먼저 배운 것이 꼭 좋은 순서는 아니었습니다.
프런트엔드의 뿌리는 결국 시맨틱 HTML(Semantic HTML), CSS, JavaScript입니다. 여기서 시맨틱 HTML이란 단순히 태그로 화면을 구성하는 것이 아니라, 콘텐츠의 의미와 구조를 정확히 전달하는 태그를 선택해 작성하는 방식을 말합니다.
예를 들어 모든 구조를 div로만 쌓는 것이 아니라, 내비게이션에는 nav, 주요 콘텐츠에는 main, 글 제목에는 h1을 쓰는 식입니다. 이 차이가 검색 엔진 최적화(SEO)와 웹 접근성에 직결됩니다.
MDN 웹 문서(MDN Web Docs)에서 제시하는 프런트엔드 커리큘럼도 시맨틱 HTML, CSS, JavaScript 기초를 가장 먼저 다루고 있으며, 현업 피드백으로 프레임워크 사용에만 집중하고 기본 기술 이해가 부족한 신입이 문제로 자주 지적된다고 명시하고 있습니다.
이 말이 단순한 조언처럼 들릴 수 있지만, 저는 이게 꽤 날카로운 지적이라고 느꼈습니다.
프런트엔드 개발자에게 기본기가 중요한 이유를 정리하면 다음과 같습니다.
- 프레임워크가 바뀌어도 기본 원리를 이해하면 적응 속도가 빠릅니다
- 화면 오류의 원인을 HTML, CSS, JavaScript 수준에서 직접 추적할 수 있습니다
- 시맨틱 마크업(Semantic Markup)은 SEO와 접근성 두 가지를 동시에 챙길 수 있습니다
- 기본기를 설명할 수 있어야 기술 면접에서도 설득력이 생깁니다
결국 React를 써봤다는 말보다 왜 이 컴포넌트를 이렇게 나눴는지, CSS는 어떻게 관리했는지를 설명할 수 있는 사람이 더 단단한 개발자로 보입니다. 이 부분은 제가 프로젝트를 돌아보면서 가장 많이 반성한 부분이기도 합니다.
프런트엔드 문제해결 - 화면이 잘 보인다는 것의 진짜 의미
화면이 잘 만들어졌다는 건 어떤 의미일까요? 단지 디자인대로 구현됐다는 뜻일까요? 저는 이 질문을 프로젝트 중반쯤에 처음 진지하게 떠올렸습니다.
실제로 팀 프로젝트에서 반응형 레이아웃(Responsive Layout) 문제가 터졌을 때, 처음에는 모바일에서 왜 이게 깨지지?라는 단순한 의문으로 시작했습니다. 반응형 레이아웃이란 화면 크기에 따라 콘텐츠 배치와 요소 크기가 자동으로 조정되는 구조를 말합니다.
미디어 쿼리(Media Query)를 통해 특정 뷰포트(Viewport) 너비 이하에서 스타일이 달리 적용되도록 분기하는 방식이 대표적입니다. 문제를 찾아보니 미디어 쿼리 기준값 하나가 잘못 설정돼 있었고, 그걸 추적하는 데 예상보다 훨씬 긴 시간이 걸렸습니다. 기본 CSS 구조에 대한 이해가 부족했기 때문이었습니다.
여기에 더해 웹 접근성(Web Accessibility) 이슈도 생각보다 자주 등장합니다.
웹 접근성이란 장애가 있거나 보조 기술을 사용하는 사람들도 불편 없이 웹 콘텐츠를 이용할 수 있도록 보장하는 기준입니다.
예를 들어 스크린 리더(Screen Reader) 사용자가 버튼의 역할을 인식할 수 있도록 aria-label 속성을 붙이는 것, 혹은 키보드만으로도 메뉴 이동이 가능하도록 포커스 순서를 관리하는 것이 이에 해당합니다. 솔직히 이건 예상 밖이었습니다. 처음에는 접근성이 장애인을 위한 선택사항 정도로 인식했는데, 실제로는 HTML 태그 하나를 잘못 쓰는 것만으로도 접근성이 무너질 수 있다는 점이 충격적이었습니다.
성능 최적화도 빠질 수 없습니다. 웹 성능(Web Performance)이란 페이지가 얼마나 빨리 로드되고, 사용자 입력에 얼마나 빠르게 반응하는지를 측정하는 개념입니다.
이미지 지연 로딩(Lazy Loading), 불필요한 리렌더링 방지, 번들 사이즈(Bundle Size) 최적화 같은 작업이 여기에 포함됩니다. NCS(국가직무능력표준) 기반 직무 자료에서도 프런트엔드 개발자의 역량으로 소프트웨어 성능 평가와 유지보수를 명시적으로 다루고 있습니다.
제 경험상 이런 문제들은 프레임워크를 알고 있다는 것만으로는 절대 해결이 안 됩니다.
오히려 기본 원리를 얼마나 이해하고 있느냐가 문제 해결 속도를 결정합니다. 기업이 어떤 라이브러리를 써봤냐 보다 문제가 생겼을 때 어떻게 접근했냐를 더 깊이 파고드는 이유가 여기에 있다고 봅니다.
프런트엔드 협업 - 코드를 짜는 것만이 일이 아니었다
혼자 개발하다 보면 잘 안 느끼지만, 팀 작업에서는 전혀 다른 역량이 요구됩니다.
내가 만든 화면을 디자이너에게 설명하고, 백엔드 API 응답 구조에 맞게 프런트 로직을 조율하고, 변경 이력을 Git으로 관리하는 일련의 과정들이 사실 개발만큼 중요합니다.
저는 팀 프로젝트에서 처음으로 Git 브랜치(Branch) 전략을 제대로 써봤을 때 당황했던 기억이 있습니다.
버전 관리(Version Control)란 코드 변경 이력을 추적하고, 여러 사람이 동시에 같은 프로젝트를 수정할 수 있도록 관리하는 시스템입니다. Git은 그중 가장 널리 쓰이는 분산 버전 관리 도구로, 브랜치를 나눠 작업하고 병합(Merge)하는 방식으로 협업 충돌을 줄입니다. 혼자 쓸 땐 그냥 커밋만 했는데, 팀으로 작업하니 브랜치 네이밍 규칙부터 PR(Pull Request) 메시지 작성까지 신경 써야 할 것들이 생각보다 많았습니다.
그리고 설명하는 능력이 이렇게까지 중요한지도 처음엔 몰랐습니다.
제가 직접 경험해 보니, 내가 왜 이 컴포넌트를 이렇게 분리했는지, 어떤 API 응답 구조를 가정하고 설계했는지를 말로 설명할 수 없으면 팀 전체의 흐름이 막히는 경우가 생깁니다. MDN 커리큘럼도 버전 관리와 협업 소프트 스킬을 프런트엔드 핵심 역량으로 명시하고 있는데, 이게 단순한 추가 스킬이 아니라 실무의 기본 조건이라는 것을 팀 작업을 통해 체감했습니다.
결국 프런트엔드 개발자는 코드를 잘 짜는 것과 그 코드를 팀 안에서 함께 완성하는 것, 이 두 가지를 동시에 할 수 있어야 합니다. 신입이라면 기술 스택 목록을 길게 나열하는 것보다, 프로젝트에서 어떤 문제를 어떻게 팀과 함께 풀었는지를 설명할 수 있는 편이 훨씬 설득력 있다고 생각합니다.
지금 돌이켜보면, 프런트엔드 개발자를 준비하는 데 있어 가장 중요한 것은 빠른 출발보다 단단한 토대입니다. 기본기를 갖추고, 문제를 추적하는 습관을 기르고, 협업 흐름에 익숙해지는 것. 이 세 가지가 쌓이면 프레임워크가 바뀌어도 흔들리지 않는 개발자가 될 수 있다고 저는 믿습니다. 아직 배우는 중이지만, 그 방향만큼은 틀리지 않았다고 느끼고 있습니다.