Lead가 쌓일수록 일이 안 보인다: SmartNexus 필터·정렬·일괄 처리

Lead와 Listing이 늘자 검색보다 “지금 처리할 것만 남기는 일”이 더 어려워졌습니다. 상태를 바꿀 때마다 상세 화면을 열고, 목록으로 돌아오면 필터가 풀렸습니다. 이번 단계는 많은 데이터를 더 빠르게 보는 것이 아니라 업무 대상을 잃지 않게 정리하는 작업이었습니다.

SmartNexus 개발일지 ⑬ · 2026년 9월 14일 · 약 6분

목록이 길어지면 검색창 하나로는 부족하다

이름을 아는 고객은 검색할 수 있지만 오늘 들어온 New Lead, NDA가 필요한 Lead, 종료된 Listing을 제외한 목록처럼 업무 질문은 여러 조건을 가집니다. 상태 필터, 검색어와 정렬 방향을 함께 사용할 수 있게 했습니다.

현재 사용하지 않는 상태 코드는 필터에서 제외했습니다. 선택지가 많다고 유연한 것이 아니라 실제 행동과 연결되지 않는 값은 판단을 늦춥니다. 과거 데이터는 보존하지만 새 필터와 입력에는 활성 코드만 노출했습니다.

Bulk Action은 편의 기능보다 안전장치가 중요하다

여러 Lead를 선택해 상태를 바꾸면 빠르지만 잘못된 필터에서 실행할 위험도 큽니다. 화면에 현재 조건과 선택 개수를 표시하고, 보이는 전체와 검색 결과 전체를 혼동하지 않도록 했습니다. 실행 대상 ID는 서버에서 다시 검증했습니다.

상태 변경은 허용된 전환만 처리하고 결과를 Activity에 남겼습니다. 일부 항목이 권한이나 현재 상태 때문에 실패하면 전체가 성공한 것처럼 표시하지 않았습니다. 처리 수, 건너뛴 수와 실패 이유를 나눠 다음 조치를 결정할 수 있게 했습니다.

목록으로 돌아왔을 때 조건이 남아 있어야 한다

필터링한 Lead 하나를 수정한 뒤 목록으로 돌아왔는데 전체 목록이 보이면 다음 항목을 찾는 데 다시 시간이 듭니다. 검색어, 상태, 정렬과 현재 tenant 경로를 링크와 폼에 계속 전달했습니다. 부분 목록을 추가로 불러오는 요청에도 같은 조건을 적용했습니다.

URL에 조건이 남으면 새로고침과 뒤로 가기도 예측 가능합니다. 팀원이 같은 목록을 재현하기도 쉽습니다. 다만 사용자별 민감한 검색어를 장기간 저장하는 기능과는 구분하고, 현재 업무 탐색에 필요한 범위만 유지했습니다.

Listing에는 기간 만료라는 별도의 상태가 있었다

Listing은 Active라는 한 단어만으로 충분하지 않았습니다. 계약 또는 마케팅 기간이 끝나가는데 상태가 그대로면 Lead는 계속 연결되고 후속 작업이 잘못될 수 있습니다. 시작일과 만료일을 바탕으로 임박·만료 표시를 추가하고 Home 화면에서 확인할 수 있게 했습니다.

만료가 곧 자동 종료를 뜻하지는 않습니다. 연장 협의나 날짜 수정이 필요할 수 있어 먼저 reminder로 보여주고 사용자가 상태를 결정하도록 했습니다. 자동화가 계약 판단을 대신하지 않게 한 것입니다.

정렬은 데이터가 같을 때까지 정의해야 한다

여러 Lead의 생성 시간이 같거나 Listing 이름이 같은 경우 순서가 요청마다 바뀌면 무한 스크롤에서 항목이 중복되거나 빠질 수 있습니다. 주 정렬값 뒤에 고유 ID 같은 안정적인 보조 기준을 사용했습니다. 화면의 자연스러운 순서와 데이터 요청의 일관성을 함께 맞췄습니다.

필터와 일괄 변경은 AI 기능보다 단순해 보이지만, 이후 AI Report가 만든 후보를 사람이 검토하고 실행하는 기반입니다. 자동 추천이 있어도 최종 대상은 사람이 좁히고 선택해야 하므로 목록 도구의 신뢰성이 먼저 필요했습니다.

대량 작업 뒤에는 선택 상태를 그대로 남기지 않았습니다. 이미 처리한 항목이 다시 선택된 채 다음 검색 결과와 섞이면 두 번째 변경이 일어날 수 있습니다. 결과를 보여준 뒤 선택을 초기화하고, 현재 필터로 목록을 다시 불러와 실제 상태가 반영됐는지 확인했습니다.

모바일에서는 표의 모든 열을 억지로 줄이지 않고 이름, 상태와 다음 행동을 우선했습니다. 추가 정보는 상세 화면에서 확인하도록 하면서도 체크박스와 실행 버튼은 손가락으로 누르기 충분한 크기를 유지했습니다. 같은 기능을 제공하되 화면 크기에 따라 판단 순서를 다르게 배치했습니다.

작업이 끝난 뒤 선택 상태를 비우는 것도 중요했다

일괄 변경 후 체크박스가 그대로 남으면 사용자는 다음 검색 결과에서도 이전 대상이 선택됐다고 오해할 수 있습니다. 성공한 항목은 선택을 해제하고, 실패한 항목만 남겨 다시 확인하게 했습니다. 필터가 바뀌거나 페이지를 이동할 때는 선택 범위를 초기화해 보이지 않는 항목이 다음 작업에 섞이지 않도록 했습니다.

확인 문구에는 단순히 “계속하시겠습니까?” 대신 대상 건수와 바뀔 상태를 넣었습니다. New 12건을 Contacted로 변경하는 것과 같은 구체적인 문장은 마지막 순간의 실수를 줄입니다. 대량 작업일수록 버튼을 한 번 줄이는 것보다 실행 결과를 되돌아볼 단서를 남기는 편이 중요했습니다.

모바일 목록은 열 수보다 우선순위를 줄였다

PC 표를 그대로 좁히면 이름, 상태와 날짜가 모두 잘려 현장에서 쓸 수 없습니다. 모바일에서는 Client와 현재 상태를 먼저 보여주고, 보조 정보는 두 번째 줄이나 펼침 영역으로 옮겼습니다. 체크박스와 상태 버튼은 손가락으로 누를 수 있는 간격을 유지했습니다.

테스트 데이터는 같은 이름과 같은 시각을 일부러 포함하고, 필터를 바꾼 뒤 상세 화면을 열었다가 돌아오는 과정을 반복했습니다. 목록 기능은 처음 화면보다 여러 번 왕복한 뒤에도 대상과 순서가 유지될 때 비로소 업무 도구로 신뢰할 수 있었습니다.

실무 체크리스트

FAQ

필터 조건을 쿠키에 저장해야 하나요?

URL query로 유지하면 새로고침과 공유가 쉽습니다. 개인별 장기 설정이 필요할 때만 별도 저장을 검토할 수 있습니다.

일괄 상태 변경은 모두 성공하거나 모두 실패해야 하나요?

업무 규칙에 따라 다르지만 각 항목 결과를 분명히 보여줘야 합니다. 부분 성공을 숨기면 재처리 과정에서 중복이 생깁니다.

만료일이 되면 Listing을 자동으로 Inactive로 바꿔야 하나요?

계약 연장과 운영 판단이 필요할 수 있어 먼저 알림을 제공하고 사람이 확정하는 방식이 안전합니다.

왜 보조 정렬 기준이 필요한가요?

같은 값이 여러 건일 때 순서를 안정적으로 유지해 페이지나 무한 스크롤의 중복·누락을 막기 위해서입니다.

공식 자료

• PostgreSQL: Sorting Rows
• Microsoft Learn: Model Binding
• W3C WAI: Grid Pattern

관련 글

• Other Lead와 Pacific Time 통합
• 점진적 로딩과 백그라운드 처리
• Client 검색과 전화번호 표준화