중복 레코드 병합 UX: 남길 값과 연결 데이터를 미리 보여 주기

레코드 병합 화면에서는 실행하기 전에 결과를 예측할 수 있어야 합니다. 어떤 값을 남기는지, 연결된 업무 데이터는 어떻게 처리되는지, 되돌릴 수 있는지를 보여 주세요. 이름이 비슷한 두 레코드는 검토할 이유가 될 뿐, 같은 사람이나 조직이라는 증거는 아닙니다.

이 가이드에서는 운영팀이 사용하는 공급업체 레코드 병합 화면을 설계합니다. 작업에 들어가기 전의 행과 선택 컨트롤은 데이터 테이블 컴포넌트 가이드에서 다룹니다. 여기서는 두 레코드를 선택한 다음의 결정에 집중합니다. 합친 레코드에는 정확히 어떤 정보가 들어가야 할까요?

같은 업체인지, 어떤 값을 쓸지, 연결된 업무는 어떻게 할지 나누어 판단하기

구매 시스템에 Northstar Studio 레코드가 두 개 있다고 해 보겠습니다. SUP-104에는 예전 청구 이메일과 발주서 3건이, SUP-218에는 새로운 청구 이메일과 발주서 2건이 연결되어 있습니다. 이 중 발주서 1건은 두 레코드에 모두 연결되어 있습니다. 회사명이 같아서 검토 대상이 되었지만, 등록 주소가 다르다면 실제로는 별개의 사업체일 수도 있습니다.

화면은 세 가지 질문에 답해야 합니다. 두 레코드를 합쳐도 되는가, 충돌하는 값 중 무엇을 최종 값으로 쓸 것인가, 발주서·메모·파일·참조는 어떻게 되는가입니다. ‘가장 최근 레코드 유지’라는 지시 하나로 처리하면 서로 다른 세 결정을 한 가지 기본값 뒤에 숨기게 됩니다.

이름 옆에 안정적으로 식별할 수 있는 레코드 ID와 잘못된 일치를 알아챌 만큼의 정보를 보여 주세요. 확인된 도메인, 거래처 번호, 알려진 사무실 주소가 아바타 하나를 더 넣는 것보다 유용할 수 있습니다. 중요한 정보의 출처와 마지막 확인 시점을 표시하세요. 어제 바뀐 것이 태그뿐이라면 ‘어제 업데이트됨’은 정보가 정확하다는 근거로 약합니다.

병합하지 않고 나갈 수 있는 경로도 분명해야 합니다. 중복 후보를 제안하는 흐름에서 ‘같은 공급업체가 아님’과 ‘나중에 검토’는 다른 결과입니다. 전자는 두 레코드의 관계를 부정하고, 후자는 판단을 보류합니다. 어느 동작도 레코드를 조용히 삭제하거나 관련 없는 제안까지 없애서는 안 됩니다.

기본 선택을 보여 주되 검증된 값처럼 보이게 하지 않기

기본값은 수고를 줄이지만 그 이유를 설명할 수 있어야 합니다. 구매 시스템에 연결된 레코드를 우선하면서 청구 담당 연락처는 다른 레코드에서 가져올 수도 있습니다. 우선하는 출처를 명확히 표시하고, 선택된 각 값을 결과 열에 보여 주세요. 왼쪽에서 오른쪽으로 향하는 화살표만으로 어느 값이 남는지 설명하려고 하지 마세요.

실제 제품의 규칙도 서로 다릅니다. HubSpot의 병합 문서는 남길 속성값 검토, 연결 관계 통합, 병합 취소 불가를 설명합니다. Attio의 문서에서는 충돌하는 데이터에 오른쪽 레코드의 값을 우선하며, 병합 결과에 새로운 레코드 ID가 생깁니다. ‘기본 레코드’라는 말이 어디서나 같은 뜻이라고 가정하지 말고, 지금 설계하는 제품의 규칙을 화면에 밝혀야 합니다.

특히 우선하는 값의 출처와 병합 결과 레코드의 식별자를 구분하세요. SUP-104의 이름과 이메일을 남긴다고 해서 결과 ID까지 SUP-104가 된다는 뜻은 아닙니다. 새 ID를 만드는 시스템이라면 그 결과를 알려 주세요. 기존 링크가 병합 결과로 연결되는지도 개발팀이 확인한 실제 동작에 한해서 설명해야 합니다.

필드별로 충돌 비교하기

데스크톱에서는 필드 수가 감당할 만할 때 출처 A, 출처 B, 선택한 결과의 세 열을 비교하기 좋습니다. 각 행에 필드 라벨을 붙이고, 차이는 색뿐 아니라 텍스트나 아이콘으로도 표시하세요. 선택된 값과 단순히 선택 가능한 값은 눈에 띄게 구분되어야 합니다.

선택한 값 옆에는 출처 ID를 유지하세요. 검토자가 원본 레코드를 다시 열지 않고도 결과의 근거를 따라갈 수 있어야 합니다.

항목이 많은 레코드에는 ‘차이만 보기’를 제공하되 ‘모든 필드 보기’도 남겨 두세요. 두 곳의 값이 같아도 틀릴 수 있고, 승인 전에 전체를 보려는 사용자도 있습니다. 미해결 충돌이 여러 개라면 실행 버튼 근처에 ‘결제 기한과 청구 이메일을 선택해 주세요’처럼 항목을 알려 주세요. 설명 없이 버튼만 비활성화하면 해결 경로를 알 수 없습니다.

모든 빈칸을 같은 뜻으로 다루지 마세요. ‘아직 기록하지 않음’, ‘의도적으로 지움’, ‘볼 권한 없음’은 다른 처리가 필요할 수 있습니다. 접근할 수 없는 값을 빈 필드로 표시하면 사용자가 안심하고 덮어쓸 수 있다고 오해합니다. 보호된 필드 때문에 안전하게 병합할 수 없다면 값을 노출하지 않으면서 누가 검토할 수 있는지 설명하세요.

연결 항목을 단순 합산하지 말고 결과를 미리 보여 주기

두 레코드를 합치면 비교표의 필드 외에도 영향이 생깁니다. 발주서는 내부 ID로 공급업체를 참조할 수 있습니다. 파일명이 같아도 서로 다른 문서일 수 있고, 메모의 작성자와 날짜는 원래 메모에 계속 연결되어야 합니다.

예제 결과에는 발주서가 5건이 아니라 4건 남습니다. 실제 연결 항목이나 펼쳐 볼 수 있는 의미 있는 요약을 보여 주고, 양쪽에 있던 발주서도 확인할 수 있게 하세요. 일부 관계를 중복 제거하거나 권한에 따라 제한하거나 별도로 처리한다면 ‘모든 데이터가 보존됩니다’라고 일괄 안내하지 마세요.

예외는 필요한 지점에서 설명합니다. 외부 연동 때문에 병합할 수 없는 레코드라면 사용자가 다른 필드 열두 개를 정리하기 전에 알려 주세요. 옮길 수 없는 첨부파일이 있다면 파일과 해결 경로를 명시합니다. 작업 전체를 막는 규칙과 사용자가 의도적으로 제외할 수 있는 선택 항목을 구분해야 합니다.

정책에 민감한 필드에는 단순한 우선순위를 적용하지 마세요. 구독 동의, 접근 권한, 확인된 신원 속성은 제품에서 승인한 규칙을 따라야 합니다. 시간이 더 최근이거나 값이 비어 있지 않다는 이유만으로 그 출처가 자동으로 우선권을 갖지는 않습니다.

병합의 영향을 확인한 뒤 실제 처리 결과 보여 주기

유용한 확인 화면은 방금 내린 결정을 요약합니다. ‘공급업체 레코드 2개를 하나로 병합합니다’와 함께 선택한 청구 이메일, 결과 발주서 수, 되돌릴 수 없는 영향을 보여 주세요. 비교 화면에 이미 이 정보가 명확하다면 일반적인 ‘정말 진행할까요?’ 대화상자를 추가할 이유는 적습니다. 결과를 살펴보기 쉬운 곳에 최종 실행 동작을 두세요.

버튼은 ‘공급업체 레코드 병합’처럼 작업 이름을 나타내야 합니다. ‘취소’나 ‘레코드 목록으로’도 혼동되지 않게 하세요. 관련 값, 연결 관계, 후속 영향을 실제로 복구할 수 없다면 ‘실행 취소’를 제공해서는 안 됩니다. 감사 이벤트를 저장하는 것은 변경의 근거를 남기는 일이며 복구 수단은 아닙니다.

제출한 뒤에도 처리 중과 완료를 구분하세요. ‘병합 요청됨’이 ‘병합 완료’처럼 보여서는 안 됩니다. 백그라운드에서 계속 처리한다면 상태를 다시 확인할 수 있는 고정된 위치를 제공하고 돌아갈 곳을 알려 주세요. 첫 응답이 느리다는 이유로 같은 병합을 다시 요청하지 않도록 합니다.

연결 실패로 처리 결과를 모를 수도 있습니다. 이때는 아무것도 바뀌지 않았다고 단정하지 말고 작업 상태를 확인하게 하세요. 검증 실패가 확인된 경우는 다릅니다. 병합을 막은 필드나 연결 관계를 구체적으로 보여 주고, 사용자의 선택은 유지한 채 수정하게 합니다.

동시에 다른 사람이 수정하는 상황도 준비하세요. 검토 화면이 열린 동안 동료가 청구 이메일을 바꿨다고 해 보겠습니다. 실행 전에 미리보기에 사용한 데이터와 현재 레코드를 비교해야 합니다. 바뀌었다면 해당 필드와 그 영향을 다시 검토하게 하세요. 오래된 미리보기를 조용히 적용하면 사용자가 꼼꼼하게 비교한 의미가 사라집니다.

완료 후에는 결과 레코드를 열거나 링크를 제공하고, 두 원본이 어떻게 처리되었는지 밝히며 읽을 수 있는 변경 이력을 남기세요. 감사 로그 UI 설계 가이드에서는 작업자, 작업, 영향받은 레코드와 결과를 로딩 오류와 혼동하지 않고 보여 주는 방법을 다룹니다.

작은 화면과 키보드에서도 비교할 수 있게 만들기

휴대전화 화면에 데스크톱의 세 열을 억지로 넣으면 긴 값을 비교하기 어렵습니다. 필드마다 이름, SUP-104의 값, SUP-218의 값, 선택한 결과를 세로로 묶으세요. 각 선택 위치에 짧은 레코드 ID를 반복해, 화면 밖으로 사라진 열 머리글을 기억하지 않아도 되게 합니다.

남길 값이 하나라면 그에 맞는 선택 컨트롤을 사용하고, 라벨에 필드와 출처를 포함하세요. 클릭할 수 있는 색상 셀만으로는 부족합니다. 여러 값을 합칠 수 있는 행이라면 단일 선택처럼 보이게 하지 말고 그 규칙이 다름을 명시합니다.

키보드 포커스가 보여야 하며 미리보기가 갱신되어도 유지되어야 합니다. 선택할 때마다 결과 열로 포커스를 옮기지 않고 갱신 내용을 전달하세요. 제출 시 미해결 충돌을 발견했다면 관련 컨트롤로 이동할 수 있는 오류 요약을 제공합니다. 보조 기술로 구현된 컨트롤을 시험해야 합니다. 디자인 파일은 동작을 설명할 수 있지만 모양만으로 접근성을 확인할 수는 없습니다.

Pixso에서 화면을 다듬기 전에 결정 흐름부터 만들기

Pixso 디자인 파일에 두 공급업체 레코드와 결과 미리보기를 먼저 배치하세요. 결제 기한 충돌과 공통 발주서를 포함해 예제의 실제 값을 사용합니다. 재사용 가능한 비교 행을 하나 만든 다음 다른 필드에도 인스턴스를 적용하면 간격과 선택 표시를 일관되게 유지할 수 있습니다.

처음 검토하는 상태, 청구 이메일 선택을 바꾼 상태, 미해결 충돌, 처리 중, 결과를 아직 알 수 없는 상태, 동료가 원본을 수정한 상태, 완료된 레코드를 각각 프레임으로 만드세요. 관련 클릭 경로를 프로토타입으로 연결합니다. 검토자가 사용자의 결정을 따라가게 하는 것이 목적이며, 데이터 조정과 실제 병합 서비스는 구현된 애플리케이션이 담당합니다.

동료에게 ‘확인된 SUP-218 청구 이메일을 남기고, 기존 거래처 담당자를 유지하며, 발주서가 몇 건 남는지 알아보세요’라는 구체적인 과제를 주세요. 무엇을 찾아보는지, 최종 버튼을 누르기 전에 결과를 설명할 수 있는지 관찰합니다. 설명하지 못한다면 경고를 하나 더 넣기보다 비교 방식이나 영향 설명을 개선하세요.

개발 전달 때는 필드 우선순위를 관련 행 옆에 적고, 처리 중·실패·동시 변경 동작은 해당 프레임 옆에 둡니다. 애플리케이션이 지원하는 복구 동작과 연결 레코드를 갱신하는 규칙도 포함하세요.

Pixso에서 레코드 비교 화면을 설계해 보세요.