Figma 파일을 개발 가능한 구조로 정리하기

2026-08-27Views 7약 9분생성형 AI 활용

Summary

디자인 파일은 개발 입력이다

AI로 만든 Figma 화면은 빠르게 논의하기 좋은 초안이다. 하지만 그 상태 그대로 개발자에게 넘기면 문제가 생긴다. 화면은 그럴듯해 보여도 레이어 패널에는 Rectangle 47, Group 12, Frame 89 같은 이름이 남아 있다. 이 이름은 사람에게도, AI에게도 의미가 없다.

개발 가능한 Figma 파일은 예쁜 그림이 아니라 구조화된 설계도에 가깝다. 어떤 요소가 버튼인지, 어떤 텍스트가 제목인지, 어떤 영역이 카드인지, 어떤 이미지를 내보내야 하는지 읽을 수 있어야 한다. Unity, Unreal, 웹 프론트엔드로 옮길 때도 이 구조가 기준이 된다.

정리의 목표는 단순하다.

레이어 이름만 보고 역할을 알 수 있게 한다.
화면의 부모·자식 관계가 실제 UI 구조와 맞게 한다.
반복되는 요소는 컴포넌트로 관리한다.
간격과 정렬은 오토 레이아웃으로 설명한다.
Dev Mode에서 개발자가 필요한 값을 바로 확인할 수 있게 한다.

이 장에서는 AI가 만든 Figma 파일을 구현 친화적인 형태로 정리하는 방법을 다룬다.

Figma 파일을 개발 가능한 구조로 정리하기 AI 생성 이미지

AI 레이어 이름 변경은 첫 정리 도구다

Figma AI의 레이어 이름 변경 기능은 기본 이름으로 남아 있는 레이어를 문맥에 맞게 바꾸는 데 도움을 준다. Figma 공식 도움말에 따르면 이 기능은 프레임, 그룹, 이미지가 채워진 사각형 또는 둥근 사각형, 텍스트 레이어, 기본 이름을 유지한 인스턴스 등을 대상으로 작동한다. 이름을 정할 때는 레이어의 내용, 위치, 선택된 다른 레이어와의 관계를 함께 본다¹.

예를 들어 상점 화면 안에 상품 이미지, 이름, 가격, 구매 버튼이 묶여 있다면 AI는 단순히 Group 12라고 부르지 않고 product-card나 item-card에 가까운 이름을 제안할 수 있다. 상단 메뉴 안의 텍스트라면 nav-link, 프로필 옆의 이미지라면 avatar-image처럼 문맥을 반영할 수 있다.

다만 이 기능을 최종 정리로 생각하면 안 된다. AI는 화면을 보고 추정한다. 팀의 명명 규칙, 코드 구조, 엔진 구현 방식까지 완전히 알지는 못한다. 따라서 AI로 1차 정리를 한 뒤 사람이 이름을 검토해야 한다.

특히 다음 항목은 직접 확인한다.

같은 역할의 레이어가 같은 규칙으로 이름 붙었는가?
버튼, 카드, 모달, 탭처럼 개발 컴포넌트가 될 단위가 드러나는가?
장식용 요소와 상호작용 요소가 구분되는가?
상태 이름이 구현 가능한 방식으로 표현되는가?
Unity, Unreal, 웹에서 공통으로 이해할 수 있는 이름인가?

AI 레이어 정리는 청소의 시작점이다. 최종 기준은 팀의 구현 방식이다.

좋은 레이어 이름은 역할을 말한다

Rectangle 47은 모양을 말한다. 하지만 개발자는 모양보다 역할을 알아야 한다. 같은 사각형이라도 배경일 수 있고, 버튼일 수 있고, 체력 바의 채워진 부분일 수 있다. 그래서 레이어 이름은 시각적 형태보다 UI 역할을 기준으로 붙인다.

나쁜 이름과 좋은 이름을 비교해 보자.

기본 이름	구현 친화적 이름	이유
`Rectangle 47`	`health-bar-fill`	체력 바에서 채워지는 영역임을 알 수 있다.
`Group 12`	`item-card`	상품 또는 아이템 카드 단위로 구현할 수 있다.
`Text 8`	`item-card-title`	카드 안의 제목 텍스트임을 알 수 있다.
`Frame 23`	`inventory-grid`	인벤토리 슬롯을 배치하는 영역임을 알 수 있다.
`Ellipse 5`	`avatar-status-dot`	아바타의 접속 상태 표시임을 알 수 있다.
`Button`	`primary-action-button`	주요 행동 버튼이라는 우선순위가 드러난다.

이름을 붙일 때는 다음 순서를 추천한다.

영역을 먼저 쓴다. shop, inventory, hud, settings처럼 화면이나 기능 범위를 적는다.
역할을 쓴다. card, button, title, icon, container, list, grid처럼 UI 역할을 적는다.
필요할 때 상태를 붙인다. selected, disabled, hover, focused, empty, error처럼 상태를 뒤에 붙인다.
모양만 설명하는 이름은 피한다. blue-box, big-text, red-circle은 구현 의미가 약하다.
한 가지 표기법을 유지한다. 예를 들어 kebab-case를 쓰기로 했다면 item-card-title처럼 끝까지 맞춘다.

게임 UI에서는 HUD 요소의 이름도 중요하다. bar라고만 쓰면 무슨 바인지 알 수 없다. health-bar-container, health-bar-fill, health-bar-label처럼 계층과 역할을 나누면 Unity의 UI Toolkit, Unreal의 UMG, 웹 컴포넌트로 옮길 때 구조를 쉽게 매핑할 수 있다.

계층 구조는 화면 구조와 같아야 한다

레이어 이름만 좋아도 부족하다. 부모·자식 관계가 뒤섞여 있으면 구현할 때 다시 해석해야 한다.

예를 들어 아이템 카드 하나가 다음처럼 정리되어 있다고 해 보자.

item-card
  item-card-thumbnail
  item-card-content
    item-card-title
    item-card-description
    item-card-price-row
      item-card-price-icon
      item-card-price-text
  item-card-action-button

이 구조는 개발자가 바로 이해할 수 있다. 카드 안에 이미지, 콘텐츠 영역, 가격 행, 버튼이 있다. 반대로 이미지와 텍스트와 버튼이 화면 전체에 흩어져 있으면 실제로는 카드 하나처럼 보여도 구현자는 다시 묶어야 한다.

Figma에서 구조를 정리할 때는 다음 기준을 적용한다.

한 번에 움직여야 하는 요소는 같은 프레임이나 컴포넌트 안에 둔다.
반복되는 UI는 독립 컴포넌트로 만든다.
배경 장식은 상호작용 요소와 분리한다.
텍스트와 아이콘이 함께 의미를 만들면 같은 그룹 또는 프레임에 둔다.
스크롤 영역, 고정 헤더, 고정 푸터는 별도 영역으로 구분한다.

개발자는 이 계층을 보고 코드 구조를 떠올린다. Figma의 부모 프레임은 Unity의 VisualElement, Unreal UMG의 Widget, 웹의 div나 컴포넌트가 될 수 있다. 완전히 1:1로 옮겨지지는 않더라도, 큰 구조가 맞으면 구현 판단이 빨라진다.

오토 레이아웃은 간격을 설명하는 언어다

오토 레이아웃은 Figma에서 요소를 자동으로 정렬하고 간격을 유지하는 기능이다. 개발 관점에서는 "이 UI가 어떻게 늘어나고 줄어드는지"를 설명하는 규칙이다.

AI가 만든 초안은 겉보기에는 정렬되어 있어도 실제로는 좌표로만 배치된 경우가 많다. 이 상태에서는 버튼 텍스트가 길어졌을 때 어떻게 늘어날지, 카드가 여러 개일 때 간격이 유지될지 알기 어렵다. 오토 레이아웃을 적용하면 이런 규칙을 파일 안에 남길 수 있다.

정리할 때는 다음 요소에 우선 적용한다.

버튼: 아이콘과 텍스트 사이 간격, 내부 패딩
카드: 이미지, 제목, 설명, 버튼의 세로 배치
리스트: 항목 사이 간격
메뉴: 링크 간격과 활성 상태 표시
HUD: 아이콘, 수치, 게이지의 정렬
모달: 제목, 본문, 버튼 영역의 간격

오토 레이아웃에서 개발자가 주로 보는 값은 방향, 간격, 패딩, 정렬, 크기 조정 방식이다. 예를 들어 버튼의 좌우 패딩이 16px이고 아이콘과 텍스트 간격이 8px이면, 개발자는 이를 USS, UMG Slot 설정, CSS 스타일로 옮길 수 있다.

여기서 중요한 점은 모든 레이어에 오토 레이아웃을 억지로 적용하지 않는 것이다. 장식용 배경, 자유로운 일러스트, 합성 이미지처럼 규칙보다 시각적 배치가 중요한 요소는 이미지 에셋으로 내보내는 편이 낫다. 오토 레이아웃은 반복되고 반응해야 하는 UI에 우선 적용한다.

AI 기반 에셋 검색은 팀의 다른 용어를 연결한다

큰 Figma 파일이나 디자인 시스템에서는 원하는 아이콘과 컴포넌트를 찾는 일도 시간이 걸린다. 같은 체크 아이콘을 어떤 팀은 check, 어떤 팀은 tick, 어떤 팀은 complete라고 부른다. 오류 상태도 alert, warning, error, validation-error처럼 다르게 부를 수 있다.

AI 기반 에셋 검색은 이런 차이를 줄이는 데 유용하다. 정확한 파일 이름을 몰라도 의미로 검색해 후보를 찾을 수 있기 때문이다. 예를 들어 다음처럼 검색한다.

check: 체크마크, 완료, 선택됨 아이콘 후보 찾기
alert: 경고, 오류, 주의 상태 아이콘 찾기
avatar: 프로필 이미지, 사용자 사진 컴포넌트 찾기
empty state: 빈 목록 화면에 쓰는 일러스트나 패턴 찾기
purchase button: 상점 화면의 구매 버튼 컴포넌트 찾기

검색 결과를 그대로 쓰기 전에 확인할 항목이 있다.

현재 프로젝트의 스타일과 맞는가?
이미 디자인 시스템에 등록된 컴포넌트인가?
상태나 변형이 필요한가?
엔진으로 내보낼 수 있는 형태인가?
라이선스나 사용 범위에 문제가 없는가?

AI 검색은 "찾기"를 빠르게 해 준다. 하지만 "이 에셋이 맞는가"는 사람이 판단해야 한다. 특히 게임 UI에서는 아이콘의 의미가 플레이 경험에 직접 영향을 준다. 경고 아이콘과 실패 아이콘이 비슷하면 사용자는 상태를 오해할 수 있다.

Dev Mode에서 넘길 정보를 구분한다

Figma Dev Mode는 개발자가 디자인 파일을 탐색하고 구현에 필요한 정보를 확인하는 작업 공간이다. Figma의 공식 설명에 따르면 Dev Mode에서는 레이어 구조, 컴포넌트 정보, 코드 스니펫, 주석, 상태, 변경 사항 등을 확인하며 디자인을 코드로 옮기는 데 필요한 정보를 볼 수 있다².

정리된 파일은 Dev Mode에서 더 큰 효과를 낸다. 레이어 이름이 명확하고 오토 레이아웃이 적용되어 있으면 개발자는 색상, 폰트, 간격, 크기, 에셋을 빠르게 확인할 수 있다. Figma Inspect에서는 선택한 레이어나 프레임의 계층, 치수, 간격, 색상, 타이포그래피, 텍스트, 컴포넌트 속성, 스타일, 변수, 내보내기 에셋 등을 확인할 수 있다³.

다만 모든 구현 환경에 같은 정보를 넘기면 안 된다. Unity, Unreal, 웹은 UI를 만드는 방식이 다르다. 공통 정보와 플랫폼별 정보를 구분해야 한다.

공통으로 넘길 정보

화면 이름과 목적
주요 사용자 행동
프레임 크기와 기준 해상도
색상 토큰과 실제 색상값
폰트, 크기, 굵기, 줄 간격
간격, 패딩, 정렬 규칙
컴포넌트 이름과 상태
아이콘, 이미지, 배경 에셋
클릭, 포커스, 비활성, 오류 상태
스크롤 여부와 고정 영역

Unity UI Toolkit에 넘길 정보

Unity UI Toolkit은 UXML과 USS를 사용해 UI 구조와 스타일을 나누어 관리한다. 따라서 Figma에서 다음 정보를 명확히 넘기면 좋다.

프레임 계층을 UXML 구조로 옮길 수 있는지
버튼, 리스트, 카드, HUD 같은 반복 컴포넌트 단위
색상과 폰트 값을 USS 변수로 만들 수 있는지
9-slice가 필요한 패널 또는 버튼 배경
SVG로 유지할 아이콘과 PNG로 내보낼 이미지
키보드나 게임패드 포커스 순서

예를 들어 inventory-grid 안에 item-card가 반복된다면, 개발자는 이를 리스트 데이터와 연결할 수 있다. Figma 파일에서 카드 구조가 정리되어 있어야 이 판단이 쉽다.

Unreal UMG에 넘길 정보

Unreal의 UMG는 Widget Blueprint 중심으로 UI를 구성한다. 따라서 위젯으로 분리할 단위와 상태가 중요하다.

WBP_ItemCard, WBP_HealthBar처럼 분리할 위젯 후보
Canvas, Overlay, Horizontal Box, Vertical Box로 옮길 수 있는 배치 구조
Anchors가 필요한 영역: HUD, 미니맵, 하단 버튼 등
텍스트가 데이터 바인딩될 위치
애니메이션이 필요한 상태: 등장, 선택, 경고, 비활성
텍스처로 내보낼 배경과 벡터로 유지할 아이콘

UMG에서는 화면 크기에 따른 앵커와 정렬이 중요하다. Figma에서 오토 레이아웃과 기준 프레임을 정리해 두면 어떤 요소가 고정되고 어떤 요소가 늘어나는지 설명하기 쉽다.

웹 프론트엔드에 넘길 정보

웹에서는 HTML 구조, CSS 스타일, 컴포넌트 분리가 핵심이다. Dev Mode에서 다음 정보를 확인할 수 있어야 한다.

버튼, 카드, 모달, 탭 같은 재사용 컴포넌트
CSS 변수로 만들 색상, 간격, 폰트 토큰
반응형 중단점과 레이아웃 변화
hover, focus, active, disabled 상태
접근성에 필요한 라벨과 포커스 순서
SVG 아이콘, 래스터 이미지, 배경 이미지 구분

웹 구현에서는 접근성 검토도 함께 필요하다. Figma 파일에 상태와 라벨이 빠져 있으면 개발자가 추측하게 된다. 추측이 많아질수록 디자인과 구현은 달라진다.

정리된 파일은 AI에게도 좋은 입력이다

이 장의 핵심은 간단하다. 정리되지 않은 디자인 파일은 AI와 개발자 모두에게 나쁜 입력이다. 이름 없는 레이어, 뒤섞인 계층, 좌표로만 배치된 UI, 출처가 불분명한 에셋은 구현 시간을 늘린다.

반대로 구조화된 파일은 다음 작업을 쉽게 만든다.

AI에게 특정 컴포넌트 수정 요청하기
Dev Mode에서 개발 정보 확인하기
Unity나 Unreal로 UI 구조 옮기기
반복 UI를 코드 컴포넌트로 만들기
QA 과정에서 디자인과 구현 차이 찾기

Figma 파일 정리는 문서 작업이 아니라 제작 파이프라인의 일부다. AI가 초안을 만들고, 사람이 구조를 정리하고, 개발자가 구현 가능한 정보로 받아야 한다. 이 흐름이 만들어지면 AI는 단순한 그림 생성 도구가 아니라 실제 제작 속도를 높이는 보조 도구가 된다.

실무 점검표

개발자에게 넘기기 전 다음 항목을 확인한다.

Rectangle, Group, Frame 같은 기본 이름이 남아 있지 않은가?
컴포넌트 단위가 이름과 계층으로 드러나는가?
버튼, 카드, 리스트, 모달에 오토 레이아웃이 적용되어 있는가?
반복 요소가 컴포넌트 또는 인스턴스로 정리되어 있는가?
색상, 폰트, 간격이 토큰이나 스타일로 연결되어 있는가?
내보낼 아이콘과 이미지를 구분했는가?
상태별 화면 또는 변형이 준비되어 있는가?
Dev Mode에서 구현자가 필요한 값을 바로 확인할 수 있는가?
Unity, Unreal, 웹 중 어떤 환경으로 옮길지에 맞춰 추가 주석을 달았는가?

이 점검표를 통과한 파일은 AI에게도, 개발자에게도 읽기 쉬운 입력이 된다. 구조화가 곧 생산성이다.

참고

¹Rename layers with AI – Figma Learn

²Guide to Dev Mode – Figma Learn

³Guide to inspecting – Figma Learn

책 목록

Figma AI와 Unity·Unreal AI 워크플로

전체 목차 보기