안녕하세요, 플러터 개발자 여러분! 오늘 우리는 플러터 앱 개발에서 반응형 UI를 만들 때 자주 사용되는 MediaQuery의 대안으로 FittedBox와 LayoutBuilder를 왜 고려해야 하는지에 대해 이야기해보려 해요. 혹시 화면 크기에 따라 위젯을 조절하는 게 늘 막막하셨다면, 이 글이 아주 유용한 해결책을 제시해 줄 겁니다. 2025년 현재, 더욱 유연하고 강력한 UI를 위한 최신 권장 사항들을 함께 살펴보시죠!

📱 MediaQuery: 편리하지만 숨겨진 함정?
플러터 개발을 시작하면 가장 먼저 접하게 되는 반응형 UI 도구 중 하나가 바로 MediaQuery일 거예요. 저도 처음에는 MediaQuery.of(context).size.width나 .height를 이용해서 화면 크기에 따라 위젯의 크기나 레이아웃을 조절하는 게 그렇게 편할 수가 없었죠.
예를 들어, 화면 너비에 따라 텍스트 크기를 조절하거나, 특정 위젯의 가로 길이를 화면의 절반으로 설정하는 식이죠. 마치 모든 문제를 해결해 줄 만능 열쇠처럼 느껴졌을 거예요. 그런데 말이죠, 이 편리함 뒤에는 몇 가지 함정이 숨어있다는 사실, 알고 계셨나요?
double screenWidth = MediaQuery.of(context).size.width;
return Container(
width: screenWidth * 0.8,
child: Text('화면 너비의 80%'),
);
🚨 왜 MediaQuery를 조심해야 할까요?
솔직히 말하면, MediaQuery는 '전체 화면'의 정보를 제공해요. 이게 문제의 시작점이 될 수 있습니다.
- 글로벌 컨텍스트 의존성:
MediaQuery는 앱 전체 화면의 크기 정보를 가져오기 때문에, 특정 위젯이 놓여 있는 부모 위젯의 크기나 제약 조건을 반영하지 못해요. 예를 들어, 작은 카드 위젯 안의 내용물을 조절하고 싶은데, 전체 화면 크기에만 반응하게 되니 유연성이 떨어지죠. - 재사용성 저하:
MediaQuery로 크기를 고정해버리면, 해당 위젯은 다른 부모 위젯 안에서 사용될 때 의도치 않은 레이아웃 문제를 일으킬 수 있어요. 마치 특정 신발만 신어야 하는 사람처럼요. - 불필요한 리빌드:
MediaQuery는 화면 크기, 방향 등 환경 변화에 따라 위젯 트리를 리빌드합니다. 물론 이 자체는 필요한 동작이지만, 만약 작은 위젯 하나 때문에 앱 전체가 불필요하게 다시 그려진다면 성능 저하의 원인이 될 수도 있겠죠? - 테스트의 어려움: 전체 화면 크기에 의존하는 로직은 위젯 단위 테스트를 어렵게 만듭니다. 다양한 화면 크기를 가정한 테스트 환경을 구축하기가 까다로워질 수밖에 없어요.
결론적으로, MediaQuery는 전체 앱의 테마나 글로벌 설정(예: 글꼴 크기, 패딩 기본값)을 결정할 때는 유용하지만, 특정 위젯의 복잡한 레이아웃을 조절하는 데는 적합하지 않다는 겁니다.
📦 FittedBox: 내용물을 '꽉' 채우고 싶을 때!
자, 그럼 MediaQuery의 대안으로 첫 번째 주자, FittedBox를 소개합니다! 이 위젯은 이름 그대로 자식 위젯을 부모 위젯의 공간에 '딱 맞게' 채워 넣고 싶을 때 사용해요. 특히 텍스트나 이미지가 너무 커서 공간을 넘어갈 때 유용하답니다.
FittedBox는 자식 위젯의 크기가 부모 위젯의 공간을 초과할 때, 자식을 스케일 다운하거나 업하여 부모의 제약 조건 안에 들어오도록 해요. 이때 fit 속성을 이용해 어떻게 맞출지, alignment 속성으로 어디에 정렬할지를 결정할 수 있죠.
fit:BoxFit.contain(비율 유지, 모두 보이게),BoxFit.fill(비율 무시, 꽉 채움),BoxFit.cover(비율 유지, 공간 꽉 채우고 잘리는 부분 발생) 등alignment:Alignment.center(중앙 정렬),Alignment.topLeft(왼쪽 위 정렬) 등
생각해보니, 영수증 앱에서 상품 이름이 길어질 때, 명함 앱에서 이름이 너무 길어질 때 FittedBox를 사용하면 텍스트가 잘리지 않고 보기 좋게 조절될 수 있어요. 정말 편리하죠!

📐 LayoutBuilder: 부모의 제약 조건에 따라 유연하게!
다음으로 소개할 강력한 친구는 바로 LayoutBuilder입니다. 이 위젯은 부모 위젯이 제공하는 제약 조건(constraints)에 따라 자신의 자식 위젯을 빌드할 수 있게 해줍니다. MediaQuery가 '전체 화면'을 본다면, LayoutBuilder는 '나를 감싸는 부모의 공간'을 본다고 생각하면 쉬울 거예요.
LayoutBuilder는 빌더 함수를 제공하는데, 이 함수는 BoxConstraints 객체를 인자로 받아요. 이 BoxConstraints 객체 안에는 부모가 자식에게 허용하는 최대/최소 너비와 높이 정보가 담겨 있죠. 이 정보를 활용해서 우리는 해당 공간에 딱 맞는 레이아웃을 동적으로 구성할 수 있습니다.
- 가로 모드/세로 모드에 따라 위젯 구성을 완전히 다르게 하고 싶을 때
- 특정 위젯의 가용 공간이 좁아지면 레이아웃을 변경해야 할 때 (예: 두 개의 컬럼이 한 개의 컬럼으로 변경)
- 위젯의 크기가 동적으로 결정되어야 할 때
제가 겪어본 바로는, 복잡한 대시보드 화면을 만들 때 LayoutBuilder가 정말 빛을 발했어요. 화면이 작아지면 그리드 형태의 위젯들이 자동으로 한 줄로 정렬되도록 만들 수 있었거든요. 덕분에 훨씬 유연하고 유지보수하기 쉬운 코드를 만들 수 있었습니다.
📊 비교 분석: 언제 무엇을 사용해야 할까요?
이제 세 가지 방식의 장단점을 비교해서 어떤 상황에서 가장 적합한 도구를 선택할 수 있을지 정리해볼게요. 솔직히 말하면, 각 도구는 고유한 목적을 가지고 있기 때문에 '정답'은 없어요. 중요한 건 '적재적소'에 사용하는 것이죠!
| 특징 | MediaQuery | FittedBox | LayoutBuilder |
|---|---|---|---|
| 스코프 | 전체 화면 | 자식 위젯과 부모 위젯 사이 | 부모의 제약 조건 내 |
| 주요 용도 | 글로벌 테마, 앱 전체 레이아웃 방향 결정 (가로/세로) | 자식 위젯의 스케일 조절 (텍스트, 이미지) | 부모 공간에 따른 동적 레이아웃 구성 |
| 장점 | 간편하게 전체 화면 정보 접근 | 자식 위젯 내용을 훼손 없이 공간에 맞춤 | 가장 유연하고 강력한 반응형 레이아웃 제어 |
| 단점 | 위젯 레벨에서 세밀한 제어 어려움, 재사용성 저하 | 단일 자식 위젯 스케일에만 집중, 복잡한 레이아웃에는 부적합 | 빌더 함수 내부에서 로직 구현 필요, 학습 곡선 |
MediaQuery를 전역적으로 사용하는 것이 반드시 나쁜 것은 아니에요. 하지만 특정 위젯의 레이아웃을 부모의 크기에 따라 조절해야 할 때는 FittedBox나 LayoutBuilder가 훨씬 더 명확하고 효율적인 해결책이 될 수 있다는 점을 기억해주세요.✨ 현명한 선택으로 더 나은 UI를!
오늘 우리는 플러터 반응형 UI의 세 가지 핵심 도구인 MediaQuery, FittedBox, LayoutBuilder에 대해 깊이 있게 알아봤습니다. MediaQuery가 제공하는 전역적인 정보는 유용하지만, 위젯 레벨의 정교한 반응형 디자인에는 FittedBox와 LayoutBuilder가 훨씬 강력하고 유연한 대안이 될 수 있다는 것을 깨달으셨을 거예요.
개인적으로 저는 LayoutBuilder를 만난 후로 복잡한 UI 구성에 대한 두려움이 많이 줄었어요. 마치 레고 블록을 조립하듯이, 부모가 제공하는 공간이라는 제약 조건 안에서 마음껏 창의력을 발휘할 수 있게 된 거죠. 여러분도 2025년, 더 성숙한 플러터 개발자로 나아가기 위해 이 두 위젯의 활용법을 꼭 익혀두시길 바랍니다!
결국 핵심은 '최고의 도구'는 없으며, '가장 적합한 도구'를 선택하는 지혜에 있다는 점을 강조하고 싶어요. 부디 이 글이 여러분의 플러터 여정에 작은 빛이 되기를 바랍니다!
1. MediaQuery는 전역 화면 정보 제공: 전체 앱의 테마나 글로벌 설정에 적합하며, 위젯 단위의 세밀한 반응형 조절에는 부적합할 수 있습니다.
2. FittedBox는 자식 위젯 스케일링: 단일 자식 위젯이 부모 공간을 벗어나지 않도록 크기를 조절할 때 사용하며, 텍스트나 이미지에 특히 유용합니다.
3. LayoutBuilder는 부모 제약 조건 기반: 부모 위젯의 가용 공간 정보를 활용하여 동적으로 레이아웃을 구성할 수 있어, 복잡한 반응형 UI에 가장 강력한 도구입니다.
4. 적재적소에 맞는 도구 선택: 각 위젯의 특성을 이해하고 상황에 맞춰 사용하는 것이 플러터 반응형 UI 개발의 핵심입니다.
❓ 자주 묻는 질문 (FAQ)
Q1: MediaQuery를 아예 사용하지 말아야 하나요?
A1: 아니요, 그렇지 않습니다. MediaQuery는 앱의 전체적인 테마(예: 글꼴 크기, 패딩 기본값)나 전체 화면의 특성(예: 가로/세로 모드 전환, 노치 영역)을 알아낼 때 여전히 유용합니다. 하지만 특정 위젯의 크기나 레이아웃을 부모 위젯의 가용 공간에 따라 동적으로 조절해야 할 때는 FittedBox나 LayoutBuilder가 더 적합한 해결책입니다.
Q2: FittedBox와 LayoutBuilder 중 무엇을 먼저 배워야 할까요?
A2: 두 위젯 모두 중요하지만, 사용 시나리오가 다릅니다. 간단하게 자식 위젯의 크기를 부모 공간에 맞추어 스케일링해야 한다면 FittedBox가 직관적이고 사용하기 쉽습니다. 반면, 부모의 제약 조건에 따라 위젯의 구조 자체를 변경해야 하는 복잡한 반응형 UI를 만들 때는 LayoutBuilder의 강력한 기능을 익히는 것이 좋습니다.
Q3: LayoutBuilder를 사용하면 MediaQuery보다 성능이 더 좋아지나요?
A3: LayoutBuilder는 MediaQuery보다 더 지역적인(local) 컨텍스트에서 작동하므로, 부모 위젯의 크기 변경에만 반응하여 불필요한 전체 화면 리빌드를 줄일 수 있습니다. 이는 특정 상황에서 성능 향상에 기여할 수 있습니다. 하지만 어떤 도구를 사용하느냐보다는, 적절하게 사용하여 위젯 트리의 불필요한 리빌드를 최소화하는 것이 더 중요합니다.
'Flutter' 카테고리의 다른 글
| IOS App Tracking Transparency (a.k.a ATT) (0) | 2025.06.07 |
|---|---|
| App Store에 광고 넣으려면 반드시 알아야 할 ATT 설정법 (0) | 2025.05.28 |
| flutter - App Store Guideline 2.1 - AppTrackingTransparency 대응 가이드 (0) | 2025.05.17 |
| version_update.sh스크립트 소개 (0) | 2025.05.06 |
| flutter 필수 작업 - java 17 버전 적용 (맥) (0) | 2025.05.04 |