요즘 프론트엔드 생태계를 보면 한 가지 흐름은 꽤 분명하다.

Next.js는 시장 표준에 수렴하는 방향으로 확장되고 있고, Nuxt 4는 명시성과 예측 가능성을 강화하는 방향으로 진화하고 있다.

흥미로운 점은 이 차이가 단순한 기술 취향의 문제가 아니라,

👉 대규모 조직에서의 사고 비용과 운영 방식에서 차이가 드러난다는 것이다.

이 글에서는 다음 관점을 중심으로 정리한다.

• 대규모 팀에서의 사고 비용 차이
• 디버깅 관점에서의 현실적인 차이
• RSC(React Server Components)는 장기적으로 옳은 선택인가
• 그럼에도 불구하고 대기업들이 Next.js를 계속 쓰는 이유

1. Nuxt 4 vs Next.js — 경계를 대하는 철학의 차이

Nuxt 4: 경계를 드러내는 방향

Nuxt 4는 “이 코드는 어디서 실행되는가?”를 구조적으로 드러내는 방향으로 발전하고 있다.

• server/ 디렉토리
• .client.ts, .server.ts
• plugins/*.client.ts

파일 구조 자체가 실행 환경을 설명한다.

// server/api/user.get.ts
export default defineEventHandler(async () => {
  return {
    name: 'Kim',
    from: 'server'
  }
})

👉 경계가 코드보다 먼저 보인다.

Next.js: 경계를 암묵적으로 관리하는 방향

Next.js에서는 동일한 컴포넌트 문법 안에서 서버와 클라이언트가 섞인다.

• 기본은 Server Component
• 필요할 때 'use client' 선언
• 경계는 트리 구조를 따라 전파됨

👉 경계는 존재하지만 눈에 잘 띄지 않는다.

2. 대규모 팀에서의 사고 비용 차이

핵심 요약

• Nuxt 4: 사고 비용이 초기에 들고 이후엔 거의 증가하지 않는다
• Next.js: 사고 비용이 _누적_되며 프로젝트 규모에 따라 증가한다

Nuxt 4: 사고 비용이 공간적으로 분리됨

Nuxt 4에서는 파일 위치와 확장자만 봐도 실행 환경이 결정된다.

// server/api/user.get.ts
export default defineEventHandler(async () => {
  // 서버에서만 실행 가능
  const users = await getUsersFromDB()
  return users
})

// composables/useAuth.client.ts
export const useAuth = () => {
  // 브라우저 API 사용 가능
  const token = localStorage.getItem('token')
  return token
}

<!-- pages/profile.vue -->
<script setup>
const { data } = await useFetch('/api/user')
</script>

• 서버 / 클라이언트 코드가 물리적으로 분리됨
• 코드 리뷰 시 “이게 어디서 도는 코드지?”라는 질문이 사라짐

👉 인지 모델이 단순하고 고정적

Next.js: 사고 비용이 시간적으로 누적됨

Next.js에서는 동일한 컴포넌트 문맥 안에서 실행 환경을 계속 추적해야 한다.

// app/page.tsx (Server Component)
import ClientButton from './ClientButton'

export default async function Page() {
  const data = await fetchData() // 서버 실행
  return <ClientButton data={data} />
}

// ClientButton.tsx
'use client'

export default function ClientButton({ data }: { data: any }) {
  // data는 직렬화 가능해야 함
  return <button>{data.title}</button>
}

// ❌ 실수하기 쉬운 예
export default function Broken() {
  const [state, setState] = useState(0) // ❌ Server Component
  return null
}

개발자는 항상 다음을 머릿속에서 추적해야 한다:

• 이 파일은 Server인가 Client인가?
• 부모 컴포넌트의 실행 환경은?
• props는 직렬화 가능한가?
• 이 fetch는 캐시되는가?

👉 실행 모델에 대한 이해도에 따라 생산성 격차가 커짐

3. 디버깅 관점에서의 차이

Nuxt 4: 경우의 수가 적다

• 파일 위치 = 실행 환경
• 에러 원인 파악이 직관적

// *.client.ts
window.localStorage // OK

// server/*
window.localStorage // ❌ 즉시 판단 가능

👉 환경 추론이 필요 없다

Next.js: 실행 모델부터 추적해야 한다

자주 마주치는 상황:

• window is not defined
• Hooks can only be used in Client Components
• 직렬화 불가 props 에러
• fetch 캐시로 인한 데이터 미갱신

디버깅 순서:

1. 이 파일에 'use client'가 있나?
2. 부모는 Server Component인가?
3. props는 직렬화 가능한가?
4. fetch cache 옵션은?

👉 문제 해결 이전에 실행 모델을 해석하는 비용이 발생한다

4. RSC는 장기적으로 옳은 선택인가?

결론부터 말하면

RSC는 기술적으로는 옳다

**하지만 모든 조직에 동일하게 친화적인 선택은 아니다**

RSC가 해결하려는 문제

• 과도한 JS 번들
• 불필요한 hydration
• 서버에서 가능한 작업의 클라이언트 이전

👉 문제 인식 자체는 정확하다.

하지만 RSC의 비용

• UI 코드와 실행 위치가 분리됨
• React 생태계에 강하게 락인됨
• 숙련도 격차가 매우 큼

// 컴포넌트처럼 보이지만 서버 코드
export default async function Component() {}

👉 기존 UI 중심 사고와는 다른 인지 모델을 요구

장기 전망

• RSC 개념 자체는 남을 가능성이 높다
• 하지만 현재 형태가 그대로 유지되긴 어렵다
• 결국 다음 요소들이 강화될 수밖에 없다
  • 경계 시각화
  • 명시적 어노테이션
  • 컴파일 타임 경고

👉 장기적으로는 명시성과 경계 가시화를 강화하는 방향으로 수렴할 가능성

5. 그럼에도 대기업들이 Next.js를 계속 쓰는 이유

이유는 개별 기술 선택보다 조직 구조에 가깝다

1) 책임 회피가 가능한 선택

“왜 Next.js를 썼나요?”

→ “업계 표준이니까요.”

👉 문제 발생 시 선택의 책임이 개인에게 귀속되지 않는다.

2) 인력 수급이 압도적으로 쉽다

• React 경험자 = 즉시 투입 가능
• 외주, 파견, 글로벌 협업에 유리

👉 대기업에 매우 중요한 요소

3) 플랫폼 패키징

• 배포
• CDN
• 캐시
• 관측성
• SLA

👉 프레임워크라기보다 서비스

4) 내부 설득 비용이 낮다

• 임원, 비개발자 설득이 쉽다
• “Google, Netflix도 씁니다” 한 줄이면 끝

5) 기술 부채 관리 방식

대기업은:

• ❌ 부채를 없애려 하지 않는다
• ✅ 예측 가능한 부채를 원한다

Next.js는:

• 문제 패턴이 이미 알려져 있음
• 해결책과 컨설턴트가 존재

6. 그래서 무엇이 정답인가?

정답은 없다. 전제의 차이만 있을 뿐이다.

마무리

Next.js는 지금 웹 생태계의 ‘AWS’에 가깝고

**Nuxt 4는 잘 설계된 내부 플랫폼에 가깝다**

대세를 따르는 선택은 충분히 합리적이다.

다만 중요한 건 대세이기 때문에 감수해야 할 비용을 알고 선택하는 것이다.

이 차이를 조금 더 멀리서 보면, 이는 기술 우열의 문제가 아니라 조직 구조의 반영에 가깝다.

조직이 어떻게 소통하고, 책임을 어떻게 나누며, 암묵적 합의를 얼마나 허용하는가는 결국 시스템의 형태로 굳어진다. 이는 오래전부터 알려진 콘웨이의 법칙이 말하는 바와 다르지 않다.

Next.js와 Nuxt 4의 차이 역시, 서로 다른 조직이 서로 다른 문제를 해결하려다 도달한 결과라고 보는 편이 자연스럽다.

기술보다 어려운 건 언제나 조직과 사람이니까.