MAUI CollectionView에서 비동기 처리로 인해 발생하는 UI 불안정 문제

비동기와 CollectionView가 충돌할 수밖에 없는 이유

MAUI CollectionView는 UI를 빠르게 렌더링하기 위해 많은 내부 최적화 구조를 갖고 있다.
하지만 이 구조는 비동기 로직(async/await) 과 만나면 예측하지 못한 UI 이상 현상들을 만들어낼 수 있다.

이 글은 실제 MAUI 앱 개발에서 가장 많이 발생하는
비동기 + CollectionView 조합의 문제들을 심층 분석하고
앱을 안정적으로 유지하는 구조적 해결 패턴을 제시한다.

---

UI는 왜 MainThread에서만 갱신되나

MAUI UI 렌더링은 3가지 요소에 의해 좌우된다.

하지만 비동기 작업은 기본적으로

• 백그라운드 스레드
• I/O thread
• Task Pool
  등에서 실행된다.

이 둘이 충돌하면 UI가 즉시 반영되지 않거나
작업 순서가 역전(reordering)된다.

---

스크롤 중 비동기가 왜 셀 상태를 뒤섞나

비동기 처리 중 스크롤이 발생하면…

• 기존 셀이 재활용됨
• BindingContext가 교체됨
• UI가 다시 그려짐
• 아직 비동기 작업이 끝나기 전
  → UI가 엉뚱한 값으로 바뀌는 문제 발생

이것이 흔히 말하는
비동기 상태 레이스 컨디션(UI Race Condition) 이다.

---

ObservableCollection은 비동기 갱신에 왜 취약한가

특히 다음 상황에서 문제가 매우 자주 발생한다.

• await 이후 리스트 Add
• await 이후 리스트 Clear
• Task.Delay 이후 UI 반영
• 작업 도중 리스트 구조가 변경됨
• 빠른 속도로 항목들을 갱신하는 경우

DataTemplate 재활용 + 비동기 + Binding
이 세 가지가 동시에 작동하면 문제가 발생하는 것이 매우 자연스러운 구조다.

---

실제 앱에서 어떤 증상이 나타나나

비동기 로직을 CollectionView와 함께 사용한 대부분의 앱에서 다음 증상들이 나타난다.

체크박스가 순간적으로 다시 풀림

비동기 로직 이후 UI 재바인딩으로 인해 상태가 초기화된 것처럼 보인다.

다운로드 버튼 클릭 후 바인딩 상태가 늦게 반영됨

await 이후 UI 갱신 타이밍이 밀림.

빠르게 스크롤하면 UI가 깜빡임

Template 재활용 + 비동기 로딩 레이스.

항목 추가, 삭제 시 CollectionView가 튕김

ObservableCollection이 비동기 처리 후 갑자기 수정되기 때문.

토스트 또는 팝업이 중복 실행

await 이후 UI 흐름이 중첩으로 실행됨.

즉, 이전 글(16~19)에서 다룬 문제들이
비동기 작업이 개입되면 더 강하게 드러난다.

---

비동기 문제를 해결하는 핵심 전략 7가지

전략 1, 모든 비동기 UI 변경은 반드시 MainThread에서 실행

가장 기본이면서 가장 강력한 패턴이다.

 

MainThread.BeginInvokeOnMainThread(() => { PlaylistItems.Add(newItem); });

이 한 줄로 UI 레이스 문제가 반 이상 해결된다.

전략 2, ObservableCollection 변경은 await 이후 즉시 실행하지 말 것

다음 패턴은 매우 위험하다.

 

await Task.Delay(2000); PlaylistItems.Add(item); // 🚨 문제 발생 가능성 높음

비동기 이후 셀이 재활용되면 UI 상태가 뒤섞인다.

안전한 패턴은 다음과 같다.

 

await Task.Delay(2000); MainThread.BeginInvokeOnMainThread(() => { PlaylistItems.Add(item); });

전략 3, 비동기 작업 중에는 UI 상태 변경 금지

예를 들어 다운로드 UI에서 다음 패턴은 절대 금지다.

 

item.IsSelected = false; // 비동기 도중 상태 조작은 위험 await ytdlpService.Download(item);

셀 재활용 + await가 결합되면 UI와 Model의 상태가 틀어질 수 있다.

전략 4, CancellationToken을 정확히 사용해 흐름을 정리

비동기 작업 도중 사용자가 스크롤하거나 재클릭할 때 취소되지 않으면
이벤트가 겹쳐 UI 버그가 매우 쉽게 발생한다.

안전 패턴

 

_cts?.Cancel(); _cts = new CancellationTokenSource(); await DoWorkAsync(_cts.Token);

전략 5, async void 이벤트 핸들러 남용 금지

MAUI에서 가장 흔한 실수 중 하나.

예

 

private async void CheckBox_CheckedChanged(...)

이 패턴은 예외 처리, 흐름 제어, 중복 방지 등이 매우 어렵다.

가능하면 다음 구조로 바꿔야 한다.

비동기 → Task 반환

UI 이벤트 → Task.FireAndForget 구조

전략 6, DataTemplate 내부에서 비동기 작업 금지

템플릿 내부에서 다음 코드가 실행되면 UI 혼란이 거의 확정이다.

 

await Task.Delay(500); Image.Source = newImage;

셀은 재활용되므로 await 이후 UI가 다른 항목에 반영될 수도 있다.

해결법
→ 셀 내부에서는 비동기를 사용하지 않는다
→ ViewModel 계층에서 이미지 로드 후 Model 속성에 반영
→ UI는 Binding을 통해 값만 표시

전략 7, 비동기 로직은 반드시 ViewModel 중심으로 관리

UI → 이벤트 → ViewModel → Model → UI 갱신
이 흐름을 유지해야 비동기 중첩 문제를 완전히 해결할 수 있다.

---

안정적인 비동기 아키텍처 설계 예시

프로젝트 규모가 커질수록 다음 구조는 필수에 가깝다.

UI 레이어

• 클릭 이벤트만 받고 ViewModel에 전달
• UI 조작 금지
• async void 최소화

ViewModel

• 모든 async Task 로직 관리
• CancellationToken 관리
• ObservableCollection 갱신은 MainThread에서 수행

Model

• UI 상태는 모두 Model 속성에서 파생되도록 구성
• 단일 상태 원본 유지

이 구조로 설계하면
스크롤 · 갱신 · 다운로드 · 체크박스 · UI 업데이트
이 모든 요소가 자연스럽게 안정화된다.

 

 

---

마무리 요약

MAUI CollectionView는 성능 최적화 때문에 비동기 로직과 섞이면 다음 문제가 거의 필연적으로 발생한다.

• UI 반영 순서 틀어짐
• 값 반영 지연
• 상태 누수
• 셀 재활용 + await 조합 문제
• ObservableCollection의 비동기 수정 버그

이 문제들을 해결하려면 다음 5가지를 반드시 기억해야 한다.

1 비동기 후 UI 변경은 MainThread에서만
2 ObservableCollection 변경은 await 바로 뒤에서 하면 위험
3 DataTemplate 내부 비동기 금지
4 async void 최소화
5 ViewModel 중심 비동기 아키텍처 구성

이 구조를 지키면 CollectionView 기반 앱은 훨씬 안정적으로 동작한다.