CSV 가져오기 UX: 레코드를 바꾸기 전에 열 연결하기

CSV 가져오기 화면은 데이터를 바꾸기 전에 “각 행을 가져오면 어떤 일이 일어나는가?”에 답해야 합니다. 파일 업로드는 첫 단계일 뿐입니다. 원본 열을 어떤 필드에 연결하는지, 식별자가 어느 레코드를 가리키는지, 기존 값은 어떻게 처리하는지, 어떤 행을 처리할 수 없는지까지 보여 줘야 사용자가 실행 여부를 판단할 수 있습니다.

진행률을 100%로 채우는 것보다 이러한 판단을 중심으로 흐름을 설계하세요. 파일 전송에 성공했어도 식별자가 중복되거나 열이 잘못된 필드에 연결될 수 있습니다. 폼 상태와 입력 검증(영문)을 최종 데이터 반영과 구분하면 ‘가져오기 준비 완료’가 ‘가져오기 완료’처럼 보이는 일을 막을 수 있습니다.

실제 판단이 필요한 작은 파일부터 사용하기

가상의 워크숍 참가자 관리 앱을 예로 들어 보겠습니다. 관리자는 새 참가자를 추가하면서 기존 참가자 정보도 업데이트하려고 합니다. 이 앱은 레코드 ID로 기존 데이터를 찾습니다. 이름과 이메일은 화면에서 사람을 확인하는 데 도움이 되지만, 일치 여부를 결정하는 기준은 아닙니다. 참가자마다 이메일과 워크숍 하나가 필요합니다.

파일에는 다음과 같은 데이터 5행이 있습니다. 아래 행 번호에는 머리글을 포함하지 않습니다. P-104와 P-102는 이미 존재하며 P-108과 P-109는 아직 없습니다. P-102의 현재 워크숍은 ‘디자인 시스템’입니다.

이 5행만으로도 새 참가자 생성, 기존 참가자 업데이트, 안전하게 처리할 수 없어 보류하는 경우를 살펴볼 수 있습니다. 문제가 전혀 없는 100행보다 설계에서 결정해야 할 사항이 더 잘 드러납니다.

원본 열과 대상 필드를 나란히 보여 주기

매핑 화면의 각 행에는 원본 열 이름, 대표 값, 대상 필드, 필요한 입력 규칙이 있어야 합니다. 대상 필드 이름만 있는 드롭다운을 보여 주면 사용자가 스프레드시트 내용을 기억해야 합니다. 값을 미리 볼 수 있으면 연결이 맞는지 그 자리에서 확인할 수 있습니다.

워크숍 열이라면 ‘리서치’, ‘프로토타이핑’ 같은 값을 대상 필드 ‘워크숍’ 옆에 표시합니다. 앱이 실제로 워크숍 ID를 저장한다면 이 이름을 어떤 ID와 연결하는지도 설명해야 합니다. 표시 이름이 같은 워크숍이 둘이라면 구분할 정보가 더 필요합니다. 이름이 그럴듯해 보인다는 이유만으로 연결해서는 안 됩니다.

자동으로 제안한 연결은 최종 확인 전까지 수정할 수 있어야 합니다. ‘제안됨’과 ‘확인됨’을 시각적으로 구분하거나 안내 문구로 설명하고, 필수 필드에 연결된 열이 없으면 알려 주세요. 선택 사항인 열에는 ‘이 열은 가져오지 않음’이라는 명확한 선택지를 제공합니다. 아무것도 선택하지 않았다는 이유로 조용히 건너뛰거나 값을 지우거나 새 필드를 만들면 안 됩니다.

HubSpot의 가져오기 문서(영문)는 속성 매핑, 레코드 식별자, 기존 값을 보호하는 옵션을 별도 결정으로 다룹니다. 구체적인 규칙은 해당 제품의 사양이지만, 이러한 결정을 가져오기 버튼 뒤에 숨기지 않고 드러낸다는 점은 참고할 만합니다.

미리보기 전에 처리 방식과 일치 기준 정하기

기존 ID가 들어 있는 파일에는 ‘참가자 가져오기’라는 설명만으로 충분하지 않습니다. 새 레코드만 생성하는지, 기존 레코드만 업데이트하는지, 둘 다 하는지 표시해야 합니다. 선택한 방식에서 식별자가 비어 있거나 등록되지 않은 ID일 때 어떻게 처리하는지도 설명합니다.

이 예시에서는 ‘새 참가자를 생성하고 일치하는 참가자를 업데이트’를 선택합니다. 일치 기준은 레코드 ID입니다. 유효한 새 ID는 레코드를 만들 수 있고, 기존 ID는 해당 레코드를 업데이트할 수 있습니다. 이름만 같다고 해서 어느 쪽으로든 처리하지 않습니다. 이 규칙은 도움말에만 두지 말고 선택지 가까이에 표시합니다.

빈 셀에도 처리 규칙이 필요합니다. 나중에 선택 사항인 ‘메모’ 열이 추가된다면 빈 셀은 기존 메모를 유지할까요, 지울까요, 아니면 오류가 될까요? 이 예시에서는 선택 사항인 셀이 비어 있으면 기존 값을 유지하며, 값을 지우려면 별도의 명시적 작업이 필요합니다. 실수로 지우는 일을 막기 위한 선택이지만 모든 가져오기 기능에 적용되는 보편적인 규칙은 아닙니다. 빈 셀을 삭제로 처리하는 앱이라면 그 결과를 똑같이 분명하게 알려야 합니다.

연결하지 않은 열, 빈 셀, 유효하지 않은 값, 명시적으로 지우려는 값은 구분하세요. 스프레드시트에서는 비슷해 보여도 대상 데이터에 미치는 영향은 다를 수 있습니다.

파일 일부가 아니라 변경 결과를 미리 보여 주기

원본 미리보기는 ‘CSV를 제대로 읽었는가?’에 답합니다. 변경 미리보기는 ‘이대로 실행하면 무엇이 달라지는가?’에 답합니다. 후자에는 예상 처리 결과와, 업데이트라면 달라지는 필드까지 보여 줘야 합니다.

예시 앱은 같은 레코드 ID를 가진 모든 행을 보류하고, 관리자가 중복을 해결하기 전에는 반영하지 않습니다. 첫 번째나 마지막 행을 임의로 우선하지 않습니다. 또한 이 파일의 검증 문제를 모두 해결해야 최종 반영할 수 있도록 설계합니다.

요약은 생성 1행, 업데이트 1행, 확인 필요 3행으로, 원본 5행과 일치합니다. 이를 예상 결과로 명시하세요. 성공을 뜻하는 체크 표시를 하거나 참가자 한 명이 이미 생성됐다고 말해서는 안 됩니다.

‘확인 필요’만 볼 수 있는 필터를 제공하되 파일 전체 행 수와 원본 행 번호를 유지합니다. 일부 행만 미리 보여 준다면 그 사실을 알리고, 준비 완료를 표시하기 전에는 파일 전체를 검증해야 합니다. 첫 페이지에 문제가 없다는 사실이 나머지 행의 정확성까지 보장하지는 않습니다.

Pixso에서 매핑과 변경 결과를 함께 검토하기

Pixso 디자인 파일에 ‘열 연결’과 ‘변경 검토’ 프레임을 만들고 두 화면 모두 같은 참가자 데이터 5행을 사용합니다. 첫 번째 화면에서는 워크숍 값의 예시와 대상 필드를 나란히 놓습니다. 두 번째 화면에는 예상 처리 건수, 확인이 필요한 3행, P-102의 ‘디자인 시스템 → 프로토타이핑’ 변경을 표시합니다.

매핑 컨트롤과 레코드 미리보기는 별도 컴포넌트로 구성합니다. 그러면 매핑을 고쳤을 때의 화면을 전체적으로 다시 만들지 않고도 비교할 수 있습니다. 미리보기 옆에는 해당 3행의 문제가 해결되기 전까지 가져올 수 없다는 주석을 둡니다. 검토자에게 어떤 참가자가 이미 존재하는지, 어떤 값이 바뀌는지, 이미 반영된 변경이 있는지 물어보세요. 말로 보충하지 않아도 화면만 보고 답할 수 있어야 합니다.

Pixso에서 가져오기 미리보기 화면 디자인하기 →

수정 작업을 원래 문제와 연결하기

‘가져오기에 실패했습니다’라는 문구만으로는 관리자가 어디서부터 고쳐야 할지 알 수 없습니다. 조치할 수 있는 오류에는 파일, 원본 행이나 열, 안전하게 공개할 수 있다면 문제의 값, 원인, 다음 작업이 포함돼야 합니다. 식별자 중복과 필수 값 누락을 구별할 수 없는 빨간 경고 하나로 처리하지 마세요.

HubSpot의 오류 안내(영문)는 레코드 ID 중복, 행 내용 중복, 고유 속성 값 중복을 구분합니다. ‘중복’이라는 한 단어로는 서로 다른 처리 결과가 가려질 수 있으므로 오류 이름도 실제 동작과 맞아야 합니다.

참가자 예시에서 관리자가 P-104의 워크숍을 ‘프로토타이핑’으로 결정했다고 가정해 보겠습니다. 원본 1행을 삭제하고 Jo Rivera의 이메일을 입력합니다. 수정된 파일은 4행이므로 미리보기 결과도 다시 계산해야 합니다. 생성 2행, 업데이트 2행이며 확인이 필요한 행은 없습니다. 입력이 달라졌는데도 이전의 전체 5행을 계속 표시하면 안 됩니다.

가져오기 화면 안에서 값을 수정할 수 있다면 원본 파일 자체가 바뀌는지, 이번에 반영할 데이터만 바뀌는지 알려 주세요. 나중에 오류가 생겨도 해당 레코드를 찾을 수 있도록 원본과의 연결을 남깁니다. 파일을 교체할 때는 열 구성이 여전히 일치하는 경우에만 기존 매핑을 유지하고, 다시 확인해야 하는 연결은 표시합니다.

준비 완료, 처리 중, 완료를 구분하기

최종 실행 전에는 파일, 처리 방식, 식별자, 최신 건수, 변경되는 필드를 보여 줍니다. ‘참가자 4명 가져오기’라는 버튼도 그 옆에서 2명 생성과 2명 업데이트를 설명해야 의미가 분명해집니다. 미리보기 이후 기존 레코드가 바뀌었다면 오래된 예상 결과를 그대로 적용하지 말고 다시 검증해야 합니다.

처리 중에는 중복 실행을 막고 가져오기 작업을 식별할 참조 정보를 유지합니다. 응답을 받지 못했다고 곧바로 파일 전체를 다시 제출하게 하지 말고, 원래 작업의 상태를 확인하는 경로를 설계하세요. 이를 뒷받침하는 구현이 필요합니다. 버튼을 비활성화하는 것만으로 중복 처리를 막을 수는 없습니다.

작업이 끝나면 확인된 결과를 알려 줍니다. 일부만 완료될 수 있다면 완료, 건너뜀, 실패를 구분하고 해결되지 않은 레코드만 다시 처리할 수 있게 합니다. 이미 생성에 성공한 레코드까지 반복하도록 안내해서는 안 됩니다. 전체 성공 또는 전체 실패만 가능한 방식이라면 그 동작을 명시하고, 부분 성공용 화면을 그대로 쓰지 마세요.

마지막 화면에서는 관리자가 가져온 레코드를 찾고, 바뀐 내용을 확인하고, 남은 문제를 해결할 수 있어야 합니다. 참가자 데이터와 연결되지 않은 초록색 진행률 표시보다 실제 작업이 끝났는지 판단하는 데 도움이 됩니다.