최근 대규모 트래픽을 처리하는 커머스 앱을 Flutter로 마이그레이션하면서 팀원들 사이에서 가장 뜨거운 논쟁 주제는 "왜 하필 Dart인가?"였습니다. JavaScript 생태계의 방대함이나 Kotlin의 안전성을 두고 구글은 왜 당시 죽어가던 언어였던 Dart를 선택했을까요? 단순히 구글 내부 언어라서가 아닙니다. 실제 프로덕션 환경에서 앱을 배포하고 프로파일링을 돌려보면, Dart가 아니었다면 불가능했을 퍼포먼스 구간들이 보이기 시작합니다. 특히 복잡한 애니메이션이 겹치는 UI 스레드에서 60fps(최근엔 120fps)를 방어하려면, Dart의 독특한 메모리 관리와 컴파일 전략을 반드시 이해해야 합니다. 오늘은 겉핥기식 문법 공부가 아닌, 시니어 엔지니어 관점에서 Flutter와 Dart의 기술적 필연성을 파헤쳐 보겠습니다.
JIT와 AOT: 두 마리 토끼를 잡는 전략
개발 생산성과 런타임 성능은 보통 트레이드오프 관계에 있습니다. 인터프리터 언어는 수정이 빠르지만 느리고, 컴파일 언어는 빠르지만 빌드 시간이 깁니다. Flutter 개발팀은 이 문제를 Dart의 "이중 컴파일 모델"로 해결했습니다.
저희 팀이 처음 Flutter를 도입했을 때, 안드로이드 네이티브 개발자들이 가장 놀라워했던 기능은 'Hot Reload'였습니다. 이는 Dart가 개발 모드(Debug Mode)에서는 JIT(Just-In-Time) 컴파일러를 사용하기 때문에 가능합니다. 코드 변경 사항을 증분 컴파일하여 실행 중인 VM에 즉시 주입하죠. 하지만 앱을 배포(Release Mode)할 때는 AOT(Ahead-Of-Time) 컴파일러가 작동하여 기계어(ARM/x86)로 직접 변환됩니다. 이 덕분에 브릿지(Bridge) 없이 네이티브에 준하는 속도를 낼 수 있는 것입니다.
--profile 모드로 빌드하여 분석해야 합니다.
동시성의 함정: async는 병렬이 아니다
많은 주니어 개발자들이 Dart의 Future와 async/await를 사용하면서 가장 많이 하는 오해가 있습니다. "비동기 함수니까 백그라운드 스레드에서 돌겠지?"라는 생각입니다. 하지만 Dart는 기본적으로 Single Thread 기반의 이벤트 루프(Event Loop) 모델입니다.
실제 프로젝트에서 대용량 JSON 파싱(약 5MB 크기)을 수행할 때, 단순히 async 함수로 처리했다가 UI가 2초간 멈추는(Freezing) 현상을 겪었습니다. 이는 CPU 바운드 작업이 메인 아이솔레이트(Main Isolate)를 점유해버렸기 때문입니다. Dart에서 진정한 병렬 처리를 하려면 Isolate를 사용해야 합니다.
실패했던 접근: 단순 Future 처리
아래 코드는 UI를 멈추게 하는 전형적인 나쁜 패턴입니다.
// ⛔️ 잘못된 접근: 메인 스레드를 차단함
Future<void> heavyTask() async {
// 이 루프가 도는 동안 UI는 터치에 반응하지 않음
var result = 0;
for (var i = 0; i < 1000000000; i++) {
result += i;
}
print(result);
}위 코드는 비동기 함수처럼 보이지만, 실제 연산은 이벤트 루프의 틱(Tick)을 잡아먹으며 동기적으로 실행됩니다. 이를 해결하기 위해 Dart 2.19 이후부터는 Isolate.run()이나 Flutter의 compute() 함수를 활용해야 합니다.
솔루션: Isolate를 활용한 메모리 격리
Dart의 Isolate는 스레드와 비슷하지만, 메모리를 공유하지 않는다는 결정적인 차이가 있습니다. 락(Lock)을 걸 필요가 없어 데드락(Deadlock) 문제에서 자유롭지만, 데이터를 주고받을 때 메시지 패싱(Message Passing) 비용이 발생합니다.
// ✅ 올바른 접근: 별도의 Isolate 생성
import 'dart:isolate';
Future<void> betterTask() async {
// 메인 스레드와 완전히 분리된 메모리 공간에서 실행
final result = await Isolate.run(() {
var total = 0;
for (var i = 0; i < 1000000000; i++) {
total += i;
}
return total;
});
print('Result: $result');
}Isolate.run을 사용하면 내부적으로 별도의 힙(Heap) 공간을 가진 작업자가 생성되어 연산을 수행하고 결과만 메인 아이솔레이트로 반환합니다. 이 패턴을 적용한 후, JSON 파싱 중에도 스크롤 프레임 드랍이 '0'으로 수렴하는 것을 확인할 수 있었습니다. 자세한 내용은 Dart 공식 문서의 Concurrency 가이드를 참고하시기 바랍니다.
가비지 컬렉션과 위젯 라이프사이클
Flutter는 UI를 그릴 때 수많은 단기(Short-lived) 위젯 객체를 생성하고 파괴합니다. build() 메서드는 초당 60회 이상 호출될 수도 있는데, 이때마다 수천 개의 객체가 힙에 쌓입니다. Java나 예전 Android 개발 경험이 있다면 "GC 오버헤드 때문에 렉이 걸리지 않을까?"라고 걱정할 수 있습니다.
Dart의 GC는 세대별 가비지 컬렉션(Generational Garbage Collection)을 사용하여 이 문제에 최적화되어 있습니다.
| 메모리 영역 | 특징 | Flutter와의 궁합 |
|---|---|---|
| Young Space | 객체 생성 속도가 매우 빠르며, 수거(Scavenge) 비용이 저렴함 | build()에서 생성되는 일회성 위젯(StatelessWidget) 처리에 최적 |
| Old Space | 오래 생존한 객체가 이동됨. Mark-Sweep 알고리즘 사용 | 앱의 상태(State)나 오래 유지되는 컨트롤러 객체 관리 |
Flutter가 "모든 것은 위젯이다(Everything is a Widget)"라는 철학을 유지하면서도 고성능을 내는 비결이 바로 여기에 있습니다. Young Space에서의 할당과 해제는 단순히 포인터를 이동시키는 것만큼 빠르기 때문에, 불변(Immutable) 위젯을 계속해서 재생성하는 패턴이 성능 저하를 일으키지 않는 것입니다. 오히려 상태를 가진 가변 객체를 관리하는 비용보다 저렴합니다.
주의할 점과 엣지 케이스
물론 Dart와 Flutter의 조합이 만능은 아닙니다. Platform Channel을 통한 네이티브 통신(MethodChannel)은 직렬화/역직렬화 비용이 발생합니다. 이미지 바이너리 데이터나 실시간 센서 데이터를 대량으로 주고받을 때는 이 오버헤드가 병목이 될 수 있습니다. 이럴 때는 FFI(Foreign Function Interface)를 사용하여 C/C++ 레벨에서 직접 메모리를 공유하는 방식을 고려해야 합니다.
또한, Dart의 Isolate 생성 비용은 0이 아닙니다. 아주 가벼운 작업(예: 간단한 수학 연산)을 위해 Isolate를 띄우는 것은 오히려 초기화 비용 때문에 전체 응답 시간을 늦출 수 있습니다. 작업의 복잡도가 최소 2ms 이상 걸릴 것으로 예상될 때만 Isolate를 사용하는 것이 좋습니다.
compute()로 분리하되, 빈번한 호출은 지양하고 배치(Batch)로 처리하세요.
결론
Flutter가 Dart를 선택한 것은 우연이 아닙니다. AOT 컴파일을 통한 네이티브급 실행 속도, JIT를 통한 빠른 개발 주기, 그리고 UI 프레임워크에 최적화된 메모리 할당 구조는 모바일 개발의 난제들을 우아하게 해결했습니다. 단순한 문법 습득을 넘어 이러한 내부 동작 원리를 이해한다면, 더욱 견고하고 부드러운 사용자 경험을 제공하는 앱을 만들 수 있을 것입니다.
Post a Comment