Google Sheets IMPORTRANGE가 #REF! "You need to connect these sheets"를 표시
안녕하세요, BlueByte입니다. IMPORTRANGE가 #REF!를 보이면 수식부터 다시 쓰지 마세요 — 이 #REF!는 대개 망가진 수식이 아니라 클릭 한 번을 기다리는 일회성 권한 요청입니다. 오늘은 그게 맞는지 확인하고, 연결을 부여하고, 안 풀리게 하는 두 가지를 짚는 순서로 가보겠습니다.
이 #REF!의 정체
=IMPORTRANGE(...) 수식이 데이터 대신 #REF!를 보입니다. 셀에 마우스를 올리면:
You need to connect these sheets. Allow access.이 #REF!는 망가진 수식이 아니라 아직 답하지 않은 일회성 권한 요청입니다. 이걸 알아채는 게 해결의 절반 — 사람들은 접근이 진짜 문제인데 멀쩡한 수식을 자꾸 다시 씁니다.
IMPORTRANGE가 연결을 요구하는 이유
IMPORTRANGE는 다른 스프레드시트에서 데이터를 읽으므로, Google은 대상 시트가 그 특정 소스에서 가져오도록 명시적으로 승인되기를 요구합니다. 한 번 승인 전까지 #REF!를 반환합니다. 안 풀리는 흔한 두 가지:
- 이 소스–대상 쌍에 대한 연결이 승인된 적 없음.
- 소스 스프레드시트 자체에 접근 권한이 없어 연결할 대상이 없음.
"Array result was not expanded"라고 뜨는 다른 #REF!는 별개 — 가져올 범위가 비어 있지 않은 셀을 덮어쓰려는 것입니다.
툴팁을 읽어 어느 쪽인지 확인
셀을 클릭해 툴팁을 읽으세요. Allow access 버튼과 함께 "You need to connect these sheets"면 연결 미승인 — 정상 경우입니다. 대신 권한 오류가 나면 소스 URL을 직접 여세요: 못 열면 접근 권한이 없는 것이고 그걸 먼저 고쳐야 합니다. 툴팁이 "Array result"를 말하면 문제는 접근이 아니라 공간입니다.
연결을 한 번 부여하기
-
IMPORTRANGE 수식이 있는 셀을 클릭합니다.
-
마우스를 올리거나(오류 툴팁 확인) 안내에서 Allow access를 누릅니다.
-
데이터가 로드되고, 같은 소스에서의 모든 IMPORTRANGE가 이제 다시 묻지 않고 동작합니다 — 부여는 수식마다가 아니라 소스마다입니다.
안내가 없으면 문법을 확인하세요 — 첫 인자는 소스 URL/ID, 둘째는 따옴표 범위:
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/SOURCE_ID/edit", "Sheet1!A1:C")실제 사례: 한 번의 부여가 전부를 커버
동료의 데이터 시트에서 =IMPORTRANGE("https://.../d/1AbC.../edit","Data!A1:F")로 끌어오는 대시보드를 만드는데 #REF!가 뜹니다. 셀에 마우스를 올리니 "You need to connect these sheets — Allow access"가 보입니다. Allow access를 누르니 범위가 즉시 채워집니다. 같은 소스를 가리키는 IMPORTRANGE 세 개를 더 추가해도 아무것도 다시 묻지 않습니다 — 연결이 소스 수준에서 부여돼 한 번 승인이 전부를 커버했습니다. 일주일 뒤 팀원이 대시보드를 열어도 데이터가 보입니다 — 부여가 계정이 아니라 시트에 있기 때문입니다.
pull과 갱신을 확인
셀이 소스 데이터로 채워지고, 같은 소스를 가리키는 다른 IMPORTRANGE도 풀려야 합니다. 소스에서 값을 바꿔 잠시 뒤 대상에서 갱신되는지 확인하세요 — 그게 일회성 복사가 아니라 살아 있는 연결임을 증명합니다.
나중에 깨지지 않게 하려면
시트를 처음 만들 때 소스를 한 번 연결하고, 대상을 편집하는 모두가 소스에 최소 보기 권한을 갖게 해 나중의 권한 변경이 조용히 pull을 깨지 않게 하세요.
평범한 #REF!·#N/A와의 구분
"connect these sheets" #REF!는 IMPORTRANGE 고유의 권한 게이트입니다. 다른 곳의 평범한 #REF!는 잘못된 셀 참조(삭제된 셀)이고, 조회의 #N/A는 일치 없음 — 둘 다 접근 부여로 안 풀립니다. 그러니 툴팁이 "connect"라 하면 다시 쓰지 말고 클릭하세요.
관련 질문
Allow access를 눌렀는데도 계속 #REF!입니다.
소스 스프레드시트에 최소 보기 권한이 있는지, 수식의 소스 ID가 올바른지 확인하세요. 접근 허용 후 대상 시트를 다시 여세요.
협업자들도 접근을 허용해야 하나요?
아니요. 연결은 스프레드시트 수준에서 부여되므로, 편집자 한 명이 허용하면 대상 시트에 접근하는 모두에게 링크가 동작합니다.
전엔 됐는데 지금 다시 #REF!입니다.
소스 접근이 회수됐을 가능성이 큽니다. 소스에 대한 보기 권한을 복구한 뒤 대상에서 재연결하세요.
툴팁이 'Array result was not expanded'입니다.
그건 다른 #REF! — 가져올 범위가 비어 있지 않은 셀을 덮어쓰려는 것입니다. 수식 아래·오른쪽 셀을 비워 결과가 들어갈 자리를 주세요.
매번 셀을 열지 않고 시트를 연결할 수 없나요?
소스당 한 번의 승인이 대상의 그 소스에서 나오는 모든 IMPORTRANGE를 커버하므로 한 번만 하면 됩니다. 그 첫 Allow access 외에 UI의 일괄 방법은 없습니다.
참고 자료
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을 삭제하면 문서가 다시 편집 가능하게 열립니다.