서버액션 / RSC랜더링

좋아!
“서버 액션, RSC 렌더링”이라는 말이 헷갈릴 수 있으니까,
이해할 수 있게 정말 쉽고 구체적으로 풀어서 설명해줄게.

---

🎯 핵심 요약 먼저

“직접 처리한다” = 브라우저가 하지 않고 Next.js 서버가 그 일을 전부 대신 해준다는 뜻

이걸 바탕으로 두 가지를 쉽게 설명해볼게:

• 서버 액션 (쓰기)
• RSC 렌더링 (읽기)

---

🧩 1️⃣ RSC 렌더링 (읽기 작업을 서버가 직접 처리)

✔ 기존(클라이언트 방식)

브라우저가:

1. HTML 받음
2. JS 다운로드
3. JS 실행
4. fetch()로 API 호출
5. 데이터 응답받음
6. 화면 렌더링

브라우저가 직접 해야 하는 일이 매우 많았음.

---

✔ Server-First 방식(RSC)

브라우저: “이 페이지 보여줘!”
Next.js 서버: “오케이, 내가 직접 가져올게.”

서버가 하는 일:

1. DB/백엔드에 직접 데이터 요청
2. 데이터를 받아옴
3. React 컴포넌트를 서버에서 렌더링해 HTML로 만듦
4. HTML을 브라우저에 바로 전달

브라우저는 그냥 HTML을 받아 보는 것만 하면 됨.

---

🎨 비유

예전: 손님이 주방 들어가서 재료 가져와서 요리까지 해옴
지금: 손님이 요청 → 사장님이 요리해서 접시에 담아 바로 가져다줌

→ 이게 RSC 렌더링을 서버가 직접 처리하는 개념!

---

🧩 2️⃣ 서버 액션 (쓰기 작업을 서버가 직접 처리)

✔ 기존(클라이언트 방식)

브라우저가:

1. 이벤트 핸들러에서 fetch POST 요청 작성
2. 요청 payload 수동으로 구성
3. 응답 처리
4. 실패/성공 처리
5. 상태 업데이트
6. 화면 리렌더링

프론트 코드와 복잡한 비동기 흐름이 매우 많음.

---

✔ Server-First 방식(Server Actions)

브라우저: <form> 제출
Next.js 서버: “오케이, 내가 직접 처리할게.”

서버가 하는 일:

1. form 데이터 받음
2. 서버에서 실행되는 함수(Server Action) 호출
3. DB 업데이트 / 인증 확인 / 외부 API 호출 등 수행
4. 성공/실패 처리
5. 새로운 화면까지 서버에서 렌더링해 다시 브라우저로 전달

브라우저는 그냥 form 제출만 함

---

🎨 비유

예전: 손님이 주방 들어가서 재료 섞고, 굽고, 확인하고 요리까지 해야 했음
지금: 손님은 주문서만 제출 → 사장님이 알아서 요리하고 결과만 가져다줌

→ 이게 서버 액션을 서버가 직접 처리하는 개념!

---

💡 왜 “직접 처리”라는 표현을 쓸까?

이전에 읽기·쓰기 모두 브라우저가 직접 해야 했어.
즉,

• 데이터 요청
• 응답 처리
• 화면 렌더링
• 에러 처리
• 비동기 처리
• 상태 업데이트

이런 모든 “처리” 과정을 브라우저가 맡음 → 복잡, 느림, 보안 취약

지금은 이 모든 것을 브라우저 대신 Next.js 서버가 직접 처리함.

그래서 “직접 처리한다”라고 표현한 거야.

---

📘 끝의 3줄 요약

1. RSC 렌더링 = 화면을 만들기 위한 데이터 가져오기와 UI 조립을 서버가 직접 함.
2. 서버 액션 = 폼 제출 뒤 DB 저장/검증 같은 로직을 서버가 직접 실행함.
3. 즉, 브라우저는 단순히 요청하고 결과만 받으면 되며, 복잡한 처리는 모두 Next.js 서버가 담당함.

---

좋아! Server-First 구조에서 “읽기(RSC)”와 “쓰기(Server Action)”가 어떻게 흐르는지
프론트 주니어도 한 번에 이해할 수 있게 그림으로 설명해줄게.

---

🧩 1. 읽기(Read) – RSC 요청 흐름도

브라우저가 페이지를 요청할 때 발생하는 흐름

[브라우저]
     │   "페이지 보여줘!"
     ▼
[Next.js 서버]
     │   RSC 실행 (서버에서 React 컴포넌트 렌더링)
     │   DB / API에서 데이터 직접 가져옴
     ▼
[Next.js 서버]
     │   완성된 HTML 생성
     ▼
[브라우저]
     │   HTML 그대로 받음
     ▼
화면 표시 (JS 없어도 가능)

👉 중요 포인트

• 브라우저는 그냥 요청만 하고 데이터 fetch 안 함
• Next.js 서버가 DB까지 접근해서 화면을 만들어 제공함

---

🧩 2. 쓰기(Write) – Server Action 요청 흐름도

브라우저에서 <form action={...}> 제출할 때 흐름

[브라우저]
     │   폼 제출 (form submit)
     ▼
[Next.js 서버]
     │   서버 액션(Server Action) 실행
     │   ├ DB 저장
     │   ├ 인증 체크
     │   └ 외부 API 요청
     ▼
[Next.js 서버]
     │   새로운 UI를 다시 RSC로 렌더링
     ▼
[브라우저]
     │   갱신된 화면(HTML)을 전달받음
     ▼
업데이트된 화면 표시

👉 중요 포인트

• 브라우저는 fetch/axios 코드를 하나도 안 씀
• 서버가 폼 데이터를 받고 바로 로직 실행 + 새로운 UI까지 만들어 반환함
• 브라우저는 그저 “제출 → 화면 받기”만 할 뿐

---

🧩 전체 구조를 한눈에 보는 큰 그림

┌───────────────────┐
│      브라우저      │
│ (요청하고 결과받음) │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│    Next.js 서버    │  ← 우리가 "서버"라고 부르는 것
│  (읽기·쓰기 전부 처리) │
│ - RSC 렌더링        │
│ - 서버 액션         │
│ - DB 접근           │
│ - 인증/검증         │
│ - HTML 생성         │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│   DB / 백엔드 API  │
└───────────────────┘

👉 브라우저는 데이터 처리·상태 관리·비동기 관리에서 거의 해방됨
👉 Next.js 서버가 모든 “어려운 일”을 맡아서 웹 앱이 더 빠르고 안전해짐

* gpt 를 이용해 작성되었습니다.