이 문제를 한 문장으로 말하면
동일한 사람이나 회사가 여러 서비스에서 다른 이름으로 들어올 때, 같은 대상인지 판단하고 그 결정의 근거를 남기는 일이 식별·매핑이다. MDM(Master Data Management)은 그 결과를 회사가 믿고 쓰는 하나의 기준 정보로 관리하는 운영 체계다.
리멤버 Data Engineer 채용 공고는 명함과 프로필의 핵심 데이터 모델링, 정교한 식별·매핑, MDM을 함께 언급한다. 다만 실제 내부 규칙, 임계값, 검토 조직은 공개된 바가 없다. 이 글은 업무 문제를 이해하기 위한 설계 원칙이며, 리멤버 내부 구현을 재현한 문서가 아니다.
1. 왜 스트링 일치만으로는 부족한가
예를 들어 (주)리멤버앤컴퍼니, 리멤버앤컴퍼니, Remember & Company는 같은 회사일 수 있다. 반대로 이름이 같은 두 사람, 사업자번호가 바뀐 법인, 이직 전후의 프로필은 문자열만 비슷하다고 합치면 안 된다.
오류는 두 가지다.
- false merge: 다른 대상을 하나로 합침. 다른 사람의 경력이 섞이는 것처럼 회복 비용이 크다.
- false split: 같은 대상을 여러 개로 남김. 연결된 프로필과 분석 결과가 분산된다.
매핑 정확도를 높인다는 말은 두 오류 사이의 비용을 조정한다는 뜻이다. 회사와 개인정보의 성격에 따라 false merge를 더 엄격히 막아야 할 수 있다.
2. 실무적인 단계
1) 표준화
공백·하이픈·법인 표기를 정리하고, 전화번호·이메일·주소를 비교 가능한 형식으로 바꾼다. 그러나 원문은 버리지 않는다. 표준화 규칙이 틀렸을 때 다시 확인하려면 원본이 필요하다.
2) 후보 생성
모든 레코드 쌍을 비교하면 데이터가 늘어날수록 비용이 폭발한다. 그래서 같은 이메일 도메인, 전화번호 일부, 지역, 회사명 토큰처럼 비교할 만한 후보만 줄이는 blocking이 필요하다. 이 단계가 너무 엄격하면 false split이 늘고, 너무 넓으면 비용과 오탐이 늘어난다.
3) 매칭과 판정 구간
먼저 신뢰도가 높은 exact rule을 쓴다. 나머지는 이름 유사도 하나만 보지 않고 출처, 시간, 회사, 연락처처럼 독립적인 근거를 함께 본다.
- 높은 확신: 자동 연결
- 중간 구간: 사람이 근거를 보고 판정
- 낮은 확신: 연결하지 않고 보류
AWS Entity Resolution도 rule-based, ML-based matching을 구분하고, 규칙 기반 결과에는 어느 규칙이 매칭을 만들었는지 남긴다. 점수만 남기는 것보다 판정 근거를 추적하기 쉬운 이유다.
3. MDM은 ‘합치기’ 뒤부터가 시작이다
매칭으로 같은 대상임을 알아도 어느 이름과 주소를 최종값으로 보여 줄지는 다른 문제다. 이를 survivorship라고 한다.
- source priority: 공식 원천의 값을 우선한다.
- recency: 더 최근 검증된 값을 쓴다.
- completeness: 더 완전한 값을 선택한다.
- human override: 데이터 소유자의 판정을 버전과 함께 남긴다.
최종 golden record는 값만 있으면 안 된다. 각 컬럼이 어느 원천에서 왔는지(provenance), 어떤 규칙이 선택했는지, 이전 값은 무엇인지를 볼 수 있어야 한다.
4. 잘못 합친 결정을 풀 수 있어야 한다
엔터티 연결을 명사로만 저장하면 회복이 어렵다. record A -[rule v17, evidence]→ cluster C처럼 레코드와 클러스터 사이의 edge를 버전으로 남기면 잘못 합친 클러스터를 나누고 downstream을 다시 만들 수 있다.
이 때 필요한 지표는 전체 accuracy 하나가 아니다.
- 자동 연결 구간의 precision
- 수동 검토 양과 처리 시간
- false merge 풀기 건수와 downstream 재처리 범위
- 출처별·규칙별 false split 표본
- 결정 버전 변경 후 영향받는 클러스터 수
면접에서 확인할 질문
- 어느 근거가 정확히 일치할 때만 자동으로 합칠 것인가?
- false merge와 false split 중 이 도메인에서 더 큰 손실은 무엇인가?
- 애매한 구간을 누가 판정하고, 판정 결과는 어디에 남는가?
- 잘못 합친 레코드를 분리한 후 소비자 데이터를 어떻게 재생성하는가?