왜 디자이너가 Next.js를 알아야 하는가

코딩을 배우자는 말이 아니다

이 책은 디자이너를 개발자로 바꾸기 위한 책이 아닙니다.

목표는 더 작습니다. 하지만 실무에서는 꽤 강력합니다.

디자이너가 웹 제품이 만들어지는 방식을 이해하고, 개발자와 더 정확하게 대화할 수 있게 되는 것. 그리고 필요하다면 포트폴리오 사이트 정도는 직접 열어 보고, 구조를 읽고, 간단한 문구와 스타일을 고치고, 실제 URL로 배포해 보는 것.

이 정도만 할 수 있어도 디자인 핸드오프의 질은 달라집니다.

Figma에서 만든 화면은 제품의 중요한 출발점입니다. 하지만 Figma 파일은 실제 제품이 아닙니다. 실제 제품은 브라우저에서 열리고, 다양한 화면 크기에서 보이고, 서버에서 데이터를 받아 오고, 사용자의 클릭에 반응하고, 느린 네트워크에서도 버텨야 합니다.

디자이너가 Next.js를 배운다는 것은 이 과정을 전부 혼자 하겠다는 뜻이 아닙니다. 내 디자인이 실제 제품이 되는 과정에서 무엇이 변하고, 무엇이 빠지고, 어디서 비용이 생기는지 이해하겠다는 뜻입니다.

Figma 화면은 완성품처럼 보이지만, 웹은 계속 움직인다

Figma에서는 모든 것이 비교적 안정적입니다.

프레임의 크기를 정할 수 있고, 텍스트도 원하는 줄에서 끊을 수 있습니다. 이미지는 가장 보기 좋은 비율로 넣을 수 있고, 버튼의 상태도 Variant로 정리할 수 있습니다. 프로토타입 연결을 만들면 화면 흐름도 꽤 그럴듯하게 보입니다.

하지만 실제 웹은 다릅니다.

사용자는 390px 너비의 모바일 화면으로 들어올 수도 있고, 1440px 데스크톱 모니터로 들어올 수도 있습니다. 어떤 사용자는 이름이 두 글자이고, 어떤 사용자는 이름이 스무 글자입니다. 이미지는 늦게 로딩될 수 있고, 서버에서 데이터가 비어 올 수도 있습니다. 클릭했는데 권한이 없을 수도 있습니다.

Figma가 "가장 이상적인 장면"을 보여 준다면, 실제 웹은 "가능한 모든 상황"을 처리해야 합니다.

Figma 화면
= 가장 잘 정돈된 한 장면

실제 웹 제품
= 화면 크기 + 데이터 + 상태 + 속도 + 사용자 행동이 계속 바뀌는 환경

여기서 핸드오프의 간극이 생깁니다.

핸드오프에서 자주 사라지는 것들

디자인 핸드오프는 보통 이렇게 진행됩니다.

Figma 시안 작성
   ↓
프로토타입 연결
   ↓
개발자에게 공유
   ↓
개발자가 구현
   ↓
QA에서 차이 발견
   ↓
수정 요청

이 흐름이 나쁘다는 뜻은 아닙니다. 대부분의 팀은 이렇게 일합니다. 문제는 Figma에서 개발로 넘어가는 순간, 디자인의 일부 정보가 사라지거나 다르게 해석된다는 점입니다.

1. 오토레이아웃 의도가 CSS로 정확히 번역되지 않는다

Figma의 오토레이아웃은 디자이너에게 매우 직관적입니다.

"안쪽 여백은 24px, 아이템 간격은 12px, 텍스트가 길어지면 아래로 늘어난다."

하지만 개발에서는 이 의도를 CSS의 flex, grid, padding, gap, min-width, max-width 같은 속성으로 옮겨야 합니다. 디자이너가 보기에는 같은 오토레이아웃이어도, 개발자가 보기에는 여러 구현 방식이 있을 수 있습니다.

예를 들어 카드 리스트를 생각해 봅시다.

Figma에서의 생각
카드 3개를 가로로 배치하고 간격은 24px

브라우저에서의 질문
화면이 좁아지면 2개로 줄어드나?
1개로 떨어지는 시점은 어디인가?
카드 높이가 서로 달라지면 어떻게 정렬하나?
텍스트가 길면 버튼은 아래로 밀리나?

Figma에서는 한 프레임만 보면 됩니다. 하지만 웹에서는 프레임 밖의 상황까지 결정해야 합니다.

2. 컴포넌트 Variant가 실제 상태를 모두 담지 못한다

Figma 컴포넌트에는 Variant가 있습니다.

버튼이라면 default, hover, disabled 같은 상태를 만들 수 있습니다. 개발에서도 비슷하게 컴포넌트를 만듭니다. 하지만 실제 제품의 상태는 더 많습니다.

예를 들어 "프로젝트 카드" 컴포넌트를 만든다고 해 봅시다.

Figma에는 보통 이런 상태가 있습니다.

• 기본 카드

• 마우스를 올렸을 때 카드

• 선택된 카드

실제 제품에서는 여기에 더 많은 질문이 붙습니다.

• 썸네일 이미지가 아직 로딩 중이면?

• 이미지 주소가 깨졌다면?

• 프로젝트 설명이 비어 있다면?

• 비공개 프로젝트라면?

• 클릭했는데 접근 권한이 없다면?

Figma의 Variant는 시각적 상태를 정리하는 데 강합니다. 하지만 실제 제품은 데이터와 권한, 네트워크 상태까지 함께 다룹니다.

3. 프로토타입 연결과 실제 URL 구조는 다르다

Figma 프로토타입에서는 프레임과 프레임을 선으로 연결합니다.

Home 프레임 → Project Detail 프레임 → Contact 프레임

이 연결은 사용 흐름을 보여 주는 데 좋습니다. 하지만 실제 웹에서는 각 화면이 URL과 연결됩니다.

/                 홈
/projects         프로젝트 목록
/projects/brand   특정 프로젝트 상세
/contact          연락처

이 차이는 작아 보이지만 중요합니다.

URL이 있다는 것은 사용자가 특정 페이지를 북마크할 수 있고, 링크로 공유할 수 있으며, 브라우저의 뒤로 가기 버튼으로 이동할 수 있다는 뜻입니다. 검색엔진이 페이지를 읽을 수도 있습니다. 개발자는 이 구조를 기준으로 파일과 폴더를 나눕니다.

디자이너가 URL 구조를 이해하면 "이 화면은 독립된 페이지인가, 아니면 한 페이지 안에서 열리는 모달인가?" 같은 질문을 더 빨리 할 수 있습니다.

4. 샘플 텍스트는 실제 데이터가 아니다

Figma에서는 가장 보기 좋은 문장을 넣습니다.

포트폴리오 카드에 이런 문구를 넣을 수 있습니다.

브랜드 경험을 개선한 모바일 앱 리디자인

보기 좋습니다. 길이도 적당합니다. 하지만 실제 데이터는 늘 이렇게 친절하지 않습니다.

어떤 제목은 짧습니다.

리서치

어떤 제목은 깁니다.

신규 사용자의 첫 구매 전환율을 높이기 위한 온보딩 및 상품 탐색 경험 개선 프로젝트

디자인은 두 경우를 모두 견뎌야 합니다. 개발자는 실제 데이터를 화면에 넣어야 하기 때문입니다.

그래서 디자인을 넘길 때는 예쁜 상태만이 아니라, 긴 텍스트, 빈 데이터, 오류 상태도 함께 생각해야 합니다.

보기 좋은 시안
= Best Case

실제 제품 설계
= Best Case + Long Case + Empty Case + Error Case + Loading Case

Next.js를 개발자만의 어려운 도구로 보지 않기

Next.js라는 이름을 처음 들으면 어렵게 느껴질 수 있습니다.

React, 서버 렌더링, 라우팅, API, 배포 같은 단어가 함께 나오기 때문입니다. 하지만 디자이너의 관점에서는 이렇게 이해하는 편이 좋습니다.

Next.js는 화면, 흐름, 데이터, 배포를 한 프로젝트 안에서 연결하는 웹 제품 제작 환경입니다.

Figma가 단순한 그림 도구가 아닌 것과 비슷합니다. Figma 안에는 프레임, 컴포넌트, Variant, 오토레이아웃, 프로토타입, Dev Mode가 함께 있습니다. Next.js도 마찬가지입니다. 단순히 코드를 적는 곳이 아니라, 실제 웹 제품을 구성하는 여러 요소가 한 프로젝트 안에 모여 있습니다.

Figma에서 익숙한 것        Next.js에서 대응되는 것
────────────────────────────────────────
Frame                    Page / Route
Component                React Component
Variant                  Props / State
Auto Layout              CSS Layout
Prototype Flow           Routing
Design Token             CSS Variable / Tailwind Token
Published Prototype      Deployed URL

물론 완전히 같은 것은 아닙니다. 하지만 이 대응 관계를 잡고 나면 Next.js 프로젝트가 조금 덜 낯설어집니다.

Next.js는 무엇을 한곳에 묶어 주는가

Next.js를 이해할 때 처음부터 기술 용어를 외울 필요는 없습니다. 먼저 "무엇을 연결하는 도구인가"를 보면 됩니다.

Next.js 프로젝트

화면 구조
  ↓
컴포넌트
  ↓
스타일
  ↓
데이터
  ↓
배포

공식 Next.js 학습 과정도 실제 웹 애플리케이션을 단계적으로 만들면서, 컴포넌트와 데이터, 애플리케이션 로직을 연결하고, 최종적으로 배포 가능한 웹사이트를 만드는 흐름으로 구성되어 있습니다.¹ 이 책도 같은 방향을 따르되, 디자이너가 이해하기 쉬운 언어로 바꿔 설명합니다.

디자이너에게 중요한 관점은 이것입니다.

• 화면은 어디에서 시작되는가?

• 반복되는 UI는 어떤 컴포넌트로 나뉘는가?

• 스타일 값은 어디에서 관리되는가?

• 콘텐츠는 코드 안에 고정되어 있는가, 외부 데이터에서 오는가?

• 내가 본 화면은 실제 배포된 화면인가, 개발 중인 미리보기인가?

이 질문에 답할 수 있으면 개발자가 작성한 모든 코드를 이해하지 못해도 협업의 밀도가 올라갑니다.

기존 핸드오프 흐름과 Next.js 기반 협업 흐름

기존의 핸드오프는 대체로 "완성된 시안을 넘기는 방식"에 가깝습니다.

기존 흐름

디자이너
Figma에서 완성된 화면 제작
   ↓
개발자
시안을 보고 구조와 상태를 해석
   ↓
구현
   ↓
디자이너
실제 화면을 보고 차이점 피드백

이 흐름에서는 구현 가능성, 상태 설계, 반응형 규칙이 뒤늦게 드러나는 경우가 많습니다. 그래서 QA 단계에서 이런 말이 나옵니다.

• "이건 의도한 간격이 아니에요."

• "모바일에서는 이렇게 보이면 안 돼요."

• "이 텍스트가 길어질 줄 몰랐어요."

• "이 화면은 따로 URL이 있어야 해요."

Next.js를 조금 이해한 디자이너는 흐름을 이렇게 바꿀 수 있습니다.

Next.js를 이해한 협업 흐름

디자이너 / Figma에서 화면과 의도 설계
   ↓
디자이너 + 개발자 / 페이지 구조, 컴포넌트, 상태, 데이터 출처를 함께 확인
   ↓
개발자 / 구현
   ↓
디자이너 / 배포 미리보기 URL에서 실제 동작 확인
   ↓
팀 / 수정 범위와 우선순위를 더 정확히 결정

차이는 하나입니다.

디자인을 "이미지"로만 넘기지 않고, 실제 제품이 될 구조로 함께 바라보는 것입니다.

이 책에서 만들 프로젝트: 디자이너의 포트폴리오 사이트

이 책 전체에서는 하나의 프로젝트를 계속 이어서 만듭니다.

포트폴리오 사이트입니다.

포트폴리오 사이트는 디자이너에게 익숙한 주제이면서도 Next.js의 핵심 개념을 연습하기 좋습니다.

우리가 만들 포트폴리오 사이트에는 이런 요소가 들어갑니다.

홈 페이지
- 이름
- 소개 문구
- 대표 프로젝트 링크

프로젝트 목록 페이지
- 여러 프로젝트 카드
- 썸네일
- 역할과 기간

프로젝트 상세 페이지
- 문제 정의
- 과정
- 결과
- 이미지

연락처 영역
- 이메일
- 링크드인 또는 기타 링크

이 구성 안에는 책에서 배울 핵심이 거의 모두 들어 있습니다.

• 페이지가 여러 개이므로 라우팅을 배울 수 있습니다.

• 프로젝트 카드가 반복되므로 컴포넌트를 배울 수 있습니다.

• 색상과 간격이 필요하므로 스타일링을 배울 수 있습니다.

• 프로젝트 목록이 필요하므로 데이터를 배울 수 있습니다.

• 실제 URL로 공유해야 하므로 배포를 배울 수 있습니다.

중요한 점은 처음부터 완벽한 사이트를 만들지 않는다는 것입니다. Figma에서 디자인 시스템을 처음 만들 때도 모든 컴포넌트를 한 번에 완성하지 않습니다. 버튼부터 만들고, 카드로 확장하고, 페이지에 적용하면서 다듬습니다.

Next.js도 같은 방식으로 배웁니다.

이 책에서 디자이너가 직접 다룰 범위

부담을 줄이기 위해 범위를 분명히 하겠습니다.

이 책은 여러분에게 다음을 요구하지 않습니다.

• 복잡한 JavaScript 알고리즘 작성하기

• 서버와 데이터베이스를 직접 설계하기

• 로그인, 결제, 권한 시스템 만들기

• 대규모 서비스를 혼자 개발하기

• 개발자의 역할을 대신하기

대신 다음을 할 수 있게 되는 것을 목표로 합니다.

1. 화면 구조 이해하기

Next.js 프로젝트에서 어떤 파일이 어떤 화면과 연결되는지 읽을 수 있게 됩니다.

디자이너식으로 말하면, "이 Figma 프레임이 실제 제품의 어느 파일과 대응되는지" 찾을 수 있게 되는 것입니다.

2. 컴포넌트 읽기

반복되는 UI가 어떻게 나뉘어 있는지 이해합니다.

Figma에서 버튼 컴포넌트를 수정하면 여러 인스턴스에 반영되듯, 코드에서도 하나의 컴포넌트가 여러 화면에서 재사용될 수 있습니다.

3. 간단한 수정하기

문구를 바꾸거나, 간격을 조정하거나, 색상 값을 바꾸는 정도의 수정을 연습합니다.

이 정도만 해도 개발자에게 모든 사소한 수정을 요청하지 않고 직접 확인할 수 있습니다. 물론 팀의 규칙에 따라 실제 반영은 개발자의 리뷰를 거칠 수 있습니다.

4. 배포 대화에 참여하기

"이 화면을 실제 URL에서 볼 수 있나요?"

"배포 미리보기 링크가 있나요?"

"이 수정은 운영 사이트에 바로 나가나요, 아니면 테스트 환경에서 먼저 확인하나요?"

이런 질문을 자연스럽게 할 수 있게 됩니다.

구현 감각은 디자인 판단을 바꾼다

Next.js를 조금 이해하면 디자인을 덜 하게 되는 것이 아닙니다. 오히려 더 정확하게 디자인하게 됩니다.

예를 들어 카드 컴포넌트를 디자인할 때도 전과 다른 질문을 하게 됩니다.

이전에는 이렇게 생각했을 수 있습니다.

카드가 예쁘게 보이는가?

Next.js와 웹 구현 방식을 이해하면 질문이 확장됩니다.

이 카드는 몇 곳에서 재사용되는가?
텍스트가 길어져도 구조가 깨지지 않는가?
클릭하면 별도 페이지로 이동하는가, 모달이 열리는가?
데이터가 없을 때는 무엇을 보여 주는가?
모바일에서는 어떤 순서로 쌓이는가?

이것이 구현 감각입니다.

구현 감각은 코드를 많이 외운다고 생기는 것이 아닙니다. 내 디자인이 브라우저 안에서 어떤 조건을 만나게 되는지 이해할 때 생깁니다.

실습: 내 포트폴리오 Figma를 Next.js 관점으로 다시 보기

아직 코드를 작성하지 않아도 됩니다. 이번 장의 실습은 Figma 파일을 Next.js 관점으로 다시 보는 것입니다.

포트폴리오 시안이 있다면 열어 보세요. 없다면 종이에 간단히 그려도 됩니다.

다음 표를 채워 봅니다.

이 표를 작성하면 Figma 화면이 단순한 시안이 아니라 제품 구조로 보이기 시작합니다.

Figma 프레임을 보는 관점
"이 화면이 예쁜가?"

Next.js 관점으로 보는 질문
"이 화면은 어떤 페이지이고, 어떤 컴포넌트와 데이터로 만들어지는가?"

이 전환이 이 책의 출발점입니다.

앞으로의 흐름

다음 장에서는 웹이 작동하는 원리를 다시 봅니다.

서버, 브라우저, HTML 같은 단어가 나올 예정입니다. 하지만 어렵게 접근하지 않겠습니다. Figma 프로토타입을 떠올리며 설명할 것입니다.

먼저 브라우저는 사용자가 보는 화면이고, 서버는 필요한 파일과 데이터를 보내 주는 곳이라고 생각하면 됩니다. HTML은 브라우저가 화면의 구조를 이해하기 위한 기본 설계도입니다.

그다음 React에서 컴포넌트를 배우고, Next.js에서 페이지와 라우팅을 배우고, 실제 포트폴리오 화면을 띄워 보겠습니다.

이 책의 목적은 끝까지 같습니다.

디자이너가 개발자가 되는 것보다, 제품이 만들어지는 방식을 이해하는 디자이너가 되는 것.

그 이해가 쌓이면 핸드오프는 더 구체적이 되고, QA는 덜 막연해지고, 개발자와의 대화는 훨씬 빨라집니다.

디자이너가 개발자에게 이제 할 수 있는 질문

이번 장을 이해했다면, 다음 질문들을 개발자에게 할 수 있습니다.

• 이 화면은 별도 URL이 필요한 페이지인가요, 아니면 한 페이지 안의 섹션이나 모달인가요?

• 이 UI는 공통 컴포넌트로 만들 수 있나요, 아니면 이 화면에서만 쓰이나요?

• Figma의 이 Variant들이 실제 코드에서는 어떤 상태로 구현되나요?

• 로딩 중, 데이터 없음, 오류 상태도 따로 디자인해야 하나요?

• 프로젝트 카드의 제목이나 설명이 길어지면 레이아웃은 어떻게 처리되나요?

• 모바일에서는 몇 px 지점에서 레이아웃이 바뀌나요?

• 이 콘텐츠는 코드에 직접 넣나요, 아니면 API나 CMS 같은 외부 데이터에서 가져오나요?

• 구현 난이도를 크게 높이는 디자인 요소가 있다면 어떤 부분인가요?

• 배포 전에 실제 URL로 확인할 수 있는 미리보기 링크가 있나요?

참고

¹Learn Next.js