프로젝트에서 보기 →

[Flutter 앱 개발 실전] 2-2. 상태 관리 이해하기

태그
기술
시작일
종료일
수정일

https://www.youtube.com/watch?v=060WneH9Dzk

1. 이건 꼭 알아야 한다[^1]

[? 질문] Flutter에서 말하는 **상태(state)**란 무엇이며, 위젯에서 어떻게 나타나는가[^2]
[= 답] 상태는 코드상에서 변수에 할당된 값으로 존재하며, 위젯이 생성될 때 전달받는 값(예: color, child)처럼 UI를 구성하는 입력으로 나타난다.[^2]

[? 질문] StatelessWidget과 StatefulWidget의 핵심 차이는 무엇인가[^3]
[= 답] Stateless는 “상태가 없다”가 아니라 상태 변경이 없다는 뜻이며, 한번 할당된 값(상수처럼 취급되는 상태)을 바꿀 수 없다.[^3][^4] 반면 Stateful은 상태를 바꿀 수 있고, 상태 변경 후 setState로 build를 다시 실행해 화면을 갱신한다.[^5]

[? 질문] 왜 **상태 관리(state management)**가 필요하고, 어떤 방식으로 문제를 해결하는가[^10]
[= 답] 동일한 데이터(공유 상태)가 여러 위젯에 흩어져 있으면 변경 시 동기화가 필요하고, 이를 못하면 데이터 일관성이 깨진다.[^9][^10][^12] 해결은 공유 상태를 한 곳에 모아 중앙집중식으로 관리하고, 변경 시 이를 소비하는 위젯에 변경 알림을 보내 일관성을 유지하는 것이다.[^13][^14]

2. 큰 그림[^1]

이 콘텐츠는 Flutter 앱 개발에서 UI가 바뀌는 근본 단위인 **상태(state)**를 “변수 값” 관점에서 정의하고, Stateless/Stateful 위젯에서 상태가 어떻게 다뤄지는지 설명한 뒤, 로컬 상태와 공유 상태를 구분하여 왜 상태 관리가 필요해지는지(일관성/동기화 문제)와 전형적 해결 방향(중앙집중식 관리 + 알림)을 제시한다.[^2][^5][^10][^14]

  • 상태 = 변수 값: 위젯은 생성 시 전달받는 값(예: color, child)을 기반으로 UI를 그리며, 이 값들을 상태로 볼 수 있다.[^2]
  • Stateful의 갱신 메커니즘: 상태를 새 값으로 바꾸고 setState를 호출해 build를 다시 실행함으로써 UI를 갱신한다.[^5][^6][^7]
  • 상태 관리의 본질 = 공유 상태 동기화: 여러 위젯이 같은 데이터를 보여줄 때 변경이 발생하면 전체가 동일한 값으로 맞춰져야 하며, 이를 위해 데이터를 한 곳에 모으고 변경 알림을 전달한다.[^9][^10][^13][^14]

3. 하나씩 살펴보기[^1]

3.1 “상태”는 코드에서 변수 값으로 존재한다[^2]

📸 0:01

발표자는 “다음으로 상태의 이야기”라고 하며 논의를 상태로 전환한다.[^1] 이어서 상태를 추상적으로 정의하기보다, Flutter 코드/위젯을 볼 때 상태가 무엇인지 직관적으로 잡는 방식으로 설명한다.[^2]

  • 상태는 코드상에서 변수에 할당된 값으로 존재한다고 말한다.[^2]
  • 예시로 어떤 위젯(영상에서 “뷰 A라는 위젯”)을 보면서, 그 안에 color와 child 같은 속성이 있다고 한다.[^2]
  • 이 color와 child는 해당 위젯이 처음 생성될 때 전달받은 상태를 의미한다고 설명한다.[^2]

즉, 이 콘텐츠의 관점에서 “상태”는 거창한 개념이 아니라, UI가 구성될 때 위젯에 주입되는 입력 값들이며(변수 값), 화면에 어떤 모습이 나타날지를 결정하는 데이터로 이해시키려 한다.[^2]

3.2 StatelessWidget: “상태가 없다”가 아니라 “상태 변경이 없다”[^3]

📸 0:19

발표자는 StatelessWidget을 오해하기 쉬운 표현부터 바로잡는다.[^3]

  • [? “스테이트리스”는 상태가 없다는 뜻인가?]
    [= 아니다. “상태가 없다”가 아니라 상태 변경이 없다는 뜻이다.][^3]

그리고 그 이유를 “변수를 바꿀 수 있느냐”로 연결한다.[^4]

  • StatelessWidget에서는 한번 할당된 변수를 바꿀 수 없기 때문에, 발표자는 이를 “상태 상수”라고 표현했다고 말한다.[^4]
  • 여기서 핵심은 “상태라는 값은 존재할 수 있지만” 그 값이 생성 이후 바뀌지 않는 구조라는 점이다.[^3][^4]

[!IMPORTANT] Stateless의 포인트 StatelessWidget의 핵심은 “상태의 부재”가 아니라, UI를 결정하는 값이 초기 할당 이후 변경되지 않음(불변)이라는 점이라고 강조한다.[^3][^4]

3.3 StatefulWidget: 상태 변경 + setState로 build 재실행 → 화면 갱신[^5]

📸 0:32

Stateless와 대비하여 StatefulWidget의 동작을 “상태 변경이 가능하다”로 정의한다.[^5]

  • StatefulWidget은 상태 변경을 할 수 있다고 말한다.[^5]
  • 화면 아래 예시를 보며, 상태 클래스에 color라는 상태가 있고, setColor 메소드를 통해 새로운 상태를 전달한다고 설명한다.[^5]
  • 이후 setState를 호출해서 build 메소드를 다시 한번 실행하게 하고, 그 결과 화면을 갱신한다고 한다.[^5]

발표자는 “상태가 새롭게 변경되었기 때문에 build 메소드를 다시 실행해야 한다”는 흐름을 명시한다.[^6] 그리고 그 “build를 다시 실행하는 명령어”가 무엇이냐고 이어가는데, 맥락상 그것이 setState임을 다시 한번 강조하는 구간이다.[^7] 마지막으로 이를 통해 UI를 갱신할 수 있다고 정리한다.[^8]

  • [? 상태가 바뀌면 왜 build를 다시 실행해야 하는가?]
    [= 변경된 상태를 반영한 UI를 다시 그려 화면을 갱신해야 하기 때문이다.][^6][^8]

[!TIP] 상태 변경 후 UI 갱신의 핵심 흐름 상태 값 변경(새 값 준비) → setState 호출 → build 재실행 → UI 갱신 순서로 이해하면 된다고 안내한다.[^5][^6][^8]

3.4 상태의 종류: 로컬 상태 vs 공유 상태(공유 여부 기준)[^9]

📸 1:09

발표자는 “상태는 변수 값”이라는 정의를 다시 상기시키고, 이어서 “상태의 종류”로 넘어간다.[^9]

상태는 공유 여부에 따라 두 가지로 나뉜다고 한다.[^9]

  1. 로컬 상태(Local state)
  • 다른 위젯과 공유되지 않는 상태를 의미한다고 정의한다.[^9]
  1. 공유 상태(Shared state)
  • 여러 위젯에서 공유되어 표현되는 상태를 의미한다고 정의한다.[^10]

여기서 중요한 포인트는 “상태 관리가 주로 문제가 되는 지점”이 공유 상태에서 발생한다는 것을 뒤에서 연결하기 위한 준비로 보인다.[^10][^12]

3.5 공유 상태 예시: 유저 프로필이 여러 위젯에 동시에 등장한다[^11]

📸 2:04

공유 상태를 설명하기 위해 구체 예시를 든다.[^11]

  • “유저의 프로필” 정보가 있다고 가정한다.[^11]
  • 이 유저 프로필이 유저가 작성한 게시글에서도 함께 표현된다고 말한다.[^12]
  • 따라서 지금은 “여러 위젯에서 동일한 정보가 공유”되고 있다고 짚는다.[^12]
  • 이런 상태 변수들을 “공유 상태”라고 부른다고 정리한다.[^12]

이 예시는 Flutter UI에서 흔한 상황(프로필 정보가 헤더, 글 작성자 영역 등 다양한 곳에 반복 노출)을 통해, “한 데이터가 여러 곳에서 동시에 쓰인다”는 구조를 직관적으로 보여준다.[^11][^12]

+++ 상세 예시(콘텐츠 흐름을 풀어쓴 설명)

  • 화면 A: 유저 프로필 영역에 닉네임/프로필 이미지가 표시됨
  • 화면 A의 다른 섹션(예: 게시글 카드): 작성자 정보로 동일한 닉네임/프로필 이미지가 다시 표시됨
  • 이때 프로필 데이터는 “한 사람의 동일 데이터”인데, UI 구성 요소(위젯)는 복수이므로 “여러 위젯이 같은 상태를 바라보는 상황”이 된다.[^11][^12] +++

3.6 공유 상태의 핵심 요구: 변경 시 “동기화”가 필요하다[^13]

📸 2:26

발표자는 공유 상태의 본질적 문제를 “변경”과 “동기화”로 설명한다.[^13]

  • 공유 상태는 여러 위젯에서 같은 데이터가 표현되므로, 만약 상태가 변경되면 공유되고 있는 다른 위젯에서도 동일한 상태를 보여주기 위해 동기화를 해야 한다고 말한다.[^13]

즉, 데이터가 하나 바뀌면 그 데이터를 표시하는 UI 전체가 같은 값으로 업데이트되어야 사용자가 일관된 화면을 본다는 뜻이다.[^13]

  • [? 공유 상태에서 ‘동기화’가 필요한 이유는 무엇인가?]
    [= 같은 데이터가 여러 위젯에 나타나므로, 한 곳에서 바뀌면 다른 곳도 같은 값으로 맞춰 일관된 UI를 보여줘야 하기 때문이다.][^13]

3.7 상태 관리(state management)란: 공유 상태 변경 시 동기화를 수행하는 것[^10]

📸 1:22

이제 발표자는 “상태관리 이야기”로 넘어가며 용어를 정의한다.[^10]

  • 공유 상태가 변경될 때 동기화하는 것을 상태 관리(State Management)라고 부른다고 한다.[^10]
  • 상태 관리가 되지 않으면 데이터의 일관성을 잃게 된다고 경고한다.[^10]

즉 이 콘텐츠에서 “상태 관리”의 정의는 포괄적/추상적 설명이 아니라, 매우 실무적인 문장으로 정리된다:

  • “공유 상태 변경”이라는 사건이 발생했을 때
  • “여러 위젯에 흩어진 표현”을
  • “동일한 값으로 맞추는 동기화 작업”을 수행하는 것[^10]

3.8 상태 관리가 없으면 생기는 사용자 경험 문제: “새로고침이 안 된 느낌”[^11]

📸 2:04

발표자는 데이터 일관성이 깨졌을 때 사용자 입장에서 어떤 느낌이 드는지 예시로 설명한다.[^11]

  • 위 예시처럼 프로필이 변경되었는데, 게시글에 표시되는 작성자 프로필이 변경되지 않으면 사용자 입장에서 “뭔가 새로고침이 안 된 느낌”을 받는다고 한다.[^11]

이는 기술적 오류(동기화 실패)가 UX 문제로 곧바로 번역되는 장면을 보여준다.[^11]

[!WARNING] 일관성 붕괴의 UX 신호 한 화면/영역에서는 값이 바뀌었는데 다른 영역은 그대로라면, 사용자는 앱이 느리거나 버그가 있다고 느끼며 “갱신이 안 됐다”는 인상을 받는다고 설명한다.[^11]

3.9 상태 관리가 필요한 근본 원인: 동일 데이터를 여러 곳에서 갖고 있기 때문[^12]

📸 1:33

발표자는 상태 관리를 “왜 해야 하느냐”를 한 문장으로 귀결한다.[^12]

  • 데이터의 일관성을 잃지 않도록 상태 관리를 하게 된다고 말하고,[^12]
  • 상태 관리가 필요한 근본 원인은 동일한 데이터를 여러 곳에서 가지고 있기 때문이라고 못 박는다.[^12]

즉, 문제의 뿌리는 “데이터가 복제/분산되어 존재하는 구조”이며, 이를 해결하려면 데이터의 단일 출처를 만드는 방향으로 가야 한다는 논리로 이어진다.[^12][^13]

3.10 해결 방식: 공유 상태를 한 곳에 모아 중앙집중식으로 관리 + 변경 알림[^13]

📸 2:26

발표자는 해결을 “데이터를 한 곳으로 모으기”로 제시한다.[^13]

  • 동일 데이터가 여러 곳에 있어 생기는 문제이므로, 데이터를 한 곳으로 모아 관리하면 문제를 해결할 수 있다고 한다.[^13]
  • 그리고 “모든 상태 관리 방법들”이 공유 상태를 한 곳에 모아 중앙집중식으로 관리하도록 만들어 이 문제를 해결한다고 설명한다.[^13]

또한 중앙 저장소(한 곳에 모인 데이터)가 변경되었을 때의 동작을 설명한다.[^14]

  • 중앙집중식으로 관리되는 데이터가 변경되면, 이 데이터를 소비하는 위젯들에게 변경 알림을 보내 데이터 일관성을 유지하는 방식으로 작동한다고 한다.[^14]

정리하면 이 콘텐츠가 제시하는 해결 구조는 다음 흐름이다.[^13][^14]

  1. 공유 상태를 UI 곳곳에 분산해 들고 있지 않는다.[^13]
  2. 공유 상태를 한 곳(중앙)에서 관리한다.[^13]
  3. 중앙의 데이터가 바뀌면, 그 데이터를 사용하는 위젯들에게 변경을 알려 재렌더/갱신을 유도한다.[^14]

3.11 다음 단계 예고: 다양한 상태 관리를 실습으로 학습[^15]

📸 2:45

마지막으로 발표자는 이번 파트에서 “상태 관리가 필요한 이유와 해결 방법”을 배웠다고 정리하고,[^15] 다음 영상/파트에서 다양한 상태 관리 방법을 직접 실습으로 배워보겠다고 예고한다.[^15]

4. 핵심 통찰[^2]

  1. [h “상태”를 거창한 개념이 아니라 ‘변수에 담긴 값’으로 정의하면 UI 변화의 출발점을 빠르게 잡을 수 있다.] Flutter에서 위젯의 color, child 같은 입력을 상태로 보며 출발한다는 점이 실전 이해에 도움을 준다.[^2]
  2. [h Stateless/Stateful의 구분은 ‘상태 유무’가 아니라 ‘상태 변경 가능성’으로 이해해야 오해가 줄어든다.] Stateless도 값은 갖지만, 생성 후 바꾸지 못한다는 설명으로 정리한다.[^3][^4]
  3. [c 상태 관리의 본질은 “공유 상태의 동기화”이며, 실패하면 데이터 일관성 붕괴가 UX 문제로 드러난다.] 프로필은 바뀌었는데 게시글의 프로필이 안 바뀌면 사용자는 “새로고침이 안 됐다”고 느낀다는 예시가 이를 보여준다.[^10][^11]
  4. [h 근본 원인은 ‘동일 데이터를 여러 곳에서 각각 보관’하는 구조다.] 따라서 해결도 “한 곳에 모으기(중앙집중식)”로 자연스럽게 귀결된다.[^12][^13]
  5. [h 중앙 저장소 + 변경 알림은 많은 상태관리 기법들의 공통 골격이다.] 중앙 데이터가 바뀌면 소비 위젯에 알림을 보내 일관성을 유지한다는 동작 모델을 제시한다.[^14]
  • 실행 시사점(콘텐츠가 암시하는 실무 행동)
    • 공유 데이터(예: 로그인 유저 프로필)가 여러 화면/위젯에 등장한다면, 각 위젯이 개별적으로 들고 있지 말고 한 곳에서 관리하도록 설계를 검토한다.[^12][^13]
    • UI 갱신이 필요할 때 “값 변경만”으로 끝내지 말고, 변경 사실이 UI에 반영되도록(예: setState 호출 같은 트리거) 갱신 메커니즘을 확인한다.[^5][^8]

5. 헷갈리는 용어 정리[^9]

  • 상태(State): 코드상에서 변수에 할당된 값으로 존재하며, 위젯 생성 시 전달받는 color, child 같은 값으로 예시화된다.[^2]
  • StatelessWidget: 상태가 “없다”가 아니라 상태 변경이 없다. 한번 할당된 값을 바꿀 수 없어 발표자는 이를 “상태 상수”처럼 표현한다.[^3][^4]
  • StatefulWidget: 상태 변경이 가능하며, 새 상태를 반영하기 위해 setState로 build를 다시 실행해 UI를 갱신한다.[^5][^8]
  • 로컬 상태(Local state): 다른 위젯과 공유되지 않는 상태.[^9]
  • 공유 상태(Shared state): 여러 위젯에서 공유되어 표현되는 상태(예: 유저 프로필이 여러 영역에 표시).[^10][^12]
  • 동기화(Synchronization): 공유 상태가 변경될 때, 그 상태를 사용하는 다른 위젯들도 동일한 값을 보여주도록 맞추는 것.[^13]
  • 상태 관리(State management): 공유 상태 변경 시 동기화를 수행해 데이터 일관성을 유지하는 것.[^10]
  • 중앙집중식 관리(Centralized management): 공유 상태를 한 곳에 모아 관리하고, 변경 시 소비 위젯에 변경 알림을 보내 일관성을 유지하는 방식.[^13][^14]

참고(콘텐츠 정보)[^1]

  • 제목: [Flutter 앱 개발 실전] 2-2. 상태 관리 이해하기[^1]
  • 채널: DevStory[^1]
  • 길이: 2분 59초[^1]
  • 링크: https://www.youtube.com/watch?v=060WneH9Dzk[^1]

[^1]: @[00:01] “다음으로 상태의 이야기입니다” 및 사용자 제공 메타데이터(제목/채널/길이/링크).
[^2]: @[00:08] “상태는 코드상에서 변수에 할당된 값… 컬러와 차일드… 위젯이 처음 생성될 때 전달받은 상태”
[^3]: @[00:19] “스테이트 리스라는 건 상태가 없다는게 아니라 상태 변경이 없다는 거고요”
[^4]: @[00:24] “스트레스리스 위젯에선 한번 할당된이 변수를 바꿀 수 없기 때문에… 상태 상수”
[^5]: @[00:32] “스테이트풀 위젯은 상태 변경… set 컬러… 새로운 상태… 셋 스테이트… 빌드 메소드… 화면 갱신”
[^6]: @[00:45] “상태가 새롭게 변경되었기 때문에… 빌드 메소드를 다시 실행해야”
[^7]: @[01:00] “빌드 메소드를 다시 실행하는 명령어가”
[^8]: @[01:00]~@[01:02] “ui를 갱신하실 수 있습니다” (문맥상 setState 호출로 UI 갱신을 설명하는 구간)
[^9]: @[01:09] “상태는 공유 여부에 따라 로컬 상태와 공유 상태” 및 @[01:17] “로컬 상태는 다른 위젯과 공유되지 않는 상태”
[^10]: @[01:22] “공유 상태는 여러 위젯에서 공유” + @[01:50] “공유 상태가 변경될 때 동기화… 상태 관리… 일관성을 잃게 됩니다”
[^11]: @[02:04] “프로필이 변경… 게시자의 프로필이 변경되어 있지 않으면… 새로고침이 안 된 느낌”
[^12]: @[01:33] “게시글에서도 표현” + @[01:38] “여러 위젯에서 동일한 정보가 공유” + @[02:15] “근본적인 원인은 동일한 데이터를 여러 곳에서”
[^13]: @[02:26] “데이터를 한 곳으로 모아 관리… 중앙집중식으로 관리”
[^14]: @[02:38] “데이터가 변경된 경우… 소비하는 위젯들에게 변경 알림… 데이터 일관성 유지”
[^15]: @[02:45] “여기까지… 배우셨구요” + @[02:54] “다음으로 다양한 상태 관리를… 실습”

← 프로젝트에서 보기