Google Sheets: Array result was not expanded because it would overwrite data
안녕하세요, BlueByte입니다. Google Sheets가 #REF!와 함께 Array result was not expanded because it would overwrite data in [cell] 메모를 보여줄 때, 수식에는 문제가 없습니다 — 결과 블록을 만들었는데 그 블록이 필요한 셀에 이미 무언가 있어, Sheets가 여러분 데이터를 덮어쓰기를 거부한 것입니다. 가까운 사촌은 열을 채우는 대신 한 줄만 돌려주는 ARRAYFORMULA입니다. 오늘은 두 경우, 왜 일어나는지, 어느 쪽인지 확인하는 법, 각각의 해결과 기대 출력, 그리고 spill을 유지하는 법까지 하나씩 짚어보겠습니다.
Array result was not expanded가 뜻하는 것
값을 하나보다 많이 돌려주는 수식들이 있습니다 — FILTER, SORT, UNIQUE, IMPORTRANGE, 또는 ARRAYFORMULA로 감싼 것. Sheets는 그 블록을 여러분이 입력한 셀에서 시작해 오른쪽과 아래의 이웃 셀로 spill하려 합니다. 대상 셀 중 하나라도 이미 값을 가지고 있으면 그럴 수 없습니다 — 데이터를 말없이 덮어쓰는 것이 에러보다 나쁘기 때문입니다:
#REF!
Array result was not expanded because it would overwrite data in B5.메모가 가리키는 셀(여기서는 B5)이 길을 막은 첫 번째 셀입니다. 이것은 망가진 수식이 아닙니다 — 실행돼 결과를 냈는데 둘 곳이 없었던 것입니다.
헷갈리는 두 증상
비슷해 보이는 별개의 문제가 둘 있습니다:
- 막힌 spill — 위의
#REF!. 수식이 여러 셀을 원하는데 하나가 차 있습니다. - 한 줄만 채우는 수식 — 열 전체의 곱을 기대하며
=A2:A*B2:B를 썼는데 2행만 계산됩니다. 수식이 배열 인식이 아니라 spill을 시도조차 하지 않은 것입니다.
원인이 정반대입니다: 앞쪽은 spill했다가 막혔고, 뒤쪽은 아예 spill하지 않았습니다. 해결에 손대기 전에 둘을 구분하세요.
배열 결과가 막히거나 안 퍼지는 이유
막힌 #REF! 경우는 다음 중 하나입니다:
- 수식 아래나 옆의 데이터 — spill 범위에 입력된 값, 흔히 몇 줄 아래의 엉뚱한 입력.
- 다른 수식의 출력이 같은 셀에 내려앉았습니다.
- 대상 범위 안의 병합된 셀 — 병합 셀은 spill된 값을 받을 수 없습니다.
한 줄만 차는 경우는 뿌리가 다릅니다: Sheets가 자동 확장하지 않는 범위에 대한 평범한 산술·조회 수식이라 명시적 ARRAYFORMULA 래퍼가 필요하거나, 결합하는 두 범위의 크기가 같지 않은 것입니다.
spill 범위에 무엇이 있는지, 수식이 배열 인식인지 확인하기
어느 셀이 막는지 추측하지 마세요 — 메모가 하나를 가리키지만 더 있을 수 있습니다. 결과가 채워야 할 열에서 수식 아래의 비어 있지 않은 셀을 세어 봅니다:
=COUNTA(B2:B1000)기대하는 머리글 행보다 많다면 spill 범위에 무언가 놓여 있는 것입니다. 한 줄만 차는 문제라면 수식이 감싸였는지 확인하세요 — ARRAYFORMULA는 수식 입력줄에 함수 접두사를 보여줍니다. Google 문서는 많은 배열 수식이 이웃 셀로 자동 확장되며, 편집 중 Ctrl+Shift+Enter를 누르면 ARRAYFORMULA( 접두사가 자동으로 붙는다고 설명합니다.
결과가 들어갈 셀을 비우기 (#REF! 해결)
무엇이 spill을 막는지 알았으면 그 셀을 비우세요 — 엉뚱한 값을 지우거나, 배열 수식을 비어 있는 열로 옮깁니다:
=FILTER(A2:A, A2:A<>"")수식 아래의 대상 열이 비면, #REF!를 돌려주던 같은 FILTER가 이제 결과 전체를 spill합니다. 병합 셀이 길을 막는다면 범위를 선택해 Format ▸ Merge cells ▸ Unmerge를 고른 뒤 수식이 확장되게 하세요. 기대 결과: #REF!가 사라지고 값이 수식 셀부터 아래로 채워집니다.
한 줄짜리 수식을 열 전체로 퍼뜨리기
"2행만 계산되는" 경우는 연산을 ARRAYFORMULA로 감싸고, 새 행이 포함되도록 끝이 열린 범위를 쓰세요:
=ARRAYFORMULA(A2:A * B2:B)Google 레퍼런스는 인자를 "a range, mathematical expression using one cell range or multiple ranges of the same size, or a function that returns a result greater than one cell"로 설명합니다. 이 같은 크기 규칙이 중요합니다: A2:A * B2:B10은 열린 범위와 고정 범위를 섞어 에러가 납니다. 빈 입력이 0을 돌려주지 않도록 조건으로 빈 행을 막으세요:
=ARRAYFORMULA(IF(A2:A="", "", A2:A * B2:B))실제 사례: spill 범위에 입력된 머리글
라이브 표를 만들려고 F2에 =SORT(FILTER(A2:D, C2:C>0), 1, TRUE)를 넣습니다. #REF!가 뜹니다 — Array result was not expanded because it would overwrite data in F8. 아래로 내려보니 몇 주 전 누군가 F8에 적어 둔 메모가 있습니다. 그 메모를 다른 시트로 잘라내자, F8이 비는 순간 정렬된 표가 F2부터 F8을 지나 아래로 에러 없이 spill됩니다. 수식은 내내 옳았고, 자리가 필요했을 뿐입니다.
spill을 확인하고 재발을 막기
수식 셀을 클릭해 보면, 올바른 spill은 채워진 블록 전체를 강조하고, 범위에 건 COUNTA()가 이제 수식이 만든 행 수와 일치합니다. 유지하려면: 배열 수식을 비어 있는 전용 열의 맨 위에 두어 아무것도 그 spill 범위로 자라들지 못하게 하세요. 수식이 채우는 영역에는 병합 셀을 피하세요. 추가된 행이 포함되도록 고정 범위보다 끝이 열린 범위(A2:A)를 쓰세요. 협업자가 spill 아래에 계속 입력한다면 Data ▸ Protect sheets and ranges로 범위를 보호하세요.
Excel의 #SPILL!·#N/A와 어떻게 다른가
발상은 Excel과 같지만 표면이 다릅니다. Excel은 동적 배열 spill을 #SPILL!과 "Spill range isn't blank" 메모로 막고, Google Sheets는 #REF!와 "Array result was not expanded"를 씁니다. 둘 다 결과가 내려앉을 자리가 없다는 뜻이지만, 제품도 에러 토큰도 달라서 한쪽에 쓴 대책(예: Excel의 spill anchor)이 다른 쪽엔 없습니다. 그리고 둘 다 #N/A가 아닙니다: 그것은 조회가 일치를 못 찾았다는, spill 자리가 아니라 값의 문제입니다.
관련 질문
메모는 셀 하나를 가리키는데, 그걸 비워도 #REF!가 안 풀립니다.
spill 범위에 차 있는 셀이 하나가 아닙니다. Sheets는 첫 번째만 알려줍니다. 결과가 채워야 할 열 전체를 선택해 엉뚱한 값을 모두 지우거나, 확장할 자리가 있는 빈 열로 수식을 옮기세요.
함수가 이미 배열을 돌려주는데도 ARRAYFORMULA가 필요한가요?
아니요. FILTER, SORT, UNIQUE, IMPORTRANGE는 스스로 spill합니다. ARRAYFORMULA는 A2:A*B2:B나 행별 IF처럼 배열이 아닌 연산을 한 셀 계산 대신 범위 전체로 확장시킬 때 씁니다.
ARRAYFORMULA가 빈 행에 0을 돌려줍니다.
끝이 열린 범위가 빈 셀을 포함하고, 빈 값에 숫자를 곱하면 0이 됩니다. IF(A2:A="", "", …)로 감싸 빈 행이 0 대신 공백을 돌려주게 하세요.
범위 크기가 같아야 한다고 나옵니다.
열린 범위와 고정 범위를 섞었습니다. 예: A2:A * B2:B10. 양쪽을 모두 열린 범위(A2:A, B2:B)로 하거나 같은 고정 높이로 맞춰 행마다 짝이 있게 하세요.
병합된 셀이 원인일 수 있나요?
네. spill 범위 안의 병합 셀은 값을 받을 수 없어 배열이 확장되지 못하고 #REF!가 납니다. Format ▸ Merge cells ▸ Unmerge로 범위를 병합 해제하면 수식이 정상적으로 채워집니다.
참고 자료
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을 삭제하면 문서가 다시 편집 가능하게 열립니다.