Flutter 튜토리얼 7편: 제약 조건(Constraints) 이해하기

Why#

NOTE

Flutter 레이아웃이 다른 프레임워크와 다르게 작동하는 이유는 성능 최적화 때문입니다.
제약 기반 레이아웃은 O(n) 시간 복잡도로 매우 효율적입니다.

What#

NOTE

Flutter 레이아웃의 핵심 규칙은 다음과 같습니다.

1. Constraints go down (제약은 아래로)
2. Sizes go up (크기는 위로)
3. Parent sets position (부모가 위치 결정)

How#

TIP

레이아웃 과정을 그림으로 보기

flowchart TB subgraph "1단계: 제약 전달 ⬇️" A[부모] -->|"최대 300×100"| B[위젯] B -->|"최대 290×90"| C[자식] end subgraph "2단계: 크기 보고 ⬆️" D[자식] -->|"100×50 원함"| E[위젯] E -->|"110×60 결정"| F[부모] end subgraph "3단계: 위치 결정" G[부모가 위젯을<br/>x:10, y:20에 배치] end

3단계 정리

단계	방향	내용
1. Constraints	부모 → 자식	”너는 최대 이 크기까지만 가능해”
2. Size	자식 → 부모	”저는 이 크기로 할게요”
3. Position	부모 결정	”넌 여기에 배치할게”

중요한 제한사항

규칙	설명
크기 제한	위젯은 제약 범위 내에서만 크기 결정 가능
위치 무지	위젯은 자신의 화면 위치를 알 수 없음
전체 의존	정확한 크기/위치는 전체 트리에 의존

Watch out#

WARNING

위젯에 width: 100을 설정해도 부모의 제약이 우선합니다.
부모가 “최소 200픽셀”이라고 하면 100픽셀은 무시됩니다.

1
// 부모가 tight constraints를 전달하면
2
// Container의 크기 설정이 무시됨
3
SizedBox.expand(
4
  child: Container(
5
    width: 100,    // 무시됨
6
    height: 100,   // 무시됨
7
    color: Colors.red,
8
  ),
9
)

결론: 위젯 크기는 자신의 설정과 부모의 제약 중 더 엄격한 것에 따릅니다.

Why#

NOTE

같은 위젯이 어떤 부모 아래에서는 원하는 크기로 렌더링되고, 다른 부모 아래에서는 그렇지 않습니다.
이 차이는 부모가 전달하는 제약의 종류 때문입니다.

What#

NOTE

Tight Constraints는 정확한 크기를 강제하고, Loose Constraints는 최대 크기만 제한합니다.

How#

TIP

Tight Constraints (긴밀한 제약)

최소값과 최대값이 같은 제약입니다.
자식은 정확히 그 크기여야 합니다.

1
// Tight Constraints 예시
2
BoxConstraints.tight(Size(200, 100))
3
// minWidth: 200, maxWidth: 200
4
// minHeight: 100, maxHeight: 100

Loose Constraints (느슨한 제약)

최소값은 0이고 최대값만 있는 제약입니다.
자식은 0부터 최대값 사이에서 원하는 크기를 선택합니다.

1
// Loose Constraints 예시
2
BoxConstraints.loose(Size(200, 100))
3
// minWidth: 0, maxWidth: 200
4
// minHeight: 0, maxHeight: 100

차이점 비교

구분	Tight	Loose
최소/최대	같음	다름 (최소=0)
자식 자유도	없음	있음
사용 위젯	Scaffold body, SizedBox.expand	Center, Align

실제 예제

1
// 예제 1: Container가 화면 전체를 차지
2
// Scaffold의 body는 tight constraints 전달
3
Scaffold(
4
  body: Container(
5
    width: 100,     // 무시됨
6
    height: 100,    // 무시됨
7
    color: Colors.red,
8
  ),
9
)
10

11
// 예제 2: Container가 원하는 크기로 렌더링
12
// Center는 loose constraints 전달
13
Scaffold(
14
  body: Center(
15
    child: Container(
16
      width: 100,   // 적용됨!
17
      height: 100,  // 적용됨!
18
      color: Colors.red,
19
    ),
20
  ),
21
)

왜 Center가 해결책인가?

graph TD A[Scaffold body] -->|Tight: 화면 전체| B[Container] B --> C[화면 전체 크기] D[Scaffold body] -->|Tight: 화면 전체| E[Center] E -->|Loose: 0~화면 전체| F[Container] F --> G[100x100 크기]

Watch out#

WARNING

Center, Align 같은 위젯은 자식에게 loose constraints를 전달합니다.
하지만 자식이 크기를 지정하지 않으면 0 크기가 될 수 있습니다.

1
Center(
2
  child: Container(
3
    // width, height 없음
4
    color: Colors.red,
5
  ),
6
)
7
// Container 크기가 0x0!

결론: 위젯이 원하는 크기로 렌더링되지 않으면 Center나 Align으로 감싸서 loose constraints를 전달합니다.

Why#

NOTE

때로는 부모의 제약을 수정하거나 무시해야 합니다.
ConstrainedBox는 추가 제약을 적용하고, UnconstrainedBox는 제약을 제거합니다.

What#

NOTE

ConstrainedBox⁴는 자식에게 추가 제약을 적용합니다.
UnconstrainedBox⁵는 부모의 제약을 무시하고 자식이 원하는 크기를 허용합니다.

How#

TIP

ConstrainedBox: 추가 제약 적용

1
Center(
2
  child: ConstrainedBox(
3
    constraints: BoxConstraints(
4
      minWidth: 70,
5
      minHeight: 70,
6
      maxWidth: 150,
7
      maxHeight: 150,
8
    ),
9
    child: Container(
10
      width: 10,    // 최소값 70이 적용됨
11
      height: 10,   // 최소값 70이 적용됨
12
      color: Colors.red,
13
    ),
14
  ),
15
)
16
// 결과: 70x70 빨간 Container

ConstrainedBox의 규칙

ConstrainedBox는 부모 제약과 자신의 제약 중 더 엄격한 것을 적용합니다.

1
// 부모 제약: maxWidth 100
2
// ConstrainedBox: maxWidth 150
3
// 결과: maxWidth 100 (더 엄격한 것)
4

5
// 부모 제약: minWidth 0
6
// ConstrainedBox: minWidth 70
7
// 결과: minWidth 70 (더 엄격한 것)

UnconstrainedBox: 제약 무시

1
ConstrainedBox(
2
  constraints: BoxConstraints(
3
    maxWidth: 200,
4
    maxHeight: 200,
5
  ),
6
  child: UnconstrainedBox(
7
    child: Container(
8
      width: 300,   // 200 제약 무시!
9
      height: 50,
10
      color: Colors.red,
11
    ),
12
  ),
13
)
14
// 결과: 300x50 Container (overflow 경고 발생)

OverflowBox: 오버플로우 허용

1
SizedBox(
2
  width: 100,
3
  height: 100,
4
  child: OverflowBox(
5
    maxWidth: 300,
6
    child: Container(
7
      width: 300,
8
      height: 50,
9
      color: Colors.red,
10
    ),
11
  ),
12
)
13
// 결과: 300x50 Container가 부모 밖으로 넘침

Watch out#

WARNING

UnconstrainedBox로 제약을 무시하면 overflow 경고가 발생할 수 있습니다.
화면 밖으로 위젯이 넘치면 노란색/검은색 줄무늬로 표시됩니다.

1
// overflow 경고 예시
2
Row(
3
  children: [
4
    UnconstrainedBox(
5
      child: Container(width: 1000),  // 화면보다 큼!
6
    ),
7
  ],
8
)

결론: ConstrainedBox로 추가 제약을, UnconstrainedBox로 제약 해제를 조절합니다.

Why#

NOTE

Flutter의 효율적인 렌더링을 이해하려면 세 가지 트리 구조를 알아야 합니다.
Widget은 설계도, Element는 인스턴스, RenderObject는 실제 렌더링을 담당합니다.

What#

NOTE

Flutter는 Widget Tree⁶, Element Tree⁷, RenderObject Tree⁸ 세 가지 트리를 유지합니다.

How#

TIP

세 가지 트리의 역할

트리	역할	특징
Widget	UI 설계도	불변, 매 프레임 재생성 가능
Element	Widget 인스턴스	프레임 간 유지, 캐시 역할
RenderObject	실제 렌더링	레이아웃과 페인팅 수행

관계도

graph TD subgraph Widget Tree W1[Container] --> W2[Row] W2 --> W3[Text] W2 --> W4[Image] end subgraph Element Tree E1[ContainerElement] --> E2[RowElement] E2 --> E3[TextElement] E2 --> E4[ImageElement] end subgraph RenderObject Tree R1[RenderDecoratedBox] --> R2[RenderFlex] R2 --> R3[RenderParagraph] R2 --> R4[RenderImage] end W1 -.-> E1 E1 -.-> R1

성능 최적화: Element 캐싱

Widget이 변경되어도 Element는 재사용됩니다.

1
// 이전 프레임
2
Text('Hello')
3

4
// 현재 프레임
5
Text('World')
6

7
// 동작:
8
// 1. 새 Text Widget 생성
9
// 2. 기존 TextElement 재사용
10
// 3. RenderParagraph만 업데이트

RenderBox와 제약

RenderObject 중 대부분은 RenderBox입니다. RenderBox는 BoxConstraints를 받아 레이아웃을 계산합니다.

1
// RenderBox가 받는 제약
2
BoxConstraints(
3
  minWidth: 0,
4
  maxWidth: 300,
5
  minHeight: 0,
6
  maxHeight: 200,
7
)
8

9
// RenderBox가 결정하는 크기
10
Size(200, 150)  // 제약 범위 내

Watch out#

WARNING

Widget은 불변이므로 속성을 변경하면 새 Widget이 생성됩니다.
하지만 Element와 RenderObject는 가능하면 재사용되어 성능을 유지합니다.

1
// 비효율적: 매번 새 Widget 타입
2
condition ? Text('A') : Container(child: Text('B'))
3

4
// 효율적: 같은 Widget 타입, 속성만 변경
5
Text(condition ? 'A' : 'B')

결론: Flutter는 Widget-Element-RenderObject 구조로 효율적인 렌더링을 달성합니다.

Why#

NOTE

Constraints를 이해해도 실제 개발에서는 다양한 문제를 만납니다.
흔한 문제들의 원인과 해결책을 알아둡니다.

What#

NOTE

Unbounded constraints, overflow, 크기 무시 등의 문제는 대부분 제약 조건 관련입니다.

How#

TIP

문제 1: Container 크기가 무시됨

1
// 문제
2
Scaffold(
3
  body: Container(
4
    width: 100,
5
    height: 100,
6
    color: Colors.red,
7
  ),
8
)
9
// Container가 화면 전체 차지
10

11
// 해결: Center로 감싸기
12
Scaffold(
13
  body: Center(
14
    child: Container(
15
      width: 100,
16
      height: 100,
17
      color: Colors.red,
18
    ),
19
  ),
20
)

문제 2: Column 안의 Container가 안 보임

1
// 문제
2
Column(
3
  children: [
4
    Container(color: Colors.blue),  // 높이 0!
5
  ],
6
)
7

8
// 해결 1: 높이 지정
9
Column(
10
  children: [
11
    Container(
12
      height: 100,
13
      color: Colors.blue,
14
    ),
15
  ],
16
)
17

18
// 해결 2: Expanded 사용
19
Column(
20
  children: [
21
    Expanded(
22
      child: Container(color: Colors.blue),
23
    ),
24
  ],
25
)

문제 3: Unbounded height 오류

1
// 문제: Column 안에 ListView
2
Column(
3
  children: [
4
    ListView(...),  // 오류!
5
  ],
6
)
7

8
// 해결 1: Expanded로 감싸기
9
Column(
10
  children: [
11
    Expanded(
12
      child: ListView(...),
13
    ),
14
  ],
15
)
16

17
// 해결 2: SizedBox로 높이 제한
18
Column(
19
  children: [
20
    SizedBox(
21
      height: 200,
22
      child: ListView(...),
23
    ),
24
  ],
25
)

문제 4: Row 안의 Text가 넘침

1
// 문제
2
Row(
3
  children: [
4
    Text('아주 긴 텍스트가 화면을 넘어갑니다...'),  // overflow!
5
  ],
6
)
7

8
// 해결: Expanded나 Flexible 사용
9
Row(
10
  children: [
11
    Expanded(
12
      child: Text('아주 긴 텍스트가 화면을 넘어갑니다...'),
13
    ),
14
  ],
15
)

문제 해결 체크리스트

증상	원인	해결책
위젯이 화면 전체	Tight constraints	Center/Align 사용
위젯이 안 보임	크기 0	높이/너비 지정 또는 Expanded
Unbounded 오류	무한 제약	Expanded 또는 SizedBox
Overflow 경고	부모보다 큼	Expanded, Flexible, 스크롤

Watch out#

WARNING

flutter analyze나 DevTools의 Widget Inspector를 사용하면 제약 조건을 확인할 수 있습니다.
문제가 발생하면 해당 위젯의 constraints를 직접 확인하세요.

1
LayoutBuilder(
2
  builder: (context, constraints) {
3
    print('Constraints: $constraints');
4
    return Container(...);
5
  },
6
)

결론: 레이아웃 문제는 대부분 제약 조건 관련이며, Center, Expanded, SizedBox로 해결합니다.