'미검증' 배지, 프런트 단일 소스로 관리한 이유
실시간 리서치 대시보드에서 화면마다 어긋나던 '미검증' 배지를 유틸 1개와 컴포넌트 1개로 모은 과정과 이유를 정리했어요.
화면마다 배지가 다르게 뜨던 날
실시간 리서치 대시보드를 만들면서 '미검증' 배지를 붙이기 시작했어요. 출처 확인이 끝나지 않은 자료를 표시하는 작은 회색 배지예요.
처음엔 각 화면이 알아서 판단하게 뒀어요. 목록, 상세, 요약 카드, 알림, 검색 결과까지 배지를 그리는 곳이 5곳이었죠. 그런데 돌려 보니 같은 자료가 목록에선 미검증인데 상세에선 멀쩡하게 보이는 일이 생겼어요. 화면마다 기준이 조금씩 달랐던 거예요. 어떤 곳은 출처 링크가 없으면 미검증, 어떤 곳은 검증 시각이 비어 있으면 미검증으로 처리하고 있었어요.
판단은 한곳, 렌더링도 한곳
그래서 구조를 바꿨어요. 판별 로직은 유틸 함수 1개로, 화면 표시는 배지 컴포넌트 1개로 모았어요.
직접 만들어 보니 지킬 규칙이 자연스럽게 정리됐어요. 우선 상태를 verified, unverified, pending 3가지로 고정하고, 여기 매칭되지 않는 값은 전부 미검증 쪽으로 떨어뜨렸어요. 서버가 새 상태값을 추가해도 화면이 검증된 것처럼 보여주는 사고는 안 나요.
파생값 계산도 중요했어요. 서버가 준 값을 스토어에 참·거짓으로 저장해 두면 실시간 업데이트가 올 때 어긋나기 쉬워요. 저장하지 않고 렌더링 시점에 원본 데이터에서 매번 계산하게 했어요.
마지막 규칙은 배지 컴포넌트 밖에서 배지 모양을 못 만들게 하는 거예요. 색이나 문구를 개별 화면에서 흉내 내기 시작하면 단일 소스가 무너져요.
- 상태 3가지 고정
- 저장 대신 파생 계산
- 배지 렌더링 창구 단일화
바꾸고 나서 달라진 것
적용해 봤더니 검증 기준이 바뀌었을 때 고치는 파일이 1개가 됐어요. 실제로 기준을 한 번 조정했는데 10분 정도 걸렸고, 화면 5곳에 동시에 반영됐어요. 테스트해 보면 유틸 함수 하나만 검사하면 되니 케이스 짜기도 수월했고요.
법령·판례 검색 서비스인 플랜엘(plan-l)을 만들 때도 같은 원칙을 지키고 있어요. 국가법령정보센터와 대법원 데이터처럼 출처가 분명한 자료를 다루다 보니, 반대로 확실하지 않은 건 확실하지 않다고 보여주는 게 신뢰의 시작이라고 느꼈거든요.
미검증 배지는 장식이 아니라 데이터 신뢰도를 화면에 전하는 계약이에요. 계약서는 한 부만 두는 게 관리하기 편해요. 흩어진 조건문이 보인다면, 한곳으로 모으는 일부터 해보세요.
관련 글
댓글
아직 댓글이 없어요. 첫 댓글을 남겨주세요.