엑셀 | 오류 다섯 개만 읽을 줄 알면 된다

VLOOKUP 하나 넣었을 뿐인데 #N/A가 주르륵 뜬다. 열 하나 지웠더니 이번엔 #REF!가 사방에 번진다.

그런데 오류 기호 자체가 힌트다. #N/A와 #VALUE!는 원인이 완전히 다르고 고치는 자리도 다르다. 어느 쪽인지만 읽어도 절반은 끝난 셈인 것 같다.

자주 만나는 다섯 개를 한 시트에서 실제로 내 봤다.

#N/A는 값을 못 찾은 것이지 수식이 틀린 게 아니다. 반대로 #NAME?는 엑셀이 수식 자체를 해석하지 못한 것이다. 이 구분만 해도 엉뚱한 곳을 뒤지는 시간이 줄어든다.

#N/A — 대체로 공백이 범인이다

VLOOKUP·MATCH·XLOOKUP이 “찾아봤는데 없다”고 알려주는 신호다. 진짜로 없는 경우도 있지만, 눈으로 보면 분명히 있는데도 뜨는 쪽이 더 골치다.

원본 시스템에서 내려받은 코드 뒤에 공백이 딸려오면 "A1007 "과 "A1007"은 다른 값이 된다. 조회 열에 =LEN(A2)를 걸어 글자 수가 하나 더 나오면 범인은 공백이다.

=TRIM(A2)

형식 불일치도 흔하다. 한쪽은 숫자 1001, 다른 쪽은 텍스트 "1001". 셀 왼쪽 위 초록 삼각형이 단서고, VALUE나 TEXT로 한쪽에 맞춘다.

값이 없는 게 정상인 자리 — 신규 거래처라 아직 단가표에 없다든가 — 라면 고치려 들 게 아니라 뒤에 나올 IFNA로 메시지를 바꿔주는 쪽이 맞다.

#REF! — 밟고 있던 발판이 사라졌다

참조하던 셀·열·시트가 없어지면 그 자리를 가리키던 수식이 한꺼번에 #REF!가 된다. 위 그림의 두 번째 줄처럼 2열짜리 표에 5열을 달라고 해도 같은 오류가 뜬다.

무서운 건 연쇄다. B열을 지웠는데 B열을 물던 D열이 깨지고, D열을 물던 요약 시트까지 줄줄이 무너진다.

당장은 Ctrl + Z. 이미 저장하고 닫았다면 Ctrl + H로 #REF!를 검색해 어디가 깨졌는지 전수로 확인하는 수밖에 없다. 아무래도 예방이 훨씬 싸다 — 열은 삭제 대신 숨기기, 흔들리면 안 되는 표는 이름 정의로 참조.

#VALUE! — 계산할 수 없는 걸 시켰다

숫자가 와야 할 자리에 글자가 온 경우가 대부분이다. =A2+B2인데 B2에 “미정”이라고 적혀 있으면 이 오류가 난다.

다른 시스템에서 받은 숫자가 텍스트로 저장돼 있는 게 제일 흔하다. 어느 칸이 범인인지 모르겠으면 =ISTEXT(A2)로 TRUE가 뜨는 칸을 찾는다.

한 칸씩 고치기 귀찮으면 빈 셀에 1을 넣고 복사한 뒤 범위에 선택하여 붙여넣기 → 곱하기. 한 번에 진짜 숫자로 바뀐다.

#DIV/0!과 #NAME?

#DIV/0!는 말 그대로 0이나 빈 셀로 나눴을 때다. 달성률 =매출/목표에서 목표가 아직 안 채워졌으면 뜬다. 나누기 전에 분모를 한 번 보게 만들면 된다.

=IF(B2=0, "", A2/B2)

#NAME?는 거의 오타다. =SUMM(...) 같은 함수명 오타, =IF(A2=완료,...)처럼 텍스트에 따옴표를 안 씌운 경우, 정의하지 않은 범위 이름. 그리고 엑셀 2016에서 XLOOKUP을 썼을 때도 이게 뜬다.

IFERROR를 습관처럼 씌우면 안 되는 이유

오류를 못 고치거나 뜨는 게 정상인 자리라면 다른 값으로 대체한다. 문제는 IFERROR가 모든 오류를 다 먹는다는 점이다. 같은 조회를 셋으로 감싸 봤다.

첫 줄이 문제다. 열 번호를 잘못 쓴 진짜 버그인데 IFERROR가 “확인필요”로 덮어 버렸다. 둘째 줄은 같은 식을 IFNA로 감싼 것이라 #REF!가 그대로 남아 눈에 띈다.

그래서 조회 함수에는 IFNA 쪽이 안전하다고 본다. 값 없음만 메시지로 바꾸고, 참조나 형식이 깨진 건 오류인 채로 두는 게 낫다.

=IFNA(VLOOKUP(A2, 단가표, 2, 0), "미등록")

대체값을 정할 때 하나 더. 합계나 평균을 낼 열이라면 “확인필요” 같은 텍스트 대신 빈칸("")이나 0을 넣어야 뒤 계산이 안 깨진다.

결론. 셀에 적힌 글자부터 읽자

#N/A면 조회 대상을, #REF!면 지운 셀을, #VALUE!면 형식을 의심하면 된다. 시트 전체를 훑을 땐 수식 → 오류 검사로 순회하고, 여러 오류가 섞여 있으면 #REF!부터 잡는 게 순서인 듯 싶다. 원본이 살아나면 그걸 물던 오류도 같이 사라지니까.

다음에 #N/A를 만나면 일단 TRIM부터 걸어 보기로.