'use client' 지시어가 두 세계의 경계를 정의하면서, 서버 컴포넌트의 진정한 잠재력이 폭발하기 시작했다. 개발자들은 이제껏 상상조차 하지 못했던 방식으로 컴포넌트를 작성할 수 있게 되었다.
조쉬 스토리는 팀원들 앞에서 새로운 프로토타입 코드를 시연했다. 그것은 사용자의 상세 정보를 보여주는 UserProfile 컴포넌트였다.
// UserProfile.server.js
import { db } from './lib/db'; // 데이터베이스 직접 임포트
async function UserProfile({ userId }) {
const user = await db.user.findUnique({ where: { id: userId } });
const posts = await db.post.findMany({ where: { authorId: userId } });
return (
<div>
<h1>{user.name}</h1>
<p>{user.email}</p>
<h2>최신 글</h2>
<ul>
{posts.map(post => <li key={post.id}>{post.title}</li>)}
</ul>
</div>
);
}
코드를 본 팀원들의 눈이 휘둥그레졌다. 그 코드에는 fetch API 호출이 단 한 줄도 없었다. useEffect나 로딩 상태를 관리하는 useState도 보이지 않았다.
대신, 데이터베이스 커넥션 객체(db)를 직접 import해서, async/await 구문으로 마치 동기 코드처럼 자연스럽게 데이터를 조회하고 있었다. 사용자 정보와 게시물 목록을 가져오는 두 번의 비동기 요청이 순식찰에 일어났다.
“이게… 정말 가능한 겁니까?”
경력이 짧은 한 엔지니어가 믿을 수 없다는 듯 물었다. 그의 머릿속에는 ‘클라이언트 코드는 절대 데이터베이스에 직접 접근해서는 안 된다’는 철칙이 깊게 박혀 있었다. 보안상의 이유로, 모든 데이터 접근은 반드시 API 엔드포인트를 통해서만 이루어져야 했다.
“가능합니다.” 조쉬가 미소를 지으며 답했다. “왜냐하면 이 코드는 클라이언트가 아니라, 우리가 완벽하게 통제하는 서버 환경에서 실행되니까요.”
그의 말에 회의실은 새로운 깨달음으로 술렁였다.
지금까지의 개발 방식은 이랬다.
- 클라이언트 컴포넌트가 렌더링된다.
useEffect안에서fetch('/api/users/123')을 호출한다.- API 라우터는 이 요청을 받아, 데이터베이스에서 사용자 정보를 조회한 후 JSON으로 응답한다.
- 클라이언트는 이 JSON을 받아 상태에 저장하고, 다시 렌더링한다.
- 다시
useEffect안에서fetch('/api/posts?userId=123')을 호출한다. - 이 과정을 반복한다.
수많은 보일러플레이트 코드와 불필요한 네트워크 레이어, 그리고 네트워크 폭포수까지. 이 모든 복잡성은 단지 ‘데이터를 가져오기 위해’ 존재했다.
하지만 서버 컴포넌트는 이 모든 과정을 생략했다. 컴포넌트 자체가 서버에 있었기 때문에, API라는 중간 다리 없이 데이터베이스와 직접 대화할 수 있었다. 비밀 키나 데이터베이스 접속 정보가 클라이언트로 유출될 걱정도 전혀 없었다.
“우리는 지난 몇 년간 데이터 페칭을 위한 수많은 추상화 계층을 쌓아 올렸습니다.” 조쉬가 말을 이었다. “하지만 서버 컴포넌트는 우리에게 가장 근본적인 질문을 다시 던지게 합니다. ‘데이터가 있는 곳에서 코드를 실행하면 안 될까?’ 라고요.”
그것은 개발의 패러다임을 바꾸는 순간이었다. 개발자는 더 이상 복잡한 API 스펙을 설계하고, 클라이언트에서 그 API를 호출하기 위한 상태 관리 로직을 짜느라 시간을 허비할 필요가 없었다. 그저 필요한 데이터를 데이터베이스에서 직접 가져와 UI를 그리면 그만이었다.
컴포넌트는 이제 단순한 UI 템플릿이 아니었다. 데이터베이스와 가장 가까운 곳에서, 가장 효율적으로 데이터를 가져와 완성된 구조물을 만들어내는 강력한 설계자로 진화하고 있었다. 이 직관성과 단순함. 개발자들은 이 경험에 열광할 것이 분명했다.
