주위에 연차 3년쯤 지나서 천장에 부딪혀 발전할거 없다며 현타오는 프론트가 넘쳐나는데 뭐
이게 프론트도 SaaS같이 복잡한 앱을 만들면 난이도가 상당히 높지만
한국 내에서 그런 복잡한거 만드는 프론트 개발자 비율이 10%는 될까 모르겠다.
해외로 눈을 돌려도 기술적 난이도가 높은 프론트 개발 비율은 한 50%??
나도 지금은 운좋게 좀 어려운 프론트개발을 하고있는데
이게 이직하려고 알아보면 죄다 단순 데이터 서빙하는 곳들이 태반이라 회사 고르기가 힘들다
그래서 더더욱 옆으로 세서 AI나 그래픽스같은 다른 챌린징한것들을 계속 공부하게 되는 것 같고
[%] 근데 프론트가 쉬운곳이 많은거 맞긴 하잖아
익명(116.251)
2024-07-06 15:28
추천 0
댓글 11
다른 게시글
-
깃갤에 프론트 많은데 프론트 까면 당연히 욕쳐먹지[%] 익명(223.39) | 24.07.06추천 0
-
이제 프로그래밍 에서 삽질이 많이 없어질 듯[%] rrrr(115.94) | 24.07.06추천 0
-
디씨같은 커뮤니티 만들까 [1][%] 익명(223.39) | 24.07.06추천 1
-
(neo)vim: 플러그인 없이 인권보장 받기 (1) [12][연재] 전자책가방(precede5148) | 24.07.06추천 4
-
커피도 잘 내리는 사람들은 습도나 온도, 원두 특성 다 공부하더라고 [20][%] 익명(122.36) | 24.07.06추천 6
-
내가 볼때 프론트는 생산직같은거임 [63][%] 익명(118.235) | 24.07.06추천 9
-
펨코 글 자동삭제 프로그램 만들었다 [4][%] 익명(210.121) | 24.07.06추천 0
-
군머 업무용pc에 비인가 프로그램 깔아보신 분 있음? [14][%] 익명(172.226) | 24.07.06추천 1
-
편입충인데 C언어랑 자료구조만으로 3학년 수업 따라가기 가능? [5][%] 익명(118.235) | 24.07.06추천 0
-
포렌식은 어떻게 공부 시작해야 됨 [8][%] 익명(211.234) | 24.07.06추천 0
백앤드는 실제로 비즈니스 문제를 다룬다고하면 프론트는 비즈니스 문제가 아니라 기술문제를 가지고 어쩔거니 저쩔거니 하니까 기술문제 대충 이렇게 해결했어요 짜잔 하면 급현타오는게 사실임.
비즈니스문제는 스펙이 발전하면서 끊임없이 발전하는데 프론트는 그 문제를 제한적으로밖에 해결할 수 없고, 당장 기술문제를 해결하고 케바케로 보는 것 말고는 큰 답이없음. 요즘 느끼는 현타임. 그래서 프론트 개발자중에 유독 DX/플랫폼쪽으로 생각을 많이 해보는 사람도 많은듯.
프론트엔드의 난이도라는게 결국 백엔드의 프레젠테이션 역할을 넘어서서 별도의 앱을 구성하면서 확 올라가는거라. 그런쪽으로 이직을 해야 어려운 비지니스 문제들도 다루고, 실력도 쌓이지 않을까 싶다 그게 아니면 자꾸 헛물만 켜는 것 같아
내 생각에는 프론트는 비즈니스 문제에 떨어질 수 밖에 없음. DB를 관리하고 접근하지못하면.. 크게 뭐.. (open api specficiation을 프론트도 같이 고민한다면 나쁘지 않을수도..?) 그럼 남은 문제는 그 결과물들을 어떻게 관리할거냐의 문제인데.. 복잡성을 높이고 다양한 스펙을 대비할거냐, 복잡성을 낮추고 특수 스펙에 집중할거냐 이런 전투밖에 안되는거지. 거기에 기술들도 다 웹표준이 아니라 자체표준(React + Next.js, css-in-js)같은게 쏟아지면서 거기에 맞는 추가 표준같은것도 쏟아지고말이야.. 쓸데없는 기술논쟁은 오지게 많음. 별도의 앱을 구성한다면 복잡도를 높이고 다양한 스펙을 대비하는 케이스인데, 나는 그 경험이 과연 경력에 도움될까 생각이 들긴함.
왜냐하면, 결국 그 복잡성에 비용을 더 지불해야하는 이유를 찾지못하고 간단하게 돌아가는 케이스가 더 많거든. 프론트 개발자들은 그래서 비즈니스에 집중하기보단 새로운 문제의 영역을 찾아내려고 하는 것 같기도 해. (DX/플랫폼/Dev Ops/접근성/디자인시스템)
근데 그 쓸데없는 기술논쟁이라는게, 요즘 보면 다 일관된 방향을 가지고 있긴 함. 복잡성을 낮춰서 단순하게 만드는 방향으로. 복잡도를 높인다는게 다양한 스펙을 대비한다는게 아니라 그냥 구현해야할 과제의 복잡도가 높은걸 얘기한거였어. 그걸 구현하려면 오히려 구현자체의 복잡도는 더더욱 낮추어야겠지. 디비접근은 백엔드를 통해서 하겠지만, 프론트앱 내에서의 data manipulation이 많다면 결국 별도의 앱으로 구성되어야 하잖아. 그런 복잡도
아이피가 기억나는건 아닌데 말투만 봐도 프론트얘기 나하고 몇번 한적 있는 게이같아서 찾아보니 맞네 ㅋㅋㅋㅋ
https://gall.dcinside.com/mgallery/board/view/?id=github&no=64770
나도 예전에 님처럼 생각했었는데, 요즘엔 반대임. 과연 기술이 일관된 방향이 맞을까? React 19의 Suspense 사건만 해도 봐봐. (Suspense의 기본동작을 바꾸겠다고 하였다가 커뮤니티 반발먹고 결정보류로 바뀜) 그 react renderer의 정해지지 않은 표준 위에서, relay or tanstack react + query만의 조합방식도 나오고 있고, remix는 나름대로 또 새로운 스펙을 추가하고... 괴상한 스펙위에 괴상한 스펙이 쌓이고 있다고 봐. 이게 복잡성을 늘리는 짓이라 생각하고, 신규 유저들은 '프론트는 쉬워보이지만 까보면 역시 어려워'라는 이상한 이야기나 하게 된다고 봄.
요즘 내가 현타와서 그런가. 구현해야할 과제가 복잡한건 맞는데, 뭔가 내가 본질적인 비즈니스로직에(실제 데이터 저장 및 관리) 기여도가 거의 0%로 된다는 느낌이 들어서 좀 짜증이 나기도 했나봄.
근데 내 문장에 지문이 묻어있나보네 ㅋㅋ;; 머쓱해라
프론트도 케바케고 백도 케바케지 백엔드도 단순 crud는 동네 개데려놔도 공부시키면 할거여