오늘의 목표: 화면 안의 글자를 데이터로 보기
지난 장까지 우리는 포트폴리오 첫 화면을 만들고 스타일을 입혔습니다. 이제 화면은 그럴듯해졌습니다. 하지만 아직 중요한 문제가 남아 있습니다.
프로젝트 카드의 제목, 설명, 역할, 기간이 코드 안에 직접 박혀 있다면 어떻게 될까요?
ProjectCard
├─ 제목: "커머스 앱 리디자인"
├─ 설명: "구매 전환율을 높이기 위한 UX 개선"
├─ 역할: "Product Designer"
└─ 기간: "2025.03 - 2025.06"프로젝트가 2개일 때는 괜찮습니다. 하지만 10개, 30개가 되면 이야기가 달라집니다. 카드 디자인을 바꾸고 싶은 것인지, 콘텐츠를 바꾸고 싶은 것인지 구분하기 어려워집니다.
디자인에서도 비슷한 일이 있습니다. Figma에서 카드 컴포넌트를 만들 때 모든 텍스트를 컴포넌트 안에 고정해 두면 재사용하기 어렵습니다. 대신 우리는 컴포넌트 구조는 유지하고, 인스턴스마다 텍스트와 이미지만 바꿉니다.
코드에서도 같은 생각이 필요합니다.
카드 컴포넌트 = 반복되는 화면 틀
프로젝트 데이터 = 카드마다 바뀌는 내용이번 장에서는 포트폴리오 프로젝트 목록을 데이터로 분리해 봅니다. 그리고 이 데이터가 나중에 API나 CMS에서 들어올 수 있다는 흐름까지 이해합니다.
정적 콘텐츠와 동적 콘텐츠
먼저 두 가지 콘텐츠를 구분해야 합니다.
정적 콘텐츠 = 자주 바뀌지 않는 내용
동적 콘텐츠 = 상황에 따라 바뀌는 내용포트폴리오 사이트에서 정적 콘텐츠는 이런 것들입니다.
내 이름
소개 문장
기본 섹션 제목
사이트 전체 분위기
반대로 동적 콘텐츠는 이런 것들입니다.
프로젝트 목록
프로젝트 썸네일
프로젝트별 역할
프로젝트 기간
프로젝트 상세 링크
추천 글이나 블로그 글 목록
정적 콘텐츠는 Figma 파일에 직접 적어도 큰 문제가 없습니다. 그러나 동적 콘텐츠는 다릅니다. 바뀔 가능성이 높고, 개수가 늘어날 수 있으며, 다른 화면에서도 재사용될 수 있습니다.
예를 들어 포트폴리오 메인에는 프로젝트 3개만 보여 주고, /work 페이지에는 전체 프로젝트를 보여 줄 수 있습니다. 상세 페이지에서는 같은 데이터를 더 자세히 보여 줄 수도 있습니다.
이때 콘텐츠를 화면마다 따로 적어 두면 관리가 어려워집니다.
나쁜 구조
메인 페이지에 프로젝트 정보 입력
/work 페이지에 같은 프로젝트 정보 다시 입력
상세 페이지에 또 입력이렇게 되면 프로젝트 제목을 하나 바꿀 때 세 군데를 찾아야 합니다. 실무에서는 이런 중복이 오류를 만듭니다.
좋은 구조는 이렇습니다.
좋은 구조
프로젝트 데이터는 한 곳에 둔다
각 화면은 필요한 데이터만 가져와 보여 준다디자인 시스템으로 비유하면, 컬러 토큰을 한 곳에서 관리하고 여러 컴포넌트가 가져다 쓰는 것과 비슷합니다. 콘텐츠도 토큰처럼 관리할 수 있습니다.
API는 외부 콘텐츠 라이브러리로 가는 통로다
API라는 말을 처음 들으면 어렵게 느껴집니다. 하지만 디자이너 관점에서는 이렇게 이해하면 됩니다.
API = 화면이 외부 데이터에 말을 거는 통로조금 더 Figma식으로 비유해 보겠습니다.
Figma 파일 안에 직접 텍스트를 박아 넣는 방식은 이렇습니다.
Figma Frame
└─ Text Layer: "커머스 앱 리디자인"API를 사용하는 방식은 이렇습니다.
Figma Frame
└─ Project Card Template
└─ 외부 콘텐츠 라이브러리에서 제목, 설명, 이미지 불러오기즉 API는 화면과 콘텐츠 저장소 사이에 있는 연결 통로입니다. 화면은 "프로젝트 목록을 주세요"라고 요청하고, API는 "여기 있습니다"라고 데이터를 돌려줍니다.
브라우저 또는 서버
↓ 요청: 프로젝트 목록 주세요
API
↓ 응답: 프로젝트 데이터입니다
화면
↓
ProjectCard 여러 개로 표시API 뒤에는 여러 종류의 저장소가 있을 수 있습니다.
데이터베이스
CMS
스프레드시트
외부 서비스
사내 관리자 도구
중요한 것은 API 자체가 화면이 아니라는 점입니다. API는 데이터를 주고받는 약속입니다. 화면은 그 데이터를 받아 사용자가 보기 좋은 형태로 보여 줍니다.
Next.js 공식 학습 코스에서도 API를 애플리케이션 코드와 데이터베이스 사이의 중간 계층으로 설명합니다. 특히 외부 서비스의 데이터를 가져오거나, 브라우저에 노출하면 안 되는 정보를 서버 쪽에 숨겨야 할 때 API 계층을 사용합니다.1
데이터 모델: 화면을 만들기 전에 콘텐츠의 칸을 정한다
디자이너가 API를 이해할 때 가장 중요한 개념은 데이터 모델입니다.
데이터 모델은 어렵게 말하면 "데이터가 어떤 항목으로 구성되는지 정한 설계도"입니다. 쉽게 말하면 콘텐츠 입력 양식입니다.
포트폴리오 프로젝트 카드를 보겠습니다.
ProjectCard
├─ 썸네일 이미지
├─ 프로젝트 제목
├─ 한 줄 설명
├─ 나의 역할
├─ 진행 기간
└─ 상세 보기 링크이 구조를 데이터로 바꾸면 이렇게 됩니다.
Project
├─ title
├─ description
├─ role
├─ period
├─ thumbnail
└─ href여기서 title, description, role 같은 항목을 필드라고 부릅니다.
Figma로 비유하면 필드는 컴포넌트 속성에 가깝습니다.
Figma 컴포넌트 속성
├─ title text
├─ description text
├─ image swap
└─ show badge true/false
코드의 데이터 필드
├─ title
├─ description
├─ thumbnail
└─ featured디자이너가 데이터 필드를 이해하면 화면을 더 정확히 설계할 수 있습니다. 단순히 "카드 디자인입니다"가 아니라 이렇게 말할 수 있습니다.
이 카드는 프로젝트 데이터 하나를 표시합니다.
필수 필드는 제목, 설명, 역할, 기간, 썸네일, 링크입니다.
역할은 여러 개가 될 수 있으니 배열로 관리하면 좋겠습니다.
썸네일이 없을 때의 기본 상태도 필요합니다.이것은 개발자에게 매우 유용한 정보입니다. 화면의 모양뿐 아니라 콘텐츠가 바뀌는 규칙까지 전달하기 때문입니다.
먼저 API 없이 시작하기: 로컬 데이터 배열
처음부터 진짜 API를 만들 필요는 없습니다. API의 핵심은 "화면과 데이터를 분리한다"는 생각입니다.
그래서 먼저 프로젝트 안에 작은 데이터 파일을 만들어 보겠습니다. 외부 CMS나 데이터베이스 대신, 코드 안에 간단한 배열을 둡니다.
app/
├─ page.tsx
├─ components/
│ └─ ProjectCard.tsx
└─ data/
└─ projects.tsdata/projects.ts 파일을 만든다고 생각해 봅시다.
export const projects = [
{
title: "커머스 앱 리디자인",
description: "구매 전환율을 높이기 위해 상품 탐색과 결제 흐름을 개선했습니다.",
role: "Product Designer",
period: "2025.03 - 2025.06",
thumbnail: "/projects/commerce.png",
href: "/work/commerce-redesign",
},
{
title: "SaaS 대시보드 UX 개선",
description: "복잡한 데이터를 빠르게 읽을 수 있도록 정보 구조와 카드 레이아웃을 정리했습니다.",
role: "UX Designer",
period: "2025.07 - 2025.09",
thumbnail: "/projects/dashboard.png",
href: "/work/dashboard-ux",
},
{
title: "모바일 온보딩 실험",
description: "가입 후 첫 행동을 유도하기 위해 온보딩 단계와 메시지를 재설계했습니다.",
role: "Product Designer",
period: "2025.10 - 2025.11",
thumbnail: "/projects/onboarding.png",
href: "/work/onboarding-test",
},
];여기서 중요한 것은 문법을 완벽히 외우는 것이 아닙니다. 구조를 보는 것입니다.
projects = 프로젝트 여러 개를 담은 목록
{ ... } = 프로젝트 하나
title = 제목
thumbnail = 이미지 경로
href = 클릭했을 때 이동할 주소Figma로 비유하면 이 배열은 프로젝트 카드 인스턴스 목록입니다.
ProjectCard Instance 1
ProjectCard Instance 2
ProjectCard Instance 3단, Figma에서는 인스턴스를 눈으로 복제합니다. 코드에서는 데이터 목록을 돌면서 자동으로 만듭니다.
ProjectCard를 반복해서 그리기
이제 page.tsx에서 프로젝트 데이터를 가져와 카드로 보여 줄 수 있습니다.
예를 들어 이런 흐름입니다.
1. projects 데이터를 가져온다
2. projects 목록을 하나씩 살펴본다
3. 프로젝트 하나마다 ProjectCard를 만든다
4. 화면에 카드 목록을 보여 준다코드로는 이렇게 생겼습니다.
import { projects } from "./data/projects";
import ProjectCard from "./components/ProjectCard";
export default function HomePage() {
return (
<main>
<section>
<h2>Selected Work</h2>
<div>
{projects.map((project) => (
<ProjectCard
key={project.href}
title={project.title}
description={project.description}
role={project.role}
period={project.period}
thumbnail={project.thumbnail}
href={project.href}
/>
))}
</div>
</section>
</main>
);
}처음 보면 낯설 수 있지만, 핵심은 한 줄입니다.
projects.map((project) => (...))map은 목록을 하나씩 꺼내 다른 형태로 바꾸는 도구입니다.
디자인 작업에 비유하면 이렇습니다.
프로젝트 데이터 목록 3개
↓ map
ProjectCard 인스턴스 3개즉 map은 "데이터를 카드로 바꾸는 반복 규칙"입니다.
여기서 key는 각 카드의 고유 이름표입니다. Figma에서 레이어 이름을 구분하듯, React도 반복되는 카드 중 어떤 카드가 어떤 것인지 구분해야 합니다. 그래서 href처럼 겹치지 않는 값을 key로 넣어 줍니다.
ProjectCard는 이제 빈 틀이 된다
ProjectCard 컴포넌트는 더 이상 특정 프로젝트 하나에 묶이지 않습니다. 대신 데이터를 받아 그리는 틀이 됩니다.
type ProjectCardProps = {
title: string;
description: string;
role: string;
period: string;
thumbnail: string;
href: string;
};
export default function ProjectCard({
title,
description,
role,
period,
thumbnail,
href,
}: ProjectCardProps) {
return (
<article>
<img src={thumbnail} alt="" />
<p>{role}</p>
<h3>{title}</h3>
<p>{description}</p>
<p>{period}</p>
<a href={href}>프로젝트 보기</a>
</article>
);
}type ProjectCardProps는 이 컴포넌트가 어떤 데이터를 받을 수 있는지 적어 둔 설명서입니다.
Figma로 비유하면 컴포넌트 속성 패널과 비슷합니다.
ProjectCard Props
├─ title: 글자여야 함
├─ description: 글자여야 함
├─ role: 글자여야 함
├─ period: 글자여야 함
├─ thumbnail: 이미지 경로여야 함
└─ href: 링크 주소여야 함이 설명서가 있으면 실수를 줄일 수 있습니다. 예를 들어 title 없이 카드를 만들려고 하면 코드 편집기가 알려 줄 수 있습니다.
디자이너에게 중요한 점은 이것입니다.
컴포넌트는 화면의 틀이고, props는 그 틀에 꽂히는 콘텐츠 슬롯입니다.
데이터가 분리되면 디자인도 달라진다
데이터를 분리하면 단순히 코드가 깔끔해지는 것에서 끝나지 않습니다. 디자인 판단도 더 구체적이 됩니다.
예를 들어 프로젝트 제목 길이가 모두 같을까요? 아닙니다.
짧은 제목: "온보딩 개선"
긴 제목: "B2B SaaS 관리자 대시보드 정보 구조 재설계"설명도 마찬가지입니다. 역할이 하나일 수도 있고, 여러 개일 수도 있습니다. 썸네일이 없는 프로젝트도 생길 수 있습니다.
데이터를 생각하는 디자이너는 이런 질문을 하게 됩니다.
제목은 최대 몇 줄까지 허용할까?
설명이 길면 말줄임 처리할까?
역할이 여러 개면 태그로 나눌까?
기간이 없는 프로젝트는 어떻게 보일까?
썸네일이 준비되지 않았을 때 기본 이미지를 보여 줄까?
프로젝트가 0개일 때는 어떤 빈 상태를 보여 줄까?이 질문들은 단순한 예외 처리가 아닙니다. 실제 제품에서 사용자가 마주하는 화면의 품질을 결정합니다.
Figma에서 예쁜 기본 상태만 만들면 개발 중에 빈 상태, 로딩 상태, 오류 상태가 빠질 수 있습니다. 하지만 데이터가 들어오는 구조를 이해하면 이런 상태를 미리 설계할 수 있습니다.
데이터가 아직 도착하지 않음 → 로딩 상태
데이터가 비어 있음 → 빈 상태
데이터를 가져오다 실패함 → 오류 상태
데이터가 정상 도착함 → 기본 상태실무에서 좋은 화면은 정상 상태 하나만 잘 만든 화면이 아닙니다. 데이터가 늦거나, 없거나, 실패할 때도 사용자가 길을 잃지 않는 화면입니다.
로컬 데이터에서 API로 확장하기
방금 만든 projects.ts는 아직 진짜 API가 아닙니다. 프로젝트 안에 있는 로컬 데이터입니다.
하지만 구조는 API와 매우 비슷합니다.
지금
page.tsx → projects.ts → 프로젝트 데이터
나중
page.tsx → API 또는 CMS → 프로젝트 데이터화면 입장에서는 큰 차이가 없습니다. 중요한 것은 "프로젝트 목록을 가져와 카드로 보여 준다"는 흐름입니다.
나중에 CMS를 연결하면 이런 식이 될 수 있습니다.
CMS
├─ 커머스 앱 리디자인
├─ SaaS 대시보드 UX 개선
└─ 모바일 온보딩 실험
Next.js
└─ CMS에서 프로젝트 목록을 가져옴
화면
└─ ProjectCard로 반복 표시CMS는 콘텐츠 관리 시스템입니다. 개발자가 아닌 사람도 관리자 화면에서 콘텐츠를 입력하고 수정할 수 있게 해 주는 도구입니다. 블로그 글, 제품 소개, 채용 공고, 포트폴리오 프로젝트처럼 자주 바뀌는 콘텐츠에 자주 사용됩니다.
디자이너 관점에서는 CMS를 "실제 서비스에 연결된 콘텐츠 입력 폼"으로 이해하면 좋습니다.
Figma의 텍스트 레이어
→ 디자이너가 직접 수정
CMS의 입력 필드
→ 운영자나 에디터가 수정
→ 사이트에 반영이제 API의 역할이 더 선명해집니다.
CMS에 저장된 프로젝트 데이터
↓
API가 필요한 형태로 전달
↓
Next.js가 데이터를 받아 화면 생성
↓
사용자가 브라우저에서 확인Next.js 서버 컴포넌트: 화면을 만들기 전에 데이터를 꽂는다
Next.js에서는 데이터를 가져오는 위치가 중요합니다. 특히 App Router를 사용하는 Next.js에서는 기본적으로 서버 컴포넌트를 사용합니다. 서버 컴포넌트는 이름 그대로 서버에서 먼저 실행되는 컴포넌트입니다.
이 말을 디자이너식으로 바꾸면 이렇습니다.
브라우저에서 빈 카드부터 보여 주고 나중에 채우는 방식이 아니라,
서버에서 최신 콘텐츠를 먼저 꽂은 뒤 완성된 화면을 보내는 방식Figma에 비유하면 이런 느낌입니다.
일반적인 상상
템플릿을 먼저 열고 → 나중에 텍스트를 수동으로 입력
서버 컴포넌트 방식
파일을 여는 순간 → 최신 콘텐츠가 이미 템플릿에 꽂혀 있음Next.js 공식 학습 코스에서는 서버 컴포넌트가 서버에서 실행되기 때문에 비용이 큰 데이터 요청이나 로직을 서버에 둘 수 있고, 결과만 클라이언트로 보낼 수 있다고 설명합니다. 또한 async/await 문법으로 데이터를 가져올 수 있어 별도의 클라이언트 상태 관리 없이도 서버에서 데이터를 준비할 수 있습니다.2
예를 들어 실제 API에서 프로젝트 데이터를 가져온다면 페이지는 이런 느낌이 됩니다.
async function getProjects() {
const response = await fetch("https://example.com/api/projects");
const projects = await response.json();
return projects;
}
export default async function HomePage() {
const projects = await getProjects();
return (
<main>
<section>
<h2>Selected Work</h2>
<div>
{projects.map((project) => (
<ProjectCard
key={project.href}
title={project.title}
description={project.description}
role={project.role}
period={project.period}
thumbnail={project.thumbnail}
href={project.href}
/>
))}
</div>
</section>
</main>
);
}여기서 async와 await는 "데이터가 도착할 때까지 기다린다"는 뜻입니다.
fetch = 데이터를 요청한다
await = 응답이 올 때까지 기다린다
json = 받은 데이터를 코드가 읽을 수 있는 형태로 바꾼다이 장에서 이 코드를 완벽히 작성할 필요는 없습니다. 핵심은 흐름입니다.
데이터 요청
→ 데이터 도착
→ 컴포넌트에 전달
→ 화면 완성API가 항상 필요한 것은 아니다
여기서 한 가지를 정확히 짚고 넘어가야 합니다.
데이터를 가져온다고 해서 항상 API를 직접 만들어야 하는 것은 아닙니다.
Next.js에서는 서버 컴포넌트가 서버에서 실행되기 때문에, 경우에 따라 API 계층을 거치지 않고 데이터베이스에서 직접 데이터를 가져올 수도 있습니다. 공식 학습 코스에서도 서버 컴포넌트를 사용하면 서버 쪽에서 데이터베이스를 직접 조회할 수 있어, 클라이언트에 민감한 정보를 노출하지 않으면서 추가 API 계층을 줄일 수 있다고 설명합니다.3
하지만 입문 단계에서는 이렇게 구분하면 충분합니다.
외부 서비스나 CMS에서 가져온다
→ API를 통해 데이터를 받는 경우가 많다
서버에서 직접 데이터베이스를 조회한다
→ API 없이 가져올 수도 있다
브라우저에서 직접 가져와야 한다
→ 민감한 정보가 노출되지 않도록 API 계층이 필요할 수 있다디자이너가 이 차이를 모두 구현할 필요는 없습니다. 대신 어떤 콘텐츠가 어디에서 관리되는지 질문할 수 있으면 됩니다.
이 프로젝트 목록은 코드에 고정되나요?
CMS에서 운영자가 수정하나요?
관리자 페이지에서 등록하나요?
외부 서비스에서 받아오나요?이 질문이 곧 데이터 설계의 시작입니다.
실습: 포트폴리오 프로젝트 데이터를 분리해 보기
이제 오늘의 실습을 정리해 보겠습니다. 목표는 프로젝트 카드 내용을 코드 안에 직접 반복해서 적지 않고, 데이터 파일로 분리하는 것입니다.
1단계: 데이터 파일 만들기
app/data/projects.ts 파일을 만듭니다.
export const projects = [
{
title: "커머스 앱 리디자인",
description: "상품 탐색부터 결제까지의 흐름을 개선해 구매 전환을 높이는 프로젝트입니다.",
role: "Product Designer",
period: "2025.03 - 2025.06",
thumbnail: "/projects/commerce.png",
href: "/work/commerce-redesign",
},
{
title: "SaaS 대시보드 UX 개선",
description: "복잡한 업무 데이터를 더 빠르게 이해할 수 있도록 정보 구조를 정리했습니다.",
role: "UX Designer",
period: "2025.07 - 2025.09",
thumbnail: "/projects/dashboard.png",
href: "/work/dashboard-ux",
},
];2단계: 페이지에서 데이터 가져오기
app/page.tsx에서 데이터를 불러옵니다.
import { projects } from "./data/projects";이 한 줄은 Figma에서 라이브러리 컴포넌트를 가져오는 것과 비슷합니다.
디자인 라이브러리에서 Button 가져오기
코드 데이터 파일에서 projects 가져오기3단계: ProjectCard 반복 렌더링하기
기존에 카드 두 개를 직접 적어 두었다면, 이제는 map으로 바꿉니다.
<div>
{projects.map((project) => (
<ProjectCard
key={project.href}
title={project.title}
description={project.description}
role={project.role}
period={project.period}
thumbnail={project.thumbnail}
href={project.href}
/>
))}
</div>이제 프로젝트를 하나 더 추가하고 싶다면 page.tsx의 화면 구조를 건드릴 필요가 없습니다. projects.ts에 데이터만 하나 추가하면 됩니다.
카드 디자인 수정 → ProjectCard 수정
프로젝트 내용 추가 → projects.ts 수정역할이 분리되었습니다.
4단계: 데이터 필드 점검하기
마지막으로 디자이너 관점에서 데이터 필드를 점검해 봅니다.
프로젝트 제목은 필수인가?
설명은 몇 글자 정도를 예상하는가?
역할은 하나인가, 여러 개인가?
기간은 항상 표시되는가?
썸네일 비율은 고정인가?
상세 링크가 없는 프로젝트도 있는가?
대표 프로젝트 여부가 필요한가?이 질문에 답하다 보면 단순한 카드 UI가 아니라, 실제 운영 가능한 콘텐츠 구조가 보이기 시작합니다.
디자이너가 데이터 구조를 알면 달라지는 것
디자이너가 데이터를 이해한다는 것은 개발자가 될 준비를 한다는 뜻이 아닙니다. 화면을 더 현실적으로 설계한다는 뜻입니다.
Figma에서 우리는 보통 가장 이상적인 상태를 먼저 만듭니다.
이미지 있음
제목 적당함
설명 두 줄
카드 개수 딱 맞음하지만 실제 서비스에서는 이런 일이 생깁니다.
이미지가 아직 없음
제목이 너무 김
설명이 비어 있음
카드가 1개뿐임
카드가 30개임
데이터가 아직 로딩 중임
API 요청이 실패함데이터를 이해하는 디자이너는 이 상황들을 미리 화면으로 준비할 수 있습니다. 그래서 개발자는 추측하지 않아도 됩니다. 사용자는 깨진 화면을 보지 않습니다.
핵심은 이것입니다.
디자인은 고정된 그림이 아니라,
데이터가 들어왔을 때 어떻게 변하는지에 대한 규칙이다.Next.js를 배우는 이유도 여기에 있습니다. 화면의 모양뿐 아니라 화면이 만들어지는 흐름을 이해하면, 디자이너는 더 좋은 질문을 할 수 있습니다.
이번 장에서 기억할 것
API는 화면과 외부 데이터 저장소를 연결하는 통로다.
프로젝트 카드는 화면 틀이고, 프로젝트 데이터는 그 안에 들어가는 내용이다.
데이터 필드는 Figma 컴포넌트 속성처럼 생각할 수 있다.
처음에는 로컬 배열로 시작해도 충분하다.
map은 데이터 목록을 컴포넌트 목록으로 바꾸는 반복 규칙이다.Next.js 서버 컴포넌트는 데이터를 먼저 가져와 화면을 만들 수 있다.
좋은 디자인은 기본 상태뿐 아니라 로딩, 빈 상태, 오류 상태까지 고려한다.
디자이너가 개발자에게 이제 할 수 있는 질문
이 프로젝트 목록은 코드에 고정되나요, 아니면 CMS나 API에서 가져오나요?
프로젝트 카드에 필요한 필드는 무엇인가요?
제목, 설명, 썸네일, 링크 중 필수값과 선택값은 어떻게 나뉘나요?
역할이나 태그는 하나만 들어가나요, 여러 개가 들어갈 수 있나요?
데이터가 아직 로딩 중일 때 어떤 화면을 보여 줘야 하나요?
프로젝트가 하나도 없을 때 빈 상태 화면이 필요한가요?
API 요청이 실패하면 사용자는 어떤 메시지를 보게 되나요?
썸네일 이미지 비율이 맞지 않을 때 자르나요, 여백을 두나요?
메인 페이지에는 몇 개만 보여 주고, 전체 목록은 별도 페이지에서 보여 주나요?
이 데이터는 나중에 관리자나 운영자가 직접 수정할 수 있어야 하나요?
참고
1Next.js Learn - Fetching Data
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.