Flutter 앱 생명주기는 화면보다 먼저 시작됩니다

App Lifecycle는 정의보다 Flutter에서 깨지는 모양으로 이해하는 편이 빠릅니다.

앱이 켜진 뒤 첫 화면만 보면 생명주기를 놓칩니다.
Flutter 앱은 화면이 그려지기 전에도 초기화, 권한 확인, 세션 복원, 플랫폼 이벤트를 지나갑니다.
그래서 앱 시작 코드는 위젯 코드와 같은 속도로 움직이지 않습니다.

이 글에서 다루는 개념은 App Lifecycle입니다.
검색해서 들어온 독자에게 남길 것은 용어 정의가 아니라, Flutter에서 이 개념이 깨질 때 어떤 모양으로 보이는지입니다.

Flutter에서는 이렇게 깨집니다

앱 생명주기는 화면 전환이 아니라 프로세스와 플랫폼 상태의 변화입니다.
resumed, inactive, paused 같은 상태가 바뀌는 동안 네트워크 요청이나 plugin 초기화가 겹치면 같은 화면 코드도 다른 결과를 냅니다.

class AppLifecycleLogger extends StatefulWidget {
  const AppLifecycleLogger({super.key});
  @override
  State<AppLifecycleLogger> createState() => _AppLifecycleLoggerState();
}

class _AppLifecycleLoggerState extends State<AppLifecycleLogger>
    with WidgetsBindingObserver {
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
  }

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.resumed) {
      // 세션/권한/원격 설정처럼 resume 때 다시 볼 일을 여기에 분리합니다.
    }
  }

  @override
  void dispose() {
    WidgetsBinding.instance.removeObserver(this);
    super.dispose();
  }
}

작은 어긋남은 화면에서 먼저 보입니다

이 문제는 처음부터 큰 설계 이슈처럼 보이지 않습니다.
탭을 다시 열었을 때 값이 돌아오거나, 화면 전환 직후 상태가 한 박자 늦거나, 실제 기기에서만 다른 반응이 나오는 정도로 시작합니다.
사용자는 App Lifecycle라는 말을 보지 않습니다.
눌렀는데 늦고, 돌아왔는데 값이 바뀌고, 방금 본 화면이 다음 순간 다른 얼굴을 하는 장면만 봅니다.

그래서 처음에는 화면을 탓하기 쉽습니다.
하지만 Flutter 화면은 눈앞의 위젯만으로 움직이지 않습니다.
그 위젯이 읽는 값은 provider에서 왔을 수 있고, route가 바뀌며 다시 만들어졌을 수 있고, platform event나 async callback이 늦게 들어왔을 수 있습니다.
화면을 구성하는 코드는 짧아도 화면에 도착하기까지 지나온 경로는 길 수 있습니다.

이 작은 어긋남을 그냥 넘기면 나중에 더 비싼 문제가 됩니다.
한 화면에서만 보이던 증상이 탭 구조, nested navigation, refresh, background 복귀를 만나면서 다른 모양으로 퍼집니다.
그때 필요한 것은 “Flutter가 이상하다”는 말이 아니라 어느 경계가 사용자의 손보다 늦게 움직였는지 보는 눈입니다.
이 눈이 있어야 같은 냄새가 다른 위젯에서 나와도 당황하지 않습니다.

이때 디버깅 순서도 달라집니다.
먼저 화면에서 보이는 현상을 그대로 둔 다음, 그 현상이 사용자의 입력 직후인지, 다음 frame 뒤인지, route를 떠난 뒤인지 나눕니다.
같은 늦음이라도 위치가 다르면 원인이 다릅니다.
이 구분을 하지 않으면 작은 수정이 큰 리팩터링으로 번지고, 결국 무엇을 고쳤는지도 흐려집니다.

원인은 위젯 밖 경계에서 커집니다

App Lifecycle 같은 주제는 한 줄짜리 코드 문제처럼 보일 때가 많습니다.
하지만 실제 원인은 build 타이밍, layout 비용, 상태 소유자, native plugin, network 응답 같은 경계를 지나가며 커집니다.
처음 실행에서는 맞았는데 뒤로 갔다 오면 달라지거나, debug에서는 멀쩡한데 release에서 흔들리거나, 빠르게 탭을 넘길 때만 꼬이는 이유가 여기에 있습니다.

이 단계에서는 답을 급하게 내리지 않는 편이 낫습니다.
먼저 사용자가 본 증상과 코드가 바뀐 지점을 나란히 둡니다.
그 다음 어느 경계에서 시간이 어긋났는지, 값의 주인이 둘이 되었는지, 화면보다 늦게 도착한 이벤트가 있는지를 봅니다.
이런 순서로 보면 정답이 늦게 나오는 것 같지만, 실제로는 헛수정을 줄입니다.

예를 들어 화면이 늦게 바뀐다고 해서 바로 setState 위치만 바꾸면 원인을 놓칠 수 있습니다.
이미지 decode가 끝나기 전인지, provider가 dispose된 뒤인지, route가 새 인스턴스를 만든 뒤인지가 다 다릅니다.
같은 “늦다”라도 원인은 다르고, 원인이 다르면 손댈 위치도 달라집니다.
독자가 검색으로 들어왔을 때 필요한 것은 바로 이 구분입니다.

그래서 코드 예시는 짧아도 설명은 충분해야 합니다.
setState, context.mounted, precacheImage, provider 수명 같은 도구는 각각 자기 자리가 있습니다.
도구 이름만 외우면 다음 버그에서 다시 흔들리지만, 도구가 들어가는 경계를 기억하면 다른 화면에서도 같은 판단을 반복할 수 있습니다.

고칠 때는 가장 가까운 경계만 움직입니다

수정은 한 번에 크게 하지 않는 편이 낫습니다.
화면이 어긋났다고 상태 소유자, build 타이밍, navigation, cache를 동시에 바꾸면 결과가 좋아져도 왜 좋아졌는지 남지 않습니다.
먼저 가장 가까운 경계 하나만 고릅니다.
값을 쓰는 쪽이 둘이면 하나로 줄이고, build 안에서 일이 시작되면 생명주기 바깥으로 빼고, platform 이벤트가 늦으면 기다리는 위치를 분리합니다.

이 과정에서 필요한 흔적은 거창하지 않습니다.
작은 widget test 하나, 전후 화면 캡처 하나, 로그 한 줄이면 충분할 때가 많습니다.
다만 그 흔적은 무엇이 달라졌는지를 말해야 합니다.
다음 작업자가 코드를 열었을 때 “왜 이렇게 했지”가 아니라 “이 경계를 줄였구나”라고 읽을 수 있어야 합니다.

또 하나는 손대지 않은 부분을 의식적으로 남기는 일입니다.
Flutter에서는 작은 수정이 주변 위젯의 rebuild, focus, gesture, scroll 상태까지 건드릴 수 있습니다.
그래서 한 번의 수정이 넓게 퍼졌다면 그 자체로 다시 좁혀야 합니다.
고친 줄보다 건드리지 않은 경계가 분명할수록 나중에 되돌리기도 쉽고, 다른 화면에 옮길 때도 덜 위험합니다.

다음 화면에서 같은 냄새를 맡게 됩니다

마지막에 남아야 하는 것은 요약문이 아니라 다음 작업에서 바로 쓰는 감각입니다.
비슷한 화면이 다시 흔들릴 때 제목을 외우지 않아도 됩니다.
사용자의 손, frame, 상태 소유자, 외부 이벤트가 어떤 순서로 만나는지 다시 그려보면 됩니다.
그 순서가 보이면 Flutter의 복잡함은 사라지지 않아도 다루는 속도는 달라집니다.

그래서 결말은 질문표나 보고 문장으로 닫지 않습니다.
무엇을 했다는 말보다 다음에 어디를 먼저 볼지가 남아야 합니다.
같은 종류의 버그를 더 빨리 알아보고, 한 번에 한 경계만 고치는 쪽으로 손이 움직이면 충분합니다.
짧게 말해도 되는 부분과 길게 남겨야 하는 부분을 구분하는 감각도 여기서 생깁니다.

결국 이 주제는 위젯 하나를 예쁘게 고치는 문제가 아닙니다.
화면이 흔들릴 때 보이는 증상 뒤에 있는 순서를 읽는 문제입니다.
그 순서를 읽기 시작하면 수정은 덜 요란해지고, 다음 화면에서 같은 문제가 나와도 다시 처음으로 돌아가지 않습니다.
그 감각이 남으면 다음 수정에서 다시 처음으로 돌아가지 않습니다.
다음 수정에서 손이 먼저 가야 할 곳을 떠올릴 수 있으면 충분합니다.

이 감각은 한 번에 생기지 않습니다.
같은 종류의 화면 흔들림을 두세 번 겪고 나면, 코드보다 먼저 흐름을 그리게 됩니다.
어느 값이 먼저 왔고, 어느 이벤트가 늦었고, 어느 위젯이 오래 살아남았는지 떠올리는 순간 수정의 크기가 줄어듭니다.
그래서 결론을 빨리 닫기보다 그 장면을 충분히 남기는 쪽을 택합니다.

원문 기준

원문 기준: https://api.flutter.dev/flutter/dart-ui/AppLifecycleState.html

원문 본 날짜: 2026-07-01.
발행 전에는 원문의 바뀐 표현만 한 번 더 봅니다.