D-3: 서버 vs 클라이언트 컴포넌트 ① — 경계를 긋는다

질문 하나로 시작할게요.

지금 우리 앱에는 컴포넌트가 아홉 개 있습니다. 피드, 탐색, 프로필, 바깥 껍데기, 프로필 껍데기, 머리말, 검색칸, 없는 주소, 터진 화면.

이 중에 브라우저에서 도는 건 몇 개일까요?

안녕하세요, 홍순구입니다. 아마 "아홉 개 다요"라고 답하셨을 거예요. React로 만들었고 React는 브라우저에서 도는 것이니까, 당연히 전부 브라우저에서 돈다. 순수 자바스크립트만 하다 넘어왔다면 이보다 자연스러운 답이 없습니다.

답은 셋입니다.

나머지 여섯은 브라우저에 자바스크립트가 아예 안 갔어요. 우리가 지난 시간에 그렇게 만들어놓고도 몰랐던 겁니다.

셋이 무엇인지는 사실 이미 아십니다. 지난 시간에 파일 세 개(머리말, 검색칸, 에러 화면)에 'use client' 한 줄을 붙였는데, 그때마다 "이게 무엇을 가르는지는 다음에"라고 미뤄뒀습니다.

오늘 그 한 줄을 정면으로 다룹니다.

💡 오늘 수업의 핵심 — "브라우저로 보낼 것을 우리가 고릅니다"

지금까지 여러분이 만든 React 앱은 전부 브라우저에서 돌았습니다. index.html이 거의 비어 있고, 자바스크립트가 도착해야 화면이 그려졌죠. C-10에서 "검색 엔진이 흰 종이를 본다" 고 했던 그 구조입니다.

Next는 반대라서, 아무 표시도 안 하면 서버에서 돕니다. 브라우저에서 돌게 하려면 그렇게 하겠다고 따로 말해야 하는데, 그러다 보니 무엇을 서버에 두고 무엇을 브라우저로 보낼지 새로운 결정이 하나 생깁니다. 이 선을 어디에 긋느냐로 사용자가 받는 바이트가 달라지고, 심지어 화면에 안 보이는 데이터까지 딸려 갈 수 있습니다.

오늘은 그 선을 긋는 법만 다룹니다. 서버가 데이터를 직접 가져오는 이야기는 다음 시간이에요.

🎯 학습 목표

• 지금까지 만든 컴포넌트가 어디서 돌고 있었는지 직접 확인합니다.
• 'use client' 한 줄이 파일 하나가 아니라 어디까지 영향을 주는지 실험으로 알아냅니다.
• 경계 밖으로는 자바스크립트가 안 간다는 것을 바이트로 잽니다.
• 좋아요 버튼만 브라우저로 내려보내고, 그 값이 얼마인지 확인합니다.
• 경계를 건널 수 있는 값과 없는 값을 가릅니다.

 오늘의 여정

 1. 이미 서버에서 돌고 있었다   심어서 확인한다
 2. 'use client' 가 긋는 선     파일 하나가 아니라 그 아래 전부
 3. 경계 밖으로는 JS 가 안 간다  실제로 받는 바이트를 잰다
 4. 좋아요만 브라우저로          경계를 잎에 둔다
 5. 경계를 건너는 값             함수는 못 건넌다

Step 1: "이미 서버에서 돌고 있었습니다"

셋과 여섯을 갈라봅시다

app/ 아래를 훑어보면 이렇습니다.

 app/layout.tsx                  표시 없음
 app/page.tsx                    표시 없음
 app/explore/page.tsx            표시 없음
 app/[username]/layout.tsx       표시 없음
 app/[username]/page.tsx         표시 없음
 app/not-found.tsx               표시 없음
 app/[username]/error.tsx        ← 'use client'
 app/components/HeaderNav.tsx    ← 'use client'
 app/components/UserSearch.tsx   ← 'use client'

표시가 붙은 셋에는 공통점이 있는데, 전부 훅(usePathname, useRouter, useState)을 쓰고 에러 화면은 버튼을 눌러야 하니 onClick이 필요하죠.

나머지 여섯에는 훅도 없고 onClick도 없습니다. 그냥 데이터를 받아 화면 모양을 만들어 돌려줄 뿐이라, 그 여섯은 어디서 도는 걸까요? 말로 설명하는 것보다 심어서 보는 게 빠릅니다.

심어서 확인해봅시다

app/page.tsx에 줄 하나만 넣어보세요.

// apps/web-next/app/page.tsx
import { feedPosts } from '@/lib/posts';

export default function HomePage() {
  console.log('[서버] 피드를 그립니다');

  return (
    <main className="mx-auto max-w-xl p-6">
      <h1 className="mb-4 text-xl font-bold">피드</h1>

프로필에도 하나 넣습니다. 이쪽은 누구의 프로필인지도 같이 찍어볼게요.

// apps/web-next/app/[username]/page.tsx
export default async function ProfilePage({ params }: PageProps<'/[username]'>) {
  const { username } = await params;
  console.log('[서버] 프로필을 그립니다:', username);
  const posts = postsByUsername(username);

그리고 빌드합니다.

npm run build

빌드 로그를 잘 보세요. 이런 줄이 지나갑니다.

 ✓ Compiled successfully in 281ms
 [서버] 피드를 그립니다

브라우저를 열지도 않았는데 벌써 찍혔어요. HomePage가 빌드하는 동안 한 번 돌았다는 뜻입니다.

요청할 때마다 도는 것도 있습니다

이번엔 서버를 띄우고 주소를 몇 개 두드려봅시다.

npm run start

/jaehoon, /minji, 그리고 / 순서로 들어가보세요. 그리고 브라우저가 아니라 서버를 띄운 터미널을 봅니다.

 [서버] 프로필을 그립니다: jaehoon
 [서버] 프로필을 그립니다: minji

두 줄만 찍혔습니다. 프로필은 들어갈 때마다 찍히는데, 피드는 아무리 들어가도 다시 안 찍혀요. 빌드 때 이미 한 번 돌아서 결과를 만들어뒀기 때문입니다.

이 갈림은 사실 지난 시간에 이미 보셨어요. 빌드 표의 동그라미와 물결 표시요.

 ○ /            빌드 때 미리 그려둔다
 ƒ /[username]  요청이 올 때 그린다

동그라미는 미리 그려두는 것, 물결은 요청을 받고 그리는 것. 우리가 심은 로그가 정확히 그 표대로 찍혔습니다.

그런데 브라우저에는 한 글자도 안 갔습니다

여기가 오늘의 출발점입니다. 브라우저 개발자 도구의 콘솔을 열어보세요.

비어 있습니다.

더 확인해볼까요. 응답으로 받은 HTML 안에도, 내려받은 자바스크립트 파일 안에도 그 문구가 없습니다.

 [서버] 프로필을 그립니다  가 어디에 있나

   서버 터미널        →  찍힌다
   브라우저 콘솔      →  아무것도 없음
   응답 HTML 안       →  0 건
   내려받은 JS 안     →  0 개 파일

console.log는 코드입니다. 그 코드가 브라우저로 갔다면 어떤 형태로든 자바스크립트 파일 안에 남아 있어야 해요. 그런데 없습니다.

컴포넌트가 브라우저로 안 간 겁니다. 서버에서 실행돼서, 그 결과인 글자만 브라우저로 갔어요.

⚠️ 확인이 끝났으면 심어둔 console.log 두 줄은 지워주세요. 앞으로 계속 쓸 코드가 아닙니다.

그래서 이름이 서버 컴포넌트입니다

이게 서버 컴포넌트(Server Component)입니다. 서버에서 실행되고, 브라우저에는 실행 결과만 보내는 컴포넌트인데, Next에서는 이게 기본값이라 아무 표시도 안 하면 서버 컴포넌트가 돼요. 우리가 여섯 개를 서버 컴포넌트로 만든 게 아니라, 아무것도 안 했더니 서버 컴포넌트가 된 겁니다.

순수 자바스크립트에서 React로 넘어오신 분들에게 이건 꽤 큰 재배선이에요. "React 컴포넌트 = 브라우저에서 도는 것"이라는 전제가 여기서 깨집니다. C-1부터 C-10까지 만든 SPA에서는 그 전제가 맞았어요. 그때는 브라우저 말고 코드가 돌 곳이 없었으니까요.

Next에는 돌 곳이 두 군데입니다. 그래서 고를 수 있게 됐고, 고를 수 있게 되니 고르는 법을 알아야 합니다.

💡 한 줄 정리

아무 표시도 안 한 컴포넌트는 서버에서 돌고 브라우저에는 결과만 갑니다. 지금까지 만든 아홉 개 중 여섯이 그랬어요.

Step 2: "'use client'가 긋는 선"

세 파일에 붙어 있는데, 하나는 이상합니다

지시어가 붙은 셋을 다시 봅시다.

 app/[username]/error.tsx        'use client'
 app/components/HeaderNav.tsx    'use client'
 app/components/UserSearch.tsx   'use client'

앞의 둘은 이유가 분명해요. 에러 화면은 버튼을 눌러야 하고, 머리말은 usePathname을 쓰는데, 세 번째는 좀 이상합니다. UserSearch는 아무 데서도 직접 안 불리고, HeaderNav가 불러다 씁니다.

// apps/web-next/app/components/HeaderNav.tsx
'use client';

import Link from 'next/link';
import { usePathname } from 'next/navigation';
import { UserSearch } from './UserSearch';

여기서 질문이 하나 생깁니다. HeaderNav가 이미 브라우저에서 도는데, 거기서 불러 쓰는 UserSearch에 그 한 줄이 또 필요할까요?

지워보면 압니다.

실험 A — 검색칸에서만 지워본다

app/components/UserSearch.tsx의 'use client'; 한 줄만 지우고 빌드해보세요. HeaderNav는 그대로 둡니다.

npm run build

 ✓ Compiled successfully in 237ms

아무 일도 안 일어납니다. 화면도 그대로고, 검색칸에 글자를 쳐도 잘 되고, 이동 버튼도 멀쩡해요.

이상하죠. UserSearch는 useRouter와 useState를 쓰는데, 브라우저에서 돌겠다는 표시가 없는데도 잘 돕니다.

실험 B — 머리말에서도 지워본다

이번엔 HeaderNav의 'use client';도 지웁니다. 이제 두 파일 다 표시가 없어요.

 Error: Turbopack build failed with 3 errors:

 Error: You're importing a module that depends on `usePathname` into a
 React Server Component module. This API is only available in Client
 Components. To fix, mark the file (or its parent) with the
 `"use client"` directive.

 Error: You're importing a module that depends on `useRouter` into a
 React Server Component module. ...

 Error: You're importing a module that depends on `useState` into a
 React Server Component module. ...

빌드가 실패했는데, 에러가 세 개라는 걸 보세요.

• usePathname — 이건 HeaderNav 것입니다.
• useRouter — 이건 UserSearch 것이에요.
• useState — 이것도 UserSearch 것입니다.

우리는 방금 HeaderNav에서 한 줄을 지웠을 뿐인데, UserSearch가 같이 무너졌습니다.

실험 A의 답이 여기 있습니다

두 실험을 나란히 놓으면 답이 나옵니다.

 실험 A   HeaderNav  'use client' 있음
          UserSearch 없음               →  둘 다 멀쩡

 실험 B   HeaderNav  없음
          UserSearch 없음               →  둘 다 터짐 (에러 3건)

UserSearch의 운명이 자기 파일이 아니라 HeaderNav에 달려 있었으니, 'use client'는 그 파일 하나에만 붙는 표시가 아니라 그 파일에서 시작해서, 거기서 불러다 쓰는 것들까지 전부 브라우저 쪽으로 끌고 가는 셈입니다.

 app/layout.tsx                     서버
   │
   └─ HeaderNav.tsx    'use client'  ←── 선은 여기서 그어진다
        │
        └─ UserSearch.tsx            ←── 표시가 없어도 딸려 들어온다

Next의 에러 문구가 이미 그 이야기를 하고 있었는데, 다시 읽어보세요.

To fix, mark the file (or its parent) with the "use client" directive.

그 파일에 붙이거나, 부모에 붙이거나. 부모에 붙이면 자식은 안 붙여도 된다는 뜻입니다.

그럼 왜 검색칸에도 붙여뒀을까요

지워도 되는데 왜 붙어 있을까요. 실무에서 셋 다 붙여두는 이유가 있습니다.

UserSearch는 지금 HeaderNav 안에서만 쓰이지만, 나중에 다른 데서 쓸 수도 있어요. 그때 그 다른 곳이 서버 컴포넌트라면 그 순간 터지는데, 파일 하나만 보고는 "이게 안전한가"를 알 수 없는 겁니다.

훅을 쓰는 파일에는 그냥 붙여두세요. 중복이 있어도 아무 손해가 없고, 파일 하나만 봐도 어디서 도는지 알 수 있습니다.

⚠️ 실험이 끝났으면 두 파일의 'use client';를 원래대로 되돌려주세요. 빌드가 다시 통과해야 합니다.

💡 한 줄 정리

'use client'는 파일 하나가 아니라 거기서부터 불러다 쓰는 것 전부에 걸리기 때문에, 이 한 줄을 어디에 두느냐가 곧 "무엇을 브라우저로 보낼 것인가"의 답이 됩니다.

Step 3: "경계 밖으로는 자바스크립트가 안 갑니다"

손해가 얼마인지 재봅시다

앞 Step 끝에서 한 화면을 통째로 브라우저로 보내면 손해라고 했지만, 얼마나 손해인지는 안 말했습니다.

느낌으로 말하면 안 됩니다. 재봅시다.

그런데 재는 법부터 정해야 합니다

⚠️ 검색해서 나오는 옛 자료들은 대부분 이렇게 가르칩니다. "next build를 하면 라우트 표에 First Load JS 열이 나오니 그걸 보라."

Next 16에서는 그 열이 없습니다. 직접 확인해보세요.

 Route (app)
 ┌ ○ /
 ├ ○ /_not-found
 ├ ƒ /[username]
 └ ○ /explore

주소와 동그라미/물결 표시뿐이고, 숫자가 아예 안 나옵니다. 그래서 우리는 브라우저가 실제로 받는 것을 직접 세겠습니다. 어차피 그게 우리가 알고 싶은 값이라, 서버가 보낸 HTML에서 자바스크립트 파일 목록을 뽑고 그 파일들의 크기를 더하면 됩니다.

서버를 띄워두고 이렇게 하세요.

PORT=3000
ROUTE=/explore

curl -s "http://localhost:$PORT$ROUTE" \
  | grep -oE 'src="/_next/static/chunks/[^"]+"' \
  | sed 's/src="//; s/"//' | sort -u \
  | xargs -I{} curl -s -o /dev/null -w '%{size_download}\n' "http://localhost:$PORT{}" \
  | paste -sd+ - | bc

⚠️ 재기 전에 그 포트를 우리 앱이 잡고 있는지 확인하세요. 다른 프로그램이 이미 3000을 쓰고 있으면 npm run start는 조용히 죽고, 위 명령은 이미 돌고 있던 남의 앱을 재게 됩니다. 숫자는 멀쩡하게 나오는데 우리 앱 값이 아니라서, 서버를 띄운 터미널에 EADDRINUSE가 없는지 먼저 보세요.

기준선

지금 상태에서 세 주소를 재면 이렇습니다.

숫자가 꽤 크지만, 이 중 대부분은 React와 Next 자체라서 어떤 앱을 만들어도 깔리는 바닥이에요. 우리가 정하는 건 이 바닥이 아니라 그 위에 얼마를 더 얹느냐이므로, 절대값 말고 차이를 봐야 합니다.

탐색 화면을 통째로 브라우저로 보내봅니다

app/explore/page.tsx 맨 위에 딱 한 줄을 넣습니다.

// apps/web-next/app/explore/page.tsx
'use client';

import { allPosts } from '@/lib/posts';

export default function ExplorePage() {

다시 빌드하고 재보세요.

한 줄 넣었더니 2 KB가 늘었는데, /는 한 바이트도 안 변했어요. 선이 그 화면에만 그어졌으니까요.

그런데 늘어난 2 KB의 정체가 문제입니다

새로 생긴 자바스크립트 파일 안에서 이 문장을 찾아보세요.

grep -l "한강 노을이 미쳤다" .next/static/chunks/*.js

나옵니다. 게시물 데이터가 자바스크립트 파일 안에 통째로 실려 있어요.

바꾸기 전에 같은 명령을 돌리면 한 건도 안 나옵니다. 서버가 읽고 서버가 그렸으니 브라우저는 그 데이터를 볼 일이 없었거든요.

여기서 한 번 더 보셔야 할 게 있습니다. 탐색 화면은 content를 화면에 안 그립니다.

// apps/web-next/app/explore/page.tsx
<li key={post.id} className="aspect-square rounded bg-black/5 p-3 text-sm">
  <p className="font-semibold">@{post.username}</p>
  <p className="mt-1 text-black/60">좋아요 {post.likeCount}</p>
</li>

이름과 좋아요 수만 씁니다. 글 내용은 안 써요.

그런데도 브라우저까지 갔습니다. allPosts 배열이 통째로 경계를 건넜기 때문이에요. 우리가 그중 두 필드만 쓴다는 건 아무도 모릅니다.

 서버 컴포넌트일 때
   allPosts ──→ 서버가 읽고 그린다 ──→ HTML 에 결과 글자만
                                        JS 에는 0 건

 'use client' 일 때
   allPosts ──→ JS 파일에 통째로 실린다 ──→ 브라우저가 받아서 그린다
                                            안 쓰는 글 내용까지 함께

지금은 게시물이 열 장이라 2 KB 지만, 실제 서비스라면 어떨지, 그리고 그 데이터에 사용자 이메일이나 전화번호 같은 게 섞여 있었다면 어땠을지 생각해보세요.

경계를 넓게 그으면 보내려던 것보다 많이 보내게 됩니다.

HTML은 왜 줄었을까요

표에서 HTML이 2,401 B 줄어든 걸 보셨을 거예요. 데이터가 사라진 게 아니라 옮겨간 겁니다.

서버 컴포넌트일 때는 서버가 그린 결과가 HTML에 실립니다. 클라이언트 컴포넌트가 되면 그 부분이 "이 파일을 받아서 브라우저가 그려라"라는 짧은 표시로 바뀌고, 대신 데이터와 코드가 자바스크립트 쪽으로 갑니다.

HTML에서 2.4 KB를 덜고 자바스크립트로 2 KB를 옮긴 셈이에요. 그런데 이 교환은 손해입니다. HTML은 받는 즉시 화면이 되지만, 자바스크립트는 받고 → 실행하고 → 그려야 화면이 되거든요.

⚠️ 확인이 끝났으면 'use client'; 한 줄을 지워 원래대로 되돌려주세요.

💡 한 줄 정리

경계 밖에 있는 컴포넌트는 코드도 데이터도 브라우저로 안 갑니다. 경계를 넓게 그으면 화면에 안 쓰는 데이터까지 딸려 갑니다.

Step 4: "좋아요만 브라우저로"

지금 좋아요는 글자입니다

피드를 보면 좋아요 숫자가 있는데, 눌러도 아무 일이 안 일어납니다.

// apps/web-next/app/page.tsx
<p className="mt-2 text-sm text-black/60">좋아요 {post.likeCount}</p>

<p> 니까요. B-2에서 만들었던 그 토글을 여기서 되살릴 차례입니다.

누르면 상태가 바뀌어야 하니 useState가 필요하고, useState는 훅이니 브라우저에서 돌아야 합니다. 여기까진 정해져 있어요.

정하지 않은 건 어디에 선을 그을 것인가입니다. 피드 페이지 전체를 브라우저로 보낼 수도 있고, 버튼만 보낼 수도 있어요. Step 3에서 전자가 어떤 값을 치르는지 봤으니 후자로 갑니다.

버튼만 따로 떼어냅니다

// apps/web-next/app/components/LikeButton.tsx
'use client';

import { useState } from 'react';

// 이 화면에서 브라우저가 맡는 일은 이것 하나다.
// 카드의 나머지(사람 이름·글·격자)는 서버가 그려서 글자로 보낸다.
export function LikeButton({ likeCount, liked }: { likeCount: number; liked: boolean }) {
  const [pressed, setPressed] = useState(liked);
  const [count, setCount] = useState(likeCount);

  function toggle() {
    setPressed(!pressed);
    setCount(pressed ? count - 1 : count + 1);
  }

  return (
    <button
      type="button"
      aria-pressed={pressed}
      onClick={toggle}
      className="mt-2 text-sm text-black/60"
    >
      {pressed ? '♥' : '♡'} 좋아요 {count}
    </button>
  );
}

B-2에서 쓰던 것과 거의 같죠. 달라진 건 맨 위 한 줄뿐입니다.

aria-pressed를 붙인 이유는 E-7에서 다룬 그대로예요. 하트 모양만 바뀌고 글자는 그대로라, 눌렸는지 아닌지를 낭독기가 알 방법이 이것뿐입니다.

피드에서도 이 컴포넌트로 갈아 끼웁니다.

// apps/web-next/app/page.tsx
import { LikeButton } from '@/app/components/LikeButton';
import { feedPosts } from '@/lib/posts';

// 이 컴포넌트는 서버에서만 돈다. 브라우저로는 결과 글자만 간다.
export default function HomePage() {
  return (
    <main className="mx-auto max-w-xl p-6">
      <h1 className="mb-4 text-xl font-bold">피드</h1>
      <ul className="space-y-4">
        {feedPosts.map((post) => (
          <li key={post.id} className="rounded border border-black/10 p-4">
            <p className="font-semibold">@{post.username}</p>
            <p className="mt-1">{post.content}</p>
            <LikeButton likeCount={post.likeCount} liked={post.liked} />
          </li>
        ))}
      </ul>
    </main>
  );
}

HomePage에는 'use client'가 없습니다. 여전히 서버 컴포넌트예요. 서버 컴포넌트가 클라이언트 컴포넌트를 불러다 쓰는 건 아무 문제가 없습니다.

 HomePage             서버      데이터를 읽고 카드를 그린다
   └─ LikeButton      브라우저  ← 선은 여기서만 그어진다

값이 얼마나 붙었나

재봅시다.

453 바이트. 그리고 다른 두 화면은 한 바이트도 안 늘었습니다.

Step 3의 실험과 나란히 놓아보세요.

Step 3은 2 KB를 내고 아무 상호작용도 못 얻었습니다. Step 4는 그 4분의 1도 안 되는 값으로 실제 기능을 얻었어요.

같은 앱, 같은 빌드입니다. 달라진 건 선을 어디에 그었느냐 뿐이에요.

그런데 버튼은 이미 HTML 안에 있습니다

앞 Step의 🙋 에서 클라이언트 컴포넌트도 서버가 먼저 그린다고 했죠. 확인해봅시다.

curl -s http://localhost:3000/ | grep -o '<button' | wc -l
curl -s http://localhost:3000/ | grep -o 'aria-pressed' | wc -l

 <button       3개
 aria-pressed  2개
 ♡             2개

aria-pressed가 2개인 건 피드에 게시물이 두 장이기 때문이고, <button>이 3개인 건 머리말의 이동 버튼이 하나 더 있어서입니다.

자바스크립트가 도착하기 전에 이미 하트가 그려져 있습니다. 서버가 LikeButton을 한 번 실행해서 그 결과를 HTML에 담아 보냈어요.

그다음 자바스크립트가 도착하면 그 하트에 onClick을 붙이는데, 그때부터 눌립니다. 이게 하이드레이션이고, 'use client'는 "서버에서 빼라"가 아니라 "브라우저에도 보내라"라는 뜻이에요. 서버는 어차피 한 번 그려요.

💡 한 줄 정리

상호작용이 필요하면 그 부분만 떼어 브라우저로 보냅니다. 같은 기능이라도 선을 잎에 두면 4분의 1 값으로 끝나고, 다른 화면은 영향을 안 받습니다.

Step 5: "경계를 건너는 값"

아무거나 내려보내도 될까요

방금 서버에서 브라우저로 값을 두 개 내려보냈습니다.

// apps/web-next/app/page.tsx
<LikeButton likeCount={post.likeCount} liked={post.liked} />

숫자 하나, 참/거짓 하나. 잘 됐죠.

그렇다면 아무거나 내려보내도 될까요? 지금까지 React를 쓰면서 props에 뭘 넣든 문제된 적이 없었을 겁니다. 함수도 넣고, 객체도 넣고요.

여기서는 다릅니다.

함수를 내려봅시다

좋아요를 누를 때 부모가 뭔가 하고 싶다고 해봅시다. 흔한 패턴이죠. 콜백을 내려주면 됩니다.

// apps/web-next/app/page.tsx
<LikeButton
  likeCount={post.likeCount}
  liked={post.liked}
  onLike={() => console.log('좋아요')}
/>

LikeButton 쪽도 받아서 부르게 고칩니다.

// apps/web-next/app/components/LikeButton.tsx
export function LikeButton({ likeCount, liked, onLike }: { likeCount: number; liked: boolean; onLike: () => void }) {

타입 검사부터 돌려보세요.

npx tsc --noEmit

통과합니다. 에러 0건이에요. 타입만 보면 아무 문제가 없습니다.

빌드해봅니다.

npm run build

 Error occurred prerendering page "/"
 Error: Event handlers cannot be passed to Client Component props.
   {likeCount: 1240, liked: false, onLike: function onLike}
                                           ^^^^^^^^^^^^^^^
 If you need interactivity, consider converting part of this to a
 Client Component.

빌드가 멈췄는데, 화살표가 어느 prop 때문인지 정확히 짚어줘요.

타입이 통과했는데 왜 막힐까요

이 과목에서 비슷한 일을 여러 번 겪었습니다. A-6에서 "번들러는 타입체크를 안 한다"를 봤고, C-4에서 "테스트가 전부 초록인데 타입은 8건을 잡았다"를 봤죠.

이번엔 방향이 반대입니다. 타입은 통과하는데 실제로 막힙니다.

이유는 경계의 정체에 있어요. 서버에서 그린 결과는 브라우저로 갈 때 글자로 바뀌어서 갑니다. 네트워크를 건너야 하니까요. 1240은 글자로 쓸 수 있고 false도 쓸 수 있는데, 함수는 글자로 쓸 수가 없습니다.

 서버                        네트워크              브라우저
 likeCount: 1240   ──→   "1240"       ──→   1240        ✅
 liked: false      ──→   "false"      ──→   false       ✅
 onLike: () => {}  ──→   ???                            ❌

함수는 코드예요. 코드를 글자로 적어 보낸다 해도, 그 함수가 붙잡고 있던 바깥 값들은 같이 못 갑니다. 그래서 아예 막습니다.

타입 시스템은 이 사정을 모릅니다. TypeScript에게 () => void는 그냥 정상적인 타입이거든요. 경계는 타입이 아는 개념이 아닙니다.

그럼 JSON으로 바꿀 수 있는 것만 되나요

여기서 많이들 이렇게 외우는데, 틀립니다.

Date 객체를 내려보세요.

// apps/web-next/app/page.tsx
<LikeButton likeCount={post.likeCount} liked={post.liked} at={new Date(post.createdAt)} />

LikeButton에서 연도를 찍어봅니다.

{pressed ? '♥' : '♡'} 좋아요 {count} · {at.getFullYear()}

빌드가 통과합니다. 화면에 연도가 그대로 찍혀요.

JSON.stringify를 거치면 Date는 문자열이 되고 돌아올 때 Date로 안 살아나는데, 여기서는 살아나요. React는 자기만의 방식으로 값을 실어 나르고, 그 방식은 JSON보다 조금 더 똑똑합니다.

그러니 기준을 이렇게 잡으세요.

 건널 수 있다     숫자 · 문자열 · 참거짓 · 배열 · 평범한 객체 · Date · null
 못 건넌다        함수 · 클래스로 만든 인스턴스 · 화면 요소가 아닌 것

외우기보다, 막히면 빌드가 알려준다는 걸 기억하시는 게 낫습니다. 화살표까지 그려서 알려주니까요.

그럼 클릭은 어떻게 처리하나요

onClick은 어떻게 되는 거냐고 물으실 텐데, 우리 LikeButton을 다시 보세요.

// apps/web-next/app/components/LikeButton.tsx
  function toggle() {
    setPressed(!pressed);
    setCount(pressed ? count - 1 : count + 1);
  }

toggle은 LikeButton 파일 안에서 만들어졌습니다. 경계를 건넌 적이 없어요. 이미 브라우저 쪽에 있는 코드가 브라우저 쪽에서 함수를 만들어 쓰는 겁니다.

막히는 건 서버가 만든 함수를 브라우저로 보내려 할 때뿐이에요.

⚠️ 확인이 끝났으면 onLike와 at을 지워 원래대로 되돌려주세요. 빌드가 다시 통과해야 합니다.

💡 한 줄 정리

경계를 건너는 값은 글자로 옮겨 적을 수 있어야 합니다. 함수는 못 건너고, 타입 검사는 그걸 안 막아줍니다. 막아주는 건 빌드입니다.

마무리

오늘 시작은 질문 하나였습니다. 아홉 개 중 브라우저에서 도는 게 몇 개냐.

답이 셋이라는 것보다 중요한 건, 그 셋을 우리가 골랐다는 사실입니다. 지난 시간에는 훅을 쓰려니 어쩔 수 없이 붙였던 한 줄이었는데, 오늘 보니 그게 선을 긋는 행위였고, 그 선의 위치가 숫자로 나왔습니다.

 같은 기능, 다른 선

 페이지 통째로 브라우저   +2,003 B   상호작용 0개   데이터 유출 있음
 버튼 하나만 브라우저       +453 B   좋아요 토글    유출 없음

프레임워크가 좋은 선을 자동으로 골라주지 않습니다. 우리가 고릅니다.

오늘 배운 핵심 세 가지

💡 하나 — Next에서는 아무것도 안 하면 서버입니다. 브라우저에서 돌게 하려면 그렇게 하겠다고 따로 말해야 해요. C-1부터 만든 SPA와 정반대입니다.

💡 둘 — 'use client'는 파일 하나가 아니라 그 아래 전부에 걸립니다. 검색칸에서 지웠을 땐 아무 일도 없었지만 머리말에서 지우니 검색칸까지 무너졌죠. 선은 그 파일에서 시작해 불러다 쓰는 것들을 따라 내려갑니다.

💡 셋 — 경계를 건너는 값은 글자로 옮겨 적을 수 있어야 합니다. 함수는 못 건너고, 타입 검사는 그걸 안 막아줍니다. 막아주는 건 빌드예요.

다음 시간 예고

오늘 우리는 선을 그었습니다. 그런데 그 선의 서버 쪽에서 무엇을 할 수 있는지는 아직 안 봤어요.

지금까지 데이터는 전부 lib/posts.ts에 적어둔 상수였습니다. 진짜 서비스라면 어딘가에 물어봐서 가져와야 하죠. C-6에서 그걸 하려고 무엇이 필요했는지 떠올려보세요. 훅을 부르고, 로딩 상태를 만들고, 에러 상태를 만들고, 언제 다시 부를지 정하고요.

서버 컴포넌트에서는 그게 전부 필요 없습니다. 함수 안에서 그냥 기다렸다 받으면 됩니다.

지난 시간에 세 번에 한 번만 성공하는 흉내 서버를 만들어뒀는데, 그걸 진짜로 바꿉니다.

기다린다는 말이 나온 김에 하나 더요. 서버가 데이터를 기다리는 동안 사용자는 뭘 보고 있어야 할까요? 흰 화면일까요? 그 답이 파일 이름 하나로 정해집니다. D-1에서 파일 규칙 표를 볼 때 이름만 부르고 넘어간 것이 있었는데, 다음 시간에 그걸 씁니다.

과제

[구현] 탐색 화면에도 좋아요를

탐색 화면의 격자에도 좋아요 버튼을 붙여보세요. Step 4에서 만든 LikeButton을 그대로 쓰면 됩니다.

• 붙이기 전에 예상해보세요. /explore의 자바스크립트가 몇 바이트 늘까요? 피드는 게시물이 두 장이었고 탐색은 열 장입니다. 다섯 배 늘까요?
• 예상을 적어두고 나서 재보세요.
• /와 /jaehoon도 함께 재서, 안 건드린 화면이 정말 안 변했는지 확인하세요.

[구현] 머리말의 경계를 더 아래로 내리기

지금 HeaderNav는 파일 전체가 브라우저로 갑니다. 그런데 그 안을 뜯어보면 브라우저가 꼭 필요한 부분은 일부예요.

• HeaderNav 안에서 정말 브라우저가 필요한 부분이 어디인지 먼저 표시해보세요.
• 그 부분만 별도 컴포넌트로 떼어내고, HeaderNav 자신은 서버 컴포넌트로 되돌려보세요.
• 되돌린 뒤 빌드가 통과하는지, 화면이 그대로인지 확인하세요.
• 세 주소의 자바스크립트를 다시 재서 값이 얼마나 줄었는지 적어보세요. ⚠️ 줄지 않았다면 그것도 결과입니다. 왜 안 줄었을지 생각해보세요.

[탐구] 무엇이 경계를 건너나

Step 5에서 함수는 못 건너고 Date는 건넌다는 걸 봤습니다. 나머지도 직접 확인해서 표를 채워보세요.

• 배열 · 평범한 객체 · null · undefined · Map · Set · 정규식 · 클래스로 만든 인스턴스
• 각각을 LikeButton에 prop으로 내려보고 빌드해보세요.
• 막히는 것은 에러 메시지도 함께 적으세요. 함수가 막혔을 때와 같은 메시지인가요, 다른 메시지인가요?
• 통과한 것들은 원래 모습 그대로 도착할까요? Map을 받아서 .get()을, Date를 받아서 .getFullYear()를 화면에 찍어보세요. 메서드가 동작한다면 그건 무슨 뜻일까요?
• ⚠️ 빌드가 통과했는지는 종료 코드로 확인하세요. 화면에 Compiled successfully가 지나가도 그 뒤에서 막히는 경우가 있습니다.

[탐구] 가장 나쁜 선을 그어보기

app/layout.tsx 맨 위에 'use client'를 붙이면 어떻게 될까요.

• 먼저 예상해보세요. 빌드가 될까요, 안 될까요? 된다면 자바스크립트가 얼마나 늘까요?
• 실제로 붙여보고 확인하세요. ⚠️ 에러가 난다면 그 에러가 무엇을 말하는지 읽어보세요. 오늘 배운 것으로 설명이 되나요?
• 확인이 끝나면 반드시 되돌려주세요.

생각해볼 주제

1. 선을 어디에 그을지 정하는 기준

오늘 우리는 좋아요 버튼 하나만 브라우저로 내려보냈고, 결과만 놓고 보면 잘한 선택처럼 보이지만, 항상 잎에 두는 게 정답일까요? 버튼이 스무 개인 화면이라면 작은 클라이언트 컴포넌트가 스무 개 생깁니다. 그게 부모 하나를 클라이언트로 만드는 것보다 반드시 나을까요?

여러분이 팀에 들어가서 "이 화면은 어디에 선을 그어야 하나요"라는 질문을 받았다고 해봅시다. 무엇을 보고 판단하겠으며, 그 판단이 옳았는지는 나중에 무엇으로 확인할 수 있을까요?

2. 안 보이는 데이터가 새는 문제

Step 3에서 탐색 화면을 브라우저로 보냈더니, 화면에 그리지도 않는 글 내용이 자바스크립트 파일에 실려 갔습니다.

우리 데이터는 공개된 게시물이라 별일 아니었어요. 그런데 그 배열에 사용자 이메일이나 전화번호가 섞여 있었다면 어떨까요.

이런 일은 조용히 일어납니다. 화면은 멀쩡하고, 빌드도 통과하고, 아무도 경고해주지 않아요. 어떻게 하면 이런 유출을 미리 막을 수 있을지 생각해보세요. 코드를 짜는 습관으로 막을 수 있을까요, 아니면 자동으로 잡아주는 장치가 필요할까요?

3. 그럼 SPA는 이제 안 쓰나요

우리는 C-1부터 C-10까지 브라우저에서 전부 도는 앱을 만들었고, 오늘 그 전제가 깨졌습니다.

그렇다면 앞으로는 모든 화면을 서버 컴포넌트로 만드는 게 맞을까요? 오늘 배운 대로라면 브라우저로 가는 코드가 적을수록 좋아 보입니다.

그런데 서버에서 그린다는 건 서버가 있어야 한다는 뜻이기도 합니다. 우리가 만든 SPA는 파일 몇 개만 올려두면 돌아갔죠. 어떤 종류의 서비스가 어느 쪽에 어울릴지, 그리고 그 선택을 되돌리려면 무엇을 치러야 할지 생각해보세요.