Figma to Code: 디자인이 승인된 뒤에는 실제로 무슨 일이 일어날까요?

디자이너가 마침내 이렇게 말하는 순간을 아실 겁니다.

“Figma 준비됐습니다.”

클라이언트는 이렇게 말합니다.

“승인합니다!”

모두가 행복합니다

개발자가 화면을 보고 이렇게 말하기 전까지는 말이죠.

“좋아… 이제 이걸 코드로 만들어야 하네.”

그리고 바로 그때 진짜 작업이 시작됩니다.

Figma 디자인을 실제로 작동하는 웹사이트로 만드는 일은 보이는 것을 그대로 베끼는 것만큼 간단하지 않기 때문입니다.

사실 아름다운 Figma 화면과 실제로 오픈된 웹사이트 사이에서는 수많은 일이 일어납니다.

그렇다면 그 뒤에서는 무슨 일이 일어날까요?

복잡한 기술 용어 없이 하나씩 풀어 보겠습니다.

먼저, Figma to Code란 무엇입니까?

이렇게 생각해 보십시오.

Figma는 설계도입니다.

코드는 실제 건물입니다.

Figma는 이렇게 알려 줍니다.

“웹사이트는 이렇게 보여야 합니다.”

코드는 이것을 알아내야 합니다.

“이걸 실제로 어떻게 작동하게 만들까?”

예를 들어 Figma에 멋진 로그인 페이지가 있다고 해 봅시다.

화면에는 다음이 보입니다.

1. 이메일 입력란
2. 비밀번호 입력란
3. 로그인 버튼
4. 비밀번호 찾기
5. Google 로그인

간단해 보이지요?

하지만 개발자는 여전히 다음을 확실히 해야 합니다.

버튼이 실제로 작동하는지.

양식이 오류를 잡아내는지.

비밀번호가 안전하게 처리되는지.

사용자가 실제로 로그인되는지.

이것이 웹사이트처럼 보이는 것과 실제 웹사이트인 것의 차이입니다.

그렇다면 Figma가 승인된 뒤에는 무슨 일이 일어날까요?

전체 여정은 다음과 같습니다.

Figma → 기획 → 코드 → 테스트 → 웹사이트 오픈

하지만 그 화살표 안에서는 많은 일이 일어납니다.

한 단계씩 살펴보겠습니다.

1단계: 아직 코딩하지 마십시오. 디자인부터 이해하십시오.

많은 프로젝트가 바로 여기서 잘못됩니다.

개발자가 Figma 파일을 받자마자 곧바로 코딩을 시작합니다.

하지만 잠깐만요.

코드를 작성하기 전에, 지금 보고 있는 것이 무엇인지 이해해야 합니다.

다음을 확인해야 합니다.

1. 페이지는 어떻게 구성되어 있는가?
2. 어떤 요소가 반복되는가?
3. 어떤 글꼴을 사용하는가?
4. 색상은 무엇인가?
5. 여백은 얼마나 되는가?
6. 모바일에서는 어떻게 되는가?
7. 어떤 요소가 인터랙티브한가?

Figma에서 10가지 서로 다른 요소처럼 보이는 것이 실제로는 재사용 가능한 컴포넌트 하나일 수도 있기 때문입니다.

그리고 이를 초기에 파악하면 나중에 몇 시간을 아낄 수 있습니다.

2단계: 재사용 가능한 요소 찾기

웹사이트를 만들고 있다고 상상해 보십시오.

같은 버튼이 다음과 같이 반복된다는 것을 발견합니다.

홈페이지 → 6번

요금 페이지 → 4번

문의 페이지 → 2번

그 버튼을 12번이나 코딩하시겠습니까?

아니길 바랍니다.

대신 재사용 가능한 버튼 컴포넌트 하나를 만듭니다.

그러면 클라이언트가 이렇게 말해도:

“버튼을 조금만 더 크게 할 수 있을까요?”

한 번만 수정하면 됩니다.

그러면 모든 곳에 반영됩니다.

그래서 개발자는 디자인만 보지 않습니다.

디자인 뒤에 있는 시스템을 찾습니다.

3단계: 디자인 시스템 파악하기

이제 세부 사항으로 들어갑니다.

어떤 글꼴을 사용하는가?

브랜드 색상은 무엇인가?

버튼의 모서리는 얼마나 둥근가?

섹션 사이의 여백은 얼마인가?

제목은 어떤 모습인가?

카드는 어떤 모습인가?

이것들이 웹사이트의 디자인 시스템을 이룹니다.

웹사이트의 규칙집이라고 생각하시면 됩니다.

이렇게 그때그때 정하는 대신:

“여기는 18px 정도면 될까?”

개발자는 따라야 할 일관된 시스템을 갖게 됩니다.

그리고 웹사이트가 5페이지에서 50페이지로 커질 때 이러한 일관성은 매우 중요해집니다.

4단계: Figma에 있는 그 많은 이미지는 어떻게 할까?

흥미로운 사실이 하나 있습니다.

Figma에서 보이는 모든 것을 이미지로 내보내서는 안 됩니다.

초보자는 이렇게 생각할 수 있습니다.

“이건 버튼처럼 생겼네. 이미지로 내보내야지.”

하지만 좋은 개발은 그렇게 하지 않습니다.

버튼은 실제 버튼으로 만들어야 합니다.

텍스트는 텍스트로 남아 있어야 합니다.

카드는 코드로 만들어야 합니다.

정말로 이미지여야 하는 사진과 일러스트만 따로 내보내면 됩니다.

왜일까요?

실제 웹사이트 요소는 다음과 같기 때문입니다.

반응형입니다.

클릭할 수 있습니다.

접근성이 좋습니다.

수정할 수 있습니다.

그리고 유지 관리가 훨씬 쉽습니다.

5단계: 이제 기술 선택하기

여기서 개발자는 이렇게 묻습니다.

“우리는 무엇을 만드는가?”

간단한 비즈니스 웹사이트인가요?

그렇다면 HTML, CSS, JavaScript로 충분할 수 있습니다.

최신 웹 애플리케이션인가요?

React나 Next.js가 더 적합할 수 있습니다.

모바일 애플리케이션인가요?

Flutter나 React Native가 좋을 수 있습니다.

대규모 SaaS 제품인가요?

이제 훨씬 더 많은 것을 고려해야 합니다.

1. 프론트엔드
2. 백엔드
3. 데이터베이스
4. API
5. 인증
6. 보안
7. 확장성

즉, Figma 디자인이 모든 것을 결정하지는 않습니다.

제품 요구 사항이 결정합니다.

6단계: 디자인을 컴포넌트로 바꾸기

이제부터 흥미로워집니다.

이렇게 생각하는 대신:

“이 페이지를 만들어야 해.”

개발자는 이렇게 생각하기 시작합니다.

“이 페이지는 무엇으로 이루어져 있지?”

예를 들면:

이 각각이 재사용 가능한 구성 요소가 될 수 있습니다.

LEGO와 비슷합니다.

LEGO 조각을 매번 처음부터 만들지는 않습니다.

이미 있는 조각을 활용해 더 큰 것을 만듭니다.

이것이 바로 컴포넌트 기반 개발의 본질입니다.

7단계: 구조부터 만들기

드디어 코딩을 시작합니다.

하지만 이 단계에서도 개발자는 보통 아주 작은 디테일 하나하나에 집착하며 시작하지 않습니다.

먼저:

구조를 만듭니다.

그다음:

스타일을 입힙니다.

그다음:

인터랙션을 추가합니다.

그다음:

모든 것을 테스트합니다.

집을 짓는다고 생각해 보십시오.

벽을 세우기도 전에 커튼 색부터 고르지는 않습니다.

여기서도 마찬가지입니다.

구조가 먼저, 디테일은 나중입니다.

8단계: Figma와 똑같이 보이게 만들기

이제 디자인과 맞춰 나가기 시작합니다.

글꼴 크기.

색상.

여백.

버튼.

카드.

이미지.

테두리.

그림자.

모든 것이 하나로 모이기 시작합니다.

하지만 중요한 규칙이 하나 있습니다.

픽셀을 그대로 베끼지 말고, 이해하십시오.

왜일까요?

Figma에는 1440px 데스크톱 화면이 있을 수 있습니다.

하지만 사용자는 이런 기기를 쓸 수 있습니다.

1366px 노트북

1024px 태블릿

390px 스마트폰

웹사이트는 이 모든 기기에서 작동해야 합니다.

9단계: 그리고 이제 모바일 차례…

여기서부터 흥미로워집니다.

아름다운 데스크톱 디자인에는 이런 구성이 있습니다.

한 줄에 카드 3개.

그런데 스마트폰에서는 어떻게 될까요?

아마 이렇게 바꿔야 할 겁니다.

한 줄에 카드 1개.

데스크톱 내비게이션은 이렇습니다.

홈 | 회사 소개 | 서비스 | 문의

모바일에서는요?

햄버거 메뉴가 될 수도 있습니다.

커다란 히어로 이미지는요?

크기를 줄이거나 위치를 바꿔야 할 수도 있습니다.

이것을 반응형 디자인이라고 합니다.

그리고 이것이 Figma to Code가 단순한 “복사 붙여넣기”가 아닌 가장 큰 이유 중 하나입니다.

개발자는 이렇게 결정해야 합니다.

“화면이 바뀌면 이 디자인은 어떻게 동작해야 할까?”

10단계: 모든 것이 실제로 작동하게 만들기

이제 웹사이트가 진짜 제품이 되기 시작합니다.

Figma의 버튼에는 이렇게 쓰여 있을 수 있습니다.

로그인

코드는 실제로 사용자를 로그인시켜야 합니다.

검색창은 실제로 검색해야 합니다.

양식은 실제로 제출되어야 합니다.

드롭다운은 실제로 열려야 합니다.

결제 버튼은 실제로 결제 시스템과 연결되어야 합니다.

대시보드는 실제로 데이터를 보여 줘야 합니다.

여기서 UI 디자인과 소프트웨어 개발의 차이가 분명해집니다.

Figma는 경험을 보여 줍니다.

코드는 경험을 만들어 냅니다.

11단계: 백엔드 연결하기

간단한 예를 들어 보겠습니다.

온라인 음식 주문 앱을 상상해 보십시오.

Figma에는 이런 흐름이 있습니다.

레스토랑 → 메뉴 → 장바구니 → 주문 확인 → 결제

단순해 보입니다.

하지만 그 화면들 뒤에서는요?

많은 일이 일어나고 있습니다.

애플리케이션은 다음을 알아야 합니다.

1. 사용자는 누구인가?
2. 무엇을 주문했는가?
3. 장바구니에는 무엇이 있는가?
4. 합계는 얼마인가?
5. 주문은 어디로 전달되어야 하는가?
6. 결제는 성공했는가?
7. 주문 상태는 어떤가?

바로 여기서 API, 데이터베이스, 백엔드 시스템이 등장합니다.

사용자는 인터페이스를 봅니다.

그 뒤의 기술이 모든 것을 실현합니다.

12단계: Figma vs 현실

이제 모두가 좋아하는 단계입니다.

Figma 디자인을 엽니다.

웹사이트를 엽니다.

둘을 나란히 놓습니다.

그러면 갑자기…

“잠깐, 이게 왜 다르게 보이지?”

예를 들면:

Figma 제목 → 48px

웹사이트 제목 → 42px

Figma 여백 → 24px

웹사이트 여백 → 16px

버튼이 약간 너무 클 수도 있습니다.

이미지 위치가 다를 수도 있습니다.

모바일 레이아웃이 답답하게 느껴질 수도 있습니다.

이런 작은 디테일이 중요합니다.

그래서 개발자는 최종 결과물을 원래 디자인과 비교하며 조정합니다.

이것을 디자인 QA라고 합니다.

13단계: 실제 기기에서 테스트하기

웹사이트가 내 노트북에서는 완벽해 보여도 다른 사람의 스마트폰에서는 완전히 깨질 수 있습니다.

그러니 테스트하십시오.

확인할 기기:

모바일

태블릿

노트북

데스크톱

다양한 브라우저도 잊지 마십시오.

다음을 살펴보십시오.

1. 깨진 레이아웃
2. 넘쳐흐르는 텍스트
3. 너무 작아진 버튼
4. 이상하게 보이는 이미지
5. 열리지 않는 메뉴
6. 작동하지 않는 양식

왜냐하면:

“내 노트북에서는 잘 되는데요”는 테스트 전략이 아니기 때문입니다.

14단계: 빠르게 만들기

좋습니다. 웹사이트가 보기 좋습니다.

잘 작동합니다.

그런데 빠른가요?

로딩에 한참 걸리는 아름다운 웹사이트는 결코 좋은 경험이 아닙니다.

그래서 개발자는 다음과 같은 요소를 최적화합니다.

1. 이미지
2. 글꼴
3. 코드
4. 스크립트
5. 컴포넌트
6. 로딩 방식

목표는 간단합니다.

웹사이트가 빠르게 느껴지도록 만드는 것.

사용자는 Figma 파일이 얼마나 아름다웠는지 신경 쓰지 않기 때문입니다.

사용자가 신경 쓰는 것은 웹사이트가 얼마나 빨리 작동하느냐입니다.

15단계: 접근성을 잊지 마십시오

쉽게 놓칠 수 있는 것이 하나 더 있습니다.

웹사이트는 가능한 한 많은 사람이 사용할 수 있어야 합니다.

즉 다음을 고려해야 합니다.

1. 색상 대비
2. 키보드 내비게이션
3. 읽기 쉬운 텍스트
4. 접근 가능한 양식
5. 이미지 설명
6. 포커스 상태

디자인이 완벽해 보여도 일부 사용자에게는 사용하기 어려울 수 있습니다.

좋은 개발은 단지 보기 좋게 만드는 것이 아닙니다.

모두에게 잘 작동하도록 만드는 것입니다.

AI는 어떨까요?

이제 흥미로운 부분입니다.

AI는 개발자가 디자인을 훨씬 빠르게 코드로 바꾸도록 도와줄 수 있습니다.

다음과 같은 것을 생성할 수 있습니다.

1. HTML
2. CSS
3. React 컴포넌트
4. Tailwind 코드
5. UI 구조

대단하게 들립니다.

실제로 대단합니다.

하지만 함정이 있습니다.

생성된 코드가 저절로 좋은 코드가 되는 것은 아닙니다.

여전히 누군가는 다음을 확인해야 합니다.

모바일에서 작동하는가?

접근성이 확보되었는가?

안전한가?

유지 관리하기 쉬운 코드인가?

제품이 성장해도 계속 작동할 것인가?

AI는 개발 속도를 높여 줄 수 있습니다.

하지만 좋은 엔지니어링에는 여전히 사람의 사고가 필요합니다.

Figma to Code에서 가장 큰 실수

이렇게 생각하는 것입니다.

Figma → 복사 → 붙여넣기 → 끝

전문적인 개발은 그렇게 이루어지지 않습니다.

실제 과정은 오히려 이렇습니다.

Figma

↓

이해하기

↓

기획하기

↓

컴포넌트 만들기

↓

코드 작성하기

↓

반응형으로 만들기

↓

백엔드 연결하기

↓

테스트하기

↓

디자인과 비교하기

↓

최적화하기

↓

오픈하기

그러고 나면 그 간단해 보이던 “Figma를 웹사이트로” 요청이 더 이상 간단해 보이지 않습니다.

디자이너가 개발자의 일을 더 쉽게 만드는 방법

디자이너가 개발자가 될 필요는 없습니다.

하지만 몇 가지만 지켜도 핸드오프가 훨씬 매끄러워집니다.

다음을 활용하십시오.

1. Auto Layout
2. 컴포넌트
3. 일관된 여백
4. 적절한 레이어 이름
5. 명확한 타이포그래피
6. 반응형 디자인
7. 체계적으로 정리된 에셋

그리고 가장 중요한 것은:

분명하지 않은 부분은 설명하십시오.

마우스를 올렸을 때 버튼이 바뀐다면 그 모습을 보여 주십시오.

모바일에서 메뉴가 다르게 동작한다면 그 점을 알려 주십시오.

클릭하면 카드가 펼쳐진다면 문서로 남겨 주십시오.

좋은 소통은 불필요한 수정 작업 몇 시간을 아껴 줍니다.

개발자가 프로세스를 더 좋게 만드는 방법

개발자에게도 역할이 있습니다.

이렇게만 묻지 마십시오.

“CSS는 어디 있어요?”

이렇게 물으십시오.

“이 컴포넌트는 왜 이렇게 디자인되었나요?”

제품을 이해하십시오.

재사용 가능한 패턴을 찾으십시오.

모바일을 일찍부터 고려하십시오.

디자이너와 대화하십시오.

원래의 Figma와 비교하며 테스트하십시오.

그리고 무언가가 작동하지 않는다는 사실을 마지막에 가서야 발견하지 않도록 하십시오.

Figma to Code의 진짜 의미

Figma to Code는 사실 디자인을 변환하는 일이 아닙니다.

아이디어를 사람들이 실제로 사용할 수 있는 무언가로 바꾸는 일입니다.

Figma 파일은 아이디어가 눈에 보이는 형태가 되는 곳입니다.

코드는 아이디어가 실제로 작동하는 형태가 되는 곳입니다.

그리고 그 두 지점 사이의 모든 과정이 디자인을 진짜 디지털 제품으로 바꿉니다.

그러니 다음에 누군가 이렇게 말한다면:

“그냥 Figma를 웹사이트로 바꿔 주시면 돼요.”

이제 그 말 뒤에서 훨씬 많은 일이 일어난다는 것을 아실 겁니다.

훌륭한 디지털 제품은 디자인만으로 완성되지 않기 때문입니다.

세심하게 만들어집니다.