수식 문법이 맞아 보이는데 #VALUE!가 반복된다면, 지금 의심하는 원인이 틀렸을 가능성이 높다. 엑셀 브이룩업 VALUE 오류 원인은 열 번호 인수 오류·찾을 값 255자 초과·네 번째 인수 형식 오류, 이 세 가지뿐이다. 데이터 형식 불일치를 의심하며 셀 서식을 바꾸거나 텍스트 나누기를 돌리는 건 시간 낭비다. 그 작업은 #N/A 오류에 필요한 것이지, #VALUE!와는 무관하다.
#VALUE!와 #N/A는 전혀 다른 신호다
엑셀 오류 메시지는 계층이 다르다. #VALUE!는 수식에 전달된 인수 자체에 문제가 있다는 뜻이다. 연산을 시작조차 할 수 없을 때 수식 엔진이 돌려보내는 메시지다. 반면 #N/A는 연산은 정상적으로 시작됐지만 찾는 값이 범위 안에 없을 때 발생한다.
흔한 오해가 있다. 숫자처럼 보이는 텍스트(셀 왼쪽 정렬로 붙어 있는 숫자)로 인해 VLOOKUP이 실패하면 #VALUE!가 뜰 것 같지만, 실제 결과는 #N/A다. 이 둘을 혼동하면 데이터 정제에 한 시간을 쓰고도 오류가 사라지지 않는 상황이 생긴다. 오류 유형 구분이 먼저다.
원인 ① 열 번호(col_index_num)가 0 이하이거나 텍스트
세 번째 인수 col_index_num은 1 이상의 정수여야 한다. 0이나 음수를 넣으면 즉시 #VALUE!가 반환된다. 직접 숫자를 입력할 때는 잘 생기지 않는 실수지만, 다른 셀의 값을 열 번호로 참조할 때는 의외로 자주 발생한다.
=VLOOKUP(A2, B:D, 0, FALSE)→ #VALUE! (0은 유효하지 않음)=VLOOKUP(A2, B:D, -2, FALSE)→ #VALUE! (음수 불가)=VLOOKUP(A2, B:D, "3", FALSE)→ 버전에 따라 #VALUE! 또는 정상
셀 참조로 열 번호를 가져올 때 해당 셀이 텍스트 형식의 숫자라면 버전에 따라 #VALUE!로 이어질 수 있다. 이럴 때는 =VLOOKUP(A2, B:D, VALUE(F1), FALSE)처럼 VALUE() 함수로 강제 변환하거나, 수식에 직접 숫자를 입력해 테스트해 원인을 좁힌다. 참조 셀 탓인지 수식 자체 탓인지를 먼저 분리해야 한다.
원인 ② 찾을 값(lookup_value)이 255자를 넘긴 경우
VLOOKUP의 첫 번째 인수 lookup_value는 최대 255자까지만 지원한다. 이 제한은 오래된 스펙이고 현재까지 변경되지 않았다. 255자를 초과하는 순간 이유를 설명하지 않고 #VALUE!가 반환된다.
255자 초과는 주로 두 가지 상황에서 발생한다.
- 여러 셀을
&연산자로 이어붙여 긴 문자열을 만들고 그 결과를 VLOOKUP 첫 번째 인수로 넘길 때 - 외부 시스템이나 ERP에서 복사한 데이터 중 설명 필드·메모 컬럼처럼 긴 텍스트가 포함된 경우
먼저 =LEN(A2)로 찾을 값의 길이를 확인한다. 255를 초과하면 VLOOKUP으로는 해결이 안 된다. INDEX/MATCH 조합은 이 제한이 없다.
=INDEX(C:C, MATCH(A2, B:B, 0))
MATCH의 첫 번째 인수에 255자를 넘는 값을 넣어도 정상 작동하므로, 데이터 구조가 단순하다면 이 전환이 가장 빠른 해결책이다. 구조를 바꾸기 전에 LEN으로 길이 확인부터 하자. 그래야 255자 초과가 원인인지 확정할 수 있다.
원인 ③ 네 번째 인수(range_lookup)에 잘못된 형식
VLOOKUP의 네 번째 인수는 TRUE(근사 일치), FALSE(정확 일치), 또는 이에 해당하는 1·0만 받는다. 여기에 텍스트 문자열이 들어가면 #VALUE!가 발생한다.
실제로 자주 생기는 실수는 두 가지다. TRUE/FALSE 대신 한국어 텍스트(“정확”, “근사”, “예”)를 입력하는 경우, 그리고 수식을 수정하는 과정에서 인수 자리가 밀려 네 번째 자리에 의도치 않은 값이 들어가는 경우다.
=VLOOKUP(A2, B:D, 2, "정확")→ #VALUE!=VLOOKUP(A2, B:D, 2, FALSE)→ 정상=VLOOKUP(A2, B:D, 2, 0)→ 정상
네 번째 인수를 생략하면 기본값 TRUE로 처리된다. 정확히 일치하는 값을 찾으려면 반드시 FALSE 또는 0을 명시해야 한다. 엑셀 함수마다 인수 순서와 기본값이 다르다는 점도 혼선을 부른다. SUMIF와 SUMIFS처럼 인수 순서가 통째로 뒤집히는 함수 차이를 함께 정리해두면 이런 실수를 줄이는 데 도움이 된다.
#VALUE! 오류를 빠르게 진단하는 순서
수식 전체를 한꺼번에 고치려 하면 변수가 많아 오히려 늦다. 인수 하나씩 순서대로 고정값으로 교체하며 테스트하는 것이 가장 빠른 방법이다.
| 진단 순서 | 확인 항목 | 확인 방법 |
|---|---|---|
| 1 | col_index_num 값 | 세 번째 인수를 직접 숫자(예: 2)로 교체해 테스트 |
| 2 | lookup_value 길이 | =LEN(찾을값셀)로 255 이하인지 확인 |
| 3 | range_lookup 형식 | 네 번째 인수를 FALSE 또는 0으로 명시 교체 |
각 인수를 교체하며 오류가 사라지는 시점을 찾으면 원인을 1~2분 안에 특정할 수 있다. 진단 과정에서 세 인수 모두 정상인데도 #VALUE!가 사라지지 않는다면, 수식이 배열 입력(Ctrl+Shift+Enter)으로 잘못 입력된 경우도 확인해본다.
IFERROR로 오류를 감추면 안 되는 이유
=IFERROR(VLOOKUP(...), "")로 처리하면 오류 메시지는 사라진다. 하지만 이 셀 값을 참조하는 다른 수식에 빈 문자열(“”)이 전달되고, 거기서 예상치 못한 계산 오류가 이어질 수 있다. SUMIF나 피벗테이블에서 이 셀을 집계할 때 결과가 조용히 틀어지는 상황이 바로 여기서 비롯된다.
오류 메시지는 수식이 보내는 경고 신호다. 신호를 가린다고 문제가 해결되지 않는다. 임시로 IFERROR를 쓰더라도 반드시 원인을 파악하고 수식을 수정하는 과정이 뒤따라야 한다.
반복되는 수식 오류를 구조적으로 줄이려면 자주 쓰는 수식을 매크로로 묶어 단축키로 실행하는 방법도 검토할 만하다. 수작업 입력 횟수가 줄면 인수 오입력 빈도도 낮아진다.
정리
엑셀 VLOOKUP에서 #VALUE! 오류가 발생하는 경로는 세 가지다. 열 번호가 0 이하이거나 텍스트로 전달될 때, 찾을 값이 255자를 초과할 때, 네 번째 인수에 논리값이 아닌 텍스트가 들어갔을 때. 데이터 형식 불일치는 #N/A를 일으키며 #VALUE!와는 무관하다.
진단은 인수 하나씩 고정값으로 교체하며 테스트하는 것이 가장 빠르다. 255자 초과가 원인이라면 INDEX/MATCH로 전환하고, 나머지 두 경우는 해당 인수를 올바른 형식으로 수정하면 바로 해결된다. 원인을 특정하지 않고 IFERROR로 덮어두는 것은 더 큰 문제의 씨앗이 된다.
자주 묻는 질문
VLOOKUP에서 #VALUE!와 #N/A 오류는 어떻게 다른가요?
#VALUE!는 수식에 전달된 인수 자체가 잘못된 경우(열 번호 0 이하, 찾을 값 255자 초과, 잘못된 논리값)에 발생합니다. #N/A는 수식 구조는 정상인데 찾는 값이 범위 안에 없거나 데이터 형식이 불일치할 때 나타납니다. 둘은 원인 계층이 완전히 다릅니다.
열 번호를 숫자로 직접 입력했는데도 #VALUE!가 나요. 왜 그런가요?
셀 참조로 열 번호를 가져올 경우, 해당 셀이 텍스트 형식으로 저장된 숫자라면 일부 버전에서 #VALUE!가 발생할 수 있습니다. =VLOOKUP(A2, B:D, VALUE(F1), FALSE)처럼 VALUE() 함수로 강제 변환하거나 수식에 직접 숫자를 입력해 테스트해보세요.
찾을 값이 255자를 넘으면 항상 #VALUE! 오류가 나나요?
네, VLOOKUP의 lookup_value 인수는 최대 255자까지만 지원합니다. 이를 초과하면 반드시 #VALUE! 오류가 발생합니다. 이 경우 INDEX/MATCH 조합으로 대체하면 255자 제한이 없어 문제가 해결됩니다.
IFERROR로 #VALUE! 오류를 감춰도 되나요?
오류 메시지는 사라지지만 근본 원인이 해결되지 않아, 해당 셀을 참조하는 SUMIF나 피벗테이블 등에서 잘못된 결과가 조용히 나올 수 있습니다. 임시 방편으로 사용하더라도 반드시 원인을 파악하고 수식을 수정해야 합니다.
INDEX/MATCH로 바꾸면 #VALUE! 오류가 해결되나요?
255자 초과 문제는 INDEX/MATCH로 전환하면 해결됩니다. 그러나 열 번호 인수 오류나 논리값 형식 오류는 수식 구조가 바뀌어도 입력값 자체를 올바르게 고쳐야 해결됩니다.