고객이 늘자 드롭다운이 멈췄다: SmartNexus Client 검색과 전화번호 표준화

고객이 많아지자 가장 단순한 입력창이 가장 느린 화면이 됐습니다. Client를 고르려고 긴 목록을 열어야 했고, 전화번호는 괄호와 하이픈 때문에 같은 사람을 찾지 못했습니다. 이메일 작성창마다 편집 방식도 달랐습니다. 이번 단계는 기능을 더하기보다 입력과 검색의 기준을 하나로 맞추는 작업이었습니다.

SmartNexus 개발일지 ⑨ · 2026년 9월 8일 · 약 6분

드롭다운은 데이터가 적을 때만 편했다

Client가 수십 명일 때는 목록을 열어 이름을 선택하는 방식이 간단했습니다. 수백 명이 되면 화면을 열 때 전체 Client를 먼저 가져와야 하고, 같은 이름을 이메일이나 전화번호 없이 구분하기 어려웠습니다. Event 작성, 이메일 연결과 Follow-up마다 비슷한 드롭다운이 반복되면서 첫 화면 속도도 함께 느려졌습니다.

검색창에 이름, 이메일 또는 전화번호 일부를 입력하면 서버가 작은 후보 묶음만 돌려주도록 바꿨습니다. 사용자가 입력하기 전에는 목록을 요청하지 않고, 연속 입력은 잠시 모아 한 번 검색합니다. 후보에는 이름만이 아니라 구분에 필요한 연락처와 연결 상태를 함께 보여줬습니다.

전화번호는 보이는 형식과 찾는 형식을 나누기

같은 미국 전화번호도 7145551212, 714-555-1212, (714) 555-1212처럼 저장될 수 있습니다. 사용자가 하이픈 없이 검색했는데 DB에는 괄호가 있으면 단순 문자열 비교로는 찾지 못합니다. 중복 Client를 만드는 원인이 되기도 했습니다.

표시는 읽기 좋은 형식을 유지하되 비교와 검색에는 숫자 중심의 정규화 값을 사용했습니다. 국가번호가 있는 경우와 내선번호, 비어 있는 값도 구분했습니다. 기존 데이터를 한 번에 강제 수정하면 위험하므로 새 입력부터 규칙을 적용하고, 운영 권한에 맞춰 기존 데이터 보완을 분리했습니다.

이메일 작성 경험도 한 번만 정의하기

새 메일, 답장과 Broadcast 화면이 각각 다른 편집기를 가지면 서명, 글꼴과 줄바꿈이 조금씩 달라집니다. 수정 하나를 세 화면에 반복해야 하고, 사용자는 같은 이메일 기능인데도 매번 다른 조작을 배워야 합니다.

공통 Rich Text Editor와 설정을 공유하도록 정리했습니다. 수신자도 전체 Client 목록을 내려받는 대신 같은 비동기 검색을 사용했습니다. 답장에서는 기존 Client와 Listing 연결을 유지하고, 새 메일에서도 검색 결과를 선택하면 CRM 맥락이 함께 남도록 했습니다.

검색 결과의 속도보다 정확한 구분이 먼저다

빠르게 후보가 나와도 같은 이름의 고객을 잘못 선택하면 더 큰 문제가 됩니다. 이메일, 전화번호 일부, 관련 Listing처럼 업무에 필요한 식별 정보를 함께 보여줘야 합니다. 개인정보를 과도하게 노출하지 않으면서 선택에 필요한 정보만 표시하는 균형도 필요했습니다.

검색은 ‘찾음’뿐 아니라 ‘새로 만들지 않음’을 돕는다

전화가 온 직후 이름이 정확하지 않으면 새 Client부터 만들기 쉽습니다. 하지만 전화번호 숫자 일부와 이메일 앞부분으로 기존 기록을 찾을 수 있으면 중복 등록을 피할 수 있습니다. 신규 등록 화면에서도 입력 중인 연락처와 유사한 Client를 먼저 제안하도록 발전시킬 수 있는 기반을 이번 검색 구조에서 마련했습니다.

검색 결과는 사용자가 입력한 표현과 달라도 같은 대상을 찾을 수 있어야 했습니다. 대소문자, 공백, 하이픈과 괄호를 정리하되 원본 값을 함부로 덮어쓰지 않았습니다. 검색용 정규화는 비교를 위한 도구이고, 실제 고객이 제공한 연락처 형식은 감사와 수정에 필요한 원본 정보일 수 있기 때문입니다.

공통 편집기에서도 같은 원칙을 적용했습니다. 화면별 초깃값과 서명은 명시적으로 전달하고, 사용자가 선택한 글꼴이나 작성 모드는 공유 설정으로 저장했습니다. 답장 창을 열 때 이전 메시지의 CRM 링크가 먼저 보이게 해 편집 편의와 잘못된 수신자 방지를 하나의 흐름으로 묶었습니다.

검색창은 키보드만으로도 끝까지 사용할 수 있어야 한다

검색형 입력은 마우스로 후보를 누르는 것만 생각하면 금방 만들 수 있지만, 실제 업무에서는 이름을 입력한 뒤 방향키와 Enter로 선택하는 경우가 많습니다. 로딩 중인지, 결과가 없는지, 현재 어떤 후보가 선택됐는지도 화면 읽기 도구가 이해할 수 있어야 했습니다. 입력창과 후보 목록의 관계를 명확히 하고, Esc로 목록을 닫아도 이미 선택한 Client가 사라지지 않도록 상태를 분리했습니다.

서버 검색 결과에도 순서를 정했습니다. 정확히 일치하는 이메일과 전화번호를 먼저 보여주고, 이름 일부가 맞는 후보는 그다음에 배치했습니다. 검색어가 너무 짧을 때는 요청하지 않고 안내 문구를 표시했으며, 결과가 많아도 필요한 수만 내려받았습니다. 속도 개선이 사용자의 판단을 어렵게 만들지 않도록 검색 품질과 화면 반응을 함께 조정한 것입니다.

실무 체크리스트

FAQ

Client가 적어도 검색형 선택이 필요한가요?

초기에는 드롭다운도 충분하지만 데이터가 계속 늘어날 서비스라면 일찍 검색형 구조를 잡는 편이 나중의 화면 교체 비용을 줄입니다.

전화번호는 DB에 숫자만 저장해야 하나요?

원본 또는 표시용 값과 검색용 정규화 값을 함께 관리할 수 있습니다. 국제 번호와 내선 등 의미 있는 정보가 사라지지 않게 해야 합니다.

검색할 때마다 서버를 호출하면 더 느리지 않나요?

입력을 잠시 모으는 debounce, 최소 글자 수와 결과 제한을 함께 사용하면 전체 목록을 매번 내려받는 것보다 효율적입니다.

공통 편집기를 만들면 화면별 기능을 넣기 어렵지 않나요?

공통 핵심 기능과 화면별 옵션을 분리하면 됩니다. 서명과 기본 형식은 공유하고 Broadcast 전용 변수 같은 기능만 선택적으로 켤 수 있습니다.

공식 자료

• PostgreSQL 공식 문서: Indexes
• PostgreSQL 공식 문서: String Functions
• MDN: Accessible Combobox

관련 글

• SmartNexus 버전·Health Check 정리
• 점진적 로딩과 백그라운드 처리
• 이메일을 To-do로 바꾼 과정