빈 캔버스 대신 1차 시안에서 시작하기
좋은 UI는 처음부터 완성된 형태로 나오지 않는다. 게임 UI든 앱 화면이든 먼저 빠르게 만들고, 팀이 함께 보며 고치는 과정에서 좋아진다. Figma AI의 초기 디자인 생성 기능은 이 첫 단계를 줄여 준다. Figma는 First Draft를 아이디어를 편집 가능한 와이어프레임이나 디자인으로 빠르게 바꾸는 기능으로 설명한다.1 중요한 점은 "편집 가능하다"는 것이다. 결과물을 그대로 쓰라는 뜻이 아니라, 팀이 토론할 수 있는 구조물을 빠르게 만든다는 뜻이다.
이 장에서는 Figma AI의 Make Designs 또는 First Draft 계열 기능을 사용한다고 가정한다. 이름이나 메뉴 위치는 제품 업데이트에 따라 달라질 수 있지만, 실무 원리는 같다. 텍스트로 목적을 설명하고, AI가 만든 화면을 평가하고, 기존 컴포넌트와 토큰으로 정리한 뒤, 엔진 구현을 고려해 다시 다듬는다.
초보자가 자주 하는 실수는 "판타지 RPG 상점 화면 만들어 줘"처럼 짧게 입력하는 것이다. 이런 요청도 화면을 만들 수는 있다. 하지만 어떤 플랫폼인지, 누가 쓰는지, 무엇을 먼저 보여 줘야 하는지, 버튼은 어떤 입력 장치로 눌러야 하는지 알 수 없다. 그래서 보기에는 그럴듯하지만 실제 프로젝트에 넣기 어려운 화면이 나온다.
AI 생성 이미지
프롬프트는 화면 요구사항 문서처럼 쓴다
Figma AI에 입력하는 프롬프트는 예쁜 문장이 아니라 작은 작업 지시서여야 한다. 다음 다섯 가지를 포함하면 결과가 안정된다.
사용자: 누가 이 화면을 쓰는가?
목적: 사용자가 이 화면에서 무엇을 끝내야 하는가?
핵심 화면: 어떤 화면 또는 상태가 필요한가?
플랫폼: 모바일, PC, 콘솔, 태블릿 중 어디에서 쓰는가?
제약 조건: 해상도, 조작 방식, 접근성, 브랜드 톤, 포함·제외 요소는 무엇인가?
예를 들어 모바일 게임의 인벤토리 화면이라면 다음처럼 쓸 수 있다.
모바일 세로 화면용 캐주얼 RPG 인벤토리 UI를 만들어 주세요. 사용자는 전투 후 획득한 장비를 확인하고, 장착하거나 분해해야 합니다. 핵심 영역은 아이템 그리드, 선택한 아이템 상세 정보, 장착 버튼, 분해 버튼, 필터 탭입니다. 한 손 조작을 고려해 주요 버튼은 화면 하단에 배치하고, 작은 텍스트를 피하세요. 아이템 슬롯은 희귀도 색상으로 구분하되 색상만으로 의미가 전달되지 않게 아이콘이나 라벨도 함께 사용하세요. 390×844 모바일 기준으로 작성하고, 나중에 Unity UI로 옮길 수 있도록 반복 요소는 카드형 구조로 정리해 주세요.
이 프롬프트에는 "인벤토리"라는 단어보다 중요한 정보가 많다. 사용자의 행동, 완료해야 할 목적, 화면 구성 요소, 플랫폼, 조작 조건, 접근성 조건, 구현 방향이 들어 있다. AI는 이 정보를 바탕으로 더 구체적인 초안을 만든다.
PC 또는 콘솔 게임의 설정 화면이라면 조건이 달라진다.
1920×1080 PC/콘솔 공용 게임 설정 화면을 만들어 주세요. 사용자는 그래픽, 오디오, 조작, 접근성 설정을 바꿉니다. 왼쪽에는 카테고리 탭, 오른쪽에는 선택된 설정 목록을 배치하세요. 게임패드로 위아래 이동과 좌우 값 변경이 가능해야 하므로 포커스 상태가 분명해야 합니다. 저장, 되돌리기, 기본값 복원 버튼을 하단에 배치하고, 현재 변경 사항이 저장되지 않았을 때 알림 영역을 보여 주세요.
여기서 핵심은 "게임패드 포커스"다. 마우스 중심 앱 화면과 콘솔 UI는 구조가 다르다. AI가 이 차이를 알 수 있도록 처음부터 적어야 한다.
화면별로 평가할 기준을 정한다
AI가 만든 대시보드, 인벤토리, 로그인, 상점, 설정 화면은 최종안이 아니다. "이 방향으로 갈지 말지 판단하는 1차 시안"이다. 그래서 화면을 볼 때도 예쁜지보다 목적에 맞는지 먼저 확인해야 한다.
대시보드 또는 HUD는 현재 상태를 빠르게 읽는 화면이다. 체력, 재화, 미션, 알림, 진행률 같은 정보가 동시에 들어가기 쉽다. 이때 가장 중요한 정보가 가장 먼저 보이는지 확인한다. 전투 게임이라면 체력과 스킬 쿨타임이 장식보다 우선이다. 경영 시뮬레이션이라면 자원 변화와 위험 알림이 우선이다.
인벤토리는 반복 요소가 많은 화면이다. 아이템 슬롯, 필터, 정렬, 상세 패널이 명확해야 한다. AI가 그리드를 예쁘게 만들었더라도 선택 상태, 비활성 상태, 희귀도 표시, 빈 슬롯 표시가 빠져 있으면 실무 초안으로는 부족하다.
로그인 화면은 입력 오류와 계정 복구가 중요하다. 이메일, 비밀번호 입력칸만 있으면 끝이 아니다. 오류 메시지, 비밀번호 보기, 게스트 로그인, 약관 링크, 로딩 상태가 필요할 수 있다. 게임에서는 플랫폼 로그인, 게스트 계정, 보호자 동의 같은 조건도 고려해야 한다.
상점 화면은 구매 판단을 돕는 화면이다. 상품 카드가 화려한지보다 가격, 보유 재화, 구매 제한, 할인 조건, 확률형 상품 고지처럼 사용자가 알아야 할 정보가 충분한지 확인한다. 특히 결제와 관련된 화면은 법적·윤리적 검토가 필요하다. AI 초안이 이런 조건을 자동으로 보장하지 않는다.
설정 화면은 "나중에 넣자"라고 미루기 쉽지만 접근성과 품질에 직접 연결된다. 자막, 색각 보정, 화면 흔들림, 음량, 조작 반전, 감도, 키 설정처럼 사용자의 플레이 가능성을 좌우하는 항목이 있다. AI가 만든 기본 설정 화면에 이런 항목이 없다면 사람이 추가해야 한다.
기존 컴포넌트와 토큰이 일관성을 만든다
AI는 빈 파일에서도 화면을 만들 수 있다. 하지만 실무에서는 빈 파일보다 기존 컴포넌트와 디자인 토큰이 있는 파일이 훨씬 유리하다. 디자인 토큰은 색상, 글꼴 크기, 간격, 둥근 모서리, 그림자 같은 디자인 값을 이름으로 관리하는 규칙이다. 예를 들어 color/bg/panel, space/16, radius/card, text/body/14처럼 정해 두면 화면마다 값이 흔들리지 않는다.
AI가 만든 상점 버튼이 화면마다 조금씩 다르다고 해 보자. 어떤 버튼은 둥근 모서리가 8px이고, 어떤 버튼은 12px이며, 텍스트 크기도 다르다. 이 상태로 Unity나 Unreal에 옮기면 개발자는 매번 다른 값을 맞춰야 한다. 반대로 버튼 컴포넌트가 Button/Primary, Button/Secondary, Button/Disabled로 정리되어 있고 색상과 간격이 토큰으로 연결되어 있으면 생성 결과를 빠르게 기존 규칙에 맞출 수 있다.
현재 Figma AI의 초기 생성 기능이 모든 팀의 자체 디자인 시스템을 완전히 이해해 자동 적용한다고 가정해서는 안 된다. 공식 안내에서도 First Draft는 Figma가 제공하는 와이어프레임·디자인 라이브러리 기반의 초기 탐색에 적합하며, 자체 디자인 시스템으로 직접 생성하는 데에는 제한이 있음을 밝히고 있다.1 그래서 실무에서는 두 단계로 접근하는 편이 안전하다.
첫째, AI로 화면의 큰 구조를 만든다. 둘째, 사람이 기존 컴포넌트와 토큰으로 치환한다. 예를 들어 AI가 만든 "구매하기" 버튼을 그대로 두지 않고 Button/Primary/Large 컴포넌트로 바꾼다. 상점 카드의 가격 텍스트는 Text/Price, 희귀도 배지는 Badge/Rarity로 바꾼다. 이렇게 하면 AI 초안이 팀의 디자인 시스템 안으로 들어온다.
이 과정은 나중에 개발 핸드오프에도 도움이 된다. Figma Dev Mode는 개발자가 레이어 구조, 치수, 컴포넌트 속성, 코드 스니펫 같은 구현 정보를 확인하는 데 쓰인다.2 즉, 디자인 파일이 컴포넌트와 변수 중심으로 정리되어 있을수록 개발자가 "이 모양을 어떻게 구현하지?"라고 추측하는 시간이 줄어든다.
사람이 반드시 검토할 네 가지
AI가 만든 화면을 받으면 다음 순서로 검토한다. 이 절차는 디자이너만을 위한 것이 아니다. 기획자, 개발자, QA도 함께 보면 좋다.
1. 정보 위계
가장 중요한 정보가 먼저 보이는가? 사용자가 지금 해야 할 행동이 분명한가? 인벤토리에서 선택한 아이템 이름보다 배경 장식이 더 눈에 띈다면 위계가 잘못된 것이다. 상점에서 구매 버튼보다 배너 이미지가 더 강하면 결정을 방해할 수 있다.
검토할 때는 화면을 3초만 보고 무엇을 해야 하는지 말해 본다. 팀원이 서로 다른 답을 한다면 구조를 다시 잡아야 한다.
2. 터치 영역과 클릭 영역
모바일 화면에서는 손가락으로 누를 수 있는 크기가 필요하다. 작은 아이콘을 촘촘히 배치하면 보기에는 정보량이 많아 보이지만 실제 조작은 어렵다. 중요한 버튼은 충분한 크기와 간격을 가져야 한다. PC 화면에서도 클릭 영역이 텍스트에만 걸려 있는지, 카드 전체를 누를 수 있는지 정해야 한다.
AI 초안은 종종 버튼처럼 보이는 장식을 만든다. 따라서 실제로 누를 요소와 단순 표시 요소를 구분해 레이어 이름과 컴포넌트 이름에 반영한다.
3. 게임패드 조작 가능성
콘솔 또는 PC 게임패드 지원이 필요한 UI라면 포커스 이동 순서를 확인해야 한다. 위, 아래, 왼쪽, 오른쪽 입력을 했을 때 어느 요소로 이동하는지 예측 가능해야 한다. 포커스 상태도 명확해야 한다. 색만 바꾸는 것보다 테두리, 확대, 배경 강조처럼 눈에 보이는 차이가 필요하다.
상점 화면을 예로 들면 상품 카드 그리드에서 오른쪽 끝으로 이동했을 때 다음 줄로 내려갈지, 멈출지, 상세 패널로 이동할지 정해야 한다. AI가 만든 시안은 이런 입력 흐름을 대부분 설명하지 않는다. 사람이 별도 주석으로 남겨야 한다.
4. 반응형 레이아웃
한 해상도에서만 예쁜 화면은 실무에서 오래 버티기 어렵다. 모바일은 기기 비율이 다양하고, PC는 창 크기와 해상도가 다르다. Figma에서는 오토 레이아웃, 제약 조건, 변수, 컴포넌트를 사용해 화면이 늘어나거나 줄어들 때의 규칙을 정리해야 한다.
예를 들어 인벤토리 그리드는 화면이 넓어지면 열 수를 늘릴지, 카드 크기를 키울지, 여백만 늘릴지 결정해야 한다. 설정 화면은 작은 화면에서 왼쪽 탭과 오른쪽 목록을 유지할지, 탭을 상단 드롭다운으로 바꿀지 정해야 한다. 이런 결정은 AI에게 맡기는 것이 아니라 프로젝트의 플랫폼 전략에 맞춰 사람이 정한다.
초안을 실무 화면으로 다듬는 순서
실제 작업에서는 다음 순서로 진행하면 안정적이다.
만들 화면의 목적과 사용자 행동을 한 문장으로 쓴다.
플랫폼과 입력 장치를 정한다.
반드시 들어갈 정보와 제외할 정보를 나눈다.
Figma AI에 구조화된 프롬프트를 입력한다.
생성된 여러 안을 비교하고, 하나를 기준안으로 고른다.
정보 위계, 조작 영역, 게임패드 포커스, 반응형 규칙을 검토한다.
기존 컴포넌트와 디자인 토큰으로 치환한다.
Dev Mode에서 개발자가 읽을 수 있는 이름, 치수, 상태, 주석을 정리한다.
이 순서의 핵심은 "AI 생성 → 사람 검토 → 시스템 정리"다. AI가 빠르게 초안을 만들고, 사람은 제품 목적과 품질 기준으로 판단한다. 그다음 디자인 시스템 안에 넣어 반복 가능한 구조로 만든다.
Figma 화면은 이후 Unity나 Unreal로 옮겨질 수 있다. Unity Assistant는 Figma 프로젝트 링크를 바탕으로 선택한 화면의 이미지 에셋과 UI 레이아웃 파일을 생성하는 흐름을 제공한다.3 하지만 엔진으로 가져갈 수 있다는 것과 좋은 UI 구조라는 것은 다르다. 레이어 이름이 엉켜 있고, 상태가 빠져 있고, 반응형 규칙이 없다면 가져온 뒤 다시 손봐야 한다.
따라서 이 장의 목표는 AI로 그럴듯한 그림을 얻는 것이 아니다. 팀이 빠르게 논의할 수 있는 1차 시안을 만들고, 그것을 개발 가능한 화면 구조로 바꾸는 것이다. 다음 장에서는 이렇게 만든 Figma 파일을 더 구체적으로 정리해 개발자가 읽고 엔진으로 옮기기 쉬운 구조로 만드는 방법을 다룬다.
참고
1Use First Draft with Figma AI
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.