Unread vs Total Messages: 상태 업데이트가 헷갈리는 이유와 정확한 동작 방식

메일 앱이나 임시 메일(수신 전용) 서비스에서 자주 나오는 질문이 있습니다. “분명 새 메일이 들어왔는데 Unread(읽지 않음) 숫자는 그대로예요.” 혹은 “Total(전체)은 늘었는데 왜 Unread는 안 늘죠?” 같은 혼란입니다.

결론부터 말하면 Unread와 Total은 서로 다른 기준으로 집계되는 값이고, 상태 업데이트(배지/카운트/리스트 갱신)는 동기화 타이밍, 필터, 폴더 기준, 읽음 처리 규칙에 따라 자연스럽게 차이가 발생합니다. 이 글에서는 ‘오류처럼 보이지만 정상인 상황’과 ‘진짜로 수정해야 하는 상황’을 구분할 수 있게, 동작 원리를 단계별로 정리합니다.

1) Unread와 Total은 무엇을 세는가?

Unread(읽지 않음): “현재 읽지 않은 상태”의 메시지 수

Unread는 말 그대로 읽지 않은 상태(flag)로 남아 있는 메시지의 개수입니다. 여기서 중요한 포인트는 “새로 들어온 메일 수”가 아니라, 현재 읽지 않음으로 표시된 상태의 누적 개수라는 점입니다.

• 메일을 열어보면 Unread는 줄어듭니다(읽음 처리).
• 자동으로 ‘읽음’ 처리되는 규칙이 있으면, 새로 온 메일이어도 Unread가 늘지 않을 수 있습니다.
• 필터(예: 스팸/프로모션 제외, 특정 폴더 제외)가 걸려 있으면 Unread가 다르게 보일 수 있습니다.

Total(전체): “현재 범위에 포함되는 메시지 총량”

Total은 선택된 범위(예: 받은편지함/전체 메일함/특정 주소의 수신함)에 존재하는 메시지의 총 개수입니다. 보통 “읽음+읽지 않음”을 모두 포함하고, 시스템에 따라 “보관/아카이브/스팸/휴지통을 포함하느냐”가 달라집니다.

• 새 메일이 들어오면 Total은 거의 항상 증가합니다.
• 하지만 일부 메시지가 다른 폴더로 자동 분류되면(스팸/프로모션) Total 범위에서 제외될 수 있습니다.
• 동일한 메일이 스레드로 묶이는 경우 “메시지 수”와 “스레드 수”가 달라 보일 수 있습니다.

2) “상태 업데이트(Status Updates)”는 보통 어떤 파이프라인으로 움직이나?

앱이 Unread/Total을 보여주는 과정은 생각보다 단순하지 않습니다. 대부분의 서비스는 성능과 배터리를 위해 ‘매번 서버에서 실시간 계산’하지 않고, 이벤트 기반 + 주기 동기화 + 캐시 조합으로 상태를 관리합니다.

(1) 수신 이벤트 감지

새 메일이 도착하면 서버는 “새 메시지 도착” 이벤트를 만들고, 앱은 푸시 또는 폴링으로 이를 감지합니다. 이때 앱이 즉시 전체 목록을 다시 받지 않고, 요약 정보(요약 카운트/최신 1~N개 헤더)만 먼저 받는 설계가 흔합니다.

(2) 카운트(배지/상단 숫자) 선반영

사용자 경험상 “새 메일이 왔다는 느낌”이 중요하기 때문에, 일부 시스템은 Total만 먼저 증가시키거나, 반대로 Unread만 임시로 증가시키고 나중에 정확한 값으로 재조정하기도 합니다. 그래서 잠깐 “숫자가 튀는” 현상이 발생할 수 있습니다.

(3) 리스트 동기화(페이지네이션/증분 로딩)

실제 메시지 리스트는 보통 페이지네이션으로 가져옵니다. 이 과정에서 “최신 몇 개만 갱신”하고 나머지는 다음 스크롤 때 불러오므로, Total은 늘었는데 리스트에는 아직 새 메일이 안 보이는 상황도 생깁니다.

(4) 읽음 상태 동기화(로컬 ↔ 서버)

사용자가 메일을 열면 로컬에서 즉시 읽음 처리하고, 서버에 읽음 상태를 업데이트합니다. 그런데 네트워크가 느리거나, 서버 반영이 늦으면 Unread가 줄어든 것처럼 보였다가 다시 늘어나는 역전도 가능합니다. 반대로 서버 쪽에서 이미 읽음 처리된 메일이 뒤늦게 동기화되면 Unread가 갑자기 줄 수도 있습니다.

3) “Total은 늘었는데 Unread가 안 늘어”는 어떤 경우에 정상일까?

케이스 A: 자동 읽음 처리 규칙이 있는 경우

어떤 서비스는 특정 유형의 메시지를 “자동 읽음” 처리합니다. 예를 들어 시스템 알림, 구독 안내, 중복 인증 메일, 혹은 특정 헤더(자동 응답 등)가 붙은 메일이 이에 해당할 수 있습니다. 이런 메일은 새로 도착해도 Total은 늘지만, Unread는 늘지 않을 수 있습니다.

케이스 B: 필터/폴더 범위가 다를 때

화면에 보이는 Total이 “전체 메일함 기준”인데, Unread는 “받은편지함 기준”으로 표시되는 UI도 있습니다. 또는 스팸/프로모션이 자동으로 분류되어 Total에는 포함되지만, Unread는 현재 탭(예: Primary)에서는 제외될 수 있습니다.

케이스 C: 스레드(대화) 단위로 집계할 때

어떤 앱은 “메시지 개수”가 아니라 “스레드 개수”로 Unread를 보여줍니다. 예를 들어 같은 발신자/제목으로 묶인 대화 스레드에 새 메일이 3개 들어와도, Unread는 “스레드 1개”로만 증가할 수 있습니다.

케이스 D: 동기화 지연(정확한 Unread가 뒤늦게 계산)

새 메일을 먼저 헤더만 받아오고, 읽음/중요/분류 같은 메타데이터는 다음 동기화에서 받는 구조라면 Total은 즉시 늘고 Unread는 조금 뒤에 늘어나는 것처럼 보일 수 있습니다. 특히 모바일 환경에서 흔합니다.

4) 반대로 “Unread는 늘었는데 Total이 안 늘어”는 왜 생길까?

일반적으론 Total이 먼저 늘기 쉬운데, 특정 설계에서는 반대로 보이기도 합니다.

• 캐시된 Total: 상단 Total은 캐시를 쓰고, Unread는 이벤트 기반으로 실시간 반영하는 경우
• 페이지네이션: Total은 “현재 로드된 페이지 개수”만 세고, Unread는 서버 요약값을 쓰는 경우
• 중복 제거: Total 계산 시 중복 메시지를 합치지만, Unread는 플래그 기준으로 남아 있는 경우

즉, 두 숫자가 같은 데이터 원천을 보지 않을 수 있습니다. 하나는 서버 집계, 하나는 로컬 캐시, 하나는 현재 화면 범위 같은 식으로 서로 다른 기준을 쓰면 사용자 입장에서는 “왜 이래?”가 됩니다.

5) “정상”과 “이상”을 구분하는 체크리스트

정상일 가능성이 높은 신호

• 잠깐 숫자가 어긋났다 몇 초~몇 분 내에 자연스럽게 맞춰진다
• 필터/탭을 바꾸면(예: 전체/받은편지함/스팸) 숫자가 일관된 방식으로 변한다
• 앱을 새로고침하거나 재진입하면 정상화된다(캐시 리프레시)

이상일 가능성이 높은 신호

• 특정 메시지를 열어도 Unread가 절대 줄지 않는다
• 새 메일이 확실히 들어오는데 Total이 수 시간 동안 변하지 않는다
• 같은 메시지가 반복해서 다시 나타난다(중복/동기화 충돌)
• 로그아웃/재로그인 후에도 카운트가 비정상적으로 고정된다

위 ‘이상 신호’가 보이면, 단순 UI 문제가 아니라 읽음 상태 업데이트 API 실패, 동기화 토큰 불일치, 캐시 파손 같은 구조적 문제일 수 있습니다.

6) 개발/운영 관점에서 자주 쓰는 집계 규칙(개념 정리)

서비스에서 Unread/Total을 정의할 때는 보통 다음 중 하나를 선택합니다. 같은 “Unread”라도 정의가 달라지면 결과가 달라져요.

• Message-based: 메시지 단위로 읽음/전체 카운트
• Thread-based: 스레드(대화) 단위로 읽음/전체 카운트
• Folder-based: 특정 폴더(받은편지함)만 집계
• Account-based: 계정 전체(아카이브/스팸 포함 여부는 별도 규칙) 집계

운영상 가장 흔한 혼선은 “UI 문구는 Unread/Total인데, 실제로는 스레드 기반이거나 특정 폴더 기준”인 경우입니다. 사용자에게 혼란을 줄이려면 UI에 범위를 명시하거나, 설정에서 집계 기준을 선택 가능하게 제공하는 방식이 효과적입니다.

7) 사용자 입장에서 헷갈림을 줄이는 사용 팁

• 현재 탭/폴더 기준이 무엇인지 확인: 전체인지, 받은편지함인지, Primary인지
• 새로고침을 한 번 해보기: 목록 동기화가 늦는 구조라면 즉시 맞춰질 수 있음
• 정렬/필터를 바꿔보기: “안 보이는 새 메일”이 사실 다른 분류로 들어갔을 수 있음
• 읽음 처리가 적용됐는지 확인: 미리보기만으로 읽음 처리되는 설정이 있을 수 있음
• 시간차를 인정하기: 모바일은 배터리 최적화로 동기화가 즉시 일어나지 않을 수 있음

8) 결론: Unread는 ‘상태’, Total은 ‘범위의 총량’이다

Unread는 “안 읽은 상태로 남아 있는 것”을 세고, Total은 “현재 범위에 속한 전체 메시지의 총량”을 셉니다. 그래서 새 메일이 들어오더라도 자동 읽음, 필터, 폴더 분류, 스레드 집계, 캐시/동기화 타이밍에 따라 두 숫자는 쉽게 어긋나 보일 수 있습니다.

만약 숫자가 잠깐 달라졌다가 정상화된다면 대부분 정상 동작입니다. 하지만 읽음 처리나 새로고침을 해도 장시간 고정되거나, 중복/역전 현상이 반복된다면 동기화 로직(토큰/캐시/상태 업데이트)을 점검해야 합니다. 이 차이를 알고 나면, “숫자가 이상하다”는 느낌보다 “어떤 기준으로 세고 있지?”가 먼저 보이기 시작할 겁니다.