이 글은 Firebase 실무 오류 해결 모음: Storage, Firestore, Auth 체크리스트의 세부 항목입니다. 전체 설정 흐름과 관련 오류 해결 순서는 대표 허브 글에서 함께 확인할 수 있습니다.
브라우저 콘솔에 CORS 정책 오류가 보이면 Firebase 문제인지, CORS 설정 문제인지, 요청 방식 문제인지 구분하기 어렵습니다.
CORS 오류와 권한 오류를 먼저 구분합니다
Firebase 에서 이미지 업로드가 막힐 때 콘솔에 CORS라는 단어가 보이면 모두 같은 문제처럼 느껴집니다. 하지만 실제로는 브라우저가 요청을 차단한 CORS 문제일 수도 있고, Firebase 에서 권한이 거부된 문제일 수도 있습니다. 403 가 함께 보이면 를 봐야 하고, preflight 요청이나 Access-Control-Allow-Origin 메시지가 보이면 CORS 설정을 확인해야 합니다.
브라우저 요청의 출처를 확인합니다
CORS는 브라우저가 서로 다른 출처로 요청을 보낼 때 적용되는 정책입니다. 로컬 개발 환경의 http://localhost:3000, 배포된 https 도메인, 관리자 페이지 도메인이 서로 다르게 취급됩니다. 버킷에 허용한 origin과 실제 요청 origin이 다르면 업로드나 다운로드가 막힐 수 있습니다. 먼저 Network 탭에서 요청 URL과 Origin 헤더를 확인합니다.
[ { "origin": ["http://localhost:3000", "https://example.com"], "method": ["GET", "POST", "PUT"], "responseHeader": ["Content-Type"], "maxAgeSeconds": 3600 }
]CORS 설정은 버킷에 적용해야 합니다
Firebase 의 CORS 설정은 코드 안에서 해결하는 것이 아니라 버킷 설정에 적용합니다. Google Cloud CLI나 관련 도구로 허용 origin, method, responseHeader, maxAgeSeconds를 지정합니다. 개발 중에는 localhost를 포함하고, 배포 후에는 실제 서비스 도메인을 포함해야 합니다. 모든 origin을 허용하는 설정은 빠르게 테스트할 수 있지만 운영 환경에서는 필요한 도메인만 허용하는 편이 안전합니다.
Storage Rules는 인증과 파일 경로 기준을 담당합니다
CORS 설정이 맞아도 에서 막히면 업로드는 실패합니다. 로그인 사용자만 업로드할 수 있는지, 특정 폴더만 접근 가능한지, 파일 크기나 contentType 제한이 있는지 확인해야 합니다. 이미지 업로드라면 request.resource.contentType.matches(“image/.*”) 같은 조건을 사용할 수 있지만, 프론트엔드에서 보내는 파일 타입이 비어 있으면 예상과 다르게 막힐 수 있습니다.
로컬과 배포 도메인을 따로 점검합니다
로컬에서는 업로드가 되는데 배포 후 막힌다면 CORS origin에 배포 도메인이 빠졌을 가능성이 있습니다. 반대로 배포는 되는데 로컬에서만 막히면 localhost 포트가 다르거나 http/https 차이가 원인일 수 있습니다. 최종 점검은 콘솔 에러 구분, Network origin 확인, CORS 설정, 조건, 실제 배포 도메인 순서로 진행합니다.
발행 전 마지막 점검 기준
Firebase CORS 오류 해결: 이미지 업로드가 막힐 때 확인할 설정은 문제 해결형 글이므로 독자가 바로 따라 할 수 있는 순서가 중요합니다. 증상부터 원인을 좁히고로컬에서 재현한 뒤, 설정과 버전 차이를 확인하는 흐름으로 마무리해야 합니다. 기존 글과 겹치는 설명은 길게 반복하지 않고, 현재 글에서는 어떤 기준으로 다음 행동을 선택할지 남기는 것이 좋습니다.
실제 발행 전에는 제목과 포커스 키워드가 너무 넓지 않은지, 본문 이미지가 문제 해결 흐름을 설명하는지, WordPress JSON의 카테고리와 Rank Math 포커스 키워드가 비어 있지 않은지 확인합니다. 이 점검까지 끝나야 단순 초안이 아니라 업로드 가능한 작성본으로 볼 수 있습니다.
실제 작업에서는 재현 조건을 먼저 고정합니다
Firebase CORS 오류 해결: 이미지 업로드가 막힐 때 확인할 설정 같은 문제 해결형 글은 해결 명령어를 바로 나열하는 것보다 재현 조건을 고정하는 과정이 중요합니다. 같은 코드라도 로컬 개발 서버로컬 빌드, Preview 배포, Production 배포에서 다르게 동작할 수 있기 때문입니다. 독자는 먼저 어느 환경에서 문제가 나는지 표시하고같은 조건으로 다시 실행해본 뒤 원인을 좁혀야 합니다.
문제가 재현되는 조건을 적어두면 수정 후 검증도 쉬워집니다. 예를 들어 환경변수 문제라면 개발 서버 재시작 전후를 나눠 보고, 의존성 문제라면 node_modules를 지운 뒤 lockfile 기준으로 다시 설치합니다. 폼 validation 문제라면 submit 전과 submit 후의 errors 객체를 비교하고, 문제라면 브라우저 Network 탭에서 Origin과 응답 코드를 확인합니다.
또 하나 중요한 점은 임시 우회와 실제 해결을 구분하는 것입니다. 빌드 옵션을 끄거나 강제 설치 옵션을 쓰면 당장 지나갈 수는 있지만, 다음 배포에서 다시 막힐 수 있습니다. 글 본문에서는 빠른 확인 방법을 소개하되, 최종적으로는 설정과 버전을 맞추고 원인을 기록하는 쪽으로 안내해야 합니다.
같은 오류가 반복되지 않게 기록할 것
문제를 해결한 뒤에는 어떤 로그가 원인이었는지, 어떤 설정을 바꿨는지, 어떤 버전 기준으로 맞췄는지 남겨두는 것이 좋습니다. 팀 프로젝트라면 README나 작업 메모에 Node 버전, 패키지 매니저, 환경변수 이름, 배포 플랫폼 설정 위치를 적어두면 다음 사람이 같은 시간을 쓰지 않아도 됩니다.
블로그 글에서도 이 기록 방식이 중요합니다. 독자가 글을 읽고 단순히 “해결했다”에서 끝나는 것이 아니라, 다음에 같은 증상이 나오면 어디부터 확인해야 하는지 기억할 수 있어야 합니다. 그래서 마지막에는 증상, 확인 위치, 수정 방법, 재발 방지 기준을 짧게 다시 연결해주는 구성이 좋습니다.
마지막으로, 해결 후에는 같은 증상이 다시 나왔을 때 바로 비교할 수 있도록 수정 전후 조건을 남깁니다. 어떤 명령어를 실행했는지, 어떤 로그가 바뀌었는지, 어떤 설정값을 수정했는지 적어두면 다음 배포나 다음 설치에서 문제를 더 빨리 좁힐 수 있습니다. 문제 해결 글의 목적은 한 번의 정답을 외우게 하는 것이 아니라, 비슷한 오류를 만났을 때 확인 순서를 떠올리게 만드는 데 있습니다.
“Firebase CORS 오류 해결: Storage 이미지 업로드가 막힐 때 확인할 설정”에 대한 3개의 생각