Next.js의 서버 및 클라이언트 컴포넌트 상호 작용 탐색

소개

현대 웹 개발은 성능, 사용자 경험 및 효율적인 리소스 활용을 점점 더 강조하고 있습니다. 이러한 맥락에서 Next.js는 서버 컴포넌트(RSC) 및 클라이언트 컴포넌트(RCC) 아키텍처로 패러다임 전환을 주도하는 선도적인 프레임워크로 부상했습니다. 이 이중 컴포넌트 모델은 강력하지만, 중요한 과제를 제시합니다. 바로 이 두 가지 별개의 컴포넌트 유형 간의 복잡한 상호 작용 패턴을 이해하는 것입니다. 이러한 상호 작용을 파악하는 것은 단순한 학문적 연습이 아닙니다. 성능이 뛰어나고 확장 가능하며 유지 관리 가능한 Next.js 애플리케이션을 구축하는 데 필수적입니다. 명확한 이해 없이는 개발자는 최적이 아닌 경험을 만들거나, 일반적인 함정에 빠지거나, Next.js의 혁신적인 접근 방식의 잠재력을 완전히 활용하지 못할 위험이 있습니다. 이 글은 이러한 상호 작용을 명확히 하고, 메커니즘, 모범 사례 및 실제 적용에 대한 포괄적인 가이드를 제공하는 것을 목표로 합니다.

컴포넌트 분류 및 상호 작용 이해

Next.js 앱 라우터의 핵심에는 서버 컴포넌트와 클라이언트 컴포넌트의 구분이 있습니다. 이 구분은 임의적이지 않습니다. 컴포넌트가 렌더링되는 위치, 액세스할 수 있는 데이터 유형, 애플리케이션 라이프사이클 전체에서 작동 방식을 결정합니다.

핵심 용어

서버 컴포넌트(RSC): 이 컴포넌트는 서버에서만 렌더링됩니다. 데이터베이스, 파일 시스템 및 환경 변수와 같은 서버 측 리소스에 직접 액세스할 수 있습니다. 클라이언트에 JavaScript 번들을 보내지 않아 초기 페이지 로드가 더 작고 성능이 향상됩니다. RSC는 데이터 페칭, 민감한 작업 및 하이드레이션 전에 정적 또는 동적 콘텐츠 생성을 위해 이상적입니다.
클라이언트 컴포넌트(RCC): 이 컴포넌트는 클라이언트(브라우저)에서 렌더링됩니다. 상호 작용이 가능하며 상태를 관리하고, 브라우저별 API(localStorage 또는 window 등)를 사용하고, 사용자 이벤트를 처리할 수 있습니다. RCC는 파일 상단에 'use client' 지시자로 표시되어야 합니다. 클라이언트에 전송되어 상호 작용이 가능하도록 하이드레이션되는 JavaScript 번들이 필요합니다.
하이드레이션(Hydration): React가 클라이언트 측에서 서버 컴포넌트에 의해 렌더링된 정적 HTML을 가져와 이벤트 수신기를 연결하고 애플리케이션을 상호 작용 가능하게 만드는 프로세스입니다.

서버 컴포넌트와 클라이언트 컴포넌트의 상호 작용 방식

RSC와 RCC 간의 주요 상호 작용 패턴은 서버 컴포넌트에서 클라이언트 컴포넌트로의 props 전달입니다. 서버 컴포넌트는 클라이언트 컴포넌트를 자식으로 렌더링하거나 props로 데이터를 전달할 수 있습니다. 그러나 중요한 제한 사항과 고려 사항이 있습니다.

서버 컴포넌트 우선 렌더링: 요청이 들어오면 Next.js는 먼저 모든 서버 컴포넌트를 렌더링합니다. 이 과정에서 서버 컴포넌트가 클라이언트 컴포넌트를 만나면 플레이스홀더 역할을 합니다. 서버 컴포넌트가 생성한 HTML은 클라이언트로 스트리밍됩니다.

props 전달:

직렬화 가능한 데이터: 서버 컴포넌트는 JSON 직렬화 가능한 데이터만 props로 클라이언트 컴포넌트에 전달할 수 있습니다. 이는 함수, 날짜 또는 직렬화할 수 없는 복잡한 객체를 전달할 수 없다는 것을 의미합니다. 데이터가 네트워크를 통해 클라이언트로 전송되어야 하므로, 이는 근본적인 제약 사항입니다.

RSC에서 RCC로의 props (허용됨):

// app/page.tsx (기본적으로 서버 컴포넌트)
import ClientButton from './ClientButton';

async function getData() {
    // 서버에서 데이터 페칭 시뮬레이션
    return { message: 'Hello from Server!' };
}

export default async function HomePage() {
    const data = await getData();
    return (
        <div>
            <h1>Server Component Content</h1>
            <ClientButton serverMessage={data.message} />
        </div>
    );
}

// app/ClientButton.tsx (클라이언트 컴포넌트)
'use client';

import { useState } from 'react';

interface ClientButtonProps {
    serverMessage: string;
}

export default function ClientButton({ serverMessage }: ClientButtonProps) {
    const [count, setCount] = useState(0);

    return (
        <button onClick={() => setCount(count + 1)}>
            Client Button: {serverMessage} - Clicked {count} times
        </button>
    );
}

이 예제에서 HomePage(RSC)는 데이터를 페칭하고 serverMessage(직렬화 가능한 문자열)를 ClientButton(RCC)에 props로 전달합니다.

자식/슬롯으로서의 클라이언트 컴포넌트 (중요 패턴): 서버 컴포넌트는 클라이언트 컴포넌트를 렌더링할 수 있지만, 클라이언트 컴포넌트는 서버 컴포넌트를 직접 가져와 렌더링할 수 없습니다. 이는 클라이언트 컴포넌트가 브라우저에서 실행되기 때문이며, 여기서 서버 컴포넌트는 존재하지 않습니다. 클라이언트 컴포넌트 서브트리에 서버 컴포넌트 로직을 통합하는 주요 해결책은 서버 컴포넌트를 자식 또는 props(슬롯)로 클라이언트 컴포넌트에 전달하는 것입니다.

자식으로 서버 컴포넌트 전달:

// app/layout.tsx (서버 컴포넌트)
import ClientWrapper from './ClientWrapper';
import ServerNav from './ServerNav'; // 또 다른 서버 컴포넌트

export default function Layout({ children }: { children: React.ReactNode }) {
    return (
        <html>
            <body>
                <ClientWrapper>
                    <ServerNav /> {/* ClientWrapper 내에서 렌더링되는 서버 컴포넌트 */}
                    {children}
                </ClientWrapper>
            </body>
        </html>
    );
}

// app/ClientWrapper.tsx (클라이언트 컴포넌트)
'use client';

import { useState } from 'react';

export default function ClientWrapper({ children }: { children: React.ReactNode }) {
    const [isExpanded, setIsExpanded] = useState(false);

    return (
        <div style={{ border: '2px solid blue', padding: '10px' }}>
            <button onClick={() => setIsExpanded(!isExpanded)}>
                Toggle Client Wrapper ({isExpanded ? 'Shrink' : 'Expand'})
            </button>
            {isExpanded && (
                <div style={{ marginTop: '10px' }}>
                    {children} {/* 자식(ServerNav 포함)은 여기서 렌더링됩니다 */}
                </div>
            )}
        </div>
    );
}

이 시나리오에서 ClientWrapper(RCC)는 ServerNav(RSC)를 children props로 받습니다. ClientWrapper는 이 자식을 렌더링할 수 있습니다. ServerNav 자체는 서버에서 렌더링되며, 미리 렌더링된 HTML이 children props의 일부로 ClientWrapper에 전달됩니다. ClientWrapper의 클라이언트 측 JavaScript는 자체 isExpanded 상태와만 상호 작용하며 ServerNav를 직접 '보거나' '실행'하지 않습니다.

이름 있는 슬롯으로 서버 컴포넌트 전달: 이는 복잡한 레이아웃을 위한 보다 명시적인 패턴입니다.

// app/DashboardLayout.tsx (서버 컴포넌트)
import ClientDashboardWrapper from './ClientDashboardWrapper';
import ServerSidebar from './ServerSidebar'; // 서버 컴포넌트
import ServerAnalytics from './ServerAnalytics'; // 서버 컴포넌트

export default function DashboardLayout({ children }: { children: React.ReactNode }) {
    return (
        <ClientDashboardWrapper
            sidebar={<ServerSidebar />}
            analytics={<ServerAnalytics />}
        >
            {children}
        </ClientDashboardWrapper>
    );
}

// app/ClientDashboardWrapper.tsx (클라이언트 컴포넌트)
'use client';

import { ReactNode } from 'react';

interface ClientDashboardWrapperProps {
    sidebar: ReactNode;
    analytics: ReactNode;
    children: ReactNode;
}

export default function ClientDashboardWrapper({ sidebar, analytics, children }: ClientDashboardWrapperProps) {
    return (
        <div style={{ display: 'flex', gap: '20px' }}>
            <aside style={{ width: '200px', borderRight: '1px solid #ccc' }}>
                {sidebar} {/* ServerSidebar의 미리 렌더링된 HTML을 렌더링합니다 */}
            </aside>
            <main style={{ flex: 1 }}>
                {analytics} {/* ServerAnalytics의 미리 렌더링된 HTML을 렌더링합니다 */}
                <div>{children}</div>
            </main>
        </div>
    );
}

여기서 DashboardLayout(RSC)는 ServerSidebar와 ServerAnalytics(모두 RSC)를 ClientDashboardWrapper(RCC)에 sidebar와 analytics라는 이름의 props로 전달합니다. ClientDashboardWrapper는 이러한 ReactNode props를 렌더링합니다. 마찬가지로 서버 컴포넌트는 서버에서 렌더링되며, 정적 출력만 표시를 위해 클라이언트 컴포넌트에 전달됩니다.

언제 무엇을 사용해야 하는가: 애플리케이션 시나리오

서버 컴포넌트 사용:
- 데이터 페칭: 직접적인 데이터베이스 쿼리, 클라이언트 측 재페칭이 필요 없는 API 호출.
- 민감한 데이터: API 키, 데이터베이스 자격 증명을 클라이언트 오프라인 상태로 유지.
- SEO: 콘텐츠가 서버에서 완전히 렌더링되므로 크롤링하기 쉽습니다.
- 초기 페이지 로드 성능: 더 작은 JavaScript 번들, 더 빠른 렌더링.
- 정적 또는 드물게 변경되는 콘텐츠: 블로그 게시물, 제품 설명.
- 번들 크기 최적화: 상호 작용이 필요 없는 컴포넌트.
클라이언트 컴포넌트 사용:
- 상호 작용: 클릭 핸들러, 양식 제출, 상태 관리.
- 브라우저 API: localStorage, window, 웹소켓.
- 타사 라이브러리: 특히 브라우저 DOM 조작에 의존하는 라이브러리(예: 일부 차트 라이브러리, 애니메이션 라이브러리).
- 양식: 사용자 입력, 유효성 검사(단, 액션은 서버 측 처리를 처리할 수 있습니다).
- 실시간 업데이트: 서버 컴포넌트도 데이터를 페칭할 수 있지만, 클라이언트 컴포넌트는 매우 동적인 클라이언트 주도 업데이트(예: 채팅 애플리케이션)에 더 좋습니다.

고급 상호 작용: 서버 액션

Next.js는 클라이언트 컴포넌트가 기존 API 라우트 없이 직접 서버 측 함수를 호출할 수 있도록 하는 서버 액션을 도입했습니다. 이는 변환을 위한 클라이언트-서버 격차를 효과적으로 연결하며, 서버에서 작동하고 서버 측 리소스에 액세스할 수 있으며 데이터베이스 쓰기 또는 리디렉션과 같은 작업을 수행할 수 있습니다.

// actions/formActions.ts (서버 액션)
'use server';

import { redirect } from 'next/navigation';

export async function submitForm(formData: FormData) {
    const name = formData.get('name');
    console.log('Server received data:', name);
    // 데이터베이스 저장 시뮬레이션
    await new Promise(resolve => setTimeout(resolve, 1000));
    console.log('Data saved!');
    redirect('/success'); // 작업 후 리디렉션
}

// app/ClientForm.tsx (클라이언트 컴포넌트)
'use client';

import { submitForm } from '@/actions/formActions'; // 서버 액션 가져오기

export default function ClientForm() {
    return (
        <form action={submitForm}> {/* 서버 액션 직접 사용 */}
            <input type="text" name="name" placeholder="Your Name" />
            <button type="submit">Submit</button>
        </form>
    );
}

// app/page.tsx (서버 컴포넌트)
import ClientForm from './ClientForm';

export default function HomePage() {
    return (
        <div>
            <h2>Enter Your Name</h2>
            <ClientForm />
        </div>
    );
}

이 예제에서 ClientForm(RCC)은 <form> 요소의 action props를 사용하여 submitForm(서버 액션)을 직접 호출합니다. 이 액션은 서버에서 실행되며 서버 측 리소스에 액세스하고 데이터베이스 쓰기 또는 리디렉션과 같은 작업을 수행할 수 있습니다.

결론

Next.js의 서버 컴포넌트 및 클라이언트 컴포넌트 아키텍처는 강력하고 미묘한 현대 웹 애플리케이션 구축 접근 방식을 제공합니다. 고유한 역할과, 더 중요하게는 상호 작용 패턴, 즉 서버 컴포넌트가 직렬화 가능한 props와 자식을 클라이언트 컴포넌트에 전달하는 방법, 클라이언트 컴포넌트가 서버 액션을 트리거하는 방법을 이해하는 것이 중요합니다. 이러한 패턴을 효과적으로 활용함으로써 개발자는 성능을 최적화하고, 사용자 경험을 개선하며, 통합된 사고 모델로 진정한 전체 스택 애플리케이션을 만들 수 있습니다. 이는 더 빠르고, 더 강력하며, 유지 관리하기 쉬운 웹 경험으로 이어집니다.