프로젝트에서 보기 →

Flutter 모바일 개발이 이렇게 쉽다고? ( EP 01 )

태그
기술
시작일
종료일
수정일

https://www.youtube.com/watch?v=1UjR-zTIbx4

1. 이건 꼭 알아야 한다[^1]

[? 질문] Flutter에서 주어진 화면(UI) 레이아웃 예제를 어떤 관점과 순서로 분석해서 구현으로 옮겨야 하는가[^4]
[= 답] 화면을 먼저 **큰 덩어리(이미지/타이틀/버튼/설명 텍스트)**로 쪼개고, 각 덩어리 내부를 다시 Row/Column(행/열) 구조로 식별한 뒤, 겹침(Stack 필요 여부)·스크롤(Scroll 필요 여부)·정렬/패딩 필요 여부를 점검하는 방식으로 하향식으로 접근한다.[^15]

[? 질문] Flutter 기본 프로젝트(카운터 앱)에서 레이아웃 예제를 만들기 위한 “출발 코드”는 어떻게 준비하는가[^19]
[= 답] flutter create로 생성되는 기본 카운터 예제 코드를 걷어내고, main.dart를 **간단한 단일 앱(Hello World 수준)**으로 재구성한 뒤, 에뮬레이터/디바이스에서 실행 환경(디바이스 매니저 UI 크기 등)을 정리하고 확인한다.[^24]

[? 질문] 레이아웃 코드가 길어질 때 가독성을 위해 함수로 분리해도 되는가, 성능 관점에서의 주의점은 무엇인가[^17]
[= 답] 중첩이 깊어 시각적 혼란이 생기면 변수/함수로 일부를 분리할 수 있지만, Flutter는 빌드/리렌더 과정이 빈번하므로 함수 분리는 성능에 영향을 줄 수 있어 보통은 StatelessWidget 등 별도 위젯 클래스로 분리하는 방식이 자주 쓰인다.[^18]

2. 큰 그림[^4]

이 콘텐츠는 Flutter 공식(또는 대표) 레이아웃 예제 화면을 대상으로, “코드를 바로 치기” 전에 화면을 어떻게 분해/도식화해서 Row/Column 중심으로 구현할지 분석하는 과정을 설명한다.[^9] 또한 Flutter 기본 생성 프로젝트의 구조와, 예제 구현을 위한 최소한의 초기 코드 정리 및 실행(에뮬레이터 실행, 디바이스 매니저 조절)까지 이어진다.[^24]

  • 레이아웃 분석 절차를 먼저 잡는다: 큰 요소를 식별하고, 내부를 Row/Column으로 나누며, 그리드/겹침/스크롤/정렬·패딩 필요 여부를 체크한다.[^15]
  • 예제 화면은 단일 Column 흐름으로 정리된다: 이미지 → 타이틀 섹션 → 버튼 섹션 → 설명 텍스트 섹션 순으로 “위에서 아래”로 쌓인다.[^11]
  • 코드가 길어지면 분리 전략이 필요하다: 다만 함수 분리는 리빌드 시 비용이 될 수 있어, 보편적으로는 위젯 클래스로 분리하는 실무적 선택을 소개한다.[^18]

3. 하나씩 살펴보기[^1]

3.1 도입: 오늘 다룰 것—Flutter 레이아웃 예제 따라가기[^2]

📸 0:01

영상은 인사로 시작한 뒤, 오늘의 주제로 Flutter에서 “레이아웃(layers/레이아웃 예제)”를 살펴보겠다고 밝힌다.[^2] 진행 방식은 Flutter “대부(메인) 페이지”에 있는 레이아웃 관련 예제를 하나 골라, 그 예제를 직접 따라 만들어보는 흐름이다.[^3]

여기서 “따라 만들기”에 앞서 화면을 먼저 관찰하며 구성 요소를 눈으로 확인한다.[^5]

  • 화면 상단에 큰 이미지가 위치한다.[^5]
  • 이미지 아래에는 **문자열(설명 텍스트)**이 이어지고, 내용은 호수 설명 및 “스위스 어딘가” 같은 위치 설명으로 보인다고 말한다.[^6]
  • 오른쪽에는 별표(스타) 아이콘과 숫자가 있으며, 이 별표를 누르면 숫자가 계속 늘어나는 형태처럼 보인다고 설명한다(좋아요/즐겨찾기 유사 동작을 암시).[^7]
  • 그 아래에는 CALL(전화), ROUTE(경로), SHARE(공유) 같은 기능성 버튼(아이콘+텍스트)이 있는 구역이 보인다고 짚는다.[^8]
  • 더 아래에는 “Description” 성격의 텍스트 블록이 추가로 존재한다고 한다.[^9]

즉, 예제 화면은 “이미지 → 타이틀/평점 → 버튼 3개 → 본문 설명”처럼 대표적인 소개 페이지 레이아웃임을 관찰로 드러낸다.[^9]

3.2 화면을 ‘분리’해서 보는 방법: 큰 덩어리부터 9분(구획)하기[^10]

📸 0:58

화자는 화면을 간단히 분리해보자며, 먼저 이미지 영역이 있고 그 아래에 여러 정보 구역이 이어진다고 정리한다.[^10] “9분할”이라는 표현을 쓰며, 화면을 여러 블록으로 쪼개어 구조를 파악하는 습관을 강조한다.[^11]

그가 제안하는 큰 구획은 다음처럼 들린다:

  • 이미지 영역[^10]
  • (이미지 아래) 타이틀/별점/숫자 등이 있는 영역[^12]
  • (그 아래) 버튼 섹션(전화/라우트/쉐어)[^13]
  • (마지막) 설명 텍스트 블록[^9]

이 단계의 요지는 “코드로 들어가기 전에 화면을 먼저 기능 단위/레이아웃 단위로 분해하라”는 것이다.[^11]

3.3 레이아웃 도식화의 체크리스트: Row/Column, 그리드, 겹침(Stack), 스크롤, 정렬/패딩[^14]

📸 1:35

화자는 “기본 코드를 만들기 전에” 레이아웃을 먼저 분석하겠다며, 다이어그램 관점에서 무엇을 확인하는지 순서대로 말한다.[^14]

3.3.1 Row/Column 식별과 ‘그리드가 있는지’ 확인[^14]

  • 첫 단계로 **행(Row)과 열(Column)**을 식별한다.[^14]
  • 분석할 때 “레이아웃의 그리드가 있는지”를 먼저 나눠 보라고 말한다.[^15]
  • 이 예제는 “그리드가 없는 것 같다”고 판단한다.[^15]

여기서 “그리드”는 여러 행/열이 반복되는 격자형 배치를 뜻하며(예: 갤러리, 카드 목록 등), 이 예제는 그런 형태가 아니라는 결론으로 이어진다.[^15]

3.3.2 ‘로우 2개, 컬럼 4개’ 같은 오해를 경계—실제로는 Column 하나로 끝난다[^11]

화자는 어떤 사람은 빨간 선으로 나눠진 것처럼 “Row 2개”와 “Column 4개” 같은 방식으로 생각할 수도 있다고 언급한다.[^11] 하지만 이 예제는 그렇게 복잡한 격자 사고를 할 필요가 없고,

  • 이미지 하나,
  • 아래의 텍스트 블록들(타이틀/버튼/설명)이 이어지는 형태이므로,
  • 최상위는 사실상 하나의 Column으로 “위에서부터 1,2,3,4”를 쌓아 구현할 수 있다고 말한다.[^12]

즉, 화면 전체는 “세로로 쌓는 구조”가 메인이라는 판단이다.[^12]

3.3.3 겹치는 요소가 있는가? → 있으면 Stack 필요[^16]

다음 체크는 “겹치는 요소”가 있는지다.[^16]

  • 예를 들어 어떤 요소가 이미지 위에 올라가 겹쳐 보이면 “겹치는 요소”로 판단한다.[^16]
  • 그런 경우에는 아마 Stack 레이아웃이 필요하다고 생각하게 될 거라고 말한다.[^16]
  • 하지만 이번 예제에서는 겹치는 요소가 없으니 Stack을 사용할 일이 없다고 결론낸다.[^16]

여기서 전달되는 논리는 명확하다:
“겹침 UI → Stack 고려 / 겹침 없음 → Stack 불필요”[^16]

3.3.4 스크롤이 필요한가? (Scroll 필요 여부) 점검[^16]

화자는 이어서 스크롤(스크롤뷰)이 필요한지 여부도 확인해야 한다고 말하며, 이 예제는 “하나의 페이지 같고” 스크롤 필요성은 특별히 없어 보인다는 취지로 언급한다.[^16] (다만 실제 구현에서는 화면 높이에 따라 스크롤이 필요할 수 있는데, 영상에서는 우선 “단일 페이지” 관점으로 본다.)[^16]

3.3.5 정렬·패딩이 필요한가?—일부 요소가 센터 영역에 모여 보임[^16]

마지막으로 “정렬 패딩(또는 패딩)”이 필요한 요소가 있는지 확인해야 한다고 한다.[^16]

  • 얼핏 보면 “굳이 정렬이 되어 있지는 않은 것 같은데”라고 말하면서도,[^16]
  • 특정 요소들이 “센터 영역으로 모여 있는 것 같다”는 관찰을 덧붙이며,[^16]
  • 이 부분은 구현 시 확인이 필요하다고 예고한다.[^16]

정리하면, 레이아웃 분석 체크리스트는:

  1. Row/Column 식별 → 2) 그리드 여부 → 3) 겹침(Stack) 여부 → 4) 스크롤 여부 → 5) 정렬/패딩 여부[^14]

[!TIP] 레이아웃 분석 실전 체크리스트 큰 요소부터 나누고(이미지/타이틀/버튼/설명), 그 다음 “겹침(=Stack)”, “스크롤”, “정렬/패딩” 같은 구현 난이도에 영향을 주는 조건을 먼저 걸러내면 전체 구조가 빨리 잡힌다.[^14]

3.4 큰 요소 식별: 이미지 + 텍스트 블록(타이틀/버튼/설명) = Column으로 세로 정렬[^12]

📸 2:04

화자는 “큰 요소들 먼저 식별”하자고 하며, 이 화면은

  • 이미지,
  • 그리고 그 아래 텍스트 블록들

이렇게 해서 4개의 요소가 열(세로)로 하나의 Column에 정렬되어 있다고 정리한다.[^12] 즉 최상위 레이아웃은 Column이며, 그 Column의 자식으로 주요 섹션들이 위에서 아래로 배치된다는 그림이다.[^12]

3.5 타이틀 섹션(Title Section) 내부 분석: 텍스트 2개 + 별 아이콘 + 숫자[^20]

📸 3:26

화자는 각 행(섹션)을 더 깊게 “도표화”해본다며, 첫 번째로 “타이틀 섹션”을 정의한다.[^20]

3.5.1 타이틀 섹션 구성 요소[^20]

타이틀 섹션에는 다음이 들어간다고 말한다:

  • 왼쪽에 텍스트 2줄(예: 제목/부제 또는 위치 설명)[^20]
  • 오른쪽에 별표(스타) 아이콘[^20]
  • 그리고 숫자(카운트 텍스트)[^20]

별표와 숫자도 결국 위젯 관점에서는 (아이콘은 Icon 위젯, 숫자는 Text 위젯처럼) 구성될 수 있고, 말로는 “이것도 텍스트로 되어 있구요”라고 표현한다.[^20]

3.5.2 Row 내부 공간 배분: 왼쪽 텍스트 묶음은 Expanded로 감싸야 할 것[^21]

타이틀 섹션은 “3개의 하위 항목(자식)이 있다”고 말한다.[^21] 여기서 구조는 대체로:

  1. 왼쪽: 텍스트 2개를 담은 Column(혹은 텍스트 묶음)
  2. 가운데/오른쪽: 스타 아이콘
  3. 오른쪽: 숫자 텍스트

화자는 첫 번째 자식(왼쪽 텍스트 2줄)이 “남은 공간을 차지하므로” Expanded 위젯으로 래핑되어야 할 것 같다고 설명한다.[^21] 즉, Row에서 왼쪽 텍스트 묶음이 가능한 넓게 차지하고, 오른쪽의 스타/숫자는 필요한 만큼만 차지하게 하는 전형적인 패턴을 암시한다.[^21]

또한 “그건 만들다 보면 알게 될 거”라고 덧붙여, 구현 과정에서 자연스럽게 공간 제약을 체감하게 된다는 맥락을 준다.[^21]

3.5.3 스타+숫자 쪽도 공간을 많이 차지하니 Expanded? (화자의 판단 제시)[^21]

화자는 이어서 “별표와 텍스트(숫자)가 있는 것”도 (두 컬럼/두 요소가) Expanded로 만들어줘야 할 것 같다고 말한다.[^21] 이유로는 “스페이스를 좀 많이 차지하고 있으니까”라고 설명한다.[^21]

이 부분은 일반적으로는 (아이콘/숫자가 Expanded까지 필요 없을 수도 있으나) 화자는 화면상 공간 배분을 보며 “Expanded 고려”를 말한 것으로 이해하면 된다.[^21] 핵심은 Row에서 어떤 자식이 남는 공간을 먹어야 하는지를 판단하는 과정 자체를 보여준다는 점이다.[^21]

3.6 버튼 섹션(Button Section) 내부 분석: 아이콘+텍스트 Column 3개[^13]

📸 4:24

두 번째 행(섹션)으로 “버튼 섹션”이 있다고 명명하며 설명한다.[^13]

3.6.1 버튼 섹션의 자식 3개[^13]

버튼 섹션에는 3개의 자식이 있고, 각각은:

  • 전화(CALL): 아이콘 + 텍스트[^13]
  • 라우트(ROUTE): 아이콘 + 텍스트[^13]
  • 쉐어(SHARE): 아이콘 + 텍스트[^13]

화자는 이들이 “아이콘과 텍스트를 포함하는 열(Column)” 형태로 3개 있다고 설명한다.[^13] 즉, 버튼 섹션은 가로로 3개가 놓이므로 바깥은 Row, 각 버튼은 내부적으로 Column(아이콘 위/텍스트 아래)이 되는 전형적 구조를 시사한다.[^13]

3.7 구현 전략: 레이아웃 도표 후 하향식 접근이 가장 쉽다[^22]

📸 4:49

화자는 레이아웃을 도표(분석)한 후, 이를 구현할 때는 하향식(top-down) 접근을 취하는 것이 가장 쉽다고 말한다.[^22]

여기서 그가 설명하는 문제의식은 다음과 같다:

  • 처음 Flutter에 접근하면(Flutter뿐 아니라 다른 UI 프레임워크도 마찬가지로) 화면을 보고 “어떻게 레이아웃을 구성해야 하지?”가 막막할 수 있다.[^22]
  • 이런 경우, 화면을 잘게 “9분”해서 구조를 잡고(그림/도표화), 위에서 아래로 큰 구조부터 구현해 들어가면 전체 난이도가 낮아진다.[^22]

즉, “코드로 바로 뛰어들기 전에 설계도를 그려라”에 가깝다.[^22]

3.8 코드가 길어질 때의 가독성: 변수/함수로 배치하되, 함수 분리의 성능 주의[^17]

📸 5:26

다음으로 화자는 Flutter 레이아웃 코드가 중첩이 깊어져 시각적 혼란이 생길 수 있다고 말한다.[^17]

3.8.1 왜 길어지는가: build 함수 내부 중첩 구조[^17]

그는 예시로, build 함수 아래에 MaterialApp이 있고, 그 안에 home, 그 안에 body…처럼 계속 중첩되며, 바디 영역에 화면 구성 요소들이 모두 들어가면 코드가 너무 길어진다고 말한다.[^17]

그래서:

  • 일부 구현을 변수나 함수에 배치(분리)하면 좋다고 제안한다.[^17]

3.8.2 함수 분리의 주의점: 리빌드/리렌더에서 퍼포먼스 영향[^18]

다만 “함수 배치는 조금 주의”해야 한다고 강조한다.[^18]

  • Flutter는 UI에서 build가 다시 호출되고, 렌더링(리렌더) 과정이 반복된다.[^18]
  • 이 리렌더 과정에서 “함수 같은 경우는 퍼포먼스가 떨어지는 작업을 하게 된다”는 취지로 말한다.[^18]
  • 그래서 많은 경우, 위젯을 하우스로(바깥으로) 뺄 때 함수를 쓰기보다 StatelessWidget 같은 별도 위젯으로 빼거나, 상속받아 “하나의 클래스”로 만들어 분리하는 경우가 많다고 설명한다.[^18]

마무리로 “이런 거 알아두시고 그때그때 활용”하라고 한다.[^18]

[!IMPORTANT] 코드 분리 원칙(화자 관점) 중첩된 위젯 트리가 길어지면 분리가 필요하지만, 리빌드가 잦은 Flutter 특성상 “함수로 위젯을 뽑는 방식”은 성능 이슈를 유발할 수 있어, 실무에선 별도 StatelessWidget(또는 위젯 클래스) 분리가 흔히 선택된다고 말한다.[^18]

3.9 Flutter 기본 프로젝트 생성 흐름 소개: flutter create → 카운터 앱 생성[^19]

📸 6:58

이후 화자는 “초기에 Flutter를 create 해보면 어떤 식으로 프로젝트가 생기냐”를 보여준다.[^19]

  • 새 Flutter 프로젝트를 만들면(뉴 플러터 프로젝트 설정에서) 프로젝트 이름 등을 정하고 생성하면 기본 프로젝트가 만들어진다.[^19]
  • 기본 생성 결과에는 counter 예제(카운트 값이 올라가는 앱)가 포함되어 있다.[^23]
  • 버튼을 클릭하면 increment를 통해 카운터가 증가하는 형태의 앱이라고 설명한다.[^23]
  • 실행하면 그 카운터 앱이 돌아가지만, 오늘/이번 시리즈에서 만들 것은 그게 아니라 “아주 간단한 하나의 앱”이라고 선을 긋는다.[^23]

3.10 예제용 최소 앱으로 정리: main.dart에서 카운터 코드 제거 → Hello World 앱 실행[^24]

📸 8:16

화자는 예제 구현을 위해 기본 카운터 앱 코드를 정리했다고 말한다.[^24]

  • main.dart에서 카운터 관련 코드들을 빼버린다.[^24]
  • 그리고 “기본 앱” 형태로 간단히 재구성했다고 한다.[^24]

실행 과정도 함께 설명한다:

  • 상단의 **디바이스 매니저(Device Manager)**에서 기존에 만들어둔 에뮬레이터를 실행한다.[^25]
  • 실행 시 “약간 시간(로딩)이 걸릴 수” 있다고 언급한다.[^25]
  • 디바이스 매니저 UI 때문에 화면 영역이 보기 싫게 커졌다/줄었다 할 수 있어, 디바이스 매니저를 접거나 위치를 조정해 작업 공간을 확보하는 팁을 말한다.[^26]
  • 그 상태에서 디버그 실행을 하면, 중앙에 “Hello World” 같은 텍스트가 보이고, 앱바 타이틀이 “Welcome to Flutter”로 보이는 것을 확인한다.[^27]

이로써 다음 회차에서 본격적으로 레이아웃 예제를 구성할 준비(프로젝트 초기 상태 정리)가 끝났다는 흐름이 된다.[^27]

3.11 마무리: 오늘은 레이아웃 분석까지, 앞으로 예제 구현 진행 예고[^28]

📸 9:27

마지막으로 화자는

  • 오늘은 “기본적인 레이아웃에 대한 분석”을 했고,[^28]
  • 이번 주 내내 관련 예제를 구성해보겠다고 예고하며,[^28]
  • 구독/좋아요를 요청하고 종료한다.[^29]

4. 핵심 통찰[^14]

  1. 화면 구현의 난이도는 “위젯을 얼마나 아는가”보다 “화면을 구조로 잘 쪼개는가”에서 크게 갈린다는 전제를 깔고, 큰 덩어리→세부 구조 순으로 분석하는 습관을 반복해서 강조한다.[^10]
  2. 레이아웃 분석은 감이 아니라 체크리스트로 할 수 있다는 점(그리드/겹침/스크롤/정렬·패딩)을 제시하며, 특히 겹침 여부로 Stack 필요를 빠르게 판정하는 사고를 보여준다.[^16]
  3. 이 예제 화면은 복잡한 그리드가 아니라 “세로로 쌓는 Column”이 핵심이며, 섹션 내부에서만 Row/Column 조합이 쓰인다는 식으로 “최상위 구조 단순화”를 유도한다.[^12]
  4. 코드가 길어지는 문제는 Flutter에서 흔하며, 단순 가독성만 보고 함수 분리를 남발하면 리빌드 상황에서 성능 이슈가 될 수 있다는 실무적 주의를 준다.[^18]
    • 실행 시사점:
      • build 안이 길어지면 “섹션 단위(TitleSection, ButtonSection 등)”로 별도 위젯 클래스로 분리하는 습관을 들인다.[^18]
      • 레이아웃을 짜기 전, 먼저 화면을 그리고(혹은 머릿속으로) Column 자식 4개 같은 최상위 골격부터 고정한다.[^12]

참고(콘텐츠 정보)

  • 제목: Flutter 모바일 개발이 이렇게 쉽다고? (EP 01)[^1]
  • 채널: yogingang soft[^1]
  • 길이: 9분 52초[^1]
  • 링크: https://www.youtube.com/watch?v=1UjR-zTIbx4[^1]

[^1]: 영상 메타데이터(사용자 제공): “# Flutter 모바일 개발이 이렇게 쉽다고? ( EP 01 ) / 채널: yogingang soft / 길이: 9분 52초 / https://www.youtube.com/watch?v=1UjR-zTIbx4” [^2]: @[00:01] “안녕하세요”, “반갑습니다” [^3]: @[00:09] “플루타… 대부 페이지에 있는 레이아웃 관련된 예제… 그걸 한번 따라해 볼 거에요” [^4]: @[00:04] “오늘은 … 레이어스(레이아웃) 에 대해서 좀 알아 볼텐데요” [^5]: @[00:14] “이미지가 … 위쪽에 있죠” [^6]: @[00:29] “문자열 … 호수에 대한 설명… 스위스에 어디에 있다” [^7]: @[00:36] “오른쪽… 별표 아이콘이랑 숫자… 눌렀을 때 아마 계속 늘어나는 것 같아요” [^8]: @[00:45] “아이콘 전화… 라우트… 쉐어… 공유하기 위해서” [^9]: @[00:51] “밑에 이제 디스크립션… 텍스트 블럭” [^10]: @[00:58] “우리가 이거를 간단하게 한번 분리를 해 보면 이미지 영역” [^11]: @[01:18] “그렇게 9분할 수 있고요” [^12]: @[02:04] “이미지… 텍스트 블럭으로 끝날 수… 컬럼 하나… 위에서부터 1234” [^13]: @[04:24] “버튼 섹션… 세 개의 자식… 아이콘과 텍스트… 콜… 라우트… 쉐어” [^14]: @[01:35] “기본 코드를 만들기 전에… 레이아웃… 먼저 볼게요” [^15]: @[01:41] “행과 열을 식별… 레이아웃의 그리드… 그리드는 없는 것 같아요” [^16]: @[02:18] “겹치는 요소… 이미지 위쪽에 올라가… 스택… 겹친 요소 없으니까 스택… 사용할 일이 없을 거에요” + @[02:55] “정렬 패딩… 필요한지 확인” [^17]: @[05:26] “코드의 중첩이 깊게… 시각적 혼란… 일부 구현을 변수와 함수에 배치” [^18]: @[06:14] “함수… 퍼포먼스 영향… 빌드를 다시… 리렌더… 함수… 퍼포먼스… 함수로 빼지 않고 다른 스테이트(리스) 위젯으로… 클래스로…” [^19]: @[06:58] “초기에… 플루터… 크레이트… 초기 프로젝트를 만들어 보면” [^20]: @[03:26] “타이틀 섹션… 텍스트… 별표 아이콘… 숫자” [^21]: @[04:03] “첫 번째… 남은 공간을 차지… 익스팬디드로 래핑… 별표와 텍스트… 익스팬디드…” [^22]: @[04:49] “레이아웃을 도표 한 후… 하향식 접근 방식… 가장 쉽다” [^23]: @[07:44] “버튼을 클릭하면… 카운터가 증가… 형태의 앱” [^24]: @[08:16] “메인… 카운터 있던 것들을 빼버리고… 기본 앱” [^25]: @[08:30] “디바이스 매니저… 에뮬레이터 실행… 약간 시간 걸릴” [^26]: @[08:46] “디바이스 매니저 때문에… 보기 싫으니까… 안쪽으로… 다시 누르시면” [^27]: @[09:18] “중앙에 헬로 월드… 타이틀… 웰컴투 플루토” [^28]: @[09:27] “오늘은… 기본적인 레이아웃에 대한 분석… 이번주 내내… 예제 구성” [^29]: @[09:39] “구독 좋아요 부탁드립니다”

← 프로젝트에서 보기