프론트앤드에 대한 소문들의 진위가 궁금합니다.

안녕하세요, 프론트엔드 풀타임 3년 백엔드 풀타임 1년 반 경력이 있는 프론트엔드 개발자입니다. 질문에 대한 답변을 드리자면 1. 네. 백엔드에 비해 진입장벽이 낮은것은 사실입니다. 아무 튜토리얼만 잡고 시작해도 금방 따라할 수 있습니다. 대신 이 진입장벽이 낮다 == 쉽게 마스터할 수 있다 는 아닙니다. 2. 아니요. 높은 연차일수록 능력있다는 뜻은 아니지만, 경험이 많을 수록 문제상황을 마주했을 때 쉽게 풀어갈 힘이 생깁니다. 물론 마주해온 경험들을 내 것으로 만든 개발자일때 말이죠. 3. 네, 아니요. 프론트엔드 쪽이 제 경험상으로도 라이브러리 메이저 업데이트도 잦고, 언어 자체도 새 스펙이 매년 나오고, 트렌드가 자주 바뀌긴 합니다. 그러나 백엔드라고 해서 한번 공부한 것을 천년만년 우려먹을 수는 없습니다. 대신 백엔드쪽이 더 기둥이 되는 필수 지식이 많기 때문에 학습 진입장벽이 높고, 그 기둥들이 잘 바뀌지 않을 뿐입니다. 4. 네... 프론트엔드 특성상 화면 디자인이 바뀌면 코드도 같이 바뀔 확률이 높습니다. 백엔드는 뷰에 대한 의존성이 비교적 낮기 때문에 코드 수명이 비교적 긴 편입니다. 대신, 백엔드에서는 성능 개선을 위한 코드 리팩토링이나, architecture 개편 등에 의한 대대적인 재개발이 있기도 합니다. 5. 아니요. 확장성을 고려한 코딩을 한다면 얼마든지 매번 새롭게 개발하지 않아도 됩니다. 매번 갈아엎어야 하는 코드는 좋은 코드라고 볼 수 없습니다. 그리고 지속가능한 코딩을 할 수 있는가가 좋은(=연차 높은, 높은 연봉을 받는) 개발자의 판단 기준이기도 합니다. 제가 직접 이직을 위해 취업시장에 나와보며 느끼는 점이 있습니다. 회사들은 잘 하는 프론트엔드 개발자를 찾고 있습니다. 그리고 다들 잘 하는 프론트엔드 개발자를 찾기 어렵다고 하시더라구요. 프론트엔드 분야 내에서 풀어내야 할 어려운 문제들은 백엔드 만큼이나 굉장히 많고 다양합니다. 저 또한 해결하지 못하는 문제들도 있어서 항상 구글링하고 관련된 강의 찾아보고 공부합니다. 새로운 기술 트렌드 뿐 아니라, 내가 개발해야하는 어플리케이션의 뷰와 로직을 어떻게 현명하게 풀어낼것인가도 항상 고민하는 문제입니다. 점점 개발해야하는 디자인, 기획 요구사항은 고도화되고 있기 때문에 비슷해 보이는 페이지여도 매번 다르게 해결해야합니다. 잘 하는 프론트엔드 개발자는 기획, 디자인 요구사항에서 빠르게 개발이 어려울 부분을 캐치해 개발 전에 피드백을 줘야 하고, 기존 코드를 재사용하고, 확장성 있는 코드를 짜고, 다양한 브라우저, 디바이스에서 문제없이 돌아가도록 안정성을 보장하며, 때로는 BE, 데이터, 기획, 디자인 사이 중간 톱니바퀴 역할을 적절히 해 전체 프로젝트가 원활히 돌아갈 수 있게 해야 합니다. 그 외 신경써야하는 자잘한 요소들도 많죠. 프론트엔드는 쉬워보이지만 복잡성이 굉장히 높은 분야입니다. 따라서 잘못 짜다보면 말씀하신것처럼 수명이 짧은 코드가 생기고, 매 업데이트마다 지우고 새로 만드는게 나은 수준이 되기도 합니다. 하지만 회사 입장이라면, 매번 똑같은 시간을 절대적으로 필요로 하는 개발자보다, 처음에 좀 더 고민해서 오래 걸리더라도 이후 업데이트들에 시간 리소스 소모가 적은 개발자를 선호하지 않을까요? 저는 이 차이가 O(N)과 O(logN)처럼 시간이 갈수록 벌어진다고 생각합니다. 그리고 마지막 질문에 대한 답변입니다. 제가 비전공자가 아니라 CS지식의 유무가 어떤 영향을 미치는지 잘은 모르겠으나, 저는 학교 다녔을 때 배운 CS과목들을 통해 은연중에 프로그래밍의 essense를 조금씩 익혀왔다고 생각합니다. 시간적, 공간적 제약을 어떻게 해결할 것이냐, 복잡한 문제을 어떻게 잘 책임을 나눠 해결할 것인가 등... 제가 통달하지는 못했지만 일 할때 문득문득 학교에서 배운 지식들이 떠오르고, 그게 문제 해결에 영감을 주기도 합니다. 그리고 어려운 과제들이 로직 개발 능력에 도움이 되었다고 생각합니다. View의 개입이 없는 시스템프로그랭, OS 과제들을 통해 복잡한 문제를 해결하는 법을 배운 것 같습니다. 물론 이 두가지 모두 대학과정을 수료하지 않더라도 개인 프로젝트나 현업에서 배울 수 있는 것들이라고 저는 생각합니다. 대신 전공자든 비전공자든 뇌 빼고 하면 내 것이 되어있지는 않겠죠 😇 프론트엔드 분야에 접근하는 진입장벽이 점점 낮아지는 것은 너무도 좋은 현상입니다. 그만큼 개발이라는 숨어있던 적성을 발견할 수 있는 분들이 늘어나고 있다는 뜻이니까요! 그렇다고 해서 프론트엔드 분야가 경쟁력이 없거나 백엔드보다 낮은 연봉을 받는다는것은 아닙니다. 여전히 업계는 전문성있고 다양한 문제를 경제적이고 멋지게 해결해온 프론트 개발자들을 찾고있고, 또 찾기 어려워하고 있습니다. 저 또한 한때, 프론트엔드 분야 지식과 코드가 너무 휘발성인것 같아 잠시 백엔드에 몸담았던 때가 있습니다. 하지만 백엔드 개발자로 일 할때도 여전히 매일매일 공부해야 했습니다. 그냥 개발자는 매일 공부하는게 맞다는 것을 느꼈습니다 😄 그래서 더 저에게 재미있는 프론트로 다시 돌아와 일했습니다. 이 복잡하고 복잡한 문제를 해결하는 것이 더 흥미롭습니다. 개발 능력 뿐 아니라 커뮤니케이션도 중요하고, 디자인을 놓치지 않는 미적 감각도 중요하고, BE 이해도도 있으면 좋습니다. 프론트엔드 분야가 잘 맞으시다면 한번 진득하게 시작해보시면 어떨까요? 무궁무진한 문제상황들을 효율적으로 풀기 위해 노력한다면 더 가치있는 프론트엔드 개발자가 되실 수 있으실거에요. 💪 그리고 잘 안맞으면, 백엔드로 옮겨도 되구요. 첫 술에 배부를 수는 없으니까요. 저도 아직 어떤게 잘 하는 개발자인지 찾고 있고, 노력하고있지만 갈 길이 먼 것 같습니다🥲 그래도 조금 먼저 둘 다 경험해본 개발자로서 도움이 되는 답변이 되었기를 바랍니다

다른건 모르겠지만 제 경험상 프론트엔드 시니어와 주니어 격차 엄청납니다. 격차가 안나는 경우는 다음과 같은 경우일거같습니다. 1. 서비스 규모가 작고 2. 서비스를 만들어서 런칭해야된다거나 서비스 코드 히스토리가 얼마 안됐거나 이런 환경의 회사라면 상대적으로 그렇게 큰 기술력을 요구하지 않을 확률이 높습니다. (이는 백엔드도 마찬가지일겁니다) 반대로 1. 서비스 규모가 크고 2. 서비스 코드의 히스토리가 엄청 길고.. 즉, 레거시 코드가 엄청 많은 회사라면 여기서 실력 격차가 어마어마하게 납니다. (여기서 레거시라함은 리액트 15의 클래스 컴포넌트 <-> 리액트18 이정도의 격차가 아닙니다. 이정도면 사실 레거시 코드도 아니죠. 정말 보지도 못한 프론트 1세대 프레임워크라던지 또는 jsp, php, 또는 ejs, nunjucks, jade, handlebars 같은 html 템플릿이라던지.. 웹팩 vite가 아닌 grunt, gulp 환경이라던지.. 정말 격차가 많이나는 경우도 많습니다) 이런 환경이라면 하나의 기능을 개발할 때 해결해야되는 문제가 수십가지가 되는 경우도 있습니다. 겉으로 봤을 땐 단순히 모달 하나 추가하는 것처럼 보여도 코드적으로는 너무 레거시 코드라 새 프론트 프로젝트로 작업해 연결해 붙여야한다던지, 그런 과정에서 웹팩, vite 설정을 자유자재로 다룰 수 있어야하고, 노드 버전이라던지 라이브러리 버전상 이유로 라이브러리 추가도 마음대로 안돼 어떤 기능을 스스로 만들어야된다던지.. UI도 프레임워크 쓰는 경우도 많겟지만 그 프레임워크에 원하는 UI 컴포넌트가 없거나 디자인 커스텀이 필요한 경우 그걸 만들어낼 수 있는 능력이라던지, 커스텀할 수 있는 능력이라던지.. 이러한 과정에서 이를 방치할수도 없으니 미래를 대비하여 마이그레이션 한다던지.. 서비스 규모가 크면 버전관리라던지 유지보수 비용이 많이들어갈 수밖에없긴하지만 그나마 그걸 최소화 하기위해 마이크로프런트엔드로 앱을 쪼개서 빌드하고 서비스에선 하나의 앱처럼 보이게 서비스 구축 한다던지.. 모노레포 선택하게되면 그 각 프로젝트마다 로컬서버환경을 자유자재로 세팅한다던지.. 이런걸 하면서 빌드, 배포 전략도 짜야돼고.. 서버세팅도 해야돼고.. (역시나 이 또한 백엔드도 마찬가집니다) 여튼 본인이 얼마나 깊게 바라보는지 회사 환경이 어느정도까지 할 수 있는 프론트엔드 개발자를 원하는지에따라 시니어와 주니어의 격차가 별로 안느껴질 수 있고 반대로 엄청나게 느껴질 수도 있다고 생각합니다.

1년 전 질문글이긴 한데, 혹시라도 뒤늦게 보는 분께 도움이 될까 싶어 공유합니다. 제가 경험한, 혹은 귀동냥으로 줏어들은 시니어급 프론트엔드 개발자의 기술적인 특징입니다. - 데이터 구조 설계할 때 백엔드나 데이터 엔지니어링 파트와 긴밀하게 논의가 가능했으며, 각 파트의 특성을 이해하고 설계에 반영했습니다. - 비대한 spa의 한계를 알고 튜닝은 물론 적절하게 ssr을 사용했습니다. - fe 특성상 코드 표준화, 공통 코드 활용 등의 니즈가 높은데, 표준 설계는 물론 확장하는 기능에 맞추어 표준을 유연하게 개선했습니다. - html과 css, js가 제공하지 않고, 마땅한 라이브러리가 없는 상황에서 브라우저라는 제한된 환경에서 동작하는 간단한 그래픽 엔진을 구현했습니다. 종합적으로, 사실상 풀스택인데 포지션이 프론트엔드인 느낌이었습니다.

프론트엔드에 대한 소문들은 어느 정도 사실이지만, 완전한 진실은 아닙니다. 각 소문에 대해 개별적으로 살펴보겠습니다. 1. 진입장벽이 낮다: 프론트엔드 개발은 비전공자나 비개발자가 시작하기에 상대적으로 쉬운 편입니다. 기본적인 HTML, CSS, JavaScript 지식만 있어도 웹사이트를 만들 수 있기 때문입니다. 하지만 전문적인 수준의 프론트엔드 개발자가 되려면 깊이 있는 지식과 경험이 필요합니다. 2. 연차와 기술 격차: 프론트엔드 개발에서도 경력과 기술의 격차가 존재합니다. 연차가 쌓일수록 신입과의 차이는 분명히 있습니다. 다만, 이 차이가 백엔드 개발자에 비해 상대적으로 작을 수는 있습니다. 3. 신기술의 빠른 변화: 프론트엔드 개발은 기술이 빠르게 변화하는 분야입니다. 이에 따라 최신 기술을 계속해서 학습하고 적용하는 능력이 중요합니다. 백엔드 개발도 변화가 있지만, 프론트엔드에 비해 상대적으로 덜 급진적인 편입니다. 4. 코드 수명: 프론트엔드 코드의 수명이 백엔드에 비해 짧다고 주장하는 것은 상황에 따라 다릅니다. 기술의 변화와 디자인 트렌드에 따라 코드를 변경할 필요가 있지만, 근본적인 구조와 로직은 오랫동안 사용될 수 있습니다. 5. 유지보수보다 갈아엎기: 프론트엔드 코드를 아예 갈아엎기보다는 유지보수하는 경우가 많습니다. 새로운 기술이나 디자인을 도입할 때 기존 코드를 재사용하고 개선하는 것이 효율적이기 때문입니다. 기업의 입장에서, 실력 차이에 따른 결과물의 차이가 작다고 해도, 경력직 개발자는 전략적인 역할을 할 수 있으며, 팀의 성장과 프로젝트 성공에 큰 기여를 할 수 있습니다. 따라서 기업은 신입과 경력직 개발자를 적절하게 조합하여 팀을 구성하는 것이 일반적입니다.