Excel #REF! 오류: 잘못된 셀 참조
안녕하세요, BlueByte입니다. #REF!는 수식이 더는 존재하지 않는 셀을 가리킨다는 뜻입니다 — 값이 아니라 참조 자체가 파괴된 것이죠. 방금 그랬다면 Ctrl+Z 한 번이면 돌아옵니다. 오늘은 가능하면 되돌리고, 앞으로의 삭제가 이걸 다시 못 하게 수식을 다시 세우는 순서로 가보겠습니다.
#REF!가 뜻하는 것
값이 있어야 할 칸에 #REF!가 뜹니다:
=SUM(B2,#REF!,D2)수식이 가리키던 셀 참조가 더는 유효하지 않습니다 — 값이 아니라 참조 자체가 파괴됐습니다. Excel이 더는 풀 수 없는 주소 자리에 #REF!를 써넣고, 그걸 수식에 박아버려 저장하면 원래 주소는 사라집니다.
참조를 파괴하는 것
#REF!는 수식이 가리키던 셀을 삭제하거나 덮어썼을 때 생깁니다:
- 수식이 의존하던 행·열을 삭제 — Excel이 참조를 옮길 곳이 없음.
- 수식이 참조하던 칸 위로 잘라 붙여넣기.
- VLOOKUP(또는 INDEX)의 열 인덱스가 표 범위보다 큼.
- INDIRECT가 닫힌 통합 문서를 가리킴.
- 3‑D 참조나 다른 시트 수식이 의존하던 워크시트를 삭제.
#REF!가 어디 있는지 찾기
수식을 열어 #REF!가 어디 있는지 보고 전부 찾으세요 — 홈 → 찾기 및 선택 → 찾기에서 #REF! 검색. 뭔가 삭제한 순간 나타났으면 그 삭제가 원인. VLOOKUP 안이면 열 인덱스를 범위 너비와 대조하고, INDIRECT 안이면 참조 파일이 열려 있는지 확인하고, 한 시트의 수식이 한꺼번에 깨졌으면 삭제된 시트가 유력합니다.
되돌리고, 견고하게 만들기
-
방금 그랬다면 즉시 Ctrl+Z로 삭제를 되돌립니다. 삭제된 셀이 복구되며 참조가 스스로 고쳐집니다.
-
실행 취소가 안 되면 수식의
#REF!부분을 올바른 셀 주소로 바꿉니다. -
견고하게 — 단일 셀을 나열하는 대신 범위를 참조하면 안쪽 열을 지워도 자동 조정됩니다:
=SUM(B2:D2)이제 C열을 지워도 #REF!가 아니라 =SUM(B2:C2)가 됩니다.
- VLOOKUP은 열 인덱스를 표 범위 안에 두세요 —
=VLOOKUP(A8,A2:E5,5,FALSE)는 유효(5열), 6열 요구는#REF!.
실제 사례: 잘못된 정리
시트를 정리하려 안 쓰는 B열을 지웠는데, =C2*B2이던 요약 칸이 이제 =C2*#REF!가 됩니다. 방금 그랬으니 Ctrl+Z를 누르니 B열이 돌아오고 수식이 다시 =C2*B2가 됩니다. 요약이 지울지 모를 열에 의존하면 안 됨을 깨닫고, 대신 의도한 입력을 이름 범위로 참조하게 고쳐 이후 정리가 깨지 못하게 합니다. #REF! 찾기로 다른 수식은 영향 없었음을 확인합니다.
참조가 유지되는지 확인
칸이 계산 값을 다시 보이고, 찾기로 시트에 더는 #REF!가 없어야 합니다. 새 범위 참조 안의 테스트 열을 지워 수식이 깨지지 않고 조정되는지 확인하세요 — 그게 견고한 버전이 동작함을 증명합니다.
다시 겪지 않으려면
단일 셀 지정 대신 범위 참조를 써서 행·열을 지울 때 Excel이 조정하게 하세요. 수식이 쓰는 데이터를 지워야 하면 남은 참조를 두지 말고 같은 단계에서 수식을 갱신·제거하세요.
#NAME?·#VALUE!와의 구분
#REF!는 참조가 사라진 것. #NAME?은 이름·함수를 못 알아본 것(함수명 오타), #VALUE!는 인수 타입이 틀린 것. #REF!만 존재하던 참조가 더는 존재하지 않는 문제입니다 — 그러니 이게 보이면 방금 무엇을 지웠는지 보세요.
관련 질문
원래 참조를 되살릴 수 있나요?
실행 취소 기록에 남아 있는 동안 Ctrl+Z로 삭제를 되돌릴 때만 가능합니다. #REF!가 박혀 저장되면 Excel은 원래 참조가 뭐였는지 더는 모릅니다 — 다시 입력해야 합니다.
재발을 어떻게 막나요?
단일 셀을 지정하는 대신 범위 참조(=SUM(B2:D2))를 쓰세요. 범위 안을 지우면 Excel이 조정하므로 수식이 살아남습니다.
제 INDIRECT가 아무것도 안 지웠는데 #REF!입니다.
닫힌 통합 문서를 가리키는 INDIRECT는 #REF!를 냅니다 — 풀려면 원본 파일이 열려 있어야 합니다. 참조 통합 문서를 열거나 파일 간 INDIRECT를 피하세요.
VLOOKUP이 #REF!인데 데이터는 있습니다.
열 인덱스 번호가 표 범위의 열 수보다 큽니다. 인덱스를 줄이거나 범위를 넓혀 요청 열이 존재하게 하세요.
한 시트의 모든 수식이 한꺼번에 깨졌습니다.
그 수식들이 참조하던 워크시트를 삭제했을 가능성이 큽니다. 가능하면 실행 취소하고, 아니면 시트를 다시 만들거나 수식을 올바른 소스로 다시 가리키세요.
참고 자료
Haneul Seo
Infrastructure engineer · 10+ years running Linux fleets
같은 카테고리 다른 글
Gmail이 550-5.7.26으로 거부: 도메인의 DMARC 정책 때문에 인증되지 않은 메일이 수신 거부됨
Gmail이 우리 도메인이 직접 게시한 DMARC 정책을 집행한 결과입니다. 메시지가 header From: 도메인 기준으로 SPF·DKIM 정렬을 모두 통과하지 못했고, p=quarantine이나 p=reject 정책이 이를 하드 바운스로 바꿉니다. Authentication-Results 헤더가 어느 검사가 실패했는지 알려주고, SPF·DMARC·DKIM 레코드를 향한 dig 세 번이 원인을 지목합니다. SPF나 DKIM으로 인증하라는 비슷한 문구의 바운스는 정책이 아니라 Gmail의 기본 발신자 요구사항에 걸린 다른 문제입니다.
Microsoft Entra ID: AADSTS50011, 요청에 지정된 redirect URI 가 앱에 등록된 redirect URI 와 일치하지 않음
로그인은 끝까지 성공했는데 마지막 한 단계에서 Entra ID 가 거부합니다. 앱이 보낸 redirect_uri 가 등록된 URI 중 어느 것과도 문자 단위로 같지 않기 때문입니다. 비교는 대소문자를 구분하고 끝의 슬래시를 세며, localhost 를 제외하면 https 를 요구하고 포트도 일치해야 합니다. 목록도 web·spa·publicClient 세 개로 나뉘어 있고, application 객체가 아닌 service principal 에 넣은 URI 는 동기화 과정에서 사라질 수 있습니다. 오류 메시지에서 URI 와 앱 ID 를 꺼내 az ad app show 로 대조하고, az ad app update 나 Graph PATCH 로 정확한 문자열을 넣은 뒤 3~5분 기다리면 됩니다.
Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled
smtp.office365.com 으로 메일을 보내던 스캐너·스크립트·앱이 535 5.7.139 로 멈추는 이유는 SMTP AUTH 프로토콜이 테넌트 전체, 해당 메일박스, 또는 Basic 인증을 막는 인증 정책·보안 기본값 중 어딘가에서 꺼져 있기 때문입니다. 문구(Tenant, Mailbox, 'did not meet the criteria')를 읽고 Get-TransportConfig·Get-CASMailbox·Get-AuthenticationPolicy 로 확인한 뒤, 테넌트 전체가 아니라 필요한 메일박스 하나만 엽니다. Basic SMTP AUTH 는 다리일 뿐입니다. Microsoft 는 2026년 12월 말 기존 테넌트에서 기본 비활성화하므로 발신자를 OAuth·High Volume Email·릴레이 커넥터로 옮겨야 합니다.
Zoom: "Unable to connect" 오류 코드 5003 — 브라우저는 되는데 데스크톱 앱만 Zoom 에 못 붙을 때
오류 5003 은 같은 PC 의 웹 클라이언트는 정상 입장하는데 Zoom 데스크톱 앱이 Zoom 서버와의 연결을 끝내지 못하는 상태입니다. 앱은 브라우저보다 더 많은 것을 필요로 합니다. Zoom 방화벽 문서는 미팅용 TCP 443/8801/8802 와 UDP 3478/3479/8801–8810, 인증서 검증용 CA 호스트 목록을 들고, zoom.us 와 *.zoom.us 를 프록시·SSL 검사에서 제외하라고 권고합니다. 포트 테스트, curl issuer 확인, 앱 내장 Network Connectivity Tool(Ctrl+Alt+Shift+D / Cmd+Option+Shift+D)로 어느 계층이 끊겼는지 보고 그 계층을 고치며, 재설치는 옆자리는 되는데 한 대만 실패할 때 씁니다.
Slack: 회사 프록시 뒤에서 뜨는 "Slack cannot connect"와 회색 "Last updated…" 띠
Slack은 채널을 평범한 HTTPS로 불러오지만 새 메시지는 443 포트로 Slack이 이름을 밝힌 wss-*.slack.com 호스트 셋(primary·backup·mobile)에 붙는 지속 WebSocket으로 받습니다. 프록시나 방화벽이 HTTP 쪽은 통과시키고 upgrade는 막으면 — 대개 wss 호스트에 SSL 복호화가 켜져 있거나 허용 목록이 slack.com에서 끝나기 때문에 — 브라우저는 멀쩡해 보이는데 앱은 회색 "Last updated…" 띠나 "Slack cannot connect."를 띄웁니다. 문제의 PC에서 curl 프로브 두 개로 어느 계층이 막혔는지 보고, wss 호스트 세 개를 복호화에서 예외 처리하고, my.slack.com/help/urls의 도메인을 전부 허용한 뒤 my.slack.com/help/test로 확인합니다.
Word: 문서가 "locked for editing by another user"라며 열리지 않음
Word가 문서의 잠금(owner file)을 발견해 다른 누군가가 열어 두었다고 판단하고 읽기 전용 사본만 제안합니다. 대개는 아무도 열지 않았습니다: 크래시가 잠금을 남겼거나, 숨은 Word 프로세스가 여전히 파일을 쥐고 있는 것입니다. 어느 쪽인지 확인하고 Word 인스턴스를 모두 닫은 뒤 남겨진 ~$ owner file을 삭제하면 문서가 다시 편집 가능하게 열립니다.