Read Original
#Backend

"다 됐습니다" 알림, 대체 언제 보내야 맞나

"다 됐습니다" 알림, 대체 언제 보내야 맞나
01

Summary

"처리는 끝났는데 왜 화면은 비어있을까?" 진짜 완료 알림을 쏘는 법

대량 배치 작업의 종착지에서 사용자 경험을 망치지 않는 '진짜 완료 시점' 탐색기

이 아티클은 배치 처리의 물리적 완료와 사용자의 실제 체감 완료(조회 시점) 간의 간극을 좁히기 위한 flex 팀의 치열한 엔지니어링 고민을 담고 있습니다. 단순 건수 카운팅과 시간 기반 추론의 한계를 깨닫고, 불변 식별자와 일반 사용자 권한 기반의 '프로브(Probe)' 방식을 도입하여 알림 신뢰성을 극대화한 여정을 소개합니다.

  • 01물리적 처리 완료 시점과 사용자 조회 가능 시점 간의 시차 인식
  • 02공유 자원인 처리 시각 추론 방식의 한계를 극복하기 위한 불변 식별자 기록 적용
  • 03권한 지름길을 배제한 '특권 없는 일반 사용자' 기준의 API 프로빙 검증 도입
  • 04알림의 영구 보류를 막기 위한 타임아웃 기반 강제 발송 등 예외 처리 설계

RECOMMENDATION

비동기 대용량 데이터 처리 후 사용자에게 실시간 알림을 제공해야 하거나, 백엔드 반영 지연(Replication Lag) 환경에서 정확한 완료 상태를 전파해야 하는 백엔드 엔지니어들에게 적극 추천합니다.

The Problem

대량의 배치 작업 수행 시, 시스템 내부 처리가 완료되었더라도 실제 데이터가 사용자 화면에 조회되기까지의 시차가 존재하여 완료 알림을 받은 사용자가 빈 화면을 보게 되는 현상이 발생했습니다. 또한, 작업 완료 여부를 단순 건수 비교나 공유 자원인 최종 수정 시각을 기준으로 추론하다 보니 동시성 문제로 인해 알림이 오작동했습니다.

The Solution

완료 여부를 단순히 추론하는 대신, 마지막 처리 대상의 불변 식별자를 배치 실행 시점에 기록해 두고 이를 특권이 없는 일반 사용자 권한으로 직접 조회(Probing)하여 실제 노출 여부를 확인하는 방식을 도입했습니다.

The Result

관리자가 직접 대시보드를 확인하여 알림 발송 여부를 판단할 필요가 없어졌으며, 정상 통과, 시간 초과, 대상 분실 등 모든 케이스가 자동화되어 코드 기반으로 종결되고 일관된 사용자 경험을 보장하게 되었습니다.

Trade-off

마지막 기준값 유실에 대비해 다수의 기준점을 유지해야 하고, 일반 사용자 권한 조회 불가능 시 특권 권한으로 회귀해야 하며, 무한 대기를 막기 위한 강제 타임아웃 발송 로직을 추가해야 하는 등 복잡성이 다소 증가했습니다.

03

Key Concepts

Concept · 01

프로빙 (Probing)

시스템의 내부 상태를 단순히 숫자로 세거나 추론하지 않고, 실제 사용자가 이용하는 경로를 통해 데이터를 직접 조회하여 정상 작동 여부를 능동적으로 검증하는 기법입니다.

  • 마지막 배치 결과물의 식별자를 활용해 실제 사용자 조회 API 경로로 데이터의 존재 여부를 직접 확인하는 데 사용되었습니다.
Concept · 02

불변 식별자 기록 (Immutable Identifier Logging)

다른 트랜잭션에 의해 오염될 수 있는 수정 시각 등의 공유 상태 대신, 배치 처리 시점에 확정된 고유하고 변하지 않는 값을 별도로 저장해 두는 방식입니다.

  • 동시성 환경에서 타 프로세스에 의해 업데이트 시각이 덮어씌워져 조기 알림이 나가는 문제를 차단하기 위해 배치 수행 중 마지막 처리 대상의 불변 ID를 고정 기록했습니다.
Concept · 03

최소 권한 기반 가시성 (Least Privilege Visibility)

시스템 관리자나 작성자 등의 우회 경로(특권)를 배제하고, 가장 엄격한 권한 필터가 적용되는 일반 사용자 관점에서 데이터가 실제로 노출되는지 판단하는 설계 원칙입니다.

  • 최종 노출 단계를 거치기 전에 관리자 권한으로 검증이 조기 통과되는 문제를 막기 위해, 아무 특권 없는 일반 사용자 자격으로 프로브를 실행하도록 설계했습니다.