조회 기준값이 중복될 때 어떤 값을 가져와야 할까
VLOOKUP이나 XLOOKUP에서 기준값이 중복되면 첫 번째 값만 가져오거나 예상과 다른 결과가 나올 수 있습니다. 중복 키가 있는 기준표를 다루는 방법을 정리했습니다.
핵심 요약
- 조회 기준값은 가능하면 한 번만 등장하는 고유 키여야 합니다.
- 중복 키가 있다면 첫 번째 값, 최신 값, 합계 값 중 무엇을 가져올지 업무 기준을 정해야 합니다.
- 중복을 무시하고 조회하면 일부 행만 조용히 잘못 붙을 수 있습니다.
이런 상황에 읽어보세요
- 상품코드나 고객ID가 기준표에 여러 번 나오는 문제를 겪는 사람
- 최신 가격, 최근 상태, 누적 금액 중 무엇을 가져와야 할지 정해야 하는 사람
- 조회 함수 결과가 맞는지 검수해야 하는 사람
조회 기준표는 고유 키인지 먼저 확인합니다
조회 함수는 기준값이 하나만 있다는 전제에서 가장 안전합니다. 기준표에 같은 상품코드가 여러 번 있으면 어떤 행의 값을 가져와야 하는지 모호해집니다.
VLOOKUP은 보통 첫 번째로 만난 값을 반환합니다. 이것이 업무상 맞는 값일 수도 있지만, 최신 가격이나 최근 상태가 필요하다면 틀린 결과가 됩니다.
중복 키는 제거가 아니라 해석이 먼저입니다
기준값이 중복된다고 바로 중복 제거를 실행하면 중요한 이력이 사라질 수 있습니다. 가격 변경 이력, 상태 변경 이력, 여러 주문 내역은 중복이 아니라 정상적인 기록일 수 있습니다.
먼저 가져와야 할 값이 최신 값인지, 최초 값인지, 합계인지, 건수인지 정해야 합니다. 그 기준에 맞게 정렬, 집계, 필터링을 한 뒤 조회해야 합니다.
보조 기준을 결합해 고유 키를 만들 수 있습니다
상품코드만으로는 중복이지만 상품코드와 날짜, 상품코드와 지역을 결합하면 고유해지는 경우가 있습니다. 이런 경우 보조 열로 결합 키를 만들어 조회 기준으로 삼을 수 있습니다.
단 결합 키를 만들 때 구분자를 넣어야 합니다. `A12`+`3`과 `A1`+`23`이 같은 문자열이 되지 않도록 `A12|3`처럼 구분자를 두는 편이 안전합니다.
예시로 보면 더 빨라요
| 중복 상황 | 가져올 값 기준 | 처리 방식 |
|---|---|---|
| 상품 가격 이력 | 최신 가격 | 날짜 내림차순 후 조회 |
| 고객 주문 여러 건 | 주문 합계 | 피벗 또는 SUMIFS |
| 지역별 같은 상품 | 상품+지역 | 결합 키 생성 |
| 상태 변경 이력 | 최근 상태 | 최신일 필터 후 조회 |
실무 처리 순서
- 기준표에서 조회 키의 중복 개수를 COUNTIF로 확인합니다.
- 중복이 정상 이력인지 오류인지 판단합니다.
- 가져올 값의 기준을 최신, 최초, 합계, 건수 중에서 정합니다.
- 필요하면 결합 키를 만들어 고유 기준을 만듭니다.
- 조회 결과 샘플을 원본 기준표와 대조합니다.
자주 놓치는 실수
- 중복 키를 확인하지 않고 VLOOKUP 결과를 그대로 믿는 경우
- 이력 데이터에서 중복 제거를 실행해 최신 기준을 잃는 경우
- 결합 키에 구분자를 넣지 않아 서로 다른 조합이 같은 키가 되는 경우
공유 전 체크리스트
정정과 보완 기준
업무 도구와 스프레드시트 기능은 버전과 환경에 따라 다르게 보일 수 있습니다. 예제와 다른 결과가 나오면 사용한 프로그램, 파일 형식, 오류 메시지를 함께 보내주세요.
정정 요청하기함께 보면 좋은 가이드
VLOOKUP이 맞지 않을 때 먼저 확인할 7가지
VLOOKUP 오류는 공식 자체보다 기준값의 공백, 숫자/텍스트 차이, 범위 고정, 근사 일치 옵션에서 자주 생깁니다. 실무에서 빠르게 좁혀보는 점검 순서를 정리했습니다.
XLOOKUP과 VLOOKUP 차이를 업무 예제로 비교하기
XLOOKUP은 VLOOKUP보다 새롭다는 이유만으로 쓰는 함수가 아닙니다. 왼쪽 조회, 열 삽입 안정성, 기본 정확히 일치 동작이 필요한 상황에서 특히 유용합니다.
중복 데이터 제거 전에 기준 열을 정하는 방법
엑셀의 중복 제거 버튼은 빠르지만 기준 열을 잘못 고르면 정상 데이터까지 사라집니다. 고객, 주문, 문의 데이터에서 중복 기준을 안전하게 정하는 법을 설명합니다.
#N/A, #VALUE!, #REF! 오류를 구분해서 고치는 법
엑셀 오류값은 모두 같은 문제가 아닙니다. #N/A는 찾기 실패, #VALUE!는 값 형식 문제, #REF!는 참조 손상일 때가 많으므로 오류 종류별로 대응해야 합니다.