앱 MVP Android RecyclerView 목록 갱신: 데이터·차이·상태를 나누는 5가지 기준

앱 MVP Android RecyclerView 목록 갱신: 데이터·차이·상태를 나누는 5가지 기준

이 글은 Android Views 기반 MVP에서 `RecyclerView`, `ListAdapter`, `DiffUtil`을 각각 무엇을 맡기는 도구로 읽을지 정리합니다. 특정 구현이 모든 앱에서 더 빠르거나 출시 품질을 보장한다는 뜻은 아닙니다. 실제 데이터 규모, 화면 상호작용, 상태 모델, 기기 검증은 앱별로 별도 확인해야 합니다.

먼저 답하기: 목록이 바뀌었다는 사실과 무엇이 바뀌었는지를 나눕니다

`RecyclerView`는 큰 데이터 집합의 제한된 창을 화면에 보이게 하는 UI 구성요소입니다. Android 공식 문서에 따르면 화면 밖으로 스크롤된 뷰는 매번 버리지 않고 새로 보이는 항목에 다시 사용할 수 있습니다. 여기서 `Adapter`는 데이터와 `ViewHolder`를 연결하고, `LayoutManager`는 화면의 배치를 맡습니다.

따라서 서버 응답을 받았다는 사실만으로 화면이 완성된 것은 아닙니다. MVP 팀은 적어도 아래 네 상태를 분리해 기록하는 편이 좋습니다.

Android Developers의 RecyclerView 안내는 `RecyclerView`, `ViewHolder`, `Adapter`, `LayoutManager`의 책임을 분리해 설명합니다. MVP에서는 이 구조를 그대로 복잡하게 확장하기보다, 목록 한 화면에서 어떤 상태를 사용자에게 보여줄지 먼저 적는 것이 출발점입니다.

두 번째 기준: 전체 새로고침과 항목 차이를 같은 신호로 쓰지 않습니다

목록 데이터가 바뀐 뒤 전체 항목을 다시 묶어 갱신하는 방식은 구현을 빨리 시작하게 해 줄 수 있습니다. 다만 사용자가 보던 위치, 선택·확장 상태, 특정 행의 로딩 표시처럼 ‘어느 항목이 왜 바뀌었는가’를 다뤄야 한다면 전체 갱신만으로는 원인을 추적하기 어렵습니다.

Android의 `DiffUtil`은 두 목록을 입력으로 받아 추가·삭제·이동·변경 차이를 계산해 `RecyclerView`에 전달할 수 있습니다. 이 방식은 변경을 최소화해 갱신하는 데 도움이 될 수 있지만, 공식 API 문서도 비교 중 두 목록이 메모리에 함께 존재하고, 목록 내용은 변경 불가능한 새 인스턴스로 제공되어야 한다는 전제를 밝힙니다. 즉, 차이 계산을 붙였다는 사실만으로 데이터 모델이나 화면 상태 설계가 끝나지는 않습니다.

관찰: 새 목록 응답을 받음
식별: 항목 ID가 같은가
비교: 화면에 보이는 값이 달라졌는가
표시: 변경·삽입·삭제·빈 상태 중 무엇을 보여줄 것인가
검증: 스크롤, 탭, 재시도 뒤 의도한 상태가 유지되는가

변경 기준이 불명확하면 목록 항목의 ID와 표시 값이 어떤 데이터에서 왔는지부터 정리하세요. 예를 들어 서버의 정렬 순서가 바뀐 것인지, 사용자가 수정한 제목이 반영된 것인지, 잠시 표시할 로딩 행이 추가된 것인지가 각각 다른 상태라면 하나의 ‘새로고침 완료’ 이벤트로 묶지 않는 편이 좋습니다.

세 번째 기준: ListAdapter는 목록 책임을 줄이는 선택이지 화면 기획을 대신하지 않습니다

`ListAdapter`는 `RecyclerView.Adapter`를 바탕으로 목록 차이 계산을 백그라운드 스레드에서 수행하는 고수준 API입니다. 새 목록은 `submitList()`로 전달하고, 현재 표시 중인 목록은 `getCurrentList()`로 읽을 수 있습니다. Android 공식 API 문서는 일반적인 목록 접근과 개수 처리를 구현하는 편의 래퍼라고 설명합니다.

이 사실에서 바로 ‘모든 목록은 ListAdapter여야 한다’고 결론 내릴 수는 없습니다. 다음 조건이 맞는지 확인하세요.

• 화면이 목록의 이전·현재 값을 명확히 구분할 수 있는가

• 항목의 동일성(ID)과 내용 동일성(화면에 보이는 값)을 따로 정의했는가

• 목록 객체를 제자리에서 바꾸지 않고 새 값으로 전달할 수 있는가

• 빈 목록·첫 로딩·재시도·페이지 추가가 같은 리스트로 오해되지 않는가

• 사용자의 탭과 스크롤, 상세 화면 복귀 뒤 어떤 결과를 기대하는지 QA 조건으로 적었는가

ListAdapter 공식 API는 `submitList()`와 현재 목록, 백그라운드 차이 계산의 범위를 확인할 수 있는 기준입니다. 단, 실제 차이 계산 방식과 콜백 정의는 팀의 데이터 모델에 맞게 검토해야 합니다.

목록 자체의 갱신 방식과 별개로, 로딩·진행 상태를 어떤 문구와 다음 행동으로 나눌지까지 점검하려면 MVP 로딩·진행 상태 안내 기준도 함께 참고하세요.

목록 화면에서 데이터·상태·사용자 행동을 나눠 MVP 범위를 정리해야 한다면, 유인어스에 MVP 범위 상담하기로 현재 흐름을 공유해 보세요.

네 번째 기준: 항목 비교 규칙은 데이터 계약으로 남깁니다

차이를 계산할 때 가장 흔한 혼선은 ‘같은 항목’과 ‘같은 내용’을 한 조건으로 처리하는 것입니다. 항목 ID가 같아도 제목, 금액 표시, 진행 상태, 권한에 따른 버튼처럼 사용자에게 보이는 값은 달라질 수 있습니다. 반대로 표시 문구가 같아도 권한·탭 동작·숨은 상태가 달라졌다면 별도의 검토가 필요할 수 있습니다.

MVP 단계에서는 비교 규칙을 코드 한 곳에만 숨기지 말고 다음처럼 간단한 계약으로 남기면 좋습니다.

이 계약은 특정 라이브러리 사용 여부와 별개로 필요합니다. 특히 요청을 여러 번 보낼 수 있는 검색·필터 목록에서는 먼저 시작한 요청이 나중에 끝날 수 있습니다. ‘마지막 응답이 화면에 보였다’는 관찰과 ‘사용자가 현재 선택한 조건에 맞는 목록’은 다를 수 있으므로, 요청 조건과 화면 조건을 함께 기록하세요.

다섯 번째 기준: 목록 갱신, 핵심 흐름 QA, 실제 사용 관찰을 따로 닫습니다

목록이 부드럽게 바뀌는 것처럼 보여도 출시 검토가 끝난 것은 아닙니다. 화면 품질은 데이터 도착, 변화 계산, UI 바인딩, 상호작용, 접근성, 실제 기기 관찰을 각각 거쳐야 확인됩니다. Android 공식 문서는 `RecyclerView`가 뷰를 재사용해 반응성과 전력 사용 측면에 도움을 준다고 설명하지만, 한 번의 구현 변경이 특정 앱의 전환율이나 유지율을 높인다고 단정할 근거는 아닙니다.

출시 전 점검표

• 목록·로딩·빈 상태·오류 상태의 화면 문구와 다음 행동을 구분했는가

• 항목 동일성과 내용 변경 기준을 데이터 계약으로 남겼는가

• 새 목록 제출 뒤 스크롤·탭·상세 복귀·재시도 흐름을 확인했는가

• 필터·검색·페이지 추가처럼 요청 조건이 바뀌는 경우를 시험했는가

• 전체 갱신과 항목 차이 갱신 중 선택한 이유와 제외한 조건을 기록했는가

• 실제 대상 기기에서 텍스트 크기·네트워크 전환·빈 목록을 포함해 QA했는가

목록을 ‘그리는’ 것과 목록 상태를 사용자가 이해하고 다음 행동을 할 수 있게 만드는 일은 다릅니다. 개발 선택은 그 차이를 확인 가능한 기록으로 바꾸는 데 쓰는 편이 좋습니다.

자주 묻는 질문

RecyclerView를 쓰면 목록 성능 문제가 모두 해결되나요?

아닙니다. RecyclerView는 큰 데이터 집합을 효율적으로 표시하도록 돕고 뷰를 재사용합니다. 하지만 데이터 요청, 이미지 처리, 항목 레이아웃, 상태 모델, 실제 기기 조건은 별도로 확인해야 합니다.

ListAdapter를 쓰면 notifyDataSetChanged를 절대 쓰지 않아도 되나요?

그렇게 단정할 수 없습니다. ListAdapter는 목록 차이 계산을 돕는 고수준 API입니다. 실제 화면의 변경 성격과 데이터 모델을 보고 적절한 갱신 방식을 정해야 하며, 항목 ID·내용 비교 기준은 여전히 팀이 정의해야 합니다.

DiffUtil의 동일 항목과 동일 내용은 왜 나눠야 하나요?

같은 ID의 항목도 사용자에게 보이는 제목·상태·버튼이 달라질 수 있기 때문입니다. 반대로 표시 값이 같아도 다른 요청 조건이나 권한 상태일 수 있습니다. 두 기준을 나누면 어떤 변경을 화면에 반영할지 검토하기 쉽습니다.

목록이 보이면 MVP 검증도 끝난 것인가요?

아닙니다. 목록 표시, 데이터 정확성, 빈 상태·오류 안내, 탭과 복귀 흐름, 실제 기기 QA는 별도 확인입니다. MVP의 핵심 행동이 목록에 의존한다면 그 행동을 끝까지 수행할 수 있는지 따로 검증하세요.

Android MVP에서 목록·상태·QA 범위를 제품 흐름에 맞게 정리하고 싶다면 유인어스에 MVP 범위 문의하기로 문의해 보세요.