Skip to main content

웹이 작동하는 원리부터 다시 보기

Views 24약 6분생성형 AI 활용
Summary

Figma 프로토타입과 실제 웹사이트는 출발점이 다르다

Figma 프로토타입은 이미 만들어 둔 프레임을 사용자가 클릭하며 넘겨 보는 방식입니다. 디자이너가 화면을 먼저 완성해 두고, 사용자는 그 화면 사이를 이동합니다.

실제 웹사이트는 조금 다릅니다. 사용자가 URL을 입력하는 순간부터 화면이 만들어지기 시작합니다. 브라우저가 서버에 "이 주소에 해당하는 화면 재료를 주세요"라고 요청하고, 서버는 필요한 파일과 데이터를 보내 줍니다. 브라우저는 그 재료를 해석해 사용자의 기기 안에서 화면을 그립니다.

이 차이를 이해하면 "Figma에서는 됐는데 웹에서는 왜 다르게 보이나요?"라는 질문에 조금 더 정확히 답할 수 있습니다.

Figma에서는 화면이 고정된 캔버스에 가깝습니다. 하지만 웹에서는 화면이 사용자의 브라우저, 기기 크기, 네트워크 속도, 데이터 상태에 따라 매번 조립됩니다. 같은 디자인이라도 아이폰, 큰 모니터, 느린 와이파이, 긴 프로젝트 제목, 비어 있는 이미지 데이터에서 다르게 보일 수 있습니다.

Next.js 공식 학습 과정도 Next.js를 배우기 전 HTML, CSS, JavaScript 같은 웹 기본 개념을 이해하는 것을 전제로 안내합니다1. 코드를 깊게 쓰기 위해서가 아닙니다. 웹이 화면을 만드는 방식을 알아야 디자인 결정이 실제 제품에서 어떻게 살아 움직이는지 볼 수 있기 때문입니다.

웹이 작동하는 원리부터 다시 보기AI 생성 이미지

브라우저는 실행 가능한 캔버스, 서버는 작업실이다

먼저 두 주인공을 나눠 봅시다.

브라우저는 사용자의 기기에서 열리는 실행 가능한 캔버스입니다. Chrome, Safari, Edge 같은 앱이 여기에 해당합니다. Figma 캔버스처럼 화면을 보여 주지만, 단순히 이미지를 표시하는 곳은 아닙니다. 서버에서 받은 HTML, CSS, JavaScript, 이미지, 데이터를 해석하고, 사용자가 클릭하거나 스크롤하거나 입력할 때 반응합니다.

서버는 필요한 파일과 데이터를 건네주는 작업실입니다. 사용자가 직접 서버 화면을 보는 것은 아닙니다. 브라우저가 서버에 요청을 보내고, 서버는 요청에 맞는 응답을 돌려줍니다. Next.js 공식 설명에서도 클라이언트는 사용자의 브라우저이고, 서버는 요청을 받고 계산을 수행한 뒤 응답을 보내는 컴퓨터라고 구분합니다2.

디자이너 관점에서는 이렇게 생각하면 쉽습니다.

Figma에서 작업할 때
디자이너의 파일 → 프레임 → 프로토타입 미리보기

웹에서 사용자가 볼 때
서버의 파일과 데이터 → 브라우저 → 실제 화면

Figma 파일 안에서는 디자이너가 모든 프레임을 미리 만들어 둡니다. 반면 웹에서는 브라우저가 서버에서 받은 재료를 바탕으로 화면을 그립니다. 그래서 웹 디자인은 "최종 이미지 한 장"이 아니라 "브라우저가 화면을 조립할 수 있는 규칙"에 가깝습니다.

URL을 입력하면 무슨 일이 일어날까

사용자가 포트폴리오 주소를 입력했다고 해 봅시다.

사용자 입력
https://minji.design
        ↓
브라우저
"이 주소의 화면을 주세요"라고 요청
        ↓
서버
HTML, CSS, JavaScript, 이미지, 데이터 준비
        ↓
브라우저
받은 재료를 해석하고 화면을 그림
        ↓
사용자
포트폴리오 첫 화면을 봄

조금 더 디자이너 친화적으로 바꿔 말하면 이렇습니다.

1. 사용자가 URL을 입력한다
   = Figma 프로토타입 링크를 여는 것과 비슷하다.

2. 브라우저가 서버에 요청한다
   = "이 링크에 연결된 프레임과 에셋을 주세요"라고 묻는다.

3. 서버가 재료를 보낸다
   = 화면 구조, 스타일 규칙, 동작 코드, 이미지, 데이터가 전달된다.

4. 브라우저가 화면을 렌더링한다
   = 받은 재료를 실제 픽셀로 그린다.

5. 사용자가 상호작용한다
   = 클릭, 스크롤, 입력, 메뉴 열기 같은 동작이 실행된다.

여기서 렌더링은 화면을 실제로 그리는 과정입니다. Figma에서 프레임을 눈으로 보는 것과 비슷하지만, 웹에서는 브라우저가 HTML과 CSS를 계산해 픽셀로 바꿉니다. 이때 화면 너비, 폰트 로딩 상태, 이미지 비율, 데이터 길이가 모두 결과에 영향을 줍니다.

그래서 개발자가 "렌더링 이슈가 있어요"라고 말한다면, 대개 "디자인 의도는 알겠는데 브라우저가 실제 화면을 그리는 과정에서 예상과 다른 결과가 생겼다"는 뜻으로 이해할 수 있습니다.

HTML은 레이어 구조다

HTML은 웹페이지의 뼈대입니다. Figma의 레이어 패널처럼 "무엇이 어떤 순서로 놓여 있는지"를 정합니다.

포트폴리오 첫 화면을 떠올려 봅시다.

페이지
├─ 헤더
│  ├─ 이름 로고
│  └─ 메뉴 링크
├─ 메인
│  ├─ 자기소개 섹션
│  │  ├─ 큰 제목
│  │  ├─ 소개 문장
│  │  └─ 연락 버튼
│  └─ 프로젝트 섹션
│     ├─ 섹션 제목
│     ├─ 프로젝트 카드
│     └─ 프로젝트 카드
└─ 푸터

이 구조가 HTML의 역할입니다. 중요한 점은 HTML이 단순히 "보이는 모양"만 정하지 않는다는 것입니다. 제목인지, 문단인지, 링크인지, 버튼인지 같은 의미도 담습니다.

Figma에서는 텍스트 레이어를 크게 만들면 제목처럼 보입니다. 하지만 웹에서는 시각적으로 큰 글자라고 해서 자동으로 의미 있는 제목이 되는 것은 아닙니다. HTML에서 제목 요소로 작성해야 브라우저, 검색엔진, 스크린 리더가 "이것은 중요한 제목이구나"라고 이해할 수 있습니다.

따라서 디자이너가 화면을 넘길 때 "이 텍스트는 큰 글씨"라고만 전달하기보다 "이 페이지의 대표 제목", "이 카드는 클릭 가능한 링크", "이 버튼은 문의로 이동"처럼 역할까지 함께 말하면 구현 품질이 좋아집니다.

CSS는 오토레이아웃과 스타일 패널이다

CSS는 웹의 스타일 규칙입니다. 색상, 폰트, 간격, 정렬, 테두리, 반응형 레이아웃을 담당합니다.

Figma에 비유하면 CSS는 다음을 합친 것과 비슷합니다.

Figma Auto Layout
+ Constraints
+ Text Style
+ Color Style
+ Effect Style
+ Radius 값
= CSS가 담당하는 영역

예를 들어 포트폴리오 프로젝트 카드에는 이런 스타일 규칙이 필요합니다.

카드 배경: 흰색
카드 안쪽 여백: 24px
카드 모서리: 24px
카드 사이 간격: 16px
모바일: 한 줄에 1개
데스크톱: 한 줄에 2개 또는 3개

Figma에서는 프레임 너비를 직접 조절하며 확인할 수 있습니다. 웹에서는 이 규칙을 CSS로 작성해야 합니다. 특히 반응형 디자인에서는 "모바일 화면 하나, 데스크톱 화면 하나"만 넘기는 것으로 부족할 때가 많습니다.

개발자에게 필요한 것은 중간 구간에서의 규칙입니다.

화면이 좁아지면 카드가 언제 한 줄로 떨어지는가?
이미지는 고정 비율인가, 잘려도 되는가?
긴 제목은 두 줄까지 허용하는가?
버튼은 줄바꿈되는가, 너비가 늘어나는가?

즉, CSS는 Figma의 정적인 화면을 웹의 유연한 규칙으로 번역하는 역할을 합니다.

JavaScript는 인터랙션과 조건부 동작이다

JavaScript는 웹페이지에 동작을 더합니다. 버튼 클릭, 메뉴 열기, 폼 입력 확인, 탭 전환, 좋아요 상태 변경, 데이터를 가져와 화면에 반영하는 일이 여기에 포함됩니다.

Figma 프로토타입의 인터랙션을 떠올리면 이해하기 쉽습니다.

Figma Prototype
클릭하면 → 다른 프레임으로 이동
Hover하면 → Variant 변경
버튼 누르면 → 오버레이 열기

웹 JavaScript
클릭하면 → 메뉴 열기
입력하면 → 값 확인
데이터가 오면 → 카드 목록 업데이트
오류가 나면 → 오류 메시지 표시

하지만 Figma 프로토타입과 JavaScript에는 중요한 차이가 있습니다. Figma 프로토타입은 주로 미리 정해 둔 장면 사이를 이동합니다. 웹의 JavaScript는 실제 사용자의 입력과 실제 데이터 상태에 따라 화면을 바꿉니다.

예를 들어 포트폴리오 사이트의 문의 폼을 생각해 봅시다.

사용자가 이메일을 입력하지 않음
→ "이메일을 입력해 주세요" 표시

사용자가 메시지를 너무 짧게 입력함
→ "10자 이상 입력해 주세요" 표시

전송이 진행 중임
→ 버튼 문구를 "보내는 중..."으로 변경

전송에 실패함
→ 다시 시도 안내 표시

이런 조건부 동작은 정적인 시안만으로는 충분히 설명되지 않습니다. 그래서 디자이너는 기본 화면뿐 아니라 입력 전, 입력 중, 성공, 실패, 비활성 상태를 함께 설계해야 합니다.

정적인 자기소개와 바뀔 수 있는 프로젝트 데이터

이제 우리가 만들 포트폴리오 사이트를 기준으로 생각해 봅시다.

첫 화면에는 보통 이런 내용이 들어갑니다.

이름
한 줄 소개
프로필 이미지
대표 프로젝트 목록
연락 링크

이 중에는 자주 바뀌지 않는 것도 있고, 나중에 계속 바뀔 수 있는 것도 있습니다.

정적인 콘텐츠
- 이름
- 짧은 자기소개 문장
- 기본 연락 이메일
- 메인 소개 섹션의 큰 제목

바뀔 수 있는 데이터
- 프로젝트 제목
- 프로젝트 설명
- 프로젝트 썸네일
- 프로젝트 역할
- 프로젝트 기간
- 프로젝트 상세 페이지 링크

정적인 콘텐츠는 Figma의 고정 텍스트처럼 생각해도 됩니다. 물론 나중에 바꿀 수 있지만, 매번 여러 개가 반복되거나 외부에서 자주 업데이트되는 성격은 아닙니다.

반면 프로젝트 목록은 데이터로 보는 편이 좋습니다. 오늘은 프로젝트가 2개지만, 나중에는 6개가 될 수 있습니다. 어떤 프로젝트는 썸네일이 있고, 어떤 프로젝트는 아직 이미지가 없을 수도 있습니다. 어떤 제목은 한 줄이고, 어떤 제목은 두 줄이 될 수 있습니다.

이때 화면은 "예쁜 카드 3개"가 아니라 "프로젝트 데이터가 들어오면 반복해서 그려지는 카드 컴포넌트"가 됩니다. Next.js가 다루는 웹 애플리케이션의 구성 요소에는 UI뿐 아니라 라우팅, 데이터 가져오기, 렌더링 같은 영역도 포함됩니다3. 포트폴리오도 작게 보면 같은 구조를 가집니다. URL이 있고, 화면이 있고, 프로젝트 데이터가 있고, 브라우저가 그것을 렌더링합니다.

디자인할 때도 이 차이를 반영해야 합니다.

카드가 0개일 때는?
카드가 1개일 때는?
카드가 10개일 때는?
썸네일이 없을 때는?
프로젝트 설명이 너무 길 때는?
데이터를 불러오는 중일 때는?

이 질문들은 개발자만의 질문이 아닙니다. 실제 제품 화면을 설계하는 디자이너의 질문입니다.

왜 Figma와 웹은 다르게 보일까

이제 처음 질문으로 돌아가 봅시다.

"Figma에서는 됐는데 웹에서는 왜 다르게 보이나요?"

이유는 대개 다음 중 하나입니다.

1. 브라우저 환경이 다르다
   - 기기 너비, 픽셀 밀도, 기본 폰트 렌더링이 다를 수 있다.

2. CSS 규칙이 충분히 정의되지 않았다
   - 중간 화면 크기, 긴 텍스트, 이미지 비율에 대한 규칙이 빠졌을 수 있다.

3. 실제 데이터가 시안과 다르다
   - 제목이 더 길거나, 이미지가 없거나, 항목 개수가 달라질 수 있다.

4. 네트워크 시간이 있다
   - 이미지는 늦게 뜰 수 있고, 데이터는 로딩 상태를 거칠 수 있다.

5. JavaScript 동작이 필요하다
   - 메뉴, 폼, 필터, 탭처럼 사용자의 행동에 따라 바뀌는 부분은 별도 로직이 필요하다.

Figma는 이상적인 장면을 보여 주는 데 강합니다. 웹은 다양한 조건에서 같은 의도를 유지해야 합니다. 그래서 좋은 핸드오프는 "이 화면처럼 만들어 주세요"에서 끝나지 않습니다.

좋은 핸드오프는 이렇게 바뀝니다.

이 섹션은 HTML에서 페이지의 대표 제목입니다.
이 카드 목록은 프로젝트 데이터가 반복되어 표시됩니다.
모바일에서는 한 줄에 하나씩 쌓입니다.
이미지가 없으면 기본 배경을 보여 주세요.
데이터를 불러오는 동안에는 스켈레톤을 보여 주세요.
버튼을 누르면 문의 섹션으로 이동합니다.

이 정도만 말할 수 있어도 개발자와의 대화는 훨씬 구체적이 됩니다. 디자인은 더 이상 정적인 그림이 아니라, 브라우저에서 실행될 제품의 설계도가 됩니다.

작은 실습: 내 포트폴리오 첫 화면을 웹 재료로 나누기

코드를 쓰기 전에, 지금 Figma에 있는 포트폴리오 첫 화면을 아래 네 가지로 나눠 보세요.

1. HTML 구조
- 페이지의 큰 영역은 무엇인가?
- 제목, 문단, 링크, 버튼은 무엇인가?
- 반복되는 카드나 섹션은 무엇인가?

2. CSS 스타일
- 색상, 폰트, 간격, radius 규칙은 무엇인가?
- 모바일과 데스크톱에서 레이아웃은 어떻게 달라지는가?
- 긴 텍스트나 작은 화면에서 줄바꿈은 어떻게 되는가?

3. JavaScript 동작
- 클릭하면 무엇이 바뀌는가?
- 메뉴, 탭, 필터, 폼 같은 인터랙션이 있는가?
- 로딩, 성공, 실패 상태가 필요한가?

4. 데이터
- 고정 텍스트는 무엇인가?
- 나중에 추가되거나 바뀔 수 있는 정보는 무엇인가?
- 프로젝트 카드에 필요한 항목은 무엇인가?

이 실습의 목적은 개발자가 되는 것이 아닙니다. 내 디자인이 실제 웹에서 어떤 재료로 분해되는지 보는 것입니다. 이 감각이 생기면 다음 장에서 React 컴포넌트를 배울 때 훨씬 쉽게 이해할 수 있습니다.

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

  • 이 화면은 브라우저에서 처음 렌더링될 때 어떤 정보가 먼저 보이나요?

  • 이 페이지의 HTML 구조에서 가장 중요한 제목은 무엇으로 잡히나요?

  • 이 섹션은 서버에서 미리 만들어지는 화면인가요, 브라우저에서 JavaScript로 채워지는 화면인가요?

  • 프로젝트 목록은 코드에 고정된 콘텐츠인가요, 나중에 API나 CMS에서 가져올 데이터인가요?

  • 이미지가 늦게 로딩될 때 화면 높이가 흔들리지 않게 처리되어 있나요?

  • 모바일과 데스크톱 사이의 중간 너비에서는 카드 레이아웃이 어떻게 바뀌나요?

  • 데이터가 없거나 오류가 났을 때 사용자는 어떤 화면을 보게 되나요?

  • 이 인터랙션은 Figma 프로토타입처럼 단순 이동인가요, 실제 상태 변화가 필요한 동작인가요?

참고

1React Foundations | Next.js

2React Foundations: Server and Client Components | Next.js

3React Foundations: About React and Next.js | Next.js

책 목록

Figma에서 실제 URL까지: 디자이너를 위한 Next.js 입문

전체 목차 보기

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기