프로젝트에서 보기 →

(Next.js 0강) 요즘 프론트엔드만으로 먹고살기 힘든 이유

태그
기타 개발자 취업 코딩
시작일
종료일
수정일

https://www.youtube.com/watch?v=jYJ3ygUfPrU

# 1. 이건 꼭 알아야 한다[^1]

[? 질문] 왜 “프론트엔드 기술 하나만으로 꿀 빨던 시대”가 끝났다고 말하는가[^1]
[= 답] 단순히 채용이 줄고 외주가 늘고 GPT가 코드를 잘 짜서가 아니라, 더 근본적으로 웹 개발의 중심이 클라이언트 사이드 렌더링(CSR)에서 서버사이드 렌더링(SSR)로 이동하고 있어서, 프론트엔드 단독 전문성의 효용이 상대적으로 줄어들고 서버/풀스택 역량의 수요가 커지는 구조라고 설명한다.[^6][^16]

[? 질문] CSR(리액트/뷰 유행)이 왜 “돈이 줄줄 새는” 문제로 이어진다고 주장하는가[^11]
[= 답] CSR은 앱처럼 부드럽고 예쁜 경험을 만들 수 있지만, (1) 구글 검색 노출(SEO)이 어렵고 (2) 첫 페이지 로딩이 느려지는 두 가지 치명적 단점이 있고, 이 둘이 웹사이트의 수익성(트래픽/전환/이탈 등)에 악영향을 준다고 말한다.[^9][^10][^11]

[? 질문] 이런 변화 속에서 왜 Next.js를 배워야 한다고 권하는가[^27]
[= 답] Next.js는 풀스택 프레임워크로서 SSR 중심의 흐름을 쉽게 따라가게 해주고, 리액트 문법을 그대로 쓰면서 최신 리액트 흐름을 빠르게 흡수하며, 라우팅/서버 기능/DB 연결/인증/최적화/캐싱 등 “돈과 성능”에 직결되는 기능을 비교적 쉽게 제공해 실무 선택의 이유가 충분하다고 제시한다.[^23][^24][^26]

# 2. 큰 그림[^2]

이 콘텐츠는 “요즘 프론트엔드만으로 먹고살기 힘든 이유”를 단순 채용시장 탓이 아니라 **렌더링 패러다임 변화(CSR → SSR)**로 설명하고, 그 흐름에서 Next.js가 왜 유력한 선택지가 되는지(장점/단점/학습 방향)를 5분대에 압축해 안내하는 ‘Next.js 강의 0강’ 도입부다.[^6][^23][^39]

  • 프론트엔드 채용/업무 환경이 바뀌었다: 예전처럼 리액트만 “조금” 해도 되는 시장이 아니고, 채용 감소·외주 증가·AI 코딩 도구 확산 같은 변화가 체감된다고 깔아둔다.[^2][^3][^4]
  • 핵심 전환은 SSR의 부상: CSR의 단점(SEO/첫 로딩)이 수익성에 악영향을 주기 때문에, 서버에서 HTML을 만들어 보내는 SSR이 다시 중요해지고 있다는 논리를 편다.[^6][^9][^13]
  • Next.js는 그 전환을 쉽게 타게 해주는 실전형 도구: 풀스택(프론트+백) 지원, 리액트 친화성, 라우팅/최적화/캐싱/SSR·CSR 선택 등으로 “안 쓸 이유가 적다”는 톤으로 소개하고, 앞으로의 강의에서 심플한 프로젝트 2개로 ‘혼자 코드 짜는 법’을 목표로 한다.[^15][^20][^40]

# 3. 하나씩 살펴보기[^1]

## 3.1 “프론트엔드만으로 꿀 빨던 시대”가 끝났다는 문제 제기[^1]

영상은 도입부터 [h 프론트엔드 기술 하나만으로 쉽게 커리어를 만들던 시기가 끝났다는 선언]으로 시작한다.[^1] 화자는 과거와 현재의 채용 분위기를 대비시키며, 예전에는 리액트만 조금 할 줄 알아도 개발자로 일할 기회가 있었는데, 이제는 프론트엔드 채용 숫자가 전반적으로 많이 줄었다고 말한다.[^2]

또한 회사들이 비용 절감을 이유로 프론트엔드 업무를 외주 개발로 돌리는 경우가 많아졌다고 덧붙인다.[^3] 여기에 더해 “간단한 리액트 코드” 작성은 이제 사람보다 GPT가 더 잘하지 않냐는 식으로, AI 도구의 확산이 프론트엔드 단순 구현 업무의 가치에 압박을 준다는 뉘앙스를 준다.[^4]

다만 이 지점에서 화자는 “여러분 겁주려고 오버하는 것”이라고 톤을 조절한다.[^5] 즉, 방금 언급한 채용 감소/외주/AI 이슈가 전부가 아니라, 더 본질적인 구조적 이유가 따로 있다는 방향으로 논지를 전환한다.[^5][^6]

[!IMPORTANT] 도입부의 역할
이 구간은 “공포 조장”이 결론이 아니라, 시청자의 문제의식(프론트엔드만으로 불안함)을 끌어낸 뒤, 다음 구간에서 제시할 ‘진짜 이유(SSR 부상)’로 자연스럽게 이동시키는 장치로 기능한다.[^5][^6]

## 3.2 “진짜 큰 이유”: CSR이 아니라 SSR의 시대가 오고 있다[^6]

화자는 더 큰 이유로 [c 웹 개발에서 서버사이드 렌더링(SSR)의 시대가 오고 있기 때문]이라고 못 박는다.[^6] 이어 SSR을 매우 직설적으로 정의한다: HTML 웹페이지를 서버에서 만드는 행위를 전문 용어로 서버사이드 렌더링이라고 한다.[^7]

그 다음 최근 몇 년간 유행했던 개념으로 **클라이언트 사이드 렌더링(CSR)**을 소개한다.[^8] CSR의 의미는 리액트나 뷰 같은 라이브러리를 사용해 웹페이지를 “서버가 아니라 유저 브라우저에서 실시간으로 만들어주는 것”이라고 설명한다.[^8] 즉 서버는 주로 데이터 제공/정적 파일 제공 역할을 하고, 화면(HTML) 구성은 브라우저에서 자바스크립트로 조립하는 방식이라는 맥락이다.[^8]

CSR이 유행한 이유(장점)로는:

  • 페이지 전환이 부드러워지고[^9]
  • 앱처럼 예쁜 사이트를 만들 수 있다는 점[^9]

을 언급한다.[^9]

하지만 여기서 화자는 “크리티컬한 단점이 두 가지”라고 하며, CSR의 핵심 약점을 정면으로 제시한다.[^9]

## 3.3 CSR의 치명적 단점 2가지: SEO와 첫 로딩 속도[^9]

화자가 꼽는 CSR의 크리티컬 단점은 두 가지다.[^9]

  1. 구글 검색 노출이 어렵다[^10]
  2. 첫 페이지 로딩 속도가 느리다[^10]

그리고 문제는 이 두 가지가 “사이트 수익성에 매우 악영향”을 준다고 연결한다.[^11] 즉 단순히 “개발자 취향”이나 “기술적 우아함”의 문제가 아니라, 비즈니스 결과(돈)와 직결되는 문제라는 프레임이다.[^11]

여기서 화자는 시청자에게 연속 질문을 던진다.[^12]

[? 질문] 여러분은 웹사이트 같은 걸 왜 만드냐[^12]
[= 답] 돈 벌려고 만드는 것 아니냐, 맞다고 응답 흐름을 스스로 만든다.[^12][^13]

이 문답을 통해 “성능/SEO 문제 → 수익성 악화 → 결국 돈 문제”라는 결론을 강조한다.[^11][^13] 그리고 이를 한 문장으로 과격하게 표현한다: 리액트나 뷰를 쓰면 돈이 줄줄 새어 나간다는 소리라고 말한다.[^13]

[!WARNING] 화자의 표현 방식
“돈이 줄줄 샌다”는 표현은 CSR을 무조건 나쁘다고 단정하기보다는, SEO/초기 로딩이 특히 중요한 서비스(콘텐츠/커머스/마케팅 랜딩 등)에서 CSR 중심 설계가 가져오는 사업적 비용을 강하게 환기시키는 레토릭으로 사용된다.[^11][^13]

## 3.4 SSR의 개념과 장점: 가볍고, SEO에 유리하고, 선택적 CSR도 가능[^14]

화자는 SSR을 “HTML 웹페이지를 서버에서 미리 다 만들어서 보내주는 개념”이라고 다시 풀어 말한다.[^14] 이렇게 하면 CSR처럼 “유저한테 자바스크립트 코드를 많이 보낼 필요”가 줄어들 수 있어 결과적으로 조금 더 가볍다고 설명한다.[^14]

또한 SSR은 구글 검색 노출도 잘 되는 편이라고 말하며, 앞에서 CSR의 단점으로 제시한 SEO 문제를 정면으로 반전시킨다.[^15]

여기에 Next.js(영상에서는 “넥스트 as”라고 발음/표기되는 부분)가 제공하는 중요한 특성을 덧붙인다: 일부 페이지에서는 클라이언트 사이드 렌더링을 하고 싶다면 선택적으로 가능하다는 것이다.[^16] 즉 SSR 중심 프레임워크를 쓰더라도, 상호작용이 강한 구간/페이지에서는 CSR 또는 클라이언트 로직을 섞는 하이브리드 운용이 가능하다는 관점을 제시한다.[^16]

이 지점에서 화자는 결론적으로 “안 쓸 이유가 없다”고 정리한다.[^17] (물론 뒤에서 단점도 말하지만, 우선 흐름상 “왜 시장이 SSR 쪽으로 가는지”를 강하게 고정하는 대목이다.)[^17]

## 3.5 SSR이 프론트엔드 ‘전문성’의 체감 가치를 낮출 수 있다는 주장[^18]

화자는 CSR이 유행하던 시절의 프론트엔드 개발을 묘사한다: 리액트/뷰로 스테이트 관리, useEffect, 비동기 통신 등 “어려운 기술들”을 동원해 HTML을 만들어 왔다고 말한다.[^18] 즉 화면을 만들기 위해 복잡한 클라이언트 상태/라이프사이클/데이터 패칭 로직을 브라우저에서 운영해야 했다는 인식을 깔고 있다.[^18]

그런데 SSR을 하면(서버에서 HTML을 만들어 보내면) “프론트엔드 전문성 같은 게 진짜 별로 필요가 없어지는” 방향이 된다고 주장한다.[^19] 여기서의 요지는:

  • 화면의 기본 뼈대(HTML)가 서버에서 완성되어 내려오면,
  • 브라우저에서 복잡하게 “HTML을 만들어내는” 작업의 비중이 줄고,
  • 따라서 전통적 의미의 프론트엔드 숙련(상태/훅/복잡한 렌더링 최적화 등)의 ‘필요 체감’이 낮아질 수 있다는 관점이다.[^19]

이 관점을 바탕으로 그는 고용시장 전망을 제시한다: 예전보다 서버 개발자나 풀스택 개발자 수요가 확실히 많이 늘어날 것 같다고 말한다.[^20]

## 3.6 AI 시대 전망: “큰 그림” 이해 + 풀스택 기본 시대[^21]

화자는 미래를 한 발 더 나아가 전망한다. 미래에는 “실제 코드 작성”을 AI가 해 줄 것이며, 그 결과 “누구나 큰 그림만 이해를 잘 하고 있으면 개발을 잘 할 수 있는 시대”가 올 것이라고 말한다.[^21]

그리고 이 흐름에서 “프로는 풀스택이 기본인 세상”이 올 것 같다고 덧붙인다.[^21] 즉:

  • 단순 구현(코드 타이핑)은 자동화되고,
  • 시스템을 어떻게 구성할지/무엇을 만들지/데이터 흐름과 렌더링 전략을 어떻게 가져갈지 같은 설계·아키텍처·제품 관점의 “큰 그림”이 중요해지며,
  • 그 큰 그림에는 프론트/서버가 함께 포함되기 때문에 풀스택 역량이 기본값이 된다는 논리다.[^21]

그래서 서버 개발을 몰랐던 사람들도 “미리 서버 개발을 맛보는 것도 나쁘지” 않다고 권한다.[^22] 그리고 “요즘은 크게 어렵지도 않다”는 말로 진입장벽이 낮아졌음을 강조한다.[^22]

## 3.7 Next.js가 쉬워진 이유와 개발 속도 체험담(게시판 1시간 제작)[^23]

그 ‘쉽다’의 근거로 화자는 Next.js 같은 프레임워크가 하도 잘 나와서 이걸 쓰면 “매우 쉬우니까”라고 말한다.[^23] 이어서 본인이 “최근에 문법이 아예 바뀌어버린 Next.js”를 직접 써봤다고 하고, 구체적인 실습 결과를 공유한다.[^24]

그가 만들어 본 것은:

  • 게시판 하나[^24]
  • 서버랑 DB 기능까지[^25]

이며, “충격적인 건” 이걸 만드는 데 딱 1시간밖에 안 걸렸다고 말한다.[^25] 더 구체적으로는 “말이 안 되는 스피드”로 개발할 수 있었고, 본인이 “실제로 코드 짜는 건 30분”, “이거저거 검색하는 데 30분”이 걸렸다고 시간을 쪼개어 설명한다.[^26]

또한 여기에 “30분만 더 추가하면 회원 기능까지도 쉽게 만들 수 있을 것” 같다고 말해, Next.js 환경에서 인증/회원 기능도 비교적 빠르게 붙일 수 있다는 기대를 덧댄다.[^27]

그리고 시청자에게도 “Next.js 신버전”을 써보면 지금 하고 있는 개발을 “접고 그냥 이거 쓰고 싶어질걸”이라고 말하며, 전환 욕구를 자극하는 표현을 사용한다.[^28]

## 3.8 “쉽고 편해서”가 아니라: 사람들이 Next.js를 쓰는 진짜 이유들[^29]

화자는 곧바로 균형을 잡는다. 개발이 쉽고 편하다고 해서 사람들이 무조건 갈아타는 것은 아니라고 말한다.[^29] 즉 “편의성”은 충분조건이 아니며, 중요한 이유들이 몇 개 더 있다고 예고한다.[^29]

그 핵심 이유로 먼저 Next.js의 정체성을 선언한다: Next.js는 풀스택 프레임워크다.[^30] 그리고 이 한 문장을 구체화한다:

  • “이거 하나로 프론트엔드랑 백엔드 전부 다 개발할 수” 있다.[^30]

이어 프론트엔드 개발자(특히 리액트 개발자) 관점의 진입 장벽을 낮추는 포인트를 강조한다:

  • 여러분이 좋아하는 리액트 문법을 그대로 쓸 수 있다.[^31]
  • Next.js가 리액트 신기술을 그대로 도입하고 있기 때문에 기존 리액트 개발자들이 매우 쉽게 입문할 수 있다.[^32]

그리고 “그게 실은 Next.js를 가장 많이 선택하는 이유”라고 말해, 생태계·학습 곡선·기술 연속성이 채택의 핵심 동인임을 제시한다.[^33]

## 3.9 Next.js 추가 장점 나열: 라우팅 자동화, 서버/DB/인증 쉬움, CSR 선택, JS 없는 빠른 페이지, 캐싱, 폰트/이미지 최적화[^34]

화자는 “몇 가지 장점이 더 있다”며 기능적 장점을 이어서 열거한다.[^34]

  • 이번 버전부터는 파일과 폴더만 만들면 자동으로 HTML 페이지를 생성해 줄 수 있다고 말한다.[^34]

    • 이는 파일/폴더 기반 라우팅(혹은 그에 준하는 구조)을 통해 페이지가 자동 구성된다는 의미로 제시된다.[^34]

  • 서버 기능 만들기, DB 연결, 회원 인증 같은 것들도 “좀 쉬워진 편”이라고 말한다.[^35]

    • 앞에서 본인의 게시판 제작 시 “서버랑 DB 기능”을 포함했다고 한 경험담과 연결된다.[^25][^35]

  • 아까 말했듯이 CSR도 자유롭게 할 수 있다고 재강조한다.[^36]

    • SSR 프레임워크이면서도 클라이언트 렌더링/클라이언트 로직을 선택적으로 넣을 수 있다는 점을 반복해 설득한다.[^16][^36]

  • “난 이런 게 싫다”면 자바스크립트가 안 들어가 있는 아주 빠른 페이지도 쉽게 만들 수 있다고 말한다.[^37]

    • 즉 자바스크립트 번들 의존도를 낮춘(혹은 거의 없는) 페이지를 만들 수 있어 성능/접근성/단순 컨텐츠 제공에 유리하다는 메시지다.[^37]

  • 서버 데이터 캐싱도 가능하다고 언급한다.[^38]

  • 폰트/이미지 최적화도 가능해서 “되게 빠른 사이트”를 만들 수 있다고 정리한다.[^39]

[!TIP] 화자가 강조하는 “돈/수익성” 연결고리
앞에서 CSR의 단점이 수익성에 악영향이라고 했고,[^11] 여기서는 Next.js가 제공하는 SSR/JS 최소화/캐싱/최적화를 통해 결과적으로 “빠른 사이트”를 만들 수 있음을 강조한다.[^37][^39]

## 3.10 경쟁 프레임워크 언급과 “만족도가 안 떨어진다”는 선택 논리[^40]

화자는 Next.js와 비슷한 프레임워크들이 많다고 말하며 예시로 리믹스(Remix), 벨트킷, 녹스트(Nuxt) 등을 언급한다.[^40] 그리고 개발자 설문조사 결과를 본다는 전제 하에, 다른 프레임워크들은 “만족도가 갈수록 떨어지는데” Next.js는 “안 떨어진다”고 말한다.[^41]

이 비교를 통해 결론은 간단해진다: “그냥 Next.js 선택하시면 된다”고 정리한다.[^42] (구체적인 설문 수치나 출처는 영상 대본에 나오지 않지만, 화자의 주장 근거로 “설문조사 결과”를 제시한다.)[^41][^42]

## 3.11 비유: 주식 투자처럼 “저점 매수”—향후 5년 생존 전략으로 Next.js 학습 권장[^43]

화자는 뜬금없이 “주식” 비유를 꺼낸다: 주식을 살 때 어떤 걸 사는 게 좋냐고 묻고, “사람들이 많이 찾고 언플 같은 거 잘하는 주식”을 사는 게 맞다고 말한다.[^43][^44]

이 비유를 Next.js 선택에 연결한다. 앞으로 5년 동안 웹 개발자로 먹고 살고 싶다면, Next.js 같은 것을 지금 배워 “저점 매수해 두는 것도 좋은 생각”이라고 제안한다.[^45]

즉 여기서 Next.js는:

  • 당장 시장에서 수요/관심이 크고,
  • 앞으로 더 커질 가능성이 있으며,
  • SSR/풀스택/리액트 생태계와의 결합으로 “사람들이 찾는” 기술이 될 것이므로,
  • 선제적으로 학습해 커리어 리스크를 낮추라는 메시지로 포지셔닝된다.[^20][^45]

## 3.12 Next.js의 단점들: 복잡해지는 라우팅/예약 파일, 미완성 리액트 기능 도입, 서버·클라 컴포넌트 구분, 실시간 기능은 별도 서버, 서버 기능은 풍부하지 않음[^46]

화자는 “물론 단점도 있다”고 말하며 구체적인 불편 요소를 나열한다.[^46]

  • 폴더 기반 라우팅을 해주다 보니, “예약 파일이 너무 많아”지고, “오브젝트가 커진다 그러면 좀 복잡해진다”는 점을 든다.[^47]

    • 여기서 “예약 파일”은 프레임워크가 특정 규칙/이름의 파일들을 특별 취급하는 구조를 의미하는 맥락으로 제시된다.[^47]

  • Next.js가 “아직 리액트에 미완성 기능들을 도입해 놨다” 보니까 귀찮은 점들이 생긴다고 말한다.[^48]

    • 즉 안정화가 완전히 끝나지 않은(혹은 변화가 잦은) 신기능을 적극 채택하는 과정에서 개발자가 겪는 마찰을 단점으로 언급한다.[^48]

  • 클라이언트 컴포넌트와 서버 컴포넌트를 구분해서 코드 짜는 것도 귀찮다고 말한다.[^49]

    • SSR/서버 컴포넌트 모델에서 흔히 등장하는 “이 코드는 서버에서, 이 코드는 브라우저에서” 구분의 인지 부담을 지적한다.[^49]

  • **웹소켓(WebSocket)**이나 WebRTC 같은 기능을 쓰고 싶으면 “직접 서버 한 대를 더 만들어야” 한다고 말한다.[^50]

    • 즉 Next.js만으로 실시간 통신/피어투피어 같은 요구를 완전히 해결하기 어렵고, 별도 서버 구성(혹은 별도 런타임/서비스)이 필요할 수 있다는 점을 단점으로 든다.[^50]

  • 전반적으로 프레임워크 자체가 “풍부한 서버 기능”은 별로 없고 “HTML 렌더링 하나만 잘하는 느낌”이라고 평가한다.[^51]

    • 다만 그는 이것을 치명적 문제로 보진 않는다. “요즘은 그냥 그게 가장 중요”하니 “별 상관 없을 것”이라고 말해, SSR/렌더링 성능이 현 시점의 핵심 가치라는 관점을 재확인한다.[^52]

## 3.13 강의 운영 계획: Next.js 신버전, 프로젝트 2개(쿠팡프레시·게시판), 목표는 “혼자서 알아서 코드 짜는 법”[^53]

이제 영상은 0강 도입을 넘어, 앞으로의 강의 진행 방침을 공지한다. 시청자들이 “신버전 안 쓰면 큰일 나는 줄 알기 때문에” 앞으로 진행할 강의에서는 신버전을 쓸 거라고 말한다.[^53]

프로젝트는 두 개를 만들 계획이라고 한다.[^54]

  • “쿠팡 후레쉬 같은 거” 하나[^55]
  • “게시판” 하나[^55]

여기서 화자는 프로젝트의 ‘멋’보다 학습 효과를 강조한다. “간지나고 멋있는 프로젝트 만들면 좋겠지만” 어느 순간부터 “그냥 받아쓰기만 하고 있지 않냐”고 지적하며, 그런 방식은 실력에 “별 도움”이 안 된다고 말한다.[^56]

그래서 이번 강의의 목표를 명확히 한다: Next.js로 혼자서 알아서 코드 짜는 법을 알려주는 것이 목표이며, 이를 위해 “최대한 직관적이고 심플한 프로젝트”를 할 것이라고 한다.[^57]

강의의 대상/전제 지식도 안내한다:

  • 강의 레벨은 HTML/CSS/자바스크립트 기초를 아는 사람 대상으로 진행한다.[^58]
  • 다만 화자는 시청자의 기초 실력에 대한 “기대치가 매우 낮다”고 말하며, “걱정 안 해도 될 것”이라고 한다.[^59]
  • 리액트 문법은 미리 알면 좋지만, “몰라도 시작할 수” 있다고 말한다.[^60]

마지막으로 다음 시간에는 “프로젝트 설치”를 해보자고 예고하며 0강을 마무리한다.[^61]

# 4. 핵심 통찰[^6]

  1. [c ‘프론트엔드만으로 어렵다’의 근본 원인은 시장 심리보다 렌더링 패러다임(CSR→SSR) 변화로 설명된다.] 단순 구현의 가치가 내려가고, SEO/초기 로딩처럼 비즈니스 임팩트가 큰 요소가 다시 SSR을 요구한다는 논리다.[^6][^10][^11]

    • 실행: 본인이 만드는 서비스가 SEO/첫 로딩에 민감한지 먼저 평가하고, 민감하다면 SSR/하이브리드 전략을 기본값으로 검토한다.[^11][^16]

  2. [h CSR의 대표적 비용은 “수익성 악영향”으로 귀결된다.] SEO 노출과 첫 로딩 지연이 트래픽·이탈·전환에 영향을 주며, 이를 “돈이 줄줄 샌다”는 표현으로 강하게 환기한다.[^10][^13]

    • 실행: Lighthouse/웹바이탈 측정과 함께, 검색 유입 비중이 큰 페이지는 SSR/정적 생성 위주로 설계한다.[^15][^37]

  3. [h SSR/풀스택 흐름은 프론트엔드 ‘단독 전문성’의 상대적 가치를 낮출 수 있다.] 서버에서 HTML을 만들면 브라우저에서 복잡한 상태/훅/비동기 조립으로 “HTML을 만들어내는” 부담이 줄어든다는 관점이다.[^18][^19]

  4. [h Next.js는 “리액트를 그대로 쓰면서” 풀스택으로 확장하게 해주는 채택 장벽 낮은 선택지로 제시된다.] 리액트 개발자가 쉽게 들어오는 것이 가장 큰 선택 이유라고 못 박는다.[^31][^33]

  5. [m “편해서”가 아니라 “구조적 이유(SSR/최적화/생태계)” 때문에 사람들이 Next.js를 선택한다는 프레이밍이 반복된다.] 기능 나열(라우팅/DB/인증/캐싱/최적화)은 결국 빠른 사이트와 운영 효율로 연결된다.[^29][^35][^39]

  6. [m 단점도 분명히 존재한다: 규칙 기반 구조의 복잡성, 서버·클라 컴포넌트 구분, 실시간 기능의 별도 서버 필요.] 그럼에도 화자는 ‘요즘 중요한 건 HTML 렌더링’이라고 우선순위를 재정렬한다.[^49][^50][^52]

  7. [h 강의 목표는 “멋진 결과물”이 아니라 “혼자서 코드 짜는 능력”이다.] 받아쓰기식 튜토리얼의 한계를 지적하고, 직관적·심플한 프로젝트로 자립을 목표로 한다.[^56][^57]

    • 실행: 프로젝트를 따라 만든 뒤, 요구사항을 스스로 추가(회원 기능/검색/정렬/캐싱 전략 변경 등)해 ‘받아쓰기’를 깨는 연습을 한다.[^27][^56]

# 5. 헷갈리는 용어 정리[^7]

  • 서버사이드 렌더링(SSR): HTML 웹페이지를 서버에서 만들어서 보내주는 방식(“html 웹페이지를 서버에서 만드는 짓거리”).[^7][^14]
  • 클라이언트 사이드 렌더링(CSR): 리액트/뷰 같은 라이브러리로 웹페이지를 유저 브라우저에서 실시간으로 만들어주는 방식.[^8]
  • 풀스택 프레임워크: 하나의 프레임워크로 프론트엔드와 백엔드를 함께 개발할 수 있다고 소개되는 형태(Next.js에 대해 그렇게 설명).[^30]
  • 클라이언트 컴포넌트 / 서버 컴포넌트: Next.js에서 코드를 작성할 때 브라우저에서 동작할 부분과 서버에서 동작할 부분을 구분해야 하는 컴포넌트 구획으로, 화자는 이것이 “귀찮다”고 언급한다.[^49]
  • 웹소켓(WebSocket) / WebRTC: 실시간 통신 또는 브라우저 기반 실시간 기술로 언급되며, 이를 쓰려면 “서버 한 대를 더” 만들어야 한다는 단점 맥락에서 등장한다.[^50]

참고(콘텐츠 정보)

  • 제목: (Next.js 0강) 요즘 프론트엔드만으로 먹고살기 힘든 이유[^1]
  • 채널: 코딩애플[^1]
  • 길이: 5분 32초[^1]
  • 링크: https://www.youtube.com/watch?v=jYJ3ygUfPrU[^1]
  • 키워드(제공됨): 개발자, 취업, 코딩, 프로그래밍, 자바스크립트, 백엔드, 풀스택, 넥스트, next.js 강의, 리액트[^1]

[^1]: @[00:00] “프론트엔드 기술 하나만으로 꿀 빨던 시대가 끝났습니다” + 사용자가 제공한 메타데이터(제목/채널/길이/링크/키워드).
[^2]: @[00:05] “전에는 리액트만 조금 해도 개발자 시켜줬는데 지금은 프론트엔드가 전체적으로 채용 숫자도 많이 줄고요”
[^3]: @[00:09] “비용 아끼려고 프론트엔드를 외주개발로 돌리는 경우도 많아졌고요”
[^4]: @[00:13] “간단한 리액트 코드 짜는 건 사람보다 gpt가 더 잘하지 않습니까”
[^5]: @[00:18] “물론 여러분들 겁주려고 오버하는 거고요”
[^6]: @[00:21] “실은 이런 거보다 더 큰 이유가 있는데… 서버사이드 렌더링의 시대가 오고 있어서 그렇습니다”
[^7]: @[00:29] “html 웹페이지를 서버에서 만드는 짓거리를 전문용어로 서버사이드 렌더링이라고 합니다”
[^8]: @[00:37] “클라이언트 사이드 렌더링… 리액트나 뷰… 유저 브라우저에서 실시간으로 만들어 주는 거예요”
[^9]: @[00:45] “페이지 전환이 좀 부드러워지고요… 앱 같이 예쁜 사이트… 크리티컬한 단점이 두 가지”
[^10]: @[00:53] “구글 검색 노출이 좀 어렵구요… 첫 페이지 로딩 속도가 좀 느려요”
[^11]: @[00:57] “요거 두 가지가 사이트 수익성에 매우 악영향”
[^12]: @[01:00] “여러분들 웹사이트 같은 거 왜 만들어요”
[^13]: @[01:10] “리액트나 뷰를 쓰면 돈이 줄줄 세어 나간다는 소리에요”
[^14]: @[01:13] “서버사이드 렌더링은… 서버에서 미리 다 만들어서 보내주는… 자바스크립트 코드를 많이 보낼 필요가 없어서… 가볍고요”
[^15]: @[01:17] “구글 검색 노출도 잘 되는 편이에요”
[^16]: @[01:20] “넥스… 일부 페이지에서 클라이언트 사이드 렌더링… 선택적으로 가능합니다”
[^17]: @[01:23] “자 그래서 안 쓸 이유가 없는 거예요”
[^18]: @[01:31] “리액트나 뷰… 스테이트 관리… 유즈 이펙트… 비동기 통신… 어려운 기술들로 html을 만들었었는데”
[^19]: @[01:40] “서버사이드 렌더링하면… 프론트엔드 전문성 같은게 진짜 별로 필요가 없어지는 거예요”
[^20]: @[01:40] “서버 개발자나 풀스택 개발자 수요가 확실히 많이 늘어날 것 같고요”
[^21]: @[01:51] “미래엔 실제 코드 작성을 ai가… 큰 그림… 프로는 이제 풀스택이 기본”
[^22]: @[02:00] “서버 개발 모르던 분들도… 서버 개발… 맛보는 것도… 요즘은… 어렵지도 않습니다”
[^23]: @[02:11] “넥스트 JS 같은 프레임웍이… 잘 나와서… 매우 쉬우니까요”
[^24]: @[02:16] “최근에 문법이 아예 바뀌어버린 넥스트 js를 써봤습니다”
[^25]: @[02:19] “게시판 하나… 서버랑 DB 기능까지… 만드는데 딱 1시간”
[^26]: @[02:30] “코드 짜는 건 30분… 검색하는데 30분”
[^27]: @[02:33] “30분만 더 추가하면 회원 기능까지도 쉽게 만들 수 있을 것”
[^28]: @[02:37] “여러분들도… 신버전 써 보시면… 그냥 요거 쓰고 싶어질 걸요”
[^29]: @[02:43] “개발이 쉽고 편하다고 해서 사람들이 요걸로 갈아타진 않구요… 중요한 이유들이”
[^30]: @[02:51] “넥스 js는 풀스택 프레임워크입니다… 프론트엔드랑 백엔드 전부”
[^31]: @[02:58] “리액트 문법을 그대로 쓸 수 있고요”
[^32]: @[03:02] “리액트 신기술을 그대로 도입… 기존 리액트 개발자들이 매우 쉽게 입문”
[^33]: @[03:07] “그게… 넥스트js를 가장 많이 선택하는 이유”
[^34]: @[03:12] “이번 버전부터는 파일과 폴더만들면 자동으로 html 페이지… 생성”
[^35]: @[03:18] “서버 기능… DB 연결… 회원 인증… 쉬워진 편”
[^36]: @[03:22] “클라이언트 사이드 렌더링도 자유롭게”
[^37]: @[03:26] “자바스크립트가 안 들어가 있는 아주 빠른 페이지도… 쉽게”
[^38]: @[03:30] “서버 데이터 캐싱 같은 것도 가능”
[^39]: @[03:34] “폰트랑 이미지 최적화… 되게 빠른 사이트”
[^40]: @[03:40] “비슷한 프레임목… 리믹스… 벨트 킷… 녹스트”
[^41]: @[03:43] “설문조사 결과… 다른 프레임웍들은 만족도가… 떨어지는데 얘는 안떨어지죠”
[^42]: @[03:47] “그냥 넥스트… 선택하시면 되고요”
[^43]: @[03:51] “주식 같은 거… 어떤 거 사는게 좋아요”
[^44]: @[03:55] “사람들이 많이 찾고 언플… 잘하는 주식”
[^45]: @[03:59] “앞으로 5년… 넥스트 JS… 저점 매수”
[^46]: @[04:07] “물론 단점도 있습니다”
[^47]: @[04:12] “폴더 기반 라우팅… 예약 파일이 너무 많아… 복잡”
[^48]: @[04:13] “리액트에 미완성 기능들을 도입… 귀찮은 점”
[^49]: @[04:24] “클라이언트 컴포넌트랑 서버 컴포넌트를 구분… 귀찮”
[^50]: @[04:29] “웹 소켓이나 웹 artc… 서버 한 대를 더 만드셔야”
[^51]: @[04:35] “풍부한 서버 기능… 별로 없고… html 렌더링 하나만 잘하는 느낌”
[^52]: @[04:40] “요즘은 그냥 그게 가장 중요… 별 상관 없을 것”
[^53]: @[04:46] “이번 강의… 신버전… 앞으로 진행할 강의에서는 신버전”
[^54]: @[04:55] “프로젝트 두 개 만들어 볼 겁니다”
[^55]: @[04:56] “쿠팡 후레쉬… 게시판”
[^56]: @[05:00] “간지… 멋있는 프로젝트… 받아쓰기… 실력에 별 도움 안 되고요”
[^57]: @[05:06] “혼자서 알아서 코드 짜는 법… 목표… 직관적이고 심플한 프로젝트”
[^58]: @[05:12] “강의 레벨은 htmlcss 자바스크립트 기초 아는 분들”
[^59]: @[05:18] “기초 실력… 기대치… 매우 낮기 때문에… 걱정”
[^60]: @[05:26] “리액트 문법은 미리 알면 좋은데… 몰라도 시작”
[^61]: @[05:30] “다음 시간에 프로젝트 설치”

← 프로젝트에서 보기