고객 데이터 보강

고객 데이터 보강은 사용이 허가된 출처의 유용한 정보를 기존 고객 기록에 추가하는 작업입니다. 제공된 두 데이터셋에서 시작해 안정적인 고객 식별자로 일치 여부를 확인하고, 충돌하는 값을 검토한 뒤 통합 기록을 승인합니다.

이 가이드는 이미 사용 권한이 있는 정보를 대조하고 조정하는 작업을 다룹니다. 연락처를 스크래핑하거나 데이터를 구매하거나 모델로 누락된 고객 사실을 추론하지 않습니다.

작성: Ai Flowi · 게시일 2026-10-10

구성 예시이며, 기록된 테스트가 아닙니다
카탈로그에 문서화되어 있으나 Ai Flowi가 실운영 환경에서 테스트하지 않았습니다

1. 추가할 수 있는 정보 정의하기

기본 데이터셋과 참조 데이터셋을 선택합니다. 기본 데이터셋은 출력에 포함할 고객 기록을 정하고, 참조 데이터셋은 승인된 추가 필드를 제공합니다. 합의된 계정 분류나 확인된 온보딩 상태를 추가하는 등 각 정보 추가의 목적을 정의합니다. 필드가 많다고 반드시 더 유용한 것은 아닙니다.

조인 전에 필드별 규칙을 작성합니다. 각 필드의 기준 출처, 비어 있는 참조 값이 채워진 기본 값을 대체해도 되는지, 출처 간 값이 다를 때 어떻게 처리할지를 정합니다. 논란이 있는 필드는 양쪽 원래 값을 모두 보존합니다. 병합 작업 자체가 어느 값이 옳은지에 대한 업무상의 결정은 아닙니다.

2. 매칭 키와 출처 사용 권한 확립하기

사용이 허가된 두 내보내기 파일, 작업 공간, 두 출처에서 공유하며 문서화된 고객 식별자가 필요합니다. 제안된 결정론적 대조·조정에는 모델 계정이 필요하지 않습니다. 어느 한 데이터셋이 Google Sheets에서 온다면 별도로 테스트한 연결로 허가된 범위를 읽습니다. 외부 서비스 사용료는 구독에 포함되지 않으며, 해당되는 경우 제공업체가 별도로 청구합니다.

고객 이름 대신 안정적인 식별자를 조인 키로 사용합니다. 이름은 중복되거나 바뀔 수 있고, 비슷한 이름을 연결하면 다른 고객의 정보가 붙을 수 있습니다. 대소문자와 공백 처리 방식을 명확히 정합니다. 앞자리 0을 보존하고 빈 키는 거부합니다. 식별자가 없는 기록을 모두 한 고객으로 취급하지 마세요.

해당 보강 목적에 참조 정보를 사용하는 것이 허가되었는지 확인합니다. 두 내보내기 파일 모두 출처 식별자와 스냅샷 참조를 보존합니다. 사용 권한이나 출처의 관리 주체가 불분명하면 해당 행은 승인된 병합에서 제외하고, 부족한 정보를 검토용으로 기록합니다.

3. 변환 전에 각 데이터셋 검증하기

기본 내보내기와 참조 내보내기에 각각 별도의 Load CSV를 구성합니다. 입력 csv_file에는 해당 파일을 지정합니다. 변환 전에 각 JSON 출력 data_list를 점검합니다. 참조 데이터셋의 오류로 기본 기록이 알리지 않은 채 제거되지 않도록 두 집단을 구분해 유지합니다.

각각의 JSON Operations 단계에서 data를 제공하고, operations 값은 "JQ Expression"로 설정하고, 검증한 query 값을 각 계약에 맞게 사용합니다. 키의 자료형, 필수 헤더, 식별자 중복을 검증합니다. 빈 키, 잘못된 필드 자료형, 서로 모순되는 중복 행에 대한 예외 처리를 준비합니다.

이 설계에서는 각 입력에 고객 식별자마다 승인된 행이 하나씩 있어야 합니다. 반복된 키는 조인 전에 명시적으로 대조하고 조정해야 합니다. "Drop Duplicates"를 적용해 문제를 숨기지 마세요. 반복된 관찰에는 서로 다른 값이 담길 수 있으며, 카탈로그에는 어느 값을 선택할지 결정하는 필드별 기준 출처 정책이 정해져 있지 않습니다.

충돌할 수 있는 필드에는 출처를 접두사로 붙인 서로 다른 열 이름을 준비하되, 조인 키 이름은 일관되게 유지합니다. 이렇게 하면 런타임이 충돌 시 붙일 접미사를 가정할 필요가 없습니다. 최종 승인 필드를 도출하기 전에 각 값의 출처가 결과 표에 드러나야 합니다.

4. 범위를 정한 고객 기록 조인 수행하기

검증한 두 출처의 Table 열을 점검하기 전에 Data → DataFrame 변환 참조 문서를 사용합니다.

가상 대조·조정 예시에서 고객 키 001A의 기본 기록에는 합의된 계정 분류가 있고, 참조 기록에는 빈 분류와 온보딩 상태가 있습니다. 필드 정책에 따라 채워진 기본 분류는 유지하고, 허가된 상태 정보를 추가하며, 각 출처 참조를 보존할 수 있습니다. 키가 1A 인 참조 행은 식별 규칙에서 두 키의 동등성을 명시적으로 확립하지 않는 한 미매칭 상태로 남겨야 합니다. 겉으로 보이는 매칭률을 높이려고 앞자리 0을 제거하면 기록 보강이 아니라 식별 대상의 변경이 되며, 다른 고객의 상태가 붙을 수 있습니다.

Table Operations에서 operation 값은 "Merge"로 설정합니다. 입력 left_dataframe에는 기본 Table을, right_dataframe에는 참조 Table을, merge_on_column에는 검증한 고객 키를 지정하고, merge_how 값은 "left"로 설정합니다. 필수 입력 df에도 기본 Table을 제공합니다. 선택한 작업이 작업 공간에서 어떻게 동작하는지 확인합니다.

왼쪽 조인 정책은 승인된 기본 집단을 유지하면서 키가 일치할 때 참조 열을 추가하려는 것입니다. 매칭되지 않은 기본 기록과 참조에만 있는 기록은 별도로 점검합니다. 중복 키가 있으면 조인된 행 수가 늘어날 수 있으므로, 결과를 승인하기 전에 입력 키의 유일성과 출력 행 수를 대조합니다.

5. 충돌을 숨기지 않고 필드 우선순위 적용하기

검토 가능한 첫 구성에서는 병합한 Table을 Chat Output에 표시하고, 담당 데이터 관리자에게 문서화된 필드 정책을 적용하도록 합니다. 기본 값과 참조 값을 모두 보이게 유지합니다. 결정은 참조 값 승인, 기본 값 유지, 필드 미해결 중 하나일 수 있으며, 이유와 출처 참조를 함께 남깁니다.

나중에 우선순위 적용을 자동화한다면, 점검한 Table을 Type Convert의 input_data를 통해 변환하고, output_type 값은 "JSON"으로 설정합니다. 출력 data_output의 형태를 점검한 뒤 필드 정책에 맞게 JSON Operations의 query를 구성합니다. 이는 제안된 확장이며, 변환 결과가 특정한 레코드 목록의 외부 구조를 가진다는 주장은 아닙니다.

Google Sheets 데이터 대조·조정에서는 출처의 최신성과 기준 출처로서의 권위를 구분해야 합니다. 더 새로운 타임스탬프가 항상 올바른 우선순위 규칙은 아닙니다. 한 출처는 확인된 계정 기록이고 다른 출처는 검토되지 않은 제출 정보일 수 있습니다. 해당 필드에 대해 근거를 제시할 수 있는 정책을 사용하고, 감사에 중요하다면 선택되지 않은 값도 보존합니다.

6. 보강된 기록과 예외 점검하기

목표 출력에는 고객 키, 원래 출처 값, 승인된 보강 필드, 매칭 상태, 충돌 상태, 출처 스냅샷, 검토 결정이 포함됩니다. 누락된 참조 정보는 누락된 채로 남아야 합니다. 미해결 필드가 승인된 빈 값이나 모델이 채운 값처럼 보이면 안 됩니다.

승인된 기본 고객 수와 출력에 포함된 고객을 대조한 뒤, 미매칭 행과 충돌 행을 모두 점검합니다. 빈 키, 앞자리 0이 있는 식별자, 대소문자 차이, 중복 참조 키, 빈 참조 값, 서로 모순되는 필드를 테스트합니다. 승인하려면 설명되지 않는 행 수 증가와 다른 고객 정보의 잘못된 연결이 없어야 합니다.

기존 리드 데이터 정리 레시피는 제공된 테스트 범위에서 32개 사례 모두 통과 했다고 보고합니다. 이 레시피는 하나의 요청 안에서 필드를 정규화하고 검증합니다. 해당 결과는 두 출처의 조인, 기준 출처 정책, 충돌 해결을 테스트한 것이 아니므로 원래 레시피의 설정은 연결된 페이지에서 확인하세요.