Flutter 앱 UI 설계를 처음 시작할 때 Figma와 Codex를 함께 쓰는 방법

앱을 처음 설계하실 때 많은 분들이 가장 먼저 부딪히는 문제는 화면을 “어떻게 정리해서 만들 것인가”입니다.
특히 Flutter처럼 화면을 위젯으로 차곡차곡 쌓아 만드는 구조에서는, 보기 좋은 시안만 있다고 해서 바로 개발이 쉬워지는 것은 아닙니다.

버튼은 고정 크기로 둘지, 화면 폭에 맞춰 늘릴지, 텍스트는 내용만큼만 차지하게 둘지 같은 판단이 필요합니다.
이 기준이 없이 화면만 그려두면, 나중에 Codex로 코드를 만들 때도 수정이 반복되고 구조가 흐트러지기 쉽습니다.

그래서 중요한 것은 단순히 예쁜 화면을 만드는 것이 아니라, 개발에 바로 연결될 수 있는 방식으로 UI를 정리하는 것입니다.
이때 가장 현실적인 조합이 바로 Figma와 Codex를 함께 사용하는 방식입니다.

Figma는 화면을 시각적으로 정리하고 검토하는 데 강점이 있고, Codex는 그 구조를 바탕으로 실제 Flutter 코드로 옮기는 데 강점이 있습니다.
두 도구를 함께 쓰면, 화면 구성을 훨씬 직관적으로 다듬으면서도 개발 효율까지 챙길 수 있습니다.

Figma와 Codex를 함께 쓰는 이유

Flutter UI를 말로만 설명해서 구현하려고 하면 생각보다 비효율적입니다.
예를 들어 “버튼 높이는 48, 좌우 여백은 24, 텍스트와 입력창 간격은 16, 입력창은 화면 폭을 채우게” 같은 설명을 계속 적어야 하기 때문입니다.

이런 방식은 초반에는 가능해 보이지만, 화면 수가 늘어나면 금방 복잡해집니다.
로그인 화면 하나는 괜찮아도, 홈 화면과 상세 화면, 설정 화면까지 늘어나면 일관성을 유지하기가 어려워집니다.

반면 Figma에서는 버튼 크기, 내부 여백, 정렬, 화면 간 균형을 눈으로 바로 확인할 수 있습니다.
그리고 Codex는 그렇게 정리된 구조를 읽고 Flutter 코드로 구현하는 역할을 맡습니다.

즉, Figma는 화면을 정리하는 도구, Codex는 구현을 가속하는 도구로 이해하시면 됩니다.
둘을 섞어 쓰면 “설명만으로 만들 때 생기는 답답함”을 크게 줄일 수 있습니다.

Draft에서 시작하는 것이 좋은 이유

혼자 진행하는 프로젝트라면 처음부터 팀 단위 구조를 고민하실 필요는 없습니다.
이럴 때는 Figma의 Drafts에서 시작하는 것이 가장 편합니다.

Draft는 개인 작업 공간처럼 쓸 수 있어서 부담이 적고, 초안 작업을 자유롭게 쌓기 좋습니다.
앱 화면을 정리하고 구조를 잡는 단계에서는 이 방식이 오히려 훨씬 실용적입니다.

여기서 중요한 점은, 화면마다 파일을 따로 만들 필요가 없다는 것입니다.
초보자분들은 로그인 화면 하나, 홈 화면 하나, 설정 화면 하나를 각각 별도 파일로 만들고 싶어 하시는데, 그렇게 되면 관리가 더 어려워집니다.

오히려 하나의 Figma Design 파일 안에 여러 페이지를 만들고, 각 페이지 안에 여러 프레임을 두는 편이 훨씬 깔끔합니다.
예를 들어 아래처럼 정리하면 구조가 금방 잡힙니다.

01_Screens
02_Components
03_Archive

이렇게 페이지를 나누고, 01_Screens 안에 Login, Home, Settings 같은 프레임을 두면 됩니다.
이 구조만 익혀도 앱 전체 화면을 훨씬 보기 좋게 관리할 수 있습니다.

페이지와 프레임은 어떻게 구분하면 좋을까

Figma를 처음 접하실 때 가장 헷갈리는 것이 페이지와 프레임의 차이입니다.
이 둘만 정확히 이해해도 작업 속도가 크게 올라갑니다.

페이지는 큰 분류입니다.
예를 들어 인증 화면 묶음, 메인 화면 묶음, 공통 컴포넌트 묶음처럼 관리하는 공간입니다.

프레임은 실제 앱 화면 하나입니다.
즉, 로그인 화면 하나가 프레임이고, 홈 화면 하나도 프레임입니다.

정리하면 이렇게 이해하시면 됩니다.

파일: 프로젝트 전체
페이지: 큰 카테고리
프레임: 실제 앱 화면 하나

Flutter 앱처럼 화면이 여러 개인 프로젝트에서는 이 구조가 특히 중요합니다.
한 파일 안에 여러 화면을 넣어두고, 필요한 프레임만 골라 Codex에 전달하면 작업 효율이 훨씬 높아집니다.

안드로이드 UI는 어떤 크기에서 시작하는 것이 좋을까

안드로이드 앱 UI를 처음 설계할 때는 특정 기종 해상도에 너무 집착하실 필요는 없습니다.
처음에는 세로형 기준 프레임 하나를 정해서 작업하는 것이 가장 좋습니다.

가장 무난한 시작점은 360 × 800 기준의 세로형 화면입니다.
이 정도 크기는 모바일 앱 기본 구조를 잡기에 적당하고, 버튼과 입력창, 텍스트 배치를 보기에도 좋습니다.

처음부터 가로형이나 태블릿까지 한 번에 맞추려고 하면 오히려 설계가 흔들릴 수 있습니다.
세로형 화면에서 우선 구조를 완성한 뒤, 그 프레임을 복사해서 가로형과 큰 화면을 검토하는 순서가 훨씬 안정적입니다.

즉, 순서는 아래처럼 가져가는 것이 좋습니다.

세로형 기준 화면 설계
핵심 화면만 가로형으로 복사해 검토
필요한 경우 큰 화면 대응 구조 추가

이 순서로 가야 화면의 우선순위가 분명해지고, Flutter 코드로 옮길 때도 논리가 자연스럽습니다.

Flutter 구조를 Figma에서 어떻게 표현해야 할까

Flutter는 위에서부터 위젯을 쌓는 구조입니다.
세로 배치는 Column, 가로 배치는 Row, 남는 공간을 채우는 것은 Expanded나 Flexible로 자주 표현합니다.

이 개념을 Figma에서도 비슷하게 전달해야 Codex가 구조를 더 잘 읽습니다.
여기서 중요한 것이 바로 Fixed, Hug contents, Fill container입니다.

Fixed

고정 크기입니다.
예를 들어 아이콘 24×24, 프로필 이미지 48×48, 버튼 높이 48 같은 요소가 여기에 해당합니다.

Hug contents

내용만큼만 크기를 가지는 방식입니다.
짧은 텍스트 버튼, 칩, 작은 라벨, 제목 텍스트 같은 요소에 적합합니다.

Fill container

부모가 가진 공간을 채우는 방식입니다.
입력창, 메인 버튼, 카드 본문 폭 같은 요소에 많이 사용합니다.

이 세 가지를 잘 구분해 두면, Figma 시안이 단순한 그림이 아니라 개발 의도를 가진 설계도가 됩니다.
바로 이 지점에서 Codex가 더 안정적으로 동작합니다.

로그인 화면 예시로 보는 구조 정리 방법

가장 쉬운 예시로 로그인 화면을 생각해보겠습니다.
구성은 아래 정도면 충분합니다.

로고
제목
설명 문구
이메일 입력창
비밀번호 입력창
로그인 버튼
하단 텍스트 버튼

이 화면을 Figma에서 만들 때는 전체를 하나의 세로 Auto layout 안에 넣는 것이 좋습니다.
예를 들어 Login_Content라는 이름의 세로 레이아웃을 만들고, 그 안에 요소를 순서대로 배치하는 방식입니다.

구체적으로는 아래처럼 나누면 됩니다.

로고: 72 × 72 고정
제목: 내용만큼
설명 문구: 내용만큼 또는 텍스트 박스
이메일 입력창: 높이 고정, 가로는 채움
비밀번호 입력창: 높이 고정, 가로는 채움
로그인 버튼: 높이 고정, 가로는 채움
회원가입 버튼: 내용만큼

그리고 이 전체 묶음에 아래 기준을 주면 좋습니다.

세로 간격: 16
좌우 패딩: 24
상하 패딩: 24~32

이렇게 하면 Flutter에서도 구조가 자연스럽게 대응됩니다.
전체는 Column, 입력창과 메인 버튼은 화면 폭을 채우고, 작은 텍스트 버튼은 내용만큼만 공간을 차지하는 방식으로 구현할 수 있습니다.

세로형에서 가로형으로 확장할 때 중요한 점

세로형 화면을 다 만든 뒤, 가로형으로 자동 확장되는지 궁금해하시는 분들이 많습니다.
결론부터 말하면 어느 정도는 가능하지만, 완전 자동은 아닙니다.

Auto layout을 잘 설정해두면 버튼, 입력창, 카드 같은 요소는 꽤 자연스럽게 늘어납니다.
하지만 화면 구조 자체가 바뀌는 경우에는 사람이 직접 판단해야 합니다.

예를 들어 세로형에서는 모든 요소가 한 줄로 쌓이지만,
가로형에서는 왼쪽에 설명 영역, 오른쪽에 입력 영역처럼 2단 구조가 더 자연스러울 수 있습니다.

즉, Auto layout은 늘어나는 동작을 도와주는 도구이지,
화면 설계 자체를 대신해주는 기능은 아닙니다.

그래서 가장 좋은 방법은 세로형 화면을 먼저 완성한 뒤,
그 프레임을 복사해서 Landscape 버전으로 검토하는 방식입니다.

이때 확인해야 할 것은 단순히 “늘어났는가”가 아니라 아래 항목입니다.

간격이 어색해지지 않았는가
버튼이 지나치게 길어지지 않았는가
텍스트 줄바꿈이 이상하지 않은가
좌우 균형이 무너지지 않았는가

이 과정을 거쳐야 실제 Flutter에서 가로형 대응을 할 때도 설계가 명확해집니다.

Codex는 내부 마진과 속성 차이를 읽을 수 있을까

많이 궁금해하시는 부분입니다.
정리해서 말씀드리면, Codex는 어느 정도 읽을 수 있지만 구조가 분명할수록 훨씬 잘 읽습니다.

예를 들어 겉으로는 폭이 똑같아 보이는 두 버튼이 있다고 해보겠습니다.
하나는 우연히 고정 폭 280이라 같은 크기일 수 있고, 다른 하나는 부모 폭을 채워서 같은 크기일 수도 있습니다.

사람 눈에는 비슷해 보여도, 개발 의미는 완전히 다릅니다.
Codex도 이미지나 시각 정보만으로는 이 의도를 100% 확정하기 어렵습니다.

그래서 중요한 것은 Figma에서 단순히 보기 좋게 만드는 것이 아니라,
이 요소가 고정인지, 내용 기준인지, 부모를 채우는지를 분명히 표현하는 것입니다.

이 기준이 살아 있으면 Codex가 다음과 같은 차이를 더 잘 해석할 수 있습니다.

내부 패딩
요소 간 간격
정렬 방식
고정 크기와 상대 크기의 차이
화면 폭 변화에 따른 동작

즉, Codex가 잘 읽게 만드는 핵심은 “정확한 그림”보다도 정확한 구조 표현입니다.

자주 하는 실수와 꼭 피해야 할 점

처음 작업하실 때 아래 실수는 꼭 피하시는 것이 좋습니다.

첫째, FigJam 파일과 Figma Design 파일을 혼동하는 경우입니다.
UI 설계와 화면 검토는 Figma Design 파일에서 해야 합니다. FigJam은 아이디어 정리와 메모 용도에 더 가깝습니다.

둘째, 화면마다 파일을 따로 만드는 경우입니다.
이 방식은 초반에는 편해 보여도, 화면 수가 늘어나면 구조를 파악하기가 더 어려워집니다.

셋째, Auto layout 없이 도형만 배치하는 경우입니다.
이렇게 만들면 처음에는 쉬워 보여도, 간격 수정이나 가로형 대응이 매우 힘들어집니다.

넷째, “예쁘게 보이는 것”만 우선하는 경우입니다.
개발까지 연결할 생각이라면, 반드시 고정 크기와 상대 크기를 구분해야 합니다.

다섯째, 처음부터 유료 도구 조합을 과하게 구성하는 경우입니다.
혼자 진행하는 프로젝트라면 초반에는 Draft와 기본 구조 정리만으로도 충분히 시작할 수 있습니다.

정리하며

Figma Codex 연동의 핵심은 도구를 많이 쓰는 것이 아니라, 역할을 분명히 나누는 것입니다.
Figma는 화면 구조와 시각적 균형을 정리하고, Codex는 그 결과를 Flutter 코드로 구현하는 역할을 맡습니다.

혼자 하는 Flutter 프로젝트라면 Draft에서 시작해도 충분합니다.
한 개의 Design 파일 안에 여러 페이지와 프레임을 두고, 로그인·홈·설정 같은 화면을 차례대로 정리하면 됩니다.

그리고 가장 중요한 기준은 하나입니다.
UI를 단순히 “보여주는 것”이 아니라, 개발 가능한 구조로 표현하는 것입니다.

고정 크기인지, 내용 크기인지, 부모를 채우는지 이 세 가지 기준만 분명히 잡아도 설계 품질은 크게 달라집니다.
이 원칙이 잡히면 Codex를 활용한 Flutter UI 구현도 훨씬 수월해집니다.

지금 시작하신다면 가장 먼저 해보실 일은 어렵지 않습니다.
Figma Draft 파일 하나를 만들고, 01_Screens 페이지 안에 Login 프레임 하나를 만든 뒤, 로고·제목·입력창·버튼을 차례대로 배치해보시면 됩니다.

이 작은 시작이 결국 전체 앱 UI 품질을 결정합니다.
처음 구조를 제대로 잡아두면, 이후 화면이 늘어나도 훨씬 안정적으로 확장하실 수 있습니다.