지난 글에서 테마를 다뤘으니, 위젯과 레이아웃 카테고리의 마지막 주제는 화면 크기다. 폰마다 가로 폭이 다르고 태블릿도 있으니, 내 폰에서 예쁘게 나온 화면이 다른 기기에서 깨지는 일이 생긴다. 카드 두 장을 가로로 나란히 놓는다고 해보자. 내 폰에서 보기 좋게 폭을 300으로 맞췄다.

Row(
  children: [
    Container(width: 300, height: 100, color: Colors.blue),
    Container(width: 300, height: 100, color: Colors.green),
  ],
)

가로 폭이 360인 작은 폰에서 실행하면 레이아웃 위젯 글에서 본 에러가 그대로 나온다.

A RenderFlex overflowed by 240 pixels on the right.

반대로 태블릿에서 보면 화면 폭은 1000이 넘는데 카드 두 장이 왼쪽에 작게 몰려 있다. 폭을 숫자로 박아두면 어떤 화면에서든 같은 크기라서, 작은 화면에서는 넘치고 큰 화면에서는 휑해진다.

원인: 화면 크기를 모르는 채로 크기를 정했다

Flutter 레이아웃은 "제약은 아래로, 크기는 위로" 흐른다고 했다. 위에서 내려오는 제약(쓸 수 있는 폭)은 기기마다 다른데, 내가 300이라는 고정값으로 대답해버리면 그 제약을 무시하는 셈이다. 해결 방법은 둘로 나뉜다. 고정 크기 대신 남는 공간에 맞추거나, 화면 크기를 읽어서 레이아웃 자체를 바꾸거나. 앞의 것은 이미 Expanded로 해봤고, 이번 글은 뒤의 것이다.

해결 1: MediaQuery로 화면 크기 읽기

class CardsPage extends StatelessWidget {
  const CardsPage({super.key});

  @override
  Widget build(BuildContext context) {
    final width = MediaQuery.sizeOf(context).width; // 화면 가로 폭
    final isWide = width >= 600;

    final cards = [
      const InfoCard(color: Colors.blue),
      const InfoCard(color: Colors.green),
    ];

    if (isWide) {
      // 넓으면 가로로 나란히, 남는 폭을 반반씩
      return Row(
        children: cards.map((c) => Expanded(child: c)).toList(),
      );
    }
    // 좁으면 세로로 쌓기
    return Column(children: cards);
  }
}

class InfoCard extends StatelessWidget {
  final Color color;
  const InfoCard({super.key, required this.color});

  @override
  Widget build(BuildContext context) {
    return Container(height: 100, margin: const EdgeInsets.all(8), color: color);
  }
}

MediaQuery.sizeOf(context)는 지금 화면의 크기를 돌려준다. 폰은 폭이 600보다 작으니 Column으로 세로로 쌓이고, 태블릿은 Row로 나란히 놓인다. 넘치는 에러도 사라지고, 고정 폭 300 대신 Expanded가 남는 공간을 나눠 가진다.

cards.map(...).toList()는 컬렉션 글에서 본 그 패턴이다. map은 Iterable을 돌려주기 때문에 children에 넣으려면 .toList()가 필요하다.

MediaQuery에서 읽을 수 있는 건 크기만이 아니다.

final size = MediaQuery.sizeOf(context);               // 화면 크기
final orientation = MediaQuery.orientationOf(context); // 세로/가로 방향
final padding = MediaQuery.paddingOf(context);         // 노치, 상태바 등 가려지는 영역
final bottom = MediaQuery.viewInsetsOf(context).bottom; // 키보드 높이

예전 코드에는 MediaQuery.of(context).size가 많이 보이는데, 같은 값을 돌려준다. 다만 of는 키보드가 올라오는 것처럼 MediaQuery의 어떤 값이 바뀌어도 위젯을 다시 그리고, sizeOf는 크기가 바뀔 때만 다시 그린다. 새 코드에서는 sizeOf, orientationOf 같은 전용 메서드가 낫다.

MediaQuery의 한계: "화면" 크기이지 "내가 쓸 수 있는 공간"이 아니다

화면 왼쪽에 폭 300짜리 사이드 패널을 두고, 그 안에서 MediaQuery로 폭을 읽어보자.

Row(
  children: [
    SizedBox(
      width: 300,
      child: SidePanel(), // 이 안에서 MediaQuery.sizeOf(context).width를 읽으면?
    ),
    const Expanded(child: MainContent()),
  ],
)

SidePanel 안에서 MediaQuery로 폭을 읽으면 300이 아니라 기기 전체 화면 폭(예: 1000)이 나온다. MediaQuery는 위젯이 어디에 놓였는지와 상관없이 항상 화면 전체를 기준으로 하기 때문이다. 그래서 패널 안에서 "폭이 600 이상이면 가로로 배치"라고 판단하면, 실제로는 300밖에 안 되는 공간에 가로 배치를 해서 또 넘친다.

해결 2: LayoutBuilder로 부모가 준 공간 읽기

LayoutBuilder(
  builder: (context, constraints) {
    if (constraints.maxWidth >= 600) {
      return Row(children: [...]); // 넓은 배치
    }
    return Column(children: [...]); // 좁은 배치
  },
)

LayoutBuilder의 constraints는 부모가 이 위젯에게 내려준 제약이다. "제약은 아래로 내려간다"가 눈에 보이는 값으로 나오는 것이다. 사이드 패널 안에서 쓰면 constraints.maxWidth는 300이고, 화면이 아무리 커도 패널 안의 판단은 패널의 실제 폭을 기준으로 한다. 같은 위젯을 폰 전체 화면에도, 태블릿의 작은 패널에도 재사용할 수 있다.

builder는 리스트 글의 itemBuilder처럼 "이렇게 그려라"를 알려주는 콜백이다. 제약은 레이아웃 단계에 가서야 알 수 있어서, 위젯을 미리 만들어 두지 않고 제약이 정해진 뒤에 호출되는 함수로 넘기는 구조다.

MediaQuery와 LayoutBuilder, 언제 뭘 쓰나

• MediaQuery: 기준은 기기 화면 전체다. 화면 크기, 방향, 노치, 키보드 높이를 알 수 있고, 앱 전체 레이아웃 분기나 안전 영역, 키보드 처리에 알맞다.
• LayoutBuilder: 기준은 부모가 내게 준 공간이다. constraints의 최소·최대 폭과 높이를 알 수 있고, 재사용 위젯 안에서의 분기에 알맞다.

화면 전체 정보(방향, 키보드, 노치)는 MediaQuery, "나한테 주어진 공간"에 따른 분기는 LayoutBuilder라고 기억하면 된다.

분기 기준: 폭 구간으로 나누기

숫자를 아무 값이나 쓰기보다 Material 디자인이 권하는 구간을 따라가면 편하다.

• compact: 폭 600 미만. 폰(세로)
• medium: 폭 600 이상 840 미만. 작은 태블릿, 폰(가로)
• expanded: 폭 840 이상. 큰 태블릿, 데스크톱

LayoutBuilder(
  builder: (context, constraints) {
    final w = constraints.maxWidth;
    if (w >= 840) return const ThreeColumnLayout();
    if (w >= 600) return const TwoColumnLayout();
    return const OneColumnLayout();
  },
)

앱 전체에서 같은 기준을 쓰도록 600, 840을 상수로 한 곳에 빼두는 편이 낫다.

분기 없이 해결되는 경우도 많다

화면 크기별로 레이아웃을 따로 만드는 건 품이 많이 든다. 다음 도구로 해결되면 분기를 쓰지 않는다.

• Expanded / Flexible: 남는 공간을 비율로 나눈다 (레이아웃 위젯 글)
• GridView의 maxCrossAxisExtent: 칸 너비 기준으로 칸 수가 알아서 바뀐다 (스크롤과 리스트 글)
• SafeArea: 노치와 상태바에 가려지는 영역을 피한다
• ConstrainedBox: 넓은 화면에서 내용이 끝없이 퍼지지 않게 최대 폭을 정한다

Scaffold(
  body: SafeArea( // 노치, 상태바, 하단 제스처 바를 피해서 그림
    child: content,
  ),
)

Center(
  child: ConstrainedBox(
    constraints: const BoxConstraints(maxWidth: 600), // 아무리 넓어도 600까지만
    child: const SignupForm(),
  ),
)

태블릿에서 입력 폼이 화면 전체로 늘어나면 보기 어색한데, 이렇게 최대 폭만 정해줘도 가운데에 적당한 크기로 놓인다. 입문 단계에서는 이 정도만으로도 대부분의 화면이 무난하게 해결된다.

Compose, SwiftUI와 비교하면

// Compose
BoxWithConstraints {
    if (maxWidth >= 600.dp) {
        Row { ... }
    } else {
        Column { ... }
    }
}

// SwiftUI
GeometryReader { geo in
    if geo.size.width >= 600 {
        HStack { ... }
    } else {
        VStack { ... }
    }
}

항목별로 나란히 놓으면 이렇다.

• 부모가 준 공간으로 분기: Flutter LayoutBuilder / Compose BoxWithConstraints / SwiftUI GeometryReader
• 화면 전체 정보: Flutter MediaQuery / Compose LocalConfiguration / SwiftUI UIScreen 등
• 폭 구간 개념: Flutter는 직접 600, 840으로 분기 / Compose WindowSizeClass / SwiftUI horizontalSizeClass
• 안전 영역: Flutter SafeArea / Compose WindowInsets / SwiftUI safeAreaInset (기본 적용)

Compose의 BoxWithConstraints와 Flutter의 LayoutBuilder가 가장 비슷하다. 둘 다 "부모가 준 공간"을 알려주는 도구다. Compose는 WindowSizeClass, SwiftUI는 horizontalSizeClass로 구간을 시스템이 나눠주지만, Flutter는 600, 840을 내가 직접 비교한다는 점이 다르다.

정리

• 위젯 크기를 숫자로 박아두면 작은 화면에서는 넘치고 큰 화면에서는 휑해지므로, 남는 공간에 맞추거나 화면 크기에 따라 레이아웃을 바꾼다
• MediaQuery.sizeOf(context)는 기기 화면 전체 크기를 돌려주고, 방향, 노치, 키보드 높이도 읽을 수 있다
• MediaQuery는 위젯이 어디에 놓였는지와 상관없이 화면 전체 기준이라서, 패널처럼 일부 공간 안에서는 LayoutBuilder의 constraints.maxWidth로 판단해야 한다
• 분기 기준은 600, 840 같은 폭 구간으로 정하고, 분기 전에 Expanded, maxCrossAxisExtent, SafeArea, ConstrainedBox로 해결되는지 먼저 본다

다음 글부터는 위젯 카테고리를 넘어 상태 관리를 다룬다. setState로는 감당하기 어려워지는 지점과, 그 해결책인 InheritedWidget과 Provider부터 보겠다.