Flutter 튜토리얼 74편: 성능 프로파일링 도구 - DevTools로 앱 성능 분석하기

Why#

NOTE

DevTools¹는 Flutter 앱의 성능을 분석하는 공식 도구입니다. 시각적인 타임라인과 그래프로 성능 문제를 쉽게 파악할 수 있습니다.

What#

NOTE

DevTools의 성능 분석 도구는 세 가지 뷰로 구성됩니다.

flowchart TD subgraph DevTools["DevTools 성능 분석"] P[Performance View] C[CPU Profiler] M[Memory View] end subgraph Analysis["분석 대상"] P --> F[프레임 렌더링] P --> T[타임라인 이벤트] C --> E[코드 실행 시간] C --> CA[호출 스택] M --> H[힙 메모리] M --> L[메모리 누수] end

뷰	분석 대상	사용 시점
Performance	프레임 렌더링, UI/Raster 스레드	화면이 버벅거릴 때
CPU Profiler	메서드 실행 시간, 호출 빈도	앱이 느릴 때
Memory	힙 크기, 객체 할당	메모리 사용량이 높을 때

How#

TIP

DevTools를 실행하는 방법입니다.

1
# 1. 프로파일 모드로 앱 실행 (성능 분석에 최적)
2
flutter run --profile
3

4
# 2. DevTools 열기 (터미널에서)
5
flutter pub global activate devtools
6
flutter pub global run devtools
7

8
# 또는 VS Code에서
9
# Dart: Open DevTools 명령 실행

1
// 프로파일 모드에서만 실행되는 코드
2
import 'package:flutter/foundation.dart';
3

4
if (kProfileMode) {
5
  // 프로파일링용 코드
6
  debugPrint('Profile mode: measuring performance...');
7
}

Watch out#

WARNING

성능 분석은 반드시 profile 모드에서 해야 합니다. debug 모드는 최적화가 없어 실제 성능과 크게 다릅니다.

1
# 잘못된 예: debug 모드 (기본값)
2
flutter run  # 성능 분석에 부적합
3

4
# 올바른 예: profile 모드
5
flutter run --profile  # 성능 분석에 적합
6

7
# release 모드는 DevTools 연결 불가
8
flutter run --release  # 프로파일링 불가

결론: DevTools의 Performance, CPU Profiler, Memory 뷰를 활용하여 다양한 성능 문제를 분석할 수 있다.

Why#

NOTE

Flutter는 60fps(또는 고주사율 디스플레이에서 120fps)로 화면을 렌더링합니다. 한 프레임을 16ms 내에 완료하지 못하면 화면이 버벅거립니다(jank²).

What#

NOTE

Performance 뷰는 프레임 렌더링 과정을 타임라인으로 보여줍니다.

flowchart LR subgraph Frame["한 프레임 (16ms)"] UI[UI Thread] R[Raster Thread] end subgraph UIWork["UI Thread 작업"] B[build] L[layout] P[paint] end subgraph RasterWork["Raster Thread 작업"] S[rasterize] C[composite] end UI --> UIWork R --> RasterWork UIWork -->|"완료"| RasterWork

스레드	역할	과부하 시 증상
UI Thread	Widget 빌드, 레이아웃 계산	사용자 입력 지연
Raster Thread	픽셀 렌더링, GPU 작업	화면 버벅임

How#

TIP

Performance 뷰에서 프레임을 분석하는 방법입니다.

1
// DevTools Performance 뷰 사용 순서
2
// 1. DevTools > Performance 탭 선택
3
// 2. Record 버튼 클릭
4
// 3. 앱에서 버벅거리는 동작 수행
5
// 4. Stop 버튼 클릭
6
// 5. 타임라인에서 빨간색 프레임 확인

프레임 차트 해석 방법입니다.

1
Frame Chart 색상:
2
  초록색: 정상 프레임 (16ms 이하)
3
  노란색: 약간 느림 (16-33ms)
4
  빨간색: jank 발생 (33ms 이상)
5

6
문제 프레임 분석: 1. 빨간색 프레임 선택
7
  2. Frame Analysis 탭에서 상세 정보 확인
8
  3. UI vs Raster 시간 비교
9
  4. 병목 스레드 파악

프레임 분석 예시입니다.

1
// 느린 빌드를 유발하는 코드 예시
2
class SlowWidget extends StatelessWidget {
3
  @override
4
  Widget build(BuildContext context) {
5
    // 문제: build 메서드에서 무거운 연산
6
    final processedData = expensiveComputation(); // build에서 호출하면 안 됨
7

8
    return ListView.builder(
9
      itemCount: 1000,
10
      itemBuilder: (context, index) {
11
        return ListTile(
12
          title: Text(processedData[index]),
13
        );
14
      },
15
    );
16
  }
17
}
18

19
// 개선된 코드
20
class OptimizedWidget extends StatefulWidget {
21
  @override
22
  State<OptimizedWidget> createState() => _OptimizedWidgetState();
23
}
24

25
class _OptimizedWidgetState extends State<OptimizedWidget> {
26
  late List<String> processedData;
27

28
  @override
29
  void initState() {
30
    super.initState();
31
    // initState에서 한 번만 계산
32
    processedData = expensiveComputation();
33
  }
34

35
  @override
36
  Widget build(BuildContext context) {
37
    return ListView.builder(
38
      itemCount: processedData.length,
39
      itemBuilder: (context, index) {
40
        return ListTile(
41
          title: Text(processedData[index]),
42
        );
43
      },
44
    );
45
  }
46
}

Watch out#

WARNING

Shader compilation jank³는 첫 실행 시 발생하는 특수한 버벅임입니다. 새로운 셰이더가 컴파일될 때 일시적으로 프레임이 지연됩니다.

1
// Shader 워밍업으로 해결 가능
2
// 앱 시작 시 필요한 셰이더를 미리 컴파일
3

4
// flutter build 시 셰이더 번들 생성
5
// flutter build apk --bundle-sksl-path flutter_01.sksl.json

결론: Performance 뷰의 프레임 차트로 jank가 발생하는 시점과 원인을 파악할 수 있다.

Why#

NOTE

프레임 차트만으로는 구체적으로 어떤 작업이 느린지 알기 어렵습니다. Timeline Events⁴ 탭에서 각 프레임의 세부 작업을 분석할 수 있습니다.

What#

NOTE

Timeline Events는 프레임 내의 모든 작업을 계층적으로 보여줍니다.

flowchart TD subgraph Frame["Frame #42"] B[Build] L[Layout] P[Paint] end subgraph BuildDetail["Build 상세"] B1[MyApp.build] B2[HomePage.build] B3[ListView.build] end B --> BuildDetail B1 --> B2 --> B3

이벤트 유형	설명	최적화 대상
Build	Widget 트리 구성	불필요한 rebuild
Layout	크기/위치 계산	복잡한 레이아웃
Paint	그리기 명령 생성	과도한 클리핑
Raster	GPU 렌더링	큰 이미지, 복잡한 효과

How#

TIP

Timeline Events 분석 방법입니다.

1
Timeline Events 탭 사용법: 1. Performance 뷰에서 프레임 선택
2
  2. Timeline Events 탭 클릭
3
  3. 계층 구조에서 가장 긴 이벤트 확인
4
  4. 이벤트 클릭하여 소요 시간 확인
5
  5. 소스 코드 위치 파악

Flame Chart로 시각화된 타임라인입니다.

1
// Flame Chart 해석
2
// 가로축: 시간
3
// 세로축: 호출 스택 깊이
4
// 막대 너비: 해당 작업의 소요 시간
5

6
// 넓은 막대 = 오래 걸린 작업 = 최적화 대상
7

8
// 예: Build 이벤트가 10ms 이상이면
9
// - 어떤 Widget.build가 오래 걸리는지 확인
10
// - 해당 Widget 최적화 필요

타임라인 분석을 통한 최적화 예시입니다.

1
// 문제: Paint가 오래 걸리는 경우
2
class ProblematicWidget extends StatelessWidget {
3
  @override
4
  Widget build(BuildContext context) {
5
    return ClipPath(
6
      // ClipPath는 성능 비용이 높음
7
      clipper: ComplexClipper(),
8
      child: Container(
9
        decoration: BoxDecoration(
10
          // 복잡한 그라데이션도 비용 높음
11
          gradient: RadialGradient(
12
            colors: [Colors.red, Colors.blue, Colors.green],
13
          ),
14
          boxShadow: [
15
            // 그림자도 Paint 비용 증가
16
            BoxShadow(blurRadius: 20, spreadRadius: 5),
17
          ],
18
        ),
19
        child: child,
20
      ),
21
    );
22
  }
23
}
24

25
// 개선: 복잡한 효과 최소화
26
class OptimizedWidget extends StatelessWidget {
27
  @override
28
  Widget build(BuildContext context) {
29
    return Container(
30
      // 단순한 테두리로 대체
31
      decoration: BoxDecoration(
32
        color: Colors.blue,
33
        borderRadius: BorderRadius.circular(8),
34
      ),
35
      child: child,
36
    );
37
  }
38
}

Watch out#

WARNING

RepaintBoundary⁵를 무분별하게 사용하지 마세요. 필요한 곳에만 사용해야 효과적입니다.

1
// RepaintBoundary 적절한 사용
2
// 자주 다시 그려지는 위젯을 분리할 때
3

4
// 좋은 예: 애니메이션이 있는 부분만 분리
5
Stack(
6
  children: [
7
    StaticBackground(), // 정적인 배경
8
    RepaintBoundary(
9
      child: AnimatedWidget(), // 자주 변경되는 부분만 분리
10
    ),
11
  ],
12
)
13

14
// 나쁜 예: 모든 위젯에 RepaintBoundary
15
// 오히려 메모리 사용량만 증가

결론: Timeline Events 탭에서 프레임 내 세부 작업을 분석하여 정확한 병목 지점을 찾을 수 있다.

Why#

NOTE

앱이 전반적으로 느리거나 특정 작업이 오래 걸릴 때, 어떤 코드가 CPU 시간을 많이 사용하는지 파악해야 합니다. CPU Profiler⁶는 메서드별 실행 시간을 분석합니다.

What#

NOTE

CPU Profiler는 샘플링 방식으로 코드 실행을 기록합니다.

flowchart TD subgraph Sampling["CPU 샘플링"] S[250μs 간격] C[콜스택 캡처] end subgraph Views["분석 뷰"] BU[Bottom Up] CT[Call Tree] MT[Method Table] FC[Flame Chart] end S --> C --> Views

뷰	설명	사용 시점
Bottom Up	가장 많이 호출된 메서드부터	핫스팟 찾기
Call Tree	호출 계층 구조	호출 경로 추적
Method Table	메서드별 통계	전체 현황 파악
Flame Chart	시간순 시각화	실행 흐름 이해

How#

TIP

CPU Profiler 사용 방법입니다.

1
# CPU 프로파일링 단계
2
# 1. DevTools > CPU Profiler 탭 선택
3
# 2. Record 버튼 클릭
4
# 3. 앱에서 느린 작업 수행
5
# 4. Stop 버튼 클릭
6
# 5. 결과 분석

Bottom Up 뷰 분석입니다.

1
Bottom Up 뷰 해석:
2
  Self Time: 해당 메서드 자체 실행 시간
3
  Total Time: 하위 호출 포함 전체 시간
4

5
  정렬 기준:
6
    - Self Time 높은 순 → 직접적인 병목
7
    - Total Time 높은 순 → 전체적인 영향
8

9
  예시:
10
    jsonDecode (Self: 15%, Total: 15%)
11
    _parseList (Self: 10%, Total: 10%)
12
    → JSON 파싱이 CPU 시간의 25% 차지

Call Tree 분석으로 호출 경로를 추적합니다.

1
// Call Tree 예시 해석
2
// main() → 100%
3
//   └── MyApp.build() → 80%
4
//         └── HomePage.build() → 70%
5
//               └── _loadData() → 60%
6
//                     └── jsonDecode() → 50%
7

8
// → jsonDecode가 병목이지만
9
//   실제 문제는 _loadData가 build에서 호출되는 것
10

11
// 개선 전
12
class HomePage extends StatelessWidget {
13
  @override
14
  Widget build(BuildContext context) {
15
    final data = jsonDecode(rawJson); // build에서 파싱하면 안 됨
16
    return DataView(data: data);
17
  }
18
}
19

20
// 개선 후
21
class HomePage extends StatefulWidget {
22
  @override
23
  State<HomePage> createState() => _HomePageState();
24
}
25

26
class _HomePageState extends State<HomePage> {
27
  late Future<Data> _dataFuture;
28

29
  @override
30
  void initState() {
31
    super.initState();
32
    _dataFuture = _loadAndParseData();
33
  }
34

35
  Future<Data> _loadAndParseData() async {
36
    // 별도 작업으로 분리
37
    return compute(jsonDecode, rawJson);
38
  }
39

40
  @override
41
  Widget build(BuildContext context) {
42
    return FutureBuilder(
43
      future: _dataFuture,
44
      builder: (context, snapshot) {
45
        if (snapshot.hasData) {
46
          return DataView(data: snapshot.data!);
47
        }
48
        return CircularProgressIndicator();
49
      },
50
    );
51
  }
52
}

Watch out#

WARNING

CPU 샘플링 레이트를 조절할 수 있습니다. 높은 레이트는 정확도가 높지만 오버헤드도 증가합니다.

1
샘플링 레이트 설정:
2
  Low (250μs): 기본값, 일반적인 분석에 적합
3
  Medium (125μs): 더 정밀한 분석 필요 시
4
  High (62.5μs): 매우 짧은 작업 분석 시
5

6
  주의: 높은 레이트는 앱 성능에 영향

결론: CPU Profiler로 가장 많은 CPU 시간을 사용하는 코드를 찾아 최적화할 수 있다.

Why#

NOTE

Flutter 앱의 메모리 사용량이 계속 증가하면 앱이 느려지거나 강제 종료될 수 있습니다. Memory 뷰⁷로 메모리 사용 패턴과 누수를 분석합니다.

What#

NOTE

Memory 뷰는 Dart 힙 메모리를 실시간으로 모니터링합니다.

flowchart LR subgraph Memory["Dart 메모리"] H[Heap] O[Objects] GC[GC] end subgraph Metrics["측정 항목"] U[Used] C[Capacity] E[External] end H --> O O --> GC Memory --> Metrics

메트릭	설명
Used	현재 사용 중인 힙 메모리
Capacity	할당된 힙 크기
External	외부 메모리 (이미지 등)
GC	가비지 컬렉션 발생

How#

TIP

Memory 뷰 기본 사용법입니다.

1
Memory Chart 읽기:
2
  파란색 영역: 사용 중인 힙
3
  점선: 힙 용량
4
  스파이크: 일시적인 메모리 증가
5

6
  정상 패턴:
7
    - 사용량이 증가 → GC 발생 → 감소 반복
8
    - 기준선이 일정하게 유지
9

10
  문제 패턴:
11
    - 사용량이 계속 증가 (메모리 누수)
12
    - GC 후에도 기준선이 높아짐

메모리 차트 분석 예시입니다.

1
// 메모리 누수 패턴 확인
2
// 1. Memory 뷰 열기
3
// 2. 특정 화면 진입/이탈 반복
4
// 3. 메모리 그래프 관찰
5

6
// 정상: 화면 이탈 후 메모리 감소
7
// 누수: 화면 이탈 후에도 메모리 유지/증가
8

9
// 누수 의심 코드 예시
10
class LeakyWidget extends StatefulWidget {
11
  @override
12
  State<LeakyWidget> createState() => _LeakyWidgetState();
13
}
14

15
class _LeakyWidgetState extends State<LeakyWidget> {
16
  late StreamSubscription subscription;
17

18
  @override
19
  void initState() {
20
    super.initState();
21
    // 구독 시작
22
    subscription = someStream.listen((data) {
23
      setState(() {
24
        // 데이터 처리
25
      });
26
    });
27
  }
28

29
  // 문제: dispose에서 구독 해제 안 함
30
  // Widget이 제거되어도 구독이 유지되어 메모리 누수
31

32
  @override
33
  void dispose() {
34
    subscription.cancel(); // 이 줄이 없으면 누수!
35
    super.dispose();
36
  }
37

38
  @override
39
  Widget build(BuildContext context) {
40
    return Container();
41
  }
42
}

Watch out#

WARNING

BuildContext를 비동기 콜백에서 사용할 때 주의하세요. Widget이 dispose된 후에도 콜백이 실행되면 문제가 됩니다.

1
// 문제: async 콜백에서 context 사용
2
class ProblematicWidget extends StatefulWidget {
3
  @override
4
  State<ProblematicWidget> createState() => _ProblematicWidgetState();
5
}
6

7
class _ProblematicWidgetState extends State<ProblematicWidget> {
8
  Future<void> loadData() async {
9
    final data = await fetchData();
10
    // Widget이 이미 dispose 되었을 수 있음!
11
    Navigator.of(context).push(...);
12
  }
13

14
  @override
15
  Widget build(BuildContext context) {
16
    return ElevatedButton(
17
      onPressed: loadData,
18
      child: Text('Load'),
19
    );
20
  }
21
}
22

23
// 해결: mounted 체크
24
class SafeWidget extends StatefulWidget {
25
  @override
26
  State<SafeWidget> createState() => _SafeWidgetState();
27
}
28

29
class _SafeWidgetState extends State<SafeWidget> {
30
  Future<void> loadData() async {
31
    final data = await fetchData();
32
    // mounted 체크
33
    if (!mounted) return;
34
    Navigator.of(context).push(...);
35
  }
36

37
  @override
38
  Widget build(BuildContext context) {
39
    return ElevatedButton(
40
      onPressed: loadData,
41
      child: Text('Load'),
42
    );
43
  }
44
}

결론: Memory 뷰의 실시간 차트로 메모리 사용 패턴을 모니터링하고 누수를 탐지할 수 있다.

Why#

NOTE

메모리 차트에서 누수가 의심되면, 구체적으로 어떤 객체가 메모리에 남아있는지 확인해야 합니다. 힙 스냅샷⁸을 비교하면 누수된 객체를 찾을 수 있습니다.

What#

NOTE

Diff Snapshots 기능으로 두 시점의 메모리 상태를 비교합니다.

flowchart LR subgraph Before["스냅샷 1"] A1[화면 진입 전] end subgraph After["스냅샷 2"] A2[화면 이탈 후] end subgraph Diff["차이 분석"] D[새로 생성된 객체] R[유지된 객체] end Before --> Diff After --> Diff Diff --> D Diff --> R

용어	설명
Shallow Size	객체 자체의 크기
Retained Size	객체 + 참조하는 객체들의 크기
Instances	해당 클래스의 인스턴스 수

How#

TIP

Diff Snapshots 사용 방법입니다.

1
스냅샷 비교 절차:
2
  1. 앱을 초기 상태로 만듦
3
  2. Memory 뷰에서 "Take Heap Snapshot" 클릭 (스냅샷 1)
4
  3. 의심되는 작업 수행 (예: 화면 진입/이탈)
5
  4. "Take Heap Snapshot" 다시 클릭 (스냅샷 2)
6
  5. "Diff Snapshots" 탭에서 비교
7
  6. 인스턴스 수가 증가한 클래스 확인

누수 객체 찾기 예시입니다.

1
// Diff Snapshots 결과 해석
2
//
3
// Class Name         | Instances | Shallow Size
4
// ---------------------------------------------------
5
// _MyWidgetState     | +5        | +2,048 bytes
6
// StreamSubscription | +5        | +1,280 bytes
7
// Timer             | +5        | +960 bytes
8
//
9
// → 화면을 5번 진입/이탈했는데 State가 5개 남아있음
10
// → StreamSubscription과 Timer도 함께 누수
11

12
// 원인: dispose에서 정리 안 함
13
class _MyWidgetState extends State<MyWidget> {
14
  late Timer _timer;
15
  late StreamSubscription _subscription;
16

17
  @override
18
  void initState() {
19
    super.initState();
20
    _timer = Timer.periodic(Duration(seconds: 1), (_) {
21
      // 주기적 작업
22
    });
23
    _subscription = stream.listen((data) {
24
      // 데이터 처리
25
    });
26
  }
27

28
  @override
29
  void dispose() {
30
    _timer.cancel();        // 타이머 취소
31
    _subscription.cancel();  // 구독 취소
32
    super.dispose();
33
  }
34

35
  @override
36
  Widget build(BuildContext context) => Container();
37
}

Trace Instances 기능으로 객체 참조 경로를 추적합니다.

1
Trace Instances 사용: 1. 누수된 클래스 선택
2
  2. "Trace Instances" 체크
3
  3. 새 스냅샷 캡처
4
  4. 해당 인스턴스의 참조 경로 확인
5
  5. 어디서 참조를 유지하는지 파악

Watch out#

WARNING

힙 스냅샷 캡처는 앱을 잠시 멈추게 합니다. 대규모 앱에서는 몇 초가 걸릴 수 있습니다.

1
// 스냅샷 캡처 시 주의사항
2
// - 앱이 일시 정지됨
3
// - 메모리가 많을수록 오래 걸림
4
// - 분석 중에는 앱을 조작하지 말 것

결론: Diff Snapshots으로 두 시점의 메모리를 비교하여 누수된 객체를 정확히 찾을 수 있다.

Why#

NOTE

프로파일링 도구로 문제를 찾았다면 실제로 최적화해야 합니다. Flutter 앱에서 자주 발생하는 성능 문제와 해결 방법을 알아봅니다.

What#

NOTE

Flutter 성능 최적화의 주요 영역입니다.

flowchart TD subgraph Optimization["최적화 영역"] B[Build 최적화] R[Render 최적화] M[Memory 최적화] A[Async 최적화] end subgraph Techniques["기법"] B --> B1[const 생성자] B --> B2[Widget 분리] R --> R1[RepaintBoundary] R --> R2[이미지 캐싱] M --> M1[dispose 정리] M --> M2[약한 참조] A --> A1[compute] A --> A2[Isolate] end

How#

TIP

주요 최적화 기법들입니다.

1. Build 최적화

1
// const 생성자 사용
2
class MyWidget extends StatelessWidget {
3
  const MyWidget({super.key}); // const 생성자
4

5
  @override
6
  Widget build(BuildContext context) {
7
    return Column(
8
      children: const [
9
        Icon(Icons.star),         // const
10
        Text('Hello'),            // const
11
        SizedBox(height: 10),     // const
12
      ],
13
    );
14
  }
15
}
16

17
// Widget 분리로 rebuild 범위 최소화
18
class ParentWidget extends StatefulWidget {
19
  @override
20
  State<ParentWidget> createState() => _ParentWidgetState();
21
}
22

23
class _ParentWidgetState extends State<ParentWidget> {
24
  int counter = 0;
25

26
  @override
27
  Widget build(BuildContext context) {
28
    return Column(
29
      children: [
30
        // ExpensiveWidget은 rebuild 안 됨
31
        const ExpensiveWidget(),
32
        // CounterWidget만 rebuild
33
        CounterWidget(count: counter),
34
        ElevatedButton(
35
          onPressed: () => setState(() => counter++),
36
          child: const Text('Increment'),
37
        ),
38
      ],
39
    );
40
  }
41
}

2. 리스트 최적화

1
// ListView.builder 사용 (필수!)
2
// 보이는 항목만 빌드
3
ListView.builder(
4
  itemCount: 10000,
5
  itemBuilder: (context, index) {
6
    return ListTile(title: Text('Item $index'));
7
  },
8
)
9

10
// itemExtent 지정으로 성능 향상
11
ListView.builder(
12
  itemCount: 10000,
13
  itemExtent: 56.0, // 고정 높이
14
  itemBuilder: (context, index) {
15
    return ListTile(title: Text('Item $index'));
16
  },
17
)

3. 무거운 연산 분리

1
// compute 함수로 Isolate에서 실행
2
Future<List<Item>> loadAndParseData() async {
3
  final rawData = await fetchRawData();
4

5
  // 메인 스레드가 아닌 별도 Isolate에서 파싱
6
  final items = await compute(parseData, rawData);
7

8
  return items;
9
}
10

11
List<Item> parseData(String rawData) {
12
  // 무거운 JSON 파싱
13
  final json = jsonDecode(rawData);
14
  return (json as List).map((e) => Item.fromJson(e)).toList();
15
}

4. 이미지 최적화

1
// 적절한 크기로 이미지 로드
2
Image.network(
3
  imageUrl,
4
  cacheWidth: 200,   // 캐시 크기 제한
5
  cacheHeight: 200,
6
)
7

8
// 이미지 캐싱
9
CachedNetworkImage(
10
  imageUrl: imageUrl,
11
  placeholder: (context, url) => CircularProgressIndicator(),
12
  errorWidget: (context, url, error) => Icon(Icons.error),
13
)

Watch out#

WARNING

과도한 최적화는 오히려 해로울 수 있습니다. 항상 프로파일링으로 문제를 확인한 후 최적화하세요.

1
// 시기상조 최적화 피하기
2
// 문제가 확인되기 전까지는 단순하게 유지
3

4
// 나쁜 예: 모든 곳에 const, RepaintBoundary 추가
5
// - 코드 복잡성 증가
6
// - 실제 효과 미미할 수 있음
7

8
// 좋은 예: 프로파일링 → 병목 확인 → 해당 부분만 최적화

결론: 프로파일링으로 찾은 병목에 적절한 최적화 기법을 적용하여 성능을 개선한다.